Stopping an IP on one interface

Hi,

I have a Red Hat 9 computer that sits between two networks. Its IP address on one network exists on the other network, as shown below;

+--------------+   +--------------+   +-------------+   +-------------+  
|     Other     |    |                  |    |   Red Hat  |    |                  |  
|  Computer +---| Network1 +---| a.a.a.a-> +---| Network2 +
|    a.a.a.a    |    |                  |    | <-b.b.b.b  |    |                  |  
+--------------+   +--------------+   +-------------+   +-------------+  

The Red Hat computer keeps telling Network1 that it has a.a.a.a and so is intermittently making the other computer unavailable.

Is there any way that I can stop the Red Hat computer using/accepting a.a.a.a on Network1?

I have tried dropping packets with source a.a.a.a on the Network1 interface but it appeared to make no difference.

Thanks
Mark
TempleMoorHighSchoolAsked:
Who is Participating?
 
ahoffmannConnect With a Mentor Commented:
you can not have the same IP on 2 interface on the same logical net segment, it fools all your arp caches

iptables -A INPUT -s a.a.a.a -J DROP

will drop the packets, but it does not help in your case: you need to change the IP
0
 
jlevieConnect With a Mentor Commented:
I agree with ahoffman, but I'll state it bit differently. If a.a.a.a exists on Network1 and Network2 then Network1 & Network2 are really the same network as far as the Linux kernel's networking stack is concerned. And that means that you have two computers on the same network with the same IP. The solution is to change either Network1 or Network2 so that they aren't the same network.
0
 
yhettiCommented:
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 : )

0
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
TempleMoorHighSchoolAuthor Commented:
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
0
 
jlevieCommented:
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).
0
 
yhettiCommented:
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.)

0
 
TempleMoorHighSchoolAuthor Commented:
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
0
 
yhettiCommented:
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
0
 
jlevieCommented:
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.
0
 
ahoffmannCommented:
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.