Under RSTP, how does the proposal/agreement handshake bring a designated port to forwarding without timers, and what does the sync step do?
answer
- ask first, then open
- secure downstream before agreeing
- non-edge designated ports discard
- only on point-to-point links
- the wave moves outward
basics
~20 sAn RSTP designated port on a point-to-point link proposes; the neighbour syncs by putting its other non-edge designated ports into discarding, then agrees, and the proposing port forwards at once because no loop can pass through the neighbour.
solid answer
~50 sOn a **point-to-point** link, an RSTP designated port that is not yet forwarding sends BPDUs with the **proposal** flag set. If the neighbour accepts that information as its best path to the root, the receiving port becomes its root port and the neighbour runs **sync**: every non-edge designated port that is forwarding is moved to `discarding`, while alternate, backup and already-discarding ports are in sync as they are and **edge ports** keep forwarding. With nothing else open toward other bridges, the neighbour answers with an **agreement**, and the proposing port goes straight to `forwarding`, because no loop can now pass through the neighbour. The neighbour's own designated ports then propose to their neighbours, so the handshake ripples outward to the edge. If no agreement comes back, on a shared segment or toward an 802.1D-only bridge, the port falls back to Forward Delay timing.
go deeper
Recall that RSTP asks the neighbouring switch before opening a port, using a proposal and an agreement, instead of waiting out timers.
Explain sync: which ports go to discarding, which are left alone and why, and why the agreement may only be sent after that.
Diagnose slow ports by the conditions the handshake needs: full-duplex links, RSTP on the neighbour, and host ports marked edge, since an unmarked host port waits on timers.
Judge the handshake's limit: it makes each link fast but still briefly disturbs everything downstream on every change, which is part of the argument for smaller layer-2 domains.
## Why classic spanning tree waits Under classic **802.1D** spanning tree, a port that should become designated cannot know whether opening it would create a loop somewhere downstream, so it waits: it spends Forward Delay listening and Forward Delay learning before it forwards. The wait gives the whole network time to hear about the change. **RSTP** (IEEE 802.1w, now 802.1D-2004) replaces that wait, link by link, with an explicit question to the neighbour. ## The handshake, step by step Take distribution switch **D1**, the root bridge, and access switch **S3**, which has a second uplink to **D2**. A new full-duplex link between D1 and S3 comes up. 1. Both ends start as **designated** and `discarding`. D1's port sends BPDUs with the **proposal** flag set: "I want to forward on this link." 2. S3 sees that D1 offers a better path to the root than anything it had, so the port facing D1 becomes S3's **root port**. 3. S3 runs **sync**. Before it may agree, it makes sure no other path out of S3 is open toward another bridge: - every **non-edge designated port** that is forwarding goes to `discarding`; - **alternate** and **backup** ports are already discarding, so they are in sync as they are; - **edge ports** facing hosts are left forwarding, because a host cannot close a loop. 4. S3 sends a BPDU with the **agreement** flag out of its new root port, and that port moves to `forwarding`. 5. D1 receives the agreement and moves its designated port to `forwarding` **immediately**, with no timer. 6. S3's designated ports, now discarding, send proposals to *their* neighbours, and each neighbour repeats steps 2 to 5. The result is a wave that moves outward from the root. Each link opens as soon as the bridge behind it has closed its own onward links, so at no moment is a loop open. | Port on S3 during sync | What sync does | Why | |---|---|---| | new root port (toward D1) | becomes forwarding after the agreement | it is the path being accepted | | non-edge designated, forwarding | moved to `discarding` | could lead to a loop through another bridge | | alternate or backup | already `discarding` | in sync as it is | | edge port (host) | left forwarding | a host cannot close a loop | ## The conditions the speed depends on - **Point-to-point link.** An agreement from one neighbour proves nothing if other bridges share the segment, so the handshake runs only on point-to-point links. RFC 4318 restates the IEEE rule: in `auto` mode a port counts as point-to-point when its MAC runs **full duplex**, or when it is an aggregator whose members are all aggregatable; an administrator can force the value either way. - **An RSTP neighbour.** A bridge that speaks only 802.1D never sends an agreement. The port then walks `discarding` to `learning` to `forwarding`, each step lasting **Forward Delay**, exactly as classic spanning tree would. - **Edge ports set correctly.** Sync spares only ports that are edge ports. A host port that is *not* marked edge counts as a non-edge designated port, so sync blocks it, and since a host never answers a proposal it comes back on the timed path, unless the switch detects it as an edge port by itself (802.1D-2004 allows that after a few seconds without BPDUs; RFC 6620 cites a minimum of three seconds). ## What edge ports have to do with it An **edge port** is a port the administrator declares to face end stations. It goes to `forwarding` as soon as the link is up and is left alone by sync. The protection is built into the protocol: RFC 4318 states that the operational edge status "will also be changed to false on reception of a BPDU", so a switch plugged into an edge port is detected and the port rejoins the tree as an ordinary port. Turning a BPDU on an edge port into a shutdown is a separate guard feature, not part of the handshake. ## A sketch of the receiving side ```pseudocode on BPDU with proposal arriving on port P: if P's information is the best path to the root: role(P) = root for each port Q other than P: if role(Q) == designated and not edge(Q) and state(Q) != discarding: state(Q) = discarding # sync send BPDU with agreement on P state(P) = forwarding for each port Q with role designated and not edge(Q): send BPDU with proposal on Q # the wave continues ``` ## Common misreadings - Sync does **not** block the whole switch; edge ports and the new root port keep or gain forwarding. - The agreement is sent **after** sync, never before; agreeing first would open the loop the handshake exists to prevent. - The speed does **not** come from shorter timers; the timers keep their values and are simply not needed on point-to-point links between RSTP bridges.
- Why doesn't sync cause a long outage across the downstream switches?Sync blocks only non-edge designated ports, and each of those immediately sends its own proposal. Between RSTP bridges on point-to-point links the agreements come straight back, so the discarding wave moves outward and closes behind itself in a few BPDU exchanges. Edge ports facing hosts keep forwarding throughout; only a neighbour that never agrees holds its segment on timers.
- What makes a port point-to-point if nobody configures it?RFC 4318 mirrors the IEEE rule: the administrative value can force it true or false, and in auto mode a port is point-to-point when its MAC runs full duplex, or when it is an aggregator whose members are all aggregatable. A half-duplex port counts as shared, so it never uses the handshake and always reaches forwarding on timers.
It is like a water network where the supply valve into a junction may open only after that junction has shut every outlet leading on to other junctions; taps at sinks stay open, since they lead nowhere further.
saying these in an interview costs you the question
- RSTP brings ports up fast by shortening the Forward Delay timer.
- During sync the switch also blocks its edge ports facing hosts.
- The proposal/agreement handshake works on shared half-duplex segments too.
- The downstream switch sends its agreement first and syncs its ports afterwards.
- A host port not marked as edge is spared by sync anyway.