由于造成网络问题的因素多种多样,因此网络故障排查技能就成了每位服务器或网络服务负责人必不可少的重要素质。Linux为我们提供了大量网络故障排查工具,在本文中,我们将讨论一些常见的网络问题,并介绍如何利用某些Linux工具追踪意外状况发生的根本原因。
问题:服务器A无法与服务器B通信
可能大家在实际工作中最常见的网络故障就是一台服务器无法与另一台网络上的服务器进行通信。本小节将通过实例讲解具体处理办法。在实例中,一台名为dev1的服务器无法访问另一台名为web1的服务器中的网络服务(端口80)。导致这一现象的原因相当繁杂,因此我们需要一步步测试操作活动,进而通过排除法找到故障的根源。
一般说来,在对这样的问题进行故障排查时,大家可能会跳过某些初始步骤(例如检查链接等),因为接下来的某些测试环节能起到同样的诊断作用。举例来说,如果我们测试并确认DNS能够正常工作,那么就证明我们的主机是能够与本地网络进行通信的。但在本次实例解析中,我们将本着谨慎的态度执行每一个步骤,借以理解各个级别的不同测试方式。
问题出在客户机还是服务器端?
大家可以利用一项快速测试缩小造成故障的范围,即通过同一网络中的另一台主机尝试访问对应服务器。在本实例中,我们姑且将另一台与dev1同处一套网络环境下的服务器命名为dev2,并尝试通过它访问web1。如果dev2也不能正常访问web1,那么显然问题很可能出在web1或者是dev1、dev2及web1之间的网络身上。如果dev2能够正常访问web1,那么我们就可以断定dev1出问题的机率较大。首先,我们假设dev2能够访问web1,因此我们开始将故障排查的重点放在dev1这边。
线缆插好了吗?
故障排查的第一步要在客户机上进行。大家首先要确认自己客户机的网络连接没有问题。要做到这一点,我们可以使用ethtool程序(通过ethtool工具包安装)对链接(即以太网设备与网络构成物理连接)情况加以检测。如果大家无法确定自己使用的是哪个端口,那么请运行/sbin/ifconfig命令将所有可用的网络端口及其设定列出。我们假设自己的以太网设备在eth0端口上,那么:
$ sudo ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pg
Wake-on: d
Current message level: 0x000000ff (255)
Link detected: yes在最后一行中,大家可以看到检测结果显示链接设置为“yes”,所以dev1已经与网络构成物理连接。如果这项检测的结果为“no”,那么我们需要亲自检查dev1的网络连接,并将线缆插实到位。在确定物理连接没有问题之后,执行下面的步骤。
注意:ethtool绝不仅仅是一款用于检测链接状况的工具,它还能够诊断并纠正双工问题。当Linux服务器与网络连通时,通常会与网络自动协商以获取传输速度信息以及该网络是否支持全双工。在本实例中,传输速度经ethtool检测为100Mb/秒,且该网络支持全双工机制。如果大家发现主机的网络传输速度缓慢,那么速度及双工设定是首先需要关注的重点。如前文所示运行ethtool,若大家发现双工被设定为一半,则运行以下命令:
$ sudo ethtool -s eth0 autoneg off duplex full 意思是利用自己的以太网设备代替eth0。
端口正常吗?
一旦确认了服务器与网络之间物理连接的完好性,接下来就是判断主机上的网络端口是否配置正确。在这方面,最好的检查方式就是运行ifconfig命令并将端口作为参数后缀。因此要测试eth0的设置,大家应该运行以下内容:
$ sudo ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:17:42:1f:18:be
inet addr:10.1.1.7 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::217:42ff:fe1f:18be/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:229 (229.0 B) TX bytes:2178 (2.1 KB)
Interrupt:10
在上述输出结果中,第二行可能最值得我们关注,因为其内容是解释我们的主机已经被配置了一套IP地址(10.1.1.7)与子网掩码(255.255.255.0)。现在,大家需要确认这样的设置结果是否正确。如果端口未受配置,请尝试运行sudo ifup eth0,然后再次运行ifconfig重新检查端口是否出现。如果设置错误或端口未出现,则检查/etc/network/interfaces路径(Debian系统)或/etc/-sysconfig/-network_scripts/ifcfg-<interface>路径(红帽系统)。在这些文件中,大家可以修正网络设置中存在的所有错误。现在如果主机通过DHCP获得自身IP,我们则需要将故障排查转移到DHCP主机处,找出为什么我们没有正确获得IP租用周期。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
Linux服务器故障排查指南5:远程端口打开了吗?
现在我们已经能够路由至目标设备,但仍然无法在端口80上访问web服务器。接下来的测试意在检查端口是否打开。
-
Linux服务器故障排查指南4:我能路由至远程主机吗?
在排除了DNS问题并看到web1被正确解析为IP 10.1.2.5之后,大家需要测试自己能否路由至远程主机。假如我们的网络启用了ICMP,那么最快捷的测试办法是ping web1。
-
Linux服务器故障排查指南8:出是谁占用了带宽
有时候我们的网络缓慢并不是由远程服务器或路由器所引起,而只是因为系统中的某些进程占用了太多可用带宽。本文利用iftop找出是谁占用了带宽。
-
Linux服务器故障排查指南7:网络缓慢状况
本文帮助大家追踪导致网络速度缓慢的各种原因:排查网络缓慢状况的故障以及DNS问题。并利用traceroute解决网络缓慢问题。