We recently started deploying RSMLT in place of VRRP and have run into very few problems. With that said there is one option that is disabled by default that is a must for anyone running in an RSMLT configuration. Since the peer IP addresses are learned dynamically a problem can occur if both ERS 8600 switches go down but only one of them returns to service. In my environment we’ve been using .1 and .2 for our ERS8600 interfaces with DHCP serving up .1 as the default gateway. If the .1 ERS8600 never recovers the .2 ERS8600 will never be able to learn the IP peer interface and hence will not be able to answer requests for .1 from the DHCP clients.
I would advise anyone using RSMLT to enable rsmlt-edge-support with the following command; config ip rsmlt rsmlt-edge-support enable. You will need to be running software release 4.1.4 or later.
RSMLT implementation does not use a Virtual IP address but instead uses Physical IP addresses for redundancy. At the same time, RSMLT can be deployed in either L3/routed configurations, or L2/edge configurations, where previously one might have used VRRP (and back-up master). Now previously, if there was a power outage or shutdown of both switches within a Dual Core IST pair and for some reason only one switch came back-up, clients using the powered-off switch’s IP/MAC as their default gateway would lose connectivity to the network. In such a scenario, even through RSMLT is enabled on the switch it was unable to backup for the Peer as it was unaware of the Peer’s IP/MAC address. With this new feature, the RSMLT Peer’s IP and MAC addresses are stored in the config file and will be used upon next reboot, if the IST link does not become active and operational. Otherwise, the switches will learn from their Peer as normal; see below for additional information.
This feature can be enabled/disabled by the following CLI command:
config ip rsmlt rsmlt-edge-support <enable/disable>
When the configuration file is saved, if the rsmlt-edge-support flag is enabled and RSMLT peer is UP, the peer IP address and MAC address is also automatically saved.
The peer information is cleared by the following CLI command.
config ip rsmlt clear-rsmlt-peer [<vlanId>]
NOTE: if the peer information is cleared the switch could stop forwarding for the peer.
After both the Dual Core IST switches have come back-up, and if the IST comes up and is operational, if a RSMLT Peer enabled message is received from the peer, then normal RSMLT operation is followed. If the peer has either an IP or MAC change, then a new save config must be performed in order for the new information to be saved, and RSMLT L2 Edge support to operate correctly. However, if the IST Peer up message is not received (for example RSMLT is not enabled properly) and the rsmltedge- forward flag is enabled, then first the RSMLT Hold down timer is started to allow routing protocols to converge; during this time user operation could be affected. Once the hold down timer expires, saved peer information is picked up and Switch starts to backup for the Peer by adding the previously saved MAC and ARP records. The Holdup timer is then started and once this timer expires the previously added MAC and ARP records are deleted and the switch stops backing up for the Peer, as the Peer is not running proper RSMLT for the VLAN. It should be noted that RSMLT is a per VLAN parameter, and therefore all affects are on a per VLAN basis, not necessarily per switch. In L2 Edge support mode the Local values of the HoldDown timer (default value of 60 seconds) and HoldUp timer (default value of 180 seconds) will be used.
Cheers!