ENARSI Chapter 19

Chapter 19: DMVPN Tunnels
Instructor Materials
CCNP Enterprise: Advanced Routing

Chapter 19 Content
This chapter covers the following content:
• Generic Routing Encapsulation (GRE) Tunnels - This section explains how
GRE tunnels operate and explains the configuration of GRE tunnels.
• Next Hop Resolution Protocol (NHRP) - This section describes the NHRP
protocol and how it dynamically maps underlay IP addresses to overlay tunnel IP
addresses.
• Dynamic Multipoint VPN (DMVPN) - This section explains the three DMVPN
phases and the technologies involved with DMVPN tunnels.
• DMVPN Configuration - This section explains the configuration of DMVPN
tunnels.
• Spoke-to-Spoke Communication - This section explains how spoke-to-spoke
DMVPN tunnels form.
© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2
Chapter 19 Content (Cont.)
This chapter covers the following content:

• Problems with Overlay Networks - This section describes common issues with
overlay networks and provides optimal design concepts to prevent those issues.
• DMVPN Failure Detection and High Availability - This section explains the
DMVPN mechanisms to detect failure and methods for providing a resilient
DMVPN network.
• IPv6 DMVPN Configuration - This section explains how DMVPN tunnels can
use IPv6 networks as an underlay or overlay network.
Generic Routing Encapsulation
(GRE) Tunnels
• A GRE tunnel provides connectivity to a wide variety of network layer protocols by
encapsulating and forwarding those packets over an IP-based network.
• The original use of GRE tunnels was to provide a transport mechanism for nonroutable
legacy protocols such as DECnet, Systems Network Architecture (SNA), and IPX.
• DMVPN uses Multipoint GRE (mGRE) encapsulation and supports dynamic routing
protocols, which eliminates many of the support issues associated with other VPN
technologies.
• GRE tunnels are classified as an overlay network because a GRE tunnel is built on top
of an existing transport network, also known as an underlay network.
Generic Routing Encapsulation (GRE) Tunnels
GRE Tunnel Configuration
Figure 19-1 illustrates
the configuration of a
GRE tunnel. The
172.16.0.0/16 network
range is the transport
(underlay) network, and
192.168.100.0/24 is
used for the GRE tunnel
(overlay network).
The RIP configuration

does not include the
192.168.0.0/16 network
range.
GRE Tunnel Configuration (Cont.)
Example 19-1 shows the

routing table of R11 before the
GRE tunnel is created. Notice
that the 10.3.3.0/24 network is
reachable by RIP and is two
hops away.
GRE Tunnel Configuration (Cont.)
The steps for configuring GRE tunnels are as follows:
Step 1. Create the tunnel interface by using the global configuration command interface
tunnel tunnel-number.
Step 2. Identify the local source of the tunnel by using the interface parameter command
tunnel source {ip-address | interface-id}.
Step 3. Identify the tunnel destination by using the interface parameter command tunnel
destination ip-address.
Step 4. Allocate an IP address to the tunnel interface by using the command ip address
ip-address subnet-mask.
Step 5. Optionally define the tunnel bandwidth, measured in kilobits per second, by using
the interface parameter command bandwidth [1-10000000].
Step 6. Optionally specify a GRE tunnel keepalive by using the interface parameter
command keepalive [seconds [retries]].
Step 7. Optionally define the IP maximum transmission unit (MTU) for the tunnel interface
by using the interface parameter command ip mtu mtu.
GRE Sample Configuration
Example 19-2 provides
the GRE tunnel
configuration for R11 and
R31. EIGRP is enabled
on the LAN (10.0.0.0/8)
and GRE tunnel
(192.168.100.0/24)
networks. RIP is enabled
on the LAN (10.0.0.0/8)
and transport
(172.16.0.0/16) networks
but is not enabled on the
GRE tunnel. R11 and
R31 become direct
EIGRP peers on the
GRE tunnel because all
the network traffic is
encapsulated between
them.
GRE Sample Configuration (Cont.)
When the GRE tunnel is
configured, the state of the
tunnel can be verified with
the command show
interface tunnel number.
Example 19-3 displays
output from this command.
Next Hop Resolution Protocol
(NHRP)
• Next Hop Resolution Protocol (NHRP) is defined in RFC 2332 as a method to provide
address resolution for hosts or networks (with ARP-like capability) for nonbroadcast
multi-access (NBMA) networks such as Frame Relay and ATM networks.
• NHRP is a client/server protocol that allows devices to register themselves over
directly connected or disparate networks.
• DMVPN uses mGRE tunnels and therefore requires a method of mapping tunnel IP
addresses to the transport (underlay) IP address. NHRP provides the technology for
mapping those IP addresses.
NHRP Message Types
All NHRP packets must include the source NBMA address, source protocol address, destination protocol
address, and NHRP message type. The NHRP message types are explained in Table 19-3.
Message Type Description

Registration Registration messages are sent by the NHC (DMVPN spoke) toward the NHS (DMVPN hub).
Registration allows the hubs to know a spoke’s NBMA information.
Resolution Resolution messages are NHRP messages designed to locate and provide the address resolution
information of the egress router toward the destination.
Redirect Redirect messages are an essential component of DMVPN Phase 3. They allow an intermediate
router to notify the encapsulator (a router) that a specific network can be reached by using a more
optimal path (spoke-to-spoke tunnel).
Purge Purge messages are sent to remove a cached NHRP entry. Purge messages notify routers of the
loss of a route used by NHRP. A purge is typically sent by an NHS to an NHC (which it answered) to
indicate that the mapping for an address/network that it answered is not valid anymore.
Error Error messages are used to notify the sender of an NHRP packet that an error has occurred.
NHRP Message Extensions
NHRP messages can contain additional information that is included in the extension part of a message. Table
19-4 lists the common NHRP message extensions.
Message Extension Description

Responder address This is used to determine the address of the responding node for reply messages.
Forward transit NHS This contains a list of NHSs that the NHRP request packet may have traversed.
record
Reverse transit NHS This contains a list of NHSs that the NHRP reply packet may have traversed.
record
Authentication This conveys authentication information between NHRP speakers. Authentication is done pairwise
on a hop-by-hop basis. This field is transmitted in plaintext.
Vendor private This conveys vendor private information between NHRP speakers.
NAT DMVPN works when a hub or spoke resides behind a device that performs NAT and when the
tunnel is encapsulated in IPsec.
Dynamic Multipoint VPN (DMVPN)
• DMVPN provides complete connectivity while simplifying configuration as new sites
are deployed. It is considered a zero-touch technology because no configuration is
needed on the DMVPN hub routers as new spokes are added to the DMVPN
network.
• A spoke site initiates a persistent VPN connection to the hub router. Network traffic
between spoke sites does not have to travel through the hubs. DMVPN dynamically
builds a VPN tunnel between spoke sites on an as-needed basis.
DMVPN Benefits
DMVPN provides the following benefits to network administrators:
• Zero-touch provisioning - DMVPN hubs do not require additional configuration when
additional spokes are added.
• Scalable deployment - Minimal peering and minimal permanent state on spoke routers
allow for massive scale.
• Spoke-to-spoke tunnels - DMVPN provides full-mesh connectivity while requiring
configuration of only the initial spoke-to-hub tunnel.
• Flexible network topologies - DMVPN operation does not make any rigid
assumptions about either the control plane or data plane overlay topologies.
• Multiprotocol support - DMVPN can use IPv4, IPv6, and MPLS as the overlay or
transport network protocol.
• Multicast support - DMVPN allows multicast traffic to flow on the tunnel interfaces.
• Adaptable connectivity - DMVPN routers can establish connectivity behind NAT.
• Standardized building blocks - DMVPN uses industry-standardized technologies
(NHRP, GRE, and IPsec) to build an overlay network.
DMVPN Phases 1, 2, and 3
DMVPN was released in three phases, each phase built on the previous one with
additional functions. All three phases of DMVPN need only one tunnel interface on a
router, and the DMVPN network size should accommodate all the endpoints associated
with that tunnel network.
• Phase 1: Spoke-to-Hub – Phase 1 provides a zero-touch deployment for VPN sites.
VPN tunnels are created only between spoke and hub sites. Traffic between spokes
must traverse the hub to reach any other spoke.
• Phase 2: Spoke-to-Spoke – Phase 2 provides additional capability beyond DMVPN
Phase 1 and allows spoke-to-spoke communication on a dynamic basis by creating an
on-demand VPN tunnel between the spoke devices.
• Phase 3: Hierarchical Tree Spoke-to-Spoke - Phase 3 refines spoke-to-spoke
connectivity by enhancing the NHRP messaging and interacting with the routing table.
With DMVPN Phase 3, the hub sends an NHRP redirect message to the spoke that
originated the packet flow. The NHRP redirect message provides the necessary
information so that the originator spoke can initiate a resolution of the destination
host/network.
DMVPN Phase Comparison
Figure 19-2 illustrates the
differences in traffic patterns for
the three DMVPN phases. All
three models support direct
spoke-to-hub communication, as
shown by R1 and R2. Spoke-to-
spoke packet flow in DMVPN
Phase 1 is different from the
packet flow in DMVPN Phases 2
and 3. Traffic between R3 and R4
must traverse the hub for Phase 1
DMVPN, whereas a dynamic
spoke-to-spoke tunnel is created
for DMVPN Phase 2 and Phase 3
that allows direct communication.
DMVPN Phase Comparison (Cont.)
Figure 19-3 illustrates the
difference in traffic patterns
between Phase 2 and Phase 3
DMVPN with hierarchical
topologies (multilevel). In this
two-tier hierarchical design, R2
is the hub for DMVPN tunnel 20,
and R3 is the hub for DMVPN
tunnel 30.
This chapter explains the

DMVPN fundamentals with
DMVPN Phase 1 and then
explains DMVPN Phase 3. It
does not cover DMVPN Phase 2.
DMVPN Configuration
• There are two types of DMVPN configurations, hub and spoke. Each is used
depending on a router’s role. The DMVPN hub is the NHRP NHS, and the DMVPN
spoke is the NHRP NHC.
• The spokes should be preconfigured with the hub’s static IP address, but a spoke’s
NBMA IP address can be static or assigned from DHCP.
• In this book, the terms spoke router and branch router are used interchangeably, as
are the terms hub router and headquarters/data center router.
DMVPN Configuration
Simple DMVPN Topology
Figure 19-4 shows the first
topology used to explain DMVPN
configuration and functions. R11
acts as the DMVPN hub, and R31
and R41 are the DMVPN spokes.
All three routers use a static
default route to the SP router that
provides connectivity for the
NBMA ( transport) networks in the
172.16.0.0/16 network range.
EIGRP has been configured to
operate on the DMVPN tunnel
and to advertise the local LAN
networks.
DMVPN Configuration
DMVPN Hub Configuration
The steps for configuring DMVPN on a hub router are as follows:
Step 1. Create the tunnel interface by using the interface tunnel tunnel-number global
configuration command.
Step 2. Identify the local source of the tunnel by using the tunnel source {ip-address | interface-
id} interface parameter command.
Step 3. Configure the DMVPN tunnel as an mGRE tunnel by using the tunnel mode gre
multipoint interface parameter command.
Step 4. Allocate an IP address for the DMVPN network (tunnel) by using the ip address ip-
address subnet-mask command.
Step 5. Enable NHRP on the tunnel interface and uniquely identify the DMVPN tunnel for the
virtual interface by using the ip nhrp network-id 1-4294967295 interface parameter command.
Step 6. Optionally define the tunnel key, which adds 4 bytes to the DMVPN header, with the
tunnel key 0 -4294967295 command.
Step 7. Optionally enable multicast support for NHRP on DMVPN hub routers by using the ip
nhrp map multicast dynamic tunnel command.
DMVPN Configuration
DMVPN Hub Configuration (Cont.)
The steps for configuring DMVPN on a hub router are as follows:
Step 8. For Phase 3, enable NHRP redirect functions by using the ip nhrp redirect command.
Step 9. Optionally define the tunnel bandwidth, measured in kilobits per second, by using the
bandwidth [1-10000000] interface parameter command.
Step 10. Optionally configure the IP MTU for the tunnel interface by using the ip mtu mtu
interface parameter command.
Step 11. Optionally define the TCP maximum segment size (MSS) by using the ip tcp adjust-
mss mss-size command.
Note: mGRE tunnels do not support the option for using a keepalive.
DMVPN Configuration
DMVPN Spoke Configuration for DMVPN Phase 1 (Point-to-
Point
Configuration of DMVPN Phase 1 spokes is similar to the configuration for a hub router except in two ways:
• It does not use an mGRE tunnel. Instead, the tunnel destination is specified.
• The NHRP mapping points to at least one active NHS.
The process for configuring a DMVPN Phase 1 spoke router is as follows:
Step 1. Create the tunnel interface by using the interface tunnel tunnel-number global configuration
command.
Step 2. Identify the local source of the tunnel by using the tunnel source {ip-address | interface-id} interface
parameter command.
Step 3. Identify the tunnel destination by using the tunnel destination ip-address interface parameter
command.
Step 4. Allocate an IP address for the DMVPN network (tunnel) by using the ip address {ip-address subnet-
mask | dhcp} command or the ipv6 address ipv6-address/prefix-length command.
Step 5. Enable NHRP on the tunnel interface and uniquely identify the DMVPN tunnel for the virtual interface
by using the ip nhrp network-id 1-4294967295 interface parameter command.
DMVPN Configuration
Point) (Cont.)
The process for configuring a DMVPN Phase 1 spoke router is as follows:
Step 6. Optionally define the NHRP tunnel key, which adds 4 bytes to the DMVPN header, by using
the tunnel key 0-4294967295 command.
Note: If the tunnel key is defined on the hub router, it must be defined on all the spoke
routers.
Step 7. Specify the address of one or more NHRP NHSs by using the ip nhrp nhs nhs-address nbma
nbma-address [multicast] command.
Note: Remember that the NBMA address is the transport IP address, and the NHS address
is the protocol address for the DMVPN hub.
Step 8. Optionally define the tunnel bandwidth, measured in kilobits per second, by using the
bandwidth [1-10000000] interface parameter command.
Step 9. Optionally define the IP MTU for the tunnel interface by using the ip mtu mtu interface
parameter command.
Step 10. Optionally define the TCP MSS by using the ip tcp adjust-mss mss-size command.
DMVPN Configuration
Point) (Cont.)
Example
19-6
provides a
sample
configuratio
n for R11
(hub), R31
(spoke),
and R41
(spoke).
DMVPN Configuration
Viewing DMVPN Tunnel Status
The show dmvpn [detail] command provides the tunnel interface, tunnel role, tunnel state, and
tunnel peers with uptime. When the DMVPN tunnel interface is administratively shut down,
there are no entries associated with that tunnel interface. These are the tunnel states, in order
of establishment:
• INTF – The line protocol of the DMVPN tunnel is down.

• IKE – DMVPN tunnels configured with IPsec have not yet successfully established an
Internet Key Exchange (IKE) session.
• IPsec - An IKE session has been established, but an IPsec security association (SA) has
not yet been established.
• NHRP - The DMVPN spoke router has not yet successfully registered.
• Up - The DMVPN spoke router has registered with the DMVPN hub and received an ACK
(positive registration reply) from the hub.
DMVPN Configuration
Viewing DMVPN Tunnel Status (Cont.)
Example 19-8
provides output
of the show
dmvpn detail
command. The
detail keyword
provides the
local tunnel and
NBMA IP
addresses,
tunnel health
monitoring, and
VRF contexts.
DMVPN Configuration
Viewing the NHRP Cache
Every router maintains a cache of requests that it receives or is processing. The NHRP cache contains the
following fields displayed using the show ip nhrp [brief] :
• Network entry for hosts or for a network/xx and the tunnel IP address to NBMA IP address.
• The interface number, duration of existence, and expiration (hours:minutes:seconds).
• The NHRP mapping entry type. Table 19-6 provides a list of NHRP mapping entries in the local cache.
NHRP Mapping Description
Entry
static An entry created statically on a DMVPN interface.
dynamic An entry created dynamically. DMVPN Phase 1: an entry created from a spoke that registered with an NHS
with an NHRP registration request.
incomplete A temporary entry placed locally while an NHRP resolution request processes. Incomplete entries prevent
repetitive NHRP requests for the same entry, avoiding unnecessary consumption of router resources.
local Displays local mapping info. Represents a local network that was advertised for an NHRP resolution reply.
(no-socket) Mapping entries that do not have associated IPsec sockets and where encryption is not triggered.
NBMA address Nonbroadcast multi-access address, or the transport IP address where the entry was received.
DMVPN Configuration
Viewing the NHRP Cache (Cont.)
NHRP message flags specify attributes of an NHRP cache entry or of the peer for which the entry was
created. Table 19-7 provides a list of the NHRP message flags and their meanings.
NHRP Message Description
Flag
Used Indication that this NHRP mapping entry was used to forward data packets within the past 60 seconds.
Implicit Indicates that the NHRP mapping entry was learned implicitly.
Unique Indicates that this NHRP mapping entry must be unique and that it cannot be overwritten with a mapping
entry that has the same tunnel IP address but a different NBMA address.
Router Indicates that this NHRP mapping entry is from a remote router that provides access to a network or host that
is located behind the remote router.
Rib Indicates that this NHRP mapping entry has a corresponding routing entry in the routing table.
Nho Indicates that this NHRP mapping entry has a corresponding path that overrides the next hop for a remote
network, as installed by another routing protocol.
Nhop Indicates an NHRP mapping entry for a remote next-hop address and its associated NBMA address.
DMVPN Configuration
Viewing the NHRP Cache (Cont.)
Example 19-9 shows the
local NHRP cache for the
various routers in the
sample topology.
The traceroute shown in

Example 19-12 verifies that
R31 can connect to R41, but
network traffic must still
pass through R11.
DMVPN Configuration
DMVPN Configuration for Phase 3 DMVPN (Multipoint)
The Phase 3 DMVPN configuration for the hub router adds the ip nhrp redirect interface parameter
command on the hub router. This command checks the flow of packets on the tunnel interface and sends a
redirect message to the source spoke router when it detects packets hairpinning out of the DMVPN cloud.
Hairpinning means that traffic is received and sent out an interface in the same cloud (identified by the NHRP
network ID). The steps for configuring a DMVPN Phase 3 spoke router are as follows:
Step 1. Create the tunnel interface by using the interface tunnel tunnel-number global configuration
command.
Step 2. Identify the local source of the tunnel by using the tunnel source {ip-address | interface-id} interface
parameter command.
Step 3. Configure the DMVPN tunnel as a GRE multipoint tunnel by using the tunnel mode gre multipoint
interface parameter command.
Step 4. Allocate an IP address for the DMVPN network (tunnel) by using the ip address ip-address subnet-
mask command.
Step 5. Enable NHRP and uniquely identify the DMVPN tunnel for the virtual interface by using the ip nhrp
network-id 1-4294967295 interface parameter command.
Step 6. Optionally configure the tunnel key by using the tunnel key 0-4294967295 command.
Step 7. Enable the NHRP shortcut function by using the ip nhrp shortcut command.
DMVPN Configuration
DMVPN Configuration for Phase 3 DMVPN (Multipoint) (Cont.)
The steps for configuring a DMVPN Phase 3 spoke router are as follows:
Step 8. Specify the address of one or more NHRP NHSs by using the ip nhrp nhs nhs-address nbma nbma-
address [multicast] command.
Step 9. Optionally define the IP MTU for the tunnel interface by using the ip mtu mtu interface parameter
command.
Step 10. Optionally define the TCP MSS feature, which ensures that the router will edit the payload of a TCP
three-way handshake if the MSS exceeds the configured value. The command is ip tcp adjust-mss mss-size.
DMVPN Configuration
DMVPN Configuration for Phase 3 DMVPN (Multipoint)
(Cont.)
Example 19-
13 provides a
sample
configuration
for R11 (hub),
R21 (spoke),
and R31
(spoke)
configured
with Phase 3
DMVPN.
DMVPN Configuration
IP NHRP Authentication and Unique IP NHRP Registration
NHRP authentication is weak because the password is stored in plaintext. Enable NHRP
authentication by using the ip nhrp authentication password interface parameter command.
When an NHC registers with an NHS, it provides the protocol address and the NBMA address.
The NHS maintains a local cache of these settings. This capability is indicated by the NHRP
message flag unique on the NHS, as shown in Example 19-14.
Spoke-to-Spoke Communication
• This section focuses on the underlying mechanisms used to establish spoke-to-spoke
communication.
• In DMVPN Phase 1, the spoke devices rely on the configured tunnel destination to
identify where to send the encapsulated packets.
• Phase 3 DMVPN uses mGRE tunnels and thereby relies on NHRP redirect and
resolution request messages to identify the NBMA addresses for any destination
networks.
Packets flow through the hub in a traditional hub-and-spoke manner until the spoke-to-spoke
tunnel has been established in both directions. As packets flow across the hub, the hub engages
NHRP redirection to begin finding a more optimal path with spoke-to-spoke tunnels. In Example
19-16, R31 initiates a traceroute to R41. Notice that the first packet travels across R11 (hub), but
by the time a second stream of packets is sent, the spoke-to-spoke tunnel has been initialized so
that traffic flows directly between R31 and R41 on the transport and overlay networks.
Forming Spoke-to-Spoke Tunnels
This section explains
in detail how a
spoke-to-spoke
DMVPN tunnel is
formed. Figure 19-5
illustrates the packet
flow among all three
devices—R11, R31,
and R41—to
establish a
bidirectional spoke-
to-spoke DMVPN
tunnel.
Forming Spoke-to-Spoke Tunnels (Cont.)
Example 19-17
shows the status
of DMVPN tunnels
on R31 and R41,
where there are
two new spoke-to-
spoke tunnels
(highlighted). The
DLX entries
represent the local
(no-socket)
routes. The
original tunnel to
R11 remains a
static tunnel.
Forming Spoke-to-Spoke Tunnels (Cont.)
Example 19-18
shows the
NHRP cache for
R31 and R41.
Notice the
NHRP
mappings:
router, rib, nho,
and nhop.
NHRP Routing Table Manipulation
NHRP interacts with the routing/forwarding
tables and installs or modifies routes in the
routing table. In the event that an entry
exists with an exact match for the network
and prefix length, NHRP overrides the
existing next hop with a shortcut. The
original protocol is still responsible for the
prefix, but overwritten next-hop addresses
are indicated in the routing table by the
percent sign (%).
Example 19-19 provides the routing tables

for R31 and R41.
NHRP Routing Table Manipulation (Cont.)
The command show ip
route next-hop-
override displays the
routing table with the
explicit NHRP shortcuts
that were added.
Example 19-20 shows
the command’s output
for the sample topology.
Notice that the NHRP
shortcut is indicated by
the NHO marking and
shown underneath the
original entry with the
correct next-hop IP
address.
NHRP Routing Table Manipulation with Summarization
Summarizing routes on WAN links provides stability
by hiding network convergence and thereby adding
scalability. This section demonstrates NHRP’s
interaction on the routing table when the exact
route does not exist there. R11’s EIGRP
configuration now advertises the 10.0.0.0/8
summary prefix out tunnel 100. The spoke routers
use the summary route for forwarding traffic until
the NHRP establishes the spoke-to-spoke tunnel.
The more explicit entries from NHRP are installed
into the routing table after the spoke-to-spoke
tunnels have been initialized.
Example 19-21 shows the change to R11’s EIGRP

configuration for summarizing the 10.0.0.0/8
networks out the tunnel 100 interface.
NHRP Routing Table Manipulation with Summarization (Cont.)
You can clear the NHRP cache on all
routers by using the command clear ip
nhrp, which removes any NHRP
entries.
Example 19-22 shows the routing

tables for R11, R31, and R41. Notice
that only the 10.0.0.0/8 summary route
provides initial connectivity among all
three routers.
Traffic was re-initiated from 10.3.3.1 to 10.4.4.1 to initialize the spoke-to-spoke tunnels. R11 still sends
the NHRP redirect for hairpinned traffic, and the pattern would complete as shown earlier except that
NHRP would install a more specific route into the routing table on R31 (10.4.4.0/24) and R41
(10.3.3.0/24). The NHRP injected route is indicated by the H entry, as shown in Example 19-23.
Example 19-24 shows the DMVPN tunnels after R31 and R41 have initialized the spoke-to-spoke tunnel with
summarization on R11. Notice that both of the new spoke-to-spoke tunnel entries are DT1 because they are
new routes in the RIB. If the routes had been more explicit (as shown in Example 19-19), NHRP would have
overridden the next-hop address and used a DT2 entry.
Problems with Overlay Networks
• Two problems are frequently found with tunnel or overlay networks: recursive routing
and outbound interface selection.
• The following sections explain these problems and describe solutions to them.
Recursive Routing Problems
If a router tries to reach the remote router’s
encapsulating interface (transport IP address)
through the tunnel (overlay network),
problems will occur. This is a common issue
when a transport network is advertised into
the same routing protocol that runs on the
overlay network.
Figure 19-6 demonstrates a simple GRE

tunnel between R11 and R31. R11, R31, and
the SP routers are running OSPF on the
100.64.0.0/16 transport networks. R11 and
R31 are running EIGRP on the 10.0.0.0/8
LAN and 192.168.100.0/24 tunnel network.
Example 19-25 shows R11’s routing table,

with everything working properly.
Recursive Routing Problems (Cont.)
An administrator has accidentally added the
100.64.0.0/16 network interfaces to EIGRP on R11
and R31. The SP router is not running EIGRP, so
an adjacency does not form, but R11 and R31 add
the transport network to EIGRP, which has a lower
AD than OSPF. The routers then try to use the
tunnel to reach the tunnel endpoint address, which
is not possible. This scenario is known as recursive
routing.
The router detects recursive routing and provides Only point-to-point GRE tunnels provide the
an appropriate syslog message, as shown in syslog message “temporarily disabled due to
Example 19-26. The tunnel is brought down, which
recursive routing.” Both DMVPN and GRE
terminates the EIGRP neighbors, and then R11 and
tunnels use the message “looped chained
R31 find each other again by using OSPF. The
tunnel is reestablished, EIGRP forms a relationship,
attempting to stack.”
and the problem repeats over and over again.
Outbound Interface Selection
In certain scenarios, it is difficult for a router to properly identify the outbound interface for
encapsulating packets for a tunnel. Typically a branch site uses multiple transports (one DMVPN
tunnel per transport) for network resiliency. Imagine that R31 is connected to two different Internet
service providers that receive their IP addresses from DHCP. R31 would have only two default
routes for providing connectivity to the transport networks, as shown in Example 19-27.
Front Door Virtual Routing and Forwarding
Virtual routing and forwarding (VRF) contexts create unique logical routers on a physical
router so that router interfaces, routing tables, and forwarding tables are completely isolated
from other VRF instances.
• The routing table of one transport network is isolated from the routing table of the other
transport network and that the routing table of the LAN interfaces is separate from those
of all the transport networks.
• DMVPN tunnels are VRF aware in the sense that the tunnel source or destination can be
associated to a different VRF instance from the DMVPN tunnel itself.
• Using an FVRF instance for every DMVPN tunnel prevents route recursion because the
transport and overlay networks remain in separate routing tables.
• VRF instances are locally significant, but the configuration/naming should be consistent
to simplify the operational aspects.
Configuring Front Door VRF (FVRF)
The following steps are required to create an FVRF instance, assign it to the transport interface,
and make the DMVPN tunnel aware of the FRF instance:
Step 1. Create the FVRF instance by using the vrf definition vrf-name command.
Step 2. Initialize the appropriate address family for the transport network by using the command
address-family {ipv4 | ipv6}. The address family can be IPv4, IPv6, or both.
Step 3. Enter interface configuration submode and specify the interface to be associated with
the VRF instance by using the command interface interface-id. The VRF instance is linked to
the interface with the interface parameter command vrf forwarding vrf-name.
Step 4. Configure an IPv4 address by using the command ip address ip-address subnet-mask
or an IPv6 address by using the command ipv6 address ipv6-address/prefix-length.
Step 5. Associate the FVRF instance with the DMVPN tunnel by using the interface parameter
command tunnel vrf vrf-name on the DMVPN tunnel.
If an IP address is already configured on the interface, when the VRF instance is linked to the
interface, the IP address is removed from that interface.
Configuring Front Door VRF (FVRF) (Cont.)
Example 19-28 shows how the FVRF
instances named INET01 and INET02 are
created on R31. Notice that when the
FVRF instances are associated, the IP
addresses are removed from the
interfaces. The IP addresses are
reconfigured and the FVRF instances are
associated with the DMVPN tunnels.
FVRF Static Routes
FVRF interfaces that are assigned an IP address by DHCP automatically install a default route
with an AD of 254. FVRF interfaces with static IP addressing require only a static default route
in the FVRF context. This is accomplished with the command ip route vrf vrf-name 0.0.0.0
0.0.0.0 next-hop-ip. Example 19-29 shows the configuration for R31 for the INET01 FVRF
instance. The INET02 FVRF instance does not need a static default route because it gets the
route from the DHCP server.
DMVPN Failure Detection and High
Availability
• An NHRP mapping entry stays in the NHRP cache for a finite amount of time. The entry
is valid based on the NHRP holdtime period, which defaults to 7200 seconds (2 hours).
• The NHRP holdtime can be modified with the interface parameter command ip nhrp
holdtime 1-65535 and should be changed to the recommended value of 600 seconds.
• A secondary function of the NHRP registration packets is to verify that connectivity is
maintained to the NHSs (hubs). NHRP registration messages are sent every NHRP
timeout period, and if the NHRP registration reply is not received for a request, the
NHRP registration request is sent again with the first packet delayed for 1 second, the
second packet delayed for 2 seconds, and the third packet delayed for 4 seconds. The
NHS is declared down if the NHRP registration reply has not been received after the
third retry attempt.
DMVPN Failure Detection and High Availability
• The spoke-to-hub registration is taken down and displays as NHRP for the tunnel state when
examined with the show dmvpn command. The actual tunnel interface still has a line protocol
state of up.
• During normal operation of the spoke-to-hub tunnels, the spoke continues to send periodic
NHRP registration requests, refreshing the NHRP timeout entry and keeping the spoke-to-hub
tunnel up. However, in spoke-to-spoke tunnels, if a tunnel is still being used within 2 minutes of
the expiration time, an NHRP request refreshes the NHRP timeout entry and keeps the tunnel.
If the tunnel is not being used, it is torn down.
• The NHRP timeout period defaults to one-third of the NHRP holdtime, which equates to 2400
seconds (40 minutes). The NHRP timeout period can be modified using the interface
parameter command ip nhrp registration timeout 1-65535.
• When an NHS is declared down, NHCs still attempt to register with the down NHS. This is
known as the probe state. The delay between retry packets increments between iterations and
uses the following delay pattern: 1, 2, 4, 8, 16, 32, and 64 seconds. The delay never exceeds
64 seconds, and after a registration reply is received, the NHS (hub) is declared up again.
DMVPN Hub Redundancy
• Connectivity from a DMVPN spoke to a hub is essential to maintain connectivity.
• If the hub fails, or if a spoke loses connectivity to a hub, that DMVPN tunnel loses its ability to
transport packets.
• Deploying multiple DMVPN hubs for the same DMVPN tunnel provides redundancy and
eliminates a single point of failure.
• Additional DMVPN hubs are added simply by adding NHRP mapping commands to the tunnel
interface.
• All active DMVPN hubs participate in the routing domain for exchanging routes. DMVPN spoke
routers maintain multiple NHRP entries (one per DMVPN hub). No additional configuration is
required on the hubs.
IPv6 DMVPN Configuration
• DMVPN uses GRE tunnels and is capable of tunneling multiple protocols.
Enhancements to NHRP added support for IPv6 so that mGRE tunnels can find the
appropriate IPv6 addresses.
• This means that DMVPN supports the use of IPv4 and IPv6 as the tunnel protocol or
the transport protocol in the combination required.
IPv6 DMVPN Configuration Commands
• For all the commands explained earlier for IPv4, there are equivalent commands to support
IPv6. Table 19-8 provides a list of the tunneled protocol commands for IPv4 and the equivalent
commands for IPv6.
IPv6 DMVPN Configuration Commands (Cont.)
Table 19-9 provides a list of the configuration commands that are needed to support an IPv6
transport network. Any tunnel commands not listed in Table 19-9 are transport agnostic and are
used regardless of the transport IP protocol version.
IPv6 over DMVPN can be interpreted differently depending on the perspective. There are three possible
interpretations:
• IPv4 over IPv6: IPv4 is the tunneled protocol over an IPv6 transport network.
Regardless of the interpretation, DMVPN supports the IPv4 or IPv6 protocol as the tunneled protocol or
the transport, but choosing the correct set of command groups is vital and should be based on the
tunneling technique selected.
Table 19-10 provides a matrix to help you select the appropriate commands from Table 19-8 and Table
19-9. It is important to note that nhs-address or NBMA-address in Table 19-8 can be IPv4 or IPv6
addresses.
Table 19-11 provides a list of IPv4 display commands correlated to the IPv6 equivalents.
IPv6-over-IPv6 Sample Configuration
This section provides a sample configuration
using the topology from Figure 19-4 for the
IPv6-over-IPv6 topology. To simplify the IPv6
addressing scheme, the first two hextets of
the book’s IPv6 addresses use 2001:db8 (the
RFC-defined address space for IPv6
documentation). After the first two hextets, an
IPv4 octet number is copied into an IPv6
hextet, so the IPv6 addresses should look
familiar.
Table 19-12 provides an example of how the

book converts existing IPv4 addresses and
networks to IPv6 format.
IPv6-over-IPv6 Sample Configuration
Example 19-30 provides the IPv6-over-IPv6
DMVPN configuration for hub router R11. The
VRF definition uses the address-family ipv6
command, and the GRE tunnel is defined with
the command tunnel mode gre multipoint
ipv6. Notice that the tunnel interface has a
regular IPv6 address configured as well as a
link-local IPv6 address.
IPv6 DMVPN Verification
The show dmvpn [detail] command can be

used for viewing any DMVPN tunnel,
regardless of the tunnel or transport protocol.
The data is structured slightly differently
because of the IPv6 address format, but it still
provides the same information as before.
Example 19-32 shows the DMVPN tunnel state

from R31 after it has established its static
tunnels to the DMVPN hubs. Notice that the
protocol transport now shows IPv6, and the
NHS devices are using IPv6 addresses.
IPv6 DMVPN Verification (Cont.)
Example 19-33 demonstrates the connectivity between R31 and R41 before and after
the spoke-to-spoke DMVPN tunnel is established.
Prepare for the Exam
Key Topics for Chapter 19
Description
Generic Routing Encapsulation (GRE) tunnels Phase 1 DMVPN spoke configuration
GRE tunnel configuration Alternative NHRP mapping commands
Next Hop Resolution Protocol (NHRP) Viewing DMVPN tunnel status
NHRP message types Phase 3 DMVPN spoke configuration
Dynamic Multipoint VPN (DMVPN) IP NHRP authentication
Phase 1 DMVPN Unique IP NHRP registration
Phase 3 DMVPN Forming spoke-to-spoke DMVPN tunnels
DMVPN hub configuration NHRP routing table manipulation
Key Topics for Chapter 19 (Cont.)
Description
NHRP route table manipulation with DMVPN failure detection and high availability
summarization
Recursive routing problems DMVPN hub redundancy
Outbound interface selection IPv6 DMVPN configuration
Front door virtual routing and forwarding (FVRF)
Key Terms for Chapter 19
Term
Dynamic Multipoint Virtual Private Network GRE tunnel
(DMVPN)
DMVPN Phase 1 Next Hop Resolution Protocol (NHRP)
DMVPN Phase 3 NHRP redirect
encapsulating interface NHRP shortcut
front door VRF next-hop server (NHS, recursive routing)
Command Reference for Chapter 19
Task Command Syntax
Specify the source IP address or interface used for tunnel source {ip-address | interface-id}
encapsulating packets for a tunnel
Specify the destination IP address for establishing a tunnel tunnel destination ip-address
Convert a GRE tunnel into an mGRE tunnel tunnel mode gre multipoint
Enable NRHP and uniquely identify a DMVPN tunnel locally ip nhrp network-id 1-4294967295
Define a tunnel key globally on a DMVPN tunnel interface to tunnel key 0-4294967295
allow routers to identify when multiple tunnels use the same
encapsulating interface
Enable plaintext NHRP authentication ip nhrp authentication password
Associate a front door VRF instance to a DMVPN tunnel tunnel vrf vrf-name
interface
Command Reference for Chapter 19 (Cont.)
Task Command Syntax
Allow for an NHRP client to register with a different IP ip nhrp registration no-unique
address before timing out at the hub
Enable the NHRP redirect function on a DMVPN hub tunnel ip nhrp redirect
interface
Enable the ability to install NHRP shortcuts into a spoke ip nhrp shortcut
router’s RIB
Enable the mapping of multicast on a DMVPN hub tunnel ip nhrp map multicast dynamic
interface
Specify the NHRP NHS, NBMA address, and multicast ip nhrp nhs nhs-address nbma nbma-
mapping on a spoke address [multicast]
Or
ip nhrp nhs nhs-address
ip nhrp map
ip nhrp map multicast [nbma-address |
dynamic]
Command Reference for Chapter 19 (Cont.)
Task Command Syntax
Display the tunnel interface state and statistics show interface tunnel number
Display DMVPN tunnel interface association, NHRP show dmvpn [detail]

mappings, and IPsec session details
Display the NHRP cache for a router show ip nhrp [brief]
Display the NHRP shortcut that is installed for an overridden show ip route next-hop-override
route

ENARSI Chapter 19

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ENARSI Chapter 19

Uploaded by

Copyright:

Available Formats

Chapter 19: DMVPN Tunnels

CCNP Enterprise: Advanced Routing

This chapter covers the following content:

The RIP configuration

Example 19-1 shows the

Message Type Description

Message Extension Description

This chapter explains the

The process for configuring a DMVPN Phase 1 spoke router is as follows:

• INTF – The line protocol of the DMVPN tunnel is down.

The traceroute shown in

Example 19-19 provides the routing tables

Example 19-21 shows the change to R11’s EIGRP

Example 19-22 shows the routing

Figure 19-6 demonstrates a simple GRE

Example 19-25 shows R11’s routing table,

Table 19-12 provides an example of how the

The show dmvpn [detail] command can be

Example 19-32 shows the DMVPN tunnel state

GRE tunnel configuration Alternative NHRP mapping commands

Next Hop Resolution Protocol (NHRP) Viewing DMVPN tunnel status

NHRP message types Phase 3 DMVPN spoke configuration

Dynamic Multipoint VPN (DMVPN) IP NHRP authentication

Phase 1 DMVPN Unique IP NHRP registration

Phase 3 DMVPN Forming spoke-to-spoke DMVPN tunnels

DMVPN hub configuration NHRP routing table manipulation

Outbound interface selection IPv6 DMVPN configuration

Front door virtual routing and forwarding (FVRF)

DMVPN Phase 3 NHRP redirect

encapsulating interface NHRP shortcut

front door VRF next-hop server (NHS, recursive routing)

Display DMVPN tunnel interface association, NHRP show dmvpn [detail]

You might also like