Harping on ARP [LWN.net]

Harping on ARP

Posted Aug 21, 2003 22:03 UTC (Thu) by gswoods (guest, #37)
Parent article: Harping on ARP

I only understand part of how all this works, but one thing we have seen here is, if you have a dual-homed Solaris machine and a dual-homed Linux machine on the same two different networks, after a while, the Solaris machine will not be able to communicate with the Linux server any more.
We have traced this down to the different way that Linux does ARP, and the admin of the Solaris machine has flooded me with RFC references showing that Linux does this "wrong". I'm not a great interpreter of RFCs either so I don't know if his evidence is valid. But in the end, the only way to fix the problem was to set the MAC address of all the interfaces on the Linux machine to be the same, so that if the Linux machine sends an ARP response that is associated with the "wrong" interface, it still has the right MAC address. Does this sound like it's related to the same issue?

(Log in to post comments)

Harping on ARP

Posted Aug 22, 2003 0:33 UTC (Fri) by tmattox (subscriber, #4169) [Link]

Yes it is related. The issue seems to be that Linux 2.4.x (and probabbly previous versions) selects the Source IP address used in its own ARP Request packets in a "different" way, but possibly still RFC compliant way. The result is that an ARP Request from a Linux box can have a Source IP address field that some devices and OS's consider to be invalid, and thus don't respond to the ARP Request. Again, it is unclear to me if Linux is really in the wrong on this, but it looks like at least two people are working on a patch to add a sysctl that would allow you to force the Source IP address in a Linux ARP Request packet to be set to an IP address of the outgoing NIC.
For now the best workaround seem to be to set a prefered source IP address for each route, using the "ip route ... src ..." command, and to echo "1" into the arp_filter sysctl in /proc for each NIC. I've not tested this myself, I just finished reading the LONG discussion on the linux-netdev mailing list.