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

Greetings,

>From 2 responses on this thread sounds like this issue is unheard of?! So
may be a simple update will fix it. I should mention that my box runs
Vyatta community version 6.4.
For one, Vyatta tend to use old versions of softwares, hence version 1.2.2
of keepalived. Two, they mod the software quite a bit. So may be the
behavior I saw is a Vyatta customization. Three, the company who bought
Vyatta don't want to put much effort in supporting the community version.

Appreciate if someone not using Vyatta can confirm that vrrp vmac mode does
not use the physical MAC to send out arp requests. The steps are quite
simple:
1. Suppose Virtual IP is 10.10.10.2 and there is a host 10.10.10.x (e.g.
the backup) in the network.
2. arp -d 10.10.10.x
3. on 10.10.10.x run "tcpdump -nnq -i <10.10.10_interface> -e arp
4. ping -c2   -I 10.10.10.2   10.10.10.x
The tcpdump should tell which MAC is used in the arp request.

Below are the info asked by Patrick.
* uname -a:
Linux 3.0.23-1-586-vyatta #1 SMP Tue Jul 24 10:13:15 PDT 2012 i686 GNU/Linux

* ip addr show BASEINTERFACE
ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen
1000
    link/ether d0:67:e5:f1:01:f9 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.4/24 brd 10.10.10.255 scope global eth0
    inet6 fe80::d267:e5ff:fef1:1f9/64 scope link
       valid_lft forever preferred_lft forever

* ip addr show MACVLANINTERFACE
ip addr show eth0v164
6: eth0v164@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP
    link/ether 00:00:5e:00:01:a4 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.2/24 scope global eth0v164

 * ip route list
default via 10.10.10.1 dev eth0  proto zebra
10.10.10.0/24 dev eth0  proto kernel  scope link  src 10.10.10.4
10.10.10.0/24 dev eth0v164  proto kernel  scope link  src 10.10.10.2
172.16.0.0/24 dev eth1  proto kernel  scope link  src 172.16.0.4
127.0.0.0/8 dev lo  proto kernel  scope link  src 127.0.0.1

* and the output of for f in /proc/sys/net/ipv4/conf/{eth0,eth0v164}/arp_*;
do echo -n "$f "; cat $f; done

In summary, my values are the ones documented by Vyatta:
all.arp_ignore=1,all.arp_announce=1,all.arp_filter=0
but eth0.arp_filter=1
      eth0v164.arp_filter=0
Some say value of "rp_filter" matters. It is 0 for {all,eth0,eth0v164}.

cd /proc/sys/net/ipv4/conf
for f in {all,eth0,eth0v164}/arp_*; do echo -n "$f "; cat $f; done
all/arp_accept 0
all/arp_announce 1
all/arp_filter 0
all/arp_ignore 1
all/arp_notify 0
eth0/arp_accept 0
eth0/arp_announce 0
eth0/arp_filter 1
eth0/arp_ignore 0
eth0/arp_notify 0
eth0v164/arp_accept 0
eth0v164/arp_announce 0
eth0v164/arp_filter 0
eth0v164/arp_ignore 0
eth0v164/arp_notify 0

Thanks a lot guys.
Sial

On Sat, May 31, 2014 at 11:45 AM, Patrick Schaaf <[email protected]> wrote:

> Hello Sial,
>
> Am 31.05.2014 20:10 schrieb "Sial Nije" <[email protected]>:
>
> >
> > 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
>
> To clarify your picture, please show:
>
> uname -a
> ip addr show BASEINTERFACE
> ip addr show MACVLANINTERFACE
> ip route
> and the output of
> for f in /proc/sys/net/ipv4/conf/{BASEINTERFACE,MACVLANINTERFACE}/arp_*;
> do echo -n "$f "; cat $f; done
>
> That should give a complete picture to answer your inquiry.
>
> best regards
>   Patrick
>

------------------------------------------------------------------------------
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