1. Topology Change Notification (TCN): When a switch detects a change (e.g., a port transitions from a blocking to a forwarding state), it sends a Topology Change Notification (TCN) BPDU upstream to the root bridge. This informs the root bridge that there's a change in the topology.
2. Root Bridge Updates: Upon receiving the TCN, the root bridge generates a new BPDU to inform all other switches of the change. This BPDU contains updated information about the network's topology.
3. Switch Responses: Non-root switches receiving the TCN will update their MAC address tables and may need to transition their ports. They will also start a timer known as the "max age" timer, which is set to 20 seconds by default. During this time, switches will not learn new MAC addresses but will still forward BPDUs.
4. Port State Transitions: The affected ports will transition through the various STP states - listening, learning, and finally forwarding - based on the new topology. This process helps to stabilize the network and ensures that data flows efficiently throughout.
5. Timers: STP uses timers (forward delay and mas age) to manage the state transitions of ports. By default, it takes about 50 seconds for a port to transition from blocking to forwarding after a topology change occurs.
Let's illustrate this example:
Imagine you have a network with three switches (SW1, SW2, and SW3, respectively), connected in a loop. If the link between SW1 and SW2 goes down, SW3 will detect that change and send a TCN to the root bridge (SW1, in this case). The root bridge will then update its information and send a new BPDU to the other switches. SW2 will receive this and will re-evaluate its port states to either forward or block accordingly, thus maintaining a loop-free technology.
This process ensures that your network remains stable and has the ability to adapt to changes dynamically, minimizing downtime and disruption.
Let's have a look at the following network topology for this scenario, so I can explain a couple of things:
In the following network topology above, we have several switches in the mix (SW1, SW2, SW3, and SW4) connected in a way that includes redundancy. Here's how we can summarize the current state based on our configurations:
SW3(config)#spanning-tree vlan 1 priority 4096SW2(config)#interface fa0/19
SW2(config-if)#spanning-tree cost 50To ensure that SW3 becomes the root bridge and that the Fa0/19 interface on SW2 is blocked, we've configured SW3 with a lower bridge priority. Let's summarize the expected state of the interfaces across the switches based on this setup:
SW1#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/14 Desg FWD 19 128.16 P2p
Fa0/16 Root FWD 19 128.18 P2pSW2#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/2 Desg FWD 19 128.4 P2p
Fa0/14 Root FWD 19 128.16 P2p
Fa0/19 Altn BLK 50 128.21 P2pSW3#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13 Desg FWD 19 128.13 P2p
Fa0/19 Desg FWD 19 128.19 P2pSW4#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/4 Desg FWD 19 128.4 P2p
Fa0/16 Desg FWD 19 128.16 P2p
Fa0/19 Root FWD 19 128.19 P2pExplanation of the States
- SW3 as Root Bridge: By configuring SW3 with a lower bridge priority (4096), it has been successfully elected as the root bridge. This means all of its ports are in the forwarding state.
- Blocked Port on SW2: The Fa0/19 port on SW2 is blocked to prevent a loop. Since SW2 has multiple connections to the root bridge, the port with the higher cost (Fa0/19) is put in a blocked state.
- Designated Ports: Other ports on SW1, SW2, SW3, and SW4 that lead to the root bridge or to other switches are in the designated forwarding state, allowing for proper data flow without loops.
Why This Setup?
This configuration ensures there is a reliable and loop-free topology while maintaining redundancy. If the active path fails, STP can react by transitioning the blocked port of forwarding state, allowing for continued connectivity. Here we have all the different interfaces in this topology below:
Let's generate some traffic that allows the switches to learn the MAC addresses of the computers
C:\Documents and Settings\H1>ping 192.168.1.2
Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.1.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0msA simple ping will generate some frames, and the switches will learn the MAC addresses.
In my case, these are the MAC addresses for the computers in my network:
- H1: 000c.2928.5c6c
- H2: 000c.29e2.03ba
SW1#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/14
1 000c.29e2.03ba DYNAMIC Fa0/16SW2#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/2
1 000c.29e2.03ba DYNAMIC Fa0/14SW3#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/13
1 000c.29e2.03ba DYNAMIC Fa0/19SW4#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/19
1 000c.29e2.03ba DYNAMIC Fa0/4We can verify the traffic path by checking the MAC address table. I prefer using the show mac address-table dynamic command, as it allows us to focus on dynamic MAC addresses without sifting through static entries.
Do you know how long a switch typically retains a MAC address?
SW1#show mac address-table aging-time
Global Aging Time: 300If we examine one of the switches, we can check the default aging time for the MAC address table, which is set to 300 seconds (5 minutes) by default. If a host doesn't send any traffic for 5 minutes, its MAC address will be removed from the table.
So, why is aging time so important? Let me show you!
C:\Documents and Settings\H1>ping 192.168.1.2 -tFirst, I'll generate some continuous traffic from H1 to H2 by using the command ping -t, which will keep sending pings indefinitely.
Next, I'll unplug one of the cables to see how the network responds.
If the link between SW1 and SW3 fails, H1 and H2 will be unable to communicate until the Fa0/19 interface on SW2 transitions to the forwarding state. This process can take up to 50 seconds, as SW2 will move through the states of blocking, listening, learning, and finally to forwarding.
During this time, SW2 still has H2's MAC address in its table and will continue to forward traffic to SW1, where it will be dropped. As a result, communications between H1 and H2 will be disrupted for a maximum of 300 seconds until the MAC address tables age out.
Sending Ethernet frames to a place where no frame has gone before doesn't sound like a good idea if you want to keep your users happy.
While the 300 second aging time for MAC address tables works well in a stable network, it can cause issues when the topology changes. Fortunately, STP has a topology change mechanism to address this.
When a switch detects a network change, such as an interface going down or transitioning to a forwarding state, it sends a notification to the entire switched network. This message is known as a Topology Change Notification (TCN).
Upon receiving the TCN, switches will reduce the aging time of their MAC address tables from 300 seconds to 15 seconds (the forward delay timer).
To dig deeper into how TCNs function, we'll need to do some debugging.
SW1#debug spanning-tree events
Spanning Tree event debugging is onSW2#debug spanning-tree events
Spanning Tree event debugging is onSW3#debug spanning-tree events
Spanning Tree event debugging is onSW4#debug spanning-tree events
Spanning Tree event debugging is onI'm going to enable debug spanning-tree events on all switches so you can observe this process in action.
Next, I'll shut down the Fa0/16 interface on SW1 to simulate a link failure.
SW1(config)#interface fa0/16
SW1(config-if)#shutdownHere is what you will see:
SW1#STP: VLAN0001 sent Topology Change Notice on Fa0/14Here, you'll notice quite a bit of debug information, but among it, you should see that SW1 generates a Topology Change Notification (TCN) and sends it out through its Fa0/14 interface to SW2.
On SW2, you might see output similar to this:
SW2#STP: VLAN0001 Topology Change rcvd on Fa0/14SW2 will generate a lot of debug output, but the key information to focus on is that it has received the TCN from SW1. Upon receiving this TCN, SW2 will then adjust its MAC address table's aging time to 15 seconds.
Here's what SW2 will do with this information:
1. Aging Time Adjustment: SW2 will reduce the aging time for its MAC address table time entries from the default 300 seconds to 15 seconds. This allows it to quickly discard outdated MAC addresses that may no longer be valid due to the topology change.
2. Forwarding Decisions: SW2 will begin to monitor traffic more closely, ensuring that it forwards frames to the correct ports as the network topology stabilizes.
3. Flooding: If SW2 needs to forward frames to a MAC address that it hasn't yet learned (because the relevant MAC entry has aged out), it may flood the traffic out of all ports except the one it received the traffic on.
4. TCN Propagation: SW2 may also propagate the TCN to other switches in the network to ensure they also adjust their MAC address aging timers.
The output should look similar to this:
SW2#STP: VLAN0001 new root port Fa0/19, cost 69
SW2#STP: VLAN0001 Fa0/19 -> listening
SW2#STP: VLAN0001 Topology Change rcvd on Fa0/14
SW2#STP: VLAN0001 sent Topology Change Notice on Fa0/19
SW2#STP: VLAN0001 Fa0/19 -> learning
SW2#STP: VLAN0001 sent Topology Change Notice on Fa0/19
SW2#STP: VLAN0001 Fa0/19 -> forwardingSW2 identifies that Fa0/19 is now the new root port. You'll observe the transition process as it moves from listening to learning, and finally to the forwarding state. This transition is critical for reestablishing communications through the new path.
Additionally, SW2 will send a TCN to SW4, notifying it of the change in the network topology. This helps to ensure that SW4 can also adjust its MAC address table and respond appropriately to the changes.
You should see debug output reflecting these transitions and the TCN being sent, such as:
SW3#STP: VLAN0001 Topology Change rcvd on Fa0/19SW3 receives a TCN on its Fa0/19 interface and will reduce its age-out timer of the MAC address table to 15 seconds.
SW4#STP: VLAN0001 Topology Change rcvd on Fa0/16
SW4#STP: VLAN0001 sent Topology Change Notice on Fa0/19We can see that SW4 receives the TCN from SW2, which prompts it to reduce its MAC address table's aging time to 15 seconds. SW4 will then send a TCN to SW3.
As a result, all switches in the network receive the TCN and adjust their aging timers accordingly. Since SW2 does not receive any Ethernet frames with H2's MAC address as the source on its Fa0/14 interface during this time, it will eventually age out that entry from its MAC address table.
You might see debug messages on SW4 like:
SW4#STP:*Mar 1 00:00:06.000: STP: TCN received from SW2
SW4#STP:*Mar 1 00:00:07.000: STP: Aging time reduced to 15 seconds on MAC address table
SW4#STP:*Mar 1 00:00:08.000: STP: Sending TCN to SW3
Meanwhile, the Fa0/19 interface on SW2 transitioned from blocking to listening, learning, and finally to forwarding taking a total of 50 seconds. SW2 will now learn the MAC address of H2 on that interface, restoring connectivity.
Similarly, SW4 will learn the MAC address of H1.
Are you following along? To sum it up, we need the TCN to reduce the MAC address table aging time from 300 seconds to 15 seconds. The helps prevent traffic from being blackholed in situations like the one we've just discussed.
Now, which switches send and forward the TCN? In the previous debug output, you saw some messages, but where are they sent, and why? Are the flooded to all switches? Let's explore that!
In a typical scenario, a non-root switch receives Bridge Protocol Data Units (BPDUs) on its root port but does not send BPDUs to the root bridge. When a non-root switch detects a topology change, it generates a TCN and send it out its root port toward the root bridge.
Upon receiving the TCN, the switch will respond by sending a Topology Change Acknowledgement (TCA) on its designated port to the downstream switch. It will also generate its own TCN and send it out its root port, propagating the notification up the tree until it reaches the root bridge.
Now, regarding the message used for the TCN, take a look at this BPDU:
You can see that the BPDU has a field called "BPDU type." This value will change to indicate that it's a TCN.
Once the TCN reaches the root bridge, the root bridge will set the TC (topology change) bit in the BPDUs it sends out. This indicates to all switches in the network that a topology change has occurred, prompting them to adjust their MAC address aging timers accordingly. By setting the TC bit, the root bridge ensures that all downstream switches are aware of the change(s) and can react appropriately to maintain network stability.
These BPDUs will be forwarded to all other switches in the network, allowing them to reduce the aging time of their MAC address tables. Switches will receive these messages on both forwarding and blocked ports.
The root bridge will send out BPDUs with the TC bit set in the flag field to indicate a topology change. This informs all switches in the network that they need to take action to adjust their MAC address aging timers and ensure stable communications in light of the TC.
That, in a nutshell, my friends, is how STP handles topology changes in a network. Now, there's one more aspect of this mechanism I want to point out. Please take a look at the following illustration below:
As you can see, H1 is connected to SW2 on its Fa0/2 interface. Now, let's observe what happens when this interface goes down.
When the Fa0/2 interface on SW2 goes down, the following sequence of events will first occur:
1. Link Failure Detection: SW2 will detect that the link to H1 is down. This will trigger the STP to recognize a topology change (TC).
2. Topology Change Notification (TCN): SW2 will generate a TCN and send it to the root bridge, indicating that a device is no longer reachable.
3. Propagation of TCN: The root bridge will receive the TCN and set the TC bit in its BPDUs. It will then forward these BPDUs to all other switches in the network.
4. Adjustment of Aging: Upon receiving the BPDUs with the TC bit set, all switches will reduce the aging time of their MAC address tables from 300 seconds to 15 seconds.
5. MAC Address Table Update: SW2 will eventually age out the MAC address of H1 from its MAC address table, as it will no longer see traffic from that device.
SW2#show spanning-tree interface fa0/2
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg FWD 19 128.4 P2pWe can see that the Fa0/2 interface on SW2 is designated and forwarding. Let's enable a debug and shut this interface down:
SW2#debug spanning-tree events
Spanning Tree event debugging is onSW2(config)#interface f0/2
SW2(config-if)#shutdownNow, this is what happens on SW2:
SW2 STP: VLAN0001 sent Topology Change Notice on Fa0/14Right after shutting down, the Fa0/2 SW2 generates a topology change notification and sends it away on its root port.
Let's bring it up again:
SW2(config)#interface f0/2
SW2(config-if)#no shutdownThis is what you should see:
SW2# STP: VLAN0001 Fa0/2 -> listening
SW2# %LINK-3-UPDOWN: Interface FastEthernet0/2, changed state to up
SW2# %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2, SW2# changed state to up
SW2# STP: VLAN0001 Fa0/2 -> learning
SW2# STP: VLAN0001 sent Topology Change Notice on Fa0/14
SW2# STP: VLAN0001 Fa0/2 -> forwardingOnce we bring the interface back up, it will go through the listening and learning states before reaching the forwarding state again. The switch will then generate another TCN and send it out on the root port.
However, this can lead to some potential issues. Imagine a network with a large number of hosts: each time an interface goes up or down, a TCN will be generated, prompting all switches to reset their aging timers to 15 seconds. If many hosts are frequently connecting or disconnecting, the network could end up in a constant state of "topology changes."
Here's a possible scenario to consider that can occur:
1. Frequent TCNs: If multiple hosts are rapidly connecting and disconnecting, each event will trigger a TCN. This can lead to an unnecessary flood of notifications throughout your network.
2. Increased Overhead: As switches continually adjust their MAC address tables, the overhead obviously increases, which, in turn, can consume CPU resources and bandwidth.
3. Instability: The constant resetting of aging timers may lead to instability, where switches may become unable to maintain accurate MAC address information, causing an accessory attack path vector and delays in packet delivery or even packet loss, which may become exploitable at that point.
4. Blackholing Traffic: With frequent aging out of MAC address, legitimate traffic may be dropped because switches do not have the necessary MAC address table information.
In the diagram above, a server is sending a backup to a LAN backup device, which likely results in significant unicast traffic from the server to the backup device.
When an interface goes down, it triggers a Topology Change Notification (TCN), causing all switches to shorten their MAC address table aging time to 15 seconds. This results in all MAC addresses being cleared from the tables.
The switches will quickly re-learn the MAC address of the server because it's actively transmitting data to the LAN backup device; however, if the LAN backup device is only receiving traffic without sending any data itself, the switches won't be able to re-learn its MAC address.
What happens to unknown MAC unicast traffic?
It gets flooded to all interfaces except the one it came from. This can overwhelm the network with unnecessary traffic until the LAN backup device sends an Ethernet frame, allowing the switches to re-learn its MAC address.
So, how can we address this issue?
Enter PortFast! PortFast is a Cisco proprietary feature designed to manage topology changes. It offers two key benefits:
1. Immediate Forwarding: Interfaces with the PortFast enabled transition directly to the forwarding state when they come up, bypassing the listening and learning phases.
2. No TCN Generation: A switch will not generate a Topology Change Notification (TCN) for an interface with PortFast enabled.
Enabling PortFast on interfaces connected to hosts is advisable since these interfaces tend to go up and down frequently; however, it's important not to enable PortFast on interfaces that connect to other hubs or switches.
To find out why, tune in for the next tutorial on configuring and managing PortFast in a switched environment!
Happy Configuring TCNs!
Rate This Article
Thanks for reading: Spanning-Tree Protocol (STP) Topology Change Notification (TCN), Sorry, my English is bad:)