Awesome lesson, thanks.
I have some doubt on selecting Designated and Non Designated port on non root bridge.
Can you pls explain how D and ND ports selected in your 4 switches topology on the segment
between SwitchB--------SwitchD , will it be mac address or port cost ? while switchC is root bridge,
and one more thing on switchB in your 4 switch topology SwitchA-------(Root port)SwitchB, So port connected to SwitchB Root port on switchA will automatically
become Designated port ?
Hi Rohitendu M,
Let’s take piece by piece. The switches share BPDU to elect the root bridge. They look at the priority + MAC address==> we call it Bridge ID.
The switch which has the lowest bridge ID will be the root bridge. In the lesson, Rene has lowest the priority on Switch C so it became the root bridge.
As Switch C is the root bridge, then all interfaces will be as Designated ports.
In our case for Switch C:
F0/13 = Designated Port
F0/19 = Designated Port
For non-root bridges, they will check the shortest path to the root bridge and that’s the root port. In this lab, we assume that the speed of the interface is 100 Mbps, so the cost will be 19.
Then now we have:
F0/16 = Root Port
F0/19 = Root Port
As Rene has increased the cost on F0/19 of SwitchB, then this port will be in blocking state, thus the possible loop is not available anymore in the network which means all other switch ports will be in forwarding states.For every segment, there should be a designation port so the port F0/16 of SwitchD will be a designated port after the F0/19 of Switch B became in a block states.
We still have the segment between SwitchA and SwitchB. Every switch has only 1 Root port. As SwitchA has already a root port on F0/16 interface, then F0/14 will become a Designated Port. As I mentioned previously, there should be 1 designated port per segment, then F0/14 of SwitchB will move to Root Port.
I hope I could answer your question.
For more information, please read the following lesson:
19 posts were merged into an existing topic: Spanning Tree Topology Change Notification (TCN)
Hello everybody. I’m new here, this is my first post
I have a question on the mac address table flush.
I don’t understand if a switch flush the cam table when receveid a topology change notification (bpdu with bpdu type field changed) or it will flush the cam only after it received a configuration bpdu from Root with topology change flag field set?
Thanks a lot.
Once the root bridge is aware of a change in the topology of the network, it sets the TC flag on the BPDUs it sends out, which are then relayed to all the bridges in the network. When a bridge receives a BPDU with the TC flag bit set, it reduces its bridging-table aging time from 300 seconds to 15 seconds. This ensures a relatively quick flush of stale information.
I hope this has been helpful!
OMG I just found I missed a small paragraph that has me confused about Max Age Timer and the Mac Address Timer.
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).
So I am confused now, and need help understanding.
if the max age timer is the 20 seconds is this the 20 seconds blocking timer at the first.
edited For my notes: the Max age timer has nothing to do with mac address aging. it has to do with the time that the switches wait before sending a topology change. basically the hello packets(BPDU) are sent every two seconds after 20 seconds it initiates a topology change. which starts the forward delay.
If that is the 20 second block timer at the first then where is the timer for 15 seconds the mac age before its dropped.
if the entire process is 50 seconds max age timer(20s)>(listening(15s)>Learning(15s) then finally it starts forwarding and has is considered converged where does that mac address aging of 15 seconds fit in???
it obviously has to fit into either the listening or learning or the math does not add up someone please explain this as I just confuzzled myself!
ok may be on a lead just found the following:
The Forward Delay The Forward Delay is the time that is spent in the Listening and Learning state. When the port transitions to the Listening state, it indicates a change in the current Spanning Tree topology and that the port will go from a Blocking state to a Forwarding state. The Forward Delay is used to cover the period between the Blocking and Forwarding states, which includes the Listening and Learning states.
This time is set to 15 seconds (sec) by default but can be manually set to be between 4 and 30 seconds.
Tafa, Farai. Cisco CCNP SWITCH Simplified (Kindle Locations 2039-2043). Reality Press Ltd. Kindle Edition.
in addition, if we want to look at the forward delay default timer it can be seen and computed below:
Assuming all the default values, we can calculate the Forward Delay as follows:
Forward Delay = ((4 * hello) + (3 * Diameter)) / 2
Forward Delay = ((4 * 2) + (3 * 7)) / 2 Forward Delay = ((8) + (21)) / 2
Forward Delay = (29 / 2 Forward Delay = 29 / 2)
Forward Delay = 14.5 seconds (rounded up to 15 seconds)
Tafa, Farai. Cisco CCNP SWITCH Simplified (Kindle Locations 2045-2050). Reality Press Ltd. Kindle Edition.
that says the forward delay by default in a single switch is 15 seconds which would seem to say that the total time for listening and learning was 15 seconds on a single switch anyway. There is more information about message age timer that is increased per switch I am still banging my head against wall trying to figure out that detail. will report back findings.
The Message Age timer is used in conjunction with the Max Age timer.
Tafa, Farai. Cisco CCNP SWITCH Simplified (Kindle Location 2025). Reality Press Ltd. Kindle Edition.
so I cannot figure this out. it sounds like the default diameter which is what sets the message age timer has to do with covering the listening and learning stage and is part of the forward delay but I don’t know its confusing.
Whatever the case mac address aging is handled during this time and it seems that message age timer is in here as well and it has a default diameter of 7 but it depends on the amount of switches you go through on actual time. all that gobbly goop adds up to the listening and learning stage.
So uplinkfast basically cuts out most of that time allowing for very quick convergence. partially by getting rid of mac addresses which are part of the forward delay but also cuts out the rest by saying use me immediately basically in the code.
backbone fast on the other hand just cuts out the max age timer and does not wait on the loss of hello(BPDU) packets by sending RLQ to the root and once it gets its reply it moves the forward delay state immediately. It does nothing about the forward delay which comprises the mac address table and other gobbly goop like the message age timer.
someone should right a simple detailed engineering spec on that process so we have granular detail or maybe after we looked at it we would not want to know lol…
What are the scenarios when the TCN bit is set or a TCN BPDU is sent by a switch? Is it only when a port goes down or comes back up in a switch or even when a root bridge gets updated in a switch?
The TCN bit is set when:
* An interface that was in forwarding mode goes down.
* An interface goes into forwarding and has a designated port.
Changing the root bridge does not trigger setting the TCN bit directly but it is possible that the TCN bit is set because of interface state changes that occur because of a new root bridge.
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 that a switch should never expect to see a TCN on a root port, unless that path to the root bridge has gone down (or unless it originates from the root bridge itself). Would that be correct?
@ReneMolenaar Please could you comment on this?
I borrowed the CCIE book from a colleague and after reading the relevant section, I’m quite convinced the article is wrong.
Thanks for the discussion. It’s always good to dig deep and find out what’s really going on in all aspects.
If the root port on SW1 goes down it MUST send TCNs. From the moment there is a topology change of any kind, TCNs are sent. This is a fundamental part of STP. However, at the same time, inferior BPDUs are sent as described in the article you sent to make STP re-converge correctly. The sending of TCNs and inferior BPDUs are not mutually exclusive.
Remember that in the stable configuration, SW2 had Fa0/14 as its root port. When it received the TCN from SW1, it was informed that it was the root port of SW1 that had gone down. Therefore, the new cost to the root bridge via that path is infinite i.e. unreachable.
So, it has to choose an alternate root port. It knows the cost via Fa0/19 is the next available option, so it changes its root port accordingly.
You’re right that a topology change alone is not enough to cause a root port to change unless that topology change informs a switch that its path to the root bridge is no longer available via the current root port. This is learned via TCN.
I hope this has been helpful!
Thanks for the reply Laz.
According to this article, switches in a spanning tree topology send TCNs out of their root port. In the scenario, SW1’s port fa0/14 is not a root port therefore it shouldn’t send a TCN out of that port.
Or is it the case that if a switch detects that it’s root port has gone down, it sends a TCN out of designated ports instead?
These are the tiny little details that make STP operation very hard to master
I tested myself the scenario, in the event if links towards root bridge or say rootport is down, it will first send inferior BPDU and when it figures out the Root switch via alternate port then that alternate port will become the root Port and then it will send Topology Change notification messgae on that.
here is the log below
Enter configuration commands, one per line. End with CNTL/Z.
*Mar 1 00:39:59.363: STP: VLAN1 Fa1/1 -> blocking
*Mar 1 00:39:59.363: STP: VLAN1 we are the spanning tree root
*Mar 1 00:40:01.283: %LINK-5-CHANGED: Interface FastEthernet1/1, changed state to administratively down
*Mar 1 00:40:02.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/1, changed state to down
*Mar 1 00:40:16.051: STP: VLAN1 heard root 8192-c405.4364.0000 on Fa1/0
*Mar 1 00:40:16.051: current Root has 32768-c403.4f94.0000
*Mar 1 00:40:16.051: supersedes 32768-c403.4f94.0000
*Mar 1 00:40:16.055: STP: VLAN1 new root is 8192, c405.4364.0000 on port Fa1/0, cost 57
*Mar 1 00:40:16.055: STP: VLAN1 sent Topology Change Notice on Fa1/0.
Below is the scenario i used
SW 1 (f1/0) --------------connected to F1/0 (Sw2)
SW1 (f1/1) --------------connected to F1/1 (Sw3)
SW2 (f1/1) --------------connected to F1/1 (SW4)
SW3 (F1/0) ----------------connected to F1/0 (SW4)
It is a box type connection, you can draw on paper
I shut down port f1/1 of sw2 going towards root switch (SW4) on port f1/1
Everybody talks about a link breaking down when it comes to Topology Change. Can i know what exactly happens when a new switch is added to current STP topology.
- 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)
- I am pretty sure that TCN message won’t be sent to root by adjacent switch because nothing to be erased from MAC Addr table(whole purpose of TCN message). Please confirm my understanding on this!
- will there be a RB election process again?
Thanks for your reply in advance!
I will also work it out in my lab by enabling “debug spanning-tree events” command.
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:
- The new switch considers itself the root bridge. The port on which it is connected to the other switch will begin briefly in the blocked state as you mentioned.
- Next, that port will transition to the Listening state. During the listening state, BPDUs are exchanged. Note that both ports on both ends of the link will be transitioning from state to state at the same time assuming the timers are the same, so both ends will be in the Listening state as they exchange BPDUs. During the BPDU exchange, the new switch will learn if it is indeed the root bridge or if the current root bridge will remain, depending on the priority values and the MAC address.
- If the new switch is not the root bridge, its port will assume a role of root port while the interface at the other end of the link will assume a role of designated. (assuming no L2 loop is created with the new switch).
- if the new switch is the root bridge, the port becomes designated and superior BPDUs are sent on the link which will cause the rest of the switches to re-converge their STP orientation.
The ports continue to transition until the topology converges.
The conditions under which a TCN is sent are very specific and they are stated in detail by Cisco. Cisco states:
A bridge has detected a topology change:
- When a port that was forwarding is going down (blocking for instance).
- When a port transitions to forwarding and the bridge has a designated port. (This means that the bridge is not standalone.)
Once a topology change has been confirmed, a TCN will be sent.
The process to send a notification to all bridges in the network involves two steps:
- The bridge notifies the root bridge of the spanning tree.
- The root bridge “broadcasts” the information into the whole network.
It is only under those circumstances that a TCN is sent. It does not specify that a TCN is sent only if there are actual MAC addresses in the MAC address table of the new switch that is being connected. It doesn’t take this into account. A TCN will be sent and the aging time will be reduced regardless of whether or not there are actually new MAC addresses to be learned.
Yes there will be. As stated at the beginning, BPDUs will be exchanged and if the priority and MAC address of the new switch are indeed superior, then yes, an election and a subsequent STP reconvergence will take place.
I hope this has been helpful!
One question. What’s the point of clearing the ARP cache (default timeout 300s) on a TCN? Once an address expires, don’t you just fetch it from the ARP table again (timeout 4hours)? Or do the 15 second timers apply to both the ARP cache and table?
I am guessing that there is no ARP even if the 15 seconds duration expires since the ARP timeout is 4 hours.
Any clarification here would be helpful.
When a TCN is recieved, it’s not the ARP table that is cleared, but the MAC address table. The ARP table remains intact. The purpose of clearing the MAC table is that MACs of devices not directly connect to a particular switch may appear to be associated with an incorrect port on that switch if a topology change takes place. If this is the case, you have to wait 300 seconds for the MAC address entry to expire before that particular MAC address is correctly updated in the table of that particular switch. The result is having STP reconverge in several seconds, but having to wait up to 300 seconds for the correct MAC address table entries to converge.
I hope this has been helpful!
my question is when the switches set the mac address table aging time to 15 seconds?
when they receive a TCN from any switch? When they receive a TCA from root bridge or when they receive a TC from the root bridge?
Thanks in advance.
According to this Cisco documentation, aging time is reduced to 15 seconds by switches when they recieve the TC from the root bridge.
I hope this has been helpful!