skip to content

Under 802.1D spanning tree, why does a newly connected switch port take about 30 seconds before it forwards a host's frames?

level: middleimportance: must knowfreq 50%

answer

  1. two timed states before forwarding
  2. one listens, one learns
  3. Forward Delay, twice
  4. opening a path is the risky direction

basics

~20 s

802.1D holds the port in listening and then learning, each for one Forward Delay (15 s by the IEEE default), before forwarding: listening lets the tree settle so no temporary loop forms, and learning fills the MAC table first.

solid answer

~50 s

When the link comes up, an IEEE 802.1D bridge does not trust the port. It starts in `blocking`; once the protocol selects it as a root or designated port, it moves to `listening`, then `learning`, then `forwarding`. Listening and learning each last one **Forward Delay** — 15 s by the IEEE's default, settable from 4 to 30 s per RFC 4188 — so the host waits about 30 s. In `listening` the port takes part in the BPDU exchange but neither forwards nor learns: the delay lets new topology information reach every bridge, so no port opens before the rest of the network has blocked the redundant path. In `learning` it records source MAC addresses without forwarding, so its first frames are not all flooded. Moving toward blocking is immediate; only moves toward forwarding wait. Configuring host ports as edge ports removes the wait.

go deeper

for a junior

Recall the order — blocking, listening, learning, forwarding — and that two Forward Delays of 15 s by default make the 30 s wait.

for a middle

Explain what each state does with data frames, MAC learning and BPDUs, and why listening protects against transient loops while learning reduces flooding.

for a senior

Diagnose the symptoms a 30-second wait causes on hosts, explain why the root's timers rule, and know when edge ports are the right fix.

for a principal

Treat the walk as a deliberate trade of availability for loop safety, and weigh whether a design should depend on layer-2 reconvergence at all.

## The five 802.1D port states IEEE 802.1D gives every bridge port one of five states. The state, not the role, decides what happens to an arriving frame. RFC 4188 (the Bridge MIB) restates them as `dot1dStpPortState` values `disabled`, `blocking`, `listening`, `learning` and `forwarding`, and adds a sixth management value, `broken`, for a port the bridge has found to be malfunctioning. | State | Forwards data frames | Learns source MACs | BPDUs | How long | |---|---|---|---|---| | `disabled` | no | no | none | until the port is enabled | | `blocking` | no | no | received and processed, not sent | until chosen as root or designated port | | `listening` | no | no | processed; sent if the port is designated | one Forward Delay | | `learning` | no | yes | processed; sent if the port is designated | one Forward Delay | | `forwarding` | yes | yes | processed; sent if the port is designated | while its role holds | ## The walk, step by step A host plugs into a switch whose spanning tree is already stable: 1. **t = 0 s, `blocking`.** The link comes up and the port is initialised in blocking. No BPDU arrives from a host, so the bridge's role selection makes the port the designated port for its new segment. 2. **t ≈ 0 s, `listening`.** As a newly designated port it starts sending configuration BPDUs and processing any it receives. Data frames are dropped; nothing is learned. 3. **t = 15 s, `learning`.** After one Forward Delay the port starts recording the source MAC address of each arriving frame, then discards the frame. 4. **t = 30 s, `forwarding`.** After a second Forward Delay the port forwards. RFC 4188 counts each learning-to-forwarding move in `dot1dStpPortForwardTransitions`, which makes a flapping port visible. The 15 s figure is the IEEE default. RFC 4188 gives only the settable range, 4 to 30 s (`dot1dStpBridgeForwardDelay`, 400..3000 hundredths of a second). Every bridge uses the Forward Delay the **root** advertises; a value configured on any other bridge applies only if that bridge becomes root. ## Why listening exists The danger in spanning tree is not closing a path but opening one. When a port is selected to forward, other bridges may still be forwarding on the old path because the BPDUs announcing the change have not reached them yet. Opening immediately would let a frame circulate between the new path and the old one, and with no hop limit in an Ethernet frame a broadcast would loop until something broke. Listening is a quarantine: the port behaves like a forwarding port in the BPDU exchange, but forwards no data for long enough for the information to propagate across the network. If the port loses its role during that time, it simply goes back to `blocking` without ever having forwarded. ## Why learning exists A bridge that starts forwarding with an empty table for the port's segment floods every frame whose destination it does not yet know. Learning fills the table first, so when forwarding starts most destinations are already known and the burst of flooding is smaller. Learning cannot create a loop because nothing is forwarded. ## The asymmetry - **Toward forwarding:** two timed steps, one Forward Delay each. - **Toward blocking:** immediate. A port that loses its root or designated role stops forwarding at once, because cutting a path can drop frames briefly but cannot create a loop. This is the protocol choosing loop safety over availability, and it is why the 30 s wait is the price of a port joining the tree. ## What the host sees The host's link light comes up at once, so the host believes it is connected. For about 30 s every frame it sends is dropped. A DHCP client that sends its first requests in that window gets no answer and, depending on the client, may give up, retry or fall back; a network boot may time out. The standard answer is to mark host ports as **edge ports**, which skip listening and learning — a guard-and-convergence subject. When a blocked port must first age out stale information, as after an indirect failure, Max Age is added to the wait — the failover-timing subject. ## Common slips - Saying listening is when MAC addresses are learned: listening learns nothing. - Saying the 30 s comes from Max Age: it is two Forward Delays. - Calling the 15 s an RFC rule: it is the IEEE default; RFC 4188 holds only the range.

  • Why does 802.1D move a port to blocking immediately but delay every move toward forwarding?
    Closing a path can only drop frames for a moment; opening one while another bridge still forwards the old path can create a loop, and an Ethernet frame has no hop limit, so a looping broadcast multiplies until the network fails. The protocol is therefore deliberately asymmetric: block at once, and open only after two Forward Delays have given the new topology time to reach every bridge.
  • An administrator lowers Forward Delay to 4 s on one non-root 802.1D switch; does its new host port forward sooner?
    No. Every bridge uses the timer values the root advertises; a bridge's own configured Forward Delay applies only if it becomes root, as RFC 4188's description of the timer objects notes. Lowering it on the root shortens the walk everywhere, but too short a delay risks ports opening before BPDUs have crossed the network, which is the transient loop the delay exists to prevent.
  • A server's DHCP request fails right after its 802.1D switch port comes up but succeeds on retry; why?
    The server's link is up at once, but its port spends about 30 s in listening and learning, dropping every data frame. DHCP requests sent in that window never reach a server, so the first attempt fails; a retry after the port reaches forwarding succeeds. Making host ports edge ports removes the wait.

saying these in an interview costs you the question

  • The port waits 30 seconds because of the Max Age timer.
  • Listening is the state in which the port learns MAC addresses.
  • A port in learning state already forwards frames, just more slowly.
  • Moving a port to blocking also waits a Forward Delay.
  • The 15-second Forward Delay is fixed by an RFC.
  • Each switch uses its own configured Forward Delay regardless of the root.