Subject: Re: [VRRP] RFC5798

From: Stephen Nadas <[email-masked]>
Date: Thu, 14 Oct 2010 12:10:17 -0400

IMO better to ask VRRP list than me, individually,
Regards,
Steve

________________________________
From: Carl Petersen [mailto:[email-masked]]
Sent: Thursday, October 14, 2010 11:13 AM
To: Stephen Nadas
Subject: RFC5798

Stephen, I want to ask you a question about this RFC and the VRRP protocol. Regarding section 6.4.3, bullet points (735) to (765).

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?

Thanks

Carl Petersen

---

From: "Danny J. Mitzel" <[email-masked]>
Date: Thu, 14 Oct 2010 09:53:22 -0700 (PDT)

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 <[email-masked]> wrote:

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

 
 _filtered #yiv163395626 {
font-family:Cambria Math;}
 _filtered #yiv163395626 {
font-family:Calibri;}
 _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 {
COLOR:blue;TEXT-DECORATION:underline;}
#yiv163395626 SPAN.yiv163395626MsoHyperlink {
COLOR:blue;TEXT-DECORATION:underline;}
#yiv163395626 A:visited {
COLOR:purple;TEXT-DECORATION:underline;}
#yiv163395626 SPAN.yiv163395626MsoHyperlinkFollowed {
COLOR:purple;TEXT-DECORATION:underline;}
#yiv163395626 SPAN.yiv163395626EmailStyle17 {
COLOR:windowtext;FONT-FAMILY:"sans-serif";}
#yiv163395626 .yiv163395626MsoChpDefault {
}
#yiv163395626 DIV.yiv163395626WordSection1 {
}

IMO 
better to ask VRRP list than me, individually, 
Regards,
Steve 

From: Carl Petersen 
[mailto:[email-masked]] 
Sent: Thursday, October 14, 2010 
11:13 AM
To: Stephen Nadas
Subject: 
RFC5798

Stephen, I want to ask you a question about this RFC and the 
VRRP protocol. Regarding section 6.4.3, bullet points (735) to 
(765). 
   
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? 
   
Thanks 
   
Carl Petersen 

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

_______________________________________________
vrrp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vrrp