ping的使用

ping的使用
ping 大包的格式
Ping -s 8000 ip-address
Ping命令的格式和主要参数
在华为3Com公司Quidway系列路由器上，Ping命令的格式如下（粗体为关键字，斜体为参数）：
Ping [-c number][-t number][-s number] ip-address
-c Ping报文的个数缺省值是5个。

-t 设置Ping报文的超时时间以毫秒为单位缺省值为2000
-s 设置Ping报文的大小缺省值是56 byte。

实际上Ping命令的参数还很多本文只介绍最常用的三个。

例如：对目的地址202.101.6.21执行Ping操作，命令格式如下：
Quidway# Ping 202.101.6.21
Ping 202.101.6.21: 56 data bytes, press CTRL_C to break
Reply from 202.101.6.21: bytes=56 Sequence=1 ttl=255 time = 10 ms
Reply from 202.101.6.21: bytes=56 Sequence=2 ttl=255 time = 10 ms
Reply from 202.101.6.21: bytes=56 Sequence=3 ttl=255 time = 10 ms
Reply from 202.101.6.21: bytes=56 Sequence=4 ttl=255 time = 10 ms
Reply from 202.101.6.21: bytes=56 Sequence=5 ttl=255 time = 10 ms
--- 202.101.6.21 Ping statistics ---
5 packets transmitted
5 packets received
0% packet loss
round-trip min/avg/max = 10/10/10 ms
三、 Ping命令使用中的误区
在上一节中的命令中Ping 202.101.6.21虽然没有附加其他的参数，但实际上使用的是缺省值：路由器将发送5个大小为56个字节的ICMP报文，并认为正常的相应时间为2000毫秒。

而这些缺省参数通常为我们所忽视。

3.1 真的PING不通？
3.1.1 案例一：
工程师小L在配置完一台路由器之后，执行Ping命令检测链路是否通畅，但发现5个报文都没有Ping通，于是检查双方的配置命令、查看路由表，却一直没有找到错误所在。

最后无奈之下又重复执行了一遍相同的Ping命令，发现这一次5个报文中有2个Ping通了，原来是线路质量不好，存在比较严重的丢包现象。

点评：
小L被Ping命令的缺省参数-c 给迷惑了。

Ping不通的背后可能隐藏着的是丢包现象。

毕竟配置错误和线路质量不好的解决方法是大相径庭的。

有了此次教训之后，小L再遇到Ping不通的情况，都要把命令再敲一遍，并加上参数：-c 10，这意味着连续Ping10个报文来检验是否存在丢包现象。

命令如下
Ping -c 10 ip-address
3.1.2 案例二：
工程师小L在配置完一台路由器之后，执行Ping命令访问internet上某站点的IP地址，但没有Ping通，有了上次的教训，小L 再一次Ping了10个报文，仍旧没有响应。

于是小L断定网络故障，
但是在费劲周折检查了配置、链路之后仍没有发现任何可疑之处。

最后小L采取逐段检测的方法，对链路中的网关进行逐级测试，发现都可以Ping通，但是响应的时间越来越长，最后一个网关的响应时间在1800ms左右。

会不会是由于超时而导致显示为Ping不通呢？受此启发，小L将Ping命令回显
的时间改为4000ms。

这次成功Ping通了，但所有的报文响应时间都在2100ms左右。

点评：
这一次，小L被是被Ping命令的另一个缺省参数-t 给迷惑了。

Ping不通的背后可能隐藏着的是超时。

系统缺省的认为Ping报文应该在2000ms内有回应，如果超过这个时间，即使有回应报文送达，也认为Ping不通。

有了此次教训之后，小L再遇到Ping不通的情况，都要把命令再敲一遍，并加上参数：-c 10、-t 4000，这意味着连续Ping10个报文、每个报文的超时设置为4000ms，以此来检验是否存在丢包及响应时间过长等现象。

命令如下
Ping -c 10 -t 4000 ip-address
3.2 真的能PING通？
3.2.1 案例一：
工程师小L在一次工程中，需要在ATM接口上运行OSPF协议，由于该ATM接口只有一个对端，便将OSPF接口类型改为point-to-point。

在ATM顺利调通之后，可以正常Ping通对端地址，但是OSPF却无法正常运行。

（配置如下）
interface Atm2/0/0.100
ip address 202.111.128.214 255.255.255.252
map-group atmzz
atm pvc 1 163 199 aal5snap ipoa ubr 155000 155000 32
ip ospf cost 100
ip ospf network point-to-point
map-list atmzz
ip 202.111.128.213 atm-vc 1
查看调试信息，发现双方都没有收到对端发来的HELLO报文，打开DEBUG开关，发现本端发送的HELLO报文由OSPF交给IP层，但IP层交给ATM层时，却被ATM层丢弃了。

细查原因，原来OSPF的HELLO报文是多播报文（类似于广播报文），而ATM缺省是不支持发送广播报文的，需要特殊的配置。

将配置改为：
ip 202.111.128.213 atm-vc 1 broadcast
即增加broadcast参数以支持广播报文的发送问题解决。

点评：
Ping命令实际上只能测试单播报文，而不能测试广播和多播报文。

3.2.2 案例二：
小L在一次工程中，需要在NE路由器和JUNIPER路由器之间通过POS口相连，并运行OSPF
路由协议。

小L在配置完成后，一切正常，割接之后设备运行稳定，没有出现任何故障。

但在两个月之后，用户突然反馈说网络中断。

小L登录到路由器之后，发现POS口连接正常，可以Ping通对端地址，但是OSPF协议中断了。

小L按照如下步骤进行查询：
查看邻居状态，邻居状态机STATE处于exstart状态。

打开NE路由器的debug 开关查看相应的报文信息。

发现相互都可以收到HELLO 报文。

但NE发送DD报文之后，却一直没有收到对方回应的DD报文。

打开JUNIPER路由器的debug开关，发现对方收到NE的DD报文后，已发送了相应的DD报文予以回应。

但是NE却没有收到。

可以初步断定：NE并没有接收到这个报文，但是对方确实发出来了。

既然可以接收到HELLO报文，说明链路是通畅的。

而且多播报文的收发也没有问题。

有可能是对方发送的DD报文有错误，导致NE拒收。

但查看相应的信息，NE并没有报告接收到过错误的DD报文。

仔细查看某厂商路由器的调试信息，发现这个DD报文很大，有2000多字节。

会不会是由于报文太大导致的问题呢？小L试着Ping了一个2000字节的报文，竟然不通！仔细察看：发现因为双方的MTU不一致，导致大包不通所致。

JUNIPER路由器的MTU是4000多，而NE为1500。

将JUNIPER的MTU改为1500，问题解决。

至于为什么在工程初期没有问题，是因为后来网络扩容，导致路由信息过多，使DD报文的长度超过了1500字节。

点评：
这一次，小L被是被Ping命令的另一个缺省参数-s 给迷惑了。

由于Ping缺省报文是56个字节，所以显示的Ping通信息只表示56字节的报文可以通，而并不一定表示其他大小的报文仍旧可以通。

但这并不一定意味着我们要从56个字节逐级向上Ping。

通常如果大包可以Ping通，则小包一定会通。

有了此次教训之后，小L在Ping通的情况，都要把命令再敲一遍，并加上参数：-s 8000，这意味着测试一下大包是否能通。

命令如下：
Ping -s 8000 ip-address。