Description of problem: ifup will add a route to 169.254/16 for use of zeronconf if the following conditions are met (as seen in ifup): if [ -z "${NOZEROCONF}" -a "${ISALIAS}" = "no" ]; then ip route replace 169.254.0.0/16 dev ${REALDEVICE} fi but the anaconda created ifcfg-eth0 entry won't prevent that even if configured as shown by (TYPE=Ethernet and NOZEROCONF=yes manually added) : [root@tapir network-scripts]# cat ifcfg-eth0 # Intel Corporation|82557/8/9 [Ethernet Pro 100] TYPE=Ethernet DEVICE=eth0 ONBOOT=yes BOOTPROTO=static NOZEROCONF=yes IPADDR=66.139.79.212 NETMASK=255.255.255.192 GATEWAY=66.139.79.193 HWADDR=00:02:B3:0A:80:39 Version-Release number of selected component (if applicable): 7.31.31.EL-1 How reproducible: Always Steps to Reproduce: 1.install RHEL 2.add NOZEROCONF=yes to ifcfg-eth0 3.reboot Actual results: a route to 169.254.0.0/16 added to eth0 Expected results: no route Additional info: the version from RHEL5 works correctly, the reason behind this bug defeats logic and my debugging of the ifup scripts and related network-functions with the only workable solution to comment out those 3 lines
marking this bug as invalid as the script is doing what is meant to do eventhough the route is being created it is now attached to interface lo as shown by : [carenas@tapir carenas]$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 66.139.79.192 0.0.0.0 255.255.255.192 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lo 0.0.0.0 66.139.79.193 0.0.0.0 UG 0 0 0 eth0 having zeroconf routed through the loopback is arguable not right, but not for the scope of this bug