Re: [VRRP] RFC5798

"Danny J. Mitzel" <> Thu, 14 October 2010 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3B003A6B08 for <>; Thu, 14 Oct 2010 09:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K7hRmSjcUPu6 for <>; Thu, 14 Oct 2010 09:52:06 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id A40AB3A6AB7 for <>; Thu, 14 Oct 2010 09:52:06 -0700 (PDT)
Received: (qmail 90261 invoked by uid 60001); 14 Oct 2010 16:53:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1287075203; bh=NZ3YVPzkJeDy6fg8SUVhYCvV77rhZpPSd6ruFJLTCKs=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=195pD0tB4icBoACcw+zpZr0TAj2/eXh+9WSdRmJgM6nAcIc/ZmNB5ekXJn1gw7BzKdTlqJyCfTA99WbtCzztjnEtrMm1YkqkdzSneReFpn2cLJ8PjBEfPsrxZu+k2D2Xrc/cHfEnNil6vKlaqKTn0Q5SeGVYu+7yx9whb+/31uY=
Message-ID: <>
X-YMail-OSG: sOJLl4sVM1mDyiZw1Xdtr2_brpDa6yXFBhQ6ldYQ5z2WsVk 2m5WqmJWpB_oXgl_USA73Gw0bkceZJxkwPYwgvfcS5BFWMmtFosEIl4MXB5M jdCjTN_lRipvMlxFhJMAh7c1kuZDWI6dXNJvYMNeKMkMSd1FoOQYAOC8FW3b fYXmoczEH7Ii6YzuiOwDoE7T4oXW3UyxaaLyUlBSpGzy5Ug9O1LDwvMptd_J 14thkWQqmr3xv1v9IYJxy7w9oTJEz3YuEok2vAfw6ri_gjv6SIc.5NVmE5w9 GS.BotkixhnpYjBIwpCxsoP64HldwDoL_YE1N9.hhW_qe3WmJIYx3iP2l9.y W4pQ7
Received: from [] by via HTTP; Thu, 14 Oct 2010 09:53:22 PDT
X-RocketYMMF: danny_j_mitzel
X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/
Date: Thu, 14 Oct 2010 09:53:22 -0700 (PDT)
From: "Danny J. Mitzel" <>
To: Carl Petersen <>, Stephen Nadas <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-985233537-1287075202=:89447"
Cc: "" <>
Subject: Re: [VRRP] RFC5798
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Router Redundancy Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Oct 2010 16:52:08 -0000

When VRRP is enabled then the associated MAC address is alwaysfixed 00-00-5E-00-01-{VRID}.  Whether there's a Master failover, ornetwork partition and heal, etc. there's no change to the mapping andall client hosts should be consistent.  No action is required.
The sole reason for the gratuitous ARP is to increase robustnessthe very first time VRRP is enabled in the network.  Prior to VRRPenable some client hosts may have cached the router physicalMAC address.  When VRRP is then enabled the first Mastertransition triggers gratuitous ARP to encourage client hosts toflush the router physical MAC address if it's in their cache.

--- On Thu, 10/14/10, Stephen Nadas <> wrote:

From: Stephen Nadas <>
Subject: Re: [VRRP] RFC5798
To: "Carl Petersen" <>
Cc: "" <>
Date: Thursday, October 14, 2010, 9:10 AM

 _filtered #yiv163395626 {
font-family:Cambria Math;}
 _filtered #yiv163395626 {
 _filtered #yiv163395626 {margin:1.0in 1.0in 1.0in 1.0in;}
#yiv163395626 P.yiv163395626MsoNormal {
FONT-SIZE:11pt;MARGIN:0in 0in 0pt;FONT-FAMILY:"sans-serif";}
#yiv163395626 LI.yiv163395626MsoNormal {
FONT-SIZE:11pt;MARGIN:0in 0in 0pt;FONT-FAMILY:"sans-serif";}
#yiv163395626 DIV.yiv163395626MsoNormal {
FONT-SIZE:11pt;MARGIN:0in 0in 0pt;FONT-FAMILY:"sans-serif";}
#yiv163395626 A:link {
#yiv163395626 SPAN.yiv163395626MsoHyperlink {
#yiv163395626 A:visited {
#yiv163395626 SPAN.yiv163395626MsoHyperlinkFollowed {
#yiv163395626 SPAN.yiv163395626EmailStyle17 {
#yiv163395626 .yiv163395626MsoChpDefault {
#yiv163395626 DIV.yiv163395626WordSection1 {

better to ask VRRP list than me, individually, 

From: Carl Petersen 
Sent: Thursday, October 14, 2010 
11:13 AM
To: Stephen Nadas

Stephen, I want to ask you a question about this RFC and the 
VRRP protocol. Regarding section 6.4.3, bullet points (735) to 
If 2 vrrp routers became isolated for whatever reason, one 
router would remain as master, the other would transition from backup to master 
and send a gratuitous arp (ipv4 only) to notify remote arp caches. My question 
is about when the fault is corrected. One router transitions from master to 
backup; the other router still remains as master. The backup router follows 
(735) to (765), but the master seemingly does nothing at all. In particular the 
now-for-real master does not send a gratuitous arp. This leaves remote arp 
caches with the wrong ip/mac value. 
I’m sure this has been considered. What is typically done to 
prevent this scenario or to recover from it? 
Carl Petersen 

-----Inline Attachment Follows-----

vrrp mailing list