Re: vmac mode send out arp request with MAC of physical interface

Hi Patrick,

Many thanks for verifying it on your system.
After more digging, we came to realize that it is a routing issue.
My real IP and virtual IP are in the same segment, i.e.
eth0:    10.10.10.4/24
eth0v1: 10.10.10.2/24

Thus the local link routes look like this:
10.10.10.0/24 dev eth0    proto kernel scope link src 10.10.10.4
10.10.10.0/24 dev eth0v1 proto kernel scope link src 10.10.10.2

By virtue of the listing order, kernel prefers the route with "src
<physical MAC>"
and uses it in all packets, including arp request, but exclude arp response.

On top of that, if eth0/arp_announce is 0 or 1, the arp request has the
virtual
MAC, which the target Cisco router will latch on. If eth0/arp_announce is 2,
then the arp request contains the physical MAC. Then the Cisco router has to
explicitly arp the virtual IP addr if it has something to send to the
virtual IP.

Regards,
Sial



On Sun, Jun 1, 2014 at 11:07 AM, Patrick Schaaf <[email protected]> wrote:

> Sial,
>
> in the setup I'm running (specifics below), outgoing live traffic,
> inluding the ARP requests for the gateways IPs, is NOT "using the macvlan
> interface", but instead directly using the underlying physical interface.
>
> The macvlan interface only "sees" incoming traffic (by virtue of being
> destined to the MAC address configured there), and only sends ARP responses
> to the specific IP address configured on the macvlan interface itself.
>
> The specifics of my setup:
>
> - kernel 3.10.40
> - keepalived current (1.2.13 I think)
> - base interface with x.x.x.A/24 address
> - keepalived.conf with x.x.x.B/24 address (like in your setup) being
> assigned to the macvlan interface, or only x.x.x.B which then is assigned
> as a /32 to the macvlan interface, avoiding the "double routes" in the
> routing table
> - keepalived.conf xmit_base_interface, but the ARP stuff works the same
> regardless (only had issues with backup balancers restarting and sending
> IGMP join messages with the VMAC source, see mail to the list of some days
> ago)
>
> To test the ARP requests in this setup I do NOT use your "ping -I VRRPIP"
> approach on the balancer itself - because that is not what live traffic
> seems to be doing - but really run a ping from "inside" to "outside" (in
> fact I usually ping a nonassigned outside IP address, because that then
> makes multipe ARP requests instead of relying on the cache being cleared).
>
> And in that setup and tests and practise, I definitely see
> - outgoing ARP requests with physical MAC AND the IP of the physical
> interface, triggered by live traffic
> - outgoing gratuitous ARP of keepalived sent through the macvlan interface
> using VMAC source and VRRP IP as protocol IP
> - incoming ARP requrests for the VRRP IP being answered with the VMAC and
> VRRP IP as ARP reply protocol source (done by the macvlan magic)
> - as a result, incoming live traffic with destination VMAC
> - and outgoing live traffic with source physical MAC
>
> The only issue I can see with this result, is that the constant outgoing
> traffic with the physical MAC, will not keep the VMAC in the switch MAC
> learning table. ARP Requests for the VRRP IP will remedy that, but there is
> a better way with current keepalived: the garp_refresh setting, which makes
> periodic gratuitous ARP requests.
>
> Hope this gives you some ideas to further test and try.
>
> best regards
>   Patrick
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel