对端早挂了GRE隧道还显示Up？华为Keepalive检测把假活揪出来

本文整理自华为官方发布的典型配置案例，命令与步骤均按原始文档呈现，供现场实施参考。

GRE隧道有个先天短板：协议本身不检测链路状态。对端设备宕了、中间链路断了，只要本端Tunnel接口自身没感知到物理故障，接口状态照样显示Up——业务流量还在源源不断地往隧道里灌，对端一个都收不到，全部石沉大海。这种假活状态误事：监控看接口全是绿的，用户投诉说连不上，排查半天才发现对端早就不在了。

华为设备提供GRE Keepalive检测功能，专治这种假活：使能后源端周期发送Keepalive探测报文，同时做不可达计数；对端收到探测报文就回送回应；源端在计数达到重试次数之前收到回应，就认为对端可达并把计数清零——达到次数仍收不到回应，则判定对端不可达，直接关闭隧道连接。接口状态从假活翻成真实的Down，路由随之撤销，流量不再空跑，监控也第一时间变色。

更贴心的是这个功能是单向的：只要一端配置Keepalive，该端就具备检测能力，不要求对端也配——对端收到探测报文，无论自己有没有使能Keepalive，都会回送回应报文。当然，两端都配可以让双方都能感知。

配置就三步。进入系统视图：

system-view

进入Tunnel接口视图：

interface tunnel interface-number

开启Keepalive，周期与重试次数按需指定：

keepalive [ period period [ retry-times retry-times ] ]

三个参数的心里账要算好：period是发送间隔，retry-times是判死前的重试次数，两者相乘大致就是故障判定时间——想快点发现故障就把周期和次数调小，链路偶尔抖动多就适当放宽，避免误判。如果希望在配置隧道策略选择GRE作为VPN隧道前先确认对端可达，这个功能更是必配：没开Keepalive时对端不可达、本端Tunnel口状态也可能为Up，开了之后对端不可达则接口置Down，VPN选路自然绕开这条死隧道。

效果怎么验？正常状态下查看接口状态与Keepalive报文统计，探测与回应计数都在增长；把对端链路断掉，重试次数耗尽后本端Tunnel接口状态翻为Down，路由撤销，业务侧感知到的就是一次干脆的故障，而不是长时间的黑洞丢包。

隧道建得再漂亮，感知不到对端死活都是空中楼阁。给客户交付GRE组网时，Keepalive值得列为默认配置项，配套的故障判定时间按业务能容忍的中断时长反推，让发现故障这个动作本身就带上业务视角。欢迎搜索关注贵州诚鑫致达科技，了解更多隧道组网实战配置。