DX NetOps

 View Only
  • 1.  Modeling Across Landscapes

    Posted Dec 07, 2022 11:47 AM

    Reaching out to the community for some advice.  

    Here is the situation.  My organization operates using significant separation of duties environment.  We are across the entire United States.  The LAN is managed by a different set of admins than the WAN.

    We are operating Spectrum in a distributed environment and have 3 landscapes.  

    Leadership is requesting a single pane of glass view of the network but I am running into some roadblocks.  

    LS1 - Landscape 1

    LS2 - Landscape 2 

    R1 - Router 1 
    LAN - Local Area Network



    R1 is configured to communicate with LS1 only 
    LAN is configured to communicate with LS2 only

    R1 and R2 are at the same location 

    I need to create a container or global collection to make 1 Icon on the single pane of glass.  This is the same situation as all of my sites.   My single pane of glass needs to have Container per site all in one view. 



  • 2.  RE: Modeling Across Landscapes

    Posted Dec 09, 2022 05:25 AM
    Hi Spencer,

    We looked into something similar but unfortunately as each device has it's own device ID and landscape ID, there is no way to reconcile those into a single device. The MLS is only able to see them within their own landscape.

    In the end it was easier to use a single landscape and the multitude of security options to lock devices and containers down on a per user group basis.

    Regards, JB.


  • 3.  RE: Modeling Across Landscapes

    Posted Dec 09, 2022 11:05 AM

    James,

    Thanks for the feedback.  I am exploring options now.   I might model devices on multiple landscapes and set them to proxy.   I just don't know exactly what all the proxy setting does. 

    Spence




  • 4.  RE: Modeling Across Landscapes

    Posted Dec 12, 2022 04:42 AM
    Isn't this supposed to the goal of a Global Collection? To see/consolidate models from different landscapes? 

    Access rights to each area of the network are controller via Security Strings, as James was suggesting earlier. You can assign Security Strings on GC also, so you can control the automatic setting of Security String via a Policy. Not all models inherit Security Strings from parent models.  

    You should not have to consolidate everything in one landscape. It should work with multiple landscapes also. It the same principle. You'd have a problem whenever you'd have to monitor each device twice in a 2 different landscapes, if the case for Root Cause Analysis and Fault Isolation.

    There's however something called Proxy Model that would allow you to only create an alarm for one of those 2 duplicate devices.

    ------------------------------
    Cătălin Fărcășanu
    Senior Consultant
    SolvIT Networks
    ------------------------------



  • 5.  RE: Modeling Across Landscapes

    Posted Dec 12, 2022 12:00 PM

    Catalin, 

    Thanks for the feedback.    Because of the Devices at a single site WAN talking to LS1 and LAN talking to LS2.   I was hoping to be able to combine them into one container in  a Global Collection.   My first attempt was to create a Site Global Collection for each site.    Then have those Global collections wrapped up into a Single Pane of Glass Global collection.    Unfortunately, you can't put a GC in a GC.   


    The Access to the landscapes isn't only determined by the security strings but ACL's and FW's as the landscape is not local to the site. 

    I am tracking the Proxy model, however I was trying to avoid duplicating the models on multiple landscapes.  

    Spence.




  • 6.  RE: Modeling Across Landscapes

    Posted Dec 13, 2022 02:28 AM
    Hi @Spencer Adams,

    regarding "you can't put a GC in a GC" I assume, you refer to the contents of GCs. It actually is possible to add a model to a GC by using a search criteria like "CollectionsModelnameString contains <name of gc>".
    Using a proper naming scheme for all GCs does help a lot, because it keeps the idea of dynamic membership alive.

    regards,
    Raphael


  • 7.  RE: Modeling Across Landscapes

    Posted Dec 13, 2022 12:41 PM

    Raphael, 

    Thanks for the input.  I actually need to create a Global Collection that has multiple containers from different Landscapes. 

    I would like to take the Global Collection created and add it to another Global Collection. 

    Spence




  • 8.  RE: Modeling Across Landscapes

    Posted Dec 15, 2022 11:51 AM
    Edited by Raphael Franck Dec 16, 2022 04:50 AM
    Hi @Spencer Adams,

    unfortunately, global collections do not have a rollup condition or value when attributes. That means, the global collections themselves do not show an aggregated condition of their child elements.
    Still I still think your requirement should be achievable somehow.
    What actually is meant to do exactly that is the Spectrum Service Manager using Service (container) models. For your use case, I recommend to create one service for each location, possibly containing sub-services or sub resource monitors, one for WAN and one for LAN. Develop and assign a proper service policy. Make sure to test that policy and name all location services according to a well defined scheme. Please note, if there is dynamic required, you can use global collections (their child elements) as service resources. That might be a good idea for the LAN part, as typically there is more devices and hence change as with the WAN routers.
    Assign all relevant services to a name Service customer. Grant access for your leadership to the Spectrum service customer and related services. They then can view the "aggregated" state per location using native OneClick or the Service Dashboard.
    Please note, when using resources from different landscapes, the service must be created on a landscape, that is able to communicate to all relevant landscapes. Typically that would be the MLS. This selection is the first thing you need to do, because you can't change it once having entered any details into the new service model.
    The good thing about Spectrum service manager is, you can fine tune the service policy to define exactly, which faults actually do affect the location service and which don't, in which manner. Also, by that your leadership is not bothered with technical alerts like "FAN FAILURE" or similar while fullfilling the request to provide visibility.

    hope this helps,
    Raphael