我有一个 DNS 和 DHCP 服务器(Linux 机器)来管理我的 LAN 地址和名称。
一旦客户端启动并运行,一切都已配置并完全正常工作,让每个 Mac OS X 客户端都有一个 DHCP 给定的 IP,该 IP 属于 DHCP 服务器给定的私有类 192.168.1.x。
问题在重新启动时出现,因为每台机器似乎都在 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 > 会议室-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.darchstudio.lan 告诉 Conference-Rooms-Mac-mini.local 19:49:36.808290 arp 回复 fw1.darchstudio.lan is-at 00:0e:0c:69:b6:10 (oui Unknown) 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 > 会议室-Mac-mini.local.bootpc:BOOTP/DHCP,回复,长度 300 19:49:40.264735 arp who-has Conference-Rooms-Mac-mini.local 告诉 0.0.0.0 19:49:40.664952 arp who-has Conference-Rooms-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:DHCPACK 在 192.168.1.162 到 00:25:4b:ac:ae:be via eth1 8 月 11 日 19:45:56 fw1 dhcpd: DHCPREQUEST for 192.168.1.162 from 00:25:4b:ac:ae:be via eth1 8 月 11 日 19:45:56 fw1 dhcpd: DHCPACK 在 192.168.1.162 到 00:25:4b:ac:ae:be via eth1 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: DHCPREQUEST for 192.168.1.162 from 00:25:4b:ac:ae:be via eth1 8 月 11 日 19:49:32 fw1 dhcpd:DHCPACK 在 192.168.1.162 到 00:25:4b:ac:ae:be via eth1 8 月 11 日 19:49:36 fw1 dhcpd: DHCPDISCOVER 从 00:25:4b:ac:ae:be via eth1 8 月 11 日 19:49:36 fw1 dhcpd:DHCPOFFER 在 192.168.1.162 到 00:25:4b:ac:ae:be via eth1 8 月 11 日 19:49:40 fw1 dhcpd: DHCPREQUEST for 192.168.1.162 (192.168.1.254) from 00:25:4b:ac:ae:be via eth1 8 月 11 日 19:49:40 fw1 dhcpd:DHCPACK 在 192.168.1.162 到 00:25:4b:ac:ae:be via eth1
我认为 STP 与此无关。
编辑2:
我绝对可以确保这种行为与任何交换机协议或配置无关,我将带有 Snow Leopard Server 的 Mac mini 直接连接到我的 arpwatcher 接口,我看到了与交换机相同的行为。
我想我可以肯定地说这是 OS X 中链接本地实现中的一个 Apple BUG。
不幸的是,我怀疑你会找到解决方案。部分原因是Mac OS X,尤其是。10.4 Tiger 及更高版本是高度异步的。自 Tiger 以来,大部分创业管理都由
launchd
Tiger 负责,我相信所有这些都是 Leopard。launchd
没有任何依赖支持,因此大多数守护程序等必须自己轮询服务以查看它们何时启动并准备好(请参阅系统启动编程主题:启动过程,但请注意,SystemStarter
它已经消失了豹)。有许多框架可以完成繁重的工作,例如System Configuration,但我假设为了使这一切正常工作,他们必须做出决定,如果以太网端口有链接但他们还没有得到DHCP 响应,但他们需要将其设置为本地链接 IP。听起来可能是 DHCP 请求没有得到足够快的响应的问题。如果配置为 DHCP,机器将以无 IP 地址 (0.0.0.0) 启动并发送广播请求。只有当它在规定的时间内没有得到回复时,它才会为自己分配一个本地链接地址。
运行生成树的交换机会表现出这种行为,因为它们首先必须通过 STP 环路检测过程才能允许设备进行传输。在 Cisco 交换机上,您可以打开“spanning-tree portfast”以允许设备更快地访问网络。
由于无法路由链接本地 169.254.0.0/16 块,为什么您的 IDS 会担心它?简单地忽略它。(只需确保您的路由器确实阻止了它。)
在我看来,每个 IPv4 主机都应该在 169.254.0.0/16 块中获取并保留一个地址,就像每个 IPv6 接口都需要有一个本地链路地址一样。当事情破裂时,它们会非常有用。
与其尝试修改 Mac 的行为(我怀疑你无论如何都可以),为什么不简单地调整 IDS 规则或触发级别?在我看来,您的 IDS 对正常和预期的网络活动过于敏感。