rapid spanning tree topology change

cdntester · ‎12-22-2005

Hi,

my question is about rapid spanning tree operation.

Assume a RSTP topology as : 1-2-3-4-5-6-7-8-9-R

,where R is the root bridge of the switched network

and 1,2,3,4,5,6,7,8,9 are bridges connected through "-", so

that the active switching path towards R for all bridges passes through bridge 9. Let the delay for a bridge to switch a frame from one port to another is 1 sec

Now assuming that bridge 1 had a link to

R which just came up: R-1-2-3-4-5-6-7-8-9-R (R appears twice but actually consider it as the same one bridge)

According to 802.1w standard and cisco on line documentation, R will negotiate with 1 to block its port with 2 before R starts forwarding on its port connected to 1, 1 with 2 and so on(proposal-agreement mechanism).

Let now this new path, is selected only from 1 and 2(let 2 block its port with 3 and 3 will be the designated for the ethernet segment between 2 and 3).

According to 802.1w, 1 will Tx a BPDU with TC flag = on through R (so that all rest bridges notified for the topology change and flush their dynamic CAM table entries) immediately when 1 put its port towards R to Forwarding. No other bridge (neither 2 when blocks its port with 3) will Tx a BPDU with TC flag on.

Assuming that bridge 2 has also a port where host H1 connects to so that H1 Tx a broadcast frame just before bridge 1 negotiates with 2(proposal-agreement)t.e. before bridge 2 blocks its port with bridge 3 and bridge 1 begins forwarding on its port to R, then :this frame that just Txed ,travels towards R through bridge 3.

this frame will be Rxed by bridge 1 and bridge 2 after 8 and 9 seconds respectively, since bridge 1 after this time period has put its port to R in forwarding already.

The BPDU with TC flag set,Txed by bridge 1, will be arriving bridge 3, when the broadcast frame Txed by H1 arrives 1, travelling in oposite direction.

Since 1 and 2 have already flushed their CAM when H1's frame arrives they will record the MAC address of H1 on a wrong port.

Am i missing something here?

smalkeric · ‎12-28-2005

In your explained scenario, you have mentioned that " R will negotiate with 1 to block its port with 2 before R starts forwarding on its port connected to 1, 1 with 2 and so on(proposal-agreement mechanism".

A root Bridge will not have any of its port into blocked state. So, Root Bridge will have all its ports in forwarding state.

Francois Tallet · ‎12-28-2005

I guess the designated port mentioned there is just blocking temporarily.

The fact that the root bridge cannot have a blocked port is purely mythical btw;-) With RSTP, there is now a distinction between alternate and backup ports that did not exist with STP. Sure, the Root bridge cannot have alternate ports, but it may definitely have a backup port, which is certainly "blocking" (the IEEE term is now "discarding").

Regards,

Francois

Francois Tallet · ‎12-28-2005

Several ports will generate a topology change. The designated port on R will generate a TC when moving to forwarding for instance. Anyway, the problem you mention seems to be related to the unrealistic transmission delay that your bridges introduce. The STP protocol bounds the process time for control traffic. I don't know exactly if the data traffic is covered in the spec, but if you assume that your network can "buffer" tens of seconds of traffic, then I don't see why you would not hit this issue. With this kind of performance in data transmission, you probably do not need RSTP btw. The spec itself conveniently falls back to STP whenever that kind of problem occurs (for the potential out of order or duplicate packets with RSTP for example).

Regards,

Francois