Category Archives: GRE & DMVPN

DMVPN Phase 1, 2 and 3

Limitation of using iBGP between hub & Spoke
– Of we want to exchange routes between spoke & another spoke from that route come in with the iBGP neighbor and we’re not normally allowed to sent it to iBGP neighbor unless we are route reflector.

– If we are running DMVPN phase 3 we don’t even need the above, because the spoke doesn’t need to learn the direct route from spoke to each spoke and only need to learn the “Default route” from the hub and the the hub is going to use the “nhrp redirection” to get then what ever specific route they want.

Configuration Differences:
DMVPN Phase 1
– Static destination address
DMVPN Phase 2
– No Configuration need on hub
– Spoke should have tunnel mode GRE & ip multicast
DMVPN Phase 3
– NHRP redirect which tells the spoke that there’s a shorter path that the spoke can use.
– Enabling shortcut on spoke, Install a shortcut route when received a redirect.
Continue reading

DMVPN Configuration

Template Configuration:
## R1
int g1/0
ip address
no shut
duplex full

## R2
int g1/0
ip address
no shut
duplex full

## R3
int g1/0
ip address
no shut
duplex full

conf t
int range f1/1 – 3
no shutdown

interface tunnel 0
! IP address
ip address

! Bandwidth – Will be part of routing metrics
bandwidth 1000

! Ensures longer packets are fragmented before they are encrypted
ip mtu 1400

! The following line must match on all nodes that “want to use” this mGRE tunnel:
ip nhrp authentication donttell

! Note that the next line is required only on the hub
ip nhrp map multicast dynamic
Note: encapsulating multicast based on encapsulating unicast

! The following line must match on all nodes that want to use this mGRE tunnel:
ip nhrp network-id 99
ip nhrp holdtime 300

! Turns off split horizon on the mGRE tunnel interface; otherwise, EIGRP will not advertised routes that are learned vie the mGRE interface backout that interface.
no ip split-horizon eigrp 1

tunnel source g1/0
tunnel mode gre multipoint
tunnel key 100000

int tunnel 0
ip address
ip nhrp authentication donttell

! Definition of NHRP server at the hub (, which is permantly mapped to the static public address of the hub ( Private / Public address)
ip nhrp map

! Sends multicast packets to the hub router, and enables the use of a dynamic routing protocol between spoke and the hub.
ip nhrp map multicast

! The following line must match on all nodes that want to use this
ip nhrp network-id 99
ip nhrp holdtime 300

! Configures the hub router as the NHRP next-hop server
ip nhrp nbs
ip tcp adjust-mss 1360
delay 1000
tunnel source g1/0
tunnel destination
tunnel key 100000

int tunnel 0
ip address
ip nhrp authentication donttell
ip nhrp network-id 99
ip nhrp map
ip nhrp map multicast
ip nhrp nhs
tunnel source g1/0
tunnel destination
tunnel key 100000

Configuring Dynamic routing protocol:
! Configure on all Hub and spokes
router eigrp 1
no auto-summary




What is DMVPN?
a. Point-to-multipoint Layer 3 overlay VPN
– Logical hub and spoke topology
– Direct spoke to spoke traffic is supported

b. DMVPN uses a combination of…
– Multipoint GRE Tunnels (mGRE)
– Next Hop Resolution Protocol (NHRP)
– IPsec Crypto Profiles
– Routing

Why Use DMVPN?
a. Independent of SP access method
– Only requirement is IP connectivity

b. Routing policy is not dictated by SP
– E.g. MPLS L3VPN restriction

c. Highly scalable
– If properly designed

Note: You can use internet, MPLS, L2VPN but the main implication of this is that you can use any internet connectivity. Some design will put DMVPN on top of MPLS but the main advantage is that transport doesn’t matter. As long as the end points can ping each other they can able to build a tunnel.

How DMVPN Works?
a. DMVPN allows on-demand full mesh IPsec tunnels with minimal configuration through usage of…
– Multipoint GRE tunnel (mGRE)
– Next Hop Resolution Protocol (NHRP)
– IPsec Crypto Profiles
– Routing

b. Reduces need for n*(n-1)/2 static tunnel configuration
– Uses one mGRE interface for all connections
– Tunnel are created on-demand between nodes
– Encryption is optional

Creates on-demand tunnel between nodes
a. Initial tunnel-mesh is hub-and-spoke (always on)
b. Traffic pattern trigger spoke-to-spoke tunnels
c. Solves management scalability problem

Maintains tunnel based on traffic patterns
a. Spoke-to-spoke tunnel is on-demand
b. Spoke-to-spoke tunnel lifetime is based on traffic

Note: If Spoke A and Spoke B and eventually they stop sending traffic, that tunnel will automatically be torn down. So in a control plane scaling point of view we don’t have to have 999 crypto peers if you have dmvpn made of a thousand nodes. You would only have to have the IPsec security association or the actual GRE association with the end point the your currently talking too.

Requires two IGPs: Underlying and overlay
a. Ipv4/Ipv6 supported for both passenger and transport

How DMVPN works – Hup to Spokes
a. Two main components
– DMVPN Hub / NHRP Server (NHS)
– DMVPN Spokes / NHRP Client (NHC)

b. Spoke/Clients register with Hub/Server
– Spokes manually specify Hub’s address
– Sent via NHRP Registration Request
– Hub dynamically learns Spoke’s VPN address & NBMA address

Note: IP over ethernet uses the ARP in order to bind the destination IP and Destination mac address. IN the case of frame relaty we use inverse-ARP to bind a remote IP to a local circuit same thing with ATM. Basically NHRP is the same but it’s binding an IP to IP, Where it figure’s out “How do I actually route this traffic to a private address but the thing is I need a GRE encapsulated in order to get there, so what is the underlay address or what is the NBMA address that I need to put on the destination of the actual IP packet.”

So this is actually the job of the next-hop server is, To tell the client when you want to send a traffic to a particular destination or specifically to a specific spoke what is the mapping between the mapping of underlay address which is NBMA and overlay address which is the VPN address.

c. Spokes establish tunnels to hub
– Exchange IGP routing information over the tunnel

d. Spoke1 knows Spoke2’s routes via IGP
– Learned via tunnel to hub
– Nexthop is spoke2’s VPN IP for DMVPN phase2
– Next-hop is Hub’s VPN IP for DMVPN Phase3

e. Spoke1 asks for spokes2 real address
– Maps next-hop (VPN) IP to tunnel source (NBMA) IP
– Sent via NHRP Resolution Request

f. Spoke to spoke tunnel is formed
– Hub only used for control plane exchange
– Spoke-to-spoke data plane may flow through hub initially

NHRP Important Messages
1. NHRP Registration Request
– Spokes register their NMBA and the VPN IP to NHS
– Required to build the spoke to hub tunnels
2. NHRP Resolution Request
– Spoke queries for the NBMA-to-VPN mappings of the other spokes
– Required to build spoke-to-spoke tunnels
3. NHRP Redirect
– NHS answer to a spoke-to-spoke data-plane packet through it
– Similar to IP redirects, when packet in/out interface is the same
– Used only in DMVPN phase3 to buld spoke-to-spoke tunnels