Harping on ARP
Posted Aug 21, 2003 20:08 UTC (Thu) by
iabervon (subscriber, #722)
Parent article:
Harping on ARP
I am somewhat mystified by people's insistance that a Linux associates IP addresses with machines, not interfaces. When I do /sbin/ifconfig, I get:
eth0 ... inet addr:192.168.0.1
eth1 ... inet addr:18.85.44.195
lo ... inet addr:127.0.0.1
It can clearly report to me what addresses each interface has. So the Linux position must really be that an interface should claim an IP address if it may receive packets destined for the specified IP address. I would assume that iptables behavior ought to be included in this; eth1 should only respond to someone looking for 192.168.0.1 if it will pay attention to packets destined for 192.168.0.1 which arrive on eth1. That is, if eth1 "has" the address 192.168.0.1, because it <i>can but will not</i> receive packets for the host with that address, it should not advertize it.
If I'm reading the thread correctly, there are actually two discussions about ARP in the same thread, only one of which is reported in this article. The other is involved with Linux sending requests out of an interface using a source address not assigned to that interface (but only if that address is assigned to the host and isn't localhost), and caching failures.
That is, if you ping {remote-on-network1} -I {local-on-network2}, you'll ARP on network1 with a source address on network2. The remote machine may not believe that it can reach any machine with address {local-on-network2} without routing, despite the fact that the machine requesting managed to put the ARP packet on this network, and may therefore not respond. Linux will then cache this failure, and not try again with the other source address. This means that a non-root user on a Linux box on a network with a Cisco gateway can break networking if they manage to run ping when the gateway's MAC address is not cached, if the machine has a second network card with an address which doesn't fit the router's internal netmask.
Assuming that Linux is right to treat IP addresses as belonging to the host, shouldn't an ARP failure be cached only if all of the source addresses the host has have failed to elicit a response from the remote machine? If the reason for sending responses for all addresses is to maximize the chance that a packet destined for the host get there, shouldn't it send requests with all of its addresses as the source, in order to maximize the chance that the reply will get back? I can certainly imagine a situation where a switch doesn't forward the response to the sender, because it doesn't know the sender's address is on that segment, since it has a different address for the machine on that segment.
Out of curiousity, will a Linux machine accept an ARP response on a different interface than the one that sent the request? That is, if the network causes the replay addressed to the other interface to actually arrive at the other interface, will the machine realize that it actually asked for this?
(
Log in to post comments)