When examining the routing table (route -n) on a CentOS 5.4 system, you might notice an unexpected entry for the 169.254.0.0/16 network. This route appears automatically even though it's not configured in your network settings GUI (Network > Ethernet Device > Route).

# Example routing table output
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

This is the IPv4 link-local address range (APIPA - Automatic Private IP Addressing) defined in RFC 3927. Systems automatically assign themselves an address in this range (169.254.0.1 to 169.254.255.254) when DHCP fails, allowing limited network communication between hosts on the same link.

The route is automatically added by the kernel's IPv4 stack when an interface comes up, regardless of whether DHCP succeeds. This behavior is intentional and part of the Linux network stack implementation. Even if you have a valid DHCP-assigned address, the link-local route remains as a fallback mechanism.

If you need to remove this route (for security or policy reasons), you have several options:

# Temporary removal (until next reboot or interface restart)
sudo route del -net 169.254.0.0 netmask 255.255.0.0

# Permanent removal (CentOS 5.4 specific)
# Add to /etc/sysconfig/network-scripts/ifcfg-ethX:
NOZEROCONF=yes

# Alternative method via sysctl (add to /etc/sysctl.conf)
net.ipv4.conf.all.arp_filter=1
net.ipv4.conf.all.route_localnet=0

After making changes, verify with:

# Check routing table
route -n

# Check interface-specific settings
cat /proc/sys/net/ipv4/conf/eth2/route_localnet

In most cases, you should leave this route intact as it:

• Provides fallback connectivity for critical services
• Helps with network troubleshooting
• Follows standard network stack behavior

Only disable it if you have specific security requirements or are experiencing conflicts with this network range.

When examining the routing table on a CentOS 5.4 system, you might notice an automatically added route to 169.254.0.0/16 that doesn't appear in your network configuration. This behavior isn't a bug - it's a deliberate feature of modern operating systems implementing RFC standards.

# Typical routing table showing the APIPA route
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

The 169.254.0.0/16 network range is reserved for Automatic Private IP Addressing (APIPA), defined in RFC 3927. When a Linux system fails to obtain an IP address via DHCP, it may automatically assign itself an address in this range to maintain basic network connectivity.

Key characteristics of APIPA:

• Address range: 169.254.1.0 to 169.254.254.255
• Subnet mask: 255.255.0.0 (/16)
• No default gateway assigned
• Link-local scope only

The Linux kernel includes zeroconf networking support that creates this route when an interface is brought up, regardless of DHCP success. This behavior is controlled by the NOZEROCONF parameter in network configuration files.

For CentOS/RHEL systems, check these configuration points:

# Check if zeroconf is disabled in /etc/sysconfig/network
cat /etc/sysconfig/network | grep NOZEROCONF

# Interface-specific setting in ifcfg-ethX files
cat /etc/sysconfig/network-scripts/ifcfg-eth2 | grep -i zeroconf

If you want to prevent this route from being created, you have several options:

# Method 1: Disable globally in /etc/sysconfig/network
echo "NOZEROCONF=yes" >> /etc/sysconfig/network

# Method 2: Disable per interface in ifcfg file
echo "ZEROCONF=no" >> /etc/sysconfig/network-scripts/ifcfg-eth2

# Method 3: Remove existing route manually
route del -net 169.254.0.0 netmask 255.255.0.0

While usually harmless, there are cases where the 169.254.0.0 route can cause issues:

• When running multiple network namespaces
• In complex routing scenarios with policy routing
• When debugging network connectivity issues

# Example: Checking if APIPA address is active
ip addr show eth2 | grep 169.254

# Testing connectivity to another APIPA host
ping -c 3 169.254.123.45

Newer CentOS versions using NetworkManager handle this differently. You can check and modify the behavior with:

# Check current link-local setting
nmcli connection show eth2 | grep link-local

# Disable link-local addressing
nmcli connection modify eth2 ipv4.link-local disabled

Remember to restart networking services after making changes:

service network restart
# Or for newer systems:
systemctl restart NetworkManager