Nokia VPLS study materials
Nokia VPLS study resources

MC-LAG access failover succeeds but VPLS traffic blackholes

Nokia VPLS · Put your knowledge to work in context.

All case studies

MC-LAG access failover succeeds but VPLS traffic blackholes

VPLS 400 is deployed on four PEs. A customer CE is dual-homed using MC-LAG to PE1 and PE2; PE1 is active and PE2 standby for the VPLS SAP. PE3 and PE4 each have a mesh SDP to PE1 and PE2 and no direct access to the CE. At 02:14, PE1’s access link to the CE fails. MC-LAG moves the CE to PE2 in about 120 ms, and PE2’s SAP becomes active. Nevertheless, the customer reports a 45-second outage. PE3 and PE4 still have the CE’s MAC address pointing to PE1; PE1 has no active SAP and drops the frames. The outage clears only after the CE sends a broadcast that is flooded and relearned. FDB aging is 300 seconds. The design has no VPLS endpoint or SDP redundancy; each PE has one mesh SDP to every other PE. The customer wants sub-second recovery and no reliance on broadcast timing.

1. Explain why the MC-LAG switchover did not produce end-to-end sub-second recovery.

Read the worked answer

MC-LAG only makes the CE access redundant; it does not update the remote PEs’ VPLS FDB. After PE1’s access link fails, PE2 becomes active, but PE3 and PE4 still have the CE MAC pointing to PE1. PE1 has no active SAP, so it drops the frames. Recovery waits for the CE broadcast to be flooded and relearned, which explains the 45-second outage. The 120 ms MC-LAG switch is real, but it is not the end-to-end recovery time. The root cause is stale MAC state on the remote PEs, not a slow access switchover.

2. What change would you make to achieve sub-second recovery, and how would you verify it?

Read the worked answer

The missing piece is a MAC flush from the MC-LAG domain toward the VPLS peers when the active SAP changes, so PE3 and PE4 delete the old MAC and relearn via PE2. Enable MAC flush on the MC-LAG/VPLS SAP binding where supported and verify with show service id 400 fdb and show service id 400 sap. Also check that PE1 and PE2 have a working peer link; without it, MC-LAG may not signal or switch correctly. Shortening FDB aging is a weak workaround, not a fix, because it still leaves a window of stale forwarding. Test by failing the access link and measuring traffic loss with a continuous ping.

3. How do MC-LAG and a VPLS endpoint with redundant spoke-SDPs complement each other in this design?

Read the worked answer

MC-LAG and a VPLS endpoint solve different failures. MC-LAG protects the CE-to-PE access, while a VPLS endpoint with active/standby spoke-SDPs protects the PE-to-core path. The current design has no SDP redundancy, so a core pseudowire failure would also blackhole traffic. For sub-second recovery, combine MC-LAG with MAC flush and consider endpoint-protected spoke-SDPs toward the core. Test the access link and the core SDP separately; measure traffic loss with a continuous ping and check FDB entry movement. Do not assume one mechanism covers the other.