In this case we place the outside interface G0/2, into VRF DMVPN. This allows the separation of the underlay from the overlay by placing the underlay into a VRF and using a static route the references the VRF to reach the internet. With this in place, any EIGRP learned routes will be in the global routing table and be segregated from the underlay routing.
IOS22
vrf definition DMVPN
rd 1:1
!
address-family ipv4
exit-address-family
!
!
interface GigabitEthernet0/2
vrf forwarding DMVPN
ip address 122.0.0.22 255.255.255.0
!
ip route vrf DMVPN 0.0.0.0 0.0.0.0 122.0.0.1
!
interface Tunnel1
tunnel vrf DMVPN
With the tunnel source now in a VRF, we need to tell the tunnel interface how to reference it. However, we are NOT placing the tunnel into the VRF, the tunnel will still be in the global RIB. This is where the "tunnel vrf DMVPN" command comes into play. It tells the tunnel to look in the vrf DMVPN for the tunnel source. This allows the tunnel to know where to send and receive traffic.
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.24 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.25 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.11 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.24 (Tunnel1) is down: retry limit exceeded
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.25 (Tunnel1) is down: retry limit exceeded
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.11 (Tunnel1) is down: retry limit exceeded
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.25 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.24 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.11 (Tunnel1) is up: new adjacency
The next issue that is seen is the flapping of the EIGRP adjacencies from the spokes. This is because the hub side has changed operationally from the original setup and the spokes need to renegotiate their peerings with the hub. The way to fix this is to bounce the tunnel interfaces of the spokes.
IOS24, IOS25 and CSR11
interface tunnel1
shutdown
no shutdown
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.22 (Tunnel1) is down: holding time expired
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
%LINK-5-CHANGED: Interface Tunnel1, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
%LINK-3-UPDOWN: Interface Tunnel1, changed state to up
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.22 (Tunnel1) is up: new adjacency
On each spoke, the tunnel interface is bounced and comes back online. The way you will realize it's working is if the spoke forms an IGP/BGP peering with the hub, if it's not working, this won't happen, at least in my experience with DMVPN.
IOS22
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.25 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.24 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.11 (Tunnel1) is up: new adjacency
The hub shows 3 new peerings via EIGRP.
IOS22# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 10.1.1.25 Tu1 14 19:28:05 49 1470 0 34
0 10.1.1.11 Tu1 14 19:28:48 41 1470 0 68
1 10.1.1.24 Tu1 13 19:30:10 46 1470 0 61
IOS33#sh ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 9 subnets
D 10.1.1.0
[90/26880256] via 172.16.103.24, 19:37:11, GigabitEthernet0/0
D 10.3.9.0
[90/26880768] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
D 10.3.22.0
[90/26880512] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
D 10.4.9.0
[90/26880768] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
D 10.4.22.0
[90/26880512] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
D 10.11.19.0
[90/28160512] via 172.16.103.24, 19:36:31, GigabitEthernet0/0
D EX 10.102.12.0
[170/28160768] via 172.16.103.24, 19:36:07, GigabitEthernet0/0
D EX 10.102.15.0
[170/28160768] via 172.16.103.24, 19:36:07, GigabitEthernet0/0
D EX 10.102.25.0
[170/28160512] via 172.16.103.24, 19:36:07, GigabitEthernet0/0
19.0.0.0/32 is subnetted, 1 subnets
D 19.19.19.19
[90/28288512] via 172.16.103.24, 19:36:31, GigabitEthernet0/0
20.0.0.0/32 is subnetted, 1 subnets
D EX 20.20.20.20
[170/28288512] via 172.16.103.24, 19:36:07, GigabitEthernet0/0
22.0.0.0/32 is subnetted, 1 subnets
D 22.22.22.22
[90/27008256] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
24.0.0.0/32 is subnetted, 1 subnets
D 24.24.24.24 [90/130816] via 172.16.103.24, 2d21h, GigabitEthernet0/0
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D 172.16.101.0/24
[90/26880768] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
Looking at IOS33, we see that there are new routes showing up in the routing table, new meaning that their time in the RIB is pretty low.
IOS33#traceroute 20.20.20.20 source loopback 0 num
Type escape sequence to abort.
Tracing the route to 20.20.20.20
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.103.24 14 msec 14 msec 11 msec
2 10.1.1.22 34 msec 20 msec 30 msec
3 10.1.1.25 44 msec 62 msec 48 msec
4 20.20.20.20 46 msec 35 msec 34 msec
IOS33#traceroute 20.20.20.20 source loopback 0 num
Type escape sequence to abort.
Tracing the route to 20.20.20.20
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.103.24 22 msec 10 msec 27 msec
2 10.1.1.25 26 msec 21 msec 19 msec
3 20.20.20.20 39 msec 33 msec 24 msec
After a couple traceroutes between the spokes, we find that communication direct to the spoke is working, which means Phase 3 is working.
IOS24#show ip nhrp dynamic
10.1.1.25/32 via 10.1.1.25
Tunnel1 created 00:01:15, expire 01:58:43
Type: dynamic, Flags: router nhop rib
NBMA address: 25.0.0.25
20.20.20.20/32 via 10.1.1.25
Tunnel1 created 00:01:15, expire 01:58:43
Type: dynamic, Flags: router rib nho
NBMA address: 25.0.0.25
33.33.33.33/32 via 10.1.1.24
Tunnel1 created 00:01:15, expire 01:58:44
Type: dynamic, Flags: router unique local
NBMA address: 204.0.0.24
IOS24 proves this as well with the connection point to the tunnel IP of IOS25.
IOS22
vrf definition DMVPN
rd 1:1
!
address-family ipv4
exit-address-family
!
!
interface GigabitEthernet0/2
vrf forwarding DMVPN
ip address 122.0.0.22 255.255.255.0
!
ip route vrf DMVPN 0.0.0.0 0.0.0.0 122.0.0.1
!
interface Tunnel1
tunnel vrf DMVPN
With the tunnel source now in a VRF, we need to tell the tunnel interface how to reference it. However, we are NOT placing the tunnel into the VRF, the tunnel will still be in the global RIB. This is where the "tunnel vrf DMVPN" command comes into play. It tells the tunnel to look in the vrf DMVPN for the tunnel source. This allows the tunnel to know where to send and receive traffic.
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.24 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.25 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.11 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.24 (Tunnel1) is down: retry limit exceeded
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.25 (Tunnel1) is down: retry limit exceeded
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.11 (Tunnel1) is down: retry limit exceeded
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.25 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.24 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.11 (Tunnel1) is up: new adjacency
The next issue that is seen is the flapping of the EIGRP adjacencies from the spokes. This is because the hub side has changed operationally from the original setup and the spokes need to renegotiate their peerings with the hub. The way to fix this is to bounce the tunnel interfaces of the spokes.
IOS24, IOS25 and CSR11
interface tunnel1
shutdown
no shutdown
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.22 (Tunnel1) is down: holding time expired
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
%LINK-5-CHANGED: Interface Tunnel1, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
%LINK-3-UPDOWN: Interface Tunnel1, changed state to up
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.22 (Tunnel1) is up: new adjacency
On each spoke, the tunnel interface is bounced and comes back online. The way you will realize it's working is if the spoke forms an IGP/BGP peering with the hub, if it's not working, this won't happen, at least in my experience with DMVPN.
IOS22
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.25 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.24 (Tunnel1) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.11 (Tunnel1) is up: new adjacency
The hub shows 3 new peerings via EIGRP.
IOS22# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 10.1.1.25 Tu1 14 19:28:05 49 1470 0 34
0 10.1.1.11 Tu1 14 19:28:48 41 1470 0 68
1 10.1.1.24 Tu1 13 19:30:10 46 1470 0 61
IOS33#sh ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 9 subnets
D 10.1.1.0
[90/26880256] via 172.16.103.24, 19:37:11, GigabitEthernet0/0
D 10.3.9.0
[90/26880768] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
D 10.3.22.0
[90/26880512] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
D 10.4.9.0
[90/26880768] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
D 10.4.22.0
[90/26880512] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
D 10.11.19.0
[90/28160512] via 172.16.103.24, 19:36:31, GigabitEthernet0/0
D EX 10.102.12.0
[170/28160768] via 172.16.103.24, 19:36:07, GigabitEthernet0/0
D EX 10.102.15.0
[170/28160768] via 172.16.103.24, 19:36:07, GigabitEthernet0/0
D EX 10.102.25.0
[170/28160512] via 172.16.103.24, 19:36:07, GigabitEthernet0/0
19.0.0.0/32 is subnetted, 1 subnets
D 19.19.19.19
[90/28288512] via 172.16.103.24, 19:36:31, GigabitEthernet0/0
20.0.0.0/32 is subnetted, 1 subnets
D EX 20.20.20.20
[170/28288512] via 172.16.103.24, 19:36:07, GigabitEthernet0/0
22.0.0.0/32 is subnetted, 1 subnets
D 22.22.22.22
[90/27008256] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
24.0.0.0/32 is subnetted, 1 subnets
D 24.24.24.24 [90/130816] via 172.16.103.24, 2d21h, GigabitEthernet0/0
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D 172.16.101.0/24
[90/26880768] via 172.16.103.24, 19:37:09, GigabitEthernet0/0
Looking at IOS33, we see that there are new routes showing up in the routing table, new meaning that their time in the RIB is pretty low.
IOS33#traceroute 20.20.20.20 source loopback 0 num
Type escape sequence to abort.
Tracing the route to 20.20.20.20
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.103.24 14 msec 14 msec 11 msec
2 10.1.1.22 34 msec 20 msec 30 msec
3 10.1.1.25 44 msec 62 msec 48 msec
4 20.20.20.20 46 msec 35 msec 34 msec
IOS33#traceroute 20.20.20.20 source loopback 0 num
Type escape sequence to abort.
Tracing the route to 20.20.20.20
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.103.24 22 msec 10 msec 27 msec
2 10.1.1.25 26 msec 21 msec 19 msec
3 20.20.20.20 39 msec 33 msec 24 msec
After a couple traceroutes between the spokes, we find that communication direct to the spoke is working, which means Phase 3 is working.
IOS24#show ip nhrp dynamic
10.1.1.25/32 via 10.1.1.25
Tunnel1 created 00:01:15, expire 01:58:43
Type: dynamic, Flags: router nhop rib
NBMA address: 25.0.0.25
20.20.20.20/32 via 10.1.1.25
Tunnel1 created 00:01:15, expire 01:58:43
Type: dynamic, Flags: router rib nho
NBMA address: 25.0.0.25
33.33.33.33/32 via 10.1.1.24
Tunnel1 created 00:01:15, expire 01:58:44
Type: dynamic, Flags: router unique local
NBMA address: 204.0.0.24
IOS24 proves this as well with the connection point to the tunnel IP of IOS25.
