Linux网络崩溃：找出原因的最佳步骤？

概述我们的一台 Linux(CentOS)服务器昨晚无法访问. 除远程控制台外,服务器无法以任何方式访问.使用远程控制台登录后,结果发现我无法ping任何外部主机. 一个简单的服务网络重启解决了这个问题,但我仍然想知道是什么导致了这个问题.我的日志文件似乎表明根本没有错误(除了需要网络连接并在网络出现故障后失败的各种守护进程). 我可以采取任何其他步骤来找出导致此问题的原因吗？ 编辑：这只是再次发生. 我们的一台 Linux(CentOS)服务器昨晚无法访问.

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

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

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

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

根据Madhatters的要求,这里有一些当时的日志摘录(网络在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=0Dec  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=0Dec  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=0Dec  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 -nKernel IP routing tableDestination     Gateway         Genmask         Flags Metric Ref    Use Ifacexx.xx.xx.58    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.42    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.43    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.41    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.46    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.47    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.44    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.45    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.50    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.51    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.48    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.49    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.54    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.52    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.53    0.0.0.0         255.255.255.255 UH    0      0        0 eth0xx.xx.xx.0     0.0.0.0         255.255.255.192 U     0      0        0 eth0xx.xx.xx.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth00.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

服务网络重启后：

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

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

解决方法 校验

dmesg |与您的nic别名相关的任何内容(即eht0)
少/ var / log / messages以及

虽然罕见但它可能是一个IP地址冲突,如果这应该再次发生尝试

arPing -U< gateway ip> -I< nic alias>检查这一点,因为我使用arPing已经很长时间了,这可能是不正确的.

如果成功,您应重新获得连接而不重新加载网络服务.

总结

以上是内存溢出为你收集整理的Linux网络崩溃：找出原因的最佳步骤？全部内容，希望文章能够帮你解决Linux网络崩溃：找出原因的最佳步骤？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。