STP behaviour

[anazarenko]

Assume my topology looks like on the diagram below, it's running RSTP

SW1 ---- SW2---- SW3 (root)

       \       /

        SW4

SW4 has Alt. blocked port towards SW1.

I do shutdown for interface on SW1 towards SW4, wich is in DESG state, will SW1 generate TCN?

[johnlloyd_13]

hi,

yes, it will send a TCN out on its root port. the receiving switch (SW2) is called the designated bridge and it acknowledges SW1's TCN by immediately sending back a normal BPDU with the topology change acknowledgement (TCA) bit set. this exchange continues until the root bridge (SW3) responds.

[anazarenko]

I was thinking the same, but in my case C6500 doesn't send TCN. TCN is really not important in this scenario, but how SW1 can be aware that port is really blocked by SW4.

Or does Catalyst check FDB  entries on affected port before generating TCN upstream? If it's so, it's something new for me.

[johnlloyd_13]

Hi,

I suspect the C6500 has a port configured with portfast that's why you don't see the TCN.

Please find useful link below to help you understand its operation:

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

Sent from Cisco Technical Support iPhone App

[rsimoni]

Hi all,

please note that RSTP introduced an important change on how TCN's are handled.

With legacy 802.1D when port moves to forwarding or blocking, bridge originates a TCN BPDU towards the Root bridge.

With RSTP TCN's are generated on link moving to forwarding only (not to blocking anymore).

SW1 is not generating TCN as its link is moving to blocking (admin down) and not to forwarding.

regards,

Riccardo

[anazarenko]

Dear Ricardo,

This explains much. But how does RSTP ensure when the active topology looses one of the links to flush old MAC addresses? Comparing with STP, there's a much more chance for traffic to be blackholed instead of unknown unicasted.

[anazarenko]

I will try to answer myself. When the transit link comes down and there's alternative path available, TCN will be generated when alternative path comes into forwarding state.

[johnlloyd_13]

Hi Riccardo,

This is a good refresher for me +5.

"In RSTP, only non-edge ports that move to the forwarding state cause a topology change"

I missed out the RSTP part and the legacy STP was stucked in my head.

Sent from Cisco Technical Support iPhone App

[rsimoni · Accepted solution]

Hi,

the main difference on how L2 table gets flushed is that the switch which first triggers the TC flushes the table

for all its non-edge designated ports and its root port while the switch(es) which receives a TC flushes its table immediately for all its ports excluding the one it received the TC from.

The advantage is that the switches don't have to wait for the root bridge to send BPDUs with TC flag which change the table aging to fwd_delay value.

Flushes occur immediately instead of waiting for fwd timer ensuring avoidance of wrong l2 info. Drawback is a temporary flooding while all macs get re-learned, but this is negligeable.

In case of SW1 since the link SW1-SW4 was blocked on SW4 side no mac was learned from SW1 side in the first place. So the status change did not cause any issue and the mac flushing was not needed.

@ John too

a good refresher with more details is on this page (far better than my post )

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

Riccardo