Re: [PATCH 4/4] Build GARP with virtual MAC address

Alexandre Cassen <[email protected]>
Newsgroups gmane.linux.keepalived.devel
Message-ID <[email protected]>
Hi Eilon,

Keepalived offers the possibility to choose between using VMAC or not. Hardcoding the use of VMAC in gratuitous ARP make it no longer optional.

If you are configuring a vrrp_interface with “use_vmac” keyword, then it will bring up a VMAC interface and start VRRP over this brand new interface. It will use VMAC for gratuitous ARP in this case.

I double checked it just right now with my wireshark and if running on a VMAC interface gratuitous ARP sent are using VRRP VMAC as “Sender MAC address”.

So please elaborate if you dont agree the statement.

Regs,
Alexandre



On 11 May 2014, at 17:47, Eilon Greenstein <[email protected]> wrote:

> From: Dharmender Garg <[email protected]>
> 
> According to the RFC:
> 8.2 Host ARP Requests
> When a host sends an ARP request for one of the virtual router IP
> addresses, the Master virtual router MUST respond to the ARP request
> with the virtual MAC address for the virtual router. The Master
> virtual router MUST NOT respond with its physical MAC address. This
> allows the client to always use the same MAC address regardless of
> the current Master router.
> When a VRRP router restarts or boots, it SHOULD not send any ARP
> messages with its physical MAC address for the IP address it owns, it
> should only send ARP messages that include Virtual MAC addresses.
> This may entail:
> - When configuring an interface, VRRP routers should broadcast a
> gratuitous ARP request containing the virtual router MAC address
> for each IP address on that interface.
> 
> This patch builds the GARP with the virtual MAC address
> 
> Signed-off-by: Dharmender Garg <[email protected]>
> Signed-off-by: Eilon Greenstein <[email protected]>
> ---
> keepalived/include/vrrp_arp.h | 2 +-
> keepalived/vrrp/vrrp.c        | 2 +-
> keepalived/vrrp/vrrp_arp.c    | 5 +++--
> 3 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/keepalived/include/vrrp_arp.h b/keepalived/include/vrrp_arp.h
> index 9841ad6..9eb1ee1 100644
> --- a/keepalived/include/vrrp_arp.h
> +++ b/keepalived/include/vrrp_arp.h
> @@ -56,6 +56,6 @@ extern int garp_fd;
> /* prototypes */
> extern void gratuitous_arp_init(void);
> extern void gratuitous_arp_close(void);
> -extern int send_gratuitous_arp(ip_address_t *);
> +extern int send_gratuitous_arp(ip_address_t *, int);
> 
> #endif
> diff --git a/keepalived/vrrp/vrrp.c b/keepalived/vrrp/vrrp.c
> index a930009..5ebd9ab 100644
> --- a/keepalived/vrrp/vrrp.c
> +++ b/keepalived/vrrp/vrrp.c
> @@ -708,7 +708,7 @@ vrrp_send_update(vrrp_t * vrrp, ip_address_t * ipaddress, int idx)
>  	if (!IP_IS6(ipaddress)) {
>  		msg = "gratuitous ARPs";
>  		inet_ntop(AF_INET, &ipaddress->u.sin.sin_addr, addr_str, 41);
> -		send_gratuitous_arp(ipaddress);
> +		send_gratuitous_arp(ipaddress, vrrp->vrid);
>  	} else {
>  		msg = "Unsolicited Neighbour Adverts";
>  		inet_ntop(AF_INET6, &ipaddress->u.sin6_addr, addr_str, 41);
> diff --git a/keepalived/vrrp/vrrp_arp.c b/keepalived/vrrp/vrrp_arp.c
> index e53b9d7..101ce86 100644
> --- a/keepalived/vrrp/vrrp_arp.c
> +++ b/keepalived/vrrp/vrrp_arp.c
> @@ -57,11 +57,12 @@ static int send_arp(ip_address_t *ipaddress)
> }
> 
> /* Build a gratuitous ARP message over a specific interface */
> -int send_gratuitous_arp(ip_address_t *ipaddress)
> +int send_gratuitous_arp(ip_address_t *ipaddress, int vrid)
> {
>  	struct ether_header *eth = (struct ether_header *) garp_buffer;
>  	arphdr_t *arph		 = (arphdr_t *) (garp_buffer + ETHER_HDR_LEN);
> -	char *hwaddr		 = (char *) IF_HWADDR(ipaddress->ifp);
> +	u_char ll_addr[ETH_ALEN] = {0x00, 0x00, 0x5e, 0x00, 0x01, vrid};
> +	char *hwaddr		 = (char *)ll_addr;
>  	int len;
> 
>  	/* Ethernet header */
> -- 
> 1.8.4.3
> 
> 
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> &#149; 3 signs your SCM is hindering your productivity
> &#149; Requirements for releasing software faster
> &#149; Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Keepalived-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.