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

suketu soni <suketusoni@hotmail.com> Thu, 05 November 2009 12:49 UTC

Return-Path: <suketusoni@hotmail.com>
X-Original-To: vrrp@core3.amsl.com
Delivered-To: vrrp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4BC28C0D6 for <vrrp@core3.amsl.com>; Thu, 5 Nov 2009 04:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.877
X-Spam-Level:
X-Spam-Status: No, score=0.877 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm5QS-wuyAi7 for <vrrp@core3.amsl.com>; Thu, 5 Nov 2009 04:49:10 -0800 (PST)
Received: from bay0-omc1-s37.bay0.hotmail.com (bay0-omc1-s37.bay0.hotmail.com [65.54.246.109]) by core3.amsl.com (Postfix) with ESMTP id DE0B53A6AB6 for <vrrp@ietf.org>; Thu, 5 Nov 2009 04:49:10 -0800 (PST)
Received: from BAY144-W1 ([65.55.155.36]) by bay0-omc1-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 04:49:33 -0800
Message-ID: <BAY144-W183D9FFEF134F9D728A69DDB00@phx.gbl>
Content-Type: multipart/alternative; boundary="_7c67528d-46e1-46ee-b678-243ce661f7ca_"
X-Originating-IP: [47.152.204.150]
From: suketu soni <suketusoni@hotmail.com>
To: vrrp@ietf.org
Date: Thu, 05 Nov 2009 12:49:33 +0000
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Nov 2009 12:49:33.0572 (UTC) FILETIME=[6C7A3440:01CA5E16]
Subject: [VRRP] VRRP operations possibly affected by spanning-tree protocol?
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2009 12:49:11 -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