Under normal circumstances, a TCN will always be sent out of the root port. The purpose of the TCN is to inform the root bridge of the topology change. Then the root bridge in turn will inform all of the bridges of the topology change using a BPDU with the TC bit set. You can see this in detail at this Cisco Documentation.
But what happens if it is the root port that goes down as is the case in this lesson? SW1 will then send a TCN out of its designated port as you mention as well. This results in SW2 receiving a TCN on its root port, which is not expected. This in turn informs SW2 that a connection to the root bridge is no longer available via this path so the root port may need to be redefined on this bridge. So not only does the TCN reduce the MAC address table timer, but it also puts into motion the reconvergence of the STP topology. This results in Fa0/19 of SW2 becoming the root port, as is seen in the next diagram.
thank u very mach lazaros
i have three quistion
question 1 : when the root port on sw 1 goes down it will send TCN on designated port to sw 2 , sw 2 most send TCA to sw 1 and send TCN to reach root bridg but the port in blocking state , it well wait max age 20 second and then send TCN in listening state or wait the port to be forwarding and then send TCN on port 0/19
question 2 : the link fail between sw 1 and sw 3 , sw3 is a root bridge , it well send TC immeditly or not sending anything
question 3 : when sw 1 the root port goes down it will try to send bpdu claim i am the root or not
In this case, SW2 receives a TCN on its root port. This will only happen if the path to the root bridge via that root port is no longer a valid path. So SW2 wonât send TCNs out of the current root port. It will simply immediately begin the reconvergence procedure and forget about sending TCNs.
If this link fails, the root bridge itself is informed immediately. So it will send out a TC immediately, informing all the switches of a change.
If a root port link fails, or if a TCN is received on a root port, the switch immediately knows that the root is no longer reachable via that port. A new root port must be found. The router does not âthinkâ it is root bridge yet, but will start sending out configuration BPDUs out of its designated and blocked ports telling other switches of its priority. It receives BPDUs from other switches and compares the priorities, and either becomes root (because it does have the highest priority), or it will see that another switch becomes root, and it will designated the proper port a root port. If no BPDUs are received after a time, it considers itself not only the root bridge, but the only bridge in the topology.
When root bridge sends the BPDU post getting TCN message, What value it will set for TC in Flag filed and what value of TCN root bridge will receive in BPDU type field ?
Actually i couldnât understand the meaning of these lines given below, Could you emphasize this by taking help of same examples( Eg. Server and LAN Device stuff ) related to this?
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.
I have a doubt here that when topology change post receiving TCN root bridge send BPDU to all switch in network so they can know that topology change occurred and reduce the aging timer to 15 seconds as well but i want to know that is this timer countdown start either post receiving TC BPDU or since TCN or TC takes place in STP network.
I have gotten little bit messed up post studying given lines in UplinkFast tutorial !
"However it will take 15 seconds for the topology change mechanism to age out the MAC address table! "
After a root bridge receives a TCN message, it will do two things.
It will send a Topology Change Acknowledgement (TCA) BPDU. This BPDU is simply a configuration BPDU, thus the Type field will indicate a configuration BPDU. This is sent back downstream, to the original sender.
Once the root is aware that there has been a topology change event in the network, it starts to send out its configuration BPDUs with the topology change (TC) bit set. Since they remain configuration BPDUs, means that the Type Field indicates configuration BPDUs.
Remember that all of this is referring to the original STP (IEEE 802.1D). You can find out more about this mechanism at the following Cisco documentation:
Imagine that S1 is sending a stream of data to the LAN backup device. Imagine that this procedure takes several hours. Letâs also assume that the LAN backup device is not sending any data at all, but is silently receiving the data being sent. In other words, there are no flow control or error checking mechanisms that may cause the LAN backup device to need to send any data back.
Now letâs say that the user on one of the PCs finished their work for the day and shuts off their PC. The switchport that the PC is connected to will go down. The switch will generate a TCN, and will cause a flushing out of the MAC addresses, requiring the switch to relearn MAC addresses.
Now in this particular situation, the LAN backup device will not send any data towards the switch, and the switch will thus never learn of its MAC address to put it in the MAC address table.
What happens when a frame reaches a switch, and the destination MAC is not in the MAC address table? It is flooded to all ports.
This situation will be maintained for hours until the backup is finished, because the LAB backup device doesnât send any data for the switch to relearn its MAC address. This results in all devices receiving traffic, and needing to discard it.
The solution to this problem is portfast, as described by the lesson.
The aging time of the MAC address table in all of the switches will begin only when they receive the configuration BPDUs with the topology change (TC) bit set from the root bridge. No changes are made due to the TCN or TCA that are sent to and from the switch that initially detected the topology change.
In the uplinkfast lesson, SW2 receives a BPDU from the root (SW1) almost immediately, because it is SW1, the root itself, that detects the topology change, so it sends out a BPDU with the TC set, and SW2 receives it immediately. So the statement that the MAC address table age out timer has been set to 15 in SW2 is accurate.
This is an excellent question. Although this behaviour has changed over various older platforms, the more modern platforms behave in a consistent manner. Specifically, the STP cost is evaluated based on a composite calculation of the total bandwidth of the links in the bundle. For example, this post in the Cisco community show an example of two FastEthernet interfaces bundled in a single etherchannel. When both are up, the STP cost is calculated to be 12, whereas if one goes down, it is modified to 19, which is to be expected for a single FastEthernet link.
Although Cisco has not published the formula they use to calculate the STP cost, it is evident that it is based on the total bandwidth of the etherchannel, which makes sense. The resulting cost of specific total bandwidths can be found in the table below:
Is the TCN will be generated on both old spanning tree as well as the new spanning tree (rapid SPT) if the access port goes down? But if you enable âPortfastâ, then the TCN will NOT be generated.
Is the BPDU will be only generated by the root-switch, while the non-root-switch will just forward the received BDPD in the old spanning tree (IEEE 802.1d)?
Is the BPDU will be generated by the root-switch as well as non-root-switch new spanning tree (rapid STP) (IEEE 802.1w)?
The generation of TCNs is different for standard STP and for RSTP. This lesson describes the procedure for standard STP. The following post describes the TCN for RSTP.
Yes, you are correct, ports that are enabled with portfast will not generate TCNs for either STP or RSTP.
For both of these questions, take a look at the following post:
Laz, in STP (IEEE.1d), at what moment the mac address table will get flushed on the switch? Is it when the for example a non-root switch received a TCN from a non-root switch OR when the non-root switch received a TCN with the bit SET from the root-switch? I am guessing it will be the moment it received it from the root-switch, then at that moment it will be flushed and cleared after 15 seconds, but please confirm. Thanks
As soon as a switch receives a TCN with the TC flag bit set, only then will it reset the MAC address table timer to 15 seconds. So it is the TCN that comes from the root switch that triggers this max age timer reset.
This mechanism is valid for both STP and RSTP. The difference however between these involves when an TC is initiated. These details are further described in the following Cisco documentaiton:
Hi,
In regard to this statement "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)."
I was just wondering when the aging time is change to 15 seconds is this per vlan or for all the vlans on the switch ? as I read somewhere it was per vlan but I just wanted to know exactly.
Thanks.
Yes, it is indeed on a per VLAN basis. Remember that there is one STP topology that exists per VLAN. So any TCNs sent out will be sent within the spanning tree of the specific VLAN, and will affect the ageing timers only of the MAC address table entries of that particular VLAN.
Thanks Lazaros,
Its a very interesting topic for me.
I just have a couple of more questions -
I understand as you say above the TCN change is per vlan which makes total sense and I can see it working this way in my current production environment. However what I was wondering is how does this play out with MST ?
I thought MST kind of uses rstp under the hood so to speak, but Iâm just wondering how the TCN in one vlan effects other vlans that are in the same MST instance ?
If there is a topolgy change caused by a non portfast edgeport going up or down is the aging timer for that vlan set to 15 seconds same as rstp or are all the vlans in that MST instance set to 15 seconds ?
The reason I ask is that I also see this in another production network where it seems anytime there is a topology change on any vlan then it seems to effect all the Vlans in the same mst instance.
For example if I look at show spanning tree vlan xxx detail and I see number of topology changes and time of last change it seems to be exactly the same for all the other vlans in the same mst instance as oppose to if I look at this command for vlans in rstp then they will have different amounts of changes and times of changes for each vlan.
The other question I was wondering about is in Renes example at the bottom of the page where there is a server sending to a backup device and there is a TCN sent during this time and then as Renes says â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.â
I understand its flooded on all interfaces but what Iâm wondering is when it gets flooded also to the port of the backup device then does the backup device not send âsyn acksâ or some type of âwindowingâ acknowledgement straight back to server thus allowing the network to learn its mac address or am I understanding this wrong ?
How long would this flooding realistically continue ? would the backup device not send some type of acknowledgement ethernet frame back to the sender once it receives the first flooded frame on its port destined for itself ?
Thanks
As you suspected, the entries in the MAC address table that correspond with the specific MST instance on which a topology change has occurred will be flushed, and not those of other MST instances. Also note that because MST uses the same mechanisms as PVST+, unlike normal STP, a TCN will only be generated when a port comes up and not when it goes down.
That depends upon the protocol being used. If you were to use FTP for file transfer for example, yes, you would have some acknowledgements sent back in the form of TCP windowing as you mentioned, and the MAC address table would then be populated correctly. But what if you are using TFTP? This is a protocol that uses UDP for its transport layer, and it has no acknowledgements. If youâre sending a file of say 10GB over the link, it may take several minutes or several tens of minutes to send. During all that time, in the event of a TCN, the backup device will send no traffic, and thus the backup data transfer would be flooded.
Thanks Lazaros, your answers are always great and very helpful.
Its a very interesting situation.
Iâm gathering from this lecture that portfast is extremely important in todays networks and probably more important than most people realise ?
How would this situation work with a device that is contineously sending udp all day to a device that doesnât reply.
Lets say for example if there was one ip camera sending udp all day everyday to a single address and there is a topology change.
It would keep sending to the receivers mac address which is unknown to the switches after the switch has flushed its mac table ?
If there is no acknowledgements from the receiver then does this mean the udp packets just keep getting flooded to all ports day after day ?
If this is correct then how is this contineous flooding ended or does it ever end ?
Also if the receiver is never sending replys or acknowledgements at any stage after the session is first setup, then how is the switches mac address table being updated as surely the mac address will be flushed after 5 minutes anyway if it doesnât hear from the receiver regardless of the tcn causing the switch to flush its mac table ?
Finally would this same issue also cause problems with multicast ie. with the multicast mac addresses ?
