DMVPN - Rig In a Box (RiB) Solution




I have a customer who has multiple remote sites that require Internet connectivity. The current solution is very hands on in that someone must re-IP devices as they are moved site to site.

This was a perfect opportunity to introduce DMVPN to this customer. The proposed DMVPN Solution for remote site connectivity is a multi-facet DMVPN configuration that utilizes multiple ISP connections, VRF Lite, and Zone Based Firewall technologies. 

It is always my goal when developing a design strategy for a customer to stick to the basics, to provide a solution that not only provides scalability but one that is manageable. I always point out a familiar line from an architecture design book:

"Think of the 2:00AM test, if you were awakened in the middle of the night because of a network problem and had to figure out the traffic flows in your network while you were half asleep, could you do it?"

So many Engineers fall into the pattern of designing and configuring networks to their current skill level instead of designing the network based on the business requirements (I am no exception). Overly complex designs that are hard to manage are quite common in the wild, it should be the goal of every Network Engineer to keep the design as simple as possible.

Multi-Facet DMVPN Solution

Unlike your typical DMVPN where perhaps a remote site needs access to the Corporate HQ and should be able to share network resources. My client is looking for their remote sites to simply gain Internet access through the Hub site. In talking with the customer and getting an idea for the potential growth of the solution it was determined that the local Internet circuit should be upgraded to support the upcoming site additions. The circuit was upgraded to a 300Mb/300Mb connection.

It was now time to begin designing the solution to later demonstrate it as a Proof of Concept (PoC). If the customer signs off on the PoC, we simply take the configurations and migrate them to live hardware.

DMVPN Proof of Concept

The overall goal is to provide a remote site (Spoke) Internet connectivity via the corporate HQ (Hub) site. Resources at the spoke site will be VoIP external (Internet SIP Provider) and internal intercom service. The topology for this design is quite simple and is highly modular.

Again, simplicity and a comprehensive approach is my preference and I like to separate my drawings into Layer 3 and Layer 2. I do this as I want to create a drawing so any Engineer walking through the door can quickly wrap their head around the design and begin troubleshooting etc.





While typical DMVPN configurations are relatively straightforward, I went through various designs before settling on the following

Hub - This router also serves as my customers MPLS router so I wanted to completely segment the DMVPN configuration from the current production services provided by this router. How do we do that? Hmmm, oh yes...VRF : )

My previous background and experience has been more involved in switching and various security related avenues (ASA, L2L and SSL VPN's) so while I am fully aware of VRF and what it provides, this was a perfect opportunity for me to implement it and let it work it's magic. Exciting stuff!

Spoke - Multiple ISP connections, should primary fail we need to provide not only failover to a secondary connection but provide failover in a timely manner so that we experience as little downtime as possible, I aimed for anywhere between 15-30 seconds. Our end users are utilizing Citrix and VoIP and with Voice involved, failover must be relatively fast. Voice will be provided by leveraging a Internet SIP provider. I will not go into the CME configuration here, perhaps another time.

Hub Configuration

The Hub configuration is typical DMVPN but of course with the implementation of a VRF, we must ensure our configuration is VRF aware.

1. We first start by creating our VRF, give the VRF a name and create your route distinguisher and ensure CEF is enabled

   HQ-RTR (config) # ip vrf DMVPN
    HQ-RTR (config-vrf) # rd 1:1
    HQ-RTR (config-vrf) # ip cef

2. Configure crypto keyring, ISAKMP policy and profile, again these must be VRF aware and are configured using the following commands:

   HQ-RTR (config) # crypto keyring RiB vrf DMVPN
    HQ-RTR (config) # pre-shared key address 0.0.0.0 0.0.0.0 key Cisco123
    
    HQ-RTR (config) # crypto isakmp policy 10
    HQ-RTR (config-isakmp) # hash md5
    HQ-RTR (config-isakmp) # authentication pre-share
    HQ-RTR (config-isakmp) # exit
    HQ-RTR (config) # crypto isakmp keepalive 10

    HQ-RTR (config) # crypto isakmp profile RiB
    HQ-RTR (config-isa-profile) # keyring RiB
    HQ-RTR (config-isa-profile) # match identity address 0.0.0.0 0.0.0.0 DMVPN

3. Now configure the IPsec transform-set and IPsec profile:

    HQ-RTR (config) # crypto ipsec transform-set strong esp-3des esp-md5-hmac
    HQ-RTR (cfg-crypto-trans) # mode transport

    HQ-RTR (config) # crypto ipsec profile DMVPN
    HQ-RTR (ipsec-profile) # set security-association lifetime seconds 120
    HQ-RTR (ipsec-profile) #set transform-set strong
    HQ-RTR (ipsec-profile) #set isakmp-profile RiB

That concludes the configuration of our VRF, our crypto and IPsec arguements. Now we need to configure the public facing interface, VTI's, NAT, and create our dynamic routing process to complete the Hub configuration.

I requested a public IP from the customers applicable range, as an example let's use 200.1.1.1/24. Let's apply this to our available interface on the router.

1. Apply public IP to interface and provide a description

    HQ-RTR (config) # interface GigabitEthernet0/3
    HQ-RTR (config-if) # ip address 200.1.1.1 255.255.255.0
    HQ-RTR (config-if) # description DMVPN Internet Connection

2. We will need to provide a means for traffic to reach the Internet via the G0/3 interface, in order for this to happen we will need to NAT/PAT, let's create an ACL to identify which traffic should be PAT'd then create our NAT pool, again we must make our NAT statement VRF aware:

    HQ-RTR (config-if) # access-list 1 permit 10.0.0.0 0.255.255.255
    HQ-RTR (config) # ip nat pool PAT 200.1.1.1 200.1.1.1 prefix-length 24
    HQ-RTR (config) # ip nat inside source list 1 interface GigabitEthernet0/3 vrf DMVPN overload

3. Let's apply NAT to our G0/3 interface

    HQ-RTR (config) # interface GigabitEthernet0/3
    HQ-RTR (config-if) # ip nat outside

As mentioned previously, this router serves as the gateway to my clients MPLS network and is therefore running multiple dynamic routing protocols (EIGRP & BGP), we must create a separate EIGRP process for the DMVPN solution.

1. Create the VTI's (Virtual Tunnel Interfaces) and assign an IP address in a range that will provide for growth, I have chosen consecutive /24 networks for this purpose

    HQ-RTR (config) # interface Tunnel 1
    HQ-RTR (config-if) # ip address 10.0.1.1 255.255.255.0
    HQ-RTR (config-if) # no ip redirects
    HQ-RTR (config-if) # ip mtu 1400
    HQ-RTR (config-if) # no ip next-hop-self eigrp 100
    HQ-RTR (config-if) # ip nat inside
    HQ-RTR (config-if) # ip nhrp authentication Cisco
    HQ-RTR (config-if) # ip nhrp map multicast dynamic
    HQ-RTR (config-if) # ip nhrp network-id 1
    HQ-RTR (config-if) # ip virtual-reassembly in
    HQ-RTR (config-if) # no ip split-horizon eigrp 100
    HQ-RTR (config-if) # tunnel source GigabitEthernet0/3
    HQ-RTR (config-if) # tunnel mode gre multipoint
    HQ-RTR (config-if) # tunnel key 1111
    HQ-RTR (config-if) # tunnel vrf DMVPN
    HQ-RTR (config-if) # tunnel protection ipsec profile DMVPN shared


    HQ-RTR (config) # interface Tunnel 2
    HQ-RTR (config-if) # ip address 10.0.2.1 255.255.255.0
    HQ-RTR (config-if) # no ip redirects
    HQ-RTR (config-if) # ip mtu 1400
    HQ-RTR (config-if) # no ip next-hop-self eigrp 200
    HQ-RTR (config-if) # ip nat inside
    HQ-RTR (config-if) # ip nhrp authentication Cisco
    HQ-RTR (config-if) # ip nhrp map multicast dynamic
    HQ-RTR (config-if) # ip nhrp network-id 2
    HQ-RTR (config-if) # ip virtual-reassembly in
    HQ-RTR (config-if) # no ip split-horizon eigrp 200
    HQ-RTR (config-if) # tunnel source GigabitEthernet0/3
    HQ-RTR (config-if) # tunnel mode gre multipoint
    HQ-RTR (config-if) # tunnel key 2222
    HQ-RTR (config-if) # tunnel vrf DMVPN
    HQ-RTR (config-if) # tunnel protection ipsec profile DMVPN shared

Let's configure the EIGRP processes now, one for each connection that will be on the spoke side:

1. Let's now create the EIGRP routing processes and again, we must make the routing process aware of our VRF, thus making the autonomous system part of our VRF:

    HQ-RTR (config) # router eigrp 100
    HQ-RTR (config-router) # address-family ipv4 vrf DMVPN autonomous-system 100
    HQ-RTR (config-router-af) # redistribute static
    HQ-RTR (config-router-af) # network 10.0.1.1 0.0.0.0
    HQ-RTR (config-router-af) # passive-interface default
    HQ-RTR (config-router-af) # no passive-interface Tunnel 1
    HQ-RTR (config-router-af) # exit


    HQ-RTR (config) # router eigrp 200
    HQ-RTR (config-router) # address-family ipv4 vrf DMVPN autonomous-system 200
    HQ-RTR (config-router-af) # redistribute static
    HQ-RTR (config-router-af) # network 10.0.2.1 0.0.0.0
    HQ-RTR (config-router-af) # passive-interface default
    HQ-RTR (config-router-af) # no passive-interface Tunnel 2
    HQ-RTR (config-router-af) # exit

2. We have to ensure we have a default route for our new public facing interface (G0/3) and of course once again it must be VRF aware:

    HQ-RTR (config) # ip route vrf DMVPN 0.0.0.0 0.0.0.0 200.1.1.2

3. Let's take a quick look at our vrf routing table, is our default route in the routing table?

    HQ-RTR # sh ip route vrf DMVPN

Routing Table: DMVPN
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
       + - replicated route, % - next hop override

Gateway of last resort is 200.1.1.2 to network 0.0.0.0


S*    0.0.0.0/0 [1/0] via 200.1.1.2
      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C        10.0.1.0/24 is directly connected, Tunnel1
L        10.0.1.1/32 is directly connected, Tunnel1
C        10.0.2.0/24 is directly connected, Tunnel2
L        10.0.2.1/32 is directly connected, Tunnel2
      200.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        200.1.1.0/24 is directly connected, GigabitEthernet0/3
L        200.1.1.1/32 is directly connected, GigabitEthernet0/3

4. One last thing and I have mentioned it over and over during the configurations above, are all of our interfaces VRF aware? Have we assigned interfaces to the VRF? We must configure VRF forwarding on our VTI's and Public Facing interface. Let's do that and finalize the configuration of our Hub router:

    HQ-RTR (config) # interface GigabitEthernet0/3
    HQ-RTR (config-if) # ip vrf forwarding DMVPN

    HQ-RTR (config) # interface Tunnel 1
    HQ-RTR (config-if) # ip vrf forwarding DMVPN

    HQ-RTR (config) # interface Tunnel 1
    HQ-RTR (config-if) # ip vrf forwarding DMVPN

5. That now completes the configuration on the Hub router!

Now it is time to configure the Spoke router....

Spoke Configuration

As I mentioned before, this spoke design went through various iterations, remember that failover timers need to be tweaked in order to provide for quick failover to the secondary Internet connection. I initially went with the Primary Internet up with the Secondary being down, I configured IP SLA to help track connectivity, used a floating static route then leveraged EEM to bring the secondary up and shut the other VTI down. Once both connections were up at the same time, loads of errors and failover was far from fast.

I decided once again to leverage VRF, but in particular this is a FVRF configuration in that we leave the VTI's in the global routing table and the only interface that is a member of the VRF is the secondary internet interface. This way were are using the VRF to negotiate IPsec, we then leverage the global routing table for dynamic routing across the tunnel/s. Both interfaces are up at the same time, I can then control routing by placing a higher delay metric on the secondary VTI.

Let's get started:

1. Again we start by creating a VRF, give the VRF a name and create a route distinguisher. Enable CEF if it is not already enabled

   Spoke-RTR (config) # ip vrf RigSecondary
    Spoke-RTR (config-vrf) # rd 1:1
    Spoke-RTR (config-vrf) # ip cef

2. Configure crypto keyring, and ISAKMP policy, again let's make sure the keyring is VRF aware:

   Spoke-RTR (config) # crypto keyring RiB vrf RigSecondary
    Spoke-RTR (config) # pre-shared key address 0.0.0.0 0.0.0.0 key Cisco123
    
    Spoke-RTR (config) # crypto isakmp policy 10
    Spoke-RTR (config-isakmp) # hash md5
    Spoke-RTR (config-isakmp) # authentication pre-share
    Spoke-RTR (config-isakmp) # exit
    Spoke-RTR (config) # crypto isakmp keepalive 10

3. Now configure the IPsec transform-set and IPsec profile:

    Spoke-RTR (config) # crypto ipsec transform-set strong esp-3des esp-md5-hmac
    Spoke-RTR (cfg-crypto-trans) # mode transport

    Spoke-RTR (config) # crypto ipsec profile DMVPN
    Spoke-RTR (ipsec-profile) # set security-association lifetime seconds 120
    Spoke-RTR (ipsec-profile) #set transform-set strong

**Note: This solution utilizes a head-end router (1900) that will provide DHCP addresses to each RiB. This is why we see a typical RFC1918 address on the primary outside interface.**

1. We plug the sites internet connection into port G0/0 and receive an IP address via DHCP, same for the Secondary interface which will receive a public IP address for the ISP, this is a Satellite connection, let's use 140.1.1.2/24 as a reference for this connection.

    Spoke-RTR (config) # sh interface GigabitEthernet0/3
    !
    interface GigabitEthernet0/0
    ip dhcp client default-router distance 1
    ip address dhcp

    Spoke-RTR (config) # sh ip int br
    Interface                         IP-Address         OK?      Method    Status    Protocol
    GigabitEthernet0/0         10.175.1.253        YES      DHCP       up          up


    Spoke-RTR (config) # sh interface GigabitEthernet0/1.98
    !
    interface GigabitEthernet0/1.98
    ip dhcp client default-router distance 1
    ip address dhcp

    Spoke-RTR (config) # sh ip int br
    Interface                           IP-Address         OK?      Method    Status    Protocol
    GigabitEthernet0/1.98       140.1.1.2             YES      DHCP       up          up

2. Now let's create our NAT statements for our outside interfaces, let's use route maps for this

    Spoke-RTR (config-if) # route-map InternetPRI permit 10
    Spoke-RTR (config-route-map) # match interface GigabitEthernet0/0
    Spoke-RTR (config-if) # route-map InternetSEC permit 10
    Spoke-RTR (config-route-map) # match interface GigabitEthernet0/1.98

    Spoke-RTR (config) # ip nat inside source route-map InternetPRI interface G0/0 overload
    Spoke-RTR (config) # ip nat inside source route-map InternetSEC interface G0/1.98 overload

3. Let's apply NAT to our interfaces

    Spoke-RTR (config) # interface GigabitEthernet0/0
    Spoke-RTR (config-if) # ip nat outside


    Spoke-RTR (config) # interface GigabitEthernet0/1.98
    Spoke-RTR (config-if) # ip nat outside

4. Now let's create our VTI's, again we are using IP addresses from the same /24 network on the Hub (10.0.1.0/24 and 10.0.2.0/24).

Spoke-RTR (config) # interface Tunnel 1
    Spoke-RTR (config-if) # ip address 10.0.1.2 255.255.255.0
    Spoke-RTR (config-if) # no ip redirects
    Spoke-RTR (config-if) # ip mtu 1400
    Spoke-RTR (config-if) # ip nat inside
    Spoke-RTR (config-if) # ip nhrp authentication Cisco
    Spoke-RTR (config-if) # ip nhrp map multicast dynamic
    Spoke-RTR (config-if) # ip nhrp map 10.0.1.1 200.1.1.1
    Spoke-RTR (config-if) # ip nhrp map multicast 200.1.1.1
    Spoke-RTR (config-if) # ip nhrp network-id 1
    Spoke-RTR (config-if) # ip virtual-reassembly in
    Spoke-RTR (config-if) # tunnel source GigabitEthernet0/0
    Spoke-RTR (config-if) # tunnel mode gre multipoint
    Spoke-RTR (config-if) # tunnel key 1111
    Spoke-RTR (config-if) # tunnel protection ipsec profile DMVPN

Since we are leveraging a FVRF configuration, the secondary tunnel will have a few slight differences in the configuration, this way the tunnel endpoint is negotiated via the VRF which is based on the "tunnel vrf" command. Otherwise, the endpoint negotiation would take place via the global routing table and for this design, this is something we do not want to occur.

Spoke-RTR (config) # interface Tunnel 2
    Spoke-RTR (config-if) # ip address 10.0.2.2 255.255.255.0
    Spoke-RTR (config-if) # no ip redirects
    Spoke-RTR (config-if) # ip mtu 1400
    Spoke-RTR (config-if) # ip nat inside
    Spoke-RTR (config-if) # ip nhrp authentication Cisco
    Spoke-RTR (config-if) # ip nhrp map multicast dynamic
    Spoke-RTR (config-if) # ip nhrp map 10.0.2.1 200.1.1.1
    Spoke-RTR (config-if) # ip nhrp map multicast 200.1.1.1
    Spoke-RTR (config-if) # ip nhrp network-id 2
    Spoke-RTR (config-if) # ip virtual-reassembly in
    Spoke-RTR (config-if) # tunnel source GigabitEthernet0/1.98
    Spoke-RTR (config-if) # tunnel mode gre multipoint
    Spoke-RTR (config-if) # tunnel key 2222
    Spoke-RTR (config-if) # tunnel vrf RigSecondary
    Spoke-RTR (config-if) # tunnel protection ipsec profile DMVPN


It is now time to configure our EIGRP processes, one for each public interface

1. Let's create the EIGRP routing processes and again, we have multiple network segments that we need to advertise:

    Spoke-RTR (config) # router eigrp 100
    Spoke-RTR (config-router-af) # network 10.0.1.2 0.0.0.0
    Spoke-RTR (config-router-af) # network 10.250.0.0 0.0.255.255
    Spoke-RTR (config-router-af) # passive-interface default
    Spoke-RTR (config-router-af) # no passive-interface Tunnel 1
    Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.10
    Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.20
    Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.30
    Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.99
    Spoke-RTR (config-router-af) # exit


    Spoke-RTR (config) # router eigrp 200
    Spoke-RTR (config-router-af) # network 10.0.2.2 0.0.0.0
    Spoke-RTR (config-router-af) # network 10.250.0.0 0.0.255.255
    Spoke-RTR (config-router-af) # passive-interface default
    Spoke-RTR (config-router-af) # no passive-interface Tunnel 2
    Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.10
    Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.20
    Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.30
    Spoke-RTR (config-router-af) # no passive-interface GigabitEthernet0/1.99
    Spoke-RTR (config-router-af) # exit

Unlike with the Hub router, we do not need a static route to be configured. If you will remember from the configuration of the hub we are redistributing a static route down to the spoke, this way the spoke will receive a default route via EIGRP for each active connection.

In order to ensure the Primary connection is the chosen path, let's set a delay metric on the secondary tunnel interface

Spoke-RTR (config) # interface Tunnel 2
Spoke-RTR (config-if) # delay 100000

Let's now verify EIGRP, we should have a default route in our global routing table via Tunnel 1 to the Hub router

Spoke-RTR# sh ip route
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
       + - replicated route, % - next hop override

Gateway of last resort is 10.0.1.1 to network 0.0.0.0

D*EX  0.0.0.0/0 [170/26880256] via 10.0.1.1, 04:43:45, Tunnel1   <----- Default Route via EIGRP
      10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks
C        10.0.1.0/24 is directly connected, Tunnel1
L        10.0.1.2/32 is directly connected, Tunnel1
C        10.0.2.0/24 is directly connected, Tunnel2
L        10.0.2.2/32 is directly connected, Tunnel2
C        10.175.0.0/16 is directly connected, GigabitEthernet0/0
L        10.175.1.253/32 is directly connected, GigabitEthernet0/0
C        10.250.1.0/24 is directly connected, GigabitEthernet0/1.10
L        10.250.1.254/32 is directly connected, GigabitEthernet0/1.10
C        10.250.2.0/24 is directly connected, GigabitEthernet0/1.20
L        10.250.2.254/32 is directly connected, GigabitEthernet0/1.20
C        10.250.3.0/24 is directly connected, GigabitEthernet0/1.30
L        10.250.3.254/32 is directly connected, GigabitEthernet0/1.30
C        10.250.99.0/24 is directly connected, GigabitEthernet0/1.99
L        10.250.99.254/32 is directly connected, GigabitEthernet0/1.99

Now let's verify connectivity to the Internet from the Spoke-RTR

Spoke-RTR# traceroute 4.2.2.2
Type escape sequence to abort.
Tracing the route to 4.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.1.1 44 msec 44 msec 56 msec   <------traffic has traversed the tunnel
  2 x.x.x.x 48 msec 44 msec 40 msec
  3 x.x.x.x 44 msec 48 msec 44 msec
  4 x.x.x.x 80 msec * 
    x.x.x.x 48 msec
  5 x.x.x.x 52 msec *  *
  6

Spoke-RTR# ping 4.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/77/80 ms

Another command to verify DMVPN connectivity that is useful is "sh dmvpn", and "sh crypto session"

Spoke-RTR#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel1, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:1, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 200.1.1.1                    10.0.1.1    UP 05:00:23     S

Interface: Tunnel2, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:1, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 200.1.1.1                     10.0.2.1    UP 05:00:18     S


Spoke-RTR#sh crypto session 
Crypto session current status

Interface: Tunnel1
Session status: UP-ACTIVE     
Peer: 200.1.1.1 port 4500 
  IKEv1 SA: local 10.175.1.253/4500 remote 200.1.1.1/4500 Active 
  IPSEC FLOW: permit 47 host 10.175.1.253 host 200.1.1.1
        Active SAs: 2, origin: crypto map

Interface: Tunnel2
Session status: UP-ACTIVE     
Peer: 200.1.1.1 port 500 
  IKEv1 SA: local 140.1.1.2/500 remote 200.1.1.1/500 Active 
  IPSEC FLOW: permit 47 host 140.1.1.2 host 200.1.1.1 
        Active SAs: 2, origin: crypto map

Failover to Secondary

Of course we need to verify failover, let's create a failover scenario. I will shutdown the Tunnel 1 interface on the Hub and monitor the Spoke

Spoke-RTR#
*Jan 14 02:51:15.938: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.1.1 (Tunnel1) is down: holding time expired

We have lost adjacency via Tunnel 1 as shown above, let's now look at the routing table, we should have a new default route via EIGRP

Spoke-RTR#sh ip route
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
       + - replicated route, % - next hop override

Gateway of last resort is 10.0.2.1 to network 0.0.0.0

D*EX  0.0.0.0/0 [170/51200256] via 10.0.2.1, 00:03:03, Tunnel2   <----- Default Route via EIGRP
      10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks
C        10.0.1.0/24 is directly connected, Tunnel1
L        10.0.1.2/32 is directly connected, Tunnel1
C        10.0.2.0/24 is directly connected, Tunnel2
L        10.0.2.2/32 is directly connected, Tunnel2
C        10.175.0.0/16 is directly connected, GigabitEthernet0/0
L        10.175.1.253/32 is directly connected, GigabitEthernet0/0
C        10.250.1.0/24 is directly connected, GigabitEthernet0/1.10
L        10.250.1.254/32 is directly connected, GigabitEthernet0/1.10
C        10.250.2.0/24 is directly connected, GigabitEthernet0/1.20
L        10.250.2.254/32 is directly connected, GigabitEthernet0/1.20
C        10.250.3.0/24 is directly connected, GigabitEthernet0/1.30
L        10.250.3.254/32 is directly connected, GigabitEthernet0/1.30
C        10.250.99.0/24 is directly connected, GigabitEthernet0/1.99
L        10.250.99.254/32 is directly connected, GigabitEthernet0/1.99

Is traffic routing via Tunnel 2?

Spoke-RTR#traceroute 4.2.2.2
Type escape sequence to abort.
Tracing the route to 4.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.2.1 688 msec 708 msec 720 msec   <----- Traffic has traversed Tunnel 2
  2 x.x.x.x 732 msec 700 msec 720 msec
  3 x.x.x.x 720 msec 720 msec 760 mse

Time to bring the primary back online

Spoke-RTR#
*Jan 14 03:02:13.945: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.1.1 (Tunnel1) is up: new adjacency

The routing table is again routing traffic out Tunnel 1

Spoke-RTR#sh ip route
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
       + - replicated route, % - next hop override

Gateway of last resort is 10.0.1.1 to network 0.0.0.0

D*EX  0.0.0.0/0 [170/26880256] via 10.0.1.1, 00:00:26, Tunnel1  <---- Primary route restored
      10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks
C        10.0.1.0/24 is directly connected, Tunnel1
L        10.0.1.2/32 is directly connected, Tunnel1
C        10.0.2.0/24 is directly connected, Tunnel2
L        10.0.2.2/32 is directly connected, Tunnel2
C        10.175.0.0/16 is directly connected, GigabitEthernet0/0
L        10.175.1.253/32 is directly connected, GigabitEthernet0/0
C        10.250.1.0/24 is directly connected, GigabitEthernet0/1.10
L        10.250.1.254/32 is directly connected, GigabitEthernet0/1.10
C        10.250.2.0/24 is directly connected, GigabitEthernet0/1.20
L        10.250.2.254/32 is directly connected, GigabitEthernet0/1.20
C        10.250.3.0/24 is directly connected, GigabitEthernet0/1.30
L        10.250.3.254/32 is directly connected, GigabitEthernet0/1.30
C        10.250.99.0/24 is directly connected, GigabitEthernet0/1.99
L        10.250.99.254/32 is directly connected, GigabitEthernet0/1.99

That concludes the configuration and testing of this DMVPN solution. I learned a lot during the implementation of this and am satisfied with the results.

ZBFW Configuration (Zone Based Firewall)

I will cover ZBFW in a separate blog, however I did utilize ZBFW for the Spoke router, the configuration is rather straight forward and is as follows

class-map type inspect match-any trust-to-untrust
 match protocol tcp
 match protocol udp
 match protocol icmp
class-map type inspect match-all vpn-to-trust
 match access-group 100
class-map type inspect match-any untrust-to-trust-icmp
 match protocol icmp
class-map type inspect match-any untrust-to-trust-ssh
 match protocol ssh
!
policy-map type inspect trust-to-untrust-policy-map
 class type inspect trust-to-untrust
  inspect
 class class-default
  drop
policy-map type inspect untrust-to-trust-policy-map
 class type inspect untrust-to-trust-ssh
  inspect
 class type inspect untrust-to-trust-icmp
  inspect
 class type inspect vpn-to-trust
  inspect
 class class-default
  drop
!
zone security trust
zone security untrust
zone-pair security trust-to-untrust source trust destination untrust
 service-policy type inspect trust-to-untrust-policy-map
zone-pair security untrust-to-trust source untrust destination trust
 service-policy type inspect untrust-to-trust-policy-map

Each interface must now be assigned to a zone, either trust or untrust. Outside interfaces will be assigned the untrust zone, while all internal LAN interfaces and VTI's will be assigned to the trust zone. The commands are

zone-member security trust
zone-member security untrust

I also have configured a L2L VPN on the spoke, that is what the class-map "vpn-to-trust" references but I will not delve into that topic here.

I will soon be implementing a secondary Hub, check back in the near future. As I begin to work on that solution I will post my thoughts here.

Until then, Happy Routing!




Comments

Popular posts from this blog

SSL Decryption with Palo Alto NGFW

SSL Decryption with Cisco Firepower Management Center

Cisco Firepower Management Center v6.2 - Reference Guide