本文档概述了通用路由封装(GRE)keepalive如何工作。
本文档的读者应掌握以下这些主题的相关知识:
本文档中的信息基于以下软件和硬件版本:
Cisco 7505 路由器
支持GRE over IPSec的Cisco IOS®软件
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。
有关文件规则的更多信息请参见“ Cisco技术提示规则”。
GRE保活功能为隧道启用keepalive 接口命令,并允许您为点对点GRE隧道配置保活。您可以使用keepalive命令配置keepalive,或者使用其新扩展配置keepalive。
GRE隧道提供了一种将任意数据包封装在传输协议内的方法。它们还提供一种架构,旨在提供实施任何标准点对点封装方案所需的服务。以下是GRE隧道的一些优势:
GRE隧道通过单协议主干提供多协议本地网络。
GRE隧道为包含跳数有限的协议的网络提供解决方法。
GRE隧道连接不连续的子网络。
GRE隧道允许VPN跨WAN。
但是,在GRE隧道的当前实施中,如果远端不可达,配置的隧道将无法关闭任一隧道终端的线路协议。因此,从隧道发送的流量会黑洞,并且由于隧道始终处于工作状态,因此它无法遵循备用路径。
这种情况适用于依赖静态路由的隧道或汇聚路由以查找通往隧道目的地的路由的路由协议。在控制平面中的数据与数据平面中的数据遵循不同路径的情况下,也是如此。
本部分通过示例提供隧道保持连接机制的功能说明。本节还列出此功能修改的软件元素,并讨论对内存和性能的影响。
隧道保持连接机制为隧道接口启用、扩展和实施特定于接口的命令,并提供关闭隧道线路协议的功能。有关详细信息,请参阅命令和配置部分。
隧道保持连接机制还可满足以下额外要求:
即使远隧道终端不支持keepalive,隧道保持连接机制也会运行。
隧道保持连接机制发起保持连接。
隧道保持连接机制处理保持连接。
隧道保持连接机制响应远端的保持连接数据包,即使隧道的线路协议关闭。
以下是隧道保持连接机制如何工作的示例(请参见图1):
图1 — 隧道保持连接机制示例
输出
interface tunnel 0 interface tunnel 0 ip address 1.1.1.1 255.255.255.240 ip address 1.1.1.2 255.255.255.240 tunnel source 128.8.8.8 tunnel source 129.9.9.9 tunnel destination 129.9.9.9 tunnel destination 128.8.8.8 keepalive 5 4 keepalive 5 4 interface loopback 0 interface loopback 0 ip address 128.8.8.8 255.255.255.255 ip address 129.9.9.9 255.255.255.255
源自A到B的keepalive数据包
---outer IP header---' ---inner IP header---' ============================================================= |IP | IP src | IP dst | GRE | IP | IP src | IP dst | GRE | | |128.8.8.8|129.9.9.9|PT=IP| |129.9.9.9|128.8.8.8| PT=0| ============================================================= ----' ---' GRE header GRE header
在路由器A的隧道终端上启用keepalive时,路由器会以每个间隔构建内部IP报头。在报头的末尾,路由器还会附加一个协议类型(PT)为0且没有其他负载的GRE报头。然后,路由器通过隧道发送该数据包,这会导致其封装为外部IP报头,而GRE报头的PT为IP。隧道保持连接计数器的增量为1。如果有到达远端隧道终端的方法,并且隧道线路协议由于其他原因没有关闭,则数据包会到达路由器B。然后,它与隧道0匹配,解封,并转发到目的IP,即隧道源路由器A。到达路由器A后,数据包再次解封,并检查PT。如果PT检查的结果为0,则表示这是保持连接数据包。在这种情况下,隧道保持连接计数器重置为0,并丢弃数据包。
如果路由器B无法到达,路由器A会继续构建和发送keepalive数据包以及正常流量。如果线路协议关闭,keepalive不会返回到路由器A。因此,keepalive计数器继续增加。只要隧道保持连接计数器保持零或小于配置值,隧道线路协议才会保持运行。如果该条件不正确,则下次尝试向路由器B发送保持连接时,只要保持连接计数器达到已配置的保持连接值,线路协议就会关闭。在up/down状态下,隧道不转发或处理除keepalive数据包以外的任何流量。要使此功能仅用于keepalive数据包,隧道必须是转发和接收友好的。因此,隧道查找算法在所有情况下都必须成功,并且在线路协议关闭时必须仅丢弃数据包。当收到keepalive数据包时,它表示隧道终端再次可达。然后,隧道保持连接计数器重置为0,线路协议恢复。
该功能几乎不会对路由器系统内存产生额外需求,而且性能预计不会受其添加的影响。保持连接数据包被视为普通数据包,因此在高流量条件下,它们可能会被丢弃。目前,您可以更改处理此问题的重试次数。如果这最终证明不足,您可以将本地生成的保持连接数据包放入高优先级队列中进行传输。然后,您可以将IP报头中的TOS值设置为比默认值或配置值更合适的值。
该功能包含在基本IP隧道代码和GRE子系统中。因此,它必须与具有隧道和GRE子系统的基本IP包一起使用。
本节仅在Cisco Bug ID CSCuk26449下介绍此功能启用和扩展的keepalive命令。其他命令记录在相应的Cisco IOS配置指南和命令参考中。[no] keepalive <period> <retries>命令已启用并扩展,并带有第二个参数,在Cisco IOS软件版本12.2(8)T及更高版本中可用。它也在Cisco Bug ID CSCuk29980和CSCuk29983(仅限注册用户)下移植到Cisco IOS软件版本12.1E和12.2S。
由于keepalive 是在隧道接口上启用keepalive的接口配置命令,因此当前仅支持GRE/IP模式的keepalive。命令的第二个参数(retries)可见,且仅对隧道接口可用。第一个参数的值范围为1到32767。当值为0时,它相当于“no keepalive”。 此参数的默认值为10。第二个参数的值范围为1到255,它指示已发送但未返回的keepalive数量,然后隧道接口将线路协议断开。默认情况下,隧道接口上的Keepalive处于禁用状态。
本节提供示例输出。
cisco-7505#configure terminal Enter configuration commands, one per line. End with CNTL/Z. cisco-7505(config)#interface tunnel 1 cisco-7505(config-if)#? access-expression Build a bridge boolean access expression …………… keepalive Enable keepalive <===== …………… timeout Define timeout values for this interface cisco-7505(config-if)#keepalive ? <===== <0-32767> Keepalive period (default 10 seconds) cisco-7505(config-if)#keepalive 5 ? <===== <1-255> Keepalive retries (default 3 times) cisco-7505(config-if)#keepalive 5 4 <===== cisco-7505(config-if)#end cisco-7505#show interfaces tunnel 1 Tunnel1 is up, line protocol is up Hardware is Tunnel Internet address is 10.1.1.1/24 MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (5 sec), retries 4 <===== Tunnel source 9.2.2.1, destination 6.6.6.2 Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Tunnel TOS 0xF, Tunnel TTL 128 Checksumming of packets disabled, fast tunneling enabled Last input never, output 00:57:05, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/0, 1 drops; input queue 0/75, 0 drops 30 second input rate 0 bits/sec, 0 packets/sec 30 second output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 3 packets output, 1860 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out