Where does the route to 169.254.0.0 comes from?
Solution 1:
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
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.