DMVPN Default Gateway issue

[Darren Hunter]

Hi,

I may be a million miles off but i'm trying to route all traffic at our spoke sites through to our hub site and subsequently through a firewall etc. so I obviously need the gateway to change when a dmvpn is established. I am considering using policy based routing to pickup internal traffic and change the next hop to the hub site. However how will this affect the spoke to spoke routing of the dmvpn? will nhrp take precedence over the PBR to ensure that spoke to spoke communication happens directly?

thanks

[ghostinthenet]

It would be worth labbing out this scenario to see how PBR impacts the NHRP shortcut switching. I would think that there would be a conflict because PBR overrides the routing table and would make the shortcut routes non-functional, but I would test it before standing on that.

Another solution is to separate out the internal traffic using VRF Lite and terminate the tunnels and the DMVPN routing processes on the internal VRF. This way, the router maintains the local Internet default gateway for its own operations, but the internal network receives a default route from the DMVPN hub router and preserves NHRP shortcut switching.

[ghostinthenet · Accepted solution]

Just to follow up, here's a sample configuration of what I'm talking about for the spoke.

ip vrf VRF_LAN
!
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 2
crypto isakmp key {pre-shared-key} address 0.0.0.0 0.0.0.0 no-xauth
!
!
crypto ipsec transform-set IPSec_TS_AES256SHA1ESP_T esp-aes 256 esp-sha-hmac 
 mode transport
!
crypto ipsec profile IPSec_Profile_VPN
 set transform-set IPSec_TS_AES256SHA1ESP_T
!
!
interface Tunnel0
 ip vrf forwarding VRF_LAN
 ip address 172.31.255.10 255.255.255.0
 ip nhrp authentication 31240
 ip nhrp map 172.31.255.1 x.x.x.x
 ip nhrp map multicast x.x.x.x
 ip nhrp network-id 31240
 ip nhrp holdtime 600
 ip nhrp nhs 172.31.255.1
 ip nhrp shortcut
 ip nhrp redirect
 cdp enable
 tunnel source FastEthernet0/1
 tunnel mode gre multipoint
 tunnel protection ipsec profile IPSec_Profile_VPN
!
interface FastEthernet0/0
 ip vrf forwarding VRF_LAN
 ip address 172.31.128.1 255.255.255.0
!
interface FastEthernet0/1
 ip address dhcp
!
router eigrp 1
 passive-interface default
 no passive-interface Tunnel0
 no auto-summary
 !
 address-family ipv4 vrf VRF_LAN
  network 172.31.128.1.0 0.0.0.0.0
  network 172.31.255.10.0 0.0.0.0.0
  no auto-summary
  autonomous-system 1
  eigrp router-id 172.31.255.10
  eigrp stub connected summary
 exit-address-family

As you can see, this works almost identically to a standard DMVPN setup, except that the tunnel interface, the LAN (FastEthernet0/0) interface and EIGRP processes all run in the VRF_LAN virtual routing and forwarding instance.

The primary routing table gets its default route from DHCP in this case, though it could just as easily be static. The VRF, on the other hand, gets a default route from the DMVPN hub and shortcut switches for spoke-to-spoke communications. At no point does the default route in the global routing table factor into the DMVPN network's routing table or vice versa, eliminating the need for PBR entirely.

[Darren Hunter]

Thanks this seems to work in a lab, ill consider the solution more closely before rolling it out in production