|Summary:||ip aliases on lo interface cause loss of default gateway|
|Product:||[Retired] Red Hat Linux||Reporter:||Jeff Frost <jeff>|
|Component:||kernel||Assignee:||Michael K. Johnson <johnsonm>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2000-05-10 16:53:31 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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=18.104.22.168 IPADDR="22.214.171.124" NETMASK="255.255.255.224" NETWORK=126.96.36.199 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="188.8.131.52" NETMASK="255.255.255.224" /etc/sysconfig/network: NETWORKING=yes FORWARD_IPV4=false HOSTNAME="g2-lawson3" GATEWAY=184.108.40.206
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.