↓Skip to main content
Hugo’s IT journal

25 - Setup DMVPN

·
ccie notes
Hugo
Author
Hugo
DevOps Engineer based in London
Table of Contents

DMVPN
#

  • Hub and spoke topology
  • Uses multiple GRE tunnels
  • Requirement: All routers are accessible to each other, typically over the internet
  • Allows for easy addition of new spokes without reconfiguring the hub
  • Useful for sites (spoke) with changing public IP addresses

DMVPN Phases:

  • Phase 1: Hub-and-spoke only, no direct spoke-to-spoke tunnels
  • Phase 2: Allows dynamic spoke-to-spoke tunnels
  • Phase 3: Improves routing and tunnel establishment for large-scale deployments

GRE Tunnels:

  • All spokes point to the hub via GRE tunnels
  • Multipoint GRE (mGRE) is used, allowing multiple destinations on a single interface

NHRP (Next Hop Resolution Protocol):

  • Spokes send NHRP registration to the hub
  • Hub creates a mapping table containing:
    • Prefix
    • Spoke’s public IP address (NBMA address)
    • Spoke’s tunnel IP address (next hop)
  • Spokes can query the hub for NHRP resolution to reach other spokes for specific prefix

Phase2
#

(enabled nhs)

  • SpokeA has a specific route for SpokeB’s network, with the hub as the next hop.
  • Before sending traffic, SpokeA initiates an NHRP resolution request to the hub.
  • SpokeA asks, “What’s the NBMA address for the next hop of this specific prefix?”
  • The hub responds with SpokeB’s information.
  • SpokeA then creates a direct tunnel to SpokeB and sends the traffic for the specfic route.

Spoke

interface Tunnel0
ip address 10.1.1.2 255.255.255.0
tunnel source GigabitEthernet1/0
tunnel mode gre multipoint
ip nhrp network-id 1
ip nhrp nhs 10.1.1.3
ip nhrp map multicast 13.13.13.3
ip nhrp map 10.1.1.3 13.13.13.3

hub

interface Tunnel0
ip address 10.1.1.3 255.255.255.0
tunnel source GigabitEthernet1/0
tunnel mode gre multipoint
ip nhrp network-id 1
ip nhrp map multicast dynamic

Phase3
#

Flow:

  • SpokeA sends the initial traffic to the hub without any NHRP resolution.
  • The hub receives the packet and recognizes it should go to SpokeB.
  • The hub initiates NHRP redirects to both SpokeA and SpokeB.
  • This prompts SpokeA and SpokeB to perform NHRP resolution between themselves.
  • SpokeA and SpokeB then create a direct tunnel for subsequent communication.

Hub

ip nhrp redirect
  • This enables the hub to send NHRP redirect messages to spokes.
  • It allows the hub to inform spokes about more optimal paths (shortcuts) to reach other spokes.

Spoke

ip nhrp shortcut
  • This allows spokes to install shortcuts in their routing table.
  • It enables spokes to create direct tunnels to other spokes when informed by the hub.

Phase 2 vs Phase 3
#

  • Resolution process: Phase 2 is prefix-based, Phase 3 is spoke-based
  • Route specificity: Phase 2 requires specific routes, Phase 3 allows summarization
  • NHRP behavior: In Phase 3, hub initiates redirect, spokes resolve between themselves
  • Scalability: Phase 3 is more scalable due to summarization capabilities

Phase 2, hub resolves the specific prefix.

  • IGP is needed to advertise spoke internal networks to the hub
  • Hub maintains specific routes for each spoke network
  • No summarization possible at the hub

Phase 3, hub is resolving the spoke.

  • The hub still knows about networks behind each spoke (via routing protocols)
  • NHRP resolution happens directly between spokes after hub redirection
  • Hub can summarize routes when advertising to spokes
  • Spokes can work with summarized or default routes

Summarization
#

Why summarization cannot be done in phase2?

DMVPN Phase 2:

Hub Routing Table:

  • Specific routes for networks behind each spoke pointing to Spoke’s tunnel IP (not public IP)

Spoke Routing Table:

Initially: (before the spoke-spoke tunnel created)

  • Specific routes for networks behind other spokes pointing to Hub

After spoke-to-spoke tunnel creation:

  • The specific route now updated to the destination spoke’s tunnel IP.

Hub:

  • Can’t summarize routes to spokes
  • Reason: Needs to provide specific routes for NHRP resolution

Spoke:

  • Initially has specific routes pointing to hub
  • After tunnel creation, “updates” these specific routes
  • Can’t use summarization because it needs the initial specific routes

DMVPN Phase 3:

Hub Routing Table:

  • Can have specific routes or summarized routes for networks behind spokes
  • Next-hop: Spoke’s tunnel IP

Spoke Routing Table:

  • Summarized route or default route pointing to the hub
  • Next-hop: Hub’s tunnel IP

Hub:

  • Can summarize routes to spokes
  • Reason: Doesn’t need to provide specific routes for NHRP resolution
  • Hub initiates NHRP redirect, but resolution happens between spokes

Spoke:

  • Can work with summarized or default routes from hub
  • Specific routes are dynamically “installed” (not updated) during spoke-to-spoke resolution
  • These new specific routes take precedence over summarized routes

IPSEC
#

IPsec is commonly used with DMVPN for encryption.

DMVPN uses IPsec to secure the communication between network devices, providing a scalable and flexible VPN solution.

IPsec can be applied to

  • physical interfaces or
  • tunnel interfaces.

The configuration process involves two main phases:

  • IKE (Internet Key Exchange)
  • IPsec.

IKE (Phase 1)
#

IKE (Phase 1) is responsible for negotiating security associations and establishing a secure channel for IPsec.

Components of IKE configuration:

  1. Pre-shared key
  2. IKE policy (how the negotiation works):
    • Lifetime
    • DH (Diffie-Hellman) group
    • Encryption method
    • Authentication method
    • Hash algorithm

Key Exchange Process:

  • Uses Diffie-Hellman (DH) algorithm for secure key exchange
  • Peers agree on hash, encryption method, and DH group
  • Each peer generates private and public keys
  • Public keys are exchanged
  • Shared secret key is generated using own private key and other’s public key

Example:

  • P1 private key + P2 public key = Key1
  • P2 private key + P1 public key = Key1
  • P3 private key + P1 public key = Key2 (different from Key1)

This process ensures that only intended peers can generate the same shared secret.

IPsec (Phase 2)
#

IPsec (Phase 2) uses the secure channel established by IKE to negotiate security associations for data traffic.

Components of IPsec configuration:

  1. Transform set: Defines authentication and encryption methods for data traffic
  2. Crypto map: Associates transform sets with specific traffic and peers

Applying IPsec to Interfaces

Physical Interface:

When applying IPsec to a physical interface, crypto map must specify:

  • IPsec peer
  • Interesting traffic (which traffic should be encrypted)
  • Transform set

Tunnel Interface:

When applying IPsec to a tunnel interface (e.g., GRE tunnel):

As Tunnel interface already defines:

  • Peer (tunnel destination)
  • Traffic (anything routed through the tunnel)

Crypto map doesn’t need to specify:

  • IPsec peer
  • Interesting traffic

AH and ESP
#

There are two protocols in ipsec

  • AH (Authentication Header)
  • ESP (Encapsulating Security Payload)

AH

  • Authenticates the entire IP packet
  • Provides integrity and authentication
  • Does not provide encryption

ESP

  • Authenticates and encrypts the packet payload
  • Does not authenticate the entire IP header
  • Provides encryption, integrity, and authentication

Key Differences

  • ESP provides both authentication and encryption, while AH only provides authentication.

  • We can either use ESP or AH or both (but not common).

  • Using both ESP and AH simultaneously creates additional overhead without significant security benefits in most cases.

  • NAT cannot be used in AH. When NAT changes the IP addresses in the header, it invalidates the AH integrity check.

Whe ESP and AH are used at the same time. The packet looks like

Transform Sets
#

When configuring IPsec, we use transform sets to define the protocols and algorithms. The command crypto ipsec transform-set allows to specify:

  • encryption method (e.g., ESP-xxx)
  • authentication method (e.g. AH-xxx-HMAC, ESP-xxx-HMAC)

xxx usually are md5 / sha2 You’ve outlined the key differences between transport mode and tunnel mode in IPsec. Let’s expand on this to provide a more comprehensive comparison:

Transport vs. Tunnel
#

Transport Mode

  • Insert the ESP header after the IP header
  • Encrypt the rest of the IP packet (payload)

Format:

[IP Header] | [ESP Header] | [TCP/UDP Header] | [Data] | [ESP Trailer] | [ESP ICV]

Tunnel Mode

  • Clone the original IP header
  • Encrypt the entire original IP packet
  • Insert the cloned (new) IP header and ESP header before the encrypted packet

Format:

[New IP Header] | [ESP Header] | [Original IP Header] | [TCP/UDP Header] | [Data] | [ESP Trailer] | [ESP ICV]

If both AE and ESP are used:

[New IP Header] | [AH] | [ESP] | [Original IP Packet] | [ESP Trailer] | [ESP ICV]

GRE + IPSEC
#

Encapsulation Process
#

GRE encapsulates the original packet first:

  1. Original IP packet (internal IP)
  2. GRE header is added
  3. New IP header (tunnel public IP) is added

Format:

[Outer IP header] | [GRE header] | [Inner IP header] | [Original IP packet]

IPsec then processes the GRE packet.

For transport mode, IPsec uses the existing outer IP header from GRE:

  1. ESP header is inserted after the outer IP header
  2. The rest of the packet (GRE header, inner IP header, and original packet) is encrypted

Format:

[Outer IP header] | [ESP header] | [Encrypted: {GRE header, Inner IP header, Original IP packet}] | [ESP trailer] | [ESP ICV]

For tunnel mode, IPsec adds another IP header:

  1. The entire GRE packet is encrypted
  2. A new IP header is added
  3. ESP header is inserted between the new IP header and the encrypted GRE packet

Format:

[Cloned outer IP header] | [ESP header] | [Encrypted: {Outer IP header, GRE header, Inner IP header, Original IP packet}] | [ESP trailer] | [ESP ICV]
  • Transport mode has less overhead as it uses the GRE outer IP header
  • Tunnel mode adds an additional IP header, increasing overhead

Routing
#

  • GRE is for Encapsulation
  • IPSEC is for Protection
  • Actual routing is performed by the router’s routing process.

IPSEC + GRE:

  • IPsec IP Header: Used for internet routing
  • GRE IP Header: Can be a placeholder (loopback) or private IP (no direct reachability)

GRE Tunnel:

  • Not a “real” physical tunnel
  • Always up (unless manually shut down)
  • A logical interface for encapsulation
  • Main reason to is:
    • Supports multicast traffic
    • Allows running of IGP like OSPF, EIGRP cross multiple networks