What is the best way to represent an Ethernet switch stack in the CMDB?

[GoBucks]

We do not have Discovery for CMDB population. We have been building out our own integrations via scripted REST APIs.

The following question was asked of me and my co-workers (we are my org's ServiceNow admin/dev team):

"What's the best way to represent an Ethernet switch stack (or a Juniper "virtual chassis" or "virtual chassis fabric") in CMDB?  These are situations where a single logical network device is composed of multiple physical network devices and managed as a single unit. In the Juniper VC and VCF cases the subordinate devices are effectively line cards of the master of the logical device."

Thanks in advance for any guidance.

[AJ-TechTrek]

Hi @GoBucks 

Is the Stacked Switch pattern enabled? Are you using probes or patterns?

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.

Thanks

AJ

Linkedin Profile:- https://www.linkedin.com/in/ajay-kumar-66a91385/

[GoBucks]

@AJ-TechTrekWe do not have Discovery as part of our license.  I assume that is what your question about probes and patterns was referencing.  An internal systems team would be scripting the payloads and pushing them to our teams inbound scripted REST APIs that would then populate the CMDB with this data.

We just aren't sure of how the switch stack, as described in my original post, is to be mapped within the CMDB's class hierarchy and any related supporting tables.  Which classes and related tables exist that are intended to support such a thing?  Are their classes and tables out-of-the-box that we have available that could help represent the switch stack described in the original post's question?

[AJ-TechTrek]

Hi @GoBucks 

Apologies i missed the you dont have discovery License.

Thanks

AJ

[smithraaj]

Representing an Ethernet switch stack, Juniper "virtual chassis," or "virtual chassis fabric" in a Configuration Management Database (CMDB) involves capturing the relationships and dependencies among the logical and physical components. Here are some suggestions on how to model these scenarios in ServiceNow CMDB:

1. Configuration Item (CI) for Master/Logical Device:

   • Create a CI representing the master or logical device, such as the switch stack or Juniper virtual chassis.
   • Include attributes like device name, model, serial number, and other relevant details.

2. Related CIs for Physical Devices:

   • Create individual CIs for each physical device within the stack or virtual chassis.
   • Establish a relationship (e.g., "Member Of") between the physical devices and the master CI.

3. Hierarchical Structure:

   • Use the hierarchical structure in ServiceNow to visually represent the relationship. For instance, configure a "Contains Configuration Item" relationship between the master CI and its subordinate physical devices.

4. Attributes for Stacks:

   • Include attributes specific to the stack or virtual chassis configuration, such as stack ID, member count, and role (master or subordinate).

5. Specialized Relationships for Virtual Chassis:

   • For Juniper virtual chassis, you may need specialized relationships to represent the master-slave relationship and how each device contributes to the overall logical device.

6. Business Services:

   • Link the logical and physical devices to relevant business services to demonstrate the impact on business functionality.

7. Custom Fields for Vendor-Specific Details:

   • Depending on the vendor and the specific details you want to capture, consider adding custom fields to store vendor-specific information.

8. Documentation and Relationships:

   • Attach documentation, such as network diagrams or device manuals, to the CIs to provide a comprehensive view of the configuration.

9. Versioning and Change History:

   • Implement versioning or maintain a change history to track modifications to the configuration over time.

10. Automated Population:

    • If possible, automate the population of CMDB data using your scripted REST APIs to ensure accuracy and consistency.

Remember to consult with your network and infrastructure teams to ensure that the CMDB accurately reflects the real-world relationships and dependencies within your network architecture. Additionally, document your CMDB modeling approach to facilitate understanding and maintenance by your team and future administrators.