Advanced DMVPN Deployments

© 2009 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKSEC-3006 1

Advanced DMVPN Deployments

BRKSEC-3006

Frederic Detienne, Distinguished Services Engineer

© 2007 Cisco Systems, Inc. All rights reserved. Cisco Public

Session ID

Presentation_ID 2

Housekeeping

� We value your feedback- don't forget to complete your online session evaluations after each session & complete the Overall Conference Evaluation which will be available online from Thursday

� Visit the World of Solutions

� Please remember this is a 'non-smoking' venue!

� Please switch off your mobile phones

� Please make use of the recycling bins provided

� Please remember to wear your badge at all times including the Party


Agenda

� DMVPN phases

Phase 2 and phase 3 comparison

Shortcut Switching

NHRP forwarding

� Designing with DMVPN phase 3

Basic Scalable Design – passing the 1,000 nodes barrier with a single hub

Dual Homed Scalable Design – hub resilience, beyond 1,000 nodes using IP SLA

Very large scale DMVPN design – limitless aggregation

� Deployment tips and tricks

Using ISAKMP profiles to map users to tunnels

VRF and DMVPN

� Recent DMVPN enhancements

DMVPN and IPv6

Per Tunnel QoS

� GET vs DMVPN


Sessions objectives

� DMVPN phase 2 and 3 comparison

� Large IPsec VPN meshes designs

� Integrating DMVPN with other features

VRF, PKI, IPv6, QoS

� In-depth knowledge of DMVPN is assumed

This includes IKE and IPsec ☺


DMVPN phase 2-3 comparison


Nomenclature – Transport

Spoke 1192.168.0.0/29

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

Spoke 2192.168.0.8/29

Hub192.168.254.0/24Transport

Network

NBMAAddress

DMVPNTunnels


Nomenclature – Overlay

Spoke 1192.168.0.0/29

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

Spoke 2192.168.0.8/29

Hub192.168.254.0/24Overlay network

TunnelAddress

Overlay/PrivateAddresses


Hub192.168.254.0/24

Spoke Registration

Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.1

NHRP table10.0.0.254 � 172.16.254.1

ip address 10.0.0.1 255.255.255.0ip nhrp network-id 1ip nhrp map 10.0.0.254 172.16.254.1ip nhrp nhs 10.0.0.254

ip address 10.0.0.254 255.255.255.0ip nhrp network-id 1

Spoke 2192.168.0.8/29

Regis

tratio

n Req

uest

Regis

tratio

n Req

uest


Hub192.168.254.0/24

Route exchange

Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.1

NHRP table10.0.0.254 � 172.16.254.1

ip nhrp map multicast 172.16.254.1

ip nhrp map multicast dynamic

Spoke 2192.168.0.8/29

Routing tableC 10.0.0.0 � Tunnel0D 192.168.0.0/29 � 10.0.0.1D 192.168.0.8/29 � 10.0.0.2

Routing tableC 192.168.0.0/29 � Eth0C 10.0.0.0 � Tunnel0

Routing tableC 192.168.0.8/29 � Eth0C 10.0.0.0 � Tunnel0

IT DEPENDS !!IT DEPENDS !! IT DEPENDS !!IT DEPENDS !!

Routing U

pdate

Routing U

pdate

Routing U

pdate

Routing U

pdate


Hub & Spoke design

Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.1

NHRP table10.0.0.254 � 172.16.254.1

Spoke 2192.168.0.8/29

Routing tableC 10.0.0.0 � Tunnel0C 192.168.254.0 � Tunnel0D 192.168.0.0/29 � 10.0.0.1D 192.168.0.8/29 � 10.0.0.2

Routing tableC 192.168.0.0/29 � Eth0C 10.0.0.0 � Tunnel0S 172.16.254.1 �� Dialer0D 192.168.0.0/16 �� 10.0.0.254


Hub via transport networkHub via transport network

192.168.0.0/16 encrypted 192.168.0.0/16 encrypted & tunneled to hub& tunneled to hub

Hub192.168.254.0/24


DMVPN phase 2 design style

Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.1

NHRP table10.0.0.254 � 172.16.254.1

Spoke 2192.168.0.8/29

Routing tableC 10.0.0.0 � Tunnel0C 192.168.254.0/24 � Eth0D 192.168.0.0/29 � 10.0.0.1D 192.168.0.8/29 � 10.0.0.2

Routing tableC 192.168.0.0/29 � Eth0C 10.0.0.0 � Tunnel0S 0.0.0.0/0 �� Dialer0D 192.168.0.8/29 �� 10.0.0.2


Tunnels via transport networkTunnels via transport network

Hub192.168.254.0/24

Hub advertises back individual prefixespointing to corresponding spoke.

Lots of individual prefixesLots of individual prefixes


DMVPN phase 2 shortcuts (1)

Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.1

NHRP table10.0.0.254 � 172.16.254.110.0.0.2 �� Spoke 2

192.168.0.8/29




Hub192.168.254.0/24

Resolu

tion R

equest

Resolu

tion R

equest



Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.1

NHRP table10.0.0.254 � 172.16.254.110.0.0.2 �� Spoke 2

192.168.0.8/29




Hub192.168.254.0/24

Resolu

tion R

eply

Resolu

tion R

eply

172.16.2.1



Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.1

NHRP table10.0.0.254 � 172.16.254.110.0.0.2 �� 172.16.2.1 Spoke 2

192.168.0.8/29




Hub192.168.254.0/24



Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.1

NHRP table10.0.0.254 � 172.16.254.1

Spoke 2192.168.0.8/29




Tunnels via transport networkTunnels via transport network

Hub192.168.254.0/24

Hub advertises back summary prefixpointing to hub.

192.168.0.0/16 summary 192.168.0.0/16 summary tunneled to hubtunneled to hub



Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.1

NHRP table10.0.0.254 � 172.16.254.1

Spoke 2192.168.0.8/29




Hub192.168.254.0/24

ip nhrp shortcut

ip nhrp redirect



Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.1

NHRP table10.0.0.254 � 172.16.254.1

Spoke 2192.168.0.8/29




Hub192.168.254.0/24

Indire

ction (1

92.1

68.0.9

)

Indire

ction (1

92.1

68.0.9

)



Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.110.0.0.1 �� 172.16.1.1

NHRP table10.0.0.254 � 172.16.254.110.0.0.2 �� 172.16.2.1192.168.0.8/29 �� 172.16.2.1

Spoke 2192.168.0.8/29




Hub192.168.254.0/24

Resolu

tion (1

92.1

68.0

.9)

Resolu

tion (1

92.1

68.0

.9) Resolution (192.168.0.9)

Resolution (192.168.0.9)

Resolution ReplyResolution Reply

192.168.0.8192.168.0.8/29/29��10.0.0.210.0.0.2��172.16.2.1172.16.2.1



Spoke 1192.168.0.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.2 � 172.16.2.1

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

Physical: 172.16.2.1172.16.2.1Tunnel: 10.0.0.210.0.0.2

Physical: 172.16.254.1172.16.254.1Tunnel: 10.0.0.25410.0.0.254

NHRP table10.0.0.254 � 172.16.254.110.0.0.1 �� 172.16.1.1

NHRP table10.0.0.254 � 172.16.254.110.0.0.2 �� 172.16.2.1192.168.0.8/29 �� 172.16.2.1

Spoke 2192.168.0.8/29




Hub192.168.254.0/24


DMVPN phase 3 data packet forwarding

� Route lookup determines output interface and next-hop

The packet and next-hop are passed to the interface

Assuming the interface is NHRP enabled

� Destination address is looked up in the NHRP cache

If success, use entry to encapsulate

� Next-hop address is looked up in the NHRP cache

Is success, use entry to encapsulate

� Fallback: send packet to configured NHS

Use NHS NHRP entry

Resolve next-hop address via resolution-request

For yourreference


DMVPN phase 3 resolution triggers

� If packet forwarding falls back to NHS

Issue resolution-request for next-hop address (/32)

� If router receives indirection-notification

Aka “NHRP Redirect”

Issue resolution-request for address in notification

A /32 address is looked-up

For yourreference


DMVPN phase 3 resolution forwarding

� Address look up in NHRP cache

If authoritative entry present, answer w/ entry

� Otherwise lookup address in routing table (RIB)

� If next-hop belongs to same DMVPN

i.e. nhrp network-id of next-hop same as incoming request

Treat found next-hop as NHS

Forward resolution-request to next-hop

� If next-hop does not belong to DMVPN

i.e. Network-id is different or interface not NHRP-enabled

Respond with full prefix found in routing table – maybe < /32

For yourreference


Phase 3: Platform Support Summary


Cisco IOS Code and Platform Support

� IOS Code

Phase 1 & 2

12.3(17), 12.3(14)T6, 12.4(7), 12.4(4)T

Phase 1, 2 & 3

12.4(6)T

� Platforms

6500/7600 (12.2(18)SXF4) with VPN-SPA + sup720

No Phase 3 capability yet

7301, 7204/6, 38xx, 37xx, 36xx, 28xx, 26xx,

18xx, 17xx, 87x, 83x

Phase 1, 2 & 3


Dual Homed Spokes Scalable DesignUsing IP SLA


IP SLA and Reliable Static Routing

� IP SLA is an IOS feature to monitor an Service Levels

� Probes are sent to measure network performances

Availability, delay, jitter,…

Probes can be ICMP, UDP,…

� Tracking Objects report the status of SLA probes

Object status goes up or down as the SLA monitor hits triggers

� Routes can be injected based on the Tracking Object

Routes injected when the tracked object is up


Dual homed DMVPN spokes

= Dynamic&Temporary Spoke-to-spoke IPsec tunnels

Single DMVPN Dual HubSingle mGRE tunnel onall nodes

192.168.2.0/24

.1

192.168.1.0/24

.1

192.168.0.0/24.2 .1

Physical: 172.17.0.1Tunnel0: 10.0.0.1

Physical: (dynamic)Tunnel0: 10.0.0.11

Physical: (dynamic)Tunnel0: 10.0.0.12

Physical: 172.17.0.5Tunnel0: 10.0.0.2

Spoke A

Spoke B

. . .

. . . Web

.37

PC

.25


Dual homed DMVPN spokesHub1

interface Tunnel0bandwidth 1000ip address 10.0.0.1 255.255.255.0ip mtu 1400ip nhrp map multicast dynamicip nhrp redirectip nhrp network-id 1tunnel source Serial1/0tunnel mode gre multipointtunnel protection ipsec profile vpnprof

!router rip

network 10.0.0.0passive-interface default

!ip sla responderip sla responder udp-echo ipaddress 10.0.0.1 port 2000

Activateredirection

CommonSubnet

Make RIPPassive

Make hubSLA responder


Dual homed DMVPN spokesHub2

interface Tunnel0bandwidth 1000ip address 10.0.0.2 255.255.255.0ip mtu 1400ip nhrp map multicast dynamicip nhrp redirectip nhrp network-id 1tunnel source Serial1/0tunnel mode gre multipointtunnel protection ipsec profile vpnprof

!router rip

network 10.0.0.0passive-interface default

Activateredirection

CommonSubnet

Make RIPPassive


Dual homed DMVPN spokesSpokes – part 1

interface Tunnel0bandwidth 1000ip address 10.0.0.<x> 255.255.255.0 ! <x> = 11,12,…ip mtu 1400ip nhrp map multicast 172.17.0.1ip nhrp map 10.0.0.1 172.17.0.1ip nhrp map multicast 172.17.0.5ip nhrp map 10.0.0.2 172.17.0.5ip nhrp network-id 1ip nhrp holdtime 360ip nhrp nhs 10.0.0.1ip nhrp nhs 10.0.0.2tunnel source Serial1/0tunnel mode gre multipointtunnel protection ipsec profile vpnprof

router ripnetwork 10.0.0.0network 192.168.<x>.0 !<x> = 1,2,…

Hub2 NHRP

mappings

Activate RIP

Hub1 NHRP

mappings


Dual homed DMVPN spokesSpokes – part 2

� Model shown here makes hub1 primary, hub2 backup

� Track both hubs to make active-active if desired

ip sla 1udp-echo 10.0.0.1 2000 control disabletimeout 1000frequency 1threshold 21000

ip sla schedule 1 life forever start-time now

track 1 rtr 1 reachability

ip route 192.168.0.0 255.255.255.0 10.0.0.1 track 1track 1ip route 10.0.0.0 255.0.0.0 10.0.0.1 track 1track 1

ip route 192.168.0.0 255.255.255.0 10.0.0.2 254ip route 10.0.0.0 255.0.0.0 10.0.0.2 254

ip route 0.0.0.0 0.0.0.0 Serial 1/0

Monitor SLA probes

Poll 10.0.0.1UDP Port 2000

Poll every secondTimeout: 1 secondFail after 21 seconds

Primary routes

When track 1 is up

Floating routes

Kick-in if probes fail

(floating statics)


Large ScaleDMVPNHub & Spoke


Overall solution

SLB balances connectionsOwns virtual IP address

GRE/IPsec tunnels

IGP + NHRP

Spokes

Cluster of DMVPN hubsAggregates user tunnels

HQ network

Server Load Balancer

Hubs

Aggregation router


High level description

� Spokes believe there is a single hub

� NHRP map points to the Load Balancer’s Virtual IP Address

� The Load Balancer is configured in forwarding mode (no NAT)

� All the hubs have the same DMVPN configuration

Same Tunnel interface address

Same Loopback address (equal to the VIP)

� All the spokes have the same DMVPN configuration

Same hub NBMA address

Same NHS


The Load Balancer in general

� The Load Balancer owns a Virtual IP Address (VIP)

� When IKE or ESP packets are targeted at the VIP, the LB chooses a hub

� The hub choice is policy (predictor) based:

weighted round-robin

least-connections

…

� When hub chosen for a “tunnel”, all packets go to the same hub

� stickyness

� Once a decision is made for IKE, the same is made for ESP

� buddying


Topology and addresses

Spoke A192.168.1.1/29 192.168.2.1/29

Load BalancerVIP: 172.17.0.1(no tunnel)

Spoke B

Physical: (dynamic)172.16.1.1Tunnel0: 10.0.0.1


10.1.2.0/24

Loopback: 172.17.0.1Tunnel0: 10.0.255.254/16

Loopback: 172.17.0.1Tunnel0: 10.0.255.254/16

10.1.0.0/24

.1

.2 .3

10.1.1.0/24

.1.3.2

Supernet: 192.168.0.0/16


Load Balancer

� We will use an IOS-SLB

IOS SLB runs on top of c7200 or Catalyst6500

As of today, opt for 12.2S or 12.1E releases

� The LB must be able to do layer 3 and 4 load balancing. Upper layers are useless (encrypted)

� Content Switching Module 3.1 or above will work too but we do not need most of its features (layer 5+)

� ACE is ok but need to disable NAT-T

� Any SLB will do…


IOS SLB performances

� IOS SLB on a Cat6500 (MSFC-2)

Can manage 1M connections w/ 128MB RAM

Can create 20,000 connections per second

Switches packets at 10Gbps (64 bytes)

� IOS SLB on a c7200 (NPE-400)

Can create 5,000 connections per second

Switches packets at ½ the CEF rate (depending on other features)

� Typically not a bottleneck


IOS SLB cluster definition

ip slb probe PINGREAL ping

faildetect 2

ip slb serverfarm HUBS

failaction purge

probe PINGREAL

predictor leastconn

real 10.1.0.2

weight 4

inservice

real 10.1.0.3

weight 4

inservice

Least connections

(default is round-robin)

If all the hubs are equivalent,

the weight is the same for all

For yourreference


IOS SLB VIP definition

ip slb vserver ESPSLB

virtual 172.17.0.1 esp

serverfarm HUBS

sticky 60 group 1

idle 30

inservice

ip slb vserver IKESLB

virtual 172.17.0.1 udp isakmp

serverfarm HUBS

sticky 60 group 1

idle 30

inservice

Same farm Buddying

For yourreference


Monitoring and managing

SLB-7200#sh ip slb connections

vserver prot client real state nat

-------------------------------------------------------------------------------

IKESLB UDP 64.103.8.8:500 10.1.0.2 ESTAB none

ESPSLB ESP 217.136.116.189:0 10.1.0.2 ESTAB none

IKESLB UDP 213.224.65.3:500 10.1.0.2 ESTAB none



SLB-7200#clear ip slb connections ?

firewallfarm Clear connections for a firewallfarm

serverfarm Clear connections for a specific serverfarm

vserver Clear connections for a specific virtual server

<cr>

SLB-7200#sh ip slb reals

real farm name weight state conns

-------------------------------------------------------------------

10.1.0.2 HUBS 4 OPERATIONAL 4

10.1.0.3 HUBS 4 OPERATIONAL 1

For yourreference


interface Tunnel0

bandwidth 10000

ip address 10.0.255.254 255.255.0.0

no ip redirects

ip mtu 1400

ip nhrp map multicast dynamic

ip nhrp network-id 1

ip nhrp holdtime 3600

tunnel source Loopback0

tunnel mode gre multipoint

tunnel protection ipsec profile tp

cdp enable

end

interface Loopback0

ip address 172.17.0.1 255.255.255.255

end

Hub Tunnel configuration

interface FastEthernet0/0

ip address 10.1.0.{2,3} 255.255.255.0

interface FastEthernet0/1

ip address 10.1.1.{2,3} 255.255.255.0

Must be same on all hubsMask allows 216-2 nodes

Must be same on all hubsMask is /32

Physical interface ip addressesunique on each hub


Spoke tunnel configuration

� Basic DMVPN / ODR configuration

interface Tunnel0

ip address 10.0.0.1 255.255.255.0

ip nhrp map 10.0.255.254 172.17.0.1

ip nhrp nhs 10.0.255.254

…

� Remember…

All the spokes have the same configuration


Current status – Tunnel setup

� We now allow spokes to

build a DMVPN tunnel to a virtual hub

NHRP-register to their assigned hub

Spokes

Server Load Balancer

Hubs

Spoke 1 Spoke 2 Spoke 3 Spoke 4

NHRP table10.0.0.1 � 172.16.1.110.0.0.3 � 172.16.3.1

NHRP table10.0.0.2 � 172.16.2.110.0.0.4 � 172.16.4.1

Physical: 172.16.1.1Tunnel: 10.0.0.1

172.16.2.1172.16.2.110.0.0.210.0.0.2

172.16.3.1172.16.3.110.0.0.310.0.0.3

172.16.4.1172.16.4.110.0.0.410.0.0.4


Spoke routing configuration

interface Tunnel0

cdp enable

ip route 0.0.0.0 0.0.0.0 Dialer0

ip route 192.168.0.0 255.255.0.0 10.0.0.1

ip route 10.0.0.0 255.0.0.0 10.0.0.1

Private traffic (summary)� Tunnel 0

Tunnel packet � physical

Activate ODR over tunnel

Spoke A

192.168.1.1/29



RedistributeODR � BGP

Send information to aggregation router

Tunnel packet � physical

Activate ODR over tunnel

Hub Routing Protocol configuration

interface Tunnel0

cdp enable

router odr

distribute-list 1 in

access-list 1 permit 192.168.0.0 0.0.255.255

router bgp 1

redistribute odr

neighbor 10.1.1.1 remote-as 1

neighbor 10.1.1.1 next-hop-self

• Only allow private networks in the routing table

• Prevents recursive routing


HQ network

HQ Edge BGP configuration

router bgp 1no synchronizationbgp log-neighbor-changesaggregate-address 10.0.0.0 255.0.0.0 summary-onlyaggregate-address 192.168.0.0 255.0.0.0 summary-onlyneighbor HUB peer-groupneighbor HUB remote-as 1neighbor 10.1.1.2 peer-group HUBneighbor 10.1.1.3 peer-group HUBneighbor <other hubs> peer-group HUBno auto-summary

Cluster of DMVPN hubsAggregates user tunnelsHubs

Aggregation router

For yourreference


HQ network(10.0.0.0/8)

Runs OSPF – segment in area 1

Edge router OSPF configuration

� OSPF attracts traffic from the HQ � DMVPN

� Floating static route to Null0 discards packets to unconnected spokes

ip route 192.168.0.0 255.255.0.0 Null0 254

router ospf 1

redistribute static

network 10.1.2.0 0.0.0.255 area 1

10.1.2.0/24

For yourreference


Routing protocolsRoute Propagation spoke �� aggregation

HQ network

Spoke 1192.168.0.0/29

Spoke 2192.168.0.8/29

Spoke 4192.168.0.24/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.3 � 172.16.3.1

NHRP table10.0.0.2 � 172.16.2.110.0.0.4 � 172.16.4.1

Routing tableo 192.168.0.0/29 � 10.0.0.1o 192.168.0.16/29 � 10.0.0.3B 192.168.0.0 � 10.1.1.1B 10.0.0.0 � 10.1.1.1

Routing tableo 192.168.0.8/29 � 10.0.0.2o 192.168.0.24/29 � 10.0.0.4B 192.168.0.0/16 � 10.1.1.1B 10.0.0.0 � 10.1.1.1

Routing tableB 192.168.0.0/29 � 10.1.1.2B 192.168.0.8/29 � 10.1.1.3B 192.168.0.16/29 � 10.1.1.2B 192.168.0.24/29 � 10.1.1.3

Spoke 3192.168.0.16/29

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

172.16.2.1172.16.2.110.0.0.210.0.0.2

172.16.3.1172.16.3.110.0.0.310.0.0.3

172.16.4.1172.16.4.110.0.0.410.0.0.4


Hub&Spoke packet flow

HQ network

Spoke 1192.168.0.0/29

Spoke 2192.168.8.0/29

Spoke 4192.168.24.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.3 � 172.16.3.1


Spoke 3192.168.16.0/29

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

172.16.2.1172.16.2.110.0.0.210.0.0.2

172.16.3.1172.16.3.110.0.0.310.0.0.3

172.16.4.1172.16.4.110.0.0.410.0.0.4



NHRP table10.0.0.2 � 172.16.2.110.0.0.4 � 172.16.4.1


Large ScaleDMVPNSpoke – Spoke


Shortcut switching

� Spoke configurations get a single extra line:

interface Tunnel0

ip nhrp shortcut ! that’s it!!

� Hub get an extra line:

interface Tunnel0

ip nhrp redirect ! that’s it!!

� Spokes on a given hub will create direct tunnels

� Spokes on different hubs will NOT create tunnels


Basic spoke-spoke packet flow

HQ network

Spoke 1192.168.0.0/29

Spoke 2192.168.8.0/29

Spoke 4192.168.24.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.3 � 172.16.3.1


Spoke 3192.168.16.0/29

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

172.16.2.1172.16.2.110.0.0.210.0.0.2

172.16.3.1172.16.3.110.0.0.310.0.0.3

172.16.4.1172.16.4.110.0.0.410.0.0.4



NHRP table10.0.0.2 � 172.16.2.110.0.0.4 � 172.16.4.1

red

irect



HQ network

Spoke 1192.168.0.0/29

Spoke 2192.168.8.0/29

Spoke 4192.168.24.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.3 � 172.16.3.1


Spoke 3192.168.16.0/29

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

172.16.2.1172.16.2.110.0.0.210.0.0.2

172.16.3.1172.16.3.110.0.0.310.0.0.3

172.16.4.1172.16.4.110.0.0.410.0.0.4



NHRP table10.0.0.2 � 172.16.2.110.0.0.4 � 172.16.4.1

reso

lution

requ

est

red

irect

NHRP table10.0.255.254 � 172.16.0.1

NHRP table10.0.255.254 � 172.16.0.1



HQ network

Spoke 1192.168.0.0/29

Spoke 2192.168.8.0/29

Spoke 4192.168.24.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.3 � 172.16.3.1


Spoke 3192.168.16.0/29

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

172.16.2.1172.16.2.110.0.0.210.0.0.2

172.16.3.1172.16.3.110.0.0.310.0.0.3

172.16.4.1172.16.4.110.0.0.410.0.0.4



NHRP table10.0.0.2 � 172.16.2.110.0.0.4 � 172.16.4.1

NHRP table10.0.255.254 � 172.16.0.1192.168.16.0/29 �� 172.16.3.110.0.0.3 �� 172.16.3.1

reso

lution

requ

est

NHRP table10.0.255.254 � 172.16.0.110.0.0.1 �� 172.16.1.1192.168.1.0/29 �� 172.16.1.1


Cross-hubs spoke-spoke tunnels

� We want spokes to create direct tunnels even if they are on different hubs

� For this, we link the hubs via a DMVPN

� NOT a daisy chain!!!


Linking the hubs

interface Tunnel1

ip address 10.1.3.2 255.255.255.0

no ip redirects

ip mtu 1400


ip nhrp redirect

ip nhrp map 10.1.3.3 10.1.0.3

tunnel source FastEthernet0/1

end

Same network ID as Tunnel0 !!

Send indirection notifications

10.1.2.0/24

Loopback: 172.17.0.1Tunnel0: 10.0.255.254/16

Loopback: 172.17.0.1Tunnel0: 10.0.255.254/16

10.1.1.0/24

.1.3.2

Tunnel1:10.1.3.3/24

Tunnel1:10.1.3.2/24


Routing across hubs

� Hubs exchange their ODR information directly via BGP

� The exchange occurs over the inter-hub DMVPN

router bgp 1



10.1.2.0/24

Loopback: 172.17.0.1Tunnel0: 10.0.255.254/16

Loopback: 172.17.0.1Tunnel0: 10.0.255.254/16

10.1.1.0/24

.1.3.2

router bgp 1





HQ network

Spoke 1192.168.0.0/29

Spoke 2192.168.8.0/29

Spoke 4192.168.24.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.3 � 172.16.3.1


Spoke 3192.168.16.0/29

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

172.16.2.1172.16.2.110.0.0.210.0.0.2

172.16.3.1172.16.3.110.0.0.310.0.0.3

172.16.4.1172.16.4.110.0.0.410.0.0.4

Routing tableo 192.168.0.0/29 � 10.0.0.1o 192.168.16.0/29 � 10.0.0.3B 192.168.8.0/29 �� 10.1.3.3B 192.168.24.0/29 �� 10.1.3.3B 192.168.0.0 � 10.1.1.1B 10.0.0.0 � 10.1.1.1

Routing tableo 192.168.8.0/29 � 10.0.0.2o 192.168.24.0/29 � 10.0.0.4B 192.168.0.0/29 �� 10.1.3.2B 192.168.16.0/29 �� 10.1.3.2B 192.168.0.0/16 � 10.1.1.1B 10.0.0.0 � 10.1.1.1

NHRP table10.0.0.2 � 172.16.2.110.0.0.4 � 172.16.4.1

red

irect



HQ network

Spoke 1192.168.0.0/29

Spoke 2192.168.8.0/29

Spoke 4192.168.24.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.3 � 172.16.3.1


Spoke 3192.168.16.0/29

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

172.16.2.1172.16.2.110.0.0.210.0.0.2

172.16.3.1172.16.3.110.0.0.310.0.0.3

172.16.4.1172.16.4.110.0.0.410.0.0.4



NHRP table10.0.0.2 � 172.16.2.110.0.0.4 � 172.16.4.1

red

irect

reso

lution

requ

est


172.16.4.1172.16.4.110.0.0.410.0.0.4


HQ network

Spoke 1192.168.0.0/29

Spoke 2192.168.8.0/29

Spoke 4192.168.24.0/29

NHRP table10.0.0.1 � 172.16.1.110.0.0.3 � 172.16.3.1


Spoke 3192.168.16.0/29

Physical: 172.16.1.1172.16.1.1Tunnel: 10.0.0.110.0.0.1

172.16.2.1172.16.2.110.0.0.210.0.0.2

172.16.3.1172.16.3.110.0.0.310.0.0.3



NHRP table10.0.0.2 � 172.16.2.110.0.0.4 � 172.16.4.1

reso

lution

requ

est

NHRP table10.0.255.254 � 172.16.0.110.0.0.1 �� 172.16.1.1192.168.1.0/29 �� 172.16.1.1

NHRP table10.0.255.254 � 172.16.0.1192.168.24.0/29 �� 172.16.4.110.0.0.4 �� 172.16.4.1


Adding hubs


Linking the hubs – option 1

interface Tunnel1

ip address 10.1.3.2 255.255.255.0

. . .

ip nhrp map 10.1.3.3 10.1.0.3

ip nhrp map 10.1.3.4 10.1.0.4

ip nhrp map 10.1.3.5 10.1.0.5

. . .

end

10.1.2.0/24

10.1.1.0/24

.1.4.3

Tunnel1:10.1.3.4/24

Tunnel1:10.1.3.3/24

.2 .5

Create a manual full meshDo the same with BGP…

Tunnel1:10.1.3.5/24

Tunnel1:10.1.3.2/24


Linking the hubs – option 2

interface Tunnel1

ip address 10.1.3.2 255.255.255.0


ip nhrp redirect

ip nhrp map 10.1.3.1 10.1.0.1

ip nhrp nhs 10.1.3.1

end

10.1.2.0/24

10.1.1.0/24

.1.4.3

Tunnel1:10.1.3.4/24

Tunnel1:10.1.3.3/24

.2 .5

Use the edge router asNHRP hubUse the edge as a RR

Tunnel1:10.1.3.5/24

Tunnel1:10.1.3.1/24

Tunnel1:10.1.3.2/24


Large Scale Design Summary

� Virtually limitless scaling w/ automatic load management

� Load balancing AND resilience

� Multiply performances by number of hubs

Tunnel creation rate, speed, max SA’s

� Resilience in N+1

� No need to touch the hubs while adding a spoke

� All spokes have the same configuration

� New hubs can be added/removed on the fly

BGP needs to be told about the new hub

EIGRP may be used instead of BGP � full automatic


Virtual Routing &Forwarding (VRF)


VRF’s very short rehearsal

� VRF’s are virtual routers inside a router

� Each VRF has its own routing table that it does not share with other VRF’s

� An interface can belong to a single VRF at a time

! define VRF red

ip vrf red

! give interfaces to VRF red

interface FastEthernet 0/0

ip vrf forwarding red


Router without VRF

Layer 4

Layer 3

Layer 3helpers

Layer 2

Layer 5+

Loopback Tunnel

IKE AAA …


Forwarding without encapsulation

Layer 4

Layer 3

Layer 3helpers

Layer 2

Layer 5+

RoutingRouting

IKE AAA …


Forwarding with encapsulation

Layer 4

Layer 3

Layer 3helpers

Layer 2

Layer 5+

RoutingRouting RoutingRouting

IKE AAA …


Add VRF’s to the router

ip vrf redred

ip vrf blueblue

ip vrf greengreen


ip vrf forwarding redred



interface Tunnel 0



Router with VRF’s

Layer 4

Layer 3

Layer 3helpers

Layer 2

Layer 5+

VRF Global VRF Red VRF Blue VRF Green

IKE AAA …


Source the tunnel from a VRF


ip vrf forwarding blue

interface Tunnel 0


tunnel source FastEthernet 1/0

tunnel destination …

tunnel vrf blue

Determines how GRE packetsare routed out


VRF tunneling

Layer 4

Layer 3 VRF Global VRF Red VRF Blue VRF Green

IKE AAA …

Layer 3helpers

Layer 2

Layer 5+


Watch out the network ID

interface Tunnel 0


tunnel source FastEthernet 1/0

tunnel destination …

ipip nhrpnhrp networknetwork--id 1id 1

tunnel vrf blue

Several tunnels can share the same nhrp network-idBUT

Any given network-id can only appear in a single VRF


ISAKMP profiles in DMVPN


Purpose of the exercise

� Assume two groups of users

Finance and Engineering

� The hub hosts two DMVPN’s,

On the same the tunnel-source

� Each group of user should access its own DMVPN

And not the other…

� Each DMVPN sits in its own VRF

To fully separate the traffic from each group

� We will use ISAKMP profiles to solve the exercise


Multi-DMVPN on a single hub

Single HUB terminatingTwo distinct DMVPN’s

192.168.0.0/24.1

Physical: 172.17.0.1Tunnel1: 10.0.0.1

Physical: 172.17.0.1Tunnel2: 10.0.1.1


Assume two groups of users

� Group 1 – Engineering

Certificate

Status: Available

Certificate Serial Number: 100

Certificate Usage: General Purpose

Issuer:

cn=blue-lab CA

o=CISCO

Subject:

Name: Router100.cisco.com

o=CISCO

ouou=Engineering=Engineering

Validity Date:

start date: 14:34:30 UTC Mar 31 2004

end date: 14:34:30 UTC Apr 1 2009

Associated Trustpoints: LaBcA

� Group 2 – Finance

Certificate

Status: Available

Certificate Serial Number: 300

Certificate Usage: General Purpose

Issuer:

cn=blue-lab CA

o=CISCO

Subject:

Name: Router300.cisco.com

o=CISCO

ouou=Finance=Finance

Validity Date:

start date: 14:34:30 UTC Mar 31 2004

end date: 14:34:30 UTC Apr 1 2009

Associated Trustpoints: LaBcA

�There is a single CA

�Each user either belongs to ou=Engineering or ou=Finance


What are ISAKMP profiles ?

� ISAKMP profiles map an IKE session to an IPsec SA

� IKE sessions are identified by

Peer identity

VRF

Local-address

� IPsec SA’s can be derived from

a crypto map

an IPsec profile


Certificate maps

� We need to map users to their respective tunnels

� The only useful attribute is the Organization Unit (ou)

crypto pki certificate map engineering_mapengineering_map 10

subject-name co ouou = Engineering= Engineering

crypto pki certificate map finance_mapfinance_map 10

subject-name co ouou = Finance= Finance


Defining the ISAKMP profiles

� We now define one ISAKMP profile per group

� Each ISAKMP profile will match users of a given group

crypto isakmp profile engeng--ikmpikmp--profprof

pki trustpoint LaBcA

match certificate engineering_map

set set isakmpisakmp--profile engprofile eng--ikmpikmp--profprof

crypto isakmp profile finfin--ikmpikmp--profprof

pki trustpoint LaBcA

match certificate finance_map


The IPsec profiles

� Two IPsec profiles are necessary

Each profile maps to a distinct ISAKMP profile

crypto ipsec profile engeng--ipsecipsec--profprof

crypto ipsec transform-set high-security

set set isakmpisakmp--profile engprofile eng--ikmpikmp--profprof

crypto ipsec profile finfin--ipsecipsec--profprof

crypto ipsec transform-set high-security

set set isakmpisakmp--profile finprofile fin--ikmpikmp--profprof


Defining the tunnelsinterface tunnel1

ip vrf forwarding EngineeringEngineering

ip address 10.0.0.1 255.255.255.0

tunnel key 1tunnel key 1


ip nhrp …

tunnel source loopback0

tunnel protection ipsec profile engeng--ipsecipsec--profprof

interface tunnel2

ip vrf forwarding FinanceFinance

ip address 10.0.1.1 255.255.255.0

tunnel key 2tunnel key 2


ip nhrp …

tunnel source loopback0

tunnel protection ipsec profile finfin--ipsecipsec--profprof

Each tunnel linksTo a specific ISAKMPProfile


Session mapping example

IKEEngineering

ISAKMPProfile

FinanceISAKMPProfile

EngineeringTunnel

FinanceTunnel

Incoming sessionCert. authentication

Certificate inspected

Turns out ou=Engineering

IPsec SA’s are linked to the Engineering tunnel


DMVPN IPv6


DMVPN IPv6

� NHRP supports IPv6 since 12.4(20)T

� Feature is very similar to v4 support

Registrations, resolutions,…

Only DMVPN phase 3 is supported – no phase 2 design!!

No VRF support yet due to routing protocols limitations

� Only support for IPv6 over IPv4

All NBMA addresses must be IPv4

� V4 and V6 overlays supported simultaneously


Spoke configuration

� Spoke

interface Tunnel0

ipv6 address fe80::2002 link-local

ipv6 address 2001::2/64

ipv6 nhrp map 2001::1 172.17.0.1

ipv6 nhrp map multicast 172.17.0.1

ipv6 nhrp nhs 2001::1

ipv6 nhrp network-id 1


tunnel source …

tunnel protection ipsec profile …

Unique Link-Local address

Global or Locally Reachable addr.

IPv4 address or interface

Business almost as usual…


Hub configuration

� Hub

interface Tunnel0

ipv6 address fe80::2001 link-local

ipv6 address 2001::1/64

ipv6 nhrp network-id 1

ipv6 nhrp map multicast dynamic


tunnel protection ipsec profile …

tunnel source …

Unique Link-Local address

Global or Locally Reachable addr.

IPv4 address or interface

Business almost as usual…


Subtle differences

Hub#show ipv6 nhrp

2001::2/128 via 2001::2

Tunnel0 created 00:04:47, expire 01:59:49

Type: dynamic, Flags: unique registered used

NBMA address: 1.0.0.2

2001::3/128 via 2001::3


Type: dynamic, Flags: unique registered used


FE80::2/128 via 2001::2


Type: dynamic, Flags: unique registered


FE80::3/128 via 2001::3


Type: dynamic, Flags: unique registered


Global and Link-Localregistered!!

Global and Link-Localregistered!!


Per-tunnel QoS


The need for QoS – the obvious

� QoS is needed for

Sharing network bandwidth

Marshaling applications bandwidth usage

Meeting applications latency and speed requirements

� MQC is a CLI allowing the configuration of

Bandwidth upper limits (policing, shaping)

Bandwidth lower limits (cbwfq)

Low Latency Queuing (priority queuing)


Need for QoS – the greedy spoke

� The greedy spoke calls for a lot of traffic (VoIP calls, DB x-fer,...)

� It overruns the hub CE or the WAN link

Packets are dropped

Starves other spokes

� Greedy spoke downlink gets overloaded and packets are dropped

� damages data throughput, impacts phone conversations…

� We want to limit the amount of traffic sent to each spoke

Crypto engineCrypto engineor Wan linkor Wan link

Spoke 1 Spoke 2

GreedySpoke 3

ISProuter

Interface w/limited downstream rate

Hub


QoS and (DM)VPN – problem statement

� QoS with MQC is complex to deploy with DMVPN

� Static MQC configuration

Long configurations on hubs

Only works with static spoke addresses

� Performances of QoS/MQC is weak with lots of shapers

� Pre-Crypto-Engine QoS is limited

Only priority queuing

� Serious QoS can only be applied after the crypto engine

Classification uneasy after packet encapsulation (DSCP)

Pre-classification not always useful (e.g. NBAR)

Shaping, multiple classes, etc… only in MQC


policy-map childclass routing-protocolbandwidth 100 kbps

class voicepriority 200 kbps

class datapolice 500 kbps

class class-default!policy-map parentclass tunnel1bandwidth 400 kbpsshape average 1mbpsservice policy child

class tunnel2bandwidth 400 kbpsshape average 1mbpsservice policy child

class tunnel3bandwidth 400 kbpsshape average 1mbpsservice policy child

class class-defaultshape average 2mbps

Access-list 101 permit esp hub �� spoke1class-map tunnel1

match access-group 101

Horror MQC policy – DMVPN





Interface GigabitEthernet0/1service-policy out parent

Problem: static and slow

Interface Tunnel0(qos pre-classify optional)

The configuration goes on and on…


Changes to the QoS infrastructure

� MQC stands for Modular QoS CLI

MQC was also the name of the queuing and scheduling infrastructure

� The situation has changed

12.4(15)T introduced CCE

12.4(20)T introduced HQF

� Mostly internal changes but there is an impact

MQC � CLICCE � Common Classification EngineHQF � Hierarchical Queuing Framework


Per-tunnel QoS

� Per Tunnel QoS will apply dynamic per spoke QoS policy on hub

Spokes are be split into groups

Groups are mapped to a QoS template

� HQF / CCE framework will be used

Performances improve over current MQC framework

� The feature will apply to DMVPN and EzVPN dVTI

Not supported for crypto map based designs

� Hub CE and WAN link overruns are rare

WAN link overrun could be addressed with aggregate QoS

� Spoke downlinks overruns are more frequent

Nothing could be done

This is the primary goal of per-tunnel QoS


Per-tunnel QoS high level view

� Classification happens at the tunnel level

Before encapsulation and before the crypto engine

� Policing (dropping) and marking also applied at tunnel

� Queuing and scheduling happen at the physical interface

SA

cla

ssific

ation

CryptoEngine

Tunnel 1 - data

Tunnel 1 - voice

Derived

Inte

rface Q

oS

polic

yTunnel 1policy

Data

Voice

Tunnel 2policy

Data

Voice

Tunnel 2policy

Data

Voice

Tunnel 2 - data

Tunnel 2 - voice

Tunnel 3 - data

Tunnel 3 - voice

PhysicalInterface

Hierachical queueing per Tunnel QoS policy Classification

QoS Policy policing, marking


More per-tunnel QoS information

� Performances depend on

The number of tunnels

The number of active shapers

� Policy Provisioning via CLI and AAA

� Available on 7200 and 3800

Catalysts will require next-generation VPN hardware (5g)

ASR agenda still TBD


Provisioning DMVPN QoS

group 1

interface Tunnel0

ip nhrp group <name1>

interface Tunnel0

ip nhrp map group <name1> service policy output PM1

ip nhrp map group <name2> service policy output PM2

Group 2

interface Tunnel0

ip nhrp group <name2>

Sp

ok

es

policy-map PM1

class class-default

shape average 1000000

Policy-map PM2

class class-default


Offer 1 Mbps to each tunnelOffer 1 Mbps to each tunnel

Offer 500 kbps to each tunnelOffer 500 kbps to each tunnelHU

B


QoS policy limiting tunnel bandwidth

� Hubclass-map Control

match ip precedence …

class-map Voice


policy-map PM1

class class-default


interface Tunnel0

ip nhrp map group G1 service-policy output PM1

Offer 1Mbps to each tunnel


Hierarchical shaper

� Tunnel bandwidth parent policy

Each tunnel is given a maximum bandwidth

A shaper provides the backpressure mechanism

� Protected packets are processed by the client policy

There would be several policies: bandwidth, llq, etc.


QoS policy limiting tunnel bandwidth

� Hubclass-map Control


class-map Voice


policy-map PM1

class class-default


service-policy SubPolicy

policy-map SubPolicy

class Control

bandwidth 20

class Voice

priority percent 60

Offer 1Mbps to each tunnel

20Kbps guaranteed to Control

LLQ for voice


DMVPN vs.GET VPN


GET VPN in a nutshell

� GET VPN introduces two entities

Group Members (GM)

Key Servers (KS)

� GM’s register to KS’ using IKE and GDOI

GDOI is Group-IKE or “IKE for multicast”

� KS’ send the same Traffic Encryption Key to the GM’s

The GM’s use that TEK to encrypt/decrypt data packets

� Data packets are encapsulated in ESP

� … but the IP header is preserved


10,000 feet over GET VPN

192.168.3.0/24

.1

192.168.1.0/24

.1

192.168.0.0/24.1

Group Member

Web

.37

PC

.25

Key server

192.168.2.0/24

.1

Web

.37

TEKTEK

TEKTEK

TEKTEK

TEKTEK

TEKTEK

IP(sIP(s==PC,dPC,d=Web) TCP…=Web) TCP…

IP(sIP(s==PC,dPC,d=Web) TCP…=Web) TCP…IP(sIP(s==PC,dPC,d=Web) ESP …=Web) ESP …


Scopes of DMVPN and GET VPN

� DMVPN is an overlay VPN

� Creates tunnels over the transport network

Isolates protected networks from transport network

Allows private protected addresses over a public transport network

� Hubs concentrate connections – all spokes must connect

Hubs concentrate part of the spoke-spoke traffic

Hubs need to know about all the private networks � RP scale

� Multicast requires replication before encryption – usually on hubs

� GET VPN is a “proxy VPN”

� Encrypted packets have the same addresses as the protected packets

Does not isolate address spaces – requires end-to-end routing

� KS concentrate connections – all GM must connect

KS do not concentrate any traffic

� Transport network takes care of routing packets

� Multicast can happen in the core if core supports it


GET and DMVPN not enemies

� GET only works if protected addresses are routable

Usually recommended over an other (Virtual) Network (MPLS)

Core needs to be multicast aware for mcast to work at all

� When the transport network is optimized � GET has a lead

� When the transport network is “dumb” � DMVPN just works

� Some designs link GET and DMVPN

Making DMVPN hubs also Group Members

DMVPN over Internet links to GET over MPLS

Takes the best of both worlds


12.4 T DMVPN New Features Summary


DMVPN Enhancements

NAT and static PAT now supported

� 12.4(9)T

NAT/PAT not possible in spoke-spoke designs

NHRP resolution requests forwarding

� Simplified hub network design

� Improved resiliency.

� 12.4(6)T

Complex interconnection of Hubs to expand DMVPN Spoke-to-Spoke Networks.

Packets CEF switched via hub

� Reduced latency during call setup

� 12.4(6)T

Delays in setting up voice calls between spokes.

Shortcut switching introduced

� Route summarization now possible

� Higher scalability

� 12.4(6)T

Large routing tables at spokes sometimes caused network instability.

New Feature & Associated BenefitsPrevious Limitation

For yourreference


Per-tunnel QoS introduced

� 12.4(22)T

Complex QoS configuration. Not working well with dynamic spoke NBMA’s.

DMVPN IPv6

� Allows IPv6 in the overlay network

� 12.4(20)T

Limited to IPv4

NHRP MIB

� Monitoring of NHRP tables via SNMP

� 12.4(20)T

Network monitoring difficult or impossible

DMVPN debug enhancements

� All tables with a single show command

� Per-peer debugging also possible

� 12.4(9)T

Complex troubleshooting

New Feature & Associated BenefitsPrevious Limitation

For yourreference

DMVPN Enhancements


Session Summary


Shortcut switchingRouting protocols revisited

� OSPF does not bring anything new

Same requirements as in phase 2

� EIGRP can be tuned to summarize routes to spokes

Number of neighbors increases – still requires attention

� ODR can now be used for spoke-to-spoke configs

1200 neighbors possible

� RIP passive can now be used for spoke-to-spoke

1500 neighbors possible

� Different protocols can be used between hubs and between hub-spoke


Summary

� Phase 3 subtly different from phase 2

Most visible on the routing topology

� Shortcut switching helps picking the best protocol

Usually, the choice relates to scalability

� DMVPNv6 is now a reality

one more step in the right direction

� Per-SA QoS finally made it

� ISAKMP profiles enhance security of multi-DMVPN

Very useful for VRF separation


Recommended Sessions


Recommended sessions

� Server Load Balancing Design

BRKAPP-2002 by Floris Gransvarle

� Advanced IPsec with GET VPN

BRKSEC-3011 by Frederic Detienne

� Advanced Topics in Encryption Standards and Protocols

BRKSEC-3014 by Frederic Detienne


Q and A

© 2007 Cisco Systems, Inc. All rights reserved. Cisco Public

Session ID

Presentation_ID 118

Meet The Expert

To make the most of your time at Cisco Networkers 2009, schedule a Face-to-Face Meeting with a top Cisco Expert.

Designed to provide a "big picture" perspective as well as "in-depth" technology discussions, these face-to-face meetings will provide fascinating dialogue and a wealth of valuable insights and ideas.

Visit the Meeting Centre reception desk located in the Meeting Centre in World of Solutions


Documents

Advanced DMVPN Deployments