RSTP and link failure detection

[Lauge Sorensen]

Hi,

In a test setup with just four interconnected and RSTP enabled ProCurve switches, I observe that the time it takes for the network to converge after a link is removed depends on the configurable value of the Hello Time (default is 2s).

I would have expected an inter-switch link failure to be detected 'immediately' by lack of link pulse, followed by a rapid convergence according to the BPDU's being exchanged.

Is my observation correct: That the switches await up to a hello time period to detect a direct link failure?

PS. I'm using HP J4850A ProCurve switches 5304XL with v. E.09.03, ROM E.05.04.

Thanks in advance,
Lauge

[Jeff Brownell]

please log call to have concernes addressed.

[Ralph Bean_2]

Hello Lauge -

I am a little confused. You talk about two different time intervals: 1. "time it takes for the network to converge"; and 2. "inter-switch link failure to be detected 'immediately'". While they should both be brief, the latter is completely under control of the switch, while the former is performed by all of the switches participating in the spanning tree.

You do not mention the switch model or OS version, but I have noticed that ProCurve switches tend to recognize loss of Link immediately, at least based on the Link LED. How are you determining the point at which the Switch recognizes loss of link?

Bear in mind that the Switch Event Log may not necessarily report the Link down event instantaneously. The Event Log is not the best way to judge the Switch's respond to Link Down events, in terms of sub-second intervals.

Ralph

[OLARU Dan]

Lauge,

You speak of a "test setup". What was the purpose of your testing?

The purpose of Spanning Tree is to monitor the network topology for changes, and when a change occurs, either removing or adding a data path, the protocol reconfigures the switches so that total loss of connectivity of creation of netwotk loops are avoided.

[Lauge Sorensen]

The network carries real-time circuit switched voice service which explains why it's critical to differentiate between 'immediately' and 2 seconds.

The purpose of the four RSTP switch test set-up is to simplify a complex network and eliminate influence from other devices.

Timing was measured by inserting a passive (fifth non-RSTP switch configured with a monitor port and observe the timestamp and content of the BPDUs.

This simplified test set-up verified that the switches don't react 'immediately' upon a direct link type failure, but depends on the configurable value of the Hello Time.

Regards,
Lauge

[Mohammed Safadi]

Dear Lauge

RSTP offers convergence times of less than one
second under optimal circumstances.

To make the best use of RSTP and
achieve the fastest possible convergence times, though, there are some
changes that you should make to the RSTP default configuration.


To optimize the RSTP configuration on your switch, follow these steps

1. Set the switch to support RSTP by entring the command
Spanning-Tree Protocol-Version rstp
2. Set the â point-to-point-macâ value to false on all ports that are connected
to shared LAN segments (that is, to connections to hubs)
spanning-tree [ethernet] < port-list > point-to-point-mac force-false
3. Set the â edge-portâ value to false for all ports connected to other switches,
bridges, and hubs
no spanning-tree [ethernet] < port-list > edge-port
4. In case of using STP on other switches Set the â mcheckâ value to false for all ports that are connected to devices that are known to be running IEEE 802.1D spanning tree
no spanning-tree [ethernet] < port-list > mcheck
5. Enable RSTP
spanning-tree


I hope this c

[André Beck]

Hi,

AFAIK there is a conclusion in the network community that for VoIP, building simple campus spanning VLAN architectures with either STP or RSTP is not providing the required high availability features, no matter what. The only way to really get ideal reconvergence of either real transparent behavior or in some cases in less than a second is redundant dynamic routing in the core and the distribution layer, with L2 either banned to the access layer or completely eliminated (L3 access). If you don't have a layer 10 problem with another vendor, you should give the two "HA Campus" papers at

http://www.cisco.com/go/srnd/

a good reading. Of course they focus on Cisco hardware, but they are meta literature on a sufficiently generic level and come to some interesting, partially surprising conclusions (like: Use redundant supervisor engines only in the access layer, in distribution/core they actually harm. Or: In a setup with L2 access, RSTP actually harms more than STP).

[OLARU Dan]

Lauge,

In real operation you could put the switched voice traffic in a VLAN distinct from other user VLANs, and use per-VLAN spanning tree if the 5300 series HP switches allow this. In this setup you could turn off Spanning Tree in the switched voice VLAN (where the probability of moves-adds-changes is low), and leave it running in your user VLANs.