New SAP creates a broadcast storm and FDB pressure
VPLS 500 has three SAPs and two mesh SDPs. It is configured with fdb-table-size 8000, MAC learning enabled, and no STP. At 09:05 a technician adds SAP 1/3/1:500 in untagged mode for a new customer switch. Within minutes, show service id 500 base shows the FDB at 7,980 entries and rising; show service id 500 fdb shows the same customer MAC alternating between SAP 1/3/1:500 and a mesh SDP. show port 1/3/1 reports broadcast traffic at 180,000 pps and the PE CPU at 85%. The customer switch has a second link back to the same VPLS through an unmanaged switch, creating a loop. Existing customers report poor voice quality. The operations team wants to know whether VPLS split horizon should have prevented this, and whether they can simply raise the FDB limit.
1. What is the immediate cause of the outage, and what immediate mitigation would you apply?
Read the worked answer
The symptom pattern-same MAC alternating between a SAP and a mesh SDP, broadcast at 180,000 pps, FDB near 8,000-is a Layer 2 loop, not a VPLS scale problem. Immediate action: shut down SAP 1/3/1:500 to stop the loop. If that is not possible, apply a MAC limit or discard-unknown on that SAP and rate-limit broadcast. Verify with show service id 500 fdb and show port 1/3/1 before and after. Raising the FDB limit would only allow the storm to consume more resources and would not remove the loop.
2. Should VPLS split horizon have prevented this loop? Explain the scope of split horizon.
Read the worked answer
No. Split horizon only prevents a frame received on a mesh SDP from being forwarded to another mesh SDP. It does not stop a loop that enters through a SAP, crosses the VPLS, and returns through another SAP or the same SAP. VPLS is a bridged domain and still needs STP or MSTP at the access, or a loop-free customer topology. The unmanaged switch created a physical loop that VPLS cannot see. Split horizon protects the core mesh from mesh-to-mesh forwarding loops, not the customer access.
3. What permanent fix and guardrails would you recommend, and how would you verify normal operation before re-enabling the SAP?
Read the worked answer
Permanent fix: remove the redundant link or enable STP/MSTP on the PE SAPs and require the customer to run compatible STP. Add guardrails: mac-protect, per-SAP MAC limits, broadcast rate limiting, and discard-unknown where appropriate. Before re-enabling the SAP, verify with show service id 500 base that FDB usage is normal, with show service id 500 fdb that no MAC is flapping, and with show port 1/3/1 that broadcast traffic is at a normal rate. Then re-enable the SAP and monitor for several minutes. Raising the FDB limit is not a fix; it only delays the next outage.