skip to content

In 802.1D spanning tree, what is a BPDU, and how do Configuration BPDUs and Topology Change Notification BPDUs differ?

level: juniorimportance: should knowfreq 38%

answer

  1. control frames, consumed not forwarded
  2. reserved multicast destination
  3. one flows away from the root
  4. one climbs toward the root
  5. 35 octets versus 4

basics

~20 s

A BPDU (bridge protocol data unit) is the spanning-tree control frame bridges exchange on the reserved address 01-80-C2-00-00-00. Configuration BPDUs flow outward from the root carrying the tree's state; TCN BPDUs climb toward the root to report a change.

solid answer

~50 s

A **BPDU** (bridge protocol data unit) is the control message spanning-tree bridges exchange. It goes to the reserved multicast address `01-80-C2-00-00-00`, and a bridge running spanning tree consumes it rather than forwarding it. Classic 802.1D has two kinds. A **Configuration BPDU** is originated by the root every Hello Time and relayed outward through designated ports; it carries the root ID, root path cost, sender bridge ID, port ID, message age and the three timers, and it is how every bridge learns the tree. A **Topology Change Notification (TCN) BPDU** is a 4-octet message a bridge sends out its root port, toward the root, when one of its ports changes state; it carries no tree information and is repeated until acknowledged. The root answers by setting the TC flag in its Configuration BPDUs. RSTP replaces both with a single RST BPDU.

go deeper

for a junior

Recall that a BPDU is spanning tree's control frame, that Configuration BPDUs come from the root and TCN BPDUs go toward it.

for a middle

Explain who originates each BPDU, which ports send and receive it, and why a TCN is repeated until a TCA flag acknowledges it.

for a senior

Show you can read BPDU behaviour off a live network: who should be sending what on each port, and what a missing or unexpected BPDU on a port means.

for a principal

Weigh what the BPDU design implies for a large layer-2 domain: every bridge depends on timely control frames, which argues for keeping such domains small.

## What a BPDU is **Spanning tree** keeps a switched Ethernet network loop-free by electing one **root bridge** and blocking redundant ports so exactly one path joins any two segments. Classic spanning tree is defined by **IEEE 802.1D** (an IEEE standard, not an RFC; the IETF restates its managed objects in the Bridge MIB, RFC 4188). The messages bridges exchange to build and maintain the tree are **bridge protocol data units (BPDUs)**. A few properties hold for every BPDU: - it is sent to the reserved multicast address `01-80-C2-00-00-00`; RFC 6325 lists that address as the BPDU destination inside the `01-80-C2-00-00-00` to `01-80-C2-00-00-0F` block of layer-2 control addresses; - it is carried in an IEEE 802.2 LLC frame and never carries user data; - it is **consumed hop by hop**: a bridge running spanning tree processes the BPDUs it receives and sends BPDUs of its own, built from what it learned, rather than forwarding the received frame. ## The Configuration BPDU: the tree's state, flowing outward The **Configuration BPDU** (BPDU type `0x00`, 35 octets) carries everything a bridge needs to place itself in the tree: 1. the **Root Identifier** — the bridge ID of the bridge believed to be root; 2. the **Root Path Cost** — the sender's cost to reach that root; 3. the sender's own **Bridge Identifier** and the **Port Identifier** it was sent from; 4. **Message Age**, plus the root's **Max Age**, **Hello Time** and **Forward Delay**; 5. a **Flags** octet holding the **TC** (topology change) and **TCA** (topology change acknowledgement) bits. The root originates one every **Hello Time** (2 s by the IEEE standard's default). RFC 4188 describes Hello Time as the interval between Configuration BPDUs a bridge sends "when it is the root of the spanning tree, or trying to become so". Under 802.1D-1998 a non-root bridge sends Configuration BPDUs on its **designated ports** when one arrives on its **root port**, rewriting the cost, bridge ID, port ID and message age on the way. So the information flows **away from the root**, segment by segment, and reaches every bridge in the tree. ## The TCN BPDU: a report, flowing toward the root The **Topology Change Notification (TCN) BPDU** (type `0x80`) is only 4 octets: protocol identifier, protocol version and type. It carries no root ID, no cost, no bridge ID and no timers. A bridge sends one when it detects a topology change, such as a port moving from learning to forwarding or from forwarding to blocking. - It goes out the **root port**, toward the root, and is repeated every Hello Time until acknowledged. - The designated bridge on that segment acknowledges it by setting **TCA** in the next Configuration BPDU it sends there, then sends its own TCN out its own root port. - When the news reaches the root, the root sets **TC** in its Configuration BPDUs for a while, and that flag travels back outward to every bridge, which then ages MAC entries faster. Because the TCN carries no bridge ID, the root never learns *who* reported the change, only that one happened. ## Side by side | | Configuration BPDU | TCN BPDU | |---|---|---| | BPDU type | `0x00` | `0x80` | | Size | 35 octets | 4 octets | | Who originates it | the root; each bridge relays it on designated ports | any bridge that detects a change | | Direction | away from the root | toward the root | | Cadence | every Hello Time | repeated every Hello Time until TCA arrives | | Content | root ID, cost, bridge ID, port ID, ages, timers, flags | header only | ## What RSTP changed The **Rapid Spanning Tree Protocol** (IEEE 802.1w, folded into 802.1D-2004) uses one **RST BPDU**: protocol version `2`, type `0x02`, 36 octets. RFC 4318, the RSTP MIB, lists the version values `stpCompatible(0)` and `rstp(2)` and notes they come directly from the IEEE standard. Every RSTP bridge originates its own BPDU every Hello Time instead of only relaying the root's, and a bridge that detects a change sets TC in its own BPDUs on its root port and non-edge designated ports, so the separate TCN is used only towards 802.1D neighbours. The flag bits between TC and TCA carry RSTP's proposal and agreement handshake, a separate subject. ## Common misreadings - "BPDUs are forwarded like ordinary multicast" — a spanning-tree bridge consumes them and sends its own. - "Only the root sends BPDUs" — every designated port sends Configuration BPDUs, and any bridge can send a TCN. - "The TCN tells the root which port changed" — it carries nothing but its header.

  • Why does a TCN BPDU need an acknowledgement when Configuration BPDUs do not?
    Configuration BPDUs repeat every Hello Time, so a lost one is replaced two seconds later and stale information simply ages out. A TCN is event-driven: if it were lost, the root would never hear of the change. So the sender repeats it every Hello Time until the designated bridge on its segment returns a Configuration BPDU with the TCA flag set, and each bridge on the path to the root does the same.
  • How does an RSTP bridge exchange BPDUs with a neighbour that only runs 802.1D?
    RSTP is backward compatible per port. When a port hears 802.1D-format BPDUs, it falls back to sending 802.1D Configuration and TCN BPDUs on that port and loses the rapid handshake there. RFC 4318's protocol-migration object lets an operator force the port to try RSTP BPDUs again once the old neighbour has gone.

saying these in an interview costs you the question

  • BPDUs are forwarded through the switched network like ordinary multicast data.
  • Only the root bridge ever sends BPDUs.
  • A TCN BPDU carries the sender's bridge ID so the root knows where the change happened.
  • A non-root 802.1D bridge sets the TC flag itself to announce its own change.
  • RSTP still sends separate TCN BPDUs for every topology change.