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

8

昨晚我们的Linux（CentOS）服务器之一无法访问。

除远程控制台外，服务器无法以任何方式访问。使用远程控制台登录后，事实证明我也无法ping通任何外部主机。

一个简单的方法service network restart解决了这个问题，但是我仍然想知道是什么原因引起的。我的日志文件似乎一点都没有指示错误（除了需要网络连接且在网络故障后失败的各种守护程序之外）。

我是否可以采取其他任何措施找出导致此问题的原因？

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

根据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=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

这是我可以解决的问题，还是我该联系数据中心了吗？

linux  networking  centos 
— 阿隆·罗特维（Aron Rotteveel）
source
是否有机会在整个时间查看日志，守护程序抱怨什么等等？
— MadHatter
编辑过的帖子可以包含该时间段的部分日志，尽管看不出多少有趣之处。
— Aron Rotteveel，2010年
1
服务iptables重新启动可以解决问题，还是仅服务网络重新启动？
— JakeRobinson 2010年

Answers:

4

校验

dmesg | less为与您的网卡别名（即eht0）什么 less /var/log/messages藏汉

很少有可能是ip地址冲突，如果应该再次发生，请尝试

arping -U <gateway ip> -I <nic alias> 但是，请检查此内容，因为我已经使用arping很久了，这可能是不正确的。

如果成功，则应重新连接而不必重新加载网络服务。

— 奥尼罗伊
source
我已经检查了日志，但是除了提到的各种守护程序错误（表明网络刚刚中断）之外，找不到任何指示问题的信息。
— Aron Rotteveel，2010年
3

您如何在此网络上获取IP地址（DHCP或静态）？如果再次发生，请确保ifconfig在接口处于非功能状态时运行以查看其状态。有地址吗？有错误吗？如果您运行ethtool，是否有链接？（并且是否以正确的速度和双工协商？）

— 马特
source
IP地址是静态的。我已经运行了ifconfig，并且接口具有有效的地址，没有错误。我还没跑eththool。
— Aron Rotteveel 2010年
2
运行ethtool。:)
— mattdm 2010年
好吧，发布了:)
— Aron Rotteveel 2010年
这样可以很好地进行比较-看看有问题时会发生什么变化会很有趣。
— mattdm 2010年
2

根据遇到的问题，我会非常怀疑IP地址冲突。重新启动网络将发送免费的ARP，该ARP将再次接管该IP，这将清除一切。

我会将arpwatch安装在同一广播域（同一网络）中的另一台主机上，看看是否有其他机器正在响应针对您服务器IP的ARP请求。如果是这样，请找出哪台机器（可能使用交换机中的MAC地址表来找出它所连接的端口）并将其设置为另一个静态地址或DHCP。

— 杰夫·麦克琼肯
source
如果再次失败，我也将运行“ arp -an”；根据网关地址显示的内容，它有助于定义下一个故障排除步骤。
— BMDan 2010年
执行了arp -an。好像我的网关返回的ARP不完整，但是我不确定下一步该怎么做。
— 阿隆·罗特维
1

也许TCP连接池已满？某种东西正在打开越来越多的连接，也许尝试netstat（尝试使用不同的选项，例如-i来查看接口）将获得有关打开连接的见解。

如果实际的连接（以及iptables / routes / whatever：you_are_using配置）可以，则问题可能出在例如网络接口配置中。

您的ifconfig -a输出是否理智？该输出将告诉您是否存在一些不应该存在的网络设备（例如虚拟设备），这会导致数据包混乱。

您粘贴的此路由表看起来确实很奇怪。它是否可以正常工作，并且在连接停止工作后是否会更改？如果是，则是导致路由表更改的某种原因，可能是与iptables相关的某种原因。

最后，CentOS特有的东西：您是否正在使用NetworkManager？由于某些原因，它在CentOS中默认情况下处于启用状态，即使在没有X的虚拟机中也是如此，从而使该连接加倍，路由更改和其他操作成为可能。我建议将其关闭，除非您知道自己需要它（例如，具有打开和关闭的连接）。

— 斯玛
source
0

您在哪里测试？在子网内部还是外部？您有几条路线？自动网关选择可能会执行看似不可预测的事情。

— 乔里斯
source
我通过简单地从服务器ping一些网站并从外部ping到服务器来测试连接性。您所说的路线数是什么意思？到多少条路线？
— Aron Rotteveel，2010年
2
显示路由-n的输出？有多少个默认路由？
— 乔里斯（Joris）2010年
谢谢回复。将输出发布到问题中。
— Aron Rotteveel，2010年
0

我不使用RedHat或CentOS，但是尝试查看执行时调用的脚本是什么。service network restart. 由于当脚本中的某些内容发生时网络恢复正常，可能有助于缩小范围。

— 劳伦斯
source
-1

嗯

也许是对iptables的意外更改？它既可以解释为什么无法访问它，又可以解释为什么日志中没有奇怪的内容（可能您不记录iptables。对吗？）

— 尼古拉迪斯·弗蒂斯
source
1
A service network restart不清除iptables。
— Oneiroi
1
根据您的配置，它可能会重建iptables。我从未提到过网络重启会清除它们。如果由于某些原因更改了iptables，则网络重启可以修复它们。
— Nikolaidis Fotis 2010年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.