Specifications

9032277-04 Software Superseded by CS3/MMS3
5-25
Patches Issued After the CS1/MMS1 Release
The Interface Description Map on the HubCat models cannot be
resized. This has been resolved by increasing the size of the GIB when
it is displayed.
The values in SW_Link performance view all say "failed." The
performance view for the monitor point, which is an ATMIfPort, has
values of "failed" as well. The attributes being used for those fields --
InLoad, OutLoad, InCellRate, OutCellRate, and ErrorCellRate, are all
red-boxed in the attribute browser. Since the SW_Link can use
different types of models as its monitor point, an additional string
field was added to the inference handler to send along with the action.
The port that picks up the action will compare with the string to find
what attribute it needs to read, and then will supply the attribute ID
for the correct corresponding attributes (i.e. if it is an ATMIfPort, and
it receives the string "In_Load" it will read its appropriate In_Load
statistic, whose ID will be supplied by its own IH). This is necessary
because the SW_Link code has SwitchApp statistics hard-coded, and
obviously you can't read the SwitchApp model’s statistics on an
ATMIfPort.
When modeling a cisco router with ISDN interfaces, the interfaces are
constantly going up and down. This is resulting in the device sending
a trap for each occurrence. When the trap is received, SPECTRUM
generates a red alarm for each port that goes down. For the ISDN
interfaces this is a normal state and the ports should not show an
alarm status. The inference handler that is managing the incoming
trap has been changed to create just an event, in addition to the all or
nothing option now available. To do this another attribute
(AlarmOnLinkDnTrap) has been introduced. This attribute allows or
disallows the alarm being created after the event is created. The
default state of an ISDN interface, either modeled as a Serial_IF_Port
or as a new ISDN port, is that events are logged on port linkUp and
linkDown but alarms are not generated.
The Cisco Route Switch Module, RSM, is a board that installs into a
Catalyst hub. It has no ports out of its front panel and the only
connection which it has to the backplane is a virtual connection. This
board is modeled separately with the Rtr_Cisco MM. After modeling
an RSM and navigating to the DevTop view the only thing that is
displayed is the Rtr_Cisco icon in the upper right hand corner. What is
expected is a cable walk as well. By default in version 5.0rev1, create
sub-interfaces are set to false. For the cable walk to appear in the
DevTop view you must change the "Create Sub-Interfaces?" selection