So once spanning-tree has done its initial build, we need to talk about what happens when the topology changes. This happens any time that a port goes forwarding or goes down. For instance, if I plug my laptop into a port on switch4, this is what I see happening…
The black line is switch4 sending switch3 (the root) a TCN (Topology Change notification) out of it’s root port toward the root bridge. Each switch along the path to the root will send a TCA (Topology Change ACK) back to the switch that sent the TCN, and then send it’s own TCN out it’s root port. The process continues until the TCN reaches the root bridge. Once notified, the root bridge begins to send out BPDUs that have the the TC (Topology Change) flag set…
Upon receipt of a TC BPDU, all other switches know to age out their MAC tables and begin relearning the MAC addresses of their connected devices.
So what I find interesting about this is that you really have two different mechanisms at play. One is to determine the spanning-tree topology, and the other is to ensure that the CAM tables stay updated. So what if I plug a new switch into switch1 that has the command ‘spanning-tree vlan 1 root primary’ on it? The instant that switch 1 hears the superior BPDU it will automatically start forwarding the superior BPDU out of all of it’s forwarding interfaces and all of the other switches will elect it as the new root, pick new root ports, and pick new designated ports. This will all happen before the ports between the new switch and the switch1 even go into a forwarding state. Once that happens, switch1 will send the TCN which will tell the other switches to age out their CAMs.
I feel like this is better described in a drawing, so let’s look at a new topology and see what happens…
Now, let’s configure switch4 to the be the root for vlan 1, then plug it into switch1. Here’s what happens…
The instant the cable is plugged in between switch1 and switch4, switch1 hears switch4’s superior BPDU. Switch1 kicks it’s previously blocking interface into listen mode as well as the interface toward switch4. Since the interface toward switch2 is in listen mode, it forwards the superior BPDU directly to switch2. Switch3 also receives a copy of the superior BPDU.
Both switch2 and switch3 immediately update their root ports and determine the designated ports. Since switch2 set one of it’s ports to blocking, it also forwards a TCN out of it’s root port towards the root. In the meantime, switch1 works its two listening ports through the listen, learn, and forward phases.
Once switch1 transitions it’s port to forwarding, it sends the root 2 TCNs, one for each port that transitioned to the forwarding state. The final topology looks like this…
So there you have it, that’s a full reconvergence event. There is one last point I wanted to make. The topology change process can be a little cumbersome and cause some layer 2 problems if you aren’t aware of how it functions. Take for instance, an access layer MLS (a 6500 stacked full of 6748 line cards) that have servers plugged into each and every port. Now consider one of the servers is stuck in a reboot loop. Every time it reboots, the NIC goes up and comes back down. When that happens, a TCN is generated and all of the switches are told to age our their CAMs and relearn. This can be a real problem. The solution to this is to define certain ports as spanning-tree ‘edge’ ports. This is done by configuring the spanning-tree ‘portfast’ function on the interface. This essentially turns spanning-tree off on the specific port and puts the interface directly into forwarding mode.
Generally speaking, you should be able to define the following commands on your MLS provided that you have trunks defined for ports that should be trunking…
spanning-tree portfast default
spanning-tree portfast bpduguard default
These will only apply to access ports (non-trunking) and should fix the TCN problem.
Next up is RSTP(802.1w) and MST(802.1s)!