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.

[GoBucks]

@smithraajThanks for your reply.  This is helpful information.  Given what was described in my initial question, are there out-of-the-box tables that support a switch stack as I originally described?  If so, what are these classes and supporting tables that could represent this?  This is what we are not sure about.  We have already looked over the CMDB heirarchy of classes in our instance.  I know that there are also related supporting tables as well, but less familiar with all of these.

[Ashok Sasidhara · Accepted solution]

IP switch (cmdb_ci_ip_switch) might the most suitable OOB class. There is a checkbox field called 'Stack' and free-text field named 'Stack Mode' in that class. 

I would suggest to gather detailed information about the types of devices to be captured, attributes to be populated and relationships to be defined. That will enable in better identification of CI classes to be used and the CI relationships to be configured. If there is a huge volume of data, it is recommended to automate by enabling discovery or 3rd party integrations. 

[GoBucks]

@Ashok SasidharaThanks for the information. After some additional discussion with co-workers they also identified the IP Switch class.  It came down to deciding on the relationship type to use for the parent/child switches.