Sei sulla pagina 1di 5

1

Spanning Tree Topology Change Notification (TCN)

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

Lets generate some traffic so the switches learn the MAC addresses of the computers:

C:Documents and SettingsH1>ping 192.168.1.2

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


Sw2#show mac address-table dynamic
SW3#show mac address-table dynamic
sW4#show mac address-table dynamic

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
2

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 doesnt 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 theres a solution to every problem and thats 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 well 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

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

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

Heres what youll see:


3

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

You will see quite some debug information but somewhere along the lines youll see that SW1 is generating a topology change
notification and sends it on its fa0/14 interface to SW2. Heres 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.
Its 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. Its 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 doesnt 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.
4

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 shortwe 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.

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 wellwe 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 its a topology change notification.

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 .

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.
5

Its 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. Dont enable portfast on an interface to
another hub or switch.

Potrebbero piacerti anche