5406 VRRP Convergence Issue

[Matt Axton]

I have got a couple of 5406 switches configured for VRRP failover, this works sweet when I fail the primary router as the backup router seemlessly takes over.

However, when the primary router comes back up an election is forced and we lose around 30 seconds of connectivity.

I am really hoping this is not by design, can anyone tell me if this is the case

Cheers
Matt

[Jarret Workman]

Hi Matt,

I have not experienced slow failback in the past when testing VRRP on the 3500/5400/8212 systems. I believe I was running K.12.57 software during my tests.

I am not sure which version of software you are using, but looking at the release notes, there are a few enhancements to VRRP in the k.13.xx code. The pre-emptive delay timer looks like it controls the failback time, but by default, is set to zero so that failback would occur immediately.

Is it possible something else like an 802.1d spanning-tree implementation could be involved where it would be blocking ports for around 30 seconds while the topology is being sorted out?

[Rudie Raath]

Hi Matt,

Please could you verify id this delay was tested using 5400 or 8200?

Thanks

Rudie Raath
HP ProCurve TC

[Matt Axton]

I don't think it is spanning tree, we are using RSTP (as apposed to the default MSTP), we need to be running RSTP so we don't have network loops and even that only shoukld have a couple of seconds delay while it unblocks links....

We are using the 5406 with the K_13_09 firmware rev.

[Jarret Workman]

Hi Matt,

I agree that RSTP would have quicker conversions and sounds like spanning-tree would not be the issue. Would you be willing to attach your running configs for review? Otherwise, it might be beneficial to log a call with ProCurve technical support to look into the issue.

[Olaf Borowski]

Matt,

Even though you are using RSTP, failing back might take 30 to 50 sec. RSTP has sub second failover times if it has an alternate path. Depending on your configuration/topology, initial failure has an alternate path. Once your failed over, you don't have an alternate path and if you bring the second box up again, it goes thru its regular STP algorithm.
The VRRP preemptive delay timer only matters for the layer 3 interface. It basically tells the system to wait x seconds before giving up control to the master again. This ensure that routing protocols like OSPF have time to converge before master takes over again. Spanning tree below this is a different story....

[Matt Axton]

Thanks for all your comments.

I had 2 problems I think. RSTP had incorrectly created a root bridge on a edge switch then proceeded to block the switch trunk :( so there were no VRRP advertisements being received by the 2nd switch...

The firmeware revision K_13_09 seemed 'buggy' so updated to K_13_23

All cool now.

Many thanks

[cenk sasmaztin]

hi Matt
please send me either core switch show tech print and your network layout

cenk