- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
02-隧道接口故障处理手册
本章节下载： 02-隧道接口故障处理手册 (185.75 KB)
点对点类隧道（包括GRE、IPv4和IPv6隧道）配置完成后，Tunnel接口状态为up，且本端隧道接口IP地址可以Ping通对端隧道接口IP地址。但隧道接口工作状态不稳定，包括：
· 隧道接口震荡，反复的up/down。
· 隧道报文丢包率高，传输速率低。
本章节以GRE over IPv4隧道为例进行介绍。
本类故障的常见原因主要包括：
· 到达隧道目的地址的路由震荡，导致隧道也发生震荡。
· 设备上配置了隧道A的源目的地址和隧道B的源目的地址相同，导致其中只有一条隧道可以up。
· GRE隧道接口下使能了保活探测报文功能，但设备无法正常收发GRE keepalive报文，导致设备将隧道置为down。
· 设备资源不足，隧道下发硬件处理失败，导致隧道在物理层down。
· 隧道口下的配置不合理，导致隧道报文丢包。
本类故障的诊断流程如图1-1所示。
(1) 检查路由是否发生震荡。
通过debugging tunnel event命令打开隧道事件调试开关，如果持续出现路由刷新或删除消息，说明路由出现震荡，此时隧道也会震荡。示例如下：
<Sysname> debugging tunnel event
<Sysname> %Jun 16 12:49:55:497 2022 Sysname BGP/5/BGP_STATE_CHANGED: BGP.: 4.4.4.4 state has changed from ESTABLISHED to IDLE for TCP_Connection_Failed event received.
// BGP邻居的IP地址为4.4.4.4，收到TCP连接失败事件，BGP会话状态从Established转换为Idle
%Jun 16 12:49:55:497 2022 Sysname BGP/5/BGP_STATE_CHANGED_REASON: BGP.: 4.4.4.4 state has changed from ESTABLISHED to IDLE. (Reason: TCP connection failed(No route to host))
// BGP邻居的IP地址为4.4.4.4，BGP会话状态从Established转换为Idle，原因是TCP连接失败（没有到达主机的路由）
如果存在路由震荡，则需要根据路由刷新或删除消息进一步排查设备路由震荡原因。例如，本例中BGP会话无法稳定进入Established状态，可以参考BGP故障处理手册进行定位。
如果不存在路由震荡，请继续执行步骤(2)排查故障。
分别在两端设备的任意视图下执行display interface tunnel命令，查看是否存在隧道A的源目的地址和隧道B的源目的地址相同的情况。
<Sysname> display interface Tunnel
Tunnel0
Current state: UP
Line protocol state: UP
Description: Tunnel0 Interface
Bandwidth: 64 kbps
Maximum transmission unit: 1464
Internet protocol processing: Disabled
Output queue - Urgent queuing: Size/Length/Discards 0/100/0
Output queue - Protocol queuing: Size/Length/Discards 0/500/0
Output queue - FIFO queuing: Size/Length/Discards 0/75/0
Last clearing of counters: 15:20:18 Mon 06/13/2022
Tunnel source 1.1.1.1, destination 2.2.2.2
略…
如果存在同源同目的隧道，只允许其中一个up，可以通过undo interface tunnel命令删除不需要的隧道；如果不存在同源同目的隧道，则执行步骤(3)继续排查故障。
(3) 检查是否配置GRE保活探测报文功能，是否可以正常收发GRE keepalive报文。
在任意视图下执行display current interface tunnel命令查看隧道接口的keepalive配置。
<Sysname> display current interface tunnel
#
interface Tunnel2 mode gre
ip address 10.1.1.2 255.255.255.0
source 12.1.1.4
destination 12.1.1.2
keepalive 3 3
#
在本端设备上通过debugging gre packet命令打开GRE报文调试开关，查看是否可以正常收发keepalive报文。
<Sysname> debugging gre packet
*Jun 16 12:46:50:350 2022 Sysname GRE/7/packet:
Tunnel2 packet: Before encapsulation,
12.1.1.2->12.1.1.4 (length = 24)
*Jun 16 12:46:50:350 2022 Sysname GRE/7/packet:
Tunnel2 packet: After encapsulation,
12.1.1.4->12.1.1.2 (length = 48)
*Jun 16 12:46:50:351 2022 Sysname GRE/7/packet:
Tunnel2 packet: Before de-encapsulation according to fast-forwarding table,
12.1.1.2->12.1.1.4 (length = 24)
*Jun 16 12:46:50:351 2022 Sysname GRE/7/packet:
Tunnel2 : Received a keepalive packet.
// Tunnel2收到keepalive报文
在对端设备上同样打开GRE报文调试开关，如果对端显示发出了keepalive报文，本端却未收到，则GRE报文可能未通过本端的校验和检查。无法收到keepalive报文会导致隧道接口down，可以尝试通过undo gre checksum命令关闭本端GRE报文的校验和功能或通过undo keepalive命令关闭keepalive功能来解决该问题。
如果能够正常收到keepalive报文，则执行步骤(4)继续排查故障。
(4) 检查隧道报文的hoplimit/TTL和隧道报文DF标志配置是否合理。
在任意视图下执行display current interface tunnel命令查看hoplimit/TTL和隧道报文DF标志的配置：
#
interface Tunnel2 mode gre
ip address 10.1.1.2 255.255.255.0
source 12.1.1.4
destination 12.1.1.2
keepalive 3 3
tunnel ttl 1
tunnel dfbit enable
#
hoplimit/TTL配置和DF（Don’t Fragment，不分片）标志的配置可能导致隧道报文被丢弃：
a. hoplimit/TTL配置过小会导致隧道报文在中间设备上因为TTL超时而被丢弃。解决方法为在隧道接口视图下执行tunnel ttl命令，依照实际组网配置合理的TTL值；
b. 设置封装后的隧道报文的DF标志后，中间设备可能会因为报文长度超出接口MTU值而丢弃报文。解决方法为配置转发路径上各个接口的MTU大于隧道报文长度。在无法保证转发路径上各个接口的MTU大于隧道报文长度时，请关闭隧道报文不分片功能。
执行以上操作后仍无法排除故障，则执行步骤(5)继续排查故障。
(5) 查看是否隧道下发硬件处理失败。
打开隧道事件调试信息开关，查看是否有隧道报文或事件下内核/驱动失败，调试信息的示例如下：
<Sysname>debugging tunnel all
*Jun 16 12:51:25:832 2022 Sysname TUNNEL/7/event:
Tunnel2 notifies driver: Operation = 4.
TunnelIfIndex = 524, EvilinkIfIndex = 0
VRFIndex = 0, DstVRFIndex = 0
TunnelMode = IPv4 GRE, TransPro = 1
TunnelSrc = 12.1.1.4
TunnelDst = 12.1.1.2
TTL = 255, ToS = 0, DFBit = 0
MTU = 1476, IPv6Mtu = 1476
DrvContext[0] = 0xffffffffffffffff, DrvContext[1] = 0xffffffffffffffff
VNHandle = 0x20000040, ADJIndex = 0xfaf3889c
// 隧道接口Tunnel2通知驱动执行Operation 4
*Jun 16 12:51:25:832 2022 Sysname TUNNEL/7/event:
Processing result of operation 4 for Tunnel2: failed.
// 隧道接口Tunnel2下发的Operation 4处理失败
%Jun 16 12:51:25:832 2022 Sysname IFNET/3/PHY_UPDOWN: Physical state on the interface Tunnel2 changed to down.
%Jun 16 12:51:25:832 2022 Sysname IFNET/5/LINK_UPDOWN: Line protocol state on the interface Tunnel2 changed to down.
// 隧道Tunnel2接口down
*Jun 16 12:51:27:350 2022 Sysname TUNNEL/7/event:
Tunnel2 can't come up because there is not enough hardware resource
// 由于硬件资源不足，隧道Tunnel2不能up
当设备打印的如下的event或error信息时，表示硬件是故障导致隧道工作不稳定，此时请联系技术支持。
表1-1 硬件相关的debug信息描述表
|
字段 |
描述 |
|
Tunnelnum can't come up because reason. |
隧道Tunnelnum不能up的原因为reason，reason的取值为there is not enough hardware resource：硬件资源不足 |
|
Failed to save 6RD prefix to DBM. |
向DBM（Database in memory，内存数据库）保存6RD隧道的IPv6前缀失败 |
|
Failed to save IPv4 prefix/suffix for 6RD tunnel to DBM. |
向DBM保存6RD隧道的IPv4前缀/后缀失败 |
|
Failed to save 6RD BR address to DBM. |
向DBM保存6RD隧道的BR地址失败 |
|
Failed to send 6RD prefix to kernel. |
向内核发送隧道的6RD前缀配置消息失败 |
|
Failed to send IPv4 prefix/suffix for 6RD tunnel to kernel. |
向内核发送隧道的6RD IPv4配置消息失败 |
|
Failed to send 6RD BR address to kernel. |
向内核发送隧道的6RD BR地址配置消息失败 |
(6) 如果故障仍未排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!
支持
