37

Running CentOS 5.4

Why do I have route to 169.254.0.0 although it does not appear in Network > Ethernet Device > Route configuration dialog?

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 eth2
169.254.0.0     *               255.255.0.0     U     0      0        0 eth2
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth2
Anthony Geoghegan
  • 2,800
  • 1
  • 23
  • 34
jackhab
  • 751
  • 1
  • 8
  • 20

3 Answers3

65

I like Marcel's answer but it doesn't really address the question. The question was 'Why do I have..', not 'How can I disable'. The OP may in fact not want to disable this route.

The 169.254.0.0/16 network is used for Automatic Private IP Addressing, or APIPA. If a DHCP client attempts to get an address, but fails to find a DHCP server after the timeout and retries period it will randomly assume an address from this network. This allows communication with hosts that have failed to obtain a DHCP address.

Clarus
  • 131
  • 7
Kyle Smith
  • 9,563
  • 1
  • 30
  • 32
  • 2
    I think he knew that. He really wanted to know why the route appears although his DHCP (if he uses one) obviously worked because he has an IP address on that interface different from 169... Why do I have ? ... and as the answer says ... because you didn't disable it :) –  Apr 15 '10 at 14:31
  • 3
    Marcel: Maybe, maybe not. Your answer was great, just wanted to make sure he understood why he would have a 169.254 entry to begin with. :) – Kyle Smith Apr 15 '10 at 16:20
  • 1
    and I appreciate it , thank you ... what is SF if not the perfect place to get the complete answer :) –  Apr 15 '10 at 19:01
  • 1
    If he knew it he is not really smart enough to use a computer because he still asks WHY it is there. Or, if you do not assume the OP is a total idiot then assuming he knew it is not smart because he explicitly asks where it came from, not how to disable it. Does not get more explicit. – TomTom Jan 13 '14 at 07:42
41

From this article on the Red Hat Knowledgebase:

How do I disable the zeroconf route so that the system will boot without the 169.254.0.0 / 255.255.0.0 route?

Symptom:

Every time the system boots, the zeroconf route (169.254.0.0) is enabled. You manually disable it by turning off the firewall and remove the route with 169.254.0.0 / 255.255.0.0 using the route command.

Example output of the route with the zeroconf route enables would like similar to the following:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.15.50.0      *               255.255.252.0   U     0      0        0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0

Solution:

To disable the zeroconf route during system boot, edit the /etc/sysconfig/network file and add the following NOZEROCONF value to the end of the file:

NETWORKING=YES
HOSTNAME=localhost.localdomain
NOZEROCONF=yes
splattne
  • 28,348
  • 19
  • 97
  • 147
2

Pretty late to the party but I found this while troubleshooting a same or similar circumstance and discovered some additional things to consider. Realize OP's box may not even exist anymore, but I think the provided answers can be expanded upon some. Maybe this will help others who find this in search of the same kind of troubleshooting.

The APIPA route is added by conditional logic in the /etc/sysconfig/network-scripts/ifup-eth. You can discover this on the fly if you grep for "169.254" recursively in your settings:

# Add Zeroconf route.
if [ -z "${NOZEROCONF}" -a "${ISALIAS}" = "no" -a "${REALDEVICE}" != "lo" ]; then
ip route add 169.254.0.0/16 dev ${REALDEVICE} metric $((1000 + $(cat /sys/class/net/${REALDEVICE}/ifindex))) scope link
fi

While most are familiar with (and other comments have addressed) this kicking off if DHCP fails, it will also kick off if there are inconsistencies with your interface config causing it to detect no real device other than loopback. If your interface is eth2 as indicated by OP's provided route, but the config file is named ifcfg-eth1 (for example), or its contents refer to it as such, or if the /etc/sysconfig/network file refers to the device as eth1 or eth0 (or anything other than what's indicated by ip a), it's going to cause the APIPA route to get added because the configurations defined refer to an interface name that doesn't exist.

You might be thinking this can't be the case, or your interface wouldn't appear configured. Actually, this can still be the case even if your interface appears fully configured on ip a, if for example it's all correct in the network-scripts/ifcfg-eth2 file, but named wrong in /etc/systconfig/network.

Disabling zeroconf is one way to handle this, but the configuration issue may rear its head in other ways still. If the system (and DHCP, if applicable) were configured and working properly, the APIPA route would not get added. This is contingency logic for when things have gone awry, and disabling it should be less preferred than correcting the underlying problem causing it to fire off.

Before disabling Zeroconf, I suggest looking at:

$ ip a
/etc/sysconfig/network-scripts/ifcfg-*
/etc/sysconfig/network

And see if the file names and contents reflect the actual interface name you're working with. If they don't, and I'm thinking they probably don't, consider a recursive grep for the offending wrong interface name to see if it's lurking in any other configuration files:

grep -R -i 'eth0' /etc/

And then change it out manually or break out some sed :)

sed -i 's/eth0/eth2/g' /path/and/filename

When you're done, you'll need to restart the network service for the changes to take effect, depending on your system that might look like:

systemctl stop network
systemctl start network

or

service network stop
service network start

Be sure to check your route table again to ensure the problem was fixed. If all else fails, I could see disabling the zeroconf feature, but if possible I think it'd be preferable to preserve this functionality and instead correct the underlying problem causing this contingency feature to be utilized.

Nick
  • 21
  • 1