Académique Documents
Professionnel Documents
Culture Documents
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:
H1: 000c.2928.5c6c
H2: 000c.29e2.03ba
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).
Now we will shut the Interface fa0/16 on SW1 to simulate a link failure:
SW1(config)#interface fa0/16
SW1(config-if)#shutdown
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 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.
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 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.
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 .
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.