vmac mode send out arp request with MAC of physical interface

Sial Nije <[email protected]>
Newsgroups gmane.linux.keepalived.devel
Message-ID <CAHO7rrcBx1DuK8KprmOvfZ1Ppg4ionWakjrTdv6XfcUUrHMdVg@mail.gmail.com>
Hi list,

I am using vmac mode in keepalived version 1.2.2.
Packets send out from the master always use the physical interface's MAC,
not its virtual MAC.
The only exceptions:
 1. when it replies to arp requests for the virtual IP
 2. in the gratuitous arps it sends out when transition to master state.

Problem caused by this behavior is when there are Cisco routers in the
network.
Quote from
https://supportforums.cisco.com/discussion/11416946/arp-cache-timeout-cisco-routers
:
"If Cisco receives an ARP request from a host it will use that request to
refresh the ARP entry."

To be clear, the ARP request sends out by the VRRP interface has:
* src IP is the virtual IP addr
* src MAC is the physical interface's MAC
* target IP is the Cisco router's IP
* target MAC is zero
* the frame header uses physical interface's MAC too

After that the Cisco router will associate physical interface MAC address
to the virtual IP address.
This lasts for 4 hrs, until the arp entry ages out and Cisco sends out an
arp request. The VRRP
master will reply with virtual MAC and rectify the situation.

Does anyone know if this is a bug in keepalived? or the macvlan driver? or
kernel IP stack?
or my keepalived.conf has error?
If none of the above, can someone please point me to the source code where
the kernel/keepalived
populate the src MAC address in arp request and arp response?

Thanks
sial

------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet

_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
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.