Lab Introduction This lab tests point-to-multipoint (P2MP) OPSF with DMVPN phase 3 to enable spoke-to-spoke traffic and understand how OSPF metric/cos
This lab tests point-to-multipoint (P2MP) OPSF with DMVPN phase 3 to enable spoke-to-spoke traffic and understand how OSPF metric/cost works in point-to-multipoint scenario.
I use C7200 15.2(4) M6 (IOS: c7200-adventerprisek9-mz.152-4.M6.bin) as router on GNS3. Please note:
- Not all C7200 IOS support DMVPN Phase 3 with GNS3. For example, when I used later version 15.2(4) S7 (IOS: c7200-adventerprisek9-mz.152-4.S7.bin), it says ‘ip nhrp redirect’ failed to initialize.
- CSR1000v (IOS-XE) supports DMVPN Phase 3 with GNS3; however, it shows some different results in terms of troubleshooting. It should be ideal to use CSR1000v if RAM is not an issue.
- Crypto is not configured to protect tunnels in this lab for simplicity.
Lab topology is as below:
G1/0 : 18.104.22.168/24 (global routing instance)
Tunnel 101: 172.16.1.101/24 (global routing instance), OSPF 1 area 0
Lo 1: 10.66.1.101/24 (global routing instance), OSPF 1 area 1
G1/0 : 22.214.171.124/24 (global routing instance)
Tunnel 101: 172.16.1.102/24 (GREEN_IVRF), OSPF 1 area 0, cost 1001
Lo 1: 10.66.2.102/24 (GREEN_IVRF), OSPF 1 area 1
G1/0 : 126.96.36.199/24 (global routing instance)
Tunnel 101: 172.16.1.103/24 (GREEN_IVRF), OPSF 1 area 0
Lo 1: 10.66.3.103/24 (GREEN_IVRF), OSPF 1 area 1
G1/0 : 188.8.131.52/24 (global routing instance)
Tunnel 101: 172.16.1.104/24 (GREEN_IVRF), OSPF 1 area 0
Lo 1: 10.66.4.104/24 (GREEN_IVRF), OSPF 1 area 1
Verification 1 – show ip route
If we ‘show ip route’ on SPOKE1_1 and SPOKE1_2, spoke-to-spoke route appears traversing via HUB and with dual-trip metric (SPOKE1_1 to HUB1_1 to SPOKE1_2). Please note ‘10.66.4.104/32 [110/2001]’. Is the spoke-to-spoke direct tunnel really working?
Verification 2 – ‘show ip nhrp’ and ‘show dmvpn’
Before issuing any traffic, we execute ‘show ip nhrp’ on SPOKEs. It only shows nhrp entries to hubs.
However, when we ping from SPOKE1_2 to SPOKE1_1 lo1 address ‘ping vrf GREEN_IVRF 10.66.3.103’; SPOKE1_1 receives NHRP entries to SPOKE1_2 as dynamic type (172.16.1.104/32 via 172.16.1.104). Please also note ‘flags: router used’, which indicates spoke-to-spoke tunnel as temporary not ‘never expire’.
SPOKE1_2 also receives NHRP entries to SPOKE1_1 as dynamic type (172.16.1.103/32 via 172.16.1.103).
‘show dmvpn detail’ also demonstrates spoke-to-spoke dynamic tunnel.
One HUB1_1, we also see nhrp redirect information as below:
Verification 3 – debug nhrp
Let’s have a detailed look on what exactly happened on HUB1_1, SPOKE1_1 and SPOKE1_2 by ‘debug nhrp’.
HUB1_1: provides SPOKE physical WAN-facing IP to allow dynamic tunnel to be established between SPOKEs.
SPOKE1_2 adds SPOKE1_1 tunnel endpoint (172.16.1.103) as NHRP entry and sends packet via 172.16.1.103 directly. When no traffic traversing SPOKE1_1 and SPOKE1_2, the dynamic spoke-to-spoke tunnel will be deleted.
SPOKE 1_1 also adds SPOKE1_2 tunnel endpoint (172.16.1.104) as NHRP entry and sends packet via 172.16.1.104 directly.
Verification 4 – traceroute
Traceroute result is interesting. When first time traceroute, the traffic traverses via HUB; however, traffic directly goes through SPOKE when tried second time after the dynamic spoke-to-spoke tunnel established.
When traffic going through spoke-to-spoke directly. Do a quick ‘show ip route’. 2 records are marked with % now. % means ‘next hop override’. Traffic to SPOKE1_2’s loopback 10.66.4.104 had HUB1_1’s tunnel IP (172.16.1.101) as next-hop according to the routing table; however, the next-hop is now overridden by SPOKE1_2’s tunnel IP (172.16.1.104). The traffic will now take 172.16.1.104 as next hop to reach 10.66.4.104 with OSPF metric 2001.
Verification 5 – OSPF neighbor
SPOKEs only form OPSF neighbor with HUBs, but not other SPOKEs.
Other Useful Commands
Clear ip nhrp
Show ip nhrp nhs
Show ip nhrp nhs redundancy
1) SPOKEs only form routing neighbors with HUBs, but not other SPOKEs.
2) SPOKE to SPOKE OSPF routing metric is calculated as if traffic traversing HUB; i.e. SPOKE1_1 to SPOKE1_2 metric = 1000+1000 = 2000. When spoke-to-spoke traffic initiates, routing metric stays same but next-hop is overriden to spoke.
3) When spoke-to-spoke traffic initiates, HUB will redirect traffic to spoke and provide spoke WAN-facing physical interface IP. Dynamic tunnel between SPOKE1_1 and SPOKE1_2 will established based on information provided by HUB. When spoke-to-spoke traffic ends, the dynamic tunnel will be terminated.