DComTalk.com

I'm seeing reeeeeeeeeeally long recover times when I break a link in a
simple 4-switch ring managed by RSTP and I don't know what's not
working. I've got 802.1D-2004 open on my desk but it's, shall we say,
opaque. I hope someone here understands it enough to give me a
pointer.

I've got a ring like this:

+-------+ +-------+
| Sw1 | --------- | Sw2 |
+-------+ +-------+
| |
| |
+-------+ +-------+
| Sw3 | --------- | Sw4 |
+-------+ +-------+
| |
| |
+-------+ +-------+
| PC1 | | PC2 |
+-------+ +-------+

Sw1 is the root. PC2 constantly pings PC1. With everything connected,
the link Sw3/Sw4 is blocking and the normal path of these pings is PC2
-> Sw4 -> Sw2 -> Sw1 -> Sw3 -> PC1 (and back, of course).

If I break the link between Sw1 and Sw2, I lose connectivity (drop
pings) for nearly 2x the HelloTime of the network (3-6s for Hello = 2s,
1.7-2.3s for HelloTime = 1s).

When I break the link shouldn't the port state transition on Sw1 and
Sw2 cause them to tell Sw3 and Sw4, respectively, that "I'm not in the
path you want anymore?" Maybe Sw1 would think, "I'm still root, that's
cool." but shoudn't Sw2 tell Sw4, "I lost my path to root"
_immediately_ on loss of link on the port leading to Sw1? What I see
if Sw4 continuing to forward pings to Sw2 long after the Sw1/Sw2 link
is broken.

TIA.

I've got 802.1D-2004 open on my desk
but it's, shall we say, opaque

http://www.cisco.com/en/US/tech/tk389/t ... _home.html

Has an explanation that anyone can understand.

http://www.cisco.com/warp/public/473/146.pdf
May be more difficult however it should be more
rewarding too.

I have read much of 802.1d and found it difficult.
The purpose of these documents is to create an
unambiguous specification and not necessrily to
be a tutorial.