- Trump taps Sriram Krishnan for AI advisor role amid strategic shift in tech policy
- 5 network automation startups to watch
- 4 Security Controls Keeping Up with the Evolution of IT Environments
- ICO Warns of Festive Mobile Phone Privacy Snafu
- La colaboración entre Seguridad y FinOps puede generar beneficios ocultos en la nube
DMVPN as a Redundant Network Solution
DMVPN as a Redundant Network Solution
Recently I redesigned a network to take advantage of DMVPN. This customer had the need for high availability between their main office and branches with the advent of cloud-based applications that their organization used. For instance, they needed the branch to be able to connect back to the main office if their MPLS connection failed as well as failover Internet connectivity through the MPLS network in the event that the branch’s Internet provider experienced a failure. And it all needed to failover and fail back seemlessly. It seems like a tall order, but with DMVPN and IP SLA it’s really not. Read on…
DMVPN is short for Dynamic Multipoint VPN and is ideally positioned in a hub and spoke design. The main office is the hub and the branches are the spokes. DMVPN supports the branches having dynamically assigned addresses (site-to-site VPN does not) and supports the branches communicating directly with each other instead of via more site-to-site VPN tunnels (could you imagine the headache of full-mesh VPN tunnels?). It is so choice, if you have the means I highly recommend it. And intriguingly enough, you’ll need a Cisco router with the appropriate Security license level to support this; Cisco ASAs do not support DMVPN.
Our design utilizes EIGRP to form neighborships across the DMVPN network. This way, we don’t have to worry about static routes and since our primary MPLS network uses BGP, our routing tables will prefer the BGP routes (AD=20) instead of EIGRP routes (AD=90). But in the event of an MPLS-network failure, the BGP-learned routes will be removed and replaced with our already-learned EIGRP routes. Pretty slick, huh? And we used IP SLA to ping the ISP at each branch and if it failed, then the backup default route was already being injected via BGP (AD=20 vs. static route AD=1) and traffic sent back to the main office and out to the Internet.
I bet you’re tired of this talking and just want to look at some diagrams and configs. Read on…
In the diagram above, the bottom-most router is at the main office and the top three routers are at the branches. Each site has both MPLS and Internet connectivity. Our environment was slightly trickier to setup in that third-party firewalls sat in front of the routers, so we had to permit the appropriate ports and perform NAT for the DMVPN tunnels to build.
MAIN OFFICE (HUB):
ip sla monitor 1
type echo protocol ipIcmpEcho <ISP A address> source-interface <specify interface>
timeout 3000
frequency 30
ip sla monitor schedule 1 life forever start-time now
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
crypto isakmp <preshared key> address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10 periodic
!
crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac
mode transport
!
crypto ipsec profile DMVPN_TUNNEL
set transform-set ESP-AES-SHA
!
interface Tunnel0
description DMVPN to Remote Offices
ip address 172.16.1.1 255.255.255.0
no ip redirects
no ip next-hop-self eigrp 1
ip nhrp authentication <NHRP key>
ip nhrp map multicast dynamic
ip nhrp network-id 100
ip virtual-reassembly
ip tcp adjust-mss 1416
no ip split-horizon eigrp 1
tunnel source <source interface>
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile DMVPN_TUNNEL shared
!
router eigrp 1
passive-interface default
no passive-interface <LAN interface>
no passive-interface Tunnel0
network 172.16.1.0 0.0.0.255
network 172.20.1.0 0.0.0.255
no auto-summary
!
router bgp 65208
no synchronization
bgp log-neighbor-changes
network 172.20.1.0 mask 255.255.255.0
redistribute static
neighbor 10.10.10.1 remote-as <<remote AS>
neighbor 10.10.10.1 default-originate
default-information originate
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 <next hop of device en route to ISP A> track 1
ip route 0.0.0.0 0.0.0.0 <next hop of device en route to ISP B> 10
!
BRANCH OFFICE (SPOKE):
ip sla monitor 1
type echo protocol ipIcmpEcho <ISP A address> source-interface <specify interface>
timeout 3000
frequency 30
ip sla monitor schedule 1 life forever start-time now
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
crypto isakmp <preshared key> address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10 periodic
!
crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac
mode transport
!
crypto ipsec profile DMVPN_TUNNEL
set transform-set ESP-AES-SHA
!
interface Tunnel0
description DMVPN to Main Office
ip address 172.16.1.3 255.255.255.0
no ip redirects
ip nhrp authentication <NHRP key>
ip nhrp map 172.16.1.1 <public address on ISP A of main office router>
ip nhrp map multicast <public address on ISP A of main office router>
ip nhrp network-id 100
ip nhrp nhs 172.16.1.1
ip tcp adjust-mss 1416
tunnel source <source interface>
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile DMVPN_TUNNEL
!
router eigrp 1
passive-interface default
no passive-interface Tunnel0
network 172.16.1.0 0.0.0.255
network 172.20.2.0 0.0.0.255
no auto-summary
!
router bgp 65208
no synchronization
bgp log-neighbor-changes
network 172.20.2.0 mask 255.255.255.0
neighbor 10.10.10.9 remote-as <remote AS>
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 172.20.2.30 track 1
!
I wish I would’ve saved the routing table output when we failed over. It was amazingly seemless and the customer didn’t even realize that we had failed over