针对那些比我更了解网络的人提出的问题...
长话短说，今晚我遇到了一个远程服务器问题，即使我完全阅读了 RTFM，也无法通过 ILO（HP 的带外管理技术）解决问题。我注意到这台服务器上的 ILO 固件版本已经超过 5 年了，我想这可能是我遇到的问题的原因，所以我去升级它，但无法升级。（ILO Web 管理控制台提供了一种执行固件更新的机制。）我犯了一个错误，我会后悔很久，我决定打电话给技术支持，询问如何更新固件。在听取他们的建议并对接口进行软重置（也是通过 ILO Web 管理控制台）后，它变得没有响应了。
预期的行为，我启动了ping -tILO 接口的 ip 地址，以便知道它何时恢复。但 ping 全部恢复了，因为Reply from 0.0.0.0: ... 我决定无论如何都给它几分钟时间，以防重置出现异常。半小时后，它仍在回复0.0.0.0，所以我让某人拔掉了服务器的电源。这将 ping 回复更改为Request timed out. 重新插入后，ping 响应0.0.0.0再次启动。即使是现在，6 小时后，对该 ILO 接口的“实际”IP 地址的 ping 仍会回复0.0.0.0。
值得一提的是，我们没有为 ILO 设置单独的 VLAN 或子网（我正在研究），并且 ping 子网中没有任何内容的地址会返回 A，Request timed out. 该tracert地址通过我们的交换机，通过我们总部的链接，到达远程站点的 T1 的另一侧...然后显示0.0.0.0。来自远程 VPN（单独的 VLAN 和子网）的 ping 请求返回Request timed out.
从我对网络的了解来看，显然比我昨天认为的要少，无法从 获得回复0.0.0.0。这是“任何”地址。因此，即使 ILO 接口的地址已重置为0.0.0.0，它也不应能够以 发送回复0.0.0.0，所以……好吧，有人知道为什么会发生这种情况吗？或者这甚至如何发生可以到底发生了什么？
更新：让某人到现场检查了 ILO 上的设置，果然，接口的 IP 地址被重置为0.0.0.0。
答案1
这很可能是固件错误，但我听说的唯一一种从 0.0.0.0 获取数据包的情况是 RARP（反向 ARP），它从全零 MAC 发出请求以查找其 IP 地址。这曾经是无盘启动的一个组件，但已经很久没见过了。
可能是 ping 站仍在缓存中保存了 ILO 的 MAC 地址 - 当然还有中间交换机。如果 ILO 丢失了其地址，它可能正在经历 RARP / BOOTP 过程。或者它只是失去了理智。