Quantcast
Channel: IEOC - INE's Online Community
Viewing all articles
Browse latest Browse all 10744

RSTP - Inferior BPDU

$
0
0

Hi, sorry for so many mesages on RSTP, the info on the internet is completely vague, including the latest ccie v5 ine video actually, so it poses many questions.

In the topology in this link (http://gyazo.com/34953af31de3588392d4369496fdbf69), would someone be able to go through precisely what happens if the link between Sw1 and Sw2 goes down please? Or just explain the question below.

How I understand it is that when the link goes down, Sw2 elects itself as root bridge, sends a configuration bpdu to Sw4 with the proposal bit set and Sw4 does not agree on who Sw2 thinks is the root bridge, so sends an alternate proposal, listing Sw1 as the root. Sw2 sends an agreement to Sw4 and moves its port into into the root role and forwarding state.  At the same time, Sw2 put the port role into designated forwarding.  

Because a port moved into forwarding state on Sw2, Sw2 generates a bpdu with the tc bit set & send's it outbound toward sw4. Sw4 flushes it's cam table for the port connecting to Sw3 and sends a bpdu with the tc bit set toward Sw3, who repeats the proceedure towards Sw1. Now then, what happens in terms of rstp synchonisation when a tc-bit is seen in the bpdu?  Does it force all the switches upstream from Sw4 to then re-sync their point-to-point links? If so, that makes sense because the altn port on sw4 needs to change to a root port.  But I want someone to verify that either the bpdu with the tc-bit set caused all upstream switches to re-sync, OR whether this re-sync process happenes due to one link on Sw4 re-synching?


I hope my question makes sense.

 

Thx,

Steve


Viewing all articles
Browse latest Browse all 10744

Trending Articles