Specifications

9032277-03 Software Superseded by CS2/MMS2
5-21
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 from
false to true and then reconfigure. This has been resolved by changing the
default value for Create_Sub_Interfaces to TRUE.
WA_Link monitor points are lost if one of the routers on either side is
rebooted. The problem is that the intelligence which finds and maintains the
monitor point for the container (in this case a WA_Link) has not been designed
to handle the case where all potential monitor points which the container
could use go down, i.e Contact_Status goes LOST. When Contact_Status goes
LOST, the intelligence clears out all monitor point information for the
container and should start watching the CONTACT_STATUS of the currently
selected monitor point. The problem is that the setup of the watch is triggered
by a write to the LAN_SELECT_MP attribute for which we currently only
trigger by changes in the attribute, i.e. a new monitor point is selected. A
situation can arise where the same monitor point is written to the attribute,
thus causing the trigger to not go off. When this happens, we are not watching
any potential monitor point to see when it may regain contact.
CiscoView will not launch since we do not pass the community name
parameter. This has been resolved by adding the community name parameter.
The Performance view of Cisco Rtr HSSI interface is not showing Error_Rate,
Discard_Rate, or Packet_Rate. The problem is that the value that is being
stored into the attribute "Total_Packets" is larger than a 32 bit Integer. So the
overflow on the attribute crashes the calculation which causes a failure to be
displayed in the Serial_IF_Port Performance View. This has been resolved by
changing the attribute "Total_Packets" from an integer to a counter.
Customer has Cisco Routers in their network that are utilizing Un Number
IP. When the customer Runs an ADISC, Model By IP (with discover
connection), or even a discover LAN, WA_Links are not being created on the