![到 169.254.0.0 的路由来自哪里?](https://linux22.com/image/511163/%E5%88%B0%20169.254.0.0%20%E7%9A%84%E8%B7%AF%E7%94%B1%E6%9D%A5%E8%87%AA%E5%93%AA%E9%87%8C%EF%BC%9F.png)
运行 CentOS 5.4
为什么我有到 169.254.0.0 的路由,但它没有出现在网络 > 以太网设备 > 路由配置对话框?
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
答案1
摘自 Red Hat 知识库中的这篇文章:
如何禁用 zeroconf 路由,以便系统在没有 169.254.0.0 / 255.255.0.0 路由的情况下启动?
症状:
每次系统启动时,都会启用 zeroconf 路由 (169.254.0.0)。您可以通过关闭防火墙手动禁用它,然后使用 route 命令删除 169.254.0.0 / 255.255.0.0 的路由。
启用零配置路由的路由示例输出类似于以下内容:
# 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
解决方案:
要在系统启动期间禁用 zeroconf 路由,请编辑 /etc/sysconfig/network 文件并将以下 NOZEROCONF 值添加到文件末尾:
NETWORKING=YES
HOSTNAME=localhost.localdomain
NOZEROCONF=yes
答案2
我喜欢 Marcel 的回答,但它并没有真正解决问题。问题是“我为什么有......”,而不是“我如何禁用”。OP 实际上可能不想禁用此路由。
169.254.0.0/16 网络用于自动专用 IP 寻址 (APIPA)。如果 DHCP 客户端尝试获取地址,但在超时和重试期限后仍未找到 DHCP 服务器,它将随机假定此网络中的地址。这允许与未能获取 DHCP 地址的主机进行通信。
答案3
虽然来得有点晚,但我在排除相同或类似情况的故障时发现了这个问题,并发现了一些需要考虑的其他问题。意识到 OP 的盒子可能已经不存在了,但我认为提供的答案可以扩展一些。也许这会对其他在寻找相同故障排除时发现这个问题的人有所帮助。
APIPA 路由是通过 /etc/sysconfig/network-scripts/ifup-eth 中的条件逻辑添加的。如果您在设置中递归地 grep “169.254”,则可以即时发现这一点:
# 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
虽然大多数人都熟悉(其他评论也提到了)如果 DHCP 失败,这种情况就会启动,但如果您的接口配置不一致,导致它无法检测到除环回之外的任何实际设备,它也会启动。如果您的接口是 eth2,如 OP 提供的路由所示,但配置文件名为 ifcfg-eth1(例如),或其内容将其引用为这样,或者如果 /etc/sysconfig/network 文件将设备称为 eth1 或 eth0(或除 所示以外的任何其他名称ip a
),它将导致添加 APIPA 路由,因为定义的配置引用了不存在的接口名称。
您可能认为情况不可能如此,否则您的接口就不会显示为已配置。实际上,即使您的接口在 上显示为已完全配置ip a
,情况仍然可能如此,例如,如果 network-scripts/ifcfg-eth2 文件中的所有内容都是正确的,但在 /etc/systconfig/network 中命名错误。
禁用 zeroconf是处理此问题的一种方式,但配置问题可能仍会以其他方式出现。如果系统(和 DHCP,如果适用)配置正确且工作正常,则不会添加 APIPA 路由。这是当事情出错时的应急逻辑,禁用它应该比纠正导致它触发的根本问题更不可取。
在禁用 Zeroconf 之前,我建议查看:
$ ip a
/etc/sysconfig/network-scripts/ifcfg-*
/etc/sysconfig/network
看看文件名和内容是否反映了您正在使用的实际接口名称。如果没有,我想可能没有,请考虑对有问题的错误接口名称进行递归 grep,看看它是否潜伏在任何其他配置文件中:
grep -R -i 'eth0' /etc/
然后手动更改它或者打破一些 sed :)
sed -i 's/eth0/eth2/g' /path/and/filename
完成后,您需要重新启动网络服务以使更改生效,具体取决于您的系统,可能如下所示:
systemctl stop network
systemctl start network
或者
service network stop
service network start
请务必再次检查您的路由表以确保问题已得到解决。如果其他方法都失败了,我可能会考虑禁用零配置功能,但如果可能的话,我认为最好保留此功能,而不是纠正导致使用此应急功能的根本问题。