[Rstplib-users] RE: Question: indirect link fail in 802.1w

[<al...@nb...>]

Mick,

The problem is not in hop to the Backup role, but in "late" hop to
Designated role: only when rcvdInfoWhile timer expires, while we
discard information, that may help in it. I again ask to read
http://www.cisco.com/warp/public/473/18.html, where the explanation
(for 1d) is more detail and clear. 

Thanks for the cooperation, Alex


> -----Original Message-----
> From: Mick Seaman [mailto:mic...@ie...]
> Sent: Wednesday, November 21, 2001 3:14 AM
> To: Ar...@op...; std...@ie...; 
> rst...@li...; bri...@ie...
> Subject: RE: Question: indirect link fail in 802.1w
> 
> 
> Alex,
> 
> I suggest you test this out using the RSTP Visio simulation.
> 
> The only case in which any of these ports could be Backup is 
> a deficiency in
> the spec or the interpretation of the spec, so extra protocol is not
> required.
> 
> Mick
> 
> -----Original Message-----
> From: own...@ma...
> [mailto:own...@ma...]On Behalf Of Alex Ruzin
> Sent: Tuesday, November 20, 2001 6:09 AM
> To: std...@ie...; rst...@li...;
> bri...@ie...
> Subject: Question: indirect link fail in 802.1w
> 
> 
> 
> 
> Question: indirect link fail in 802.1w
> 
> Initial configuration:3 Bridges (A, B, C) are
> connected as a triangle.
> Let's say, Bridge A is a Root Bridge and has
> 2 designated ports A1 and A2.
> Bridge B has root port B1 (connected with port
> A1) and designated port B2, connected with
> port C2. Bridge C has root port C1 (connected
> with port A2) and Alternate port C2 (connected
> with port B2).
> 
> Now the link between B1 and A1 fails :(
> Bridge B immediately detects the failure and
> assumes it is Root Bridge ( while it doesn't
> have any Alternate port) and starts to advertise
> via port B2 its own Priority Vector.
> 
> The problem is on the Bridge C. It receives on
> Alternate port C2 SuperiorDesignate Msg BPDU.
> It is because 17.19.8:"Designated Bridge and
> Designated Port components of the received message
> priority vector are the same as those of the port
> priority vector and the message priority vector as
> a whole or any of the received timer parameter
> values (msgTimes -see 17.18.12) differ from
> those already held in port-Times (17.18.18).
> 
> As a result port C2 goes to have Backup role.
> 
> Then, switch B continues to send its BPDU, but
> for C these BPDU are "Inferior" or, in terms of
> PIM, the function rcbBpdu returns OtherMsg. This
> messages are discarded by PIM and there are 3
> such messages (6 seconds !).
> 
> Only after that the rcvdInfoWhile timer expires,
> port C2 is aged, becomes Designated, makes
> 'handshake' with port B2 (which becomes Root for
> the bridge B), and everything is OK.
> 
> During about 6 seconds LAN, connected to C was
> disconnected from LAN, connected to B ! (Yes, I
> know, that in legacy STP such situation causes
> a delay 50 seconds: MaxAge + 2 * ForwardDelay).
> 
> IMHO, there may take place an optimization, The
> idea: don't discard BPDU when 'OtherMsg', but
> to start some "upstream' handshake (in addition
> to RSTP 'downstream' handshake for rapid
> transition Designating port to Forwarding state).
> Such 'upstream' handshake may be started, when
> SuperiorDesignate message was recognized by
> another Times and message Priority Vector is worse
> than a stored one.
> 
> This idea is similar to "Spanning-Tree Protocol's
> Backbone Fast Feature" of CISCO
> (see http://www.cisco.com/warp/public/473/18.html)
> 
> What do you think about it ? Does this idea break
> the concept of 802.1w ? Is it in the plans of the
> society ?
> What if I start to design such 'handshake' ?
> 
> Best regards, Alex
> 
>