精华 | 网络故障排除命令汇总【网工必须收藏】( 二 ) _Show命令

(2) 建议和总结：
真的是Ping不通吗？这个问题需要定位清楚，因为连通性问题和性能问题排错的关注点是不一样的――问题定位错误必然会导致排错过程的周折。使用一般的Ping命令，缺省是发送5个报文的，超时时长是2000ms 。如果Ping不通情况发生，最好能够再用带参数-c和-t的Ping命令再执行一遍，如：Ping -c 20 -t 4000 ip-address，即连续发送20个报文，每个报文的超时时长为4000ms，这样一般可以判断出到底是连通性问题还是性能问题。
案例二：使用大包ping对端进行MTU不一致的故障排除(1) 现象描述：
某次开局，使用RG路由器与其他厂商的某路由器互连，并运行OSPF协议。数据配置完毕后，一切正常，并在今后相当长的时间内设备运转稳定。但两个月后，用户反馈网络中断。
(2) 相关信息显示：

登录到两台路由器上，发现双方连接正常，可以相互Ping通对端地址。但OSPF协议中断；
登录RG路由器查看邻居状态，发现邻居状态机处于Exstart状态。打开相应的debug开关查看相应的报文信息，发现双方都可以收到Hello报文，但RG路由器发送DD报文后，一直没有收到对方回应的DD报文；
登录其他厂商的那台路由器，打开相应的debug开关，发现对方收到RG路由器发送的DD报文后，一发送了相应的DD报文予以回应。

(3) 原因分析：
初步断定，RG路由器没有收到DD回应报文，但对方确实发出来了。
既然可以接收到HELLO 报文说明链路是通畅的，而且多播报文的收发也没有问题。那么有可能是对方发送的DD 报文有错误导致RG路由器拒收，但查看相应的信息，并没有报告接收到错误的DD 报文。
仔细查看某厂商路由器的调试信息发现这个DD报文很大有2000 多字节。会不会是由于报文太大导致的问题呢？试着Ping了一个2000字节的报文，结果不通。那么故障原因很可能是－－由于双方的MTU不一致导致大包不通。
(4) 处理过程：
检查配置，发现对方路由器的MTU设置为4000多而RG路由器的MTU设置为1500，于是修改对端路由器的MTU为1500 。故障排除。
那么为什么工程初期没有问题呢？这是因为前期DD报文长度小于1500字节，而后来网络扩容导致路由信息过多使DD 报文的长度超过了1500 字节。
(5) 建议和总结：
由于Ping 缺省报文是56 个字节，所以显示的Ping 通信息只是表示56字节的报文可以通而并不一定表示其他大小的报文仍旧可以通。所以，应当善于使用Ping的其他参数来进行故障排除。
案例三：A能Ping通B，B就一定能Ping通A吗？(1) 现象描述
组网图如下：

精华 | 网络故障排除命令汇总【网工必须收藏】 — 图1-1 案例：A能Ping通B，B就一定能Ping通A吗？

在RouterA上配置一条指向2.0.0.0/8的静态路由：

RouterA（config）# ip route 2.0.0.0 255.0.0.0 1.1.1.1

在RouterA 上Ping RouterB 的以太网地址2.2.2.2，显示可以正常Ping通；但是在RouterB上Ping RouterA的以太网地址3.3.3.3，却无法Ping通。
(2) 原因分析：
由于在RouterB 上却没有相应的配置到3.0.0.0/8 路由，所以从RouterB 上Ping不通RouterA的以太网口3.3.3.3。
但是为何在A上可以Ping 通2.2.2.2 呢？同样是没有回程路由呀？打开路由器上的IP报文调试开关发现，原来从RouterA上发出的ICMP报文的源地址填写的是1.1.1.1而不是3.3.3.3，由于两台路由器的s0口处于同一网段，所以响应报文可以顺利到达RouterB 。
(3) 建议和总结：
A能够Ping通B则B一定能够Ping通A（不考虑防火墙的因素）,这句话的对错取决于A和B到底是指主机还是指路由器。