Routelearn.net
Course menu

Course 6: Spanning Tree ProtocolLesson 4.2 (17 of 24 in this course)38 of 91 in the CCNA series

Understanding RSTP synchronization

The proposal/agreement handshake that lets a new link forward almost instantly.

Advanced · 7 min read

RSTP synchronization is the proposal/agreement handshake RSTP uses on point-to-point links. A switch receiving a proposal from a designated port blocks its own non-edge designated ports (sync), then sends an agreement, letting the new link start forwarding without waiting for timers while still preventing a loop.

In simple terms: Before a new link starts carrying traffic, the switch on the other end quickly blocks its other links, then says “agreed.” That way the link can go live almost instantly without creating a loop.

The question RSTP has to answer

When a new link comes up, classic STP waits 30 seconds to be sure no loop can form. RSTP does something else. It asks the switch at the other end: "Is it safe for me to forward now?" The answer comes in a short exchange called proposal / agreement. A step called sync makes it safe.

Watch the handshake

Situation: a new cable connects SW1 (the root) to SW2. SW2 already has a link down to SW3, and a PC on an edge port.

new linkSW1 (root)SW2SW3PCedge port
  1. 1. Proposal. The link comes up. Both ends are discarding (blocked). SW1's port wants to be designated, so it sends a BPDU with the proposal flag turned on.
  2. 2. Sync. The proposal shows a better root, so this link will be SW2's new root port. Before it agrees, SW2 blocks all its other ports that lead to switches (here, toward SW3). Now no loop is possible.
  3. 3. Edge ports keep forwarding. The PC's edge port can't create a loop, so sync doesn't block it.
  4. 4. Agreement. SW2 replies out of its new root port, with the agreement flag turned on.
  5. 5. Forward. SW1's port goes straight to forwarding, and so does SW2's root port. No timers are used.
  6. 6. It ripples down. Now SW2 sends its own proposal to SW3. SW3 does the same sync and agrees, and the next link starts forwarding.

Why sync makes it safe

When SW2 agrees, all its ports toward other switches are blocked. So when the new link starts forwarding, there is no path through SW2 that could make a loop. Then each switch further down does the same handshake. The tree is rebuilt one link at a time, going outward from the root, in a very short time.

A bigger example: the sync wave

Situation: five switches are already working. A new core switch, called NEW, is connected to switch A. NEW has the lowest bridge ID in the network. So every switch is about to learn about a better root, and each one must sync again.

NEWlowest BIDABCDE
  1. 1. NEW proposes to A. NEW's port starts as designated and discarding, and sends proposals.
  2. 2. A syncs and agrees. A blocks its ports toward other switches, makes the NEW link its root port, and agrees. Both ends start forwarding.
  3. 3. A proposes to B. B syncs (it blocks its ports toward C and D) and agrees.
  4. 4. B proposes to C and D in parallel. Each one syncs, agrees, and sends its own proposal on toward E.
  5. 5. E receives two proposals. One link becomes its root port, and E agrees. The other link is a worse path, so E's end becomes alternate and stays blocked. The loop is broken.

This is how it might look on two of the switches with debug spanning-tree events turned on (written to show the order of events):

Example output · based on Cisco documentation; exact format varies by platform and software version
B#debug spanning-tree events
11:20:04.312: RSTP(1): updt roles, received superior bpdu on Gi1/0/1
11:20:04.312: RSTP(1): Gi1/0/1 is now root port
11:20:04.312: RSTP(1): syncing port Gi1/0/2
11:20:04.312: RSTP(1): syncing port Gi1/0/3
11:20:04.312: RSTP(1): Gi1/0/1 agree (allSynced)
11:20:04.313: RSTP(1): transmitting an agreement on Gi1/0/1
11:20:04.313: RSTP(1): transmitting a proposal on Gi1/0/2
11:20:04.313: RSTP(1): transmitting a proposal on Gi1/0/3
11:20:04.314: RSTP(1): received an agreement on Gi1/0/2
11:20:04.315: RSTP(1): received an agreement on Gi1/0/3
Read it from top to bottom: better BPDU → new root port → sync (block the ports below) → agreement sent up → proposals sent down → agreements come back. All in about 3 milliseconds.
Example output · based on Cisco documentation; exact format varies by platform and software version
E#debug spanning-tree events
11:20:04.316: RSTP(1): updt roles, received superior bpdu on Gi1/0/1
11:20:04.316: RSTP(1): Gi1/0/1 agree (allSynced)
11:20:04.317: RSTP(1): updt roles, received superior bpdu on Gi1/0/2
11:20:04.317: RSTP(1): Gi1/0/2 is now alternate
11:20:04.317: RSTP(1): transmitting an agreement on Gi1/0/1
The last switch agrees on its root port, and makes the second link alternate. The whole network settled in a few milliseconds. Classic STP would have needed 30–50 seconds.

Who sends what

Port roleSends proposals?Sends agreements?Why
Designated (discarding or learning)YesNoIt wants to forward, so it asks the switch below for permission
RootNoYesIt receives the best BPDU, and answers after syncing
Alternate / backupNoNoThey stay blocked, so there is nothing to agree
EdgeNoNoForwards at once. Sync doesn't touch it.

Sometimes a switch gets a proposal it doesn't agree with. For example, its own BPDU is really better. Then it doesn't send an agreement. It sends its own proposal instead, and the roles are decided the other way round. If no agreement ever comes back, the port goes the slow way: one forward delay in discarding, then one in learning.

When the handshake can't be used

  • Shared (half-duplex) links: there may be more than one switch on the segment, so RSTP goes back to using timers.
  • A neighbour running classic STP: it doesn't understand proposals, so that port works the old 802.1D way.
  • No PortFast on ports to end devices: sync blocks them as if they led to switches, and they must go through discarding and learning. This is another reason to set PortFast.

Check yourself

Predict · scenario 1

During sync, which of SW2's ports are moved to discarding?

Predict · scenario 2

Which flag does the downstream switch send back to allow fast forwarding?