linux接收大量网络数据崩溃,Linux网络崩溃：找出原因的最佳步骤？

我们的一台

Linux(CentOS)服务器昨晚无法访问.

除远程控制台外,服务器无法以任何方式访问.使用远程控制台登录后,结果发现我无法ping任何外部主机.

一个简单的服务网络重启解决了这个问题,但我仍然想知道是什么导致了这个问题.我的日志文件似乎表明根本没有错误(除了需要网络连接并在网络出现故障后失败的各种守护进程).

我可以采取任何其他步骤来找出导致此问题的原因吗？

编辑：这只是再次发生.在我重新启动网络服务之前,服务器完全没有响应.任何建议都是受欢迎的.这可能是由有故障的硬件组件引起的吗？

根据Madhatters的要求,这里有一些当时的日志摘录(网络在20:13崩溃)：

在/ var / log / messages中：

Dec 2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC= SRC= DST= 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= SRC= DST= 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= SRC= DST= 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的输出：

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 on eth0

服务网络重启后：

? (xx.xx.xx.62) at 00:00:0C:9F:F0:30 [ether] on eth0

这是我能解决的问题,还是我与数据中心联系的时候了？