1 2 Previous Next 29 Replies Latest reply on Oct 21, 2019 9:27 AM by Stefan Hall

    Switch Stack Represented in Atrium

    Louis Troise
      Share This:

      Hello All,


      The March TKU made some more minor updates to the switch stack device representation and this is leading to questions from the config mgmt community here....


      The logical entity "Switch Stack" shares its serial number with a device in the stack (I think normally the stack master device).  This creates a situation in CMDB where two "network devices" have the same serial number.  There does not appear to be any specifically-defined attribute in CMDB sync out of the box to differentiate the Switch Stack from the Stack Device that shares a serial #.  I would have hoped that the two devices might have been sync'd with a different primary capability, or CTI, or ????


      I'm thinking of making an update or two to the CMDB sync TPL for network devices so to more easily query Atrium for these devices individually.  Also trying not to extend the CDM to include in the sync a Discovery attribute like "Stack" or "Stack Master".  Possibly put a suffix on the serial number or the Short Description of the Switch Stack.  Part of the challenge here is to reconcile Discovery data to other data sources, and the way "Switch Stack" and "Device in Stack" are represented in Atrium currently seem a little too similar to each other for reliable recon rules.  Thoughts and experiences from y'all?





        • 1. Re: Switch Stack Represented in Atrium
          Stefan Hall

          I have exactly the same massive problems in the cmdb, just didn't have time to write anything yet. Thanks for your input.


          In fact, the logical "cluster" device should not have a serial number. This does not only make identifying in the Recon difficult. It also massively changes the relationships when you create/separate a stack. All relationships must be reassigned to the real device. Then, if necessary, back to the stack master etc.


          Let's get to the relationships to the logical device. From my point of view a very bad cmdb implementation/integration. An example: If a stack member fails, there is no possibility at all to simulate the effects.  No server/printer or whatever is attached to the stack member. Therefore It seems all is Fine. The whole stack don‘t work as  a cluster, it's hardware with hardware connections (cables and connectors). If a stack member is defective, the connected devices are offline. The current cmdb sync does not reflect this in any way.


          For me a design error, which hopefully we can fix without an long running idea

          1 of 1 people found this helpful
          • 2. Re: Switch Stack Represented in Atrium
            Justin Sanford

            We see the same issue with these Stacked Switches and are actually filtering these from the CMDB sync until we have pattern changes to resolve the serial duplication and ambiguous naming of the stack members. Our plan is to create custom patterns to append the serial of the logical "Stack Master" to avoid duplication and rename the stack members per our config management policy for these Network devices.


            A change I also see in the latest TKU is that the devices that are stand-alone, but stackable are not coming in as the same model as they would if they were a device in the stack. Also, I am not sure how the naming and relationships are handled if we decide to stack this device and make it the stack master. This seems like an oversight as well. Seems like there could be some CI duplication in CMDB.


            BMC, if you are watching, please let us know if there are plans to deal with this stack switch situation.

            1 of 1 people found this helpful
            • 3. Re: Switch Stack Represented in Atrium
              Andrew Waters

              If you want something addressed raise a customer case with details information and example record data.

              1 of 1 people found this helpful
              • 4. Re: Switch Stack Represented in Atrium
                Stefan Hall

                Hi Andrew Waters

                Are you serious? It costs me hours and days until such a ticket reaches the right expert.

                I think it's better to discuss this with the right experts until the mistake is clear. This is not only faster, it relieves in this case the unsuspecting 1st level support. This is about the cmdb Sync Design and not about a banal error.


                Let's discuss it here, what do you think? I think custom pattern is the wrong way.


                Here are the important points

                1. Sync logical stacked devices without serial number. Serial numbers only for real devices
                2. Sync real devices with real model namens, maybe with (Stack member) hint behind model name
                3. Sync logical stacked device NOT with real model name. It has to be different from member model names. In case of possible different real devices with xx for model grouping.
                4. Sync relationships between real devices, not to the logical device.
                5. Sync logical stacked devices without OperatingSystem otherwise you have more OS than real devices. Besides, it doesn't get any easier in the CMDB - it's a logical element!


                Without 1-3, 5 It is nearly impossible to normalize these devices against product catalog or identify devices with model name and serial number.


                Without 4 you can‘t use the impact simulation. The logical stacked device don‘t act like a server cluster. A hardware defect has an direct impact. Currently a defect device has no impact.


                Are you ready and who are the other DISCO stacked devices experts?




                edit 04/17 - added point 5

                2 of 2 people found this helpful
                • 5. Re: Switch Stack Represented in Atrium
                  David Mejia

                  I have the same exact issue in my environment and it is very frustrating to say the least. Unfortunately, I don't believe that this is as much a BMC problem as it is a CISCO problem. I was trying to figure out a way to address this issue myself and while digging into CISCO documentation it specifically states in there that the logical switch takes the serial number of the master member.


                  We did notice that all of the physical devices in a stack have a partition ID set with a string that contains:


                  StackMember + device description + Device Serial number


                  In order to get around this issue we implemented a recon job with a single Identify action for BMC_ComputerSystem class which runs before ADDM dataset is identified with the Qualification set:


                  'PartitionId != $NULL$ AND 'PartitionId' LIKE "StackMember%"


                  So far we are receiving the desired results.

                  2 of 2 people found this helpful
                  • 6. Re: Switch Stack Represented in Atrium
                    Louis Troise

                    Thank you, this is all very educational.


                    I can also see that the device.partition_id attribute of physical members of the stack has data represented as David indicates.  The data looks cleaner in BMC_ComputerSystem in Atrium.


                    David - What is the outcome of your additional identification job running with that PartitionId qualification?  Is the goal to prevent the logical device ascending to higher-level datasets, and only passing the physical stack members?


                    Also, given the (new to me) information about how devices behave in impact modeling in the real world, do you guys think the design decision to relate all IP Addresses to the logical stack entity is correct?  I've been wondering if those should be related to the individual devices instead.


                    FYI I do have the ears of BMC on this as well, and am waiting to hear if there are any further enhancements planned for this pattern because, though it has been an evolving feature it still seems to me to be incomplete.

                    • 7. Re: Switch Stack Represented in Atrium
                      David Mejia

                      Louis, with this setup we also have an intermediate dataset where the data is being merged prior to going into BMC asset. The goal here is to have the physical hardware identified when the comparison of BMC Asset and ADDM is completed and the Logical Switch generate an id when the comparison of ADDM and Pre-Prod Dataset is complete.


                      We still need the logical device to come through into BMC.ASSET becuase that logical device "is" the switch being modeled.I just wish that it didnt take the serial number of the master member.

                      1 of 1 people found this helpful
                      • 8. Re: Switch Stack Represented in Atrium
                        Stefan Hall

                        Hi David Mejia, Louis Troise,

                        what an effort to compensate for what the CMDB Sync can't currently do.


                        Let's try to get BMC to make an adjustment together. At the moment it's just not good. Tonight I'm going to turn the most important aspects of this thread into an idea. Even if I don't think much of these ideas, they take much too long even with recognizable design errors, I don't see any other possibility. The BMC experts are very reserved here.


                        Maybe it's also a bit of a area problem, from the addm developer's point of view everything is fine and the CMDB is only marginally interested. There are also products synced that you can't create in cmdb like this. Known as „works as designed“ and nothing happens

                        • 9. Re: Switch Stack Represented in Atrium
                          Andrew Waters

                          The current stacked device model what you are calling the logical device has a stack attribute set. This should make it fairly simple to write a syncmapping extension for the NetworkDevice where stack and the do any overriding of attributes.

                          • 10. Re: Switch Stack Represented in Atrium
                            Stefan Hall

                            Hi Andrew, of course we can customize everything, but why is there no real interest in an official bug fix or let's call it result-oriented development.

                            It would be nice if you could briefly discuss my 5 problematic things. Then I can decide if it's a bug, a design bug, or just a thoughtless implementation.

                            The sync is only good if the CMDB can usefully use/process this OOB. This is not the case here.

                            • 11. Re: Switch Stack Represented in Atrium
                              Duncan Grisby

                              It is a bug. We are working on it.

                              3 of 3 people found this helpful
                              • 12. Re: Switch Stack Represented in Atrium
                                Stefan Hall


                                which one of the five points do you mean? I hope all.

                                • 13. Re: Switch Stack Represented in Atrium
                                  Jean Louis Deshairs

                                  Thanks All for your inputs. Stefan I just sent you a direct message. I would like to discuss about this further with you please if possible. Thank you. JL

                                  • 14. Re: Switch Stack Represented in Atrium
                                    Louis Troise

                                    Hello Again.


                                    Thanks for the continued input on this topic!  I did have a webex with BMC late last week to demo the situation and discuss what plans are in the hopper.  It does appear that a step toward resolving this matter will be in a TKU coming up.  The likely implementation is that the serial number of the logical device will get a suffix put on it so to distinguish it from the real devices.  I know this doesn't exactly address Stefan Hall 's points but it's a decent stop-gap to get recon working as it should, and probably what any of us would write in the mapping TPL for a short-term workaround.


                                    Also of note is that the switch stack modeling approach isn't the only one that creates duplicate serial numbers.  We see this in Nexus VDC and some load balancers too.


                                    I am particularly interested in "4. Sync relationships between real devices, not to the logical device."  The logical device owns all the IP Address relationships which prevents the use of yet another data point when recon'ing the real devices w/other sources.

                                    2 of 2 people found this helpful
                                    1 2 Previous Next