vIST bootstrap deadlock and Fabric Attach assignment not applied
A pair of VSP 7400 distribution switches is being added to an existing Fabric Connect fabric. The pair is connected by a 40 GbE direct link for vIST and has two 100 GbE uplinks to the core, but the uplinks are still shut as part of a staged cutover. Each distribution switch has SMLT links to 22 access switches. The design uses loopbacks 10.255.10.1/32 and 10.255.10.2/32 as vIST peer addresses so that vIST can survive a direct-link failure. On cutover, show vist reports the peer unreachable and the access switches lose their SMLT path. Separately, 30 third-party access switches use Fabric Attach. LLDP shows each FA element, but the expected VLAN 200 is not assigned. Global fa enable and port fa enable are configured on the VSP side, and VLAN 200 exists but is not mapped to an ISID.
1. Diagnose the vIST failure. What is the circular dependency, and what bring-up order or addressing change would you use?
Read the worked answer
The vIST peer addresses are loopbacks, but the uplinks that would advertise those loopbacks into IS-IS are shut. The only potential path between the loopbacks is the direct link, and that link is not yet in IS-IS. vIST needs IP reachability to its peer before it can form; the fabric needs the distribution pair to be up before it can carry the loopback route. That is the deadlock.
Break it in one of two ways. The safer staged method is to bring up one core uplink first, enable IS-IS/SPBM on it, confirm that each loopback is present in the fabric routing table, and then bring up vIST and SMLT. Alternatively, use the direct-link IP addresses for initial vIST formation, then migrate to loopbacks after the fabric path is proven. If vIST over the fabric is required for direct-link failure, verify that the peer route is learned over a redundant fabric path and that the vIST control channel does not depend on the SMLT access links. Do not enable SMLT until show vist is stable and the peer is reachable by the intended source address. Also confirm that the vIST VLAN and peer addresses are not filtered by an IP shortcut or VRF boundary.
2. Why is VLAN 200 not assigned to the Fabric Attach clients, and what checks would you perform?
Read the worked answer
fa enable only turns on Fabric Attach; it does not create an assignment. The FA server must have a mapping or policy that binds the client's element ID and port ID to VLAN 200. Check show fa element and show fa assignment to see whether the element is discovered but unassigned, or assigned to a different VLAN. Confirm that LLDP is passing in both directions and that the client is actually requesting VLAN 200.
Then check the data-plane prerequisites. VLAN 200 exists, but it is not mapped to an ISID. If the VLAN only needs to be local to the distribution pair, FA can assign it locally. If it must reach other fabric nodes, create vlan i-sid 200 <isid> on every edge node that needs it, and confirm the ISID is installed and uses an allowed B-VLAN. Also verify whether the port is an FA server port or an FA proxy port; a proxy changes what element ID the server sees. Finally, check for duplicate element IDs, because a duplicate can cause the server to apply the wrong assignment. Fix the assignment policy first, then the ISID mapping if the VLAN must cross the fabric.
3. What pre-cutover validation would have caught both issues, and what rollback guardrail would you put in place?
Read the worked answer
Pre-cutover validation should run as a scripted gate: confirm underlay MTU on every ISL; confirm IS-IS adjacencies and loopback reachability before vIST; confirm show vist peer state before enabling any SMLT; confirm show fa element and show fa assignment for every FA port; confirm VLAN-to-ISID mappings on both pair members; and test with one canary access switch before the other 21.
The rollback guardrail is to keep the SMLT access links administratively down until the distribution pair passes the gate. If vIST or FA validation fails, restore the previous uplink configuration, leave SMLT down, and keep the access switches on their existing path. Use a configuration snapshot and a documented rollback command set. Do not treat a CLI error during template push as a warning; fail the cutover on the first missing ISID or missing FA assignment, because partial provisioning is harder to diagnose than a clean rollback.