RSMLT Failover During a VIST Peer Upgrade
Two VSP 8600 switches run as a VIST pair and provide SMLT connections to 20 top-of-rack switches. The pair also provides RSMLT Layer 3 gateways for 40 VLANs. The VIST peer link is a single 10G port on each switch, not a LAG, and it carries the VIST peer VLAN. During an in-service software upgrade of peer A, the peer link resets. The VIST adjacency drops, and SMLT ports on the surviving peer B go down for about two minutes. Servers lose their default gateway until A returns and VIST re-forms. Afterward, show virtual-ist is healthy, show smlt shows all ports up, and show ip rsmlt shows normal hold-up values. The business cannot accept a two-minute outage for the next upgrade and asks whether the design or the upgrade procedure should change.
1. Why did a VIST peer-link reset take down SMLT ports on the surviving peer, and why is that behavior desirable?
Read the worked answer
VIST/IST is the coordination channel for SMLT. If the two peers lose peer connectivity, each cannot know whether the other is still forwarding. To prevent a dual-active SMLT loop, VOSS disables or stands down SMLT ports when the IST/VIST adjacency is down. That is why the surviving peer's SMLT ports dropped for roughly two minutes: the single peer link reset during the upgrade, the VIST adjacency failed, and SMLT went down even though the ToR links were physically up. The behavior is desirable because dual-active SMLT would create a loop and MAC instability. The lesson is that the peer link is a critical HA path, not an optional management link.
2. What design changes and pre-upgrade checks would you require before upgrading peer A again?
Read the worked answer
Make the VIST peer path redundant, ideally a LAG of at least two links on dedicated ports, and carry the VIST peer VLAN only on that path. Before the next upgrade, verify show virtual-ist, show ist, show smlt, and show ip rsmlt are healthy; confirm the peer IP is reachable over the direct Layer 2 path, not through the fabric; check that SMLT ports are dual-homed and that LACP is stable. Review RSMLT hold-up so the remaining peer keeps forwarding the failed gateway long enough, but not so long that it blackholes. Enable graceful-restart/NSF features supported by the release, and upgrade one peer at a time with a rollback plan. Test in a lab with a peer-link pull before repeating in production.
3. Would VRRP or DVR be a better fit than RSMLT here? Discuss the trade-offs.
Read the worked answer
RSMLT is a good fit when you want active-active Layer 3 with SMLT and no VRRP master/backup. VRRP is simpler and more familiar, but only one peer forwards for the virtual IP at a time, and failover depends on VRRP timers; it also adds a virtual MAC. DVR (Distributed Virtual Routing) with VIST can provide an anycast gateway and avoid some RSMLT hold-up behavior, but it has its own design and platform requirements. For this environment, first fix the peer-link redundancy; then decide whether RSMLT's active-active behavior is worth keeping. If the requirement is fast, deterministic failover with minimal Layer 3 state, DVR may be better; if simplicity and multi-vendor familiarity matter, VRRP may be preferred. Do not change the Layer 3 model to compensate for a bad peer-link design.