Smlt/Rsmlt Operational Improvements - Avaya 8600 Configuration Manual

Link aggregation fundamentals

SMLT/RSMLT operational improvements

The SMLT re-architecture is supported in releases 4.1.8.2, 4.1.8.3, 5.0.1.0+, 5.1.0.0+, and
7.0.0.0+.
For previous SMLT operation, bringing the SMLTs Up/Down triggered the flushing of the entire
MAC/ARP belonging to the SMLTs in both the IST core peer switches. Flushing of the MAC
addresses then causes the dependent ARP to be re-resolved. For ARP resolution, ERS
8800/8600 re-ARPs for all the SMLT learned ARPs. This created a major MAC/ARP re-learning
effort.
As the records are flushed, during the re-learning period the exception (learning) packets will
also be continuously forwarded to the CPU, thereby increasing the CPU load. This will further
slow-down the SMLT re-convergence as well as the hardware record re-programming.
Since the traffic flow is completely dependent on the hardware records, this prior behavior
could adversely affect convergence times, especially in very large networks (8000+ MACs/
ARPs), and those also running with many multicast streams, as multicast streams often need
to be forwarded to CPU for learning, thereby also increasing CPU load. The SMLT changes
improve this operation significantly, and continue to allow all previous SMLT/RSMLT topologies
to be supported.
SMLT Operational Improvements will affect SMLT/RSMLT behavior in that the actual SMLT/
RSMLT connection links on a powered-up IST Core Switch, will take longer to become active
(link status up and forwarding) than with previous versions of code. During this time period the
other Peer IST Core Switch will always be continuing to forward, therefore avoiding any loss
of traffic in the network. The SMLT/RSMLT associated links will not become active upon a boot-
up until the IST is completely up, and a 'sync' has occurred between the two Core IST Peer
Switches.
Users may see occasional instances where the Remote SMLT Flag is False on both Peer
Switches. This is normal, if the flag clears and is then set properly (False on one side, True on
the other), once the FDB age-out for that associated VLAN has occurred.
For proper network "behavior" Avaya recommends to operate both IST switches with either
the "new" or "old" SMLT architecture. Therefore SMLT operation between IST Peer Core
switches with one switch operating with pre-4.1.8.x code, and the other operating with 4.1.8.x
or later code is NOT supported.
Additionally users will see some new informational log messages generated around this
behavior. These messages formats will be seen as below, under the various situations
noted.
Table 1: SMLT informational message examples
When sync fails due to difference in IST Peer
software version (pre-4.1.8.x and 4.1.8.x)
where one peer supports MAC/ARP sync but
40 Configuration — Link Aggregation, MLT, and SMLT
Case
Comments? infodev@avaya.com
Message
CPU5 [05/15/08 05:28:51] MLT
INFO SMLT MAC/ARP Sync
Requested: CAUTION do not take
January 2012