Linux ARPs too much
PlayingExperimenting with arping, I found the following behavior:
$ sudo arping -c 1 10.202.202.254 ARPING 10.202.202.254 60 bytes from 00:0f:20:d4:07:e0 (10.202.202.254): index=0 time=196.934 usec --- 10.202.202.254 statistics --- 1 packets transmitted, 1 packets received, 0% unanswered $ sudo arping -c 1 10.101.2.1 ARPING 10.101.2.1 60 bytes from 00:0f:20:d4:07:e0 (10.101.2.1): index=0 time=168.085 usec --- 10.101.2.1 statistics --- 1 packets transmitted, 1 packets received, 0% unanswered $
wtf? 10.101.2.1 is my default gateway (running a recent Linux 2.6 kernel), so it is ok to answer ARP requests. 10.202.202.254 is bound on the same box, but on a different interface, so I don't think it is ok to answer ARP requests for that IP address on "my" interface, as it confuses some "what network segment am I on today" mechanisms.
Is there some /proc setting where I can disable this rather generous ARP behavior?
Display comments as Linear | Threaded
kju on :
echo 1 > /proc/sys/net/ipv4/conf/($interface|default|all)/arp_ignore
bzw. bei Debian in /etc/sysctl.conf: net.ipv4.conf.($interface|default|all).arp_ignore = 1
1 = Reply only if tip is configured on the incoming interface 2 = Reply only if tip is configured on the incoming interface and is in same subnet as sip
Andreas Schiermeier on :
echo 1 > /proc/sys/net/ipv4/conf/($interface|default|all)/arp_filter
arp_filter - BOOLEAN 1 - Allows you to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered based on whether or not the kernel would route a packet from the ARP'd IP out that interface (therefore you must use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond to an arp request.