Advanced DMVPN Deployments PDF

Advanced DMVPN
Deployments
BRKSEC-3006
Frederic Detienne, Distinguished Services Engineer
BRKSEC-3006 © 2009 Cisco Systems, Inc. All rights reserved. Cisco Public 1
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
Session ID
Presentation_ID © 2007 Cisco Systems, Inc. All rights reserved. Cisco Public 2
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
NBMA
Hub
Transport 192.168.254.0/24
Address
Network
Physical: 172.16.254.1
Tunnel: 10.0.0.254
Physical: 172.16.1.1 Physical: 172.16.2.1

Tunnel: 10.0.0.1 Tunnel: 10.0.0.2
Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29
DMVPN
Tunnels
Nomenclature – Overlay
Hub
Tunnel
Overlay network 192.168.254.0/24 Address
Physical: 172.16.254.1
Tunnel: 10.0.0.254

Tunnel: 10.0.0.1 Tunnel: 10.0.0.2
Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29
Overlay/Private
Addresses
Spoke Registration
ip address 10.0.0.254 255.255.255.0
ip nhrp network-id 1
Hub
192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
st
Tunnel: 10.0.0.254
e
equ
R
n
t io
ra
ist
Physical: 172.16.1.1 Reg Physical: 172.16.2.1
Tunnel: 10.0.0.1 Tunnel: 10.0.0.2
NHRP table NHRP table

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29
ip address 10.0.0.1 255.255.255.0

ip nhrp map 10.0.0.254 172.16.254.1
ip nhrp nhs 10.0.0.254
Route exchange
Routing table
C 10.0.0.0 Tunnel0 ip nhrp map multicast dynamic
D 192.168.0.0/29 10.0.0.1 Hub
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
Tunnel: 10.0.0.254
a
attee
d
pd
UUp
gg
t
t iinn
uu
RRoo Physical: 172.16.2.1
Physical: 172.16.1.1
Tunnel: 10.0.0.1 Tunnel: 10.0.0.2

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29
Routing table Routing table

C 192.168.0.0/29 Eth0
ip nhrp map multicast 172.16.254.1 C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
IT DEPENDS !! IT DEPENDS !!
Hub & Spoke design
Routing table
C 10.0.0.0 Tunnel0
C 192.168.254.0 Tunnel0
D 192.168.0.0/29 10.0.0.1 Hub
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
Tunnel: 10.0.0.254

Tunnel: 10.0.0.1 Tunnel: 10.0.0.2

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29

C 192.168.0.0/29 Eth0 Hub via transport network C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
S 172.16.254.1 Dialer0 S 172.16.254.1 Dialer0
D 192.168.0.0/16 10.0.0.254 192.168.0.0/16 encrypted D 192.168.0.0/16 10.0.0.254
& tunneled to hub
DMVPN phase 2 design style
Routing table
C 10.0.0.0 Tunnel0
C 192.168.254.0/24 Eth0 Hub advertises back individual prefixes
D 192.168.0.0/29 10.0.0.1 Hub pointing to corresponding spoke.
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
Tunnel: 10.0.0.254

Tunnel: 10.0.0.1 Tunnel: 10.0.0.2

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29

C 192.168.0.0/29 Eth0 Tunnels via transport network C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
S 0.0.0.0/0 Dialer0 S 0.0.0.0/0 Dialer0
D 192.168.0.8/29 10.0.0.2 Lots of individual prefixes D 192.168.0.0/29 10.0.0.1
DMVPN phase 2 shortcuts (1)
Routing table
C 10.0.0.0 Tunnel0
C 192.168.254.0/24 Eth0
D 192.168.0.0/29 10.0.0.1 Hub
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
t Tunnel: 10.0.0.254
ues
q
Re
n
tio
u
s ol
Physical: 172.16.1.1 Re Physical: 172.16.2.1
Tunnel: 10.0.0.1 Tunnel: 10.0.0.2

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
10.0.0.2 Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29

C 192.168.0.0/29 Eth0 C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
S 0.0.0.0/0 Dialer0 S 172.16.254.1 Dialer0
D 192.168.0.8/29 10.0.0.2 D 192.168.0.0/29 10.0.0.1
Routing table
C 10.0.0.0 Tunnel0
C 192.168.254.0/24 Eth0
D 192.168.0.0/29 10.0.0.1 Hub
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
Tunnel: 10.0.0.254
y
e pl
R
n
utio
s ol
Physical: 172.16.1.1 Re Physical: 172.16.2.1
Tunnel: 10.0.0.1 Tunnel: 10.0.0.2

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
10.0.0.2 172.16.2.1 Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29

C 192.168.0.0/29 Eth0 C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
S 0.0.0.0/0 Dialer0 S 172.16.254.1 Dialer0
D 192.168.0.8/29 10.0.0.2 D 192.168.0.0/29 10.0.0.1
Routing table
C 10.0.0.0 Tunnel0
C 192.168.254.0/24 Eth0
D 192.168.0.0/29 10.0.0.1 Hub
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
Tunnel: 10.0.0.254

Tunnel: 10.0.0.1 Tunnel: 10.0.0.2

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
10.0.0.2 172.16.2.1 Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29

C 192.168.0.0/29 Eth0 C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
S 0.0.0.0/0 Dialer0 S 172.16.254.1 Dialer0
D 192.168.0.8/29 10.0.0.2 D 192.168.0.0/29 10.0.0.1
Routing table
C 10.0.0.0 Tunnel0
C 192.168.254.0/24 Eth0 Hub advertises back summary prefix
D 192.168.0.0/29 10.0.0.1 Hub pointing to hub.
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
Tunnel: 10.0.0.254

Tunnel: 10.0.0.1 Tunnel: 10.0.0.2

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29

C 192.168.0.0/29 Eth0 Tunnels via transport network C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
S 0.0.0.0/0 Dialer0 S 0.0.0.0 Dialer0
D 192.168.0.0/16 10.0.0.254 192.168.0.0/16 summary D 192.168.0.0/29 10.0.0.254
tunneled to hub
Routing table
C 10.0.0.0 Tunnel0
C 192.168.254.0/24 Eth0 ip nhrp redirect
D 192.168.0.0/29 10.0.0.1 Hub
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
Tunnel: 10.0.0.254

Tunnel: 10.0.0.1 Tunnel: 10.0.0.2

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29
Routing table ip nhrp shortcut Routing table

C 192.168.0.0/29 Eth0 C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
S 0.0.0.0/0 Dialer0 S 172.16.254.1 Dialer0
D 192.168.0.0/16 10.0.0.254 D 192.168.0.0/29 10.0.0.254
Routing table
C 10.0.0.0 Tunnel0
C 192.168.254.0/24 Eth0
D 192.168.0.0/29 10.0.0.1 Hub
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
9) Tunnel: 10.0.0.254
.0.
8
.16
92
(1
n
c tio
e
Physical: 172.16.1.1 ndir Physical: 172.16.2.1
I
Tunnel: 10.0.0.1 Tunnel: 10.0.0.2

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
Spoke 1 Spoke 2
192.168.0.0/29 192.168.0.8/29

C 192.168.0.0/29 Eth0 C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
S 0.0.0.0/0 Dialer0 S 172.16.254.1 Dialer0
D 192.168.0.0/16 10.0.0.254 D 192.168.0.0/29 10.0.0.254
Routing table
C 10.0.0.0 Tunnel0
C 192.168.254.0/24 Eth0
D 192.168.0.0/29 10.0.0.1 Hub
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
Re
9)
.0. so Tunnel: 10.0.0.254
8 lu
.16 tio
n
92 (1
(1 92
n .16
tio 8.
lu 0.9
Physical: 172.16.1.1 eso ) Physical: 172.16.2.1
Tunnel: 10.0.0.1 R Resolution Reply Tunnel: 10.0.0.2
192.168.0.8/29
192.168.0.8/29
10.0.0.2
10.0.0.2172.16.2.1
10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
10.0.0.2 172.16.2.1 Spoke 1 Spoke 2 10.0.0.1 172.16.1.1
192.168.0.8/29 172.16.2.1 192.168.0.0/29 192.168.0.8/29

C 192.168.0.0/29 Eth0 C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
S 0.0.0.0/0 Dialer0 S 172.16.254.1 Dialer0
D 192.168.0.0/16 10.0.0.254 D 192.168.0.0/29 10.0.0.254
Routing table
C 10.0.0.0 Tunnel0
C 192.168.254.0/24 Eth0
D 192.168.0.0/29 10.0.0.1 Hub
D 192.168.0.8/29 10.0.0.2 192.168.254.0/24
NHRP table
10.0.0.1 172.16.1.1
10.0.0.2 172.16.2.1
Physical: 172.16.254.1
Tunnel: 10.0.0.254

Tunnel: 10.0.0.1 Tunnel: 10.0.0.2

10.0.0.254 172.16.254.1 10.0.0.254 172.16.254.1
10.0.0.2 172.16.2.1 Spoke 1 Spoke 2 10.0.0.1 172.16.1.1
192.168.0.8/29 172.16.2.1 192.168.0.0/29 192.168.0.8/29

C 192.168.0.0/29 Eth0 C 192.168.0.8/29 Eth0
C 10.0.0.0 Tunnel0 C 10.0.0.0 Tunnel0
S 0.0.0.0/0 Dialer0 S 172.16.254.1 Dialer0
D 192.168.0.0/16 10.0.0.254 D 192.168.0.0/29 10.0.0.254
For your
reference
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 your
reference
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 your
reference
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
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
Design
Using 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
192.168.0.0/24
Single DMVPN Dual Hub .2 .1
Single mGRE tunnel on
all nodes
Tunnel0: 10.0.0.2 Tunnel0: 10.0.0.1
Physical: (dynamic)
Tunnel0: 10.0.0.12
Spoke B .1
.37
Physical: (dynamic) 192.168.2.0/24
Tunnel0: 10.0.0.11 Web
.
..
Spoke A
.1
.25 ...
192.168.1.0/24
PC
= Dynamic&Temporary Spoke-to-spoke IPsec tunnels
Hub1
interface Tunnel0
Common bandwidth 1000
ip address 10.0.0.1 255.255.255.0
Subnet ip mtu 1400
ip nhrp map multicast dynamic
Activate
ip nhrp redirect
redirection ip nhrp network-id 1
tunnel source Serial1/0
tunnel mode gre multipoint
tunnel protection ipsec profile vpnprof
!
router rip
Make RIP network 10.0.0.0
Passive passive-interface default
!
Make hub ip sla responder
SLA responder ip sla responder udp-echo ipaddress 10.0.0.1 port 2000
Hub2
interface Tunnel0
Common bandwidth 1000
ip address 10.0.0.2 255.255.255.0
Subnet ip mtu 1400
Activate
ip nhrp redirect
redirection ip nhrp network-id 1
!
router rip
Make RIP network 10.0.0.0
Passive passive-interface default
Spokes – part 1
interface Tunnel0
bandwidth 1000
Hub1 NHRP ip address 10.0.0.<x> 255.255.255.0 ! <x> = 11,12,…
mappings ip mtu 1400
ip nhrp map multicast 172.17.0.1
ip nhrp map 10.0.0.1 172.17.0.1
Hub2 NHRP ip nhrp map multicast 172.17.0.5
mappings ip nhrp map 10.0.0.2 172.17.0.5
ip nhrp holdtime 360
Activate RIP router rip

network 10.0.0.0
network 192.168.<x>.0 !<x> = 1,2,…
Spokes – part 2 Poll 10.0.0.1
UDP Port 2000
Poll every second ip sla 1
Timeout: 1 second udp-echo 10.0.0.1 2000 control disable
timeout 1000
Fail after 21 seconds frequency 1
threshold 21000
ip sla schedule 1 life forever start-time now
Monitor SLA probes track 1 rtr 1 reachability
Primary routes ip route 192.168.0.0 255.255.255.0 10.0.0.1 track 1

ip route 10.0.0.0 255.0.0.0 10.0.0.1 track 1
When track 1 is up
Floating routes ip route 192.168.0.0 255.255.255.0 10.0.0.2 254

ip route 10.0.0.0 255.0.0.0 10.0.0.2 254
Kick-in if probes fail
(floating statics) ip route 0.0.0.0 0.0.0.0 Serial 1/0
Model shown here makes hub1 primary, hub2 backup

Track both hubs to make active-active if desired
Large Scale
DMVPN
Hub & Spoke
Overall solution
HQ network
Aggregation router
Cluster of DMVPN hubs

Hubs Aggregates user tunnels
Server Load Balancer SLB balances connections

Owns virtual IP address
GRE/IPsec tunnels
IGP + NHRP
Spokes
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
10.1.2.0/24
.1
.2 .3
10.1.1.0/24
Loopback: 172.17.0.1 Loopback: 172.17.0.1
Tunnel0: 10.0.255.254/16 Tunnel0: 10.0.255.254/16
10.1.0.0/24
.2 .3
.1
Load Balancer
VIP: 172.17.0.1
(no tunnel)
Physical: (dynamic)172.16.2.1
Physical: (dynamic)172.16.1.1 Tunnel0: 10.0.0.2
Tunnel0: 10.0.0.1
Spoke A
192.168.1.1/29 Spoke B 192.168.2.1/29
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
For your
reference
IOS SLB cluster definition
ip slb probe PINGREAL ping

faildetect 2
ip slb serverfarm HUBS

failaction purge Least connections
probe PINGREAL (default is round-robin)
predictor leastconn
real 10.1.0.2 If all the hubs are equivalent,

the weight is the same for all
weight 4
inservice
real 10.1.0.3
weight 4
inservice
For your
reference
IOS SLB VIP definition
ip slb vserver ESPSLB

virtual 172.17.0.1 esp
serverfarm HUBS
sticky 60 group 1
idle 30
inservice
Same farm Buddying
ip slb vserver IKESLB
virtual 172.17.0.1 udp isakmp
serverfarm HUBS
sticky 60 group 1
idle 30
inservice
For your
reference
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
Hub Tunnel configuration
interface Loopback0
ip address 172.17.0.1 255.255.255.255
interface Tunnel0
end
bandwidth 10000
ip address 10.0.255.254 255.255.0.0 Must be same on all hubs
no ip redirects
Mask is /32
ip mtu 1400
ip nhrp network-id 1 Must be same on all hubs
ip nhrp holdtime 3600
Mask allows 216-2 nodes
tunnel source Loopback0
tunnel protection ipsec profile tp
cdp enable
end 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
Physical interface ip addresses
unique 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

Hubs 10.0.0.1 172.16.1.1 10.0.0.2 172.16.2.1
10.0.0.3 172.16.3.1 10.0.0.4 172.16.4.1
Server Load Balancer
Physical: 172.16.1.1 172.16.2.1 172.16.3.1 172.16.4.1

Tunnel: 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4
Spokes
Spoke 1 Spoke 2 Spoke 3 Spoke 4
Spoke routing configuration
interface Tunnel0
Activate ODR over tunnel cdp enable
Tunnel packet physical ip route 0.0.0.0 0.0.0.0 Dialer0
Private traffic (summary) ip route 192.168.0.0 255.255.0.0 10.0.0.1
Tunnel 0 ip route 10.0.0.0 255.0.0.0 10.0.0.1
Physical: (dynamic)172.16.1.1
Tunnel0: 10.0.0.11 Spoke A
192.168.1.1/29
Hub Routing Protocol configuration
• Only allow private networks in
the routing table
• Prevents recursive routing
interface Tunnel0
Activate ODR over tunnel cdp enable
router odr
Tunnel packet physical distribute-list 1 in
access-list 1 permit 192.168.0.0 0.0.255.255
router bgp 1
Redistribute
ODR BGP redistribute odr
Send information to
neighbor 10.1.1.1 remote-as 1
aggregation router
neighbor 10.1.1.1 next-hop-self
For your
reference
HQ Edge BGP configuration
router bgp 1
no synchronization
bgp log-neighbor-changes
aggregate-address 10.0.0.0 255.0.0.0 summary-only
aggregate-address 192.168.0.0 255.0.0.0 summary-only
neighbor HUB peer-group
neighbor HUB remote-as 1
neighbor 10.1.1.2 peer-group HUB
neighbor 10.1.1.3 peer-group HUB
neighbor <other hubs> peer-group HUB
no auto-summary
HQ network
Aggregation router
Cluster of DMVPN hubs

Hubs Aggregates user tunnels
For your
reference
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
HQ network
(10.0.0.0/8)
Runs OSPF – segment in area 1
10.1.2.0/24
Routing protocols
Route Propagation spoke aggregation
Routing table
HQ B 192.168.0.0/29 10.1.1.2
network
B 192.168.0.8/29 10.1.1.3
B 192.168.0.16/29 10.1.1.2
B 192.168.0.24/29 10.1.1.3

10.0.0.1 172.16.1.1 10.0.0.2 172.16.2.1
10.0.0.3 172.16.3.1 10.0.0.4 172.16.4.1

o 192.168.0.0/29 10.0.0.1 o 192.168.0.8/29 10.0.0.2
o 192.168.0.16/29 10.0.0.3 o 192.168.0.24/29 10.0.0.4
B 192.168.0.0 10.1.1.1 B 192.168.0.0/16 10.1.1.1
B 10.0.0.0 10.1.1.1 B 10.0.0.0 10.1.1.1
Physical: 172.16.1.1 172.16.2.1 172.16.3.1 172.16.4.1

Tunnel: 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4

192.168.0.0/29 192.168.0.8/29 192.168.0.16/29 192.168.0.24/29
Hub&Spoke packet flow
Routing table
HQ B 192.168.0.0/29 10.1.1.2
network
B 192.168.8.0/29 10.1.1.3
B 192.168.16.0/29 10.1.1.2
B 192.168.24.0/29 10.1.1.3

o 192.168.0.0/29 10.0.0.1 o 192.168.8.0/29 10.0.0.2
o 192.168.16.0/29 10.0.0.3 o 192.168.24.0/29 10.0.0.4
B 192.168.0.0 10.1.1.1 B 192.168.0.0/16 10.1.1.1
B 10.0.0.0 10.1.1.1 B 10.0.0.0 10.1.1.1
10.0.0.1 172.16.1.1 10.0.0.2 172.16.2.1
10.0.0.3 172.16.3.1 10.0.0.4 172.16.4.1
Physical: 172.16.1.1 172.16.2.1 172.16.3.1 172.16.4.1

Tunnel: 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4

192.168.0.0/29 192.168.8.0/29 192.168.16.0/29 192.168.24.0/29
Large Scale
DMVPN
Spoke – 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
Routing table
HQ B 192.168.0.0/29 10.1.1.2
network
B 192.168.8.0/29 10.1.1.3
B 192.168.16.0/29 10.1.1.2
B 192.168.24.0/29 10.1.1.3

o 192.168.0.0/29 10.0.0.1 o 192.168.8.0/29 10.0.0.2
o 192.168.16.0/29 10.0.0.3 o 192.168.24.0/29 10.0.0.4
B 192.168.0.0 10.1.1.1 B 192.168.0.0/16 10.1.1.1
B 10.0.0.0 10.1.1.1 B 10.0.0.0 10.1.1.1
10.0.0.1 172.16.1.1 10.0.0.2 172.16.2.1
10.0.0.4 172.16.4.1
t
10.0.0.3 172.16.3.1
c
ire
red
Physical: 172.16.1.1 172.16.2.1 172.16.3.1 172.16.4.1

Tunnel: 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4

192.168.0.0/29 192.168.8.0/29 192.168.16.0/29 192.168.24.0/29
Routing table
HQ B 192.168.0.0/29 10.1.1.2
network
B 192.168.8.0/29 10.1.1.3
B 192.168.16.0/29 10.1.1.2
B 192.168.24.0/29 10.1.1.3

o 192.168.0.0/29 10.0.0.1 o 192.168.8.0/29 10.0.0.2
o 192.168.16.0/29 10.0.0.3 o 192.168.24.0/29 10.0.0.4
B 192.168.0.0 10.1.1.1 B 192.168.0.0/16 10.1.1.1
B 10.0.0.0 10.1.1.1 B 10.0.0.0 10.1.1.1
10.0.0.1 172.16.1.1 10.0.0.2 172.16.2.1
10.0.0.4 172.16.4.1
es n ct
10.0.0.3 172.16.3.1
qu uitrioe
t
rre eod
l
s
re

10.0.255.254 172.16.0.1
Physical: 172.16.1.1 172.16.2.1 10.0.255.254
172.16.3.1 172.16.0.1
172.16.4.1
Tunnel: 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4

192.168.0.0/29 192.168.8.0/29 192.168.16.0/29 192.168.24.0/29
Routing table
HQ B 192.168.0.0/29 10.1.1.2
network
B 192.168.8.0/29 10.1.1.3
B 192.168.16.0/29 10.1.1.2
B 192.168.24.0/29 10.1.1.3

o 192.168.0.0/29 10.0.0.1 o 192.168.8.0/29 10.0.0.2
o 192.168.16.0/29 10.0.0.3 o 192.168.24.0/29 10.0.0.4
B 192.168.0.0 10.1.1.1 B 192.168.0.0/16 10.1.1.1
B 10.0.0.0 10.1.1.1 B 10.0.0.0 10.1.1.1
10.0.0.1 172.16.1.1 10.0.0.2 172.16.2.1
10.0.0.3 172.16.3.1 10.0.0.4 172.16.4.1
es n
qu tio
t
r e o lu
s
re

10.0.255.254 172.16.0.1
Physical: 172.16.1.1 172.16.2.1 10.0.255.254
172.16.3.1 172.16.0.1
172.16.4.1
192.168.16.0/29 172.16.3.1
Tunnel: 10.0.0.1 10.0.0.2 10.0.0.1
10.0.0.3 172.16.1.1
10.0.0.4
10.0.0.3 172.16.3.1 192.168.1.0/29 172.16.1.1

192.168.0.0/29 192.168.8.0/29 192.168.16.0/29 192.168.24.0/29
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 Same network ID as Tunnel0 !!
ip nhrp redirect Send indirection notifications
ip nhrp map 10.1.3.3 10.1.0.3
tunnel source FastEthernet0/1
end
10.1.2.0/24
.1
.2 .3
10.1.1.0/24

Tunnel0: 10.0.255.254/16 Tunnel0: 10.0.255.254/16
Tunnel1: Tunnel1:
10.1.3.2/24 10.1.3.3/24
Routing across hubs
10.1.2.0/24
.1
.2 .3
10.1.1.0/24

Tunnel0: 10.0.255.254/16 Tunnel0: 10.0.255.254/16
router bgp 1 router bgp 1

neighbor 10.1.3.3 remote-as 1 neighbor 10.1.3.2 remote-as 1
neighbor 10.1.3.3 next-hop-self neighbor 10.1.3.2 next-hop-self
Hubs exchange their ODR information directly via BGP

The exchange occurs over the inter-hub DMVPN
Routing table
HQ B 192.168.0.0/29 10.1.1.2
network
B 192.168.8.0/29 10.1.1.3
B 192.168.16.0/29 10.1.1.2
B 192.168.24.0/29 10.1.1.3
o 192.168.0.0/29 10.0.0.1 o 192.168.8.0/29 10.0.0.2
o 192.168.16.0/29 10.0.0.3 o 192.168.24.0/29 10.0.0.4
B 192.168.8.0/29 10.1.3.3 B 192.168.0.0/29 10.1.3.2
B 192.168.24.0/29 10.1.3.3 B 192.168.16.0/29 10.1.3.2
B 192.168.0.0 10.1.1.1 B 192.168.0.0/16 10.1.1.1
B 10.0.0.0 10.1.1.1 B 10.0.0.0 10.1.1.1
NHRP table t NHRP table
10.0.0.1 172.16.1.1 10.0.0.2 172.16.2.1
c
10.0.0.3 172.16.3.1 10.0.0.4 172.16.4.1
ire
red
Physical: 172.16.1.1 172.16.2.1 172.16.3.1 172.16.4.1

Tunnel: 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4

192.168.0.0/29 192.168.8.0/29 192.168.16.0/29 192.168.24.0/29
Routing table
HQ B 192.168.0.0/29 10.1.1.2
network
B 192.168.8.0/29 10.1.1.3
B 192.168.16.0/29 10.1.1.2
B 192.168.24.0/29 10.1.1.3
o 192.168.0.0/29 10.0.0.1 o 192.168.8.0/29 10.0.0.2
o 192.168.16.0/29 10.0.0.3 o 192.168.24.0/29 10.0.0.4
B 192.168.8.0/29 10.1.3.3 B 192.168.0.0/29 10.1.3.2
B 192.168.24.0/29 10.1.3.3 B 192.168.16.0/29 10.1.3.2
B 192.168.0.0 10.1.1.1 B 192.168.0.0/16 10.1.1.1
B 10.0.0.0 10.1.1.1 B 10.0.0.0 10.1.1.1
NHRP table t NHRP table
10.0.0.1 172.16.1.1 10.0.0.2 172.16.2.1
t c
10.0.0.3 172.16.3.1 10.0.0.4 172.16.4.1
esiren
qud tio
rre eolu
s
re
Physical: 172.16.1.1 172.16.2.1 172.16.3.1 172.16.4.1

Tunnel: 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4

192.168.0.0/29 192.168.8.0/29 192.168.16.0/29 192.168.24.0/29
Routing table
HQ B 192.168.0.0/29 10.1.1.2
network
B 192.168.8.0/29 10.1.1.3
B 192.168.16.0/29 10.1.1.2
B 192.168.24.0/29 10.1.1.3
o 192.168.0.0/29 10.0.0.1 o 192.168.8.0/29 10.0.0.2
o 192.168.16.0/29 10.0.0.3 o 192.168.24.0/29 10.0.0.4
B 192.168.8.0/29 10.1.3.3 B 192.168.0.0/29 10.1.3.2
B 192.168.24.0/29 10.1.3.3 B 192.168.16.0/29 10.1.3.2
B 192.168.0.0 10.1.1.1 B 192.168.0.0/16 10.1.1.1
B 10.0.0.0 10.1.1.1 B 10.0.0.0 10.1.1.1
10.0.0.1 172.16.1.1 10.0.0.2 172.16.2.1
10.0.0.3 172.16.3.1 10.0.0.4 172.16.4.1
es n
qu tio
t
r e o lu
NHRP table
s
10.0.255.254 172.16.0.1
re
NHRP table
10.0.255.254 172.16.0.1 10.0.0.1 172.16.1.1
Physical: 172.16.1.1 172.16.2.1 172.16.3.1 172.16.4.1
192.168.1.0/29 172.16.1.1
192.168.24.0/29 172.16.4.1
Tunnel: 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4
10.0.0.4 172.16.4.1

192.168.0.0/29 192.168.8.0/29 192.168.16.0/29 192.168.24.0/29
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 Create a manual full mesh
ip nhrp map 10.1.3.4 10.1.0.4
ip nhrp map 10.1.3.5 10.1.0.5 Do the same with BGP…
. . .
end
10.1.2.0/24
.1
.2 .3 .4 .5
10.1.1.0/24
Tunnel1: Tunnel1: Tunnel1: Tunnel1:

10.1.3.2/24 10.1.3.3/24 10.1.3.4/24 10.1.3.5/24
Linking the hubs – option 2
interface Tunnel1
ip address 10.1.3.2 255.255.255.0
ip nhrp network-id 1 Use the edge router as
ip nhrp redirect NHRP hub
ip nhrp map 10.1.3.1 10.1.0.1
Use the edge as a RR
end
10.1.2.0/24
Tunnel1:
10.1.3.1/24
.1
.2 .3 .4 .5
10.1.1.0/24
Tunnel1: Tunnel1: Tunnel1: Tunnel1:

10.1.3.2/24 10.1.3.3/24 10.1.3.4/24 10.1.3.5/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 5+ IKE AAA …
Layer 4
Layer 3
helpers
Layer 3
Layer 2
Loopback Tunnel
Forwarding without encapsulation
Layer 4
Layer 3
helpers
Layer 3 Routing
Layer 2
Forwarding with encapsulation
Layer 4
Layer 3
helpers
Layer 3 Routing Routing
Layer 2
Add VRF’s to the router
ip vrf red
ip vrf blue
ip vrf green
interface Tunnel 0
Router with VRF’s
Layer 4
Layer 3
helpers
Layer 3 VRF Global VRF Red VRF Blue VRF Green
Layer 2
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 packets

are routed out
VRF tunneling
Layer 4
Layer 3
helpers
Layer 3 VRF Global VRF Red VRF Blue VRF Green
Layer 2
Watch out the network ID
interface Tunnel 0
tunnel source FastEthernet 1/0
tunnel destination …
tunnel vrf blue
Several tunnels can share the same nhrp network-id

BUT
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
192.168.0.0/24
Single HUB terminating .1
Two distinct DMVPN’s Physical: 172.17.0.1
Tunnel2: 10.0.1.1
Physical: 172.17.0.1
Tunnel1: 10.0.0.1
Assume two groups of users
Group 1 – Engineering Group 2 – Finance
Certificate Certificate
Status: Available Status: Available
Certificate Serial Number: 100 Certificate Serial Number: 300
Certificate Usage: General Purpose Certificate Usage: General Purpose
Issuer: Issuer:
cn=blue-lab CA cn=blue-lab CA
o=CISCO o=CISCO
Subject: Subject:
Name: Router100.cisco.com Name: Router300.cisco.com
o=CISCO o=CISCO
ou=Engineering
ou=Engineering ou=Finance
ou=Finance
Validity Date: Validity Date:
start date: 14:34:30 UTC Mar 31 2004 start date: 14:34:30 UTC Mar 31 2004
end date: 14:34:30 UTC Apr 1 2009 end date: 14:34:30 UTC Apr 1 2009
Associated Trustpoints: LaBcA 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_map 10

subject-name co ou = Engineering
crypto pki certificate map finance_map 10

subject-name co ou = 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 eng-

eng-ikmp-
ikmp-prof
pki trustpoint LaBcA
match certificate engineering_map
crypto isakmp profile fin-

fin-ikmp-
ikmp-prof
set isakmp-
isakmp-profile
pki trustpoint eng-
eng-ikmp-
LaBcA ikmp-prof
match certificate finance_map
The IPsec profiles
Two IPsec profiles are necessary

Each profile maps to a distinct ISAKMP profile
crypto ipsec profile eng-

eng-ipsec-
ipsec-prof
crypto ipsec transform-set high-security
set isakmp-
isakmp-profile eng-
eng-ikmp-
ikmp-prof
crypto ipsec profile fin-

fin-ipsec-
ipsec-prof
crypto ipsec transform-set high-security
set isakmp-
isakmp-profile fin-
fin-ikmp-
ikmp-prof
Defining the tunnels
interface tunnel1
ip vrf forwarding Engineering
ip address 10.0.0.1 255.255.255.0
tunnel key 1
ip nhrp …
tunnel source loopback0
tunnel protection ipsec profile eng-
eng-ipsec-
ipsec-prof
interface tunnel2
Each tunnel links
ip vrf forwarding Finance To a specific ISAKMP
ip address 10.0.1.1 255.255.255.0 Profile
tunnel key 2
ip nhrp …
tunnel source loopback0
tunnel protection ipsec profile fin-
fin-ipsec-
ipsec-prof
Session mapping example
Incoming session Certificate inspected

Cert. authentication
IKE
Engineering Finance Turns out ou=Engineering
ISAKMP ISAKMP
Profile Profile
Engineering Finance
Tunnel Tunnel
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 Unique Link-Local address
ipv6 address 2001::2/64 Global or Locally Reachable addr.
ipv6 nhrp map 2001::1 172.17.0.1

ipv6 nhrp map multicast 172.17.0.1
Business almost as usual…
ipv6 nhrp nhs 2001::1
ipv6 nhrp network-id 1

tunnel source … IPv4 address or interface
tunnel protection ipsec profile …
Hub configuration
Hub
interface Tunnel0
ipv6 address fe80::2001 link-local Unique Link-Local address
ipv6 address 2001::1/64 Global or Locally Reachable addr.

ipv6 nhrp network-id 1
Business almost as usual…
ipv6 nhrp map multicast dynamic

tunnel protection ipsec profile …
tunnel source … IPv4 address or interface
Subtle differences
Hub#show ipv6 nhrp
2001::2/128 via 2001::2 Global and Link-Local
Tunnel0 created 00:04:47, expire 01:59:49 registered!!
Type: dynamic, Flags: unique registered used
NBMA address: 1.0.0.2
2001::3/128 via 2001::3
Tunnel0 created 00:04:03, expire 01:59:49
Type: dynamic, Flags: unique registered used
FE80::2/128 via 2001::2
Type: dynamic, Flags: unique registered
NBMA address: 1.0.0.2 Global and Link-Local
FE80::3/128 via 2001::3 registered!!
Type: dynamic, Flags: unique registered
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
Interface w/
limited downstream rate
Hub
ISP Greedy
router Spoke 3
Crypto engine
or Wan link
Spoke 1 Spoke 2
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
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
Horror MQC policy – DMVPN
Problem: static and slow
policy-map child
class routing-protocol Interface Tunnel0
bandwidth 100 kbps (qos pre-classify optional)
class voice
priority 200 kbps
class data Interface GigabitEthernet0/1
police 500 kbps service-policy out parent
class class-default
!
policy-map parent
class tunnel1 Access-list 101 permit esp hub spoke1
bandwidth 400 kbps class-map tunnel1
shape average 1mbps match access-group 101
service policy child
class tunnel2
bandwidth 400 kbps Access-list 102 permit esp hub spoke2
class-map tunnel2
shape average 1mbps
service policy child match access-group 102
class tunnel3
Access-list 103 permit esp hub spoke3
bandwidth 400 kbps
class-map tunnel3
shape average 1mbps
match access-group 103
service policy child
class class-default
shape average 2mbps
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 CLI
CCE Common Classification Engine
HQF 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
QoS policy Classification
QoS Policy policing, marking Hierachical queueing per Tunnel
Tunnel 1 - data Data Tunnel 1
Interface QoS policy

policy
SA classification
Tunnel 1 - voice Voice
Derived
Tunnel 2 - data Data
Crypto Tunnel 2 Physical
Tunnel 2 - voice Engine Voice policy Interface
Tunnel 3 - data Data Tunnel 2

Tunnel 3 - voice Voice policy
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 Group 2
Spokes
interface Tunnel0 interface Tunnel0

ip nhrp group <name1> ip nhrp group <name2>
policy-map PM1
class class-default Offer 1 Mbps to each tunnel
shape average 1000000
HUB
Policy-map PM2
class class-default
Offer 500 kbps to each tunnel
shape average 500000
interface Tunnel0
ip nhrp map group <name1> service policy output PM1
ip nhrp map group <name2> service policy output PM2
QoS policy limiting tunnel bandwidth
Hub
class-map Control
match ip precedence …
class-map Voice
policy-map PM1
class class-default
shape average 1000000 Offer 1Mbps to each tunnel
interface Tunnel0
ip nhrp map group G1 service-policy output PM1
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
Hub
class-map Control
class-map Voice
policy-map PM1
class class-default
shape average 1000000 Offer 1Mbps to each tunnel
service-policy SubPolicy
policy-map SubPolicy
class Control
bandwidth 20 20Kbps guaranteed to Control
class Voice
priority percent 60 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
TEK
192.168.0.0/24 Key server
.1
Group Member
TEK
TEK
IP(s=
IP(s=PC,d=Web) .1
PC,d=Web) TCP…
IP(s=
IP(s=PC,d=Web)
PC,d=Web) ESP … .37
TEK 192.168.3.0/24
Web
TEK
.1
.25
192.168.1.0/24 IP(s=
IP(s=PC,d=Web)
PC,d=Web) TCP… .1
.37
PC
192.168.2.0/24
Web
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
For your
reference
DMVPN Enhancements
Previous Limitation New Feature & Associated Benefits
Shortcut switching introduced
Large routing tables at spokes Route summarization now possible
sometimes caused network
instability. Higher scalability
12.4(6)T
Packets CEF switched via hub
Delays in setting up voice calls
between spokes. Reduced latency during call setup
12.4(6)T
NHRP resolution requests forwarding

Complex interconnection of Hubs
to expand DMVPN Spoke-to- Simplified hub network design
Spoke Networks. Improved resiliency.
12.4(6)T
NAT/PAT not possible in spoke- NAT and static PAT now supported
spoke designs 12.4(9)T
For your
reference
DMVPN Enhancements
Previous Limitation New Feature & Associated Benefits
DMVPN debug enhancements
All tables with a single show command
Complex troubleshooting
Per-peer debugging also possible
12.4(9)T
NHRP MIB
Network monitoring difficult or
impossible Monitoring of NHRP tables via SNMP
12.4(20)T
DMVPN IPv6
Limited to IPv4 Allows IPv6 in the overlay network
12.4(20)T
Complex QoS configuration. Not Per-tunnel QoS introduced

working well with dynamic spoke
NBMA’s. 12.4(22)T
Session Summary
Shortcut switching
Routing 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
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
Session ID
Presentation_ID © 2007 Cisco Systems, Inc. All rights reserved. Cisco Public 118

Advanced DMVPN Deployments PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced DMVPN Deployments PDF

Uploaded by

Copyright:

Available Formats

Advanced DMVPN

Frederic Detienne, Distinguished Services Engineer

We value your feedback- don't forget to complete your

DMVPN phase 2 and 3 comparison

In-depth knowledge of DMVPN is assumed

Physical: 172.16.1.1 Physical: 172.16.2.1

Physical: 172.16.1.1 Physical: 172.16.2.1

NHRP table NHRP table

ip address 10.0.0.1 255.255.255.0

NHRP table NHRP table

Routing table Routing table

Physical: 172.16.1.1 Physical: 172.16.2.1

NHRP table NHRP table

Routing table Routing table

Physical: 172.16.1.1 Physical: 172.16.2.1

NHRP table NHRP table

Routing table Routing table

NHRP table NHRP table

Routing table Routing table

NHRP table NHRP table

Routing table Routing table

Physical: 172.16.1.1 Physical: 172.16.2.1

NHRP table NHRP table

Routing table Routing table

Physical: 172.16.1.1 Physical: 172.16.2.1

NHRP table NHRP table

Routing table Routing table

Physical: 172.16.1.1 Physical: 172.16.2.1

NHRP table NHRP table

Routing table ip nhrp shortcut Routing table

NHRP table NHRP table

Routing table Routing table

Routing table Routing table

Physical: 172.16.1.1 Physical: 172.16.2.1

NHRP table NHRP table

Routing table Routing table

If packet forwarding falls back to NHS

If router receives indirection-notification

Activate RIP router rip

Monitor SLA probes track 1 rtr 1 reachability

Primary routes ip route 192.168.0.0 255.255.255.0 10.0.0.1 track 1

Floating routes ip route 192.168.0.0 255.255.255.0 10.0.0.2 254

Model shown here makes hub1 primary, hub2 backup

Cluster of DMVPN hubs

Server Load Balancer SLB balances connections

IOS SLB on a Cat6500 (MSFC-2)

IOS SLB on a c7200 (NPE-400)

Typically not a bottleneck

ip slb probe PINGREAL ping

ip slb serverfarm HUBS

real 10.1.0.2 If all the hubs are equivalent,

ip slb vserver ESPSLB

vserver prot client real state nat

SLB-7200#clear ip slb connections ?

SLB-7200#sh ip slb reals

real farm name weight state conns

Basic DMVPN / ODR configuration

We now allow spokes to

NHRP table NHRP table

Server Load Balancer

Physical: 172.16.1.1 172.16.2.1 172.16.3.1 172.16.4.1

Cluster of DMVPN hubs

ip route 192.168.0.0 255.255.0.0 Null0 254