Forwarding basics: VLANs, LAG, spanning tree, routing

A transceiver problem never announces itself as a transceiver problem. It appears as a spanning-tree topology change, a LAG member suspended, an OSPF neighbour bouncing, a VXLAN tunnel flapping or "half the users are slow". To read those symptoms back to the physical layer you need the forwarding vocabulary: how a switch learns MAC addresses, what VLANs and trunks are, how link aggregation hashes flows, why spanning tree blocks ports and what routing protocols do when a link blinks. This page is that vocabulary, kept to what matters when the root cause may be a dirty connector.

Layer 2: MAC learning and VLANs

Spanning tree

Spanning tree blocks redundant L2 paths. What a bad optic does to it:

• a flapping uplink generates topology change notifications (TCN); each TCN flushes MAC tables network-wide and causes seconds of flooding — users see stalls every flap (Link flapping);
• a unidirectional link (one fibre broken, Tx works, Rx does not) can create a loop if BPDUs stop arriving — UDLD, loop guard and bridge assurance exist for exactly this (No link);
• blocked port LEDs (amber) are normal on redundant links, not a fault (Port naming & LEDs).

Leaf–spine fabrics avoid STP by routing every link.

Link aggregation (LAG, port-channel, bond)

Practical: when a LAG "works but is slow", check per-member counters and DDM, not the bundle.

Layer 3: routing on the switch

Overlays

Flow control and lossless classes

Reading forwarding symptoms back to the physical layer

The physical checks behind every row: Symptom index, Verifying optics on a switch.

In CodingBox

Forwarding-layer symptoms point at a port; the port points at a module; the module's DDM, identity and thresholds — read on the switch or on the bench — close the case. Keeping a per-module record in the code database turns "the LAG was slow again" into "member 3, serial X, Rx −17 dBm, replaced".