服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 为什么我只能连接到我的服务器时，从它产生的stream量？
Intereting Posts
我可以ping通IP，但不能ping任何域 MariaDB / MySQL galera群集节点不会join VMware高可用性问题 SSH端口转发 关于mysqlimport显示警告 为什么我的debian服务器冻结？ Server 2012networking共享无法通过cisco vpn在Windows 10上访问 NFSv3是否尊重ZFS ACL？ CentOS 6.5 iptables conntrack模块 Amazon Linux上的rsyslog更新突然将INFO级别的消息视为EMERG 创buildIIS用户后，PS退出时“powershell已停止工作” 是升级你的内核类似于在Windows中修补？ Supermicro超级服务器RAID警告 使用名称服务器将DNS转移到Office 365 Office 365 Powershell – 将用户，许可证types和公司字段导出到csv文件

为什么我只能连接到我的服务器时，从它产生的stream量？

更新 – 由于从收购的基础设施变化，有一个IP地址冲突。 一旦确定了这一点，行为就会停止，因为交通可以始终路由到正确的位置。 感谢大家的帮助。

我有一个虚拟化的Centos 6.2 FINAL服务器。 机器的目的是在Tomcat上运行Jenkins来自动构build。 随着我的公司被收购，networking基础设施发生了变化，所以一些configuration也改变了。 如果需要，我可以更多地进入历史，但现在，我将关注我的实际症状。

  1. 如果试图通过networking通过ssh或http进行交互，机器通常不会作出响应。
  2. 机器如果直接login，将与机器交互。 但是，似乎要花一点时间才能最终开始交谈。 也就是说，当我从vm运行traceroute到本地机器时，需要进行一些迭代。 与ping一样 – 在数据包开始通过之前，最多可能需要6次迭代。
  3. 一旦机器与其他机器交谈，外部接触是可以实现的。 我可以SSH，并且Jenkins应用程序将通过http进行响应。
  4. 然后，通信将最终停止，直到我直接与机器交互以使其与外部世界进行通信（2）之后，回到最初的第一个状态，在此状态下，外部接触是不可能的。

从诊断的angular度来看，我有点不知所措。 正如我刚才所说，这里有一些历史。 该机器最初有一个networking适配器，通过DHCP分配一个IP地址。 然后再添加一个networking适配器，并且IP地址被静态分配。 现在只有一个networking适配器的IP地址分配静态。

我已经看了网上的其他线程，谈论各种可以帮助诊断的命令，但我不知道如何阅读它们。

我想这是没有足够的信息来作出诊断（虽然会很感激，如果是的话），所以我会欣赏进一步阅读材料，采取步骤或澄清问题。

非常感谢你的时间。

简单的MAC表填充之外的一种可能性是无用的ARP冲突。

我想到的情况需要两件事情：

  1. 一个坏的networking掩码，可能在jenkins盒子上。
  2. 之一：
    1. 在Jenkins盒子网上configuration了一台以上的免费ARP设备，其中一台是有状态的（可能是防火墙或负载均衡器）。
    2. 为G-ARPconfiguration的设备不是您希望成为默认网关的设备。

如何无偿ARP应该工作

在初始状态下，当jenkins盒子没有被互动，并且所有的各种路由器/开关/ ARP表是空的，如果你错误configuration的jenkins盒子试图访问一个主机，它认为本地由于不好的networking掩码，但实际上远程configuration为免费ARP的设备将撒谎，并说这是问题的IP地址，并悄悄地路由到它需要去的地方。

多个G-ARP设备案例

在这种情况下，有两台设备发送G-ARP报文。 这里的失败模式是：

  1. Jenkins发送一个关于子网地址的ARP请求。
  2. 第一个G-ARP设备回复它有这个地址。
  3. Jenkins将SYN数据包发送到远程设备。
  4. 远程设备确认连接，并由Jenkins接收。
  5. 在发送SYN-ACK之前，第二个G-ARP设备也会发送一个具有该地址的ARP应答。 Jenkins忠实地更新其本地ARP表。
  6. SYN-ACK报文通过第二个G-ARP设备。 不幸的是，因为它从来没有看到最初的SYN数据包，所以它不知道连接，所以将它放在地板上。
  7. 连接永远不会打开。

这是通过在netstat查看套接字状态在两个主机上可见的。 如果你在Jenkins盒子上抓取数据包的话，这一点非常明显。

连接到它的工作，因为他们通过第二个G-ARP设备，通过这样做更新jenkins框ARP表'与'权'设备传递数据包通过。 只要这个连接已经build立并且通过了通信，出站通信就会正确。

错误的设备响应G-ARP

这是上面的一个变种。 G-ARP只能configuration一台设备，但不是正确的。 G-ARP几乎肯定是一个糟糕的configuration。

  1. Jenkins发送一个关于子网地址的ARP请求。
  2. G-ARP设备回复它有这个地址。
  3. Jenkins将SYN数据包发送到该设备。
  4. 该设备实际上不是一个路由器，或者没有configuration为通过这样的数据包，所以把它放在地板上。

和上面一样，当你build立一个连接时，只要连接正常，它就会build立一个ARP表来正确地传递信息。

最简单的解决方法是validation您的子网掩码是否正确，因为它绕过了整个G-ARP问题。

另外一种可能是，你用你configuration的默认网关有一些狡猾的东西。 如果它是其他的东西，那么对于使用该网关的任何东西，你都应该看到相同的行为。 如果是这种情况，请validation同一主机上的其他虚拟机不会发生同样的问题。

检查你的交换机的configuration。

这是一个预感，但是在我看来，你的交换机被大量stream量占满，填满了他们的MAC表，并且让他们忘记了你的服务器的MAC地址/端口。

结合STP，可能需要长达30秒才能使您的stream量再次通过交换机。