10-07-2014 12:48 PM - edited 03-04-2019 11:55 PM
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
Solved! Go to Solution.
10-09-2014 06:44 AM
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.
10-08-2014 07:32 AM
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.
10-09-2014 06:44 AM
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.
10-09-2014 06:44 AM
Thanks this seems to work in a lab, ill consider the solution more closely before rolling it out in production
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide