Specifications

9032277-04 Software Superseded by CS3/MMS3
5-57
Patches Issued Since the CS2/MMS2 Release
Cases to be considered:
(1) One side is a FR sub-interface; other side is not and has not been
modeled yet.
Skip resolving the FR sub-interface. Only do the normal FR DTE map
on the FR physical interface. We may also place a LAN/WA_Link off
the FR sub-interface. Also, if one side is a FR subinterface and other
side has not been modeled yet, don't place LAN model off the FR
subinterface
(2) One side is a FR sub-interface; other side is not and has already
been modeled.
We will treat the FR sub-interface as ordinary IF and use the
scratchpad to resolve the connection. We'll also do the normal FR DTE
mapping on the FR physical interface. The FR sub-IF's routing info
saved in the physical IF sratchpad will not be reused for the DTE
mapping.
(3) One side is not a FR sub-interface; other side is FR sub-interface
but not modeled.
The get_interface_network_mtype() will return LAN mtype for FR
subinterface. But the FR subinterface won't be resolved until other
side was modeled and is a non-FR subinterface.
(4) One side is not a FR sub-interface; but other side is FR sub-
interface and has already been modeled.
Using other side FR sub-IF scratchpad to do the normal mapping.
--
The problem was SpectroSERVER's ability to map traps to certain
types of objects was broken. A change had been made to the way the
trap mapping is done which require that SNMP communications be
established with a device before that device is registered to receive
traps in Spectrum.
The resolution was to Put the intelligence back into Spectrum to map
traps to devices based on their Agent ID attribute, as well as their IP
List attribute.
--