This post details the configuration on how to configure a DMVPN Phase 3 VPN in a Dual Hub Single Cloud. I previously wrote a post on configuring DMVPN Phase 2, refer to this post for more detailed information on configuring DMVPN.

As per most previous posts GNS3 was used to lab the configuration. I had to use the Advanced Security IOS image “c7200-advsecurityk9-mz.152-4.M7” instead of my normal Advanced IP Services IOS image “c7200-advipservicesk9-mz.152-4.S4” because that version does not support NHRP redirect required for DMVPN Phase 3. The error received when configuring NHRP redirect is: % NHRP-WARNING: ‘ip nhrp redirect’ failed to initialise.

This post covers the following:

Front Door VRF

Crypto Keyring

Dual DMVPN Hub configuration

DMVPN Spoke configuration

DMVPN NHS Clustering (dual active Hubs and Active/Standby Hub)

DMVPN Phase 3

The router default ISAKMP Policy, IPSec Transform Set and IPSec Profile were used and therefore not covered in this post. This previous post covers ISAKMP and IPSec Policy/Profile creation.

The lab scenario has 6 x Cisco IOS 15.2(4) routers as represented in the diagram below.

Hub Configuration

Step 1 – VRF

A front door VRF is configured and the physical WAN interface placed in the VRF, therefore providing a separate VRF routing table for the physical interface and the global routing table used for the routes learned via the Tunnel interface.

To complete the configuration of the Spoke routers the Hub routers’ NHRP/NHS addresses must be configured. We are specifying the Hub priority and which cluster they belong. As default, without specifying the cluster the Hub would belong to Cluster 0.

In this example, the spoke would setup a VPN tunnel to both Hub routers, therefore achieving load balancing. If this is not desired and you wish to have an Active/Standby configuration you can use the “max-connections” command in conjunction with the priority command.

Step 5 – Routing

router eigrp 1
no auto
network 10.5.0.0 0.0.0.255

I’ve not included how to create Loopback interfaces to simulate the local networks, or how to advertise via EIGRP.

The same configuration steps can be used to configure the second Spoke router, make sure to change the Tunnel and WAN interface IP addresses and the default routes’ next hop address.

Verification of VPN Connectivity

Confirm ISAKMP SA “show crypto isakmp sa“. If IKE Phase 1 has completed successfully you should see the SAs, state should be QM_IDLE.

Confirm IPSec SA “show crypto ipsec sa“. If IPSec SA has established correctly you should see pkts encaps/decaps increase and traffic pass over the VPN.

NHS Cluster/Redundancy Active/Standby

As mentioned in the previous section, you can configure the spokes to connect to the Hubs in an Active/Standby fashion. You can achieve this using the “max-connections” command with a value of 1, on the tunnel interface of the spoke routers. If you do not set the max-connections attribute then all configured NHRP/NHS servers will be active.

Use the command “show ip nhrp nhs redundancy” to confirm the current state. As you can see from the screenshot below, the max-conn attribute is not set and there is currently an active VPN to both Hub servers.

You can also confirm this by using the “show dmvpn” command.

You should have 2 equal cost paths to the core networks (10.10.x.x) via both Hub routers.

To configure Hub router in Active/Standby configuration, set the max-connections to be 1 on the spoke routers’ tunnel interface.

interface Tunnel0
ip nhrp nhs cluster 1 max-connections 1

Once this command is entered the EIGRP adjacency to the Secondary Hub router should drop. Re-running the command “show ip nhrp nhs redundancy” should confirm the number of max-connections and the Secondary Hub router is in the waiting state.

Confirm in the routing table there is only one route to the core networks via Tunnel0.

If for any reason the Primary Hub should fail or connectivity is lost, then the spoke will establish a tunnel to the configured secondary Hub router. Once connectivity to the Primary Hub is re-established then the spoke will re-setup a Tunnel to the Primary Hub and drop the tunnel to the Secondary Hub.

DMVPN Phase 3

As you can see in the last screenshot of the routing table there are no routes to the networks behind the 2nd Spoke router (10.30.x.x). If you went to the 2nd Spoke router you’d see there are no routes to the other spoke routers’ networks (10.20.x.x) either. This is because of split-horizon, the router (the hub in this instance) will not advertise router back on the same interface it learnt them from.

Enter the command “no ip split-horizon eigrp ” under the Tunnel interface on BOTH Hub routers. You should now see the other spoke routers networks via the Tunnel0 interface.

A quick traceroute would confirm reachability. Notice the traffic was routed via the Hub and not direct

In DMVPN Phase 2 we’d use the next-hop-self command on the Hub, this would allow direct spoke-to-spoke communication. We intend to use DMVPN Phase 3, so will not use the next-hop-self command, instead we need to configure NHRP Redirect/Shortcut. This will also allow direct spoke-to-spoke communication as well as route summarisation on the Hub.

On each Spoke

interface Tunnel0
ip nhrp redirect
ip nhrp shortcut

On each Hub

interface Tunnel0
ip nhrp redirect

Once the Phase 3 commands are configured on all of the Hubs and Spoke routers, re-run the tests between the spoke routers.

Ping the local loopback on the spoke router R6 from the other spoke router R5, check the routing table.

Notice the “%” code next to the route of the IP address just pinged. This confirms the route is a next hop override route.

Use the command “show ip route next-hop-override” and you will see that NHRP over-rid the routed learned from the Hub with the direct IP address of the other spoke router.

Using traceroute would confirm initial routing via the Hub until dynamic VPN established to the spoke, subsequent routing would be direct to the spoke. The NHRP route will be present in the routing table until it times out.

Route Summarisation on the Hub

A big benefit of Phase 3 is the ability to use route summarisation on the Hub. In this example both Hub routers will summarise a default route which will be learnt by all of the spoke routers. Despite the default route (gateway of last resort) pointing towards the Hub routers, spoke-to-spoke traffic will still be sent directly towards the spoke router and not via the Hub.

On each Hub

interface Tunnel0
ip summary-address eigrp 1 0.0.0.0 0.0.0.0

On each of the spoke routers, the only EIGRP learnt route is the default route.

When direct communication between spoke routers is established, an “NHRP” route will appear in the routing table with a next hop IP address of the spoke router the network is advertised from. In the routing table this NHRP routing is identified by the “H” next to the route.

You can use the command “show ip route nhrp” just to identify the routes learnt via NHRP.