- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
05-Ping和Tracert故障处理手册
本章节下载： 05-Ping和Tracert故障处理手册 (385.09 KB)
在源端执行Ping操作，在一定时间范围内没有收到目的端对该请求的回应。
存在三种故障情形：
· 源端没有发出请求报文。
· 目的端没有发出应答报文。
· 中间设备丢包或传输时间长。
本类故障的常见原因主要包括：
· 链路传输时延较长。由于传输时延长，虽然源端接收到了目的端的回应报文，但已经超过等待时限而造成Ping不通的现象。
· 配置不当。例如，当Ping报文过大时，报文的出接口MTU值较小，且设置了不可分片的功能等。
· FIB表或ARP表中缺少对应的表项。
· 存在防攻击配置。
· 硬件故障。
本类故障的诊断思路如下：
(1) 检查Ping操作是否得当，调整Ping操作参数。
(2) 查看Ping报文的统计信息，确认出问题的节点。
(3) 检查是否存在到达目的端的ARP以及FIB表项。
(4) 排查是否因为防攻击配置导致Ping报文被丢弃。
本类故障的诊断流程如图1-1所示。
图1-1 Ping不通故障诊断流程图
(1) 检查Ping操作是否得当。
a. 检查是否因为实际链路传输时延较长导致Ping不通。
检查是否执行了ping -t timeout命令，如果执行了此操作，可通过增加-t参数的值（建议取值大于等于1000，达到秒级）或者去掉-t参数重新Ping。如果故障消除，则说明较大概率属于实际网络时延大导致的Ping不通；如果故障未消除，请继续定位。
-t参数用来指定ICMP回显应答（ECHO-REPLY）报文的超时时间，单位为毫秒，缺省值为2000。如果源端在timeout时间内未收到目的端的ICMP回显应答（ECHO-REPLY）报文，则会认为目的端不可达。
b. 检查是否因为Ping报文过大而被丢弃。
检查是否执行了ping -f –s packet-size命令，如果执行了此操作，且报文转发路径上存在出接口的MTU小于报文长度packet-size的情况，则会导致报文因为超大且不允许被分片而被丢弃。可以通过减小报文长度或者取消-f参数来解决这个问题。
· -f参数表示将长度大于出接口MTU的报文直接丢弃，即不允许对发送的ICMP回显请求报文进行分片。
· -s packet-size参数用来指定发送的ICMP回显请求报文的长度（不包括IP和ICMP报文头），单位为字节，缺省值为56。
以太网接口MTU的缺省值为1500字节，可以通过执行display interface命令来查看接口的MTU值：
<Sysname> display interface gigabitethernet 0/0/1
GigabitEthernet0/0/1
Current state: UP
Line protocol state: UP
Description: GigabitEthernet0/0/1 Interface
Bandwidth: 1000000 kbps
Maximum transmission unit: 1500
其它显示信息略……
c. 检查是否指定了错误的出接口。
检查是否执行了ping -i interface-type interface-number命令指定Ping报文的出接口。如果指定了出接口，请确保该接口和目的端之间的物理链路是否可达。否则，请换成其它接口或者去掉-i参数。
-i interface-type interface-number参数用来指定发送ICMP回显请求报文的接口的类型和编号。不指定该参数时，将根据目的IP查找路由表或者转发表来确定发送ICMP回显请求报文的接口。
d. 检查是否指定了源地址。
检查是否执行了ping –a source-ip命令指定Ping报文的源地址。如果执行了该命令，请确保中间设备和目的端有到达源地址source-ip的路由。
-a source-ip：指定ICMP回显请求（ECHO-REQUEST）报文的源IP地址。该地址必须是设备上已配置的IP地址。不指定该参数时，ICMP回显请求报文的源IP地址是该报文出接口的主IP地址。
e. 检查是否为目的端指定了准确的VPN。
根据网络规划和部署情况，确认目的端是否属于某个VPN。如果目的端属于某个VPN，则需要在执行ping命令时通过-vpn-instance参数指定目的端所属的VPN。
(2) 查看源端、目的端以及中间设备的收发包统计，确认Ping故障发生的方向。
¡ 检查源端是否发出了ICMP回显请求报文，并收到了ICMP回显应答报文。
源端执行Ping操作后，在源端和目的端分别使用display icmp statistics命令查看ICMP报文收发情况。可以根据统计信息中Input和Output区段报文的数量来确定Ping出现问题的方向：
- 如果源端Output区段的echo值正常增加，但Input区段的echo replies值没有增加，则说明源端发出了请求但是没有收到回应；与此同时，如果目的端Input区段和Output区段的计数都没有变化，则说明目的端没有收到请求也没有给予回应。这样，就可以确定Ping报文是在从源端到目的端的方向上出现了转发故障。
- 如果源端Output区段的echo值正常增加，但Input区段的echo replies值没有增加，则说明源端发出了请求但是没有收到回应；与此同时，如果目的端Input区段和Output区段的计数都正常增加，则说明目的端收到了请求，同时发出了回应。这样，就可以确定Ping报文是在从目的端到源端的方向上出现了转发故障。
display icmp statistics命令显示信息示例如下：
<Sysname> display icmp statistics
Input: bad formats 0 bad checksum 0
echo 1 destination unreachable 0
source quench 0 redirects 0
echo replies 0 parameter problem 0
timestamp 0 information requests 0
mask requests 0 mask replies 0
time exceeded 0 invalid type 0
router advert 0 router solicit 0
broadcast/multicast echo requests ignored 0
broadcast/multicast timestamp requests ignored 0
Output: echo 0 destination unreachable 0
source quench 0 redirects 0
echo replies 1 parameter problem
0
timestamp 0 information replies 0
mask requests 0 mask replies 0
time exceeded 0 bad address 0
packet error 0 router advert 0
其它显示信息略……
· 当目的端是框式设备或者IRF设备，且ICMP报文到达目的端未被分片时，请在目的端执行带slot参数的display icmp statistics命令来查看ICMP报文统计信息，slot为目的端接收该ICMP报文的接口所在的Slot。
· 当目的端是框式设备或者IRF设备，但ICMP报文到达目的端前被分片了，请在目的端执行display icmp statistics命令来查看ICMP报文统计信息即可。
(3) 确定出问题的节点。
确定了Ping故障的发生的方向后，请执行tracert命令确定该方向上报文丢失的位置。
¡ 如果源端到目的端方向出现了问题，请从源端开始排查。
¡ 如果目的端到源端方向出现问题，请从目的端开始排查。
如下例所示，可以通过tracert命令查看报文从源端到目的端（IP地址为1.1.3.2，属于vpn1）所经过的路径，并显示报文经过的私网中的三层设备的信息。
<Sysname> tracert –vpn-instance vpn1 –resolve-as vpn 1.1.3.2
traceroute to 1.1.3.2 (1.1.3.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break
1 1.1.1.2 (1.1.1.2) 673 ms 425 ms 30 ms
2 1.1.2.2 (1.1.2.2) 580 ms 470 ms 80 ms
3 * * *
由以上信息可判断，Ping报文在1.1.2.2的下一跳设备上（即显示为“3 * * *”的节点）出现转发故障。
(4) 检查是否存在到达目的端和源端的FIB表项与ARP表项。
请在问题节点上执行以下操作：
¡ 执行display fib命令检查是否存在到达目的端和源端的路由。如果路由不存在，请检查OSPF、IS-IS、BGP等路由协议配置是否有误。
¡ 如果路由存在并且报文所经链路是以太链路，请执行display arp命令查看是否存在所需的ARP表项。如果ARP表项不存在，请首先排查ARP故障。
(5) 检查问题节点上是否配置ICMP防攻击功能。
如果设备上配置了ICMP攻击相关的防范策略，且设备检测到ICMP攻击，设备会将ICMP报文直接丢弃，从而导致Ping不通。
¡ 通过display attack-defense icmp-flood statistics ip命令查看统计信息的计数来判断设备是否受到了ICMP攻击。
¡ 通过display current-configuration | include icmp-flood、display current-configuration | include “signature detect”查看当前是否配置攻击防范策略。
如果设备受到了ICMP攻击，请先定位并解除ICMP攻击。
(6) 根据收发包统计，确认丢包位置和丢包原因。
在Ping报文途径的设备上：
a. 配置QoS策略，使用ACL源地址和目的地址过滤Ping报文，然后在Ping报文途径接口的入方向和出方向应用QoS策略。
b. 通过display qos policy interface命令查看应用QoS策略的接口上QoS策略匹配成功的报文个数。如果报文个数有增长，则说明设备收到了Ping报文；如果报文个数无增长，则说明设备没有收到Ping报文，此时，可以使用debugging ip packet命令打开IP报文调试信息开关，进一步排查设备没有收到Ping报文的原因并解决问题。
(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
执行Tracert操作，显示信息中出现“* * *”行，说明某些节点之间路由不可达，Tracert不通。
本类故障的常见原因主要包括：
· 无对应的路由或者ARP表项。
· 中间设备未开启ICMP超时报文发送功能。
· 目的端未开启ICMP目的不可达报文发送功能。
本类故障的诊断思路如下：
(1) 检查中间设备是否开启了ICMP超时报文发送功能。
(2) 检查目的端是否开启了ICMP目的不可达报文发送功能。
(3) 检查是否存在达到目的端的ARP以及FIB表项。
本类故障的诊断流程如图1-2所示。
图1-2 Tracert不通故障诊断流程图
(1) 检查中间设备是否开启了ICMP超时报文发送功能。
# 查看报文从源端到目的端所经过的路径（假设源端到目的端只有两跳，目的端的IP地址为1.1.2.2）。
<Sysname> tracert 1.1.2.2
traceroute to 1.1.2.2 (1.1.2.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break
1 * * *
2 1.1.2.2 (1.1.2.2) [AS 100] 580 ms 470 ms 80 ms
出现以上显示信息时，请登录中间设备，在中间设备上执行ip ttl-expires enable命令开启ICMP超时报文发送功能。如果故障排除，则说明中间设备未开启ICMP超时报文发送功能导致Tracert不通；如果故障未排除，请继续执行下面的步骤。
(2) 检查目的端是否开启了ICMP目的不可达报文发送功能。
# 查看报文从源端到目的端所经过的路径（假设源端到目的端只有两跳，目的端的IP地址为1.1.2.2）。
<Sysname> tracert 1.1.2.2
traceroute to 1.1.2.2 (1.1.2.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break
1 1.1.1.2 (1.1.1.2) [AS 99] 560 ms 430 ms 50 ms
2 * * *
出现以上显示信息时，请在目的端执行ip unreachables enable命令开启ICMP目的不可达报文发送功能。如果故障排除，则说明目的端未开启ICMP目的不可达报文发送功能；如果故障未排除，请继续执行下面的步骤。
(3) 在问题节点上检查是否存在对应的FIB表项和ARP表项。
在未回应ICMP差错报文的设备（tracert命令执行结果中显示为“* * *”的设备）上执行display fib命令，检查是否存在到目的地址的路由。
¡ 如果路由不存在，请检查OSPF、IS-IS、BGP等路由协议配置是否有误。
¡ 如果路由存在并且报文所经链路是以太链路，请执行display arp命令查看Tracert的下一跳地址对应的ARP表项是否存在。如果不存在，请检查ARP配置是否有误。
(4) 检查Tracert发起端是否收到ICMP差错报文。
发起Tracert后，在Tracert发起端上多次执行display icmp statistics命令查看发起端是否收到ICMP差错报文，显示信息示例如下：
<Sysname> display icmp statistics
Input: bad formats 0 bad checksum 0
echo 0 destination unreachable 9
source quench 0 redirects 0
echo replies 7 parameter problem 0
timestamp 0 information requests 0
mask requests 0 mask replies 0
time exceeded 3 invalid type 0
router advert 0 router solicit 0
broadcast/multicast echo requests ignored 0
broadcast/multicast timestamp requests ignored 0
其它显示信息略……
观察以上ICMP报文的统计信息的变化，判断Input区段内的time exceeded和destination unreachable值的增量是否与Tracert报文发送个数相等，如果不等则表明发起端未收到ICMP差错报文。
(5) 根据收发包统计，确认丢包位置和丢包原因。
在Tracert报文途径的设备上：
a. 配置QoS策略，使用ACL源地址和目的地址过滤Tracert报文，然后在Tracert报文途径接口的入方向和出方向应用QoS策略。
b. 通过display qos policy interface命令查看应用QoS策略的接口上QoS策略匹配成功的报文个数。如果报文个数有增长，则说明设备收到了Tracert报文；如果报文个数无增长，则说明设备没有收到Tracert报文，此时，可以使用debugging ip packet命令打开IP报文调试信息开关，进一步排查设备没有收到Tracert报文的原因并解决问题。
(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
在源端执行IPv6 Ping操作，在一定时间范围内没有收到目的端对该请求的回应。
存在三种故障情形：
· 源端没有发出请求报文。
· 目的端没有发出应答报文。
· 中间设备丢包或传输时间长。
本类故障的常见原因主要包括：
· 链路传输时延较长。由于传输时延长，虽然源端接收到了目的端的回应报文，但已经超过等待时限而造成IPv6 Ping不通的现象。
· 配置不当，执行Ping操作时，指定的参数值和网络能力不匹配。例如当IPv6 Ping报文过大时，中间设备的IPv6 Ping报文出接口MTU值较小，导致IPv6 Ping报文报文被丢弃。
· IPv6 FIB表或ND表中缺少对应的表项。
· 存在防攻击配置。
· 硬件故障。
本类故障的诊断思路如下：
(1) 检查IPv6 Ping操作是否得当，调整IPv6 Ping操作参数。
(2) 查看IPv6 Ping报文的统计信息，确认出问题的节点。
(3) 检查是否存在到达目的端的ND以及IPv6 FIB表项。
(4) 排查是否因为防攻击配置导致IPv6 Ping报文被丢弃。
本类故障的诊断流程如图1-3所示。
图1-3 IPv6 Ping不通故障诊断流程图
(1) 检查IPv6 Ping操作是否得当。
a. 检查是否因为实际链路传输时延较长导致IPv6 Ping不通。
检查是否执行了ping ipv6 -t timeout命令，如果执行了此操作，可通过增加-t参数的值（建议取值大于等于1000，达到秒级）或者去掉-t参数重新Ping。如果故障消除，则说明较大概率属于实际网络时延大导致的IPv6 Ping不通；如果故障未消除，请继续定位。
-t参数用来指定ICMPv6回显应答（ECHO-REPLY）报文的超时时间，单位为毫秒，缺省值为2000。如果源端在timeout时间内未收到目的端的ICMPv6回显应答（ECHO-REPLY）报文，则会认为目的端不可达。
b. 检查是否因为IPv6 Ping报文过大而被丢弃。
检查是否执行了ping ipv6 –s packet-size命令，如果执行了此操作，且报文转发路径上存在出接口的MTU小于报文长度packet-size的情况，则会导致报文因为超大且不允许被分片而被丢弃。可以通过减小报文长度来解决这个问题。
-s packet-size参数用来指定发送的ICMPv6回显请求报文的长度（不包括IPv6和ICMPv6报文头），单位为字节，缺省值为56。
以太网接口MTU的缺省值为1500字节，可以通过执行display interface命令来查看接口的MTU值：
<Sysname> display interface gigabitethernet 0/0/1
GigabitEthernet0/0/1
Current state: UP
Line protocol state: UP
Description: GigabitEthernet0/0/1 Interface
Bandwidth: 1000000 kbps
Maximum transmission unit: 1500
…
c. 检查是否指定了错误的出接口。
检查是否执行了ping ipv6 -i interface-type interface-number命令指定IPv6 Ping报文的出接口。如果指定了出接口，请确保该接口和目的端之间的物理链路是否可达。否则，请换成其它接口或者去掉-i参数。
-i interface-type interface-number参数用来指定发送ICMPv6回显请求报文的接口的类型和编号。不指定该参数时，将根据目的IP查找路由表或者转发表来确定发送ICMPv6回显请求报文的接口。
d. 检查是否指定了源地址。
检查是否执行了ping ipv6 –a source-ip命令指定IPv6 Ping报文的源地址。如果执行了该命令，请确保中间设备和目的端有到达源地址source-ip的路由。
-a source-ip：指定ICMPv6回显请求（ECHO-REQUEST）报文的源IPv6地址。该地址必须是设备上已配置的IPv6地址。不指定该参数时，ICMPv6回显请求报文的源IPv6地址是该报文出接口的主IPv6地址。
e. 检查是否为目的端指定了准确的VPN。
根据网络规划和部署情况，确认目的端是否属于某个VPN。如果目的端属于某个VPN，则需要在执行ping ipv6命令时通过-vpn-instance参数指定目的端所属的VPN。
(2) 查看源端、目的端以及中间设备的收发包统计，确认IPv6 Ping故障发生的方向。
¡ 检查源端是否发出了ICMPv6回显请求报文，并收到了ICMPv6回显应答报文。
源端执行IPv6 Ping操作后，在源端和目的端分别使用display ipv6 icmp statistics命令查看ICMPv6报文收发情况。可以根据统计信息中Input和Output区段报文的数量来确定IPv6 Ping出现问题的方向：
- 如果源端Output区段的echo request值正常增加，但Input区段的echo reply值没有增加，则说明源端发出了请求但是没有收到回应；与此同时，如果目的端Input区段和Output区段的计数都没有变化，则说明目的端没有收到请求也没有给予回应。这样，就可以确定IPv6 Ping报文是在从源端到目的端的方向上出现了转发故障。
- 如果源端Output区段的echo request值正常增加，但Input区段的echo reply值没有增加，则说明源端发出了请求但是没有收到回应；与此同时，如果目的端Input区段和Output区段的计数都正常增加，则说明目的端收到了请求，同时发出了回应。这样，就可以确定IPv6 Ping报文是在从目的端到源端的方向上出现了转发故障。
display ipv6 icmp statistics命令显示信息示例如下：
<Sysname> display ipv6 icmp statistics
Input: bad code 0 too short 0
checksum error 0 bad length 0
path MTU changed 0 destination unreachable 0
too big 0 parameter problem 0
echo request 1 echo reply 0
neighbor solicit 0 neighbor advertisement 0
router solicit 0 router advertisement 0
redirect 0 router renumbering 0
output: parameter problem 0 echo request 0
echo reply 1 unreachable no route 0
unreachable admin 0 unreachable beyond scope 0
unreachable address 0 unreachable no port 0
too big 0 time exceed transit 0
time exceed reassembly 0 redirect 0
ratelimited 0 other errors 0
· 当目的端是框式设备或者IRF设备，且ICMPv6报文到达目的端未被分片时，请在目的端执行带slot参数的display ipv6 icmp statistics命令来查看ICMPv6报文统计信息，slot为目的端接收该ICMPv6报文的接口所在的Slot。
· 当目的端是框式设备或者IRF设备，但ICMPv6报文到达目的端前被分片了，请在目的端执行display ipv6 icmp statistics命令来查看ICMPv6报文统计信息即可。
(3) 确定出问题的节点。
确定了IPv6 Ping故障的发生的方向后，请执行tracert ipv6命令确定该方向上报文丢失的位置。
¡ 如果源端到目的端方向出现了问题，请从源端开始排查。
¡ 如果目的端到源端方向出现问题，请从目的端开始排查。
如下例所示，可以通过IPv6 Tracert功能查看报文从源端到目的端（IP地址为2::2）所经过的路径，并显示报文经过的三层设备的信息。
<Sysname> tracert ipv6 2::2
traceroute to 2::2 (2::2), 30 hops at most, 104 byte packets, press CTRL_C to break
1 1::2 1.000 ms 0.000 ms 1.000 ms
2 * * *
由以上信息可判断，IPv6 Ping报文在1::2的下一跳设备上（即显示为“2 * * *”的节点）出现转发故障。
使用IPv6 Tracert功能：
· 需要在中间设备（源端与目的端之间的设备）的系统视图下执行ipv6 hoplimit-expires enable命令开启设备的ICMPv6超时报文的发送功能。
· 需要在目的端设备系统视图下执行ipv6 unreachables enable命令开启设备的ICMPv6目的不可达报文的发送功能。
(4) 检查是否存在到达目的端和源端的IPv6 FIB表项与ND表项。
请在问题节点上执行以下操作：
¡ 执行display ipv6 fib命令检查是否存在到达目的端和源端的路由。如果路由不存在，请检查IGP和BGP等路由协议配置是否有误。
¡ 如果路由存在并且报文所经链路是以太链路，请执行display ipv6 neighbors命令查看是否存在所需的ND表项。如果ND表项不存在，请首先排查ND故障。
(5) 检查问题节点上是否配置ICMPv6防攻击功能。
如果设备上配置了ICMPv6攻击相关的防范策略，且设备检测到ICMPv6攻击，设备会将ICMPv6报文直接丢弃，从而导致IPv6 Ping不通。
¡ 通过display attack-defense icmpv6-flood statistics ipv6命令查看统计信息的计数来判断设备是否受到了ICMPv6攻击。
¡ 通过display current-configuration | include icmpv6-flood、display current-configuration | include “signature detect”查看当前是否配置攻击防范策略。
如果设备受到了ICMPv6攻击，请先定位并解除ICMPv6攻击。
(6) 根据收发包统计，确认丢包位置和丢包原因。
在IPv6 Ping报文途径的设备上：
a. 配置QoS策略，使用IPv6 ACL源地址和目的地址过滤IPv6 Ping报文，然后在IPv6 Ping报文途径接口的入方向和出方向应用QoS策略。
b. 通过display qos policy interface命令查看应用QoS策略的接口上QoS策略匹配成功的报文个数。如果报文个数有增长，则说明设备收到了IPv6 Ping报文；如果报文个数无增长，则说明设备没有收到IPv6 Ping报文，此时，可以使用debugging ipv6 packet命令打开IPv6报文调试信息开关，进一步排查设备没有收到IPv6 Ping报文的原因并解决问题。
(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!
支持
