Category Archives: GRE & DMVPN

DMVPN Configuration

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

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

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

conf t
int range f1/1 – 3
shutdown
no shutdown
exit

HUB:
interface tunnel 0
! IP address
ip address 10.0.0.1 255.255.255.0

! 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

SPOKES:
SPOKES 1
int tunnel 0
ip address 10.0.0.2 255.255.255.0
!
ip nhrp authentication donttell

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

! 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 122.1.1.1

! 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 10.0.0.1
ip tcp adjust-mss 1360
delay 1000
tunnel source g1/0
tunnel destination 122.1.1.1
tunnel key 100000

SPOKES 2
int tunnel 0
ip address 10.0.0.3 255.255.255.0
ip nhrp authentication donttell
ip nhrp network-id 99
ip nhrp map 10.0.0.1 122.1.1.1
ip nhrp map multicast 122.1.1.1
ip nhrp nhs 10.0.0.1
tunnel source g1/0
tunnel destination 122.1.1.1
tunnel key 100000

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

Troubleshooting:

EIGRP IS FLAPPING?
https://community.cisco.com/t5/switching/eigrp-continually-flapping/td-p/1811550
https://learningnetwork.cisco.com/thread/76634
https://community.cisco.com/t5/routing/random-eigrp-peer-termination-received-msgs/td-p/2055665
https://community.cisco.com/t5/switching/eigrp-flapping-retry-limit-exceeded/td-p/1925753

DMVPN

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

Reference:
https://my.ine.com/course/ccie-rs-v5-dmvpn/653eff2c-d05d-4de3-9350-49ce03352299