DMVPN and how to exclude particular spoke from redirect process

I haven't posted anything on this blog for quite a while, but I got good occasion to write something simple but useful finally because today I was contacted by my former colleague with question. He was searching for advice with DMVPN phase 3 cloud. His issue was with particular spoke that had unreliable ISP and that led to unstable communication with another spokes via dynamic spoke-to-spoke tunnels. Pretty common situation for remote offices located somewhere far far away with lack of good Internet access service.
Actually there are two solutions for this problem. First one is obvious: you can create separate point-to-point tunnel on the hub and affected spoke, but as always that's only one solution and sometimes this is not acceptable for some reasons (e.g. you want to preserve spoke-to-spoke dynamic tunnels only between particular spokes, but not all traffic from affected spoke).
So here is my lab setup to deal with this problem that I did for my friend. Please note there is no common frond-door VRF configuration as should be in real-life scenario, IPSEC profiles or anything else, this is just for demonstration purpose, so there is no need to point me to any DMVPN configuration improvements ;) Router R1 is a hub, router R2, R3 and R4 are spokes and R3 for example is affected spoke with communication problems. From R3 we want it to communicate with another LAN segments only via hub router R1. R4 and R2 should communicate via dynamic tunnel as normal. G0/0 interfaces on this routers are underlay ISP-facing interfaces, G0/1 interfaces are LAN facing interfaces.

 R1 configuration:

 interface GigabitEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 ip ospf 1 area 0
!
interface Tunnel0
 ip address 172.16.0.1 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 ip ospf network broadcast
 ip ospf priority 255
 ip ospf database-filter all out
 ip ospf 1 area 0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
!
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.0
!
router ospf 1
 passive-interface GigabitEthernet0/1

R2 configuration:

 interface GigabitEthernet0/1
 ip address 192.168.2.2 255.255.255.0
 ip ospf 1 area 0
!
interface Tunnel0
 ip address 172.16.0.2 255.255.255.0
 no ip redirects
 ip nhrp network-id 1
 ip nhrp interest 100
 ip nhrp nhs 172.16.0.1 nbma 192.0.2.1 multicast
 ip nhrp shortcut
 ip ospf network broadcast
 ip ospf priority 0
 ip ospf 1 area 0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
!
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.0
!
router ospf 1
 passive-interface GigabitEthernet0/1
!
access-list 100 deny   ip any 192.168.3.0 0.0.0.255
access-list 100 permit ip any any
!
ip route 0.0.0.0 0.0.0.0 172.16.0.1 254

R3 configuration:

 interface GigabitEthernet0/1
 ip address 192.168.3.3 255.255.255.0
 ip ospf 1 area 0
!
interface Tunnel0
 ip address 172.16.0.3 255.255.255.0
 no ip redirects
 ip nhrp network-id 1
 ip nhrp interest none
 ip nhrp nhs 172.16.0.1 nbma 192.0.2.1 multicast
 ip nhrp shortcut
 ip ospf network broadcast
 ip ospf priority 0
 ip ospf 1 area 0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
!
interface GigabitEthernet0/0
 ip address 192.0.2.3 255.255.255.0
!
router ospf 1
 passive-interface GigabitEthernet0/1
!
ip route 0.0.0.0 0.0.0.0 172.16.0.1 254

Also there is R4 router with exactly the same configuration as on R2. It has G0/1 interface configured with address 192.168.4.4 and Tunnel0 interface with 172.16.0.4 address, so configuration of R4 excluded for sake of brevity

Now let's check the behaviour:

R2#traceroute 192.168.3.3 source g0/1 numeric
Type escape sequence to abort.
Tracing the route to 192.168.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.0.1 1 msec 1 msec 1 msec
  2 172.16.0.3 1 msec 1 msec 1 msec

R2#traceroute 192.168.4.4 source g0/1 numeric
Type escape sequence to abort.
Tracing the route to 192.168.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.0.4 1 msec 1 msec 1 msec

R3#traceroute 192.168.2.2 numeric source g0/1
Type escape sequence to abort.
Tracing the route to 192.168.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.0.1 1 msec 1 msec 1 msec
  2 172.16.0.2 1 msec 1 msec 1 msec

R4#traceroute 192.168.2.2 source g0/1 numeric
Type escape sequence to abort.
Tracing the route to 192.168.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.0.2 1 msec 1 msec 1 msec

As you can see, everything works as expected, R2 and R3 communicate via hub while R2 and R4 communicate directly via dynamic tunnel.

So the most valuable but quiet simple parts here are commands "ip nhrp interest none" and  "ip nhrp interest 100". First one is used on affected spoke to actually disable NHRP redirection for any traffic, and the second one is use on any other spoke router to disable redirection for traffic going to LAN subnet of affected spoke. You can follow the link to Cisco Systems IOS documentation for mentioned command: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr/command/ipaddr-cr-book/ipaddr-i4.html#wp3767054477 for more detailed description. If your IOS version doesn't support "ip nhrp interest none", you can use "ip nhrp interest ACL_NAME" with "deny any" ACL to achieve the same behavior. Actually you can use similar approach for DMVPN phase 2 certainly.


Hope that helps somebody.