DMVPN Overview
Linkedin: [Link]
5
DMVPN Overview
*MarketingJargon Optional
□ Point-to-Multipoint Layer 3 VPN
□ Hub/Spoke Topology
□ Supports Multiple Passenger Protocols
□ Scalable Connectivity
Linkedin: [Link]
6
DMVPN Components
□ Generic Routing Encapsulation (Specifically mGRE)
□ Next-Hop Resolution Protocol
□ Dynamic Routing Protocols
□ Crypto IPSec (Optional but recommended through insecure transport)
Linkedin: [Link]
7
DMVPN Topology
Linkedin: [Link]
8
Generic RoutingEncapsulation
Linkedin: [Link]
9
GRE:What is it Good For?
□ Transport the untransportable – IPv6 over IPv4 transport or vice versa as an
example
□ Virtual network adjacency – Supporting some legacy application protocols and
solutions
□ Routing manipulation – Path preference and traffic engineering
Linkedin: [Link]
10
GRE: How Does it Work?
□ A logical GRE tunnel interface is created on two device endpoints. This logical tunnel requires
that an interface be defined as the source of the GRE tunnel. This can be a physical or logical
interface, but can not be itself.
□ A tunnel destination is also configuredon the GRE Tunnelinterface*. This destination IP address
must be routable in order for the tunnel to go from a down to up status and allow traffic to be
routed throughthe tunnel.
□ When each tunnel source and destination is routable from the other, the GRE tunnel comes up
andtraffic can be directed into the tunnel by any method, be it IGP/EGP or static routing.
* Multipoint GRE does not need a tunnel destination configured,and will be discussed later
Linkedin: [Link]
11
GRE: How Does it Work?
□ When the next-hopof a packet is througha GRE tunnel, the router encapsulatesthe packet in a
GRE header which includes the entire original packet, preserving the source/destination of that
original packet. While that GRE-encapsulated packet traverses the infrastructure to the tunnel
destination, the originalpacket is not consultedfor routingdecisions.
□ When the GRE-encapsulatedpacket reaches the tunnel destination,the GRE header is stripped
andthe remote endpointmakes a routingdecision based on the originalpacket destination.
Linkedin: [Link]
12
GRE: Flying The Friendly Skies
GRE Tunneling is like being a passenger
on an airplane
Passengers fly over the infrastructure
from hop to hop, or from airport to
airport, without being aware of the
supporting infrastructure or conditions
outside
Linkedin: [Link]
13
GRE: Underlay [Link]
□ Overlay networkrefers to the network
virtualizationthat is achieved by
abstractingthe details of the underlay
networkfromthe passenger protocolin a
GRE tunnel.
□ Underlay networkrefers to the true
network infrastructure and layout which
serves as transport for the overlay
networkendpoints to reach each other.
Linkedin: [Link]
14
GRE Tunnel Checklist
✓ Tunnel interface created – Number is locally
significant
✓ TunnelIP addressing configured for overlay
network
✓ Tunnel source selected – IP or interface
✓ Tunnel destination selected – IP only*
✓ (Optional) Tunnel Key – Needed if sourcing
multiple GRE tunnels from same interface
✓ Verify reachability between tunnel source and
destination
* Except in case of GRE multipoint
Linkedin: [Link]
15
Anatomy of a GRE Packet
Linkedin: [Link]
16
Multipoint GRE □ Multipoint GRE works the same as traditional
GRE with some exceptions
□ With multipoint GRE, there is no tunnel
destination configuredbecause the same tunnel
can have multiple destinations
□ Multipoint GRE relies on another mechanism to
determine tunnel destinations such as NHRP in
the DMVPN model
□ With multipointGRE, the same logicaltunnelcan
have multiple endpoints instead of needing a
separate tunnel interface per endpoint
□ The use of multipointGRE is central to the
scalability and dynamicnature of DMVPN
Linkedin: [Link]
NHRP and DMVPN
17
Linkedin: [Link]
18
Next-Hop Resolution Protocol
□ NHRP is a protocol which provides a function
similar to ARP in broadcast networks, but across
a non-broadcast medium
□ By having hubdevices in the DMVPN topology
configured as Next-Hop Servers, and spoke
devices configured as Next-Hop Clients, a
mechanism exists to dynamically learn underlay
addresses
Linkedin: [Link]
19
NHRP:What is it Good For?
□ Facilitate direct spoke-to-spoketraffic flows to avoid hairpin or suboptimal routing
□ Extends scalabilityof DMVPN by ensuring that hub devices do not need separate configuration for
eachspoke device
□ Provides the gluethat allows multipoint GRE tunnelsto be built
Linkedin: [Link]
20
NHRP:How Does it Work?
□ Typically, at least one router is configured as the Next-Hop Server, which will register the
underlay/overlay addresses of the Next-HopClientsandkeepa table of registrations. In the case
of DMVPN, the hub is configuredas the server andspokes as clients.
□ Spoke routers are configuredwith the underlay andoverlay addresses of the NHS. There can be
multiple NHS configured, as well as NHS priority and other NHRP features to aid in NHS
selection.
□ Spoke routers will attempt to communicate with the configured NHS and register their
underlay/overlay addresses to that NHS. If the spokerouter needs to builda GRE multipoint
tunnel to an another spoke, it will request the underlay information from the NHS which
matches the overlay address needed to route traffic.
Linkedin: [Link]
21
NHRP:Let’s Book a Flight
NHRP is similar to bookinga flight on a travel
website
Airlines register their flights and destinations with
the travel website, andwhen a customer wants to
go to a destination,they query the travel website for
the best flights to get there
Since the airlines registered their flights, the travel
website can return best matches to the customer
for tripplanning
Linkedin: [Link]
22
NHS Checklist
✓ NHRP Multicast Mapping – Replicated unicast to
support pseudo-multicast
✓ NHRP Network ID – Differentiates NHRP NBMA
networks
✓ NHRP Authentication (Optional) – Authenticates
spokes/hubs
✓ NHRP Redirect (Optional) – Similar to IP redirect,
facilitates spoke-to-spoke traffic flows
Configuration required on the hub is minimal by design
in order to be as dynamic as possible
Linkedin: [Link]
23
NHC Checklist
✓ NHRP Multicast Mapping – Map multicast traffic to NHS
underlay address
✓ NHRP NetworkID – Differentiates NHRP NBMA networks,
must match NHS
✓ NHRP NHS Mapping – Static mapping of NHS underlayIP
addressto overlay IP address
✓ NHRP Authentication (Optional) – Authenticates spokes/hubs
✓ NHRP Shortcut (Optional) – Works in conjunction with NHRP
Redirect to facilitate spoke-to-spoketraffic flows
Linkedin: [Link]
24
NHS Registration Dissected
Linkedin: [Link]
25
NHS Registration Dissected
Linkedin: [Link]
26
Routingand DMVPN
Linkedin: [Link]
27
Routing With DMVPN
Routing With DMVPN carries specific design
considerationsdependingon the routingprotocol
used.
□ Will the routing protocolbe using unicast or
multicast to form neighbors?
□ Does the routing protocolsupport different next-
hopaddresses?
□ What per-neighbormetrics(if any) are supported?
□ On the NHS/Hub routers, how will neighbors
scale from a control plane perspective?
Linkedin: [Link]
28
DMVPN Routing:
How Does It Work? □ DMVPN routing is a hub-and-spoke flow in the control
plane
□ Spokes will form routing adjacencies with hubs but not
other spokes, and will learn route advertisements from the
hubrouters
□ In the data plane, traffic will be initially sent to the hub, but
subsequent flows will be sent directly from spoke to spoke
via two methods:
• NHRP Redirect/Shortcut will be used to trigger spoke-
to-spoke traffic flow
• Alternatively, the IP next-hop of advertised routes can
be preservedfrom spoke to hubto spoke,in orderto
trigger spoke-to-spoke traffic flows
Linkedin: [Link]
29
DMVPN Routing with EIGRP
□ Hellos will be sent to the hub because of NHRP [Link] a hub may have thousands of
neighbors,some timer tuningis needed to scale the control plane effectively
□ Scalingthe EIGRP Query Domainwith DMVPN is important – This is usually accomplishedwith a summary-
address toward spokes on the hub router andalso by settings spokes as EIGRP stub
□ From the hub perspective, metrics cannot be changed on a per-spoke basis without moving the spoke to an
entirely different DMVPN tunnel interface. Offset-lists and delay can be applied only to the tunnel interface,
which affects all spokes
□ Disable split-horizonin order to allow route updates to propagate between spokes if not using
summarization
□ Considerusing a differentEIGRP AS for the DMVPN network for traffic engineeringpurposes
Linkedin: [Link]
30
DMVPN Routing with OSPF
□ Hellos will be sent to the hub because of NHRP [Link] a hub may have thousands of neighbors,
some timer tuningis needed to scale the control plane effectively
□ Under normal circumstances, all OSPF routers within an area share an identicalcopy of the link-statedatabase,
andwith DMVPN, all routers are in the same area due to sharing the same IP subnet
□ Because of this, scaling is a [Link] DMVPN spoke routers should be totally stubby or totally not-so-
stubby if possible to aidscalingof the LSDB
□ OSPF network type is integralto DMVPN design
• Point to Multipoint: Increases routing table with host addressing but is preferred due to simple configuration
• Point to Point / P2MP: Spokes run P2P andHubs run P2MP; OSPF timers must be adjusted
• Broadcast / Non-Broadcast: Not preferred, only needed if NHRP Redirect/Shortcutisn’t supported
• All network types exceptBroadcast support per-neighbormetric manipulationon the hub
□ Routing changeson spoke routers can trigger an SPF recalculationfor all DMVPN routers, for this reason OSPF
is not preferred for large-scale DMVPN deployments
Linkedin: [Link]
31
DMVPN Routing with BGP
□ Largest routingdecisionto make with using BGP over DMVPN is whether to use iBGP or eBGP
□ eBGP:
• Uses BGP’sbuilt-inloop-preventionmechanism
• AS-Path typically used to help path preferenceacross DMVPN
• Requires far more BGP configurationon hubper spoke
• Each hub and spoke requires its own BGP AS, or configurationon each hub to breakloop prevention in order to
advertise spoke routes to other spokes
□ iBGP:
• Better scaling for neighbors(dynamicBGP neighborspossible on hub, simple configuration)
• Local Preference can be used to set path preference across the DMVPN
• Hub will typically be a route-reflector and spokes will be clients
• All spokes peer with hub over BGP using next-hop-selfto modify next-hop
• Hub doesn’trequire next-hop-self,but if configured,it can still trigger spoke/spoketunnels using NHRP
Redirect/Shortcut
Linkedin: [Link]
32
Routing: Air Traffic Control
In the DMVPN model,routingprotocols act as air
traffic control in the controlplane
Planes do not have to reach their destinations
throughthe ATCtowers, but will ask ATCon which
flight plans are available
ATCdirects the planes on the best paths to take to
reach the destination
Linkedin: [Link]
33
Crypto IPSEC and DMVPN
Linkedin: [Link]
34
IPSEC With DMVPN
Because the IP transport for DMVPN is often over a
third-party unsecure network (ie,the Internet) there is
a need to encrypt traffic. For this reason, Internet Key
Exchange andIP Security were created
□ IPSEC transport modepreferred to tunnel mode
in DMVPN because GRE is already providing
tunneling
□ No needfor staticcrypto maps with DMVPN
because crypto is based on traffic enteringthe
GRE tunnel
□ IPSEC tunnel protection profiles simply encryption
configuration
Linkedin: [Link]
35
IPSEC: How Does It Work?
□ IPSEC encrypts the entire payloadof a packet in order to
provide confidentiality and integrity to the data within
□ IPSEC parameters must be configuredon each router in
orderto choose common encryptionmethods
□ Authentication can be providedby pre-sharedkeys or
digital certificates
□ Because the establishment of an IPSEC tunnel starts with
unencrypted data, there is first an IKE Phase 1 negotiation
to establish the secure channel to negotiate the IPSEC
tunnel, followed by an IKE Phase 2 negotiation to create
the tunnel itself
Linkedin: [Link]
36
IPSEC in Action: Setup
□ Tunnel Setup: Traffic to be encrypted is forwarded to the
GRE tunnel
□ IKE Phase 1: Authenticate peer and negotiate IKE security
associations, set up a secure channel for IKE Phase 2
□ IKE Phase 2: Negotiate SA parameters, set up matching
IPSEC SA for peer
□ Data transfer, encryptionbased on IPSEC parameters
negotiated and active SA
□ Tunnel Termination: SA terminates throughdeletionor
timeout after traffic flow completes
Linkedin: [Link]
37
IPSEC in Action:Ping Between Spokes
Linkedin: [Link]
38
IPSEC: Engage Stealth Mode
No aircraft is completely invisible,just as packets are
not invisibleon the wire
Stealth aircraft rely on low radar profile andactive
measures to minimizedetection,just as encrypted
packets rely on a strong encryption algorithm to
protect the data inside
Linkedin: [Link]
39
DMVPN Design Challenges
Linkedin: [Link]
40
Solution:
Front Door VRF
Problem:
Underlay/Overlay
Route Table Fusion
Linkedin: [Link]
41
Front Door VRF: What Is It Good For?
□ Neededto separate the routing table of the underlay andoverlay networks
□ Allows default routing on hub for dynamic tunnel establishmentwithout overriding a preferred
defaultroute for spokes
□ Allows underlay network traffic flow to be different than overlay network traffic flow if desired
Linkedin: [Link]
42
Front Door VRF:Why Do We Need It?
Linkedin: [Link]
43
Front Door VRF:Why Do We Need It?
Linkedin: [Link]
Problem: Route
44
Recursion Causes
Tunnel to Bounce
Solution: Selective
Advertisement
ThroughTunnel
Linkedin: [Link]
45
Route Recursion in DMVPN Explained
□ In this example, DMVPN tunnels are built using Loopback as tunnel source
□ Underlay IGP provides reachability between tunnel endpoints
□ Overlay eBGP advertises all networks (including tunnel endpoints)
□ Routers learn path to tunnel endpoints with better AD through the tunnel and updateRIB
Linkedin: [Link]
46
Route Recursion in DMVPN Explained
□ Issue is that the underlay address of the tunnel endpoint is now thought to be best reachable
through overlay tunnel
□ When CEF does route-lookup for GRE-encapsulated packet, exit interface will be the GRE
tunnel itself
□ Tunnel will be torn down because underlay reachability is lost, until route convergence causes
the best path to tunnel endpoint to be through the underlay again
□ When tunnel is rebuilt and routing adjacenciesrecovered, the issue will repeat until the tunnel
endpoints are no longer advertised through the tunnel, longest match is through underlay
only, or AD is changedto prefer underlay instead
Linkedin: [Link]
Problem: One or
47
More Devices
Using NAT
Solution: NAT
Traversal (NAT-T)
Linkedin: [Link]
48
IPSEC NAT Traversal in DMVPN Explained
□ Since NAT changes the source address of a packet, it breaks the integrity/authenticity
principles of IPSEC
□ DMVPN routers can detect if one or more endpoints are behind a NAT when starting the
crypto setup between them by checking the result of a NAT-T probe, which includes a hash of
the source/destinationIP/port.
□ If the NAT-T probe’s hashes do not match on both ends, it is understood that NAT took place
somewhere along the path and NAT Traversal is needed
□ If NAT-T is to be used, IPSEC packets are encapsulated in a UDP packet using port 4500,
which allows the NAT device to process the packet without touchingthe IPSEC header within
andthereby retainingauthenticity/integrity
Linkedin: [Link]
49
DMVPN Designs
Linkedin: [Link]
50
Single Hub DMVPN
□ Benefits:
• Simple DMVPN Configuration
• Simple routing configuration
□ Weaknesses:
• Single point of failure
• One hub must have all control plane adjacencies
• Any traffic destined behind the hub has only a
single path to take, could lead to congestion if
spokes all need resources behindhubat same time
Linkedin: [Link]
51
Single Hub Dual Cloud
DMVPN
□ Benefits:
• Redundant paths
• Easier to set path preference per-DMVPN
• Can load balance traffic destined from/to network
behindhub
• Failover time is based on routing convergence only
□ Weaknesses:
• Routing design can be complicated,loops possible
• More tunnel interfaces per spoke needed
• More IP addressing required, different subnets per-
DMVPN
Linkedin: [Link]
52
Dual Hub Single Cloud
DMVPN
□ Benefits:
• Redundant DMVPN hubs
• Simpler routingconfiguration
• Can load balance traffic destined from/to network
behindhubs
• Less IP addressing required, fewer tunnel
interfaces
□ Weaknesses:
• Path preference, if desired, affects all spokes
because metric must be adjusted per hub
• More complicated hub andspoke configuration
Linkedin: [Link]
53
Hierarchical DMVPN
□ Benefits:
• Excellent scale for control plane and spokes
• Regional hubs can connect with central hub instead
of full mesh of hubs
• Potential to addmultiple hubs per region or
centrally to increase redundancy further
□ Weaknesses:
• Very complicated design, only needed to scale to
very high number of spokes
• More complicated hub configuration
• More complicated routingdesign
Linkedin: [Link]
Linkedin: [Link]