I-SID 20000 Works on One BEB but Not the Other
Two VSP 7400 BEBs, A and B, connect through two SPB core switches. VLAN 200 carries a test host on each side: 10.1.200.10/24 on A and 10.1.200.20/24 on B. I-SID 20000 is intended to provide the Layer 2 service. show isis spbm on A shows all expected nicknames, and IS-IS adjacencies are up. However, show i-sid 20000 on A shows the local I-SID with VLAN 200, while on B it shows I-SID 20000 bound to VLAN 201. The B access port is correctly configured as VLAN 200, and the host on B can ping its local gateway. Hosts on A and B cannot ping each other, but other tenant I-SIDs work. The engineer who built B copied an old template and changed the I-SID but not the VLAN number.
1. Given both BEBs show I-SID 20000 locally but hosts cannot communicate, what are the candidate faults and what would you check first?
Read the worked answer
Start with the service binding, not the IS-IS adjacency, because the topology is clearly up. Compare show i-sid 20000 on both BEBs: it should show the same I-SID and the correct local VLAN on each side, plus remote participation. Then check show vlan 200 on both for access-port membership, and show isis spbm for the expected nicknames. If B shows I-SID 20000 bound to VLAN 201 while the host is in VLAN 200, the control plane is healthy but the data plane has no binding for the host's VLAN. Other candidate causes are a missing I-SID on one BEB, a B-VLAN mismatch on the core IS-IS interface, or an MTU problem; those usually show up in show isis interface or in large-packet failures.
2. Explain why a local VLAN mapping error can leave IS-IS adjacencies and other I-SIDs healthy while breaking only this service.
Read the worked answer
IS-IS and SPB use the B-VLAN and system-ID/nickname information to build the topology; that control plane is independent of any one tenant's VLAN-to-I-SID binding. If B-VLAN 4000 is healthy, all BEBs still see each other and other I-SIDs work. I-SID 20000 is the service identifier that maps a local VLAN into the SPB data plane. On B, VLAN 200 frames are not mapped to 20000 because the binding points at VLAN 201; so B never encapsulates the host's frames with the right I-SID, and A never learns the MAC over that service. The symptom is isolated to one service while IS-IS remains up. That is why you check the I-SID binding before chasing adjacencies.
3. What validation and automation guardrails would prevent this on the next tenant turn-up?
Read the worked answer
Use a turn-up template where VLAN and I-SID are paired variables, not free-text CLI. Pre-checks: confirm the VLAN exists on both BEBs, the access ports are members, the I-SID is not already used, and the B-VLAN is up. Post-checks: show i-sid <id> on both BEBs shows the same VLAN binding; show vlan <id> shows the expected ports; show isis spbm shows all nicknames; then ping and check MAC learning. Add a peer review or automation gate that fails the change if the two BEBs disagree. Record the intended service in a source of truth so a later engineer can compare. This catches the VLAN 201 typo before the customer sees it.