RSPT question

[cristip]

When a RSTP bridge detects a topology change:

?It starts the TC While timer with a value equal to twice the hello time for all its non-edge designated ports and its root port if necessary.

?It flushes the MAC addresses associated with all these ports. Excepting the port that received the TCN

My question: why would the switch keep in CAM the very addresses learned through the port that received a TCN ? Obviously on that branch of the STP tree something happened and I would rather keep the addresses learned through the other ports

Thank you

Cristian

[Francois Tallet · Accepted solution]

In an L2 network, there is always a unique path between two devices. That's in fact the definition of a tree, and STP just block some ports to reduce the network to a tree, that provides at least the same connectivity as the physical network. When this tree is recomputed, typically as a result of a link coming up or down, the path between two devices may change. From the point of view of a bridge, a host that used to be reach over one particular port is not reachable through another port. Practically, it means that a mac address that was learnt on a port might need to "move" to another port. That's for the general introduction;-)

Now, RSTP is particular in the way that it only generates a topology change as a result of a port going up, adding connectivity. The idea is that, if a link is going down, the tree is split and you have two solutions:

- there is no redundancy, in which case there is no need to flush any mac address because the host that are in the now remote part of the network will not be reachable any more, regardless of the cam entries associated to them.

- there is redundancy, in which case RSTP will unblock a port, i.e. put a port to forwarding, i.e. generate a topology change.

Another difference between RSTP and STP is that the topology change indication (TC) is now originated from the port that is coming up.

So, when you received a TC on a port X, this port is on the (unique) path to a port Y that has just come up. It means that we are adding connectivity on this port: more mac addresses are now reachable through X. Those mac addresses could have been learnt on some other ports on the same bridge and could lead to black holing -> you need to flush those mac addresses on the *other* port. You don't need to flush the addresses on the port that has received the topology change, because none of them are leading to the wrong direction. A mac address on this port X could only be in the wrong direction if a host that was learnt on X was now reachable through a port Z on the switch. If this was the case, port Z would receive a topology change;-) So in fact, mac addresses on port X are the only one that can be preserved when you received a topology change on X (well, edge port are not flushed either).

That was a longer explanation than I thought would be necessary when I started typing;-) I hope it makes sense, let me know.

Regards,

Francois

[cristip]

Hi Francois

Thank you very much. This is clear now. Can you please comment on this

"If a designated port receives an inferior BPDU (higher switch ID, higher path cost, and so forth than currently stored for the port) with a designated port role, it immediately replies with its own information. "

can you please explain what kind of packet is this ? Of course it must be a BPDU but...is it a proposal or just a regular RSTP BPDU ?

[Francois Tallet]

Hi Cristian,

Actually, I don't think the RSTP code is going to answer immediately to this BPDU, I think it will just wait for its next hello-time expiry.

Anyway, to answer your question, this BPDU is a regular BPDU from a bridge that has not received yet the superior information of the designated port of the segment.

For instance, imagine a link coming up between two bridges. Port A and B are at then end of this link and Port A has better information (it will become designated eventually). When Port B is coming up, it is not aware of A's information. As a result, it will send one such "inferior" BPDU to A, that will simply ignore it. When B has heard from A, its role will be anything but designated and the condition you mention cannot happen any more. So it should be only a transient situation.

BTW, imagine that this condition is carrying on for a while, i.e. B does not hear from A because there is a unidirectional link failure (traffic can go from B to A but not from A to B, and the link is still declared up on both side). B is slowly transitioning from designated discarding to designated forwarding, through the listening and learning stages. The learning and forwarding bits in B's BPDU allow A to track this transition. A will keep receiving worse designated information from its neighbor B. As soon as B sets its learning bit (meaning that B has not received A's BPDU in 15s - forward-delay), A will consider this as an error and will enter the disputed state. This "dispute" mechanism will keep A in a discarding state as long as B does not acknowledge its information. This efficiently protects against unidirectional link failures that could have opened a one-way bridging loop. Note that this mechanism is currently only implemented by default in our MST code (Rapid-PVST does not have it yet) and that it replaces efficiently a feature like loopguard.

Regards,

Francois

[cristip]

Hi Francois

I have received very good answers from you regarding Switching topics (STP, RSPT MSTP and so on). Could you please indicate a good book or materials published on www.ciso.com where all these topics are treated with in depht details. I see that there is an other person here asking for MST for instance.

So far I have not seen a book or anything else that describes all the Spanning Tree flavours in detail starting with the election of the root switch and ending with topology changes and situation were the STP recalculation is needed. It is frustrating to try to deduct the way the different algorithms work instead of reading the documentation for these algortims.

I would very much appreciate if you can recommed us such materials.

Thank you very much

Cristian

[Francois Tallet]

Thanks for your comments Cristian.

Unfortunately, I don't know any really good book on recent STP protocols (RSTP/MST). I used to really love the Cisco LAN Switching book, but it's starting to be outdated and is mainly CatOS centered. That's still the most exhaustive reference I know of on PVST at least. I've written two white papers that are available on CCO:

http://www.cisco.com/warp/public/473/146.html

http://www.cisco.com/warp/public/473/147.html

But they are really high level (hopefully, because they were written with the Cisco pre-standard implementation in mind;-). Most of the papers on CCO are variation over those white papers and don't go deeper into the subject.

I can remember that there was a Cisco press book that had a short section on Rapid-PVST and MST. I think it was a CCNA preparation book. It was still high level but well written. That's about all I know:-( In fact, if someone out there has a good reference, I'm also interested.

I'm monitoring the Netpro forum and if the title of your question has a keyword that is STP related, I'll see it and try to answer the best I can in the meantime!

Regards,

Francois

[Kevin Dorrell]

Nice documents Fran?ois!

The 2nd edition of the CCIE Cert Exam Guide has short sections on RSTP and MST, but they are a bit summary. Your docs are the best I have seen so far on the subject.

There were once rumours of a new edition of the Clark / Hamilton book, but I have never seen it materialise - it is desperately needed. (along with an update to Beau Williamson's multicast book).

Looking at a few books in Safari, the new BCMSN book, published in February this year, has quite a good description of the subject.

Kevin Dorrell

Luxembourg

[Francois Tallet]

Thank you Kevin. The CCIE Cert Exam Guide is probably the one I browsed through. I'll check the BCMSN book on Safari, thanks for the pointer.

I was contacted by Kennedy Clark end of 2002 for the 2nd edition of the Cisco LAN switching book. He had put a lot of work in his first book and was not sure he was ready to start over. I've not heard of him again and I guess he has abandoned the project by now.

Regards,

Francois