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=<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的输出: 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 服务网络重启后: ? (xx.xx.xx.62) at 00:00:0C:9F:F0:30 [ether] on eth0 这是我能解决的问题,还是我与数据中心联系的时候了? 解决方法
校验
dmesg |与您的nic别名相关的任何内容(即eht0) 虽然罕见但它可能是一个IP地址冲突,如果这应该再次发生尝试 arping -U< gateway ip> -I< nic alias>检查这一点,因为我使用arping已经很长时间了,这可能是不正确的. 如果成功,您应重新获得连接而不重新加载网络服务. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |