CiscoCCNPEnterprise NetworkingIntermediate24 min read

What Is STP TCN Process in Networking?

Also known as: STP TCN process, topology change notification, STP convergence, CCNP ENCOR STP, spanning tree protocol TCN

Reviewed byJohnson Ajibi· Senior Network & Security Engineer · MSc IT Security
On This Page

Quick Definition

Spanning Tree Protocol uses Topology Change Notifications to keep the network working when a link goes up or down. When a switch detects a change, it sends a special message to the root bridge, which then tells every other switch to flush their learned MAC addresses. This prevents packets from being sent to old, broken paths while the network recalculates the best routes.

Must Know for Exams

The STP TCN process is a frequently tested topic in Cisco CCNP ENCOR exam, which is part of the CCNP Enterprise certification. The exam objectives include understanding Spanning Tree Protocol operations, convergence, and optimization. Cisco expects candidates to know exactly how a TCN is generated, how it is propagated, what happens when the root bridge receives it, and how the TC flag affects MAC address aging.

Exam questions often present a scenario such as: "A switch detects a link failure on a port that was in the forwarding state. Describe the sequence of BPDU exchanges that occur." The candidate must recall that the switch originates a TCN BPDU, sends it out of its root port, and that the TCN is acknowledged by the upstream neighbor.

The TCN continues hop by hop until it reaches the root bridge, which then sets the TC flag in its configuration BPDUs for a period equal to Forward Delay plus Max Age. Another common question format asks about the effect of TCN on MAC address tables. The correct answer is that all switches receiving BPDUs with the TC flag set reduce their MAC aging timer to the Forward Delay value, causing them to flush learned entries more quickly.

Questions might also ask about the differences between classic STP and RSTP regarding TCN handling. In classic STP, the TCN must travel all the way to the root bridge before the TC flag is broadcast back. In RSTP, the switch that detects the change immediately sets the TC flag on all its designated ports, speeding up convergence.

The exam also covers how PortFast and BPDU Guard affect TCN generation. A port with PortFast enabled does not generate a TCN when it goes up or down, which is a key point for minimizing unnecessary network disruptions. Cisco may also test the effect of TCNs in multi-VLAN environments using PVST+ or Rapid PVST+, where each VLAN runs its own STP instance.

In that case, a single physical link failure can generate multiple TCNs, one per active VLAN. Understanding this helps in answering questions about CPU load and convergence time during failures.

Simple Meaning

Imagine you work in a large office building with many hallways and rooms. The building manager has a master map showing the fastest way to deliver mail to every desk. One day, a hallway is closed for repairs, and the manager updates the map to reroute deliveries.

But the mail carriers are still using the old map and keep trying to go through the closed hallway, causing delays. The manager needs a way to shout out a general alert that says, "Stop using the old map! I will give you a new one soon."

That alert is the Topology Change Notification in STP. In a network, switches learn which devices are connected to each port by building MAC address tables. When a link fails or a new switch is added, the network topology changes.

If a switch continues using its old table, it might send data to a port that no longer leads to the destination. The STP TCN process triggers a temporary refresh of these tables across all switches. Every switch must forget its old learned paths and wait for the new spanning tree to be recalculated.

This process ensures that no data is sent down a broken link, but it also temporarily increases the workload on the switches because they have to re-learn all device locations. The TCN process is a critical coordination tool: it tells the entire network to hit the reset button on its forwarding tables, just as the office manager tells all mail carriers to throw away their old maps.

Full Technical Definition

The STP TCN process is part of the IEEE 802.1D Spanning Tree Protocol and its variants such as Rapid Spanning Tree Protocol (RSTP) and Multiple Spanning Tree Protocol (MSTP). When a switch detects a change in the active topology, for example a port transitioning from blocking to forwarding or a port failure, it generates a Topology Change Notification (TCN) BPDU.

The TCN BPDU is a special type of Bridge Protocol Data Unit that serves one purpose: to inform the root bridge that a topology change has occurred. The originating switch sends this TCN BPDU out of its root port, which is the port that provides the best path toward the root bridge. Each switch that receives the TCN BPDU on its designated port acknowledges receipt by setting the Topology Change Acknowledgment (TCA) flag in the next BPDU it sends back to the neighbor.

The receiving switch then forwards the TCN BPDU toward the root bridge using its own root port. This process continues hop by hop until the TCN BPDU reaches the root bridge. Once the root bridge receives the TCN, it sets the Topology Change (TC) flag in all subsequent configuration BPDUs it sends out for a period equal to the Forward Delay timer (default 15 seconds) plus the Max Age timer (default 20 seconds).

All other switches that receive these BPDUs with the TC flag set then know to shorten their MAC address aging time from the default 300 seconds down to the Forward Delay timer value (15 seconds). This rapid aging forces the switches to flush their MAC address tables and re-learn device locations via the normal flooding and learning processes. The result is that any forwarding paths that have become invalid due to the topology change are discarded quickly, and new paths are established based on the new spanning tree.

In RSTP, the process is more efficient. Instead of relying on the root bridge to propagate the TC flag, a switch that detects a topology change immediately sets the TC flag on all its designated ports, including the port that leads to the root bridge. This floods the change notification throughout the network in a single step, greatly reducing convergence time.

In STP, the TCN process is a necessary overhead because it temporarily disrupts forwarding performance while the network recalculates paths.

Real-Life Example

Think of a large public library with multiple desks and a central catalog system. Each desk has a local index card file that tells the librarian which shelf holds each book. The library is rearranged every night: some shelves are moved, new sections are added, and old ones are removed.

Every librarian has been trained to update their personal index cards only when they hear a specific announcement over the intercom. One evening, the head librarian decides to move the entire History section from the second floor to the first floor. Before the move, she makes an announcement over the intercom: "Attention all librarians: a major change is happening.

Please discard your current shelf location cards. I will announce the new layout shortly." This announcement is the Topology Change Notification. Each librarian hears the announcement and immediately throws away their cards.

They now have no way to know where any book is, so they must ask the central catalog for every single request. This slows down service, but it prevents them from sending a patron to the wrong floor. After the move is complete, the head librarian makes a second announcement with the new layout, and the librarians slowly rebuild their index cards as they help patrons.

In the network, the TCN process is like that first announcement. The switch that detects a link change sends a special message toward the root bridge, which then broadcasts a "flush your tables" message to every other switch. All switches delete their MAC address tables and begin learning device locations from scratch.

This temporary confusion is necessary to ensure that no data is sent to a port that no longer has the correct destination device. Just as the library avoids directing patrons to the wrong floor, the network avoids sending frames to dead ends or loops. The process guarantees that every switch eventually uses the correct forwarding paths based on the new network topology.

Why This Term Matters

In real IT work, especially in enterprise networks with many switches, the STP TCN process is a hidden but critical mechanism that ensures reliable data delivery after a network change. When a link fails or a new switch is added, MAC address tables across all switches become outdated. If an administrator does not understand how TCNs work, they might be puzzled by temporary performance issues after a network event.

For example, when a core switch reboots, all downstream switches generate TCNs, causing a wave of MAC table flushes. This can lead to a short burst of flooding for unknown unicast frames, which increases CPU utilization on every switch and can cause packet loss in time-sensitive applications like VoIP. Network engineers must consider the impact of TCNs when designing redundant topologies.

In data center networks with many VLANs, a single link failure can trigger multiple TCNs, one per VLAN, overwhelming the control plane of older switches. Cisco switches have features like STP PortFast and BPDU Guard that help reduce unnecessary TCNs on access ports connected to end devices. For example, enabling PortFast on an access port allows the port to transition directly to forwarding without generating a TCN when a PC boots up.

This prevents the entire network from flushing its tables every time an employee turns on their computer. Understanding the TCN process also helps with troubleshooting flapping interfaces or unstable MAC addresses. If a network engineer notices that MAC addresses are being learned and unlearned rapidly, it may be because a switch is repeatedly sending TCNs due to a faulty cable or a misconfigured port.

By monitoring TCN events using Cisco commands like show spanning-tree detail or debug spanning-tree events, an engineer can quickly isolate the problem. In summary, the TCN process is not just an exam topic; it is a real-world operational concern that affects network stability, convergence time, and application performance.

How It Appears in Exam Questions

Exam questions about the STP TCN process appear in several patterns. The most common is a sequence-based question. For example, the candidate is given a network diagram with four switches and a link failure between Switch B and Switch C.

The question asks: "Which switch originates the TCN BPDU, and how does it reach the root bridge?" The answer requires following the path of the TCN BPDU from the detecting switch through its root port to the root bridge. Another pattern is a configuration question.

The candidate is shown a partial output of show spanning-tree detail where the TC flag count is rapidly increasing. They must identify the cause, such as a user plugging and unplugging a device on an access port without PortFast enabled. The correct answer involves enabling PortFast on the interface to suppress unnecessary TCNs.

Troubleshooting questions frequently appear. A scenario describes a network where users experience intermittent connectivity after a new switch is added. The candidate must deduce that the addition caused a TCN flood, and the switches are busy flushing and re-learning MAC addresses, leading to temporary packet loss.

The solution might be to use RSTP or to tune STP timers. Architecture questions test understanding of TCN propagation in different STP variants. For instance, a question might ask: "In a network running MSTP, how does the TCN process differ from classic STP?"

The candidate must explain that MSTP uses an internal spanning tree (IST) to propagate TCNs across regions, and that the CIST (Common and Internal Spanning Tree) root handles the TCN for the entire network. Another pattern is a comparison question. The candidate is asked to compare the TCN process in classic STP versus RSTP, with the key difference being that RSTP floods the TC flag immediately from the edge switch, whereas classic STP requires the TCN to travel to the root bridge first.

Finally, there are best-practice questions. For example, "What should a network engineer do to minimize the impact of TCNs on a network with hundreds of access ports?" The correct answer is to enable PortFast on all access ports and use BPDU Guard as a security measure.

These question patterns require both theoretical knowledge and practical application.

Study encor

Test your understanding with exam-style practice questions.

Practise

Example Scenario

A company called TechCorp has a small network with three switches: Switch A, Switch B, and Switch C. Switch A is the root bridge. Switch B connects to Switch A via a fiber link, and Switch C connects to Switch B via a copper link.

The network has been running stable for months. One day, a technician accidentally unplugs the copper cable between Switch B and Switch C while cleaning the server room. Switch C immediately detects the link loss on its port that was in the forwarding state.

According to STP, Switch C must inform the rest of the network about this change. Switch C generates a TCN BPDU and sends it out of its root port, which is the port facing Switch B. Switch B receives the TCN BPDU, acknowledges it by setting the TCA flag in the next BPDU it sends back to Switch C, and then forwards the TCN BPDU out of its own root port toward Switch A.

Switch A receives the TCN BPDU, acknowledges it, and then sets the TC flag in all its configuration BPDUs for the next 35 seconds, which is the sum of Forward Delay and Max Age. All switches, including Switch B and Switch C, receive these BPDUs with the TC flag set. They immediately reduce their MAC aging timer to 15 seconds, causing them to flush their MAC address tables quickly.

For the next several seconds, when a device on Switch A wants to send data to a device on Switch C, the frame is flooded to all ports because the MAC address is no longer in the table. Eventually, the destination device responds, and the switches re-learn the correct location based on the new topology where Switch C now has only a single path through Switch B. The network converges after the STP recalculation, and normal operation resumes.

This scenario illustrates how a simple cable pull triggers the entire TCN process, temporarily flooding the network with unknown unicast frames.

Common Mistakes

Believing that only the root bridge can generate a TCN BPDU.

A TCN BPDU is generated by any non-root switch that detects a topology change, such as a port going from blocking to forwarding or a link failure. The TCN is then sent toward the root bridge. The root bridge itself does not generate the initial TCN.

Remember that any switch can originate a TCN, but it always travels toward the root bridge.

Thinking that the TCN BPDU immediately causes all switches to flush their MAC tables.

The TCN BPDU itself only travels to the root bridge. It is the TC flag set by the root bridge in its configuration BPDUs that causes other switches to reduce their MAC aging time and effectively flush their tables. The TCN is just a notification, not the flushing command.

Understand that the TCN BPDU is the message sent to the root bridge. The root bridge then broadcasts the TC flag to all switches to trigger the flush.

Confusing the TCN process with the entire STP convergence process.

The TCN process only covers the notification and MAC table flushing phase. STP convergence also includes electing a new root bridge, recalculating port roles, and transitioning ports through listening and learning states. The TCN is just one part of the overall process.

Keep in mind that the TCN process deals specifically with topology change notification and MAC aging, while full convergence also involves port role transitions and timer states.

Assuming that a TCN is generated when any port goes up or down.

A TCN is only generated when a port transitions to or from the forwarding state in a way that affects the active topology. Ports that are in blocking or alternate states do not generate TCNs when they change. Also, ports with PortFast enabled do not generate TCNs, because they are considered edge ports connected to end devices.

Remember that only ports that are part of the active spanning tree topology generate TCNs. Edge ports with PortFast are excluded.

Believing that the TCN process is the same in classic STP and RSTP.

In classic STP, the TCN travels hop by hop to the root bridge, which then sets the TC flag in its BPDUs. In RSTP, the switch that detects the change immediately sets the TC flag on the BPDUs it sends out of all its designated ports, propagating the notification much faster without waiting for the root bridge.

Learn the difference: classic STP uses a centralized root bridge to propagate the TC flag, while RSTP uses a distributed approach where edge switches can directly set the TC flag.

Exam Trap — Don't Get Fooled

In an exam scenario, a question asks: "A switch receives a TCN BPDU on its root port. What does the switch do?" Many learners incorrectly answer that the switch immediately flushes its MAC table.

Remember the exact sequence: A switch that receives a TCN BPDU on its root port must acknowledge it and forward it toward the root bridge. It does not flush its MAC table at that point. Only after the root bridge sets the TC flag in its configuration BPDUs and that flag is received by the switch does the switch reduce its MAC aging timer and effectively flush the table.

Always map the path of the TCN BPDU separately from the effect of the TC flag.

Commonly Confused With

STP TCN ProcessvsBPDU Guard

BPDU Guard is a security feature that shuts down a port if it receives any BPDU, typically used on access ports to prevent rogue switches. The TCN process is about notifying the network of a topology change, not about security. BPDU Guard does not generate TCNs; it disables the port.

If a user plugs a small switch into an access port with BPDU Guard enabled, the port will be error-disabled. This prevents the TCN process from even being triggered because the port goes down.

STP TCN ProcessvsPortFast

PortFast allows a port to bypass the listening and learning states and transition directly to forwarding, but it also suppresses the generation of TCNs when that port changes state. The TCN process is the mechanism for announcing topology changes, while PortFast is a way to avoid unnecessary TCNs on access ports.

A PC boots up and connects to a switch port with PortFast. The port goes directly to forwarding without sending a TCN, so the rest of the network does not flush its MAC tables. Without PortFast, the same port would generate a TCN each time the PC connects or disconnects.

STP TCN ProcessvsRoot Guard

Root Guard is a feature that prevents a port from becoming a root port, even if it receives superior BPDUs. The TCN process is unrelated to root election. Root Guard ensures the current root bridge remains the root, while TCN is about notifying changes in the active topology after the root is already elected.

If a new switch with a lower bridge ID is connected to a root-guarded port, the port will be placed into a root-inconsistent state rather than becoming the new root port. The TCN process is not involved in this blocking decision.

Step-by-Step Breakdown

1

Topology Change Detection

A non-root switch detects a change in the active topology. This happens when a port that was in the forwarding state goes down, or when a port transitions from blocking to forwarding (for example, after a link recovery). The switch identifies that the current MAC address table may no longer be accurate because the path to some destinations has changed.

2

TCN BPDU Generation

The switch that detected the change constructs a TCN BPDU. This BPDU has a special type field that distinguishes it from regular configuration BPDUs. It contains no other information beyond the fact that a topology change has occurred. The switch sends this TCN BPDU out of its root port, which is the port that provides the best path toward the root bridge.

3

TCN Acknowledgment by Upstream Neighbor

The upstream switch that receives the TCN BPDU on its designated port immediately sends back a configuration BPDU with the Topology Change Acknowledgment (TCA) flag set. This tells the downstream switch that the TCN has been received. The upstream switch then replicates the TCN BPDU and sends it out of its own root port toward the root bridge.

4

TCN Propagation to Root Bridge

The TCN BPDU is passed hop by hop from each switch to the next, always traveling out of the root port of each switch, until it reaches the root bridge. Each intermediate switch acknowledges the TCN before forwarding it. This step can take multiple switch hops depending on the network diameter.

5

Root Bridge Sets TC Flag

Once the root bridge receives the TCN BPDU, it sets the Topology Change (TC) flag in all subsequent configuration BPDUs it sends out for a period equal to the Forward Delay timer plus the Max Age timer. This flag is the universal signal to all switches that a topology change has occurred and they must adjust their MAC aging behavior.

6

MAC Table Aging Reduction

Every switch that receives a configuration BPDU with the TC flag set reduces its MAC address aging timer from the default 300 seconds to the value of the Forward Delay timer (default 15 seconds). This causes the switch to flush learned MAC addresses much more quickly, effectively clearing outdated entries and forcing the switch to re-learn device locations via flooding.

7

Topology Stabilization

After the TC flag period expires, the root bridge stops setting the TC flag in its BPDUs. Switches then revert to the default MAC aging timer of 300 seconds. The network has now converged with all switches using the new topology, and the MAC tables are rebuilt based on the current forwarding paths. Normal operation resumes.

Practical Mini-Lesson

The STP TCN process is a fundamental part of network convergence in Ethernet networks. As a network professional, you will encounter it in nearly every environment with redundant switches. The most important practical takeaway is that TCNs are not inherently bad; they are necessary for maintaining a loop-free topology after changes.

However, excessive TCNs can degrade network performance by causing repeated MAC table flushes, leading to increased flooding and higher CPU usage on switches. To manage this, you should configure PortFast on all access ports that connect to end devices such as PCs, printers, and IP phones. PortFast allows the port to come up immediately without generating a TCN, and it also skips the listening and learning states.

This is a standard best practice in Cisco networks. For switch-to-switch links, especially in a data center, you might consider using RSTP or MSTP instead of classic STP. RSTP dramatically reduces the TCN propagation time because the edge switch sets the TC flag directly, without waiting for the root bridge.

This cuts convergence time from tens of seconds to a few seconds. Another practical consideration is the impact of TCNs on voice or video traffic. A TCN-induced flush can cause temporary packet loss as switches re-learn MAC addresses.

In environments sensitive to jitter, such as VoIP, you can use features like STP Toolkit (PortFast, BPDU Guard, BPDU Filter, Root Guard) to minimize unnecessary TCNs. For example, BPDU Filter can suppress BPDUs on access ports, preventing a malicious or misconfigured device from triggering TCNs. When troubleshooting, you can monitor TCN events using Cisco IOS commands.

The show spanning-tree detail command displays the number of topology changes detected and the time of the last change. If you see a rapidly increasing count, it indicates a flapping link or a device repeatedly connecting and disconnecting. The show spanning-tree interface command shows the port state and the TCN count per port.

You can also use debug spanning-tree events to see each TCN in real time, but use this sparingly in production because it is CPU-intensive. In large networks with hundreds of VLANs, each VLAN may run its own STP instance if you use PVST+ or Rapid PVST+. A single physical link failure can then generate a TCN for every active VLAN, multiplying the CPU impact by the number of VLANs.

To mitigate this, consider using MSTP, which maps multiple VLANs to a single STP instance, reducing the number of TCNs. Finally, remember that the TCN process is only for classic STP and RSTP. In MSTP, the TCN concept exists but is tied to the internal spanning tree (IST) and the common spanning tree (CST).

Understanding these nuances is crucial for CCNP-level exams and for real-world network design.

Memory Tip

Think of TCN as a ‘Three-Step Chain’: The detecting switch sends a TCN, the TCN travels to the root bridge, and then the root bridge broadcasts the TC flag back to all switches. Remember the phrase: ‘Send TCN to Root, Root sends TC back.’

Covered in These Exams

Related Glossary Terms

Frequently Asked Questions

Does a switch flush its entire MAC table when it receives a TCN BPDU?

No. Receiving a TCN BPDU does not cause a flush. The flush occurs only when the switch receives a configuration BPDU with the TC flag set from the root bridge. The TCN BPDU is simply a notification that a change has happened.

How long does the TC flag remain active after a topology change?

The root bridge sets the TC flag in its BPDUs for a duration equal to the Forward Delay timer (default 15 seconds) plus the Max Age timer (default 20 seconds), totaling 35 seconds in classic STP. After that, the flag is cleared, and switches revert to normal MAC aging.

Can a TCN be generated on a port that is in blocking state?

No. A TCN is only generated when a port transitions from blocking to forwarding (new active path) or from forwarding to blocking (link failure). Ports that are already blocking and remain blocking do not trigger a TCN.

What is the difference between a TCN BPDU and a configuration BPDU?

A TCN BPDU is a short, specialized BPDU that contains only the flag indicating a topology change. A configuration BPDU is a longer BPDU that includes bridge ID, root path cost, port ID, and various flags, including the TC flag. Configuration BPDUs are sent periodically, while TCNs are sent only when a change occurs.

Does enabling PortFast on a switch port prevent TCNs from being sent?

Yes. PortFast is a Cisco feature that not only allows the port to transition directly to forwarding but also suppresses the generation of TCNs when that port changes state. This is why it is recommended for all access ports.

How does RSTP simplify the TCN process compared to classic STP?

In RSTP, the switch that detects a topology change immediately sets the TC flag on all its designated ports, including the port toward the root bridge. This propagates the notification to all switches in a single step, without waiting for the root bridge to start sending TC-flagged BPDUs.

Can a single physical link failure cause multiple TCNs?

Yes, if the network runs PVST+ or Rapid PVST+, each VLAN runs a separate STP instance. A single link failure can generate a TCN for every active VLAN on that link, potentially creating a burst of control plane activity.

Summary

The STP TCN process is an essential component of Spanning Tree Protocol that allows a network to adapt to topology changes such as link failures or new switch additions. When a switch detects a change, it sends a Topology Change Notification BPDU toward the root bridge. The root bridge then broadcasts a Topology Change flag, forcing all switches to shorten their MAC address aging time and flush outdated entries.

This coordination prevents data from being forwarded to dead paths while the network recalculates the new spanning tree. For IT certification exams like CCNP ENCOR, understanding the exact sequence of TCN generation, propagation, and the effect of the TC flag is critical. You must know the differences between classic STP and RSTP, and you should be able to apply best practices such as PortFast to minimize unnecessary TCNs in real-world networks.

The TCN process is not just theoretical; it directly impacts network stability, convergence time, and the performance of applications that rely on fast failover. By mastering this concept, you will be better prepared to design resilient networks and to troubleshoot issues that arise during topology changes. Remember the three-step chain: detect, notify the root, and broadcast the TC flag back to all switches.