除远程控制台外,服务器无法以任何方式访问.使用远程控制台登录后,结果发现我无法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已经很长时间了,这可能是不正确的.
如果成功,您应重新获得连接而不重新加载网络服务.
