01-设备转发故障处理指南-新华三集团-H3C

01-设备转发故障处理指南

本章节下载 (433.51 KB)

01-设备转发故障处理指南

1.1 设备转发故障排查思路

1.1.1 设备转发路径简图

如图1-1所示，M9000系列设备的转发路径如下：

· 流量1：接口板----交换网板-----Blade----交换网板----接口板。

· 流量2：和流量1 基本一样只是报文的入接口和出接口不在同一个接口卡上。

· 流量3：Blade之间因为二次引流需要跨板的流量，跨板流量走的是板间透传,两个Blade 之间也要走交换网板，主要是GRE隧道报文，和IPsec隧道报文。

· 流量4：就是需要主控处理的，主要是协议报文和本地管理的报文。

图1-1 设备转发路径简图

1.1.2 故障排查思路

(1) 首先进行基本配置方面和组网方面的排查，排查思路如下：

图1-2 基本配置和组网排查示意图

(2) 进一步排查需要查看会话信息以及报文在设备内部转发过程，具体思路如下：

图1-3 排查会话和报文内部转发过程示意图

1.2 Ping不通

2. 常见原因

存在三种故障情形：

· 源端没有发出请求报文。

· 目的端没有发出应答报文。

· 中间设备丢包或传输时间长。

本类故障的常见原因主要包括：

· 链路传输时延较长。由于传输时延长，虽然源端接收到了目的端的回应报文，但已经超过等待时限而造成Ping不通的现象。

· 配置不当。例如，当Ping报文过大时，报文的出接口MTU值较小，且设置了不可分片的功能等。

· FIB表或ARP表中缺少对应的表项。

· 存在防攻击配置。

· 硬件故障。

3. 故障分析

本类故障的诊断思路如下：

(1) 检查Ping操作是否得当，调整Ping操作参数。

(2) 查看Ping报文的统计信息，确认出问题的节点。

(3) 检查是否存在到达目的端的ARP以及FIB表项。

(4) 排查是否因为防攻击配置导致Ping报文被丢弃。

本类故障的诊断流程如图1-4所示。

图1-4 Ping不通故障诊断流程图

4. 处理步骤

(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 1/0/1

GigabitEthernet1/0/1

Current state: UP

Line protocol state: UP

Description: GigabitEthernet1/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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。