当故障来袭时,如何证明你的网络没问题



有人说网络工程师是整个IT行业中最可能受气的工种。其实这一点捷个本人也不否认,因为你管理的网络,是所有服务器、终端相互通信的基础。如果有电脑上网不正常,或者是访问网络中的某一台服务器出现异常现象,所以别人肯定首先就会找你网络的问题。哎!没办法,谁让你管理的是TCP/IP底层的东西呢? 

不过,当故障来袭的时候,作为网络工程师的你,也要能够清楚的判断这个问题到底是不是出现在网络设备上,并能拿出强有力的证据,有理有节地来反驳那些“气势汹汹”的人们。这到底应该怎么做呢?捷哥来为大家讲一个案例:


赵小志是一名在某垄断企业驻场工作的网络工程师,日常的工作是维护数据中心的防火墙和核心、汇聚交换机。因为DMZ区域的Cisco 6509E交换机投运时间太久,设备老化了,甲方要求将Cisco 6509E更换为H3C 9512。周四的晚上更换设备的时候一切顺利,并且在更换完成汇聚层设备以后测试DMZ区域的所有业务都一切正常,所以赵小志就收工回家了。

时间到了下周一,赵小志上班的时候,就收到了来自甲方负责人的故障工单,内容是:DMZ区域对外的两台FTP服务器(内网IP地址是172.18.130.15、172.18.130.16)上传大量小文件的时候出现了丢文件的现象,请相关网络工程师负责检查网络的问题。

为什么是网络的问题呢?FTP服务器的管理员给出的理由如下:“那两台FTP服务器是每个周一接收一次来自营销部门的文件提交,之前一直都是正常的。在周四的时候DMZ区域更换过不同型号的汇聚交换机,在换了汇聚层设备以后,传文件就开始丢数据了。”所以那边管理员就猜测是:“更换过的H3C 9512交换机与之前的Cisco 6509E有兼容问题导致了传文件丢失。”还把这个事情直接捅到了领导那里去了。

领导给出的指令是:“今晚再进行一次上传测试,如果还是丢文件,那就把之间做的割接全部回退!”

“回退?!”把两台H3C 9512再换回Cisco 6509E?先不说这两台设备有多重,再派人去换设备有多么费时费力。就怕你再历经“千辛万苦”把设备换回来,那边FTP的访问还是不正常又怎么办?另外,说H3C 9512与Cisco 6509E存在“不兼容”的那位,到底是哪里不兼容呢?他也说不上个啷哩咯啷,只是说:“凭感觉的!为什么换之前没事换之后有事呢?还肯定是你换这个设备有问题啊?”

得了!既然对方管理员这么说话,赵小志觉得,是该拿出点证据出来了!一来,不能再到机房里面去再抬一次这些沉重的设备;二来,对方FTP管理员丝毫没有查看自己服务器的想法,一口咬定是网络的问题,必须给他点颜色看看。那么,如何证明网络没问题呢?

首先,赵小志找来了DMZ区域的拓扑图:

 1.png

如图所示:IP地址为172.18.130.15的FTP Server连接在H3C 9512交换机的Gi 3/0/37号接口上;IP地址为172.18.130.16的FTP Server连接在H3C 9512交换机的Gi 3/0/43号接口上。另外,从其他区域想要访问到这两台FTP server的话,还必须穿过DMZ区域的防火墙。

首先,赵小志请对方管理员在一台营销区域的前置机上使用Telnet命令去测试172.18.130.15和172.18.130.16的TCP-20、TCP-21、TCP-22端口。用Telnet命令去测试端口,如果能够检查出前置机访问这两台FTP Server的上述端口是正常现象,那么就可以排除防火墙上ACL策略的问题。

Telnet测试得出的结果如下,从前置机上Telnet测试TCP-20、TCP-21、TCP-22端口一切正常:

YX-Sys-FrontDev> telnet 172.18.130.15 22 
Trying 172.18.130.15...
Connected to 172.18.130.15.
Escape character is '^]'.
SSH-1.99-OpenSSH_4.4

YX-Sys-FrontDev> telnet 172.18.130.15 21
Trying 172.18.130.15...
Connected to 172.18.130.15.
Escape character is '^]'.

YX-Sys-FrontDev> telnet 172.18.130.15 20
Trying 172.18.130.15...
Connected to 172.18.130.15.
Escape character is '^]'.

另外,赵小志也提供了防火墙上关于这两台FTP Server的ACL策略配置,进一步说明了不可能是防火墙导致的丢包现象。


set security policies from-zone untrust to-zone trust policy u-t-65 match source-address 172.18.125.0/24
set security policies from-zone untrust to-zone trust policy u-t-65 match destination-address 172.18.130.15/32
set security policies from-zone untrust to-zone trust policy u-t-65 match destination-address 172.18.130.16/32
set security policies from-zone untrust to-zone trust policy u-t-65 match application tcp-20
set security policies from-zone untrust to-zone trust policy u-t-65 match application tcp-21
set security policies from-zone untrust to-zone trust policy u-t-65 match application tcp-22
set security policies from-zone untrust to-zone trust policy u-t-65 then permit

赵小志认为:“如果能够使用Telnet命令去测试目标端口一切正常的话,那就肯定不是防火墙上面ACL策略写错的问题了。如果真的是防火墙上面ACL写错的问题,那应该一开始就不通,不可能是通一阵子就丢包啊。”所以,防火墙的问题排除。


然后再检查交换机上的问题。首先,赵小志先登录到了营销区域的汇聚层交换机上,对172.18.130.15和172.18.130.16进行了一次长ping测试。所谓长Ping,就是一次性让它ping 100次以上,这个可以初步判断网络状态是否稳定。

<DC-YX-7503-1>ping -c 100 172.18.130.15
  PING 127.0.0.1: 56  data bytes, press CTRL_C to break
……
    Reply from 172.18.130.15: bytes=56 Sequence=17 ttl=252 time=2 ms
    Reply from 172.18.130.15: bytes=56 Sequence=18 ttl=252 time=2 ms
    Reply from 172.18.130.15: bytes=56 Sequence=19 ttl=252 time=1 ms
    Reply from 172.18.130.15: bytes=56 Sequence=20 ttl=252 time=1 ms
    Reply from 172.18.130.15: bytes=56 Sequence=21 ttl=252 time=2 ms
    Reply from 172.18.130.15: bytes=56 Sequence=22 ttl=252 time=1 ms
……
  --- 172.18.130.15 ping statistics ---
    100 packet(s) transmitted
    100 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 1/4/7 ms
	
<DC-YX-7503-1>ping -c 100 172.18.130.16
  PING 172.18.130.16: 56  data bytes, press CTRL_C to break
……
    Reply from 172.18.130.16: bytes=56 Sequence=17 ttl=252 time=2 ms
    Reply from 172.18.130.16: bytes=56 Sequence=18 ttl=252 time=2 ms
    Reply from 172.18.130.16: bytes=56 Sequence=19 ttl=252 time=1 ms
    Reply from 172.18.130.16: bytes=56 Sequence=20 ttl=252 time=1 ms
    Reply from 172.18.130.16: bytes=56 Sequence=21 ttl=252 time=2 ms
    Reply from 172.18.130.16: bytes=56 Sequence=22 ttl=252 time=1 ms
……
  --- 172.18.130.16 ping statistics ---
    100 packet(s) transmitted
    100 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 1/3/9 ms

发送了100个ping包的结论是:从营销区域的交换机上ping位于DMZ区域的两台FTP Server,所有的包都没有丢,而且平均延迟为4毫秒、3毫秒;最大延迟也不过9毫秒。既然ping都没问题,那么上传不了文件是怎么个说法呢?

最后,赵小志查看了DMZ区域交换机上Gi 3/0/37和Gi 3/0/43的CRC校验值,也没发现有任何CRC校验失败的情况。这个时候已经完全能够说明网络环境完全没有丢包的现象发生了。

<DC-DMZ-9512-1>dis int gi 3/0/37
 GigabitEthernet3/0/37 current state: UP
 IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: c4ca-d92e-2f71
……
 Last 300 seconds input:  5 packets/sec 907 bytes/sec 0%
 Last 300 seconds output:  108 packets/sec 10184 bytes/sec 0%
 Input (total):  44806386 packets, 6003517217 bytes
         6349308 unicasts, 11862178 broadcasts, 26594900 multicasts, 0 pauses
 Input (normal):  44806386 packets, - bytes
         6349308 unicasts, 11862178 broadcasts, 26594900 multicasts, 0 pauses
 Input:  0 input errors, 0 runts, 0 giants, 0 throttles
         0 CRC, 0 frame, - overruns, 0 aborts
         - ignored, - parity errors

<DC-DMZ-9512-1>dis int gi 3/0/43
 GigabitEthernet3/0/43 current state: UP
 IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: c4ca-d92e-2f71
……
 Last 300 seconds input:  5 packets/sec 907 bytes/sec 0%
 Last 300 seconds output:  108 packets/sec 10184 bytes/sec 0%
 Input (total):  44806386 packets, 6003517217 bytes
         6349308 unicasts, 11862178 broadcasts, 26594900 multicasts, 0 pauses
 Input (normal):  44806386 packets, - bytes
         6349308 unicasts, 11862178 broadcasts, 26594900 multicasts, 0 pauses
 Input:  0 input errors, 0 runts, 0 giants, 0 throttles
         0 CRC, 0 frame, - overruns, 0 aborts
         - ignored, - parity errors

此处,CRC校验值为0,说明在这两个接口上没有一个数据帧损坏,换句话说就是没有在这两个接口上丢过一个数据包,网线的传输质量也是良好的。


于是,拿着这些证据,赵小志就真的可以理直气壮的去找FTP服务器的管理员了,请他从服务器自身的故障查起。

最后呢,按照赵小志提供的思路,在172.18.130.15和172.18.130.16两台FTP服务器上相互传送10000个小文件,因为这两台服务器本身就在一个网段内,如果它们之间互传都有问题,那肯定就是服务器自身的问题了。果然,从172.18.130.16往172.18.130.15上传文件的时候出现了丢失文件的现象……经过检查,发现在FTP服务器上,这个FTP服务端软件不是官方提供的VSFTP,而是某个公司自行编写的。因为软件BUG导致的文件上传丢失。

那么我们换一种情况来看,当时领导和对方的管理员气势汹汹的,如果赵小志的经验没那么丰富,那是不是就该蒙受“不白之冤”啦?所以,作为网络工程师的你,在故障出现的时候,既不能够大包大揽,把责任全部揽到自己身上,当然也不能够不管不问。这么给你说吧,你可以通过以下几个方式来证明自己管理的网络设备没有问题。


1、分区域的使用Telnet命令、ping命令去检测

你为某个系统管理员在防火墙上做了允许访问的ACL,但是他说访问不通

假设你为他做的ACL编号为a,源IP地址为IP-s,目标地址为IP-d,目标端口为Port-p。那么你首先要检查你的防火墙上,编号a之前的ACL有没有关于IP-s、IP-d、Port-p且执行动作为deny的策略,如果没有执行动作为deny的策略,且你写的ACL也没犯“低级错误”,那就肯定不是这个防火墙的问题。

如何给他证明呢?看图吧:

 2.png

这里需要说明一下。步骤一里面,如果你在防火墙上使用Telnet命令测试通了,说明是同一个安全区域内访问(不受防火墙ACL控制)是正常的,则肯定是防火墙的问题。如果在防火墙上使用Telnet命令测试不通的话,那进入到第二步操作,因为你还需要排除Trust区域内交换机的问题啊。

步骤二里面,如果Trust区域内的交换机不支持Telnet测试命令的话,则可以在Trust区域中尽量找一个同网段的服务器去测试。


2、先让对方证明他没问题再检查网络

如果有系统工程师告诉你说:10.11.12.13服务器的8080端口访问不了,请你检查网络。那么这个时候你先别急着答应他,你先让他证明了他的系统没问题以后你再检查。你可以按照这个步骤让他检查:

(1)如果对方可以远程登录到他管理的10.11.12.13的服务器系统,你可以先让他在服务器上尝试telnet 127.0.0.1 8080,先从本机上排除问题。如果使用127.0.0.1都访问不了,除非那台服务器上有限制使用127.0.0.1作为目标地址(一般来说大部分系统管理员都不会这么做),否则就是他那台服务器的问题。

(2)如果使用telnet 127.0.0.1 8080访问成功,则你可以让他找一台同一个网段的终端(一般不可能没有)使用telnet 10.11.12.13 8080去测试,如果测试不通那你就别管网络了,一定是他系统自身的问题。如果他能测试通,或者他能拿出配置文件告诉你说服务器上没有针对源地址做限制,那你就真的要检查下网络了。

3、ping都不通的情况

实际上,不管是从源到目标要不要经过防火墙,“ping不通”这种情况必须得引起足够的重视。大多数情况下,ping不通多半都是网络出的问题,但也有特例,比如:

172.18.139.143/24到172.18.164.253/24发现ping不通。你知道了这是两个不同网段的地址,但你也别先急着去查路由(穿越了骨干网的情形除外)。首先你得知道172.18.164.253的网关是多少吧,比如说是172.18.164.254/24,那你就ping 172.18.164.254呗。如果能ping通网关,但是ping不通目标地址,也还暂时不能排除掉网络问题哦!怎么办?

那你就在网关所在的设备上查,查什么呢?当然是ARP信息、MAC地址表、接口CRC校验这些东西啊! 如果是ARP表项、MAC表项、接口CRC都没问题的话,那你的网络也就没问题了。

如果是同网段的都ping不通,你就直接检查ARP表项、MAC表项、接口CRC,都没问题的话,那也请他别找你了。


欢迎扫码关注我的微信公众号“捷哥教你学网络”

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在,都有一个你没有努力的曾经。