Specifications
Patches Issued Since the CS2/MMS2 Release
Software Superseded by CS3/MMS3 Software Release Notice for 5.0rev1
5-106 CS3 and MMS3
During router mapping process (AD_ROUTER_MAP action), we read
each entry from the router's scratchpad and map the interface in the
scratchpad entry. Since FR sub-interfaces were not scratched by their
own IF index(all info was scratched under the FR physical IF), we
don't actually resolve each individual FR sub-interface. When
mapping the FR physical interface, we are actually dealing with the
map of this side DTE to the other side DTE. However, if a FR sub-
interface is "directly" connected to another non-FR interface, the
routing info of the non-FR interface will not be saved into the other
side DTE. So this connection couldn't be resolved during the FR DTE
mapping.
The resolution was to create a scratchpad for each FR sub-interface
which appears in the IP routing table and save the FR sub-interface's
routing info into the both FR physical and sub interface scratchpads.
So the FR DTE's can still be mapped, and the FR sub-interface
scratchpad can also be used to resolve the conductivities if the other
side is not a FR sub-interface.
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.