Specifications

9032277-03 Software Superseded by CS2/MMS2
5-17
The reason is because of spanning tree. There are two scenarios that exist that
determine how spanning tree is implemented across the backplane.
1. The root bridge is one of the boards inside the chassis. Spanning tree
sends BPDU's from the switches to the root bridge. If the root bridge
resides inside the chassis, then the BPDU's travel from the other boards
across the backplane to the root bridge and back. The root bridge knows
about all the other boards in the chassis and all the other boards in the
chassis know about the root bridge. However, BPDU's are not passed
between the other boards. Since BPDU's are not passed between these
boards, they "do not know about each other" and their bridge tables are
not compared.
The modeling in this scenario results in all the boards showing a
connection to the root bridge in a star.
2. The root bridge resides outside the chassis. Another bridge/switch is
connected via the front panel to a board in the chassis. The BPDU's are
sent across the backplane from the other boards in the chassis out to the
root bridge through the board which is connected to the root bridge via the
front panel. The front panel board knows about all the other boards in the
chassis because it records the source mac from the BPDU's sent through it
across the backplane. However, none of the other boards know about each
other.
The modeling in this scenario is erratic at best.
The solution is to write a new inference handler and attach it to the SS6000
module. It will be responsible for gathering the MAC addresses heard off the
SS6000 module's interfaces, as well as the MAC addresses of the modules
connected to it via its backplane interfaces. The model state algorithm will
also be modified so that a SS6000 module will only go active after it's properly
associated with a chassis. However, if a chassis cannot be determined within 2
minutes, then the model state will be forced active, and a yellow alarm will be
generated to alert the user. In order for all this to work, all modules that
reside in the chassis must be modeled, and their model states must all be
ACTIVE, before the GET_ADDRESS_LIST action is sent by Adisc. This will
be the case if all the SS6000 modules reside in a single subnet. However, if
they don't, then Adisc may have to be run a second time in order for the
SS6000 modules to have access to their neighbor's MAC addresses.
NOTE: Connections will only be established between modules if the
module's backplane interface has a MIB II ifOperStatus of up, and a
dot1dStpPortState status of learning, forwarding or listening.
NOTE: If the customer has done manual modeling and placed S6000
boards from the same chassis into different IPClass, LAN or Network
containers then the modeling will still be unpredictable.
The problem is that the serial number for SS 2200's cannot be read from the
GIB views. The resolution is to attach an inference handler that copies the
serial number from the device to the internal serial number attribute to the
hub model.