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: > • 3 signs your SCM is hindering your productivity > • Requirements for releasing software faster > • 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