簡介
本文檔介紹DMVPN第3階段多子網設計中的路由注意事項,以確保正確構建直接分支到分支隧道。
必要條件
需求
思科建議您瞭解以下主題:
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
背景資訊
DMVPN第2階段和第3階段都允許分支裝置建立直接分支到分支隧道,而無需通過集線器。但是,DMVPN第3階段提供了更好的可擴充性,它通過分支的NHRP重定向機制通過NHRP動態發現遠端網路,隨後將NHRP(H)路由安裝到路由表中。這刪除了要求每個分支在其路由表中具有遠端網路的特定網路字首的第2階段限制。在階段3中,來自目標分支(NBMA出口點)的NHRP解決方案回覆必須通過直接分支到分支隧道。但是,必須特別考慮多子網階段3設計,以便可以正確建立分支到分支隧道。本文對這些要求進行了詳細的討論。
問題
DMVPN phase3可以在單子網覆蓋或多子網覆蓋中實施。在單子網重疊拓撲中,中心路由器和所有分支路由器隧道地址均從單個邏輯IP子網中分配;而在多子網設計中,分支到分支隧道需要為處於不同IP子網中的分支而構建,且其隧道地址不同。後者是下圖所示的分層DMVPN設計中使用的常見場景。
DMVPN第3階段多子網拓撲
問題詳細資訊
在DMVPN階段3中,通常可以理解,當收到NHRP解析請求時,目標分支發起到源分支的IPsec隧道,然後通過該隧道傳送解析應答。但是,這僅適用於單個子網重疊的情況。當分支的隧道介面位於不同的IP邏輯子網中時,NHRP控制資料包可以通過分支中心分支路徑進行傳輸,而不是使用直接分支到分支的隧道。以下是Spoke1收到來自Hub1的NHRP重定向後,向Spoke2傳送解析請求時的事件序列:
- Spoke2收到解析請求
*Feb 7 20:57:22.272: NHRP: Receive Resolution Request via Tunnel0 vrf global(0x0), packet size: 144
*Feb 7 20:57:22.272: (F) afn: AF_IP(1), type: IP(800), hop: 252, ver: 1
*Feb 7 20:57:22.272: shtl: 4(NSAP), sstl: 0(NSAP)
*Feb 7 20:57:22.272: pktsz: 144 extoff: 52
*Feb 7 20:57:22.272: (M) flags: "router auth src-stable nat ", reqid: 5
*Feb 7 20:57:22.272: src NBMA: 172.16.1.1
*Feb 7 20:57:22.272: src protocol: 10.0.1.101, dst protocol: 192.168.101.1
*Feb 7 20:57:22.272: (C-1) code: no error(0)
*Feb 7 20:57:22.272: prefix: 32, mtu: 17912, hd_time: 900
*Feb 7 20:57:22.272: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
- Spoke2通過監聽解析請求資料包為10.0.1.101新增一個隱式NHRP快取條目。
- Spoke2為Tunnel0新增了10.0.1.101與Spoke1的NBMA地址的鄰接關係。
- Spoke2使用Resolution Reply進行響應。請注意,此時發出請求的輻條隧道地址的路由指向集線器2:
Spoke2#show ip route 10.0.1.101
Routing entry for 10.0.1.0/24
Known via "eigrp 1", distance 90, metric 3609600, type internal
Redistributing via eigrp 1
Last update from 10.0.2.1 on Tunnel0, 00:17:44 ago
Routing Descriptor Blocks:
* 10.0.2.1, from 10.0.2.1, 00:17:44 ago, via Tunnel0
Route metric is 3609600, traffic share count is 1
Total delay is 41000 microseconds, minimum bandwidth is 1000 Kbit
Reliability 255/255, minimum MTU 1400 bytes
Loading 1/255, Hops 3
Spoke2#
Spoke2#
Spoke2#show ip cef 10.0.1.101
10.0.1.0/24
nexthop 10.0.2.1 Tunnel0
由於NHRP控制資料包沿路由路徑轉發,因此它被傳送到Hub2,而不是傳送到Spoke1的新建立的分支到分支隧道:
*Feb 7 20:57:22.360: NHRP: Send Resolution Reply via Tunnel0 vrf global(0x0), packet size: 172
*Feb 7 20:57:22.360: src: 10.0.2.101, dst: 10.0.1.101
*Feb 7 20:57:22.360: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Feb 7 20:57:22.360: shtl: 4(NSAP), sstl: 0(NSAP)
*Feb 7 20:57:22.360: pktsz: 172 extoff: 60
*Feb 7 20:57:22.360: (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 5
*Feb 7 20:57:22.360: src NBMA: 172.16.1.1
*Feb 7 20:57:22.360: src protocol: 10.0.1.101, dst protocol: 192.168.101.1
*Feb 7 20:57:22.360: (C-1) code: no error(0)
*Feb 7 20:57:22.360: prefix: 24, mtu: 17912, hd_time: 900
*Feb 7 20:57:22.360: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 255
*Feb 7 20:57:22.360: client NBMA: 172.16.2.1
*Feb 7 20:57:22.360: client protocol: 10.0.2.101
*Feb 7 20:57:22.360: NHRP: Encapsulation succeeded. Sending NHRP Control Packet NBMA Address: 172.17.0.5
理論上,只要所有中間集線器都能夠將NHRP控制資料包路由回Spoke1的隧道,那麼一切都必須仍然有效。但情況並非總是如此。如果解析應答無法轉發回Spoke1,則無法建立直接分支到分支隧道。
使用單個子網覆蓋時,這不是問題,因為每個分支都有一條直接連線到隧道網路的路由。這將導致在傳送回解析應答之前對請求分支隧道地址進行鄰接查詢。在多子網重疊網路中,由於分支的隧道地址不在同一個IP子網上,因此不能保證通過直接分支到分支隧道傳送解析應答資料包。
解決方案
對於多子網DMVPN第3階段設計,建議分支具有一個路由條目,指出其需要建立直接分支到分支隧道的任何遠端分支隧道子網的隧道介面。例如:
Spoke2#show run | in ip route
ip route 10.0.101.0 255.255.255.0 Tunnel0
這允許分支嘗試解析請求分支隧道地址的鄰接,然後通過分支將解析應答傳送到分支隧道。
或者,解析回覆可以遍歷輻條中心輻條隧道。在這種情況下,所有中間集線器都必須具有到請求分支隧道子網的路由,以確保NHRP控制資料包可以端到端傳送。
注意:開啟了錯誤增強功能,以探索即使沒有顯式靜態路由,也可以在直接隧道上傳送解決方案應答的選項。思科錯誤ID CSCvo02022 — 增強功能:NHRP必須通過分支向多子網DMVPN的分支通道傳送解決方案應答。
注意:只有註冊的思科客戶端才能訪問內部思科錯誤資訊和工具。
相關資訊