Description of problem: When configuring a network card with ip address in the range 169.254.0.0/16, either manually or by DHCP, then the default gw is assigned to the "lo" (loopback) interface instead of eth0. Then the computer is unable to reach the default gateway and the Internet. The bug is related to the following 3 lines in "/sbin/ifup": ### if [ -z "${NOZEROCONF}" -a "${ISALIAS}" = "no" ]; then ### ip route replace 169.254.0.0/16 dev ${REALDEVICE} ### fi When I comment out those lines (as shown above), it seems to fix the problem. Here is a sample output of "route -n" with the problem: Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 169.254.97.1 0.0.0.0 UG 0 0 0 lo Here is a sample "ifcfg-eth0" file causing the problem: DEVICE=eth0 ONBOOT=yes BOOTPROTO=static IPADDR=169.254.97.5 NETMASK=255.255.0.0 GATEWAY=169.254.97.1 Version-Release number of selected component (if applicable): I had this bug in RHEL4, and also in Fedora Core 5. In FC5, it works fine using DHCP, but not with manual config. in RHEL4, I get the wrong "default gw" mapping in both cases (manual+dhcp). How reproducible: Configure the NIC with IP address such as 169.254.1.10, subnet mask 255.255.0.0 and default gateway 169.254.1.1 You can try both manual configuration and DHCP. Steps to Reproduce: 1. Use "ifcfg-eth0" similar to the above example 2. service network restart 3. route -n Actual results: See routing table above, and note the mapping of "default gw" to "lo" instead of "eth0". Expected results: route -n should show the default gw mapped to "eth0", and the host should be able to connect to the internet. Additional info: The private ip address range 169.254.0.0 is normaly used in APIPA (zeroconf), but some private networks use it as their "normal" private ip address range as well.
I guess the problem is on initscripts side
I've tested this in RHEL 4 (initscripts-7.93.25.EL-1) and the current FC6 devel tree (8.38-1); it works for me with static IPs in both cases. Is there anything else unusual about your config?
After some more testing, I was able to reproduce this. This fix will be in Red Hat Enterprise Linux 5; at this point, it's not likely that it will be backported to previous releases; you can work around it in a variety of ways (setting NOZEROCONF or GATEWAYDEV in the ifcfg files is probably the easiest.)
Nothing unusual on my setup - it was a clean install of FC5 on the first time, and a clean install of RHEL4-ES on the second time. I hope that you will do an official initscripts update for RHEL4 which is the current and supported version of RHEL. Can you be more descriptive about the workarounds that you suggest - the exact syntax and to which file, should it be in ifcfg-eth0 or sysconfig/network, etc. Thanks for your testing and comments, Yizhar
You could put: NOZEROCONF=<anything> in either /etc/sysconfig/network or /etc/sysconfig/network-scripts/ifcfg-lo. Alternatively, you could put: GATEWAYDEV=<the right device name> in /etc/sysconfig/network, or in /etc/sysconfig/network-scripts/ifcfg-<device>. Reopening to consider for RHEL 4 updates - you might want to talk to your support rep as well.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Created attachment 135328 [details] Patch for this issue This should solve it.
Sorry for my ignorance, but can you please write the exact instrucitons for applying the above patch?
cd /etc/sysconfig/network-scripts patch < <the file>
Added in CVS, will be in 7.93.26.EL-1 or later.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0303.html