Bug 4899

Summary: IP aliasing problems
Product: [Retired] Red Hat Linux Reporter: hooman
Component: kernelAssignee: David Miller <davem>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 6.0CC: alan, hooman
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-04-22 06:25:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description hooman 1999-09-04 00:50:30 UTC
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.

Comment 1 Cristian Gafton 2000-01-04 22:25:59 UTC
Assigned to dledford

Comment 2 Cristian Gafton 2000-01-04 22:26:59 UTC
Assigned to dledford

Comment 3 Doug Ledford 2000-04-22 06:25:59 UTC
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.

Comment 4 Alan Cox 2000-08-08 13:32:44 UTC
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