Stopping an IP on one interface

I'll assume you're using a >2.6.4 or >2.4.24.  

echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore

Then

echo "1" > /proc/sys/net/ipv4/conf/eth0/arp_ignore
...
echo "1" > /proc/sys/net/ipv4/conf/ethX/arp_ignore


Linux (via RFC 1122 I think) will answer arp requests on any interface that it gets the request for.  This is allowable behavior because you really should not have a system set up like you've got it going.  I have, however, done the same thing a number of times during server switchovers and building clusters.  There's generally a more elegant way, but sometimes Quick & Dirty is good enough...

arp_ignore tells the kernel *not* to answer an arp request unless it's specifically for the interface the request was received on.  In previous kernels, it was /proc/sys/net/ipv4/conf/*/hidden

There is also a corrosponding arp_filter and arp_announce. I'll let you research those : )

Thanks for the input.

The kernel version is 2.4.20-8

I have tried

for f in /proc/sys/net/ipv4/conf/*/hidden; do
      echo 1 > $f
Done

and

echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore

but the both error as "No such file or directory"

I looked again on the net and found ifconfig -arp but this seams to stop all arp requests (even on the appropriate interface).

Any ideas?
Thanks
Mark

I don't believe arp_ignore is going to help in this case. The fundamental problem is that  Network1 and Network2 have the same IP block and netmask. As far as the kernel is concerned it is going to route traffic to the IP a.a.a.a (which exists on both networks) via "the route" to a.a.a.0/mask, which will be the first interface configured (typically eth0).

These guys are right, the routing must be a fiasco.  Paste the routing table here : )

Working on the assumption you know what you're doing, try

echo "1" > /proc/sys/net/ipv4/conf/eth0/arp_filter
echo "1" > /proc/sys/net/ipv4/conf/eth1/arp_filter
echo "1" > /proc/sys/net/ipv4/conf/all/arp_filter

(I'm continuing this because I've done exactly what you've described and had a very legit. reason for doing it.)

I have tried what you are suggesting but it appears not to make a difference if I connect to a.a.a.a from the network 1 I connect to the Red Hat computer.

There is nothing added to the routing tables as the Red Hat computer will never have to contact a.a.a.a on network 1. All I need is for the Red Hat computer to not respond to requests for a.a.a.a on network 1.

Thanks all for the help, any more ideas?
Mark

Okay..those proc entries really should have worked.  I have no idea why *none* of them are there, unless its another of those Stupid Redhat Kernel Version things.  At this point, I would go ahead and compile a new kernel (I'm not sure how redhat responds to 2.6 series kernels.)  Give 2.6.5 a try (.6.6 and .6.7 seem to be unstable in my limited experience).  Under the network filtering, there is an option for ARP filtering.  There's also a new tool out called arptables, which works more or less like IPTables.   Arptables will do what you need to do, but it's a lot more complicated of a setup than the /proc entries.  It will, however, actually work.

Wes

I really don't see how you are going to do this and have the system able to use both interfaces. The kernel knows that there is a locally attached network and it must be able to answer ARP requests for that network. In this case you are confusing things by having the same network split physically and attached to different interfaces. As far as the kernel is concerned the two separate pieces are in fact the same network.

The only rational solution would be to use two Linux boxes separated by a glue network and statically NAT IP's in the "hidden" network, if you need fixed IP's. If fixed IP's from the "hidden" network aren't needed on the "public "network you could use dynamic NAT onto a single IP in the "public" network.

to repeat again what have been suggested: re-read the the very first comment in this thread!

If you want do it (same IP on 2 NIC) anyway, you need to patch the kernel yourself.