Using the following approach it is possible to accidentally configure a macvlan interface to respond to ARP requests for all IPs. Reproducer: ip link add link enp3s0 address f6:83:72:e4:77:0a vtest type macvlan ip addr add 192.168.1.200/32 dev vtest ip link set vtest up sysctl -w net.ipv4.conf.vtest.rp_filter=2 sysctl -w net.ipv4.conf.vtest.proxy_arp=1 sysctl -w net.ipv4.conf.vtest.forwarding=1 On a separate host on the same segment: arping -c 1 -I eth1 -s 192.168.1.2 10.1.2.3 ARPING 10.1.2.3 from 192.168.1.2 eth1 Unicast reply from 10.1.2.3 [f6:83:72:e4:77:0a] 419.288ms Sent 1 probe(s) (0 broadcast(s)) Received 1 response(s) (0 request(s), 0 broadcast(s)) arping -c 1 -I eth1 -s 192.168.1.2 8.8.8.8 ARPING 10.1.2.3 from 192.168.1.2 eth1 Unicast reply from 10.1.2.3 [f6:83:72:e4:77:0a] 27.754ms Sent 1 probe(s) (0 broadcast(s)) Received 1 response(s) (0 request(s), 0 broadcast(s)) See https://github.com/lxc/lxc/issues/775 for more information.
Hmm, what does your route table look like? If 10.1.2.3 is reachable via vtest or enp3s0, then this is not a bug, right? You set rp filter in loose mode, it will act as a proxy for whatever is accepted by rp filter. In the source code, kernel does a route table lookup first, which includes a rp filter check, if this succeeds then checks if proxy_arp is set and responses accordingly.
Hi, Thanks for your reply. I've setup another test: ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:16:3e:14:4a:d4 brd ff:ff:ff:ff:ff:ff inet 10.109.89.91/24 brd 10.109.89.255 scope global dynamic enp5s0 valid_lft 3279sec preferred_lft 3279sec inet6 fd42:d37c:f0f2:a5f:69c1:50d9:30fe:6d20/128 scope global dynamic noprefixroute valid_lft 3282sec preferred_lft 3282sec inet6 fe80::216:3eff:fe14:4ad4/64 scope link valid_lft forever preferred_lft forever 3: vtest@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether f6:83:72:e4:77:0a brd ff:ff:ff:ff:ff:ff inet 192.168.1.200/32 scope global vtest valid_lft forever preferred_lft forever inet6 fe80::f483:72ff:fee4:770a/64 scope link valid_lft forever preferred_lft forever ip r default via 10.109.89.1 dev enp5s0 proto dhcp src 10.109.89.91 metric 100 10.109.89.0/24 dev enp5s0 proto kernel scope link src 10.109.89.91 10.109.89.1 dev enp5s0 proto dhcp scope link src 10.109.89.91 metric 100 sysctl -w net.ipv4.conf.vtest.rp_filter=2 sysctl -w net.ipv4.conf.vtest.proxy_arp=1 sysctl -w net.ipv4.conf.vtest.forwarding=1 On another host: sudo arping -c1 -I lxdbr0 -S 10.109.89.1 8.8.8.8 ARPING 8.8.8.8 42 bytes from f6:83:72:e4:77:0a (8.8.8.8): index=0 time=11.809 msec --- 8.8.8.8 statistics --- 1 packets transmitted, 1 packets received, 0% unanswered (0 extra) rtt min/avg/max/std-dev = 11.809/11.809/11.809/0.000 ms So are you saying the default route is triggering a response to all ARP requests due to rp_filter=2 with proxy_arp=1? The reason this seems odd is that setting these same settings on an ethernet device (rather than a macvlan device) does not result in the same behaviour (even with rp_filter=2). E.g. Remove the macvlan interface. ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:16:3e:14:4a:d4 brd ff:ff:ff:ff:ff:ff inet 10.109.89.91/24 brd 10.109.89.255 scope global dynamic enp5s0 valid_lft 3029sec preferred_lft 3029sec inet6 fd42:d37c:f0f2:a5f:69c1:50d9:30fe:6d20/128 scope global dynamic noprefixroute valid_lft 3032sec preferred_lft 3032sec inet6 fe80::216:3eff:fe14:4ad4/64 scope link valid_lft forever preferred_lft forever ip r default via 10.109.89.1 dev enp5s0 proto dhcp src 10.109.89.91 metric 100 10.109.89.0/24 dev enp5s0 proto kernel scope link src 10.109.89.91 10.109.89.1 dev enp5s0 proto dhcp scope link src 10.109.89.91 metric 100 Set the sysctls on parent ethernet device instead: sysctl -w net.ipv4.conf.enp5s0.proxy_arp=1 sysctl -w net.ipv4.conf.enp5s0.rp_filter=2 sysctl -w net.ipv4.conf.enp5s0.forwarding=1 Now repeat the arping from a different host in same segment, and it doesn't get a response as it did with macvlan: sudo arping -c1 -I lxdbr0 -S 10.109.89.1 8.8.8.8 ARPING 8.8.8.8 Timeout --- 8.8.8.8 statistics --- 1 packets transmitted, 0 packets received, 100% unanswered (0 extra)