我们的一台Linux（CentOS）服务器昨晚无法访问。
除了远程控制台之外，服务器无法以任何方式访问。 用远程控制台login后，结果我无法ping任何外部主机。
一个简单的service network restart解决了这个问题，但我仍然想知道是什么原因造成的。 我的日志文件似乎没有任何错误（除了各种需要networking连接的守护程序以及networking故障后失败）。
是否有任何额外的步骤可以找出这个问题的原因？
编辑 ：这只是再次发生。 服务器完全没有响应，直到我发出networking服务重新启动。 任何build议是值得欢迎的。 这可能是由有故障的硬件组件引起的吗？
根据Madhatters的要求，这里是当时日志的一些摘录（networking在20:13坠毁）：
在/ var / log / messages中：
Dec 2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0 Dec 2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=100 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0 Dec 2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0 Dec 2 20:13:34 graviton junglediskserver: Connection to gateway failed: xGatewayTransport - Connection to gateway failed.
前三条消息是对我通过LFD防火墙设置的iptables规则的简单回应。 最后一条消息表明，用于备份的JungleDisk不能再连接到网关。 除此之外，这个时候还没有有趣的消息。
编辑4月12日：根据Mattdm的要求，这里是ethtool eth0的输出：
（请注意，这些是目前正在使用的设置，如果再次出现问题，我们将会在必要时再次发布。
Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: d Link detected: yes
按照Joris的要求，这里也是route -n的输出route -n ：
aron@graviton [~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface xx.xx.xx.58 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.42 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.43 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.41 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.46 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.47 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.44 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.45 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.50 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.51 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.48 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.49 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.54 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.52 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.53 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 xx.xx.xx.0 0.0.0.0 255.255.255.192 U 0 0 0 eth0 xx.xx.xx.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 xx.xx.xx.62 0.0.0.0 UG 0 0 0 eth0
底部xx.62是我的门户。
编辑12月28日：问题再次发生，我有机会比较一些上述testing的输出。 我发现， arp -an为我的网关返回一个不完整的MAC地址（这不在我的控制之下;服务器在共享机架中）：
在失败期间：
? (xx.xx.xx.62) at <incomplete> on eth0
service network restart ：
? (xx.xx.xx.62) at 00:00:0C:9F:F0:30 [ether] on eth0
这是我能解决的问题吗？还是我该联系数据中心的时候了？
查
dmesg | less dmesg | less与任何与你的nic别名（即eht0） less /var/log/messages
虽然罕见的可能是一个IP地址冲突，如果这应该再次发生尝试
arping -U <gateway ip> -I <nic alias>请检查一下，因为我已经使用了arping很长一段时间，这可能是不正确的。
如果成功，您应该重新连接而不重新加载networking服务。
你如何获得在这个networking上的IP地址（DHCP，或静态）？ 如果再次发生，请确保运行ifconfig以查看处于非function状态的接口状态。 有地址吗？ 有错误吗？ 如果你运行ethtool ，有没有链接？ （这是协商到正确的速度和双工？）
基于遇到的问题，我会非常怀疑IP地址冲突。 重新启动networking将发送一个无偿的ARP，将再次接pipe该IP，这将清除事情。
我会安装arpwatch在另一个主机在同一广播域（相同的networking），看看是否有其他机器响应您的服务器的IP的ARP请求。 如果是这样，找出哪台机器（可能使用交换机的MAC地址表来找出它连接的端口），并将其设置为另一个静态地址或DHCP。
也许TCP连接池变满了？ 有些东西正在打开越来越多的连接，也许尝试netstat （尝试不同的选项，例如-i来查看接口）将会提供有关连接打开的信息。
如果实际的连接（和iptables / routes / whatever：you_are_usingconfiguration）都可以，例如在networking接口configuration中可能会出现问题。
你的ifconfig -a输出是否理智？ 该输出会告诉您是否有某些不应该存在的networking设备，例如虚拟设备，这会导致数据包无法使用。
这个你粘贴的路由表看起来很奇怪。 当它是这样的，它是否工作，并在连接停止工作后改变？ 如果是的话，有些东西是导致路由表改变，也许是iptables相关的东西。
最后，CentOS具体的东西：你有没有使用NetworkManager？ 由于某些原因，在CentOS中默认启用，即使在没有X的虚拟机中，也可以使这个连接加倍，路由更改和其他可能的事情。 我build议把它closures，除非你知道你需要它（例如，有连接，打开和closures）。
你从哪里testing？ 在子网内还是在外？ 你有几条路线？ 自动网关select可能做看似不可预知的事情。
我不使用RedHat或CentOS，但尝试查看在执行service network restart.时调用的任何脚本service network restart. 由于当脚本发生时，你的networking恢复正常，这可能有助于缩小范围。
这个问题已经在不久前解决了：问题显然与硬件有关。
一个新的NIC已经解决了这个问题。
Hhhmm。
也许偶然更改iptables？ 它可以解释为什么无法访问，为什么没有什么奇怪的日志（可能你不loggingiptables，是吗？）