STP tcn-bpdu's

EdTheLad

A bridge will originate a tcn bpdu in two conditions
1) It transitions a port into the forwarding state and it has at least one designated port.
2) It transitions a port from learning or forwarding to blocking state.

So after the root receives the propagated tcn bpdu it sends config bpdu's with the TC bit enabled which causes all other bridges to age entries in the mac table to the forwarding time.

Now i can see why (2) occurs, to flush entries in the mac table that are no longer reachable.
But why bother flushing the mac table if a port transitions to forwarding state? Due to the nature of the stp a loop cant exist so why flush the mac tables? and why only if there is an additional designated port on the bridge in question?

I've been trying to rack my brain for an answer but its not coming!

Webmaster

I probably shouldn't be trying to answer CCIE questions, but I happened to be working on STP last week so I gathered a bunch of links and cisco articles. I hope the following link will be of help, the Principle of Operation section in particular, the line just above it, and the conclusion:

www.cisco.com/warp/public/473/17.html

and why only if there is an additional designated port on the bridge in question?

From that link above: This means that the bridge is not standalone. So no need to send if it doesn't have at least one remaining active designated port.

EdTheLad

and why only if there is an additional designated port on the bridge in question?

From that link above: This means that the bridge is not standalone. So no need to send if it doesn't have at least one remaining active designated port.

Thanks for the link Webmaster, ok i got the wrong end of the stick thanks to the common
misuse of terms on cisco documents that cause me to go in endless circles.I wasnt thinking along the lines of a standalone switch because if a switch has one path to the root bridge via one port this is a root port not a designated port.
I was thinking there had to be a root and an additional designated port to cause the tcn bpdu transmission.
I wish the cisco authors would stick to the correct terminology!

EdTheLad

I still dont see why a port transitioning to the forwarding state causes a tcn bpdu to be sent.If the new port added is just an edge branch it wont effect the network.If the new port added caused an existing link to transition from forwarding to blocking the link that transitions to blocking would send a tcn bpdu, so under what condition is the tcn bpdu sent for a forwarding transition benifical ?

DW [banned]

Lots of fun days...

Webmaster

Cisco wrote:

Accelerated Aging to Retain Connectivity
The default for aging dynamic addresses is 5 minutes, the default setting of the mac-address-table aging-time global configuration command. However, an STP reconfiguration can cause many station locations to change. Because these stations could be unreachable for 5 minutes or more during a reconfiguration, the address-aging time is accelerated so that station addresses can be dropped from the address table and then relearned. The accelerated aging is the same as the forward-delay parameter value (spanning-tree vlan vlan-id forward-time seconds global configuration command) when STP reconfigures.

The conclusion in that doc I linked to says a TCN doesn't cause a recalculation, but it is the result of a topology change. But whether a link goes up or down, a 'cheaper' path (through a different port) for certain addresses could become available, the aging is accelerated so they can be relearned for the ports on which it actually receives traffic for those mac entries. It seems the TCN is in addition to the regular STP process, merely to help speed up the refreshing of MAC table, whether a link came up or went down, it may have changed the topology in such a way that mac entries are no longer valid. The doc I linked to includes an example right above the Purpose of the Topology Change Mechanism, but here's perhaps a better link, it includes topology changes with links going up. Kinda nicely and logically goes over into PortFast.
http://www.ciscopress.com/articles/article.asp?p=426642&seqNum=2&rl=1

In short: regardless of a link going up or down, the STP process causes a port to go into certain state. For certain switches, this could result into a cheaper part becoming available, putting another port in blocking mode. Hence mac entries to that blocking port become invalid.

so under what condition is the tcn bpdu sent for a forwarding transition benifical ?

An example is in this section:
www.cisco.com/warp/public/473/17.html#topic1

Imagine the link coming back up between B2 and B3, STP converges, and traffic from A to B 'should' go through B1, B2, B3, and then B4 again, as it originally did. (probably be a 10 mb between b1 and b4 and gb links between the others , or manually configured costs..) However, B's mac address would remain in B1's forwarding table, pointing to the interface for the link between B1 and B4 (which is now blocking) for 5 minutes tops if it wouldn't be aged by the TCN notification.

So from the two conditions in your first post:

bridge will originate a tcn bpdu in two conditions
1) It transitions a port into the forwarding state and it has at least one designated port.
2) It transitions a port from learning or forwarding to blocking state.

1) can cause 2)

EdTheLad

Webmaster wrote:

An example is in this section:
www.cisco.com/warp/public/473/17.html#topic1

Imagine the link coming back up between B2 and B3, STP converges, and traffic from A to B 'should' go through B1, B2, B3, and then B4 again, as it originally did. (probably be a 10 mb between b1 and b4 and gb links between the others , or manually configured costs..) However, B's mac address would remain in B1's forwarding table, pointing to the interface for the link between B1 and B4 (which is now blocking) for 5 minutes tops if it wouldn't be aged by the TCN notification.

So from the two conditions in your first post:

bridge will originate a tcn bpdu in two conditions
1) It transitions a port into the forwarding state and it has at least one designated port.
2) It transitions a port from learning or forwarding to blocking state.

1) can cause 2)

My issue is more regarding why cisco envisioned the need to send tcn bpdu's for a port going into the forwarding state AND the blocking state.From your example if the link comes back up between B2 and B3 it will eventually transition to forwarding state and this will cause the link between B1 and B4 to transition to blocking state.
The tcn bpdu's will be sent in two cases here, for the port moving to forwarding state and also the port moving to blocking state,so effectively the same job is being done twice.If a port moves into a forwarding state and effects the topology as you have indicated above,it will always set another port to blocking state, so sending tcn bpdu's for a port making a blocking transition is all that is needed
If a new switch is connected to the existing network i.e. a port on an existing switch goes into the forwarding state i really cant see why a tcn bpdu is needed as this new switch doesnt conflict with the entries already known by the network.
So my question isnt about how it works but more about why its implemented like this.Knowing these intragite details help me to remember afew months from now.

sexion8

EdTheLad wrote:

So my question isnt about how it works but more about why its implemented like this.Knowing these intragite details help me to remember afew months from now.

I look at it as a method to maintain topology states "briefly" without having to go through the entire process. An affected machine sends the root bridge information only relevant to the affected ports... Since only the root bridge can send out topological updates, tcn's keep telling root "something is wrong... something is wrong" so the root can propagate this information to others before the others get into issues blocking, learning, etc., think of it as a pre-emptive strike if you will.

Look at what would happen without a tcn... (maybe it would make it clearer)
maxAge = 20 ... listeningMode = 15 ... forwardDelay = 20

20+15+20 = 55 seconds from blocking to forwarding... Should the network see a topological change... With a tcn, (pre-emptive strike) the root notifies everyone so they won't have to recalculate STP...

mikej412

EdTheLad wrote:

If a new switch is connected to the existing network i.e. a port on an existing switch goes into the forwarding state i really cant see why a tcn bpdu is needed as this new switch doesnt conflict with the entries already known by the network.

But how does it know its a new switch?

host -- sw1 -- sw2 -- sw3 -- sw4 -- sw5 -- sw6ROOT -- sw7

unplug the link(s) between sw2 and sw3 and plug it into sw7.....
sw4 & sw5 had the host mac in its mac address table going out the "downstream designated ports." Switch 3 knows it lost the host macs on the old designated part.... but what about the other switches?

When you plug sw2 into sw7, you want all the switches to figure out all over again where all the host macs are.

From a programmer perspective -- the hosts are playing musical chairs. Some of the hosts are still in their same old chairs (and are cheating by not getting up), but some hosts traded chairs or don't have a chair now -- so you have to figure out again where everyone is.

EdTheLad

sexion8 wrote:

EdTheLad wrote:

So my question isnt about how it works but more about why its implemented like this.Knowing these intragite details help me to remember afew months from now.

I look at it as a method to maintain topology states "briefly" without having to go through the entire process. An affected machine sends the root bridge information only relevant to the affected ports... Since only the root bridge can send out topological updates, tcn's keep telling root "something is wrong... something is wrong" so the root can propagate this information to others before the others get into issues blocking, learning, etc., think of it as a pre-emptive strike if you will.

Look at what would happen without a tcn... (maybe it would make it clearer)
maxAge = 20 ... listeningMode = 15 ... forwardDelay = 20

20+15+20 = 55 seconds from blocking to forwarding... Should the network see a topological change... With a tcn, (pre-emptive strike) the root notifies everyone so they won't have to recalculate STP...

My question is in regards to a tcn bpdu being sent during a transition from forwarding to blocking, i am not asking WHY tcn bpdu's are used.From your description i think you needto read a little more about this as tcn's are used to decrease the age of the mac table of the switches in the network from 300 sec to the forwarding time, it has nothing to do with the time to transition a port from blocking to forwarding.I think you are getting confused with backbonefast.

EdTheLad

mikej412 wrote:

host -- sw1 -- sw2 -- sw3 -- sw4 -- sw5 -- sw6ROOT -- sw7

unplug the link(s) between sw2 and sw3 and plug it into sw7.....
sw4 & sw5 had the host mac in its mac address table going out the "downstream designated ports." Switch 3 knows it lost the host macs on the old designated part.... but what about the other switches?

When you plug sw2 into sw7, you want all the switches to figure out all over again where all the host macs are.

From a programmer perspective -- the hosts are playing musical chairs. Some of the hosts are still in their same old chairs (and are cheating by not getting up), but some hosts traded chairs or don't have a chair now -- so you have to figure out again where everyone is.

Ah nice example Mike,this has triggered my brain.I was thinking along the lines that if you disconnected the link between sw2 and sw3 the ports on either side of this link would be blocked and trigger a tcn to clear the mac tables so a tcn isnt needed for the forwarding transition.This is not the case at all,if these switches were connected via a hub for instance ,disconnecting sw2 could cause the port on sw3 to go into forwarding state and then reconnecting sw3 to sw7 would again transition a port to forwarding state so effectively there is no port transition to blocking.

Humper

mikej412 wrote:

EdTheLad wrote:

If a new switch is connected to the existing network i.e. a port on an existing switch goes into the forwarding state i really cant see why a tcn bpdu is needed as this new switch doesnt conflict with the entries already known by the network.

But how does it know its a new switch?

host -- sw1 -- sw2 -- sw3 -- sw4 -- sw5 -- sw6ROOT -- sw7

unplug the link(s) between sw2 and sw3 and plug it into sw7.....
sw4 & sw5 had the host mac in its mac address table going out the "downstream designated ports." Switch 3 knows it lost the host macs on the old designated part.... but what about the other switches?

When you plug sw2 into sw7, you want all the switches to figure out all over again where all the host macs are.

From a programmer perspective -- the hosts are playing musical chairs. Some of the hosts are still in their same old chairs (and are cheating by not getting up), but some hosts traded chairs or don't have a chair now -- so you have to figure out again where everyone is.

Ahhh, just what I had been thinking as soon as I read Ed's post. This is a great post, always good to read these forums as it does a great job of refreshing your memory if you haven't studied switching in a while

Rejith Rajan

1) It transitions a port into the forwarding state and it has at least one designated port.


This statement simply means that TCN BPDU is only send if a non-edge port goes to forwarding state.An edge port will not have a DP.While a non-edge port would have either a DP or NDP .