Bug 203591 - wrong default gw route when the internal network uses 169.254.x.x addresses
wrong default gw route when the internal network uses 169.254.x.x addresses
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: initscripts (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
Brock Organ
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-22 13:00 EDT by Yizhar Hurwitz
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0303
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 13:32:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for this issue (537 bytes, patch)
2006-08-31 16:14 EDT, Bill Nottingham
no flags Details | Diff

  None (edit)
Description Yizhar Hurwitz 2006-08-22 13:00:05 EDT
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.
Comment 1 Radek Vokal 2006-08-23 04:38:05 EDT
I guess the problem is on initscripts side 
Comment 2 Bill Nottingham 2006-08-23 14:30:52 EDT
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?
Comment 3 Bill Nottingham 2006-08-23 14:54:09 EDT
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.)
Comment 4 Yizhar Hurwitz 2006-08-23 15:28:48 EDT
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
Comment 5 Bill Nottingham 2006-08-23 15:41:33 EDT
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.
Comment 6 RHEL Product and Program Management 2006-08-23 17:35:33 EDT
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.
Comment 8 Bill Nottingham 2006-08-31 16:14:30 EDT
Created attachment 135328 [details]
Patch for this issue

This should solve it.
Comment 11 Yizhar Hurwitz 2006-09-01 11:51:53 EDT
Sorry for my ignorance, but can you please write the exact instrucitons for 
applying the above patch?
Comment 12 Bill Nottingham 2006-09-01 13:44:58 EDT
cd /etc/sysconfig/network-scripts

patch < <the file>
Comment 13 Bill Nottingham 2006-11-20 17:14:18 EST
Added in CVS, will be in 7.93.26.EL-1 or later.
Comment 17 Red Hat Bugzilla 2007-05-01 13:32:17 EDT
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

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