As reported in bug 4899, setting the hidden flag resolves this issue. /proc/sys/net/ipv4/conf/devicename/hidden However for RHE3 and RHE4 (RH AS 4), this option is not available. We're attempting to set IPs hidden on the lo device to bind a web server to it, and put LVS in front of it to perform load balancing. We can successfully do this on Solaris 9, but RHEL has problems due to the arp responding as described in bug 4899. I was surprised to find our exact problem already reported, with resolution, and the issue has come back up in RHEL Now, following this maillist posting from Lon Hohberger <lhh redhat com> on Fri, 15 Apr 2005 16:39:58 -0400, concerning "RFC: Piranha + Direct Routing HOWTO v0.2", there appears to be a workaround by modifying the ARP table configuration. https://www.redhat.com/archives/piranha-list/2005-April/msg00000.html However, this is NOT documented. Is this going the be the only resolution available to this issue? Or is the resolution documented (and resolved by) in bug 4899 going to be applied once again so we can do in RHEL what we can already do in Solaris 9? If the prior is the final solution, can we have some formal documentation created as a resolution to this bug - so we can be at least a little reassured it won't break when upgrading to a future RHEL release? Thanks. -RG +++ This bug was initially created as a clone of Bug #4899 +++ Hello Redhat, Apologies in advance as this is my first time "reporting" a bug and I'm rather a novice with Linux. But, I know my IP, so I think and hope what I have here is pretty legit. The bug has been seen with RedHat linux version 6.0. We've seen it with kernels 2.2.5-15, 2.2.10, and 2.2.11. I haven't tried 2.2.12, but I believe it will be there also, since I did some looking around and found no mention of anything even near this. We've basically uncovered 3 bugs with assigning IP aliases to interfaces. They're easy to see. Let's say I have a Linux machine with IP 192.168.1.1/255.255.255.0, and I'd like to use an alias of 192.168.1.100/255.255.255.0. A legitimate application is to assign this alias to the loopback (lo) interface. This is useful in case I need the IP address to be "internal" and not associated with an ethernet interface. This will also eliminate ARPs for this IP. In other words, the host will not (or should not) answer to ARPs for 192.168.1.100 if they're seen on its ethernet interface, since this IP is in no way associated with ethernet. Problem 1: If the alias is configured with ifconfig lo:1 192.168.1.100 netmask 255.255.255.255 up The machine will respond to ARPs for 192.168.1.100. This is wrong, because this is not an ethernet interface alias. With a 2.0.x kernel (I've tried 2.0.36)this works perfectly fine and the machine does not illegally answer ARPs. Problem 2: If I configure the alias with ipconfig lo:1 192.168.1.100 netmask 255.255.255.0 up then the illegal ARP replies stop, so the machine will no longer answer to ARPs received on its ethernet interface for IP 192.168.1.100. However, with this statement, the linux machine thinks that it itself is EVERY HOST on the 192.168.1.0 network. It's actually rather amusing!!! A telnet from this linux machine to any 192.168.1.X address will give you a login prompt for the machine itself (as if you'd done "telnet 127.0.0.1"). So, no communication is any longer possible with the 192.168.1.0 network. Again, with 2.0.36 this works just fine. Problem 3: While trying to work our way around the desired configuration of putting an alias IP on the loopback interface, we ran into a third problem. The ifconfig option of "-arp" is not supported (it's ignored) for ethernet aliases. In other words if I do a ifconfig eth0:1 192.168.1.100 netmask 255.255.255.0 -arp up the -arp is ignored and indeed the machine will respond to ARPs for this IP. If I use the -arp option for eth0, it works OK. It's aliases of eth0 that ignore the option. Again, 2.0.x handles the option fine, both for eth0 itself and its aliases. I hope I described the problems OK. I think you should be able to easily recreate them. I marked them as "kernel" bug because that's what I was told they really were. If you have any questions, please let me know at hooman. Also, if you have any news regarding these, I'd appreciate hearing about it, as we have 4 customers that are currently suffering from this. Thanks in advance, Hooman. -- Additional comment from gafton on 2000-01-04 17:25 EST -- Assigned to dledford -- Additional comment from gafton on 2000-01-04 17:26 EST -- Assigned to dledford -- Additional comment from dledford on 2000-04-22 02:25 EST -- Assigned to DaveM, Cc: Alan Need to see if this is A) intended and correct under the current IP alias implementation and B) if it is this way in 2.3 kernels as well as 2.2 kernels. Some of the things described above sound like issues of making things happen automatically because it makes the common cases easier to configure, but happen to mess up this user's setup. -- Additional comment from alan on 2000-08-08 09:32 EST -- This is following the ARP specification fine. This issue does come up for a few very broke and warped setups and current 2.2 allows you set to set the hidden flag to deal with it /proc/sys/net/ipv4/conf/devicename/hidden
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.