☰

如何避免 Mac OS X 在启动时暂时将其 IP 设置在“链接本地”范围 (169.254.xx) 中？

tag-icon • tag-icon networking mac-osx dhcp link-local
如何避免 Mac OS X 在启动时暂时将其 IP 设置在“链接本地”范围 (169.254.xx) 中？

我有一个 DNS 和 DHCP 服务器（Linux 机器）来管理我的 LAN 地址和名称。

一旦客户端启动并运行，一切都配置完毕并完全正常工作，每个 Mac OS X 客户端都有一个由 DHCP 服务器指定的私有类 192.168.1.x 中的 DHCP 指定 IP。

问题在重启时出现，因为每台机器似乎都在 169.xxx 范围内启动，并且只有在获得 DHCP IP 后一切才正常……这是一个暂时的问题，只需几秒钟。这对我来说非常烦人，因为在 IDS 上，ARP 监视程序会用大量 169.xxx“新”机器淹没日志

有什么想法可以禁用这种行为吗？

正确的行为应该是当且仅当机器无法成功获取 DHCP 给定的 IP 时才获取本地链接 IP 地址。

提前致谢

编辑：

我认为没有时间问题，因为看起来 DHCP 服务器突然响应，而 macosx 站没有继续 DHCP 请求序列。

如以下 tcpdump 输出所示，我们看到 macosx 在请求 DHCP（并得到答复）后立即回退到本地链路，它继续使用本地链路，并且仅在 8 秒后重试并完成新的 DHCP 请求。

TCPDUMP 输出：

    19:49:32.373567 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP，来自 00:25:4b:ac:ae:be (oui 未知) 的请求，长度为 300
    19：49：32.373754 IP fw1.dearchstudio.lan.bootps > Conference-Rooms-Mac-mini.local.bootpc：BOOTP/DHCP，回复，长度 300


    19：49：32.374119 arp 谁有 169.254.22.58 告诉 0.0.0.0
    19：49：32.774285 arp 谁有 169.254.22.58 告诉 0.0.0.0
    19：49：33.174403 arp 谁有 169.254.22.58 告诉 0.0.0.0
    19：49：33.574622 arp 谁有 169.254.22.58 告诉 169.254.22.58
    19：49：33.974890 arp 谁有 169.254.22.58 告诉 169.254.22.58
    19:49:33.984227 IP 169.254.22.58 > 224.0.0.251：igmp v2 报告 224.0.0.251
    19：49：34.978606 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0 [5q] [4n] PTR（QM）？58.22.254.169.in-addr.arpa.[|域]
    19：49：35.078822 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0*- [0q] 5/0/0 PTR[|域]
    19：49：35.229123 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0 [4q] [4n][|域]
    19：49：35.479441 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0 [4q] [4n][|域]
    19：49：35.728759 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0*- [0q] 11/0/0[|域]
    19：49：35.981123 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0 PTR（QM）？58.22.254.169.in-addr.arpa。(44)
    19：49：36.081741 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0*- [0q] 4/0/0 PTR[|域]
    19：49：36.729630 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0*- [0q] 11/0/0[|域]
    19：49：36.808274 arp who-has fw1.dearchstudio.lan 告诉会议室-Mac-mini.local
    19：49：36.808290 arp 回复 fw1.dearchstudio.lan 位于 00：0e：0c：69：b6：10 (oui 未知)
    19:49:36.808424 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP，来自 00:25:4b:ac:ae:be (oui 未知) 的请求，长度为 300
    19：49：36.808609 IP fw1.dearchstudio.lan.bootps > Conference-Rooms-Mac-mini.local.bootpc：BOOTP/DHCP，回复，长度 300
    19:49:37.656051 IP 169.254.22.58 > 224.0.0.251：igmp v2 报告 224.0.0.251
    19：49：38.081483 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0*- [0q] 15/0/0[|域]


    19:49:40.264083 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP，来自 00:25:4b:ac:ae:be (oui 未知) 的请求，长度 300
    19：49：40.264252 IP fw1.dearchstudio.lan.bootps > Conference-Rooms-Mac-mini.local.bootpc：BOOTP/DHCP，回复，长度 300
    19：49：40.264735 arp 谁有会议室-Mac-mini.local 告诉 0.0.0.0
    19：49：40.664952 arp 谁有会议室-Mac-mini.local 告诉 0.0.0.0
    19：49：40.696059 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0*- [0q] 1/0/0（缓存刷新）PTR[|域]
    19：49：40.796526 IP 169.254.22.58.mdns > 224.0.0.251.mdns：0*- [0q] 14/0/0[|域]

dhcpd.log：

fw1:~# tail /var/log/dhcpd.log
8 月 11 日 19:45:52 fw1 dhcpd：通过 eth1 在 192.168.1.162 上向 00:25:4b:ac:ae:be 发送 DHCPACK
8 月 11 日 19:45:56 fw1 dhcpd：从 00:25:4b:ac:ae:be 通过 eth1 向 192.168.1.162 发出 DHCPREQUEST
8 月 11 日 19:45:56 fw1 dhcpd：通过 eth1 在 192.168.1.162 上向 00:25:4b:ac:ae:be 发送 DHCPACK
8 月 11 日 19:48:08 fw1 dhcpd：DHCPDISCOVER 来自 00:13:21:b8:46:e0 通过 eth1：网络 192.168.1/24：无免费租约
8 月 11 日 19:49:32 fw1 dhcpd：从 00:25:4b:ac:ae:be 通过 eth1 向 192.168.1.162 发出 DHCPREQUEST
8 月 11 日 19:49:32 fw1 dhcpd：通过 eth1 在 192.168.1.162 上向 00:25:4b:ac:ae:be 发送 DHCPACK
8 月 11 日 19:49:36 fw1 dhcpd: 通过 eth1 从 00:25:4b:ac:ae:be 发出 DHCPDISCOVER
8 月 11 日 19:49:36 fw1 dhcpd：192.168.1.162 上的 DHCPOFFER 通过 eth1 发送至 00:25:4b:ac:ae:be
8 月 11 日 19:49:40 fw1 dhcpd：从 00:25:4b:ac:ae:be 通过 eth1 向 192.168.1.162 (192.168.1.254) 发送 DHCPREQUEST
8 月 11 日 19:49:40 fw1 dhcpd：通过 eth1 在 192.168.1.162 上向 00:25:4b:ac:ae:be 发送 DHCPACK

我认为STP与此无关。

编辑2：

我完全可以保证这种行为与任何交换机协议或配置无关，我将装有 Snow Leopard Server 的 Mac mini 直接连接到我的 arpwatcher 界面，看到了与交换机相同的行为。

我认为我可以肯定地说这是苹果 OS X 中 link-local 实现的一个 BUG。

答案1

听起来可能是 DHCP 请求没有得到足够快的答复。如果配置了 DHCP，机器将以无 IP 地址 (0.0.0.0) 启动并发送广播请求 IP 地址。只有在规定的时间内没有收到答复时，它才会为自己分配一个本地链接地址。

运行生成树的交换机将表现出此行为，因为它们必须先经过 STP 环路检测过程，然后才允许设备传输。在 Cisco 交换机上，您可以打开“生成树端口快速”以允许设备更快地访问网络。

答案2

不幸的是，我怀疑您能否找到解决方案。部分原因是 Mac OS X（尤其是 10.4 Tiger 及更高版本）是高度异步的。launchd自 Tiger 以来，大多数启动管理都由它处理，我相信从 Leopard 开始，所有启动管理都由它处理。

launchd没有任何依赖支持，因此大多数守护进程等必须自己轮询服务以查看它们是否已启动并准备就绪（请参阅系统启动编程主题：引导过程，但请注意，SystemStarter自 Leopard 以来它已不复存在。有许多框架可以完成繁重的工作，例如系统配置但是我认为，为了使一切正常工作，他们必须做出这样的决定：如果以太网端口有链接但尚未收到 DHCP 响应，则他们需要将其设置为本地链接 IP。

答案3

既然无法路由本地链路 169.254.0.0/16 块，那为什么它对您的 IDS 来说是个问题呢？只需忽略它即可。（只需确保您的路由器确实阻止了它即可。）

我认为，每个 IPv4 主机都应该获得并保持169.254.0.0/16 块中的地址，就像每个 IPv6 接口都已要求具有链路本地地址一样。它们可以是非常当出现故障时很有用。

答案4

与其尝试修改 Mac 的行为（我怀疑您无论如何都做不到），为什么不直接调整 IDS 规则或触发级别呢？在我看来，您的 IDS 对正常和预期的网络活动过于敏感。

相关内容