Subject: [VRRP] VRRP operations possibly affected by spanning-tree protocol?

From: suketu soni <[email-masked]>
Date: Thu, 5 Nov 2009 12:49:33 +0000

Hi Group,

I have the following VRRP scenario:

L3 Switch_1 <-----------------> VRRP Router: RTR_1

        |

        |

        |

L3 Switch_2 <-----------------> VRRP Router: RTR_2

VRRP Routers RTR_1 and RTR_2 are connected through two L3 switches, each using a 100Mbps, full duplex link. The two L3 switches are inter-connected using a 1Gig full-duplex link. The VRRP advertisement interval = 1sec.

While testing VRRP operations, the following behaviour was observed:

1) RTR_1 is the primary address owner and hence, the master VRRP router. RTR_2 is the backup VRRP router. This is a steady state function.

2) By disconnecting the cable between RTR_1 and L3 Switch_1, a VRRP transition is forced. RTR_2 becomes the master VRRP router in little over 3 seconds. RTR_1 is in "init" state.

3) When connectivity between RTR_1 and L3 Switch_1 is restored, RTR_1 becomes the master (primary address owner). However, it takes 45-50 seconds for RTR_2 to receive the first VRRP advertisement from RTR_1. As soon as RTR_2 receives the first VRRP advertisement from RTR_1, it sends its last VRRP advertisement with priority = 0, withdrawing from the role of master router.

The gap of 45-50 seconds is undesirable. It should have been immediate, because preemption is allowed.

I suspect that this condition could be caused if spanning-tree is enabled on ports of the both of L3 switches connected to RTR_1 and RTR_2. Note, that ports of RTR_1 and RTR_2 does not participate in spanning-tree and does not send any BPDU.

Has anyone encountered this situation earlier? Please share your opinions.

Thanking you, 
Suketu Soni

_________________________________________________________________
Windows 7: Find the right PC for you. Learn more.
http://windows.microsoft.com/shop

---

From: Abuse007 <[email-masked]>
Date: Fri, 6 Nov 2009 01:05:26 +1100

Hi Suketu,

It sounds like spanning tree protocol is enabled on sw1 on the port  
connected to rtr1. It's going into learning mode etc to ensure that  
it's not connected to a switch and not creating a L2 loop. Once it  
doesn't hear any BPDU's it goes to forwarding mode which allows  
communication.

If they are cisco switches enable portfast on the ports connected to  
the routers to optimise the recovery time, but make sure you don't  
later cable those ports to switches.

On 05/11/2009, at 11:49 PM, suketu soni <[email-masked]> wrote:

> VRRP Routers RTR_1 and RTR_2 are connected through two L3 switches,  
> each using a 100Mbps, full duplex link. The two L3 switches are  
> inter-connected using a 1Gig full-duplex link. The VRRP  
> advertisement interval = 1sec.
>
> 1) RTR_1 is the primary address owner and hence, the master VRRP  
> router. RTR_2 is the backup VRRP router. This is a steady state  
> function.
>
> 2) By disconnecting the cable between RTR_1 and L3 Switch_1, a VRRP  
> transition is forced. RTR_2 becomes the master VRRP router in little  
> over 3 seconds. RTR_1 is in "init" state.
>
> 3) When connectivity between RTR_1 and L3 Switch_1 is restored,  
> RTR_1 becomes the master (primary address owner). However, it takes  
> 45-50 seconds for RTR_2 to receive the first VRRP advertisement from  
> RTR_1. As soon as RTR_2 receives the first VRRP advertisement from  
> RTR_1, it sends its last VRRP advertisement with priority = 0,  
> withdrawing from the role of master router.
>
> The gap of 45-50 seconds is undesirable. It should have been  
> immediate, because preemption is allowed.
>
> I suspect that this condition could be caused if spanning-tree is  
> enabled on ports of the both of L3 switches connected to RTR_1 and  
> RTR_2. Note, that ports of RTR_1 and RTR_2 does not participate in  
> spanning-tree and does not send any BPDU.
>
> _______________________________________________
> vrrp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vrrp