2.4 Ethernet Redundancy, Spanning Tree, and LAGs

Redundant paths need forwarding rules

The current course explicitly includes Ethernet redundancy. Adding a second cable can improve resilience, but two active Layer 2 paths can also create a loop. Ethernet frames have no IP-style TTL field that automatically ends repeated bridging.

In a triangle of three switches, a broadcast can arrive over multiple paths, be replicated again, and return to a switch that already handled it. Source-MAC learning can oscillate as copies arrive on different ports. The resulting symptoms can include excessive traffic, duplicate frames, MAC movement, and loss of useful capacity.

A physical ring is therefore not automatically a resilient logical topology. The network needs a loop-prevention or protection mechanism appropriate to the service.

Spanning tree

Spanning Tree Protocol (STP) selects a loop-free active forwarding topology. Rapid Spanning Tree Protocol (RSTP) provides faster transition mechanisms under suitable conditions. Both exchange control information rather than relying on an administrator to unplug whichever cable seems redundant.

A Root Bridge anchors the selected topology. Bridge identifiers and path costs influence which ports provide the active paths. Redundant paths can remain available while a port is placed in a non-forwarding/discarding role.

A blocked/discarding port is not necessarily broken. Forcing it to forward without understanding the topology can create the very loop the protocol prevented.

A failure walkthrough

Suppose switches A, B, and C form a triangle. The selected active topology carries traffic from A to C through B, while one redundant attachment is discarding.

If the A–B link fails, the protection protocol can move the logical topology to a surviving path. Recovery depends on link detection, protocol state, endpoint behavior, and forwarding updates. “RSTP is enabled” is not a universal promise of one fixed outage duration or zero packet loss.

After recovery, learned MAC locations may need updating. Inspect port roles and the FDB rather than assuming that a restored link immediately restores every customer flow. A link's physical state and the bridge's permission to forward are separate layers of evidence.

Link aggregation

A Link Aggregation Group (LAG) combines compatible Ethernet links into a logical attachment. Link Aggregation Control Protocol (LACP) helps establish and monitor participating links. A LAG can provide aggregate capacity and resilience to a member failure when sufficient operational members remain.

A switch or router generally treats the bundle as one logical interface for the relevant forwarding configuration. This differs from two unrelated active links creating an uncontrolled parallel bridge path.

Traffic commonly uses a flow-based hash to select a member. Four 10 Gb/s members offer up to 40 Gb/s aggregate capacity across suitable traffic, but one ordinary flow is not guaranteed 40 Gb/s. Hash distribution, flow sizes, member health, and platform behavior affect actual utilization.

LAG failure and minimum links

If one member fails, a bundle can remain operational using the surviving members. Capacity falls, and some flows may move to another member. The service can therefore continue while experiencing congestion or transient disruption.

A minimum-links or similar configured threshold can intentionally bring the logical bundle down when too few members remain. This can make routing or service protection choose another path rather than retaining a severely reduced bundle.

For an explicit example, a four-member bundle requires at least three operational members. Losing one leaves three and can preserve operation. Losing two leaves only two and violates the stated threshold. The result follows from the configured requirement, not a universal rule that every LAG survives any member failure.

Inspect both logical LAG state and each member's operational state. A bundle configured administratively Up is not proof that all links joined the intended aggregate.

Provider service redundancy

Provider access and Ethernet rings may use mechanisms such as Ethernet ring protection or multi-chassis designs. The mechanism must match the supported platform and topology. Do not combine protocols by assumption or treat a product's redundancy feature name as evidence that the intended backup path exists.

In VPLS, mesh-SDP split horizon prevents forwarding from one core mesh attachment to another. That protects a particular core bridging pattern. It does not automatically prevent a loop through customer switches, SAPs, or redundant spoke attachments.

For example, two customer switches connected by their own Ethernet link and separately attached to the same bridged provider service can create an external loop. The provider core's mesh split-horizon rule does not by itself block every path in that customer-side topology.

Diagnose without defeating protection

Begin by drawing physical links and logical forwarding permissions separately. Mark the SAPs or VLANs involved, the active protection role, LAG membership, and any forwarding restrictions.

Then check whether a non-forwarding state is expected. Inspect counters and MAC learning before making changes. Avoid “fixing” an intentional discarding port by disabling the protection protocol. For study scenarios, explain how a specific failure changes the usable path and which shared resource remains a dependency.

Redundancy means an alternative can take over under defined conditions. It does not mean that all alternatives should forward simultaneously or that every failure is covered by one mechanism.

Primary reference

Nokia Ethernet ring protection example and Nokia SR OS documentation, checked October 20, 2026. Use platform-specific STP, LACP, and protection references for configuration.