Sizing a Multi-Tenant SPB Fabric Without Exhausting VLANs
A service provider is building a data center fabric for 1,200 tenant Layer 2 segments across two VSP 8600 core switches and 16 VSP 7400 leaf switches. Each tenant currently gets one 802.1Q VLAN on the access side and a matching VLAN on the firewall trunk. The design team proposes a single SPB B-VLAN 4000 and one I-SID per tenant, with the I-SID number equal to the VLAN ID (100-1300). The firewall team insists on a single 802.1Q trunk carrying all tenant VLANs into the core. The operations team is worried about the 4,000 VLAN limit and asks whether SPB removes it. A junior engineer wants to use one B-VLAN per tenant to 'keep traffic separate' and to use VLAN 1 as the B-VLAN because it is already allowed on all trunks. The project must support future growth to 3,500 tenants without redesigning the core.
1. Evaluate the proposed one-B-VLAN/one-I-SID-per-tenant design. Does SPB remove the 4,000-VLAN ceiling, and what is the actual constraint at the firewall trunk and at each BEB?
Read the worked answer
Separate the three identifiers. The access VLAN is a local 12-bit binding on a BEB; the I-SID is a 24-bit service identifier carried in the SPB data plane; the B-VLAN is the shared transport VLAN on the IS-IS/SPB core links. Tenant isolation comes from the I-SID, not from a per-tenant B-VLAN. One B-VLAN (4000) is therefore normal and scale-efficient; one B-VLAN per tenant would multiply core state and is not a security boundary. SPB does not abolish the 4,000 local VLAN limit: each BEB still maps VLAN to I-SID, and the firewall trunk still needs a VLAN per tenant on that trunk. At 3,500 tenants you are inside 4,096, but the headroom is thin; plan multiple firewall trunks or a routed handoff, and reuse local VLAN IDs on different BEBs rather than assuming the I-SID space removes the limit. VLAN 1 is a poor B-VLAN because it is the default/untagged VLAN and often carries control traffic; use a dedicated, pruned B-VLAN.
2. What naming and addressing rules would you enforce for nicknames, system IDs, and IS-IS areas, and what would you verify in `show isis spbm` before adding tenant 1,201?
Read the worked answer
Enforce a documented, unique system-id per BEB, a unique 20-bit nickname per BEB, and a consistent IS-IS area/manual area on every fabric node; duplicates cause adjacency or path problems that are hard to diagnose. The B-VLAN must be allowed, tagged, on every core IS-IS interface. Before tenant 1,201, verify show isis spbm lists all expected nicknames, show isis adj shows full adjacencies, show isis interface shows the B-VLAN interface up, and show vlan shows the B-VLAN members on core ports. Confirm the new VLAN and I-SID are only on the intended BEBs, and that the nickname plan has no duplicate. Also check MTU 9000 end to end, because SPB encapsulation adds overhead and a 1500-byte core path will pass small pings but fail tenant traffic.
3. A tenant asks to stretch VLAN 500 between this data center and a second site over an IP WAN. What changes to the fabric design, and what is the role of Fabric Extend?
Read the worked answer
Fabric Extend transports SPB over an IP path between BEBs; it does not simply stretch a VLAN. You need a BEB at each site, a local VLAN-to-I-SID mapping for VLAN 500 at both ends, IP reachability between the Fabric Extend endpoints, and enough MTU on the WAN. SPB encapsulation adds header bytes, so a 1500-byte WAN link can break large frames even though pings succeed. The B-VLAN remains local to each site; the I-SID is the end-to-end service. Use IPsec if the WAN is untrusted, and verify tunnel status, end-to-end MAC learning, and large-packet ping. If the WAN is lossy or high-latency, consider a Layer 3 handoff instead of stretching Layer 2, because a single I-SID failure domain across sites can be operationally expensive.