Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 8234 - ip aliases on lo interface cause loss of default gateway
ip aliases on lo interface cause loss of default gateway
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Michael K. Johnson
Depends On:
  Show dependency treegraph
Reported: 2000-01-06 13:05 EST by Jeff Frost
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-05-10 12:53:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Frost 2000-01-06 13:05:12 EST
After installing RedHat 6.1, and adding an ip alias on the loopback
interface, upon reboot I lose my default gateway.  If I remove the ip
alias on the loopback interface, I get the gateway back. The ip aliases on
the loopback interface worked wonderfully in RedHat 6.0.  Any ideas what I
can do?  I've already upgraded my linuxconf and initscripts after seeing
mention of ip alias problems caused by the initscripts, but that doesn't
resolve the issue.
Comment 1 Bill Nottingham 2000-01-18 11:58:59 EST
What does /etc/sysconfig/network-scripts/ifcfg-* and /etc/sysconfig/network say?
Comment 2 Jeff Frost 2000-01-18 12:34:59 EST



# If you're having problems with gated making a martian,
# you can change this to something else (, for example)




Comment 3 Bill Nottingham 2000-02-02 12:19:59 EST
I can't reproduce this here with the current Raw Hide
initscripts; do they work for you?
Comment 4 Jeff Frost 2000-02-02 17:45:59 EST
If you mean this package:  initscripts (RHSA-1999:052-04) it is currently
installed and 100% reproducible on my system.  I could arrange ssh access for
you to one of them if you wanted to see it in action.
Comment 5 Bill Nottingham 2000-02-02 17:54:59 EST
Actually, I mean the initscripts at
ftp://ftp.redhat.com/pub/rawhide/i386/ - I wasn't
able to reproduce it with that package.
Comment 6 Jeff Frost 2000-02-23 13:23:59 EST
Well, tried the initscripts in the rawhide directory, rebooted, put in the
virtual IP on the loopback interface, rebooted again and voila, no default
route. :(  Do I need to update any other packages when I update the
Comment 7 Bill Nottingham 2000-02-28 11:07:59 EST
OK, confirmed, finally. IFF the loopback alias is on the same
network as the ethernet address, it will fail.

Out of curiousity, is there a reason you're putting the alias
on the loopback as poosted to ethernet device?
Comment 8 Bill Nottingham 2000-02-28 11:21:59 EST
Looks to be kernel weirdness; it refuses to assign a default
route through the ethernet device if the loopback alias exists.
Comment 9 Jeff Frost 2000-02-28 12:44:59 EST
The reason we're adding it to the loopback interface and not the ethernet
interface is because in order to use the Direct Server Return feature of our
load balancing foundry switch, you must assign an ip alias to the loopback
interface that is the same as the virtual ip address on the foundry switch.
That way the server recognizes the IP as its own and answers directly back to
the client and not back through the switch.
Comment 10 Doug Ledford 2000-05-10 00:14:59 EDT
Part of the problem, of course, is that your config for eth0 and lo:0 both have
IP addresses that are part of the same subnet.  As a result, when you try to add
a default route to a host on the subnet shared by both interfaces, the kernel
rightly doesn't know which of the interfaces you would prefer to use (generic
multi-path problem here).  One thing to try is adding a line that reads:


to the /etc/sysconfig/network file and see if the scripts are able to cope after
that.  If not, I would think that using an alias on the ethernet device would be
sufficient, regardless of what the Foundry Networks stuff might say.  I would
have to have a more descriptive analysis of the network requirements before I
would be able to say for sure that an eth0:0 alias wouldn't work.
Comment 11 Jeff Frost 2000-05-10 01:06:59 EDT
I'll try the GATEWAYDEV statement tomorrow and see if that makes it work.  As
for why an alias on eth0:0 won't work: The way direct server return works on
the foundry is this: The foundry receives an incoming request on it's ethernet
interface for a given virtual IP address, it then forwards that packet to the
actual server's IP address but leaving the ip address in the packet for the
virtual IP (the one attached to one of the foundry's ethernet links).  The
actual server then has to recognize that IP address as one of it's own (thus
the IP address on the loopback interface) and respond back through it's normal
route.  If we put the alias on the eth0:0 then we'll have an ip address
conflict between the linux box and the foundry, so it has to go on the
loopback.  Hopefully I ran through that explanation correctly.
Comment 12 Doug Ledford 2000-05-10 01:14:59 EDT
Given your explanation, an alias on eth0:0 should work, but you would have to go
about the business of keeping any ARP packets for that IP address from going out
the ethernet interface, which would mean some special ARP address setup in order
to stop the ARP packets.  Your current setup will require less work if the
GATEWAYDEV= parameter works.
Comment 13 Jeff Frost 2000-05-10 12:53:59 EDT
the GATEWAYDEV directive didn't work, so now we'll try the eth0:0 alias with
blocking the ARP packets and see how that goes.
Comment 14 Alan Cox 2000-08-08 14:52:33 EDT
Im assuming that worked since there was no further traffic but the foundry setup
doesnt appear to be valid internet behaviour, and relies on stuff like undefined
arp properties.
Comment 15 Jeff Frost 2000-08-08 14:59:02 EDT
Actually, no, it didn't work.  We opted to go with a NAT implementation even 
though the Direct Server Return offers better performance since we couldn't get 
DSR working with Linux.

Note You need to log in before you can comment on or make changes to this bug.