SMLT VLAN extension between VOSS and ExtremeXOS
Two VSP 7400 switches at a data center run VOSS in an SMLT pair. They connect to an ExtremeXOS 5520 core with a two-port LACP bundle. VLAN 100 for server management works. A new VLAN 240 for backup traffic was created on both VSPs and on the XOS core; the VSP access ports for the backup nodes were added, and the XOS core shows VLAN 240 up on only one member of the LACP bundle. The VSP team says IS-IS and the IST are up, and show smlt shows SMLT ID 100 operational. The new VLAN was added to physical ports 1/1 and 2/1 but not to the SMLT VLAN membership. Backup jobs fail intermittently, and MAC address flapping is logged on the core. No changes were made to MTU. The change window is 45 minutes.
1. Explain the most likely cause of the intermittent backup failure and MAC flapping. What is the role of SMLT versus IST here?
Read the worked answer
The key clue is that VLAN 240 was added to physical ports but not to the SMLT VLAN membership. SMLT is the logical multi-switch aggregation that makes the VSP pair look like one switch to the XOS core. If VLAN 240 is not associated with the SMLT, the two VSP peers can treat the VLAN differently across the LACP bundle. One peer may forward on its local port while the other floods or learns the same MAC over the IST, producing duplicate MAC learning and the flapping seen on the core. Backup traffic then takes an inconsistent path and fails intermittently.
The IST is the inter-switch trunk between the VSP peers. It carries control traffic and orphan traffic, but it is not a substitute for correct SMLT VLAN membership. IS-IS being up proves the fabric control plane is healthy; it does not prove that VLAN 240 is properly attached to the SMLT service.
The 45-minute window is enough to fix membership, but not to redesign the bundle, so the change should be narrow.
2. List the checks and commands you would run in the window, and the fix sequence.
Read the worked answer
Start read-only, then change one thing at a time.
- Capture baseline: Check
show vlanon both VSPs,show smltfor SMLT ID 100,show isis adjacencies,show lacpon the XOS core, and the MAC table for duplicate or flapping entries. Confirm that VLAN 240 exists on both VSPs and on the XOS core. - Confirm membership: Verify which VLANs are associated with the SMLT and which ports are members. Look specifically for VLAN 240 missing from the SMLT VLAN list on one or both peers.
- Fix membership: Add VLAN 240 to the SMLT VLAN membership on both VSP peers, using the VOSS SMLT VLAN configuration path. Do not add it only to physical ports. Ensure the XOS LACP bundle allows VLAN 240.
- Clear and observe: Clear the affected MAC entries if needed, then watch
show smlt,show vlan, and the core MAC table for flapping. Do not change MTU or IS-IS during the same window. - Rollback: If flapping increases, remove VLAN 240 from the SMLT on both peers and restore the prior membership.
3. What would you verify after the fix before declaring success?
Read the worked answer
Verify service behavior, not just that the VLAN is up.
Confirm that both members of the XOS LACP bundle carry VLAN 240 and that traffic uses both paths. Check that MAC flapping has stopped and that the VSP pair shows consistent SMLT membership for VLAN 240. Run a backup job or a controlled large transfer and verify throughput and path stability. Test resilience by disabling one SMLT link during a low-risk period and confirming that the backup traffic continues without MAC flaps. Recheck IS-IS adjacency and IST health to ensure the fix did not disturb the control plane.
Finally, document the intended SMLT VLAN membership and add a pre-change check so future VLANs cannot be added only to physical ports.