本檔案將概述通用路由封裝(GRE)keepalive的運作方式。
本文檔的讀者應瞭解以下主題:
本文中的資訊係根據以下軟體和硬體版本:
思科7505路由器
支援GRE over IPSec的Cisco IOS®軟體
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路正在作用,請確保您已瞭解任何指令可能造成的影響。
如需文件慣例的詳細資訊,請參閱思科技術提示慣例。
GRE keepalive功能可為通道啟用keepalive介面命令,並允許您為點對點GRE通道設定keepalive。您可以使用keepalive命令以及它的新副檔名來設定keepalive。
GRE通道提供了一種在傳輸協定中封裝任意資料包的方法。此外,它們還提供一個架構,旨在提供實施任何標準點對點封裝方案所需的服務。以下是GRE通道的一些優點:
GRE通道透過單一通訊協定骨幹網提供多通訊協定本地網路。
GRE通道為包含跳數有限的協定的網路提供解決方法。
GRE隧道連線不連續的子網路。
GRE隧道允許跨WAN的VPN。
但是在目前GRE通道的實施中,如果遠端無法連線,則已設定的通道無法關閉任一通道端點的線路通訊協定。因此,從通道傳送的流量是黑洞,且它無法跟隨替代路徑,因為通道總是處於開啟狀態。
對於依賴靜態路由的隧道或聚合路由以查詢通往隧道目標的路由的路由協定而言,情況屬於這種情況。如果控制平面中的資料沿著不同於資料平面中資料的路徑,情況也是如此。
本節通過一個範例提供了通道保持連線機制的功能說明。本節還列出了此功能修改的軟體元素,並討論了這些元素對記憶體和效能的影響。
隧道保持連線機制啟用、擴展和實施用於隧道介面的特定於介面的命令,並提供使隧道的線路協定停用的能力。有關更多資訊,請參見命令和配置部分。
通道存留機制也解決以下額外要求:
即使遠端通道端點不支援keepalive,通道keepalive機制也會運作。
通道keepalive機制產生keepalive。
通道keepalive機制處理keepalive。
即使通道的線路通訊協定關閉,通道keepalive機制也會對遠端的keepalive封包做出回應。
以下是通道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標頭。在標頭末尾,路由器還會附加GRE標頭,其協定型別(PT)為0,沒有其他負載。然後路由器會透過通道傳送封包,導致封包封裝有外部IP標頭,而GRE標頭封裝有IP的PT。隧道keepalive計數器遞增1。如果有到達遠端通道端點的方式,且通道線路通訊協定沒有因為其他原因而關閉,則封包會到達路由器B。然後,將其與隧道0匹配,解除封裝,並轉發到目標IP(隧道源,路由器A)。到達路由器A後,資料包再次解除封裝,並檢查PT。如果PT檢查的結果是0,則表示這是一個keepalive封包。在這種情況下,隧道保持連線計數器重置為0,並且資料包被丟棄。
如果路由器B無法連線,路由器A會繼續建構並傳送keepalive封包以及正常流量。如果線路通訊協定關閉,keepalive不會傳迴路由器A。因此,keepalive計數器會繼續增加。隧道線路協定僅在隧道保持連線計數器保持為零或小於配置值時才會保持開啟。如果條件不成立,則下次嘗試將keepalive傳送到路由器B時,一旦keepalive計數器達到設定的keepalive值,線路協定就會關閉。在開啟/關閉狀態,通道不會轉送或處理除keepalive封包以外的任何流量。為使隧道僅適用於keepalive資料包,隧道必須支援轉發和接收。因此,在所有情況下,隧道查詢演算法都必須成功,並且如果線路協定關閉,必須僅丟棄資料包。收到keepalive封包時,表示通道端點可再次連線。然後,通道保持連線計數器重置為0,且線路協定重新啟用。
該功能對路由器系統記憶體幾乎沒有額外要求,而且效能預計不會受到其新增的影響。Keepalive封包被當作普通封包處理,因此在高流量條件下可能會將其捨棄。現在,您可以更改嘗試處理此問題的次數。如果最終證明這是不夠的,您可以將本地生成的keepalive資料包放入高優先順序隊列中進行傳輸。然後,您可以將IP報頭中的TOS值設定為除預設或配置值之外的更合適的值。
此功能包含在基本IP通道代碼和GRE子系統中。因此,它必須與具有隧道和GRE子系統的基本IP資料包一起提供。
本節僅討論在Cisco錯誤ID CSCuk26449下此功能啟用和擴展的keepalive命令。其他命令分別記錄在Cisco IOS配置指南和命令參考中。[no] keepalive <period> <retries>命令已啟用並使用第二個引數擴展,在Cisco IOS軟體版本12.2(8)T和更新版本中可用。此軟體已根據Cisco錯誤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