Introduction
After several posts talking about classic STP, finally we are arriving to some modern use of the STP. Nowadays everybody would use RPVST+ or MST.
There are several advantages of use Rapid STP:
- First, it’s backwards compatible with classic PVSTP+
- Second, it’s extremely fast to converge
- Third, it incorporates by default several PVSTP+ advanced features
And probably a few more that we will be covering in the next paragraphs!
New port roles
We are already familiar with Root ports and Designated ports now additionally we have Alternate and Backup ports.
Root port: Best BPDU received on that port, lowest cost to root.
Designated: Best BPDU send downstream in the segment.
Alternate: Think as if it was a backup for the root port, less desirable than root port.
Backup: Think as if it was a backup for a Designated port. Normally can be seen if you have a hub.
Here in the diagram we have a backup port because in a shared segment(hub) we will see our own ports BPDU, making an alternative path into a Designated port.
Simplified port status
If you remember PVSTP had 5 status: Disabled, Blocking, Listening, Learning and Forwarding.
However, in RPVST+ this list was simplified into just 4: Disabled, Discarding, Learning and Forwarding. Note how listening disappeared.
*In fact, disabled is not an official state, it is just a way of naming a shutdown / disconnected interface.
Operation: how it works
They key factor for the speed of the RPVSTP+ is not about hello timers or anything of the sort. Speed is related with a new method of convergence called synchronization or sync for short.
Another thing to know about RPVSTP+ is that now all bridges will generate a hello BPDU.
On the contrary, classic PVSTP+ only the root generates BPDUs and other switch will just pass it through their ports.
If we look inside the RPVSTP+ hello BPDU we will see also something that was not present in the classic STP hellos, now the port role it is included inside.
That, combined with every switch sending hellos means that every switch knows about each other ports in advanced!
Convergence steps are the same as PVSTP+ as you know:
First, select a root switch per vlan.
Second, choose a single root port per switch.
Third, find the designated ports. One per segment.
Finally, block everything else.
Indeed, the steps are the same, just much faster. It could converge under a second thanks to the syn process.
Once thing to reiterate is that we don’t use max-age of 20 seconds as with classic PVSTP, we use as a holdtime 3 x hello. So after 6 seconds we would consider a neighbor down if we don’t receive hellos.
This is very important for convergence, as if you have end host ports without spanning tree edge mode(Portfast) those ports will experience a 36 seconds at least convergence. We will wait 6 seconds as holdown, then 15 in discarding (sending proposals through the non-edge ports) and another 15 seconds during Learning just before forwarding.
Note: if a RPSTP+ switch receives a classic PVSTP+ BPDU from a port, that port will fallback into classic PVSTP+ timers / behaviour.
Synchronization Process
Briefly I want to mention that RPVSTP+ includes the advanced PVSTP+ Uplinkfast and Backbone fast already inside its DNA.
It’s not exactly the same behind the scenes(for example, no RLQ like Backbonefast classic PVSTP+), but the result is the same:
- Uplinkfast in RPVSTP+ is achieved with Alternate ports. These ports are an alternative path to the root and will go FWD immediately if the main root port fails.
- BackboneFast in RPVSTP+ is achieved by switches accepting immediately inferior BPDUs and starting the syn process instead of waiting max-age timer which was the classic PVSTP+ behaviour.
Additionally, two new flags were added into the hello packets. Proposal and Agreement.
Proposal: “I want to move this port A into Designated; do you agree?”
Here we can have two possible answers:
- If the other end of port A sends a superior BPDU, there is no agreement. Port A will become a root port instead.
- If the other end of port A sends an inferior BPDU, it will agree that the other end will become Designated.
Like in normal convergence, to decide which side will be DP would depend on who has a superior BPDU.
When a switch sees a hello with the proposal bit set, it will put all their non-edge (non Portfast) ports into discarding and will send proposal to other neighbors. Thus, the proposal “wave” will go downstream until the switch sees the Agreement coming from downstream. Alternate ports will go into FWD immediately if the main root port is lost.
Sync process go downstream using the designated ports, root ports won’t send proposals upstream.
Once we have an Agreement, we will unblock that port and move it into Root or Designated, depending if the BPDU received is superior or inferior.
Another example of sync process:this time showing clearly how a SW will block all non-edge/non-root during the Proposal / Agreement:
Phase 1: Link fails, and we start the sync process. Note that the RPC (root path cost) shown is before the failure!
Phase 2: Agreements are sent back, or not agreement. Hence many port changes happened due to the RPC changes after failure.
Remember that RPC takes precedence over anything else for the hierarchy of the Designated and root ports.
This is the most important part to understand about RVPSTP+, the sync process is they key of its sub second convergence.
Note: sub second convergence would happen with small topologies, if you have a bigger topology or a ring topology it will go slower as the sync waves have to go further away.
As I mentioned earlier, now we have maximum of 3 x hellos to declare a neighbor down(if the physical links would detect it, will be much faster), so worst case scenario would be 6 seconds to start to reconverge. In RPVSTP we don’t use max-age as a hold timer, but as hop count.
Enable portfast on access ports
The main problem with synchronization and Portfast is that if we don’t enable Portfast in the edge ports connected to host, STP will send proposal to the end host that won’t understand anything. That will cost us more than 36 seconds if the root dies.
In the next drawing, all switches are running RPVST+, but we forgot to enable Portfast (edge ports) in the ports facing the end host PCs.
Now, we ping from PC1 to PC2 and traffic flows as such, following the green arrow. Life is good!
However, Root switch dies and a new election is necessary. SW1, SW3 and SW4 very fast will send Proposal/Agreement but SW3 and SW4 also will send proposal over eth0/0 which are non-edge ports; waiting for a reply. End host don’t understand STP, so they won’t reply.
Due to the sync process, SW3 and SW4 will block all their non-edge ports, waiting for an agreement from the end host side(which won’t happen) Ports facing end host will be blocked for 30 seconds.
Without Portfast, at least 30 seconds will have to elapse for the non-edge ports to come up, going through Discarding and Learning phases.
Now remember, if we enable Portfast into the edge ports; STP won’t try to sync over those ports. They will remain up and the switches will converge under a second.
Very important to set end host ports as edge ports!!!
Topology changes: Tell me what’s new
Once more RPVSTP+ simplifies things, a change now is defined as: “A non-edge port going into forwarding”. Simple enough. Portfast ports do not count as a change.
For classic PVSTP a change was defined both as a port going into forwarding or blocking (as well as root changes).
The improvement is in the thinking behind this: “If a port down does it really change anything? Well, no”. However, a port becoming forwarding is much more dangerous and has to be tracked thoroughly.
When a link become forwarding, then is when the switch will generate a BPDU with a bit marking the Topology Change. That BPDU will go upstream using the Root port and also will be flooded through all designated ports; until all switches will get that message that a changed happened.
Every switch upon receiving this BPDU with the TC bit set, will immediately flush its MAC table(except from the port where it received the TC message)
Switches will keep flooding through all its ports the same message during 2 x hello timer (named tcWhile timer).
After this timer is expired, that switch will stop flooding BPDUs with the TC(Topology Change) bit set. We are finished now!
References
Between the resources I used to document this post are:
https://nwktimes.blogspot.com/2017/10/rapid-per-vlan-spanning-tree-protocol.html –> excellent resource for RPVSTP+ sync
https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24062-146.html#anc20
CCIE v5 Routing and Switching book.
Conclusion
This was the last part for STP, as we already covered classic PVSTP+, advanced PVSTP+ features and now finally we took a look into RPVSTP+.
If you are interested in MST/MSTP you can check my other post where I talk long about it.
Any thoughts?
Recent Comments