Spanning Tree Protocol · · 6 min read

Understanding STP Timers: Hello, Forward Delay, and Max Age

STP timers control convergence speed, BPDU frequency, and failure detection. Understanding how hello, forward delay, and max age interact is essential to designing stable networks and troubleshooting convergence issues.

The Three Core Timers

Spanning Tree Protocol uses three timers to control network behavior:

Timer Default Purpose
Hello Time 2 seconds Interval between BPDU transmissions from root
Forward Delay 15 seconds Time spent in listening and learning states
Max Age 20 seconds Maximum age of a BPDU before it's considered stale

All timers are configured on the root bridge. Non-root switches inherit these values from BPDUs sent by the root.

Hello Timer (Default: 2 Seconds)

The hello timer controls how frequently the root bridge sends BPDUs out its designated ports.

BPDU Transmission Frequency

On the root bridge:

SW1 (root) Eth0/0 → SW2 (neighbor)
t=0s:   Send BPDU #1
t=2s:   Send BPDU #2
t=4s:   Send BPDU #3
t=6s:   Send BPDU #4
...

Non-root switches receive these BPDUs and relay them (appending costs), sending new BPDUs out their designated ports at the same hello interval.

Failure Detection Speed

The hello timer indirectly affects failure detection. If a link fails:

Eth0/0 loss at t=0s
Next BPDU due at t=2s
Switch notices BPDU not arriving
→ Waits up to max age (20s) to declare the link dead
→ Then transitions port roles

The shorter the hello timer, the sooner a switch detects that BPDUs aren't arriving. However, a very short hello timer increases CPU usage and BPDU flooding.

Configuring Hello Time

SW1(config)# spanning-tree vlan 1 hello-time 1

Valid values: 1-10 seconds. Default is 2.

Production Guideline

Keep hello time at 2 seconds unless you have a specific reason to change it. Most network issues are due to timer changes, not defaults.

Forward Delay (Default: 15 Seconds)

The forward delay controls how long a port spends in the listening and learning states during state transitions.

State Transition Timeline

When a port transitions from blocking to forwarding:

t=0s:   Port becomes eligible for listening (root port or designated port selected)
t=15s:  Port transitions from Blocking → Listening
t=30s:  Port transitions from Listening → Learning
t=45s:  Port transitions from Learning → Forwarding

Wait—that's 45 seconds total, not 30. Let me clarify the specification:

How Forward Delay Works

The forward delay timer starts when a port enters listening state. It counts down once:

Blocking state → Select port role (root or designated) → Enter Listening
[Wait forward delay = 15 seconds]
Listening → Learning
[Wait forward delay = 15 seconds]
Learning → Forwarding

So yes: two forward delay periods = 30 seconds minimum before a port forwards traffic.

Why Not Reduce Forward Delay?

The forward delay prevents temporary loops during convergence. If it's too short:

Link failure at t=0s
Root port selected on alternate port at t=5s
Port enters listening state
[forward delay set to 5 seconds]
Port enters forwarding at t=10s

But other switches are still converging (15-30 second total):
  SW3 hasn't yet learned about topology change
  SW3 still thinks old path is correct
  Frames sent to SW2 are looped by SW3
  Duplicate frames reach endpoints

The 15-second default (30-second total) gives all switches in a typical network (up to 7 hops) enough time to propagate changes.

The Diameter Formula

The network diameter is the maximum number of hops between any two switches. The forward delay formula relates to diameter:

Forward Delay ≥ (Network Diameter / 2) + 1

For a network with maximum 7 hops:

Forward Delay ≥ (7 / 2) + 1 = 4.5 → minimum 5 seconds

However, Cisco recommends the default 15 seconds because:

Configuring Forward Delay

SW1(config)# spanning-tree vlan 1 forward-time 12

Valid values: 4-30 seconds. Default: 15.

Warning: Cisco recommends against changing this. If you do, follow the diameter formula strictly.

Max Age (Default: 20 Seconds)

The max age timer determines how long a switch waits for a BPDU before assuming the link is dead and reconvergence is needed.

BPDU Staleness Detection

On a port receiving BPDUs:

t=0s:   BPDU received, age = 0
t=1s:   (No new BPDU), age = 1
t=2s:   BPDU received, age resets to 0
t=4s:   BPDU received, age resets to 0
...
t=25s:  (No BPDU received for 25s), age = 25 → exceeds max age (20s)
        Port transitions: Forwarding → Blocking → Listening → ...

Failure Detection Window

If BPDUs stop arriving (link failure, switch crash, etc.):

Link failure at t=0s
Blocked port waits for new BPDU
If max age = 20s, waits up to 20 seconds
At t=20s, max age expires
Port role recalculates: may become root port
Port transitions to listening state
[Another 30s for listening + learning]
Total failover time: 20s + 30s = 50s

Relationship to Hello Timer

The max age should be significantly larger than the hello timer:

If hello = 2s, max age should be 20s (2s × 10)
If hello = 1s, max age should be 10s (1s × 10)

Formula: max age ≥ 2 × hello time + 4

Configuring Max Age

SW1(config)# spanning-tree vlan 1 max-age 15

Valid values: 6-40 seconds. Default: 20.

Risks of Changing Max Age

Too small:

SW1 sends BPDU at t=0s
Network delay causes BPDU to arrive at t=3s
If max age = 2s, BPDU is already stale when it arrives
Port considers itself disconnected
Unnecessary transitions occur

Too large:

Link failure at t=0s
Switch waits 40 seconds before detecting failure
Network is black for 40s + 30s = 70s
Unacceptable for most applications

Timer Relationships and the Complete Formula

All three timers work together. For a stable network:

hello time ≤ forward delay / 2
max age ≥ 2 × hello time + 4
forward delay ≥ (diameter / 2) + 1

Example for a 7-hop network:

hello = 2s ✓
max age ≥ 2 × 2 + 4 = 8s, using 20s ✓
forward delay ≥ (7/2) + 1 = 4.5s, using 15s ✓

Relationship check:

2s ≤ 15s / 2 = 7.5s ✓
20s ≥ 2 × 2 + 4 = 8s ✓
15s ≥ 3.5s ✓

All defaults satisfy the constraints.

Viewing Timer Configuration

Show Spanning-Tree Root

SW1# show spanning-tree root

                                        Root    Hello Max Fwd
Vlan                   Root ID          Cost    Age  Dly Root Port
──────────────────────────────────────────────────────────────────
VLAN0001           4096 aabb.cc00.1100   0      2    20   15   -
VLAN0010           4096 aabb.cc00.1100   0      2    20   15   -

Columns:

(Note: Some outputs show different column order. The exact display varies by IOS version.)

Show Spanning-Tree Bridge Timers

SW1# show spanning-tree vlan 1 bridge

                                        Hello Max Fwd
Vlan                   Bridge ID          Time Age Dly
──────────────────────────────────────────────────────
VLAN0001           32768 aabb.cc00.1100   2    20   15

Show Spanning-Tree Detail

For comprehensive timer and port information:

SW1# show spanning-tree vlan 1 detail

VLAN0001 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, sysid 1, address aabb.cc00.1100
  Configured hello time 2, forward delay 15, max age 20
  Current root has priority 4096, address aabb.cc00.1100
  Root is bridge (this bridge is the root)
  Hello time 2 sec, Max age 20 sec, Forward delay 15 sec
  Aging time 300 sec (not relevant to timers, MAC table timeout)

Port 1 (Ethernet0/0)
  Port path cost 4
  Designated root has priority 4096, address aabb.cc00.1100
  Designated bridge has priority 32768, address aabb.cc00.1100
  Timers: message age 0, forward delay 0

Key fields:

If the port were transitioning:

Port 2 (Ethernet0/1)
  Timers: message age 1, forward delay 12

This means:

Real-World Timer Scenarios

Scenario 1: Detecting a Failed Core Switch

Topology:

[SW1] ─ (SW2) ─ [SW3]
 Root    (failed, power off)

SW3's convergence:

t=0s:   SW2 power off (BPDUs stop)
t=2s:   SW3 expects BPDU, none arrives
t=4s:   Still no BPDU
...
t=20s:  Max age expires on SW3's root port
t=35s:  SW3 in listening state (has alternate path through SW1? No, no alternate)
t=50s:  SW3 begins listening to new BPDUs from another path (if available)

If SW3 has only one path (through SW2), it waits until a new root bridge is elected among remaining switches. This can take additional time.

If a link is flaky (intermittent packet loss):

BPDUs arriving irregularly:
t=0s:   BPDU arrives
t=5s:   (Link flaky, BPDU lost)
t=7s:   BPDU arrives again
t=15s:  Another BPDU arrives

After several cycles, max age eventually expires if too many BPDUs are lost.
But if enough BPDUs arrive before max age (20s), the port stays stable.

Flaky links often don't trigger reconvergence, they just degrade performance.

Scenario 3: Network with Long Propagation Delay

In data center environments with long-distance links or heavily congested networks:

Hello time = 2s
BPDU sent at t=0s from root
Link is congested, BPDU delayed
BPDU arrives at t=5s (3 second delay)
Switch receives it: message age = 0 (just arrived)

But what if propagation delay is even longer?
BPDU sent at t=0s
Arrives at t=8s
Message age shows 0, but it's actually ancient

This is why monitoring message age and BPDU rates is critical.

Changing Timers: Best Practices

When to Change Timers

Very rarely. Specific cases:

  1. Small networks (1-2 hops): Can safely reduce forward delay to 10-12 seconds
  2. Very large networks (>7 hops): May need to increase max age to 25-30 seconds
  3. Slow links or WAN: Increase max age to account for propagation delay

How to Change Timers

Only on the root bridge. Non-root switches inherit:

SW1(config)# spanning-tree vlan 1 hello-time 2
SW1(config)# spanning-tree vlan 1 max-age 20
SW1(config)# spanning-tree vlan 1 forward-time 15

Better Alternative: Use Rapid STP

Instead of tuning timers, migrate to Rapid PVST+:

SW1(config)# spanning-tree mode rapid-pvst

RSTP converges in 2-6 seconds without requiring timer adjustments.

What's Next

Read Article 6: STP Path Cost and How Cisco Switches Calculate the Best Path to understand cost calculations, link speed considerations, and how to manually override costs for optimal topology design.


Read next

© 2025 Ping Labz. All rights reserved.