Where does the route to 169.254.0.0 comes from?
Solution 1
From this article on the Red Hat Knowledgebase:
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
Solution 2
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.
Solution 3
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.
Related videos on Youtube
jackhab
Updated on September 17, 2022Comments
-
jackhab over 1 year
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
-
Admin about 14 yearsI 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 :)
-
Kyle Smith about 14 yearsMarcel: 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. :)
-
TomTom over 10 yearsIf 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.
-
Evan Carroll over 2 yearsit would be nice to actually say what the zeroconf route is used for