Following my previous article on DMVPN phase 1. This time I’m going to configure DMVPN phase 2.
In phase 2, we will be able to dynamically build spoke-to-spoke tunnel.
VPN technologies – DMVPN – Phase 2 – configuration:
The configuration needs to be changed on the spoke routers.
The tunnel mode needs to be set to multiple GRE.
R2(config)#interface Tunnel0 R2(config-if)#no tunnel destination 188.8.131.52 R2(config-if)#tunnel mode gre multipoint
Same goes for R3.
Now, if we ping R3 tunnel0 IP address, we can see that a dynamic tunnel is built between R2 and R3. A traceroute shows that the traffic goes directly between R2 and R3.
R2#ping 10.10.1.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.1.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R2#traceroute 10.10.1.3 Type escape sequence to abort. Tracing the route to 10.10.1.3 VRF info: (vrf in name/id, vrf out name/id) 1 10.10.1.3 1 msec * 2 msecR2#sh dmvpn Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete N - NATed, L - Local, X - No Socket # Ent --> Number of NHRP entries with same NBMA peer NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting UpDn Time --> Up or Down Time for a Tunnel ========================================================================== Interface: Tunnel0, IPv4 NHRP Details Type:Spoke, NHRP Peers:2, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb ----- --------------- --------------- ----- -------- ----- 1 184.108.40.206 10.10.1.1 UP 00:01:12 S 1 220.127.116.11 10.10.1.3 UP 00:00:06 D
If we have a closer look at the EIGRP routing table, we still see that from R2 to reach R3 loopback, the next hope is still set to the DMVPN HUB router. A traceroute to R3 loopback still goes through the DMVPN hub.
R2#sh ip route 192.168.3.3 Routing entry for 192.168.3.3/32 Known via "eigrp 10", distance 90, metric 28288000, type internal Redistributing via eigrp 10 Last update from 10.10.1.1 on Tunnel0, 00:03:37 ago Routing Descriptor Blocks: * 10.10.1.1, from 10.10.1.1, 00:03:37 ago, via Tunnel0 Route metric is 28288000, traffic share count is 1 Total delay is 105000 microseconds, minimum bandwidth is 100 Kbit Reliability 255/255, minimum MTU 1476 bytes Loading 1/255, Hops 2 R2#traceroute 192.168.3.3 Type escape sequence to abort. Tracing the route to 192.168.3.3 VRF info: (vrf in name/id, vrf out name/id) 1 10.10.1.1 1 msec 0 msec 0 msec 2 10.10.1.3 1 msec
To correct this, we need to change the EIGRP configuration on the DMVPN hub.
R1(config-if)#no ip next-hop-self eigrp 10
Now, from R2, we can reach R3 loopback without going via the DMVPN hub. The CEF table shows the next hop is R3 tunnel IP address.
R2#traceroute 192.168.3.3 Type escape sequence to abort. Tracing the route to 192.168.3.3 VRF info: (vrf in name/id, vrf out name/id) 1 10.10.1.3 2 msec * 2 msec R2#sh ip cef 192.168.3.3 192.168.3.3/32 nexthop 10.10.1.3 Tunnel0
The article form INE explain all the reason why the “no ip next-hop-self” command must be used to get this working.
Note that both DMVPN phase 1 and phase 2 are supposed to not be used in production network.
In the next post, we will explore DMVPN phase 3 which is what you want to use for real DMPVN deployment.
Thank you for reading.
Have a look at my previous DMVPN post.
VPN technologies – DMVPN – Phase 2