更新- 由于收购后基础设施发生变化，出现了 IP 地址冲突。一旦发现冲突，这种行为就会停止，因为流量可以始终路由到正确的位置。感谢大家的帮助。
我有一台虚拟化 Centos 6.2 FINAL 服务器。这台机器的目的是运行 Tomcat 上的 Jenkins 以实现自动构建。随着我的公司被收购，网络基础设施发生了变化，因此一些配置也发生了变化。如果需要，我可以更详细地介绍历史，但现在，我将重点介绍我的实际症状。
- 如果尝试通过 ssh 或 http 网络与机器进行交互，通常不会响应。
- 如果直接登录，机器将与机器交互。但是，似乎需要一点时间才能最终开始对话。也就是说，当我从虚拟机运行跟踪路由到本地机器时，需要进行几次迭代。ping 也是如此 - 数据包开始通过之前可能需要最多 6 次迭代。
- 一旦该机器与其他机器进行通信，就可以实现外部联系。我可以通过 ssh 连接到它，Jenkins 应用程序将通过 http 进行响应。
- 然而，通信最终会停止并返回到最初的第一个状态，即无法与外界联系，直到我直接与机器交互以使其与外界进行通信（2）。
我有点不明白从诊断角度应该检查什么。正如我之前所说，这里有一些历史。该机器最初有一个网络适配器，其 IP 地址通过 DHCP 分配。然后添加了一个额外的网络适配器，并且 IP 地址是静态分配的。现在只有一个网络适配器，其 IP 地址是静态分配的。
我查看了互联网上的其他帖子，其中讨论了可以帮助诊断的各种命令，但我不确定如何阅读它们。
我想这些信息不足以做出诊断（如果足够的话我会很感激！）所以我将感谢进一步的阅读材料、采取的步骤或澄清问题。
非常感谢您抽出时间。
答案1
除了简单的 MAC 表填充之外，还有一种可能性是无偿 ARP 碰撞。
我想到的情况需要两件事：
- 一个错误的网络掩码，可能在 Jenkins 盒子上。
- 之一：
- Jenkins 盒子网上配置了多个用于免费 ARP 的设备，其中一个是有状态的（可能是防火墙或负载均衡器）。
- 为 G-ARP 配置的设备不是您期望作为默认网关的设备。
免费 ARP 的工作原理
在初始状态下，当 Jenkins 盒尚未交互且所有各种路由器/交换机/arp 表都为空时，如果错误配置的 Jenkins 盒尝试访问由于网络掩码错误而被视为本地的主机但实际上是远程的，则配置为免费 ARP 的设备会欺骗它并声称这是有问题的 IP 地址，并悄悄地将其路由到需要去的地方。
多台G-ARP设备案例
本例中，有两个设备发送G-ARP报文，故障模式为：
- Jenkins 发送一个子网外地址的 ARP 请求。
- 第一个 G-ARP 设备回复说它有该地址。
- Jenkins 将 SYN 数据包发送到远程设备。
- 远程设备确认连接并被 Jenkins 接收。
- 在发出 SYN-ACK 之前，第二个 G-ARP 设备也发送了 ARP 回复，表示它有该地址。Jenkins 尽职尽责地更新了其本地 ARP 表。
- SYN-ACK 数据包通过第二个 G-ARP 设备。不幸的是，由于它从未见过初始 SYN 数据包，因此它不知道该连接，因此将其丢弃在地板上。
- 连接始终未打开。
通过观察 中的套接字状态，可以在两个主机上看到这一点netstat。如果您在 Jenkins 框中抓取数据包，则可以非常明显地看到这一点。
与其建立的连接之所以有效，是因为它们是通过第二个 G-ARP 设备进行的，这样就可以使用“正确”的设备更新 Jenkins 框 ARP 表以传递数据包。只要该连接已启动并正在传递流量，出站流量就会以正确的方式传输。
错误设备响应 G-ARP
这是上述情况的变体。只有一个设备配置了 G-ARP，但配置不正确。G-ARP 几乎肯定是一个错误的配置。
- Jenkins 发送一个子网外地址的 ARP 请求。
- G-ARP 设备回复说它有该地址。
- Jenkins 将 SYN 数据包发送到该设备。
- 该设备实际上并不是路由器，或者没有配置为传递这样的数据包，因此将其掉落在地上。
与上述一样，当您建立连接时，只要连接处于连通状态，它就会设置 ARP 表以正确的方式传递信息。
最简单的修复方法是验证该盒子上的网络掩码对于其所在的子网是否正确，因为这样可以绕过整个 G-ARP 问题。
另一种可能性是，您配置的默认网关存在问题。如果其他所有情况都是这样，那么使用该网关的任何设备都应该出现相同的行为；如果是这种情况，请验证同一主机上的其他虚拟机是否不会发生同样的问题。
答案2
检查您的交换机的配置。
这是一种预感，但在我看来，你的交换机承受了太多的流量，填满了它们的 MAC 表并让它们忘记了你服务器的 MAC 地址/端口。
与 STP 结合，最多可能需要 30 秒才能让您的流量再次通过交换机。