A spanning-tree network shows its topology-change counter climbing all day and constant unicast flooding; how do you find the source and stop it?

## The symptom and its mechanism Users report sluggish, bursty performance; packet captures on access ports show unicast traffic for other hosts; switch monitoring shows the spanning-tree **topology change count** rising through the day. The mechanism is the topology-change machinery of **IEEE 802.1D** (an IEEE standard; the IETF's Bridge MIB, RFC 4188, restates its counters): 1. a bridge whose port changes state sends a TCN toward the root; 2. the root sets the **TC** flag in its Configuration BPDUs for **Max Age + Forward Delay**, 35 s at the IEEE defaults; 3. every bridge receiving TC ages its MAC entries after **Forward Delay**, 15 s, instead of the usual ageing time, 300 s as 802.1D-1998 recommends; 4. any host silent for more than 15 s loses its entry, and frames to it are **flooded** across the VLAN. One change is a short flood. The trouble is repetition. ## Why recurring changes mean constant flooding The arithmetic is simple. If topology changes arrive more often than every 35 s, each new TC period begins before the last one ends, so the tree **never leaves short ageing**. | Interval between changes | Share of time on 15 s ageing (approx.) | |---|---| | every 10 minutes | 35 / 600, about 6 % | | every 2 minutes | 35 / 120, about 29 % | | every 30 s | windows overlap: all of it | A server room where several hosts reboot, or one link that flaps every few seconds, is enough. The flooding also reaches every bridge in that spanning tree, not just the neighbourhood of the fault. ## Proving it is happening The Bridge MIB gives the evidence, polled from any bridge: - `dot1dStpTopChanges` — the number of topology changes the bridge has detected; a steady climb is the signature; - `dot1dStpTimeSinceTopologyChange` — time since the last one; if it never gets large, changes are continuous; - `dot1dStpPortForwardTransitions` — per port, the number of moves from learning to forwarding; a port with a climbing count is changing state repeatedly. These tell you **when** and, at the right bridge, **which port**. They do not tell a distant bridge where the change began: the TCN and the TC flag carry no bridge or port ID. ## Finding the source Work toward the bridge that originates the changes: 1. Start at any bridge, often the root, and find the port on which the most recent topology-change report arrived. Recording that port, and the sender, is an implementation feature most switches offer. 2. Go to the neighbour on that port and repeat. Under 802.1D the TCNs travelled rootward along this exact path, so walking it backwards leads to the origin. 3. Stop at the bridge where the change comes from one of its **own** ports. Its per-port forward-transition count, or RFC 4188's optional `topologyChange` notification, sent "when any of its configured ports transitions from the Learning state to the Forwarding state, or from the Forwarding state to the Blocking state", names the port. 4. Correlate with that port's link up and down history. ## Common culprits and fixes - **A flapping inter-switch link** — a failing optic, a bad cable, a duplex mismatch. Fix the physical layer; each flap is a genuine change. - **Host ports that go up and down** — rebooting servers, laptops docking, power-saving network cards. Under classic 802.1D each one is a topology change unless the port is an edge port. Declare host-facing ports **edge ports**: under RSTP an edge port does not count as a change when it reaches forwarding. How edge ports and their guards are configured is a separate subject. - **A neighbour bouncing between roles** — for instance an unstable link toward a bridge that keeps winning and losing a designated role. Stabilise the link or the priorities. What not to do: setting the normal ageing time permanently low only makes flooding permanent; lowering timers on a non-root bridge has no effect at all. ## Where RSTP helps Under RSTP (IEEE 802.1w, now in 802.1D-2004) a port going down or to discarding is not a topology change, only a non-edge port moving to forwarding is, and edge ports never count. Moving to RSTP and marking host ports as edge removes most of the noise; what is left points at real instability.