DMVPN PHASE 3 Theory
Continuing on , let’s see the basic difference between Phase 3 and Phase 2 in theory first.
Phase 2 DMVPN packet forwarding is being done using IP routing table, all next-hop info is copied into the FIB and used for packet forwarding. Spokes reach other spokes networks based on the next-hop tunnel ip address of the other spoke for particular network.
Phase 3 uses NHRP redirect cache which does not necessarily use next-hop info from FIB (FIB copied it from routing table), instead NHRP can dynamically override the entries in the FIB table and insert it’s own next-hop information. This allows direct spoke-to-spoke traffic because the HUB tells the spokes what to do and where to send the traffic. Spokes don’t even need routes, they can use default gateway towards the hub router.
Phase 3 is more scalable and used in more robust DMVPN designs. It also allows the summarization of routes from hub to spokes. So again spokes wouldn’t need specific routes to other spokes networks.
DMVPN PHASE 3 Configuration
IP addressing is done as per diagram.
The command difference is not big, only two commands need to be inserted to make the implementation Phase 3.
Let’s start off on the hub:
HUB Phase 3
1
2
3
4
5
6
7
8
9
10
11
12
csr1_hub1(config)# interface Tunnel0
csr1_hub1(config-if)# ip address 10.1.1.1 255.255.255.0
csr1_hub1(config-if)# tunnel source GigabitEthernet1
csr1_hub1(config-if)# tunnel mode gre multipoint
csr1_hub1(config-if)# ip nhrp authentication test
csr1_hub1(config-if)# ip nhrp network-id 100
csr1_hub1(config-if)# ip nhrp map multicast dynamic
csr1_hub1(config-if)# tunnel key 100
csr1_hub1(config-if)# ip mtu 1400
csr1_hub1(config-if)# ip tcp adjust-mss 1360
csr1_hub1(config-if)# ip nhrp redirect
csr1_hub1(config-if)# tunnel protection ipsec profile IPSEC_PROFILE
On the Hub we need to insert ip nhrp redirect which basically does the job of redirecting spoke-to-spoke traffic, once one spoke initiates the traffic there’s detailed NHRP messages being sent between the hub and spoke, and HUB tell’s the spoke where to send the traffic. Once the Spoke learns that information it doesn’t need to prompt Hub again for the same information. I won’t go into details for those messages but later we will see the debug output later on.
There’s one more thing we need to do on the HUB. We need to remove the no next-hop-self command for EIGRP which we needed to add in the case of Phase2. And we need to bring back the next-hop-self
Since Phase2 uses strictly routing table information, we needed to strip the eigrp next-hop from the routing updates otherwise spokes wouldn’t receive the proper next-hop to other spokes networks.
But in case of Phase3 spokes need to be pointing to the hub, because we are not relying strictly on our routing table to form tunnels with spokes, the HUB does the redirecting for us, and NHRP can override entries in the routing table which we will see later on.
1
2
3
4
csr1_hub1(config)#router eigrp DMVPN
csr1_hub1(config-router)#address-family ipv4 unicast autonomous-system 1
csr1_hub1(config-router-af)#af-interface Tunnel0
csr1_hub1(config-router-af-interface)#next-hop-self
Let’s verify that spokes are pointing to the HUB instead of the other spokes tunnel end ip.
1
2
3
4
5
6
csr3_spoke1#show ip route | b Gateway
***outpute ommited***
D 192.168.1.0/24 [90/76800640] via 10.1.1.1, 01:59:13, Tunnel0
D 192.168.4.0/24 [90/102400640] via 10.1.1.1, 01:58:12, Tunnel0
D 172.16.1.0 [90/79365120] via 10.1.1.1, 00:01:02, Tunnel0
D 172.16.2.0 [90/79365120] via 10.1.1.1, 00:01:02, Tunnel0
We can see that they are pointing to the HUB’s tunnel ip 10.1.1.1.
Spoke Phase 3
On spoke we need to add only one command and that is ip nhrp shortcut. It tells the spokes to accept the redirect messages from the HUB and install the shortcut route. Ill show only one spoke, the other is the same config.
1
2
3
4
5
6
7
8
9
10
11
12
csr3_spoke1(config)#interface tunnel0
csr3_spoke1(config-if)# ip address 10.1.1.3 255.255.255.0
csr3_spoke1(config-if)# tunnel source GigabitEthernet3
csr3_spoke1(config-if)# tunnel mode gre multipoint
csr3_spoke1(config-if)# ip nhrp nhs 10.1.1.1 nbma 10.0.0.1 multicast
csr3_spoke1(config-if)# ip nhrp shortcut
csr3_spoke1(config-if)# ip nhrp authentication test
csr3_spoke1(config-if)# ip mtu 1400
csr3_spoke1(config-if)# ip tcp adjust-mss 1360
csr3_spoke1(config-if)# tunnel key 100
csr3_spoke1(config-if)# ip nhrp network-id 100
csr3_spoke1(config-if)# tunnel protection ipsec profile IPSEC_PROFILE
Verification and testing
Now let’s see what happens when we initiate the traffic from Spoke1 to Spoke2, but first i will turn on debugging for nhrp packets on spokes and hub by using command debug nhrp packet
1
2
3
csr3_spoke1#traceroute 192.168.4.1 source l0
1 10.1.1.1 61 msec 10 msec 12 msec
2 10.1.1.4 43 msec
Traffic is going through the Hub. Let’s see the debug outputs:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
csr1_hub1#
*Mar 19 16:22:16.676: NHRP: Receive Resolution Request via Tunnel0 vrf global(0x0), packet size: 84
*Mar 19 16:22:16.676: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Mar 19 16:22:16.676: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 19 16:22:16.676: pktsz: 84 extoff: 52
*Mar 19 16:22:16.677: (M) flags: "router auth src-stable nat ", reqid: 8
*Mar 19 16:22:16.677: src NBMA: 30.0.0.1
*Mar 19 16:22:16.677: src protocol: 10.1.1.3, dst protocol: 192.168.4.1
csr3_spoke1#
*Mar 19 16:22:34.563: (M) flags: "unique nat ", reqid: 24
*Mar 19 16:22:34.563: src NBMA: 30.0.0.1
*Mar 19 16:22:34.563: src protocol: 10.1.1.3, dst protocol: 10.1.1.2
*Mar 19 16:22:34.564: (C-1) code: no error(0)
*Mar 19 16:22:34.564: prefix: 32, mtu: 9972, hd_time: 7200
*Mar 19 16:22:34.564: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
*Mar 19 16:22:34.577: NHRP: Receive Registration Reply via Tunnel0 vrf gl
csr4_spoke2#
NHRP: Receive Resolution Request via Tunnel0 vrf global(0x0), packet size: 104
*Mar 19 16:22:16.661: (F) afn: AF_IP(1), type: IP(800), hop: 254, ver: 1
*Mar 19 16:22:16.661: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 19 16:22:16.661: pktsz: 104 extoff: 52
*Mar 19 16:22:16.661: (M) flags: "router auth src-stable nat ", reqid: 8
*Mar 19 16:22:16.661: src NBMA: 30.0.0.1
*Mar 19 16:22:16.661: src protocol: 10.1.1.3, dst protocol: 192.168.4.1
*Mar 19 16:22:16.661: (C-1) code: no erro
There’s many messages in the debug but we can see from those that HUB received resolution request and then it contacted Spoke2 (192.168.4.1) letting it know about Spoke1 initiation request to connect, that way both spokes receive the way to connect to each other’s tunnel ip address and form a tunnel.
After the tunnel was created, we don’t need to contact Hub again, so let’s do traceroute again:
1
2
3
csr3_spoke1#traceroute 192.168.4.1 source l0 numeric
Tracing the route to 192.168.4.1
1 10.1.1.4 47 msec
As we can see, now we are skipping the hub and going directly to spoke2 via tunnel we formed dynamically.
Let’s verify the DMVPN tunnel and check the NHRP table:
1
2
3
4
5
6
7
8
9
csr3_spoke1#show dmvpn
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 10.0.0.1 10.1.1.1 UP 02:44:36 S
2 40.0.0.1 10.1.1.4 UP 00:13:15 DT1
10.1.1.4 UP 00:13:15 DT2
DT1 means that route through the overlay tunnel is installed (10.1.1.4). DT2 means that the next-hop was overriden to target network.
Let’s check the NHRP table to see what does that mean:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
csr3_spoke1#show ip nhrp
***rest of output ommited***
10.1.1.4/32 via 10.1.1.4
Tunnel0 created 00:23:11, expire 01:36:48
Type: dynamic, Flags: router nhop rib
NBMA address: 40.0.0.1
192.168.3.0/24 via 10.1.1.3
Tunnel0 created 00:23:10, expire 01:36:49
Type: dynamic, Flags: router unique local
NBMA address: 30.0.0.1
(no-socket)
192.168.4.0/24 via 10.1.1.4
Tunnel0 created 00:23:10, expire 01:36:48
Type: dynamic, Flags: router rib nho
NBMA address: 40.0.0.1
Notice the router nhop rib for 10.1.1.4 tunnel-ip. That indicates that the router has explicit method to reach that Tunnel IP address using an NBMA address and has associated route installed in the routing table. This corresponds to the DT1 flag from show dmvpn output.
The other flag rib nho for network 192.168.4.0/24 indicates that the router already has the same route in the routing table and that it belongs to a different protocol (EIGRP in our case). NHRP has overridden that protocol’s next-hop entry for the network 192.168.4.0/24 by installing a next-hop shortcut in routing table. And this is what corresponds to the DT2 flag we mentioned earlier from show dmvpn output.
And finally to make this clear let’s check the routing table on Spoke1:
1
2
3
4
5
6
7
8
csr3_spoke1#show ip route
Gateway of last resort is 30.0.0.2 to network 0.0.0.0
H 10.1.1.4/32 is directly connected, 00:18:57, Tunnel0
D 50.0.0.0 [90/76805120] via 10.1.1.1, 00:39:59, Tunnel0
D 172.16.1.0 [90/79365120] via 10.1.1.1, 00:39:45, Tunnel0
D 172.16.2.0 [90/79365120] via 10.1.1.1, 00:39:45, Tunnel0
D 192.168.1.0/24 [90/76800640] via 10.1.1.1, 02:50:15, Tunnel0
D % 192.168.4.0/24 [90/102400640] via 10.1.1.1, 02:49:14, Tunnel0
Notice the H flag for the Tunnel IP of Spoke2 (10.1.1.4). Means NHRP installed the route.
Also notice % flag for 192.168.4.0/24 network which sits behind 10.1.1.4. Means NHRP has overriden the next-hop IP and made it 10.1.1.4 as you can see previously in the NHRP show command.
One more verification with CEF:
1
2
3
csr3_spoke1#show ip cef 192.168.4.0
192.168.4.0/24
nexthop 10.1.1.4 Tunnel0
Phase3 behaves the same when you only have default gateway to Hub. Except it won’t have anything to override and it will just install the route to the Tunnel IP of other spoke. It will be flagged as “H” in the routing table instead of “%”. You can test this by advertising only eigrp default gateway to the spokes,and supress all other routes.
IPsec stayed the same as in Phase2 so i won’t go into that again.
Hope it has been informative, and thank you for reading!