What happens when there is a topology change?
In a normal layer2 network, BPDU Hello packets are sent every 2 seconds. With every BPDU received each switch will re-evaluate their topology. Should a topology change occur the switch first needs to establish if the root-bridge has changed.
Consider the following diagram:
Here Switch 1 is the Root-Bridge because it has the lowest priority. Switch 4 chooses to make fa0/2 the Root-Port because this is the lowest cost back to the Root-Bridge. Now consider what happens if the link between Switch 1 and Switch 2 fails:
Switch 2’s Root-Port will go down, and consequently, it needs to determine a new Root-Port. However Switch 2 is not receiving any BPDUs from Switch 4, so it then considers itself to be the Root-Bridge and floods hello BPDUs out of all its connected ports (in this case just fa0/4).
Switch 4 receives BDPUs from Switch 2 on fa0/2, but it has already stored the original BPDUs it received from Switch1 (before it lost visibility). However, the new BPDUs from Switch 2 are inferior (the bridge-ID is higher at 32768) so Switch 4 will wait until the original BPDUs expire. During this time Switch 4 doesn’t send any BPDUs to Switch 3.
Switch 3 therefore no longer receives BPDUs on its fa0/4 port, which is currently a Root Port. Fa0/4, therefore, becomes a Designated Port. SW3 then searches for a new Root Port by looking for the superior received BPDUs, ultimately choosing fa0/1. It will then forward Switch 1’s Hello’s BPDUs out of its fa0/4 port.
Switch 4 will receive BPDUs on fa0/3, and it will see these are superior to the BPDUs it had previously received from Switch 2. Consequently, fa0/3 will become the Root Port, and fa0/2 will become the designated port. Switch 4 will then relay BPDUs out of fa0/2 to Switch2.
After SW2 receives the forwarded Hello from SW4, it will also learn about SW1 being a better Root Bridge than itself. Therefore, SW2 will stop considering itself as the Root-Bridge and will instead declare its fa0/4 port as the Root Port, finally converging on the new topology.
Moving from Blocking to Forwarding
When a layer 2 network converges to a stable topology, some ports may become Root Ports, and some, Designated Ports. Both will need to be in the forwarding state. However, moving from blocking to forwarding immediately risks loops occurring. Instead, a blocked port must enter a Listening state, followed by a Learning state. The following table summarised the different 802.1D port states:
Topology Change Notification
When a frame is received by a switch it adds an entry in the MAC address table associating the frame with a port number. This way the switch knows which hosts are available through which ports. If the host is not heard of again, it will be timed out of the MAC address table after 300 seconds (five minutes). However, this can cause problems in a switched network when there is a topology change. This is illustrated in the following network:
In this network, the link between Switch 1 and Switch 4 is blocked by STP. Therefore traffic from Host A to Host B goes via Switch 1, Switch 2, Switch 3 and Switch 4.
If the link between Switch 2 and Switch 3 were to fail, then switch 1 will need to unblock the link directly to Switch 4. With legacy 802.1D STP this can take up to 50 seconds. However, when Host A wants to send a frame to Host B, Switch 1 will have a MAC table entry that says this host is via Switch 2. This will not age-out for five minutes, leading to traffic being blackholed until the MAC table entry changes.
The Topology Change Notification (TCN) is used to resolve this problem. As soon as a topology change occurs, it is advertised to the whole switched network. Each switch will then reduce their MAC ageing time temporarily to 15 seconds, meaning the MAC entry pointing to Switch 2 will be timed out more quickly.
In order to notify the entire network of a change a switch will need to inform the Root-Bridge and the Root-Bridge will then update all the other switches. In normal operation, a switch only receives BPDUs from the Root-Bridge on the Root-Port, and never sends BPDUs to the Root-bridge. Only the TCN BPDU can be sent on the Root-Port towards the Root-Bridge. The next switch upstream acknowledges the TCN and then sends its own TCN upstream towards the Root Bridge, until the Root bridge is reached, as illustrated below:
Once the Root-Bridge is aware of the topology change it will send out BDPUs with the (TC) bit set. Each switch receives these BPDUs and sets its MAC ageing timer down to 15 seconds.
The higher the number of hosts in a network the higher the number of topology changes. With a large layer 2 network, this can result in the network constantly changing topology. A simple host being switched-on can cause a topology change. The exact rules for sending a TCN are:
- When a port that was forwarding goes down (e.g. blocking, or disconnection)
- When a port transitions from learning to forwarding, and the switch has a designated port (in other words it is not a standalone switch)
Using portfast causes a port to immediately transition to forwarding, and consequently does not trigger a TCN notification. This should be configured for all host connections and reduces the number of topology changes in the network.
Should a link start flapping, and cause a lot of TCN notifications to be generated it is useful to be able to track the source of the notification. With standard cisco IOS this can be achived with the command:
Switch#show spanning-tree vlan <vlan-number> detail
e.g. the following vlan shows a high number of topology changes from Gi0/22. To find the source of the problem, you issue the same command on the switch connected to gi0/22 until you reach the source.
switch-1#show spanning-tree vlan 1 detail VLAN0001 is executing the ieee compatible Spanning Tree protocol Bridge Identifier has priority 32768, sysid 1, address 001e.1489.c400 Configured hello time 2, max age 20, forward delay 15 Current root has priority 24577, address 001e.f6bc.bc80 Root port is 24 (GigabitEthernet0/24), cost of root path is 4 Topology change flag not set, detected flag not set Number of topology changes 874615 last change occurred 2d ago from GigabitEthernet0/22 Times: hold 1, topology change 35, notification 2 hello 2, max age 20, forward delay 15 Timers: hello 0, topology change 0, notification 0, aging 300
The Traceroute Blog 