Redundant Layer 2 Links: How Do I Prevent Loops Between Sites?
Two Layer 2 links become resilient only with a defined redundancy model. Plan STP, split horizon, EVPN, failover and acceptance testing correctly.
Two Layer 2 links between the same sites are not automatically redundant. If both forward the same VLANs at the same time and create a closed path, Ethernet frames can circulate, multiply and continuously rewrite MAC tables. Resilience begins with a defined operating model: exactly one active path, a correctly bundled logical link or a coordinated multihoming design with its own loop-prevention mechanism.
Why a Layer 2 loop does not expire by itself
An Ethernet frame has no IP hop-limit or TTL mechanism that discards it after several circuits. Broadcast, multicast and frames for as-yet unknown destination MAC addresses are flooded to multiple ports within a broadcast domain. If a copy returns by a second path, it can be replicated again. Cisco lists duplicate messages, changing MAC learning and an unstable topology as typical consequences. Spanning Tree prevents this by placing one port of a redundant path into a non-forwarding state.
Cisco: spanning tree and loop-free redundant paths
| Observation | Possible cause | Useful evidence |
|---|---|---|
| Broadcast or unknown-unicast rate rises sharply | Frames are repeatedly replicated around a closed path | Per-VLAN and per-port counters plus a timestamped packet capture |
| One MAC address moves rapidly between ports | The same source frame alternately reaches the switch over two paths | MAC-move log and forwarding tables at both ends |
| CPU load and packet loss rise together | Multiplied traffic consumes control-plane and data-plane resources | Device load, drops, packet rate and topology changes on one timeline |
Choose the redundancy model first
Before ordering, establish who selects the active path and which component prevents a loop. The answer cannot emerge independently from two separately configured ends. The operator, both customer switches and any overlay must use the same model. A second link that is activated manually after a fault has different requirements from an all-active design.
| Model | Normal state | Must be agreed |
|---|---|---|
| Single-active | One path forwards while the second waits | Detection, switching criterion, hold time and controlled return |
| Spanning Tree | STP blocks one redundant port or VLAN path | BPDU transport, root placement, STP variant and VLAN mapping |
| Logical link bundle | Several members form one jointly controlled link | Endpoints, LACP behaviour, minimum active members and failure domains |
| EVPN multihoming | Single-active or all-active with a distributed control procedure | End-to-end support, ESI, DF election, split horizon and MAC mobility |
Layer 3 is often the simpler resilience boundary
If applications do not require one shared broadcast domain, routed handoffs with a routing protocol can reduce the failure domain. Do not stretch a VLAN between sites merely because two circuits exist.
Spanning Tree needs a known BPDU boundary
STP can block one of the two paths on the customer side. The switches must reliably exchange the required Bridge Protocol Data Units and see the same logical topology. A Layer 2 service may carry BPDUs transparently, filter them or terminate them itself; this must be documented rather than assumed. Root-bridge placement, path costs, RSTP or MSTP behaviour and the mapping of VLANs to instances must also be explicit.
- At each site, define which switch should be the root or preferred root.
- For every carried VLAN, know which port forwards and which blocks in the stable state.
- Clarify whether the service carries BPDUs, link OAM and other control protocols transparently.
- Use protection features such as BPDU Guard, Root Guard or Loop Guard only with the appropriate port role.
- Plan for one-way faults: a link may still send frames while losing control packets in the opposite direction.
Provider and customer loops are separate layers
A provider can keep its own Layer 2 VPN topology loop-free with split horizon. RFC 4762 specifies for VPLS that broadcast, unknown unicast and multicast traffic is flooded, but a frame must not be forwarded from one pseudowire to another pseudowire in the same full mesh. This protects the provider mesh. It does not prove that a loop formed by two customer switches, cross-connections or incorrectly joined VLANs is also prevented.
RFC 4762: flooding and split horizon in VPLS
Illustrative scenario: VLAN 120 over two circuits
The following example uses documentation values only: Site A and Site B carry VLAN 120 over Red circuit and Blue circuit. At both sites, an internal link also joins the participating switches. This is not a real AS51202 topology, a confirmed redundancy procedure or a product commitment.
| State | Unsafe effect | Controlled behaviour |
|---|---|---|
| Both circuits available | Both ports forward VLAN 120 without shared logic | One port blocks or a coordinated all-active procedure prevents reflection |
| Red circuit fails | Manual changes occur at both ends in a different order | The defined procedure activates Blue only after unambiguous fault detection |
| Red returns | Both paths forward during an uncoordinated restoration | Hold-down, synchronisation and return policy prevent a transient dual path |
Restoration matters as much as failure. Many incidents occur not when a cable is disconnected, but when a path reappears, endpoints converge at different times and MAC entries still point to the former path.
Two circuits do not automatically form an LACP bundle
A Link Aggregation Group can present several physical members as one logical link. This works only when the opposing systems and transport architecture jointly support that exact bundle. Two independent carrier services cannot be made safe merely by applying identical LACP configuration to the customer switches. Minimum active members, hash distribution, MTU, VLAN list and behaviour after a one-way member failure must also match.
EVPN multihoming requires more than two active ports
EVPN can distribute MAC reachability through BGP and connect one Ethernet segment to several provider edges. RFC 7432 defines Ethernet Segment Identifiers, auto-discovery, designated-forwarder election and split-horizon procedures for this purpose. The designated forwarder controls which node forwards multi-destination traffic towards a multihomed segment. The model must be configured consistently on every participating system; two ports carrying the same VLAN do not constitute EVPN multihoming.
RFC 7432: EVPN multihoming and designated forwarder
RFC 9746 clarifies two split-horizon procedures for EVPN multihoming: an ESI-label-based method and local bias. Both are intended to prevent a frame being sent back to the same multihomed customer segment from which it originated. The suitable method depends in part on the tunnel type. Encapsulation, operating mode and interoperability therefore belong in the design; ‘EVPN’ alone is not a complete redundancy description.
RFC 9746: split-horizon procedures for EVPN multihoming
Make flooding and MAC learning measurable
BUM traffic remains part of Layer 2 operation even without a loop: broadcast, unknown unicast and multicast. RFC 7348 describes for VXLAN how unknown destinations and broadcasts are replicated and how mappings from source MAC to tunnel endpoint are learned. An unusually high unknown-unicast share can indicate missing or unstable learning. A bandwidth graph alone is insufficient; measurements are needed per VLAN, direction and node.
RFC 7348: MAC learning and BUM traffic in VXLAN
- Observe broadcast, multicast and unknown unicast separately by packet rate and data rate.
- Log MAC moves with old interface, new interface, VLAN and timestamp.
- Correlate STP topology changes, root changes and port roles with link events.
- Evaluate drops, error counters and CPU load at both site edges together.
- Tune alerts to the normal environment; one ARP spike is not proof of a loop.
Acceptance must test failure and restoration
- 1Record cabling, VLANs, port roles, control protocols and the expected normal state in one shared diagram.
- 2For every VLAN, document the active and blocked path or DF role in the stable state.
- 3Disconnect each circuit separately and measure detection time, switching, packet loss, MAC moves and application impact.
- 4Test a one-way fault in which only one direction or only control traffic is impaired.
- 5Restore the circuit in a controlled manner and verify that hold-down, synchronisation and MAC learning work without dual forwarding.
- 6Use legitimate broadcast, multicast and unicast test traffic to verify that counters and alerts show the expected paths.
What to include in a Layer 2 enquiry
Provide both exact handoff points, bandwidth, port type, MTU, VLANs and required tagging. Describe the customer switches, internal cross-links and desired model: single-active, customer-side STP, a coordinated bundle or multihoming. Ask explicitly how BPDUs and other control protocols, MAC limits, BUM traffic, fault detection and maintenance events are handled. For an AS51202 enquiry, the available handoff and redundancy option at the requested sites can then be checked and documented in the proposal.