Under 802.1D spanning tree, how does a topology change travel through TCN BPDUs and the TC flag, and why do MAC tables then age faster?
answer
- up the tree, then down
- a report, an acknowledgement, an announcement
- Max Age plus Forward Delay
- 300 s becomes 15 s
basics
~20 sA detecting bridge sends a TCN out its root port; each upstream bridge acknowledges with TCA and relays it. The root then sets TC for 35 s at IEEE defaults, and bridges age MAC entries after Forward Delay so stale ones clear.
solid answer
~50 sA bridge detects a topology change when one of its ports moves to forwarding or stops forwarding. It sends a **TCN BPDU** out its root port every Hello Time until the designated bridge on that segment answers with the **TCA** flag in a Configuration BPDU; that bridge relays its own TCN upward, and so on to the root. The root then sets the **TC** flag in its Configuration BPDUs for Max Age plus Forward Delay, 35 s at the IEEE defaults, and every bridge relays it. While TC is set, bridges age dynamic MAC entries after **Forward Delay** (15 s) instead of the normal ageing time (300 s, as 802.1D-1998 recommends per RFC 4188). The reason: after the tree moves, entries can point at the wrong port, and silent hosts would be unreachable for up to five minutes. The cost is a burst of unknown-unicast flooding while tables relearn.
go deeper
Recall that a topology change makes switches age MAC entries faster so traffic finds hosts on their new path.
Walk the sequence: TCN rootward, TCA back, TC from the root, and Forward Delay as the temporary ageing time.
Connect the mechanism to symptoms: flooding bursts, silent hosts briefly unreachable, and why host ports that bounce make the whole tree flood.
Weigh the flooding cost of each topology change against the size of the layer-2 domain, and why that argues for edge ports, RSTP or routed access.
## The problem the topology-change machinery solves A switch forwards a known unicast frame by its **MAC table** (the Bridge MIB, RFC 4188, calls it the Forwarding Database). Entries are learned from source addresses and expire after the **ageing time**, which 802.1D-1998 recommends at **300 s**. When spanning tree changes which ports forward, the tables are not told: an entry may now point toward a port that is blocked, or toward the old side of a moved path. A host that transmits is relearned at once; a **silent host** stays unreachable until its stale entry expires. Spanning tree therefore signals a **topology change**, and IEEE 802.1D (an IEEE standard, not an RFC) uses that signal to age tables faster. ## What counts as a change Under 802.1D a bridge detects a topology change when one of its ports enters forwarding, or a port that was forwarding or learning stops, through blocking or the link going down. RFC 4188's optional `topologyChange` notification names the same transitions, Learning to Forwarding and Forwarding to Blocking. Note that a host port coming up counts too, unless it is configured as an edge port; otherwise the protocol cannot tell a host from a bridge. ## The walk, step by step 1. **Report.** The detecting bridge sends a **TCN BPDU** (type `0x80`, 4 octets) out its **root port**, repeating it every Hello Time. 2. **Acknowledge.** The **designated bridge** on that segment sets the **TCA** flag in its next Configuration BPDU on that port; the sender stops repeating. 3. **Relay.** That designated bridge sends its own TCN out its own root port, and the pattern repeats hop by hop until the TCN reaches the root. 4. **Announce.** The root sets the **TC** flag in the Configuration BPDUs it originates, for **Max Age + Forward Delay**, which is 20 + 15 = **35 s** at the IEEE defaults (the IEEE's rule). A root that detects a change itself skips straight to this step. 5. **Propagate.** Every bridge copies TC into the Configuration BPDUs it relays, so the flag reaches all bridges in the tree. 6. **Age fast.** While a bridge receives TC, it ages dynamic MAC entries after **Forward Delay** instead of the ageing time. RFC 4188: Forward Delay is "also used when a topology change has been detected and is underway, to age all dynamic entries in the Forwarding Database". | Message | Direction | Sent by | Meaning | |---|---|---|---| | TCN BPDU | toward the root | detecting bridge, then each designated bridge | "something changed below me" | | Configuration BPDU with TCA | away from the root, one segment | designated bridge on that segment | "your TCN arrived" | | Configuration BPDU with TC | away from the root, everywhere | root, relayed by all | "age your tables fast" | ## Why shortened ageing, and what it costs At the defaults, a stale entry now survives at most about **15 s** after it was last refreshed, instead of **300 s**. Entries for active hosts are simply relearned on the correct port as their next frames arrive. The price: - every host that stays silent longer than 15 s loses its entry, so frames to it are **flooded** on every forwarding port in the VLAN until it speaks; - the flood reaches access ports and low-speed links that would normally see none of that traffic; - the effect spans every bridge in the tree, not only the ones near the change. Note the two different numbers: **15 s** is the ageing time used while TC is set, and **35 s** is how long the root keeps TC set. Mixing them up is a common slip. ## How RSTP does it differently RSTP (IEEE 802.1w, folded into 802.1D-2004) reworked this, by the IEEE's rules: - only a **non-edge port moving to forwarding** counts as a change; a port going down or to discarding does not; - the **detecting bridge itself** sets TC in its own BPDUs and sends them on its non-edge designated ports and root port for a short period, the `tcWhile` timer that RFC 4188 mentions; - bridges **flush** affected entries at once rather than shortening their ageing, and each receiver repeats the TC onward, so no trip to the root is needed. RSTP keeps understanding TCN BPDUs when it talks to an 802.1D neighbour. ## What to say in an interview The short version: a change is reported up the tree with acknowledged TCNs, announced down the tree by the root's TC flag, and turned into faster MAC ageing so stale entries clear quickly, at the cost of temporary flooding.
- Why does 802.1D route the change report through the root instead of letting the detecting bridge tell everyone?In 802.1D only the root originates Configuration BPDUs, and every other bridge relays them outward. The only way to reach every bridge is therefore to get the news to the root, which then rides the TC flag down the whole tree. RSTP, where every bridge sends its own BPDUs, lets the detecting bridge announce the change directly.
- Why does the root hold TC for Max Age plus Forward Delay rather than a single Hello Time?A single BPDU can be lost, and a reconvergence can involve stored information expiring and ports moving through listening and learning. Holding TC for Max Age plus Forward Delay, 35 s at the IEEE defaults, keeps tables on short ageing across that window, so entries learned mid-transition do not linger for 300 s.
- How does a topology change behave differently under RSTP?Under RSTP only a non-edge port moving to forwarding is a change. The detecting bridge sets TC in its own BPDUs and sends them on its non-edge designated ports and root port, and receivers flush the affected MAC entries immediately and pass TC on. There is no TCN trip to the root and no 15 s ageing period.
saying these in an interview costs you the question
- A topology change makes every 802.1D switch delete its whole MAC table instantly.
- The TCN BPDU travels away from the root to every bridge.
- Any 802.1D bridge sets the TC flag itself when it detects a change.
- The root keeps the TC flag set for one Forward Delay, 15 s.
- Topology changes happen only when a link between two switches fails.