Switches, Hubs, and Modems
cancel
Showing results for 
Search instead for 
Did you mean: 

5406 VRRP Convergence Issue

Matt Axton
Occasional Advisor

5406 VRRP Convergence Issue

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
7 REPLIES
Jarret Workman
Frequent Advisor

Re: 5406 VRRP Convergence Issue

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
Occasional Visitor

Re: 5406 VRRP Convergence Issue

Hi Matt,

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

Thanks

Rudie Raath
HP ProCurve TC
Matt Axton
Occasional Advisor

Re: 5406 VRRP Convergence Issue

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
Frequent Advisor

Re: 5406 VRRP Convergence Issue

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
Respected Contributor

Re: 5406 VRRP Convergence Issue

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
Occasional Advisor

Re: 5406 VRRP Convergence Issue

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
Honored Contributor

Re: 5406 VRRP Convergence Issue

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

cenk
cenk