Search … 

You are here: Home » Cisco » CCNP ENCOR 350-401

STP Topology Change Notification 

(TCN) Course Contents

How does spanning-tree deal with topology changes? This is a topic that isn’t (heavily) CCNP ENCOR 350-401

tested on the CCNP SWITCH exam but it’s very important to understand if you deal with a
 Unit 1: Switching
network with a lot of switches.
 1.1: VLANs and Trunks

 1.2: STP
Let me show you an example so I can explain a couple of things:
Introduction to Spanning-Tree

Spanning-Tree Cost Calculation

Spanning-Tree Port States

Spanning-Tree Topology Change

Notification (TCN)

Spanning-Tree Reconvergence

Troubleshooting Spanning-Tree

 1.3: RSTP

 1.4: MSTP

 1.5: STP Tuning

 1.6: Etherchannel

 Unit 2: Routing

 Unit 3: Wireless

Let’s take a look at the picture above. We have two computers because I need something  Unit 4: Multicast

to fill the MAC address tables of these switches. All switches have the default  Unit 5: Network Architecture

configuration.  Unit 6: Services

 Unit 7: Network Assurance

 Unit 8: Security
SW3(config)#spanning-tree vlan 1 priority 4096
 Unit 9: Automation

 Unit 10: Virtualization

SW2(config)#interface fa0/19  Unit 11: Practice Exam

SW2(config-if)#spanning-tree cost 50

I want SW3 to be the root bridge and the fa0/19 interface of SW2 should be blocked. I’ll
show you why in a minute. Let’s see what the state is of all these interfaces:

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 P2p
 SW2#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 P2p

SW3#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 P2p

SW4#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 P2p

So here we have all the different interfaces, time to draw a nice picture!

Traffic between H1 and H2 will flow from SW2 to SW1, SW3 and then towards SW4.
Interface fa0/19 on SW2 has been blocked.

Let’s generate some traffic so the switches learn the MAC addresses of the computers:
 C:Documents and SettingsH1>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 = 0ms

A 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:

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/16

SW2#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/14

SW3#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/19
 SW4#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/4

We can confirm the traffic path by looking at the MAC address table. I like to use the
show mac address-table dynamic command so we don’t have to browse through a list
of static MAC addresses.

Do you have any idea how long a switch will store a MAC address?

SW1#show mac address-table aging-time

Global Aging Time: 300

If we look at one of the switches we can check the default aging time of the MAC address
table. As you can see this is 300 seconds (5 minutes by default). If a host has been silent
for 5 minutes its MAC address will be removed from the table.

Why do we care about aging time? I’ll show you why!

C:Documents and SettingsH1>ping 192.168.1.2 -t

First I’m going to get some traffic going from H1 to H2. By using ping –t it will run forever.

The next step will be to unplug one of the cables:

Assume the link between SW1 and SW3 fails. H1 and H2 will be unable to communicate
with each other until the fa0/19 interface of SW2 goes into forwarding.

It will take a maximum of 50 seconds for SW2 to move the fa0/19 interface from blocking
to listening, learning and finally the forwarding state.

Meanwhile SW2 still has the MAC address of H2 in its MAC address table and will keep
forwarding it to SW1 where it will be dropped. It will be impossible for our computers to
communicate with each other for 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…”

The idea of MAC address tables that age out after 300 seconds works perfectly fine in a
stable network but not when the topology changes. Of course there’s a solution to every
problem and that’s why spanning-tree has a topology change mechanism.

When a switch detects a change in the network (interface going down or into forwarding
state) it will advertise this event to the whole switched network.

When the switches receive this message they will reduce the aging time of the MAC
address table from 300 seconds to 15 seconds (this is the forward delay timer). This
message is called the TCN (Topology Change Notification).

To take a closer look at the TCN we’ll have to do some debugging…

SW1#debug spanning-tree events

Spanning Tree event debugging is on

SW2#debug spanning-tree events

Spanning Tree event debugging is on

SW3#debug spanning-tree events

Spanning Tree event debugging is on

SW4#debug spanning-tree events

Spanning Tree event debugging is on

I’m going to enable debug spanning-tree events on all switches so you can see this
process in action.

Now we will shut the Interface fa0/16 on SW1 to simulate a link failure:

SW1(config)#interface fa0/16
SW1(config-if)#shutdown

Here’s what you’ll see:

SW1#STP: VLAN0001 sent Topology Change Notice on Fa0/14

You will see quite some debug information but somewhere along the lines you’ll see that
SW1 is generating a topology change notification and sends it on its fa0/14 interface to
SW2. Here’s what you see on SW2:

SW2#STP: VLAN0001 Topology Change rcvd on Fa0/14

SW2 will throw quite some debug stuff in your face but this is what I was looking for. You
can see that it received the topology change notification from SW1. Upon arrival of this
topology change notification SW2 will age out its MAC address table in 15 seconds.

What will SW2 do with this information? Look below:

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 -> forwarding

SW2 decides that fa0/19 is now the new root port and you can see the transition from
listening to learning and forwarding mode. It’s also sending a topology change
notification towards SW4.

SW3#STP: VLAN0001 Topology Change rcvd on Fa0/19

SW3 receives a topology change notification 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/19

Here we see that SW4 receives the topology change notification from SW2 and as a
result it will reduce its age out timer of the MAC address table to 15 seconds. It’s also
sending a topology change notification to SW3.

All switches received the topology change notification and set their age out timer to 15
seconds. SW2 doesn’t receive any Ethernet Frames with the MAC address of H2 as the
source on its fa0/14 interface and will remove this entry from the MAC address table.
Meanwhile the fa0/19 interface on SW2 changed from blocking to listening, learning and
forwarding state (50 seconds total). SW2 will now learn the MAC address of H2 on its
fa0/19 interface and life is good!

Of course the same thing will happen for the MAC address of H1 on SW4.

Are you following me so far? To keep a long story short…we need the topology change
notification to reduce the MAC address table aging timer from 300 seconds to 15
seconds to prevent blackholing traffic in a situation like I just explained to you.

So which switches will send and forward the topology change notifications? In our
previous debug you saw a couple of messages but where do we send them and why? Is it
flooded to all switches? Let’s check it out!

In a normal situation a non-root switch will receive BPDUs on its root port but will never
send any BPDUs to the root bridge. When a non-root switch detects a topology change it
will generate a topology change notification and send it on its root port towards the root
bridge.

When a switch receives the topology change notification it will send a (TCA) topology
change acknowledgement on its designated port towards the downstream switch. It will
create a topology change notification itself and send it on its root port as well…we will
work our way up the tree until we reach the root bridge.

What kind of message is used for the TCN? Take a look at this BPDU:
You can see it has a field called BPDU type. This value will change to indicate it’s a
topology change notification.

Once the topology change notification reaches the root bridge it will set the TC (topology
change) bit in the BPDUs it will send.

These BPDUs will be forwarded to all the other switches in our network so they can
reduce their aging time of the MAC address table. Switches will receives these messages
on both forwarding and blocked ports.

The root bridge will send BPDUs and it will set the flag field to represent the topology
change.
That’s all there is to it. This is how spanning-tree deals with topology changes in our
network. There is one more thing I want to you show you about this mechanism. Take a
look at the picture below:

As you can see H1 is connected to SW2 on its fa0/2 interface. Let’s see what happens
when this interface goes down.

SW2#show spanning-tree interface fa0/2

Vlan Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- ------------------------
--------
VLAN0001 Desg FWD 19 128.4 P2p

We can see that the fa0/2 interface on SW2 is designated and forwarding. Let’s enable a
debug and shut this interface:

SW2#debug spanning-tree events

Spanning Tree event debugging is on

SW2(config)#interface f0/2
SW2(config-if)#shutdown

This is what happens on SW2:

SW2 STP: VLAN0001 sent Topology Change Notice on Fa0/14

Right 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 shutdown

This is what you’ll 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 -> forwarding

Once we bring the interface up you can see it goes through the listening and learning
state and ends in the forwarding state. The switch generates another topology change
notification and sends it on the root port.

What kind of issues could this cause? Imagine we have a network with a LOT of hosts.
Each time an interface goes up or down a topology change notification will be generated
and ALL switches will set their aging time to 15 seconds. A host will trigger a topology
change and if you have a lot of hosts it’s possible that you end up with a network that is
in a constant state of “topology changes”.

Here’s a situation that could occur:

In the picture above I have a server sending a backup to a LAN backup device. This
means we’ll probably have a lot of unicast traffic from the server to the LAN backup
device.

Whenever an interface goes down it will generate a topology change notification and as
a result all switches will reduce their aging time of the MAC address table to 15 seconds.
All the MAC addresses of the devices will be flushed from the MAC address table.

The switches will quickly re-learn the MAC address of the server since its actively sending
traffic to the LAN Backup device. If this LAN Backup device is just silently receiving traffic
and not sending any traffic itself then there’s no way for the switches to re-learn its MAC
address.
What happens to unknown MAC unicast traffic? That’s right…it’s flooded on all interfaces
except the one where it originated from. As a result this network will be burdened with
traffic until our LAN Backup device sends an Ethernet Frame and the switches re-learn its
MAC address.

How can we deal with this drama scenario?

Portfast to the rescue! Portfast is a Cisco proprietary solution to deal with topology
changes. It does two things for us:

Interfaces with portfast enabled that come up will go to forwarding mode

immediately. It will skip the listening and learning state.
A switch will never generate a topology change notification for an interface that has
portfast enabled.

It’s a good idea to enable portfast on interfaces that are connected to hosts because
these interfaces are likely to go up and down all the time. Don’t enable portfast on an
interface to another hub or switch.

« Previous Lesson
Spanning-Tree Port States
Next Lesson
Spanning-Tree
Reconvergence
»
 Tags: Portfast

Forum Replies

chandima.ediriweera

Hi Rene

It is a great lesson to understand the Topology change on the STP. I have a question which is related to the switches which receives only BPDU with TCN
flag set from the Root bridge

Assume that Switch network has few more switches and TCN notification generated by switch ( switch A on the diagram) has not been pass through on
these switches . I need to know what would be the mac address aging time for the other switches which receives BPDU’s with TCN flag set. My
understanding is if a switch in the switch network received the TCN from the Root bridge t
... Continue reading in our forum

javeedz

Hello Rene,

I am getting confused with this concepts in STP, The more i read the more i am getting confused
Please help me upnderstand this concepts, I 've wriiten my understanding and questions.

In a Steady state Network assuming the packet between computer A and Computer B takes (Switch B --> Switch A --> Switch C --> Switch D)

**Question related to interface states and convergence time**

Switch C (Root Bridge) generates configuration BPDU’s and sends it to Switch A and Switch D and in turn they relay it to switch B
When we have an indirect link failure (shut

... Continue reading in our forum

andrew

Ravi,
If we are talking about traditional spanning tree (802.1 D), and not rapid spanning tree (802.1 W), a switch will set the aging of the MAC address table
equal to the Max Age timer when it receives the Topology Change Acknowledgement from the Root Bridge. It works like this:

A switch, let’s say it is not the root bridge, has event that causes it to generate a topology change. It’s goal is to send this to the root bridge, and then it is
the root bridge’s job to acknowledge this change. This acknowledgement starts with the Root Bridge and makes its way th

... Continue reading in our forum

paul.harris3

EDIT: Having looked into this further, I don’t think the process as described in the article is actually correct… if the root port on SW1 goes down, rather than sending
a TCN, it will start sending inferior BPDUs to SW2. That’s according to this: https://learningnetwork.cisco.com/thread/63525

In the scenario given, it says that SW2 receives the TCN from SW1 and then immediately makes Fa0/19 the new root port.

A topology change doesn’t necessarily mean that the root port needs to change, so how does it know to immediately change the root port? My suspicion
is th

... Continue reading in our forum

lagapides

Hello Pradeep

https://cdn-forum.networklessons.com/letter_avatar_proxy/v2/letter/p/e68b1a/40.png

pradeepmp11366:
What would be the first state of new switch port and how it works?(I know it starts from blocking state, I want to know the series of events that happens
between those two ports - old and the new one)

For the following, we assume that we are using simple STP (802.1D). If you have a stable topology where STP has converged, and you add a new switch to
one of the switchports of the switches already in the topology, then the following would happen

... Continue reading in our forum

 80 more replies! Ask a question or join the discussion by visiting our Community Forum

© 2013 - 2021 NetworkLessons.com 39962 Disclaimer Privacy Policy Support About