GRE隧道被设计为完全无状态的。这意味着每个隧道端点都没有远端的状态或可用性的信息。因此即使是隧道的远端不可达，本地隧道端路由器也不会关闭GRE隧道接口。

　　如果没有配置GRE keepalives，只有在三种情况下GRE隧道会关闭：
1、没有到达隧道目标地址的路由；
2、充当隧道源的接口被关闭；
3、隧道的目标地址是本地隧道接口的地址。

　　注：GRE隧道接口不配置接口地址也是UP的，但指向隧道接口的路由不会被放入路由表。

　　从Cisco IOS12.2(8)T开始，可以在点到点的GRE隧道接口上配置keepalives。如果有一段时间里没有收到keepalives，隧道接口就会被自动关闭。

　　GRE隧道的keepalive机制比较特别。它能从隧道的一端向远端路由器发送keepalives和从远端路由器接收keepalives，即使是远端路由器不支持GRE keepalive。GRE隧道的keepalives的另一特性是隧道两端的keepalives的timers不需要一致。

　　如果只在隧道的一端配置了keepalives，那么当链路中断时，只有配置了keepalives的一端会自动关闭隧道接口，而另一端仍然保持UP状态。

　　下图说明了GRE keepalives的工作过程：


当Router B不可达时，Router A会按指定的周期和重试次数来向Router B发送keepalive包。超过重试次数后，隧道接口就会关闭。

　　隧道接口关闭后，隧道就停止发送和处理任何的数据流。但是它仍在继续发送keepalive包，一旦收到响应，隧道keepalive计数器就会重置为0，然后隧道接口重新激活。

　　配置方式：在隧道接口的配置模式下，输入keepalive [seconds [retries]];　默认是每10秒发一次keepalive包，重试3次。

Ex.

R1:
!
interface Tunnel0
ip address 10.10.10.1 255.255.255.0
keepalive 4 3
tunnel source Serial2/0
tunnel destination 10.244.23.2

ip route 3.3.3.0 255.255.255.0 Tunnel0

R2:
!
interface Tunnel0
ip unnumbered Serial2/0
keepalive 5 4
tunnel source Serial2/0
tunnel destination 10.244.12.1

ip route 1.1.1.0 255.255.255.0 Tunnel0

 

If there is an inbound ACL on the GRE tunnel interface, it must permit the return GRE tunnel keepalive packet

(access-list <number> permit gre host <tunnel-source> host <tunnel-destination>).

正常的情况：
*Jun 6 17:09:49.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:09:49.307: Tunnel0 count tx, adding 24 encap bytes
*Jun 6 17:09:49.355: Tunnel0: GRE/IP to decaps 10.244.12.1->10.244.23.2 (len=24 ttl=252)
*Jun 6 17:09:54.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:09:54.307: Tunnel0 count tx, adding 24 encap bytes
*Jun 6 17:09:54.335: Tunnel0: GRE/IP to decaps 10.244.12.1->10.244.23.2 (len=24 ttl=252)
*Jun 6 17:09:59.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:09:59.307: Tunnel0 count tx, adding 24 encap bytes
*Jun 6 17:09:59.335: Tunnel0: GRE/IP to decaps 10.244.12.1->10.244.23.2 (len=24 ttl=252)

链路中断后：

*Jun 6 17:13:04.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:13:04.307: Tunnel0 count tx, adding 24 encap bytes
*Jun 6 17:13:09.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:13:09.307: Tunnel0 count tx, adding 24 encap bytes
*Jun 6 17:13:14.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:13:14.307: Tunnel0 count tx, adding 24 encap bytes
*Jun 6 17:13:19.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:13:19.307: Tunnel0 count tx, adding 24 encap bytes
*Jun 6 17:13:24.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:13:24.307: Tunnel0 count tx, adding 24 encap bytes

*Jun 6 17:13:29.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:13:29.307: Tunnel0 count tx, adding 24 encap bytes

链路恢复：

*Jun 6 17:13:29.467: Tunnel0: GRE/IP to decaps 10.244.12.1->10.244.23.2 (len=24 ttl=252)
*Jun 6 17:13:30.415: Tunnel0: GRE/IP classify 10.244.12.1->10.244.23.2 failed, tunnel down
*Jun 6 17:13:30.419: Tunnel0: GRE/IP to decaps 10.244.12.1->10.244.23.2 (len=76 ttl=253)
*Jun 6 17:13:34.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:13:34.307: Tunnel0 count tx, adding 24 encap bytes
*Jun 6 17:13:34.323: Tunnel0: GRE/IP to decaps 10.244.12.1->10.244.23.2 (len=24 ttl=252)
*Jun 6 17:13:35.303: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
*Jun 6 17:13:39.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:13:39.307: Tunnel0 count tx, adding 24 encap bytes
*Jun 6 17:13:39.387: Tunnel0: GRE/IP to decaps 10.244.12.1->10.244.23.2 (len=24 ttl=252)
*Jun 6 17:13:44.303: Tunnel0: GRE/IP encapsulated 10.244.23.2->10.244.12.1 (linktype=7, len=48)
*Jun 6 17:13:44.307: Tunnel0 count tx, adding 24 encap bytes