为什么PXE引导VM会积极地寻找反向ARP？

Question

反向ARP是.。据我所知，差不多已经死了？一个伟大的互联网成功的故事在扼杀协议？近30年来，人们一直反对支持BOOTP (以及后来的DHCP)。

因此，我有点惊讶地注意到，在PXE引导期间，VM无情地通过RARP请求一个IP地址--即使是在通过DHCP获得一个非常好的IP地址之后。

在引导开始时，发送的第一个广播包是反向ARP数据包，紧接着是DHCP广播。

20:31:19.408086 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:19.441857 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:20:fd:ce, length 548
20:31:19.443536 IP 192.168.100.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

显然，它不喜欢第一个DHCP响应，因为它正在等待另一个响应(请注意，我只捕获广播数据包，因此tcpdump看不到DHCP会话的其余部分)，但在发送另外几个RARP请求之前不会这样做：

20:31:19.935341 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:20.935426 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:21.500371 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:20:fd:ce, length 548
20:31:21.501288 IP 192.168.100.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
20:31:21.504278 ARP, Request who-has 192.168.100.40 tell 192.168.100.6, length 46
20:31:22.935467 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46

很好，它有一个IP，然后是用于PXE服务器的ARP，这样它就可以启动TFTP。它把另一个RARP潜入了最后，好吧。现在，它一直进入pxelinux环境：

后来怎么样了？另一个RARP请求，正好在上次请求的1秒之后。

20:31:23.935340 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46

再来一次，整整2秒后。

20:31:25.935384 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46

还有更多。3秒后，5秒之后，8秒，13秒，21秒到了那个时候，它终于消退了。

20:31:28.935548 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:33.935518 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:41.935633 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:31:54.935970 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46
20:32:15.936232 ARP, Reverse Request who-is 00:0c:29:20:fd:ce tell 00:0c:29:20:fd:ce, length 46

而在pxelinux环境中，IP地址已经绑定到该NIC。

那么，有没有人知道这个VM (或者更确切地说，每个ESX(i) VM，至少在4.1和5.0上)在想什么？

我已经证实它既发生在模拟的E1000上，也发生在vmxnet3设备上；这是VMware PXE代码的“特殊”行为，还是任何ol‘PXE代码的典型行为？

因为作为一种协议，它不能提供任何PXE服务器信息(据我所知)，它寻找RARP有什么意义吗？

我是否需要咬紧牙关，设置rarpd，看看PXE设备将如何对它作出反应？

Answer 1

我可能错了，但如果vswitch有“Notify”配置，默认情况下是打开的，这似乎是由v内核发送的RARP数据包。