我有一个DNS和DHCP服务器（Linux机器）pipe理我的LAN地址和名称。
一旦客户端启动并运行，所有configuration和完全工作，每个Mac OS X客户端DHCP服务器提供的私有类192.168.1.x中给定的IP。
这个问题在重新启动时会上升，因为每台机器似乎都在169.xxx范围内启动，并且只有在获得了DHCP IP后才能够正常工作…这只是暂时的问题，只需要几秒钟。 这对我来说非常烦人，因为在IDS上，ARP观察者用169.xxx“新”机器
任何想法来禁用此行为？
假设正确的行为应该是获得一个本地链接的IP地址，当且仅当该机器不能成功地获得一个给定IP的DHCP时。
提前致谢
编辑：
我认为没有计时问题，因为似乎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 who有169.254.22.58告诉0.0.0.0
19：49：32.774285 arp who有169.254.22.58告诉0.0.0.0
19：49：33.174403 arp who-has 169.254.22.58 tell 0.0.0.0
19：49：33.574622 arp who有169.254.22.58告诉169.254.22.58
19：49：33.974890 arp who有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 [| domain]
19：49：35.229123 IP 169.254.22.58.mdns> 224.0.0.251.mdns：0 [4q] [4n] [| domain]
19：49：35.479441 IP 169.254.22.58.mdns> 224.0.0.251.mdns：0 [4q] [4n] [| domain]
19：49：35.728759 IP 169.254.22.58.mdns> 224.0.0.251.mdns：0 * - [0q] 11/0/0 [| domain]
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 [| domain]
19：49：36.729630 IP 169.254.22.58.mdns> 224.0.0.251.mdns：0 * - [0q] 11/0/0 [| domain]
19：49：36.808274 arp who-has fw1.dearchstudio.lan告诉Conference-Rooms-Mac-mini.local
19：49：36.808290 arp reply fw1.dearchstudio.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 [| domain]
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 who-Conference-Rooms-Mac-mini.local告诉0.0.0.0
19：49：40.664952 arp who-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（Cache flush）PTR [| domain]
19：49：40.796526 IP 169.254.22.58.mdns> 224.0.0.251.mdns：0 * - [0q] 14/0/0 [| domain]
dhcpd.log ：
fw1：〜＃tail /var/log/dhcpd.log Aug 11 19:45:52 fw1 dhcpd：192.168.1.162到00：25：4b：ac：ae上的DHCPACK：通过eth1 Aug 11 19:45:56 fw1 dhcpd：从00：25：4b：ac：ae：192.168.1.162的DHCPREQUEST：通过eth1 Aug 11 19:45:56 fw1 dhcpd：192.168.1.162到00：25：4b：ac：ae的DHCPACK：通过eth1 8月11 19:48:08 fw1 dhcpd：从00：13：21：b8：46：e0 DHCPDISCOVER通过eth1：networking192.168.1 / 24：没有空闲的租约 Aug 11 19:49:32 fw1 dhcpd：从00：25：4b：ac：ae：192.168.1.162的DHCPREQUEST：通过eth1 8月11 19:49:32 fw1 dhcpd：192.168.1.162到00：25：4b：ac：ae上的DHCPACK：通过eth1 Aug 11 19:49:36 fw1 dhcpd：从00：25：4b：ac：ae：DHCPDISCOVER通过eth1 8月11 19:49:36 fw1 dhcpd：DHCPOFFER在192.168.1.162到00：25：4b：ac：ae：通过eth1 8月11日19:49:40 fw1 dhcpd：从00：25：4b：ac：ae：192.168.1.162（192.168.1.254）的DHCPREQUEST：通过eth1 Aug 11 19:49:40 fw1 dhcpd：192.168.1.162到00：25：4b：ac：ae上的DHCPACK：通过eth1
我认为STP不是这个问题。
编辑2：
我明确地可以确保这种行为与任何交换机协议或configuration没有任何关系 ，我将Mac mini与Snow Leopard Server直接连接到我的arpwatcher接口，我看到了与交换机相同的行为。
我想我可以肯定地说这是在OS X的链接本地实现中的一个苹果BUG 。
这听起来可能有一个DHCP请求没有得到足够快的回答问题。 如果configuration为DHCP，机器将以无IP地址（0.0.0.0）启动，并发送请求一个的广播。 只有在需要的时间内没有得到回复，它才会为自己分配一个本地链接地址。
运行生成树的交换机将出现这种行为，因为在允许设备传输之前，它们首先必须经过STP环路检测过程。 在Cisco交换机上，您可以打开“spanning-tree portfast”以允许设备更快地访问networking。
不幸的是，我怀疑你会find解决办法。 部分原因是Mac OS X， 10.4 Tiger和更高版本，是非常asynchronous的。 自从Tiger开始，大部分的创业pipe理工作都已经完成，我相信所有这些都是Leopard。
launchd没有任何依赖性支持，所以大多数守护进程都必须自己进行服务轮询，以查看它们何时启动和准备就绪（请参阅系统启动编程主题：启动过程 ，但请注意， SystemStarter是去豹了）。 有很多框架可以完成繁重的工作，例如系统configuration ，但是我想假设为了使这一切都起作用，他们必须做出这样的决定：如果以太网端口有一个链接但是没有得到一个DHCP响应，但他们需要将其设置为本地链路IP。
由于本地链路本地169.254.0.0/16块无法路由，为什么这是您的IDS的关注？ 简单地忽略它。 （只要确保你的路由器真的阻止它。）
在我看来，每个IPv4主机都应该在169.254.0.0/16块中获得并保留一个地址，正如每个IPv6接口都必须具有链路本地地址一样。 事情破裂时，它们可能非常有用。
为什么不简单调整IDS规则或触发级别，而不是试图修改Mac的行为（我怀疑你可以）？ 在我看来，您的IDS对正常和预期的networking活动过于敏感。