TCN BPDU question

[Ross_Kitsis]

Hi All,

I'm currently having an issue between two switches incorrectly communicating via MSTP. The switches are connected via two cables, one being the primary link and another a secondary link. As expected MSTP causes the non-root bridge to place the secondary port into a blocking state to prevent any loops.

The problem occurs when the I take the primary connection down, I expect that the non-root bridge should realize BPDUs are no long coming in, when this happens it should send out a TCN BPDU and after the root acknowledges and propogates the change the backup link should take over and the primary link should now be down/disabled.

Instead to non-root bridge does not acknoledge the change with a TCN BPDU, it places the blocked port into a forwarding mode and appears to being sending its own BPDUs.

I am not particularly familiar with MSTP but from what I can tell settings appear to be correct, at least correct enough for MSTP to converge. Any idea as to what might cause this type of behaviour? Can the switch be configured not to send TCN BPDUs?

Thanks all,

Rostislav

[Giuseppe Larosa · Accepted solution]

Hello Rostislav,

MST is based on rapid spanning tree

you may find useful the following links

Rapid STP 802.1W

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml

MST 802.1s

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfc.shtml

With rapid STP in the given topology the secondary switch can negotiate a port state change on the secondary link with the use of the proposal mechanism and the primary switch can acknowledge this.

Actually  the secondary link is in discarding state,  but it has  an alternate root port role (see the distinction between port states and port roles in first link) that can be used immediately  if the primary link fails. This is part of the characteristics of Rapid STP.

Hope to help

Giuseppe

[Ross_Kitsis]

Thanks for the reply, one more question. From the behavior I am seeing it looks like something might be interrupting the port state change negotiation. The blocked port seems to change its state however it seems like the other switch is not acknowledging the change. Is there anything that could cause this type of behavior?