STP reconvergence

[visitor68]

Hi

I have 3 switches...

distro 1, distro 2 and access 1

d1 is root

d2 is sec

acc 1 is dual homed to d1 and d2

I run extended ping to d1 from acc1

I pull cable for acc1 to d1 connection

RSTP fails over to the acc1-d2 connection pretty quickly...lose a ping (uplinkfast)

when I plug the cable back in, it takes about 30 seconds to reconverge...I lose about 16 pings

the access switch is a non-cisco switch running IEEE rstp

Whats going on?

Thanks

[Shashank Singh]

Hi,

What is the link which is getting blocked initially before you pull the cable? d2-d1, acc1-d2 or acc1-d1?

Cheers,

Shashank

[visitor68]

Shashank:

access to d1 -- active

d1-d2 -- active

access to d2 -- blocked

I pull access to d1, it fails over to access to d2. It does this with only the loss of one ping.

I reconnect access to d1 and everythign stops for 30 seconds, and I lose 14 or so pings.

Thanks

[Shashank Singh]

Hi,

When you say that the link betwen d2 and acc1 is blocked, on which switch is the interface in BLK state? d2 or acc1?

acc1 is a non cisco switch and does not understand uplinkfast, right?

Can you remove uplinkfast from d2 and d1 and let me know the results?

Cheers,

Shashank

[visitor68]

Hi - the port on the cisco d2 switch is blocked.

uplinkfast is built-in to rstp on the Ciscos. I believe also on the non-cisco switch because uplinkfast has been incorporated into the rstp ieee standard. i dont think its called uplinkfast, but the functionality, i believe, is there...i have no way of disabling it...

as a test, i did enable portfast on the access to d1 link (both sides) and it has reduced convergence time considerably - lose only 2 packets altogether.

[Shashank Singh]

Hi,

Possibly uplinkfast is there in the IEEE flavour of RSTP but the problem indicates the other way round. when you break the link between the non cisco switch and the root, uplinkfast enabled cisco switch unblocks its interface in less than one second but when the link comes back up, it takes regular STP delay for the switches to recalculate the topology and block the interface on d2.

To be conclusive, we will need to disable uplinkfast on the switches and perform the test again to see if the convergence times are equal in both cases.

Cheers,

Shashank

P.S. Please rate the helpful post

[visitor68]

as a test, i did enable portfast on the access to d1 link (both  sides) and it has reduced convergence time considerably - lose only 2  packets altogether. of course i would never leave it that way...

lets say the access switch was a cisco switch, so all 3 ciscos..

with rstp enabled on all 3 switches, how should everything behave whrn i reconnect the access to d1 link?

so, access to d1 link is the primary link

i bring access to d1 down

almost automatic failover to the access to d2 link

reconnect the access to d1 link - and i believe with the cisco switch in the access layer, there should be another automatic failove back to the access to d1 link....correct?

[Shashank Singh]

Hi,

The fact that portfast is helping tells that the access switch was going through the classical STP convergence steps when you were bringing the link up between acc and root. (LIS, LRN, FWD) and hence was the outage. There seems to be some kind of incompatibility in the way RSTP is implemented on these switches.

In case all three were Cisco switches running RSTP, both link removal and addition would have caused equal outage. With uplinkfast enabled, it would have been less than one sec.

Cheers,

Shashank

P.S. Please rate the helpful post.