标签：现象 multicast too deny 行业 enc 技术 toolbar 本机
有人说网络工程师是整个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.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也没犯“低级错误”，那就肯定不是这个防火墙的问题。
如何给他证明呢？看图吧：
这里需要说明一下。步骤一里面，如果你在防火墙上使用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，都没问题的话，那也请他别找你了。
欢迎扫码关注我的微信公众号“捷哥教你学网络”
标签：现象 multicast too deny 行业 enc 技术 toolbar 本机
原文地址：http://blog.51cto.com/wzjxzht/2057437
