Subject: [VRRP] Virtual MAC really necessary?

From: "Roland Abt" <[email-masked]>
Date: Mon, 14 Jan 2008 17:31:55 +0100

Hello everybody

I want to implement my own VRRP protocol. The protocol itself is not that  
tricky, but using a virtual MAC seems like a big hurdle to me. The  
standard states that the MAC address of the new Master has to be published  
in a gratuitous ARP (request/reply). I think this already should help to  
update the ARP table of every device. Does anybody know of a situation  
where publishing the physical MAC would cause any trouble? Are there any  
known devices that would not update their ARP table in case of such a  
gratuitous ARP?

Best regards and thanks in advance for your time,
Roland

PS:
According to the Ethereal Wiki (http://wiki.ethereal.com/Gratuitous_ARP) a  
gratuitous ARP can be either a request or a reply. Any experience which  
one is better?

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

---

From: [email-masked]
Date: Mon, 14 Jan 2008 11:59:55 -0500

The advantage of the virtual mac is that it is a multicast address so both 
devices should receive the traffic regardless of their failover state. 
Also, the virtual mac allows failover with out any of the devices having 
to change their arp entry.  The gratuitous arp just serves to update the 
forwarding table in the switch(s).  If the gateway mac was suddenly a 
physical address you may run into issues if some of the attached devices 
don't receive the gratuitous arp or don't process it because of security.

"Roland Abt" <[email-masked]> 
01/14/08 11:31 AM

To
[email-masked]
cc

Subject
[VRRP] Virtual MAC really necessary?

Hello everybody

PS:

---

From: "Roland Abt" <[email-masked]>
Date: Mon, 14 Jan 2008 18:34:58 +0100

Hello Keegan

Thank you for your answer. I do not fully agree to your first statement.
RFC 3768 mentions that the virtual MAC address has to be:  
00-00-5E-00-01-{VRID} (in hex in internet standard bit-order).
And according to http://www.firewall.cx/multicast-intro.php, this would  
not be an Ethernet Multicast Address. If so, it would be  
01-00-5E-00-01-{VRID}.

> If the gateway mac was suddenly a

This is exactly my question. Do you know of any devices that ignore  
gratuitous ARPs?

Best regards,
Roland

-- 
---
Roland Abt
Geiselweidstrasse 21
8400 Winterthur

phone: +41 52 534 4533
mobile: +41 76 503 2828
email: [email-masked]

---

From: "Sylwester Chojkiewicz" <[email-masked]>
Date: Mon, 14 Jan 2008 12:37:29 -0500

Using the physical MAC address may also contribute to opening of another
issue: a race conditions when two Standby virtual routers compete for Master
state. 

The specific situation occurs when two Masters become active approximately
at the same time. As a result of protocol defined arbitration mechanism, the
Master with lower primary IP address will be forced to switch to Backup
state.  It is fine as long as out of these two Masters, the legitimate one,
which will remain its status, will be also the last one who has sent the
gratuitous ARP (just considering the IPv4 case). 

However, what will happen if the gratuitous ARP from the legitimate Active
is overwritten in device by that one coming from virtual router that will
assume the Standby role?

After receiving advertisement from another virtual router, should not the
legitimate Active re-broadcast the gratuitous ARP - just in any case - even
after a short delay? 

Sylwester

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 14, 2008 12:00 PM
To: Roland Abt
Cc: [email-masked]
Subject: Re: [VRRP] Virtual MAC really necessary?

The advantage of the virtual mac is that it is a multicast address so both
devices should receive the traffic regardless of their failover state.
Also, the virtual mac allows failover with out any of the devices having to
change their arp entry.  The gratuitous arp just serves to update the
forwarding table in the switch(s).  If the gateway mac was suddenly a
physical address you may run into issues if some of the attached devices
don't receive the gratuitous arp or don't process it because of security. 

01/14/08 11:31 AM 

To

[email-masked] 

cc

Subject

 

Hello everybody

PS:
According to the Ethereal Wiki ( <http://wiki.ethereal.com/Gratuitous_ARP>
http://wiki.ethereal.com/Gratuitous_ARP) a  
gratuitous ARP can be either a request or a reply. Any experience which  
one is better?

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

---

From: "Roland Abt" <[email-masked]>
Date: Tue, 15 Jan 2008 10:29:46 +0100

Sylwester,

I see your point. But sending multiple ARP Requests would not be an  
unsolvable problem :)
Again, has anybody seen devices ignoring gratuitous ARPs? And what kind of  
gratuitous ARP should be used (request or reply)?

Best regards,
Roland

On Mon, 14 Jan 2008 18:37:29 +0100, Sylwester Chojkiewicz  
<[email-masked]> wrote:

> to
> According to the Ethereal Wiki  
> ( <http://wiki.ethereal.com/Gratuitous_ARP>

---

From: [email-masked]
Date: Tue, 15 Jan 2008 09:46:11 -0500

There are certain security features common to switches that will filter 
gratuitous arp's sent from ports that do not match the known values.  Most 
do not enable this feature.  I have seen gratuitous arps dropped because 
of lack of queue space.  Gratuitous arp's must be received by the network 
device itself and copied to every port, this means that they will sit in 
the queue longer than normal messages. If there are a large amount of arps 
sent in a short period they could easily fill the queues as the switch 
tries to process them.  This will lead to arp's being dropped  (as well as 
normal traffic) and devices not having accurate arp caches.  I think the 
virtual mac was created to preclude this situation or something similar. 
While it may not be absolutely necessary it is helpful.

01/15/08 04:29 AM

To
"Sylwester Chojkiewicz" <[email-masked]>, 
[email-masked]
cc
[email-masked]
Subject
Re: [VRRP] Virtual MAC really necessary?

Sylwester,

Best regards,
Roland

On Mon, 14 Jan 2008 18:37:29 +0100, Sylwester Chojkiewicz 
<[email-masked]> wrote:

> at the same time. As a result of protocol defined arbitration mechanism, 
 
> the

---

From: sengottuvelan srirangan <[email-masked]>
Date: Tue, 15 Jan 2008 07:20:38 -0800 (PST)

Hi,
   
  For simple  Master-Backup , it may be working by sending gratuitous ARP with Physical MAC address  :-) . But For real networks like multiple Masters and Backups associated with VRIDs for an interface , you may really require Virtual MAC address associated with VRID. Masters should send gratuitous ARP for VMAC if IPv4 or Neighbor advertisement if IPv6.
   
  Have a nice VRRP.
   
  Regards
  Sengottuvelan

Sylwester Chojkiewicz <[email-masked]> wrote:
        v\:* {behavior:url(#default#VML);}  o\:* {behavior:url(#default#VML);}  w\:* {behavior:url(#default#VML);}  .shape {behavior:url(#default#VML);}        st1\:*{behavior:url(#default#ieooui) }                Using the physical MAC address may also contribute to opening of another issue: a race conditions when two Standby virtual routers compete for Master state. 
  The specific situation occurs when two Masters become active approximately at the same time. As a result of protocol defined arbitration mechanism, the Master with lower primary IP address will be forced to switch to Backup state.  It is fine as long as out of these two Masters, the legitimate one, which will remain its status, will be also the last one who has sent the gratuitous ARP (just considering the IPv4 case). 
  However, what will happen if the gratuitous ARP from the legitimate Active is overwritten in device by that one coming from virtual router that will assume the Standby role?
  After receiving advertisement from another virtual router, should not the legitimate Active re-broadcast the gratuitous ARP – just in any case – even after a short delay? 
  Sylwester

---------------------------------

  
The advantage of the virtual mac is that it is a multicast address so both devices should receive the traffic regardless of their failover state.  Also, the virtual mac allows failover with out any of the devices having to change their arp entry.  The gratuitous arp just serves to update the forwarding table in the switch(s).  If the gateway mac was suddenly a physical address you may run into issues if some of the attached devices don't receive the gratuitous arp or don't process it because of security. 

      Subject

Hello everybody

PS:

       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.