Bug 8234 - ip aliases on lo interface cause loss of default gateway
Summary: ip aliases on lo interface cause loss of default gateway
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-01-06 18:05 UTC by Jeff Frost
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-05-10 16:53:31 UTC
Embargoed:


Attachments (Terms of Use)

Description Jeff Frost 2000-01-06 18:05:12 UTC
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 16:58:59 UTC
What does /etc/sysconfig/network-scripts/ifcfg-* and /etc/sysconfig/network say?

Comment 2 Jeff Frost 2000-01-18 17:34:59 UTC
ifcfg-eth0:

DEVICE="eth0"
BROADCAST=216.35.98.255
IPADDR="216.35.98.236"
NETMASK="255.255.255.224"
NETWORK=216.35.98.224
ONBOOT="yes"
BOOTPROTO="none"
IPXNETNUM_802_2=""
IPXPRIMARY_802_2="no"
IPXACTIVE_802_2="no"
IPXNETNUM_802_3=""
IPXPRIMARY_802_3="no"
IPXACTIVE_802_3="no"
IPXNETNUM_ETHERII=""
IPXPRIMARY_ETHERII="no"
IPXACTIVE_ETHERII="no"
IPXNETNUM_SNAP=""
IPXPRIMARY_SNAP="no"
IPXACTIVE_SNAP="no"

ifcfg-lo:

DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback

ifcfg-lo:0:

IPADDR="216.35.98.231"
NETMASK="255.255.255.224"

/etc/sysconfig/network:

NETWORKING=yes
FORWARD_IPV4=false
HOSTNAME="g2-lawson3"
GATEWAY=216.35.98.225

Comment 3 Bill Nottingham 2000-02-02 17:19:59 UTC
I can't reproduce this here with the current Raw Hide
initscripts; do they work for you?

Comment 4 Jeff Frost 2000-02-02 22:45:59 UTC
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 22:54:59 UTC
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 18:23:59 UTC
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
initscripts?

Comment 7 Bill Nottingham 2000-02-28 16:07:59 UTC
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 16:21:59 UTC
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 17:44:59 UTC
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 04:14:59 UTC
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:

GATEWAYDEV=eth0

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 05:06:59 UTC
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 05:14:59 UTC
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 16:53:59 UTC
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 18:52:33 UTC
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 18:59:02 UTC
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.