我们的一台 Linux（CentOS）服务器昨晚无法访问。
除了远程控制台之外，无法通过任何方式访问服务器。使用远程控制台登录后，我发现也无法 ping 任何外部主机。
一个简单的service network restart方法解决了这个问题，但我仍然想知道是什么原因造成的。我的日志文件似乎根本没有显示任何错误（除了需要网络连接并在网络故障后失败的各种守护进程）。
我可以采取其他步骤来找出该问题的原因吗？
编辑：这又发生了。在我重新启动网络服务之前，服务器完全没有响应。欢迎任何建议。这可能是由硬件组件故障引起的吗？
根据 Madhatters 的要求，以下是当时日志的一些摘录（网络于 20:13 崩溃）：
/var/log/消息：
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 无法再连接到网关。除此之外，这段时间没有什么有趣的消息。
编辑12月4日：根据 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：
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日编辑：问题再次出现，我有机会比较了上述测试的一些输出。我发现它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
我可以解决这个问题吗？还是我该联系数据中心？
答案1
查看
dmesg | less对于任何与你的网卡别名（即 eht0）相关的
less /var/log/messages内容
虽然这种情况很少见，但可能是 IP 地址冲突，如果再次发生这种情况，请尝试
arping -U <gateway ip> -I <nic alias>然而，请检查这一点，因为我已经很久没有使用过 arping 了，这可能是不正确的。
如果成功，您应该可以重新获得连接而无需重新加载网络服务。
答案2
您如何在此网络上获取 IP 地址（DHCP 或静态）？如果再次发生这种情况，请确保运行ifconfig以查看接口在非工作状态下的状态。它有地址吗？有错误吗？如果您运行ethtool，是否有链接？（并且它是否协商到正确的速度和双工？）
答案3
根据遇到的问题，我非常怀疑存在 IP 地址冲突。重新启动网络将发送免费 ARP，该 ARP 将再次接管该 IP，这样就可以解决问题。
我会安装阿普观察在同一广播域（同一网络）的另一台主机上，查看是否有其他机器响应针对您服务器 IP 的 ARP 请求。如果是，请找出哪台机器（可能使用交换机中的 MAC 地址表来找出它连接到哪个端口）并将其设置为另一个静态地址或 DHCP。
答案4
这个问题很久以前就已解决：该问题显然与硬件有关。
新的 NIC 已解决该问题。