class 4.4 ping 不通 上传 bsp 公众 最大 人的 eply
有人说网络工程师是整个 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 区域的拓扑图:
如图所示: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.1522
- Trying172.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.1521
- Trying172.18.130.15...
- Connected to 172.18.130.15.
- Escape character is'^]'.
- YX-Sys-FrontDev> telnet 172.18.130.1520
- Trying172.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-65then 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 也没犯 "低级错误",那就肯定不是这个防火墙的问题。
如何给他证明呢?看图吧:
这里需要说明一下。步骤一里面,如果你在防火墙上使用 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,都没问题的话,那也请他别找你了。
来源: http://www.bubuko.com/infodetail-2450412.html