Specifications

Patches Issued Since the CS2/MMS2 Release
Software Superseded by CS3/MMS3 Software Release Notice for 5.0rev1
5-90 CS3 and MMS3
set of ifType ports throughout the enterprise, these traps are simply
the result of a transient remote connection, which is being deliberately
disconnected by the remote user. Alarm generation is unwanted in
these cases, and currently imposes a real burden on the alarm
management process.
The AlarmOnLinkDownTrap attribute introduced in a recent patch
allows the suppression of the alarm due to event 0x220002 on port
models which have that attribute value set to 'Never'. The second
problem is that setting this value at all port models is labor intensive,
and would require maintenance after device reconfiguration, or
creation of new router models.
The resolution is to introduce a second attribute at data_relay_prt
which is a list of ifTypes specified by the customer through the MTE.
Any model, of that model type, which has an ifType value in this list of
ifType values, will have its AlarmOnLinkDownTrap attribute value
set to 'Never'. The default value will be empty. The customer will then
evaluate the set of ifType values for each specific model type of
interest, and update the new 'NeverAlarmOnLinkDownIfTypes' list
attribute at that model type. Upon the next activation of a port model,
the update to AlarmOnLinkDownTrap will occur. Subsequent
occurrences of the 0x220002 event will be handled accordingly.
--
The problem is that when a remote VLAN server is modeled on an NT
SPECTRUM system with 5.0.1/CS1/MMS1 the user will lose almost
all SPECTRUM view function. Application such SpectroGRAPH,
AlarmView and Events are usable until the VNM reaches 100%
activity. After that, nothing can be opened. If a SpectroGRAPH
connection is already established, the user manipulate the database.
Once the original SpectroGRAPH is shut down another one cannot be
opened. Applications such as SpectroGRAPH, AlarmView, and Events
will report the error "There is no server listening on port 0xbeef" or
"Failed to connect to server <machine_name>. Location on spec158
failed to connect, not listening on port 0xbeef".
The resolution is to correct the byte ordering issue that is being
caused by this circumstance. The remote host port number is never
being translated from network order to host order.
--