Hi,

I'm in front of a strange thing. I have a small DMZ with 3 servers in it: one W2K, one Suse Linux server and a Redhat 9 server. They are all connected on a simple hub. They all have only one ethernet card installed.

When I try to setup networking on my redhat 9 machine, using 'ifup eth0', I get an error message 'some other host already have this IP address: 192.168.0.X'. I also tried using 3 other IP address, with no luck. I have confirmed that all IP address I tried are available.

if I do a arping, on my redhat machine, it returns a reply from 0.0.0.0 from the same MAC address(always), even if I try other IP address !

I searched for the MAC address replying to my ARP request, and it appears to be the Suse machine. I don't have access to this machine though.. I would like to know how to fix this behavior, so I'll contact the owner of that box ASAP.

Note that the Win2k server can ping the Suse machine successfully, but it always return a 'timeout. on the FIRST ICMP packet sent...

What can cause a server to reply to ALL ARP requests, when it should only reply to ARP containing it's own ip address?

Any ideas?

Hi,
almost 6 years later I faced the same problem in my network. A linux server machine responding to all ARP requests (and all Arping for all IP's) in the net. This may cause ALL Windows Vista (and a CentOs Linux) to be unable to get an IP (even static IP's). At least, Windows XP's machine ignore this problem.
The solution is to change a single archive that specifies how the machine will respond to ARP requests:
sysctl net.ipv4.conf.all.arp_ignore=1
or
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

The default (and problematic) is 0 for that parameter.

arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied
4-7 - reserved
8 - do not reply for all local addresses

The max value from conf/{all,interface}/arp_ignore is used
when ARP request is received on the {interface}

Similar problem here:
http://alt.awesometrousers.net/artic...rp_ignore.html

Hope this help a future similar problem

Cheers

Responding to all ARP requests is not default behaviour. So in my humble opinion the solution is not to arp_ignore on others but to correct behaviour on the offending machine.

I agree. Maybe I didn't make myself clear enough. The default value for arp_ignore is 0 and shouldn't be a problem in 99% of the cases. This case is an strange one, which is probably related to some bug or outdated kernel of the offending machine (a Suse Linux Enterprise Server 10). But I have seen other cases, while researching, where arp_ignore=0 can cause problems when the server is running in several different networks. Some people has reported it as a bug or has suggested that it should default to 1 instead of 0, which I think is more correct (Respond to the ARP requests of the incoming interface, not to check in all the interfaces for an ARP that came of only one of them).
I think this solution is harmless and is the only one that worked for this specific and strange behaviour. (And the change has to be made only in the offending machine, not in the others...)


PS: And shows another new "feature" of Vista...

Regards,
Alex

I encountered this problem when configuring two interfaces on one machine to use the same network:
eth0 192.168.1.10
eth1 192.168.1.11

When any other machine on the same network would try to connect to either of the addresses, both interfaces replied saying "this is my address!". Subsequently, the first message to get across would convince the inquiring machine and be saved in the ARP cache there, resulting in unpredictable traffic.

By setting net.ipv4.conf.all.arp_ignore=1 only the interface configured with the requested IP will send an ARP reply, which is what one would expect from a network interface.