网络基本功(十四):细说诊断工具ping
转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese
介绍
ping的工作原理很简单,一台网络设备发送请求等待另一网络设备的回复,并记录下发送时间。接收到回复之后,就可以计算报文传输时间了。只要接收到回复就表示连接是正常的。耗费的时间喻示了路径长度。重复请求响应的一致性也表明了连接质量的可靠性。因此,ping回答了两个基本的问题:是否有连接?连接的质量如何?本文主要讨论这两个问题。
更多信息
正常的ping操作主要是两个特定的ICMP消息,ECHO_REQUEST和ECHO_REPLY。理论上,所有TCP/IP网络设备都应当通过返回报文来响应ECHO_REQUEST,但实际上并不总是如此。
ping的解析:
大多数操作系统版本,会一直发送ECHO_REQUESTs,直到中断为止。例如:
bsd1# ping www.bay.com
PING www.bay.com (204.80.244.66): 56 data bytes
64 bytes from 204.80.244.66: icmp_seq=0 ttl=112 time=180.974 ms
64 bytes from 204.80.244.66: icmp_seq=1 ttl=112 time=189.810 ms
64 bytes from 204.80.244.66: icmp_seq=2 ttl=112 time=167.653 ms
^C
--- www.bay.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 167.653/179.479/189.810/9.107 ms
bsd1#
这一过程被Ctrl-C中断,此时打印出汇总统计。
上述结果中,针对每一个报文的回复给出了报文大小,来源,ICMP sequence number,TTL值,以及往返时间。其中,sequence number和往返时间对于评估基本连接状况来说是最有用的信息。
当发送一个ECHO_REQUEST时,将发送时间记录在报文里,并复制到远端主机相应的ECHO_REPLY报文中。当接收到ECHO_REPLY时,通过比较当前时间与报文时间计算出耗费时间。如果没有收到符合该sequence number的报文,则认为该报文丢失。耗费时间长短以及变化范围取决于中间链路数量,速度,以及链路拥塞情况。
什么值是合理的呢?这一值高度取决于网络以及网络质量。如果是在LAN网络环境下,响应时间还是很快的,通常在十几毫秒范围之内。如果连接到外网则该值会显著增加。如果是远程站点,可能会耗时上百毫秒。
你也可以用ping来粗略计算连接的吞吐量。在外网上发送两个不同大小的报文,通过-s选项来完成。时间长度的差别会反映大报文中额外数据所耗费的时间。例如,假设ping 100字节耗费30ms而ping 1100字节耗费60ms,因此,往返额外花费30ms单程额外花费15ms,多发送1000字节或8000比特。吞吐量近似为每15ms 8000比特或540,000bps。两个测量值之间的差异用来扣除开销。当然这一估算是非常粗略的,没有考虑到路径上其他数据流的情况,也没有考虑路径上所有链路的情况。
TTL貌似可以估算一条路径上的跳数,但是这有一些问题。当发送报文时,TTL字段先被初始化接着经过路径上每个路由器都要递减。如果达到0,报文就被丢弃了。从而对所有报文生命周期有一定限制。因而在路由回环的过程中,报文不会无期限存在于网络上。不幸的是,TTL字段可能会,也可能不会被远端设备重置,如果重置,也没有一致性。因此,要使用TTL字段估算路径中的跳数需要知道详细的系统信息。
通常一串稳定的回复意味着健康的连接。如果报文丢失或丢弃,可以在sequence number中看到跳数,以及丢失报文的编号。偶尔丢失一个报文不表示真的有什么问题。特别是跨越多台路由器或拥塞网络时。一个序列中的一个报文丢失或耗费明显更长时间是很正常的,这是因为路径中各条链路需对第一个报文做ARP解析。在ARP数据保存之后,后续报文就不会有这种开销。但是,如果丢失报文比例较大,则有可能路径上有问题。
某些情况下会收到ICMP错误消息。通常来自路由器,这里面包含很有用的信息。例如,下例中,设备尝试访问一个不存在的网络上的设备:
bsd1# ping 172.16.4.1
PING 172.16.4.1 (172.16.4.1): 56 data bytes
36 bytes from 172.16.2.1: Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 5031 0 0000 fe 01 0e49 172.16.2.13 172.16.4.1
36 bytes from 172.16.2.1: Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 5034 0 0000 fe 01 0e46 172.16.2.13 172.16.4.1
^C
--- 172.16.4.1 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
由于路由器没有到达该网络的路径,所以返回ICMP DESTINATION_HOST_UNREACHABLE信息。通常如果问题发生在运行ping命令的设备上,则会收到Destination Host Unreachable告警或 Destination Network Unreachable告警。如果问题发生在转发报文的设备上,则只会收到一条Destination Host Unreachable。
下例中,尝试向一台已配置拒绝从源设备接收数据流的路由器发送数据:
bsd1# ping 172.16.3.10
PING 172.16.3.10 (172.16.3.10): 56 data bytes
36 bytes from 172.16.2.1: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 5618 0 0000 ff 01 0859 172.16.2.13 172.16.3.10
36 bytes from 172.16.2.1: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 561b 0 0000 ff 01 0856 172.16.2.13 172.16.3.10
^C
--- 172.16.3.10 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
被过滤条件阻止的告警信息表明报文被丢弃。但也有可能过滤条件不显示该告警。
下例中,
bsd1# ping 172.16.3.10
PING 172.16.3.10 (172.16.3.10): 56 data bytes
^C
--- 172.16.3.10 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss
路由器上使用同样的过滤条件,但应用于离开网络的数据流,而不作用于inbound数据流。因此,没有消息发送。这时,ping就无法告诉你为什么报文没有收到回复。
ping的选项:
一些选项控制发送报文的速率和数量,-c选项允许用户指定发送报文的数量。例如,ping –c10会发送10个报文然后停止。这一命令在脚本中很有用处。
命令-f和-l用于将报文泛洪到网络上。-f选项表明报文发送速率与接收主机能够处理速率相同。这一参数可用于链路压力测试或接口性能比较。
-l选项用于计数,尽可能快的发送该数量报文,然后恢复正常。该命令用于测试处理泛洪的能力,需要root权限执行。
-i选项用于用户在两个连续报文之间指定等待秒数。该命令对于将报文间隔开或用在脚本中非常有用。正常情况下,偶然的ping包对数据流的影响是很小的。但重复报文或报文泛洪影响就很大了。因此,使用以上选项时需谨慎。
-n选项将输出限制为数字形式,这在碰见DNS问题时很有用。-v显示更详尽输出,较少输出为-q和-Q。
-s选项指定发送数据的大小。但如果设置的太小,小于8,则报文中就没有空间留给时间戳了。设置报文大小能诊断有路径MTU(Maximum Transmission Unit)设置或分段而导致的问题。如果不使用该选项,ping默认是64字节。