26 Chapter 2: Transport Independence

The same logic may not apply to multipoint topologies because sites may have different
bandwidth connectivity. It is possible for one router to send more traffic than the remote
network can accept. When this happens, bandwidth is wasted on the transmitting router’s
link because those packets will ultimately be dropped. In addition, it is possible to
prevent a recipient’s router from receiving traffic from a different site.
Figure 2-5 illustrates the concept. Company ABC is using an MPLS VPN for connectivity
between its headquarters (HQ) and branch sites. A majority of the network traffic is from
the Los Angeles headquarters site to the Miami branch site. R1’s circuit bandwidth has
been sized to allow simultaneous communication with R2 and R3.
Unfortunately this causes problems instead. The problem is that R1 is not aware of R3’s
bandwidth and transmits up to a rate of 10 Mbps, whereas R3 can receive only 5 Mbps
of traffic. The SP drops traffic that exceeds 5 Mbps as it is being sent to R3. In addition
to wasting some of R1’s bandwidth, R2 cannot communicate with R3 because R3’s link is
oversubscribed.

New York, NY
Branch Site
Company ABC’s
WAN Network
s R2
Los Angeles, CA bp
HQ Site 5M

10 Mpbs
Full-Mesh Network
R1
10 Mpbs Traffic Stream
5M
bp
s
R3
Congested Link
Miami, FL
Branch Site

Figure 2-5 Multipoint Link Saturation

Dynamic Multipoint VPN (DMVPN)

Dynamic Multipoint VPN (DMVPN) is a Cisco overlay routing solution that addresses
the deficiencies of site-to-site VPN tunnels. Remote locations (spokes) establish a static
tunnel to a centralized location (hub) but are also capable of establishing connectivity to
other remote locations with a dynamic spoke-to-spoke tunnel.

The dynamic spoke-to-spoke behavior allows full-mesh connectivity without the

additional management of providing full-mesh connectivity. The spoke-to-spoke tunnels
are removed after a certain period of inactivity, freeing up router memory and CPU.
Because the site-to-site tunnels are dynamic, the spoke routers do not require as much
memory or CPU as the hub routers.

Figure 2-6 illustrates a DMVPN tunnel where R1 is the hub and R2, R3, and R4 are spoke
routers. R2 and R4 establish a dynamic spoke-to-spoke tunnel for direct communication,
and eventually that dynamic tunnel is torn down after it is no longer needed.
 WAN Transport Technologies 27

R1

Spoke-to-Hub Tunnel
Persistent
R2 R4
Spoke-to-Spoke Tunnel
Dynamic

R3

Figure 2-6 Dynamic Multipoint VPN (DMVPN)

DMVPN uses the following technologies:

■ Multipoint generic routing encapsulated (mGRE) tunnels: mGRE is an overlay

tunneling protocol that transports multiple protocols such as IPv4, IPv6, IPX
(Internetwork Packet Exchange), and so on. Unlike IPsec VPN tunnels, GRE tunnels
are assigned an actual interface and require addressing on the tunnel interface. Unlike
traditional GRE tunnels which are point-to-point, mGRE supports more than two
devices on the overlay network.
■ Next Hop Resolution Protocol (NHRP): Because of the dynamic nature of
DMVPN, the DMVPN spoke routers need a method to associate the tunnel
endpoint IP address with the transport IP address for other DMVPN routers. NHRP
provides IP resolution to next-hop clients (NHCs) by registering and querying
a next-hop server (NHS). Originally used for mapping IP addresses on .X25
networks, it is now used for resolving the tunnel endpoint addresses to the logical IP
addresses of DMVPN network cloud. The protocol was defined in RFC 2332.
■ IPsec tunnel protection (optional): IPsec uses cryptography to authenticate and
encrypt IP network traffic across networks. It supports Internet Key Exchange (IKE)
v1 and v2, and the Suite-B next-generation encryption technologies.

DMVPN provides the following benefits over traditional site-to-site IPsec VPN:

■ Zero-touch hub: Adding more spoke routers does not require any additional
configuration on the hub router. This simplifies the ongoing maintenance of the hub
routers. Resolution of spoke endpoint IP addressing is accomplished with NHRP.
■ Spoke-to-spoke communication: Phases 2 and 3 of NHRP support dynamic spoke-
to-spoke network connectivity. All the DMVPN routers obtain the benefits of a
full-mesh topology but conserve router resources by creating tunnels between VPN
endpoints only as needed. Spoke-to-spoke communication reduces latency and jitter,
while avoiding consumption of bandwidth at hub locations.
■ Tunnel IP addressing: DMVPN uses GRE tunnels that use IP addressing in the
overlay network. IPv4 or IPv6 addresses can be used in the overlay or to provide
28 Chapter 2: Transport Independence

connectivity in the underlay. Routing protocols can run on top of the DMVPN
tunnel, thereby allowing dynamic network updates versus manually updating the
routing tables when using IPsec VPN tunnels.

Note Some networks use DMVPN as a method of providing IPv6 connectivity across an
IPv4 network.

■ Encryption is optional: The benefits of overlay routing can be obtained with

MPLS L3VPN networks without unnecessary consumption of router resources for
encryption. DMVPN tunnels operating on insecure networks (such as the Internet)
typically encrypt the payload with IPsec technologies.

■ Multicast support: Native IPsec VPN tunnels do not support multicast traffic,
which complicates the ability to transmit multicast traffic from branch sites to
headquarters sites. DMVPN provides multicast support between hub-and-spoke
devices for hub-to-spoke traffic flows.

■ Per-tunnel QoS: DMVPN supports the ability of the DMVPN hub to set different
QoS and bandwidth policies for each tunnel to a spoke router based on the site’s
connectivity model.

Benefits of Transport Independence

All the traditional transports (dial-up, leased circuits, MPLS, and IPsec VPNs) have
advantages and disadvantages. One transport may prefer one routing protocol whereas
a different transport may prefer a different routing protocol. Some transports are not
always available or cost-effective at all locations. Intermixing multiple transports into a
native WAN architecture can result in a complex WAN environment.

Ensuring that the network is always available for business purposes requires that there
not be any SPOFs. Network architects plan for backup circuits that are active only when
the primary circuit fails, or dual circuits that can be used at the same time. Network
architects must also decide on the number of routers at each site, whether a router is
dedicated to each circuit, or if both circuits should connect to the same router.

Using a single router with a single transport provides “three nines” (99.9%) of availability,
which correlates to about four to nine hours of downtime a year. Using a single router
with two transports provides “four nines” (99.995%) of availability, correlating to
26 minutes of downtime a year. Using two routers, each with its own transport, provides
“five nines” (99.999%) of availability, which correlates to five minutes of downtime a
year.

Figure 2-7 depicts a typical scenario for Company ABC, which uses two different
providers and transports because it cannot locate two SPs that provide the same service
at both the branch and headquarters. ABC uses MPLS L3VPN from one SP and creates
an IPsec tunnel across the Internet for a backup circuit. R1 and R2 form an external
BGP (EBGP) session to the MPLS L3VPN provider, and the routers use static routes and
reverse-route injection to send traffic across the IPsec tunnel.
 Benefits of Transport Independence 29

Company ABC’s WAN Network

Static Route

Internet
20 Mbps

IGP R1 R2 IGP
Branch Headquarters
EB MPLS L3 VPN
GP GP
10 Mbps EB

Figure 2-7 Complexities with Multiple WAN Transports

In scenarios like the one shown in Figure 2-7, one transport acts as a primary and the
other as a backup, and there are multiple routing protocols on the WAN routers that
require advanced configuration to ensure that the correct path is taken. The complex-
ity increases when routes are exchanged between IGP (Enhanced IGRP [EIGRP], Open
Shortest Path First [OSPF], and so forth) at each site and the WAN routing protocols,
which could lead to suboptimal routing or routing loops.

A well-designed network architecture should take into account the operational support
staff and reduce complexity where possible. It should account for junior-level engineers
working in the network operations center (NOC) performing day-to-day management of
the network. Redistribution between protocols should be kept to a minimum to prevent
confusion and routing loops. The design should be modular to support future growth
and allow for a simple migration between SPs to address business needs.

DMVPN provides transport independence through the use of full-mesh overlay routing.
This technology allows organizations to use multiple WAN transports, because the
transport type is associated to the underlay network and is irrelevant to the overlay
network. The overlay network is consistent and normalized to the DMVPN tunnel.

Transport independence allows operational consistency for WAN architectures by

providing the following:

■ Single routing domain: Traditional routing protocols were designed to solve

the endpoint reachability problem in a hop-by-hop destination-only forwarding
environment of unknown topology. The routing protocols choose only the best
path based on statically assigned cost. Because DMVPN presents a flat topology,
it provides a consistent topology that allows ECMP load balancing across DMVPN
tunnels.

■ Consistent troubleshooting: The same process can be used for troubleshooting

connectivity for the DMVPN tunnel and the underlay network. Even though the
underlay transport changes, it relies on basic IP connectivity between tunnel
endpoints.
30 Chapter 2: Transport Independence

■ Consistent topology: There is a consistent topology and methodology for deploying

other services such as performance routing.

Figure 2-8 illustrates the same topology as before except that R1 and R2 use a DMVPN
tunnel for each different transport (path). Company ABC can use the same routing
protocol across both paths while maintaining a consistent topology. In addition, it can
change one of the WAN transports at a later time without impacting the overall WAN
design or operational support model.

Company ABC’s WAN Network

DMVPN 1

Internet
20 Mbps

IGP R1 R2 IGP
Branch Headquarters
MPLS L3 VPN
10 Mbps

DMVPN 2

Figure 2-8 Simplification with Transport Independence

Note An example use case for transport independence is when a company deploys a new
branch. Most SPs have a 60- to 90-day lead time for new circuit installation. A company
can immediately deploy a router using a cellular data plan and then switch to the ordered
circuit at a later time with minimal changes to the configuration. The operational support
model remains the same regardless of which WAN transport is used.

Managing Bandwidth Cost

Three common solutions for providing additional bandwidth are

■ Increasing bandwidth to existing primary paths, which can be expensive

■ Deploying additional network circuits, sometimes using low-cost residential circuits

■ Deploying application optimization technologies such as Cisco WAAS

■ Deploying intelligent load-balancing technologies such as PfR

 Benefits of Transport Independence 31

Additional WAN bandwidth improves aggregate throughput but does not improve
end-to-end delay or packet loss for critical applications. Furthermore, additional
bandwidth can be expensive, especially in rural areas where faster connections may not
be available. At the same time, the cost of Internet connectivity is generally decreasing
while reliability is increasing, as shown in Figure 2-9. Enterprises are now qualifying the
Internet transport as an alternative business-class WAN circuit.

Internet Pricing vs. Reliability, 1998–2012

Internet Transit Pricing1
($ per Mbps) Packet Delivery %2
10,000 98
96.6% 96

1,000 $675 94
92
100 90
88
10 86
84
$2.34
83.7%
1 82
98 99 00 01 02 03 04 05 06 07 08 09 10 11 12
Internet Transit Pricing Packet Delivery % (1-Packet Loss %)

1
Internet Transit Pricing based on surveys and informal data collection
primarily from Internet Operations Forums—“street pricing” estimates
2
Packet delivery based on 15 years of ping data from PingER for WORLD
(global server sample) from EDU.STANFORD.SLAC in California
Source: William Norton (DrPeering.net); Standford ping end-to-end reporting (PingER)

Figure 2-9 Traditional WAN, Active/Backup

Leveraging the Internet

Enterprises face a big bandwidth challenge as guaranteed access bandwidth becomes
more costly; they need to determine how to create a secure, reliable, and optimized net-
work. According to Nemertes Research (“Benchmark 2012–2013 Emerging WAN Trends:
The Internet Arises,” July 1, 2013), nearly half (46%) of all businesses are migrating, or
are planning to migrate, their WAN to the Internet for transport. The Internet has become
a much more stable platform, and the price-to-performance gains are compelling.

Offloading network traffic to the Internet can help load-balance best-effort traffic (that
is, lower-priority traffic) across both links to help deal with traffic from business VPN
access. In addition, administrators can use local Internet access for a distributed Internet
access model to offload employee traffic that goes directly to public cloud services (such
as Google Apps, Salesforce.com, Office 365, and so on) from the private WAN altogether.
32 Chapter 2: Transport Independence

This approach uses the Internet connection not just as a backup but as a real component
in dealing with WAN workloads. With the right network technologies to optimize the
flows, administrators can reduce overall WAN transport bandwidth requirements and
improve application performance.

Intelligent WAN Transport Models

Internet- and MPLS-based VPNs are the most common WAN transports. Taking into
account each transport type and the need for redundancy, there are three typical WAN
deployment models:

■ Dual MPLS: The first transport is an MPLS VPN provided by one SP, and a second
MPLS VPN provided by a second SP. Assuming that both providers use the same
type of MPLS VPN (all MPLS L3VPN or all MPLS L2VPN), the same routing
protocol can be used.

■ Dual hybrid: The first transport is an MPLS VPN provided by one SP, and Internet
connectivity is a second transport. The Internet transport can be provided by the
same or a different SP. Ideally the SPs would use different “last mile” circuits and
routers to eliminate SPOFs. The Internet circuit is used to establish a VPN service to
another site.

This model provides connectivity for a distributed Internet model for all or select
Internet-based traffic. It is possible to allow Internet access only for IT-approved
cloud applications.

■ Dual Internet: The first transport is Internet connectivity provided by one SP, and
Internet connectivity is provided by a different SP for resiliency purposes. This
model provides connectivity for a distributed Internet model too and does not have
to be restricted to only VPN tunnels.

Note It is important to understand the BGP best-path algorithm when using multiple
Internet SPs that cannot completely provide connectivity to all your locations. Typically
BGP AS_Path length determines the path a packet takes on the Internet. If you have to use
multiple Internet SPs to provide connectivity for one transport, it may be possible for the
paths to take the same route through a transit Internet SP.

In all three models, deploying a DMVPN tunnel for each transport provides transport
independence and simplifies the routing domain, operational model, and troubleshooting.

Implementing transport independence on existing circuits provides flexibility and

leverage during circuit renewals. Typically, using the Internet as a transport maintains a
lower cost than using an MPLS VPN for a transport and may produce savings to your
company.
 Summary 33

Figure 2-10 illustrates three of the Cisco Intelligent WAN (IWAN) models. Notice the
connectivity to the Internet and cloud-based applications for all three models. Internet
connectivity is available only through the headquarters in dual MPLS, whereas the hybrid
and dual Internet models can provide Internet and cloud connectivity directly at the
branch.

Dual MPLS Hybrid Dual Internet

Headquarters Headquarters Headquarters

Cisco
Webex
Salesforce.com
DMVPN Tunnel 1

DMVPN Tunnel 2

DMVPN Tunnel 1

DMVPN Tunnel 2

DMVPN Tunnel 1

DMVPN Tunnel 2
Internet

Internet

Internet
Cisco Cisco
MPLS

MPLS

MPLS
SP 1

SP 2

SP 1

SP 1

SP 1

SP 2
Webex Webex
Salesforce.com Salesforce.com

R1 R1 R1

Branch Branch Branch

Figure 2-10 Intelligent WAN (IWAN) Models

Note The IWAN architecture does not limit the WAN design to only two transports.
It is possible to use three or more transports to provide a custom solution. For example,
you could use two different SPs providing MPLS VPN transports and a third SP providing
Internet connectivity for a transport. All three transports would use DMVPN to keep the
routing and topology consistent.

Summary
This chapter provided the history and overview of various WAN transports that are
available today. Every WAN transport technology has advantages and disadvantages.
Some remote locations cannot be serviced by an existing SP or provide the same time
of transport as other sites.
34 Chapter 2: Transport Independence

Properly designed network architecture takes into account the skill level of the network
engineers who support and maintain the network. The architecture should be consistent
and scalable to ensure consistency in the environment regardless of the technology. Using
DMVPN on top of the WAN transports provides a consistent operational model and
provides transport independence while

■ Simplifying the WAN with easy multihoming to SPs with a consistent design over all
transports

■ Providing scalable full-mesh connectivity among all DMVPN routers

■ Providing a platform that supports proven robust security and cryptography

■ Providing zero-touch configuration on DMVPN hub routers as branch sites are

added

DMVPN is explained in greater detail in the following chapters.

 Chapter 3

Dynamic Multipoint VPN

This chapter covers the following topics:

■ Generic routing encapsulation (GRE) tunnels

■ Next Hop Resolution Protocol (NHRP)

■ Dynamic Multipoint VPN (DMVPN) tunnels

■ Spoke-to-spoke communication

■ DMVPN failure and detection and high availability

■ DMVPN dual-hub and dual-cloud designs

■ Sample IWAN DMVPN transport models

Dynamic Multipoint VPN (DMVPN) is a Cisco solution that provides a scalable VPN
architecture. DMVPN uses generic routing encapsulation (GRE) for tunneling, Next
Hop Resolution Protocol (NHRP) for on-demand forwarding and mapping information,
and IPsec to provide a secure overlay network to address the deficiencies of site-to-site
VPN tunnels while providing full-mesh connectivity. This chapter explains the underlying
technologies and components of deploying DMVPN for IWAN.

DMVPN provides the following benefits to network administrators:

■ Zero-touch provisioning: DMVPN hubs do not require additional configuration

when additional spokes are added. DMVPN spokes can use a templated tunnel
configuration.

■ Scalable deployment: Minimal peering and minimal permanent state on spoke

routers allow for massive scale. Network scale is not limited by device (physical,
virtual, or logical).
36 Chapter 3: Dynamic Multipoint VPN

■ Spoke-to-spoke tunnels: DMVPN provides full-mesh connectivity while configuring

only the initial spoke-to-hub tunnel. Dynamic spoke-to-spoke tunnels are created as
needed and torn down when no longer needed. There is no packet loss while building
dynamic on-demand spoke-to-spoke tunnels after the initial spoke-to-hub tunnels
are established. A spoke maintains forwarding states only for spokes with which it is
communicating.

■ Flexible network topologies: DMVPN operation does not make any rigid
assumptions about either the control plane or data plane overlay topologies. The
DMVPN control plane can be used in a highly distributed and resilient model that
allows massive scale and avoids a single point of failure or congestion. At the other
extreme, it can also be used in a centralized model for a single point of control.

■ Multiprotocol support: DMVPN supports 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

Network Address Translation (NAT). Spoke routers can use dynamic IP addressing
such as Dynamic Host Configuration Protocol (DHCP).

■ Standardized building blocks: DMVPN uses industry-standardized technologies

(NHRP, GRE, and IPsec) to build an overlay network. This propagates familiarity
while minimizing the learning curve and easing troubleshooting.

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), or IPX. GRE tunnels have been
used as a quick workaround for bad routing designs, or as a method to pass traffic
through a firewall or ACL. DMVPN uses multipoint GRE (mGRE) encapsulation and
supports dynamic routing protocols, which eliminates many of the support issues asso-
ciated with other VPN technologies. GRE tunnels are classified as an overlay network
because the GRE tunnel is built on top of an existing transport network, also known as
an underlay network.

Additional header information is added to the packet when the router encapsulates the
packet for the GRE tunnel. The new header information contains the remote endpoint
IP address as the destination. The new IP headers allow the packet to be routed between
the two tunnel endpoints without inspection of the packet’s payload. After the packet
reaches the remote endpoint, the GRE headers are removed, and the original packet is
forwarded out of the remote router.
 Generic Routing Encapsulation (GRE) Tunnels 37

Note GRE tunnels support IPv4 or IPv6 addresses as an overlay or transport network.

The following section explains the fundamentals of a GRE tunnel before explaining
multipoint GRE tunnels that are a component of DMVPN. The process for configuring a
GRE tunnel is described in the following sections.

GRE Tunnel Configuration

Figure 3-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).

In this topology, R11, R31, and the SP router have enabled Routing Information Protocol
(RIP) on all the 10.0.0.0/8 and 172.16.0.0/16 network interfaces. This allows R11 and R31
to locate the remote router’s encapsulating interface. R11 uses the SP router as a next hop
to reach the 172.16.31.0/30 network, and R31 uses the SP router as a next hop toward the
172.16.11.0/30 network.

Transport Network

10.1.1.0/24 172.16.11.0/30 172.16.31.0/30 10.3.3.0/24

R11 Gi0/1 SP Gi0/1 R31

GRE Tunnel: 192.168.100.0/24

Figure 3-1 GRE Tunnel Topology

Note The RIP configuration does not include the 192.168.0.0/16 network range.

Example 3-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.
38 Chapter 3: Dynamic Multipoint VPN

Example 3-1 R11 Routing Table Without the GRE Tunnel

R11# show ip route

! Output omitted for brevity
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

C 10.1.1.0/24 is directly connected, GigabitEthernet0/2
R 10.3.3.0/24 [120/2] via 172.16.11.2, 00:00:01, GigabitEthernet0/1
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.16.11.0/30 is directly connected, GigabitEthernet0/1
R 172.16.31.0/30 [120/1] via 172.16.11.2, 00:00:10, GigabitEthernet0/1

R11# trace 10.3.3.3 source 10.1.1.1

Tracing the route to 10.3.3.3
1 172.16.11.2 0 msec 0 msec 1 msec
2 172.16.31.3 0 msec

The steps for configuring GRE tunnels are as follows:

Step 1. Create the tunnel interface.

Create the tunnel interface with the global configuration command interface
tunnel tunnel-number.

Step 2. Identify the tunnel source.

Identify the local source of the tunnel with the interface parameter command
tunnel source {ip-address | interface-id}. The tunnel source interface indicates
the interface that will be used for encapsulation and decapsulation of the
GRE tunnel. The tunnel source can be a physical interface or a loopback
interface. A loopback interface can provide reachability if one of the transport
interfaces were to fail.

Step 3. Identify the remote destination IP address.

Identify the tunnel destination with the interface parameter command tunnel
destination ip-address. The tunnel destination is the remote router’s underlay
IP address toward which the local router sends GRE packets.

Step 4. Allocate an IP address to the tunnel interface.

An IP address is allocated to the interface with the command ip address

ip-address subnet-mask.
 Generic Routing Encapsulation (GRE) Tunnels 39

Step 5. Define the tunnel bandwidth (optional).

Virtual interfaces do not have the concept of latency and need to have a
reference bandwidth configured so that routing protocols that use bandwidth
for best-path calculation can make an intelligent decision. Bandwidth is also
used for QoS configuration on the interface. Bandwidth is defined with the
interface parameter command bandwidth [1-10000000], which is measured in
kilobits per second.

Step 6. Specify a GRE tunnel keepalive (optional).

Tunnel interfaces are GRE point-to-point (P2P) by default, and the line
protocol enters an up state when the router detects that a route to the tunnel
destination exists in the routing table. If the tunnel destination is not in the
routing table, the tunnel interface (line protocol) enters a down state.

Tunnel keepalives ensure that bidirectional communication exists between

tunnel endpoints to keep the line protocol up. Otherwise the router must rely
upon routing protocol timers to detect a dead remote endpoint.

Keepalives are configured with the interface parameter command keepalive

[seconds [retries]]. The default timer is 10 seconds and three retries.

Step 7. Define the IP maximum transmission unit (MTU) for the tunnel interface
(optional).

The GRE tunnel adds a minimum of 24 bytes to the packet size to accom-
modate the headers that are added to the packet. Specifying the IP MTU on
the tunnel interface has the router perform the fragmentation in advance of
the host having to detect and specify the packet MTU. IP MTU is configured
with the interface parameter command ip mtu mtu.

Table 3-1 displays the amount of encapsulation overhead for various tunnel
techniques. The header size may change based upon the configuration options
used. For all of our examples, the IP MTU is set to 1400.

Table 3-1 Encapsulation Overhead for Tunnels

Tunnel Type Tunnel Header Size
GRE without IPsec 24 bytes
DES/3DES IPsec (transport mode) 18–25 bytes
DES/3DES IPsec (tunnel mode) 38–45 bytes
GRE/DMVPN + DES/3DES 42–49 bytes
GRE/DMVPN + AES + SHA-1 62–77 bytes
40 Chapter 3: Dynamic Multipoint VPN

GRE Example Configuration

Example 3-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.

EIGRP has a lower administrative distance (AD), 90, and the routers use the route learned
via the EIGRP connection (using the GRE tunnel) versus the route learned via RIP (120)
that came from the transport network. Notice that the EIGRP configuration uses named
mode. EIGRP named mode provides clarity and keeps the entire EIGRP configuration in
one centralized location. EIGRP named mode is the only method of EIGRP configuration
that supports some of the newer features such as stub site.

Example 3-2 GRE Configuration

R11
interface Tunnel100
bandwidth 4000
ip address 192.168.100.11 255.255.255.0
ip mtu 1400
keepalive 5 3
tunnel source GigabitEthernet0/1
tunnel destination 172.16.31.1
!
router eigrp GRE-OVERLAY
address-family ipv4 unicast autonomous-system 100
topology base
exit-af-topology
network 10.0.0.0
network 192.168.100.0
exit-address-family
!
router rip
version 2
network 172.16.0.0
no auto-summary

R31
interface Tunnel100
bandwidth 4000
ip address 192.168.100.31 255.255.255.0
ip mtu 1400
keepalive 5 3