VPNs

Site-to-site IPSec VPN using Static Crypto-maps - Knowledge Base
Knowledge
Base
Page 1 of 5
Search this site
Home
BGP
Data Center
GPON
Hadoop
Site-to-site IPSec VPN using Static Cryptomaps

Network topology:
IP Multicast
IPv6
IS-IS
Juniper-JUNOS
L2VPN
LAN
Link Aggregation
LTE Notes
MPLS
NAT
There are 5 steps in the life-cycle of an IPSec VPN-
Step 1: Specifying interesting traffic using accesslist:
OAM
OSPF
Here, the interesting traffic means traffic that will be encrypted; rest
PBB
of the traffic goes unencrypted. From Site1's perspective, all the traffic
with source address from internal network 10.1.1.0/24 and destination
PPP
QoS
network 10.2.2.0/24 will be regarded as interesting traffic, and vice

versa from Site2's perspective.
Security
Traffic Engineering
VPLS
Step 1: Interesting traffic
VPN
Site1:
Attachments
ip access-list extended Traffic_1to2

permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
!
Site2:
ip access-list extended Traffic_2to1
permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255
!
The IKE (Internet Key Exchange) protocol is a means to

dynamically exchange IPSec parameters and keys. IKE helps to
automatically establish security associations (SA) between two
IPSec endpoints. An SA is an agreement of IPSec parameters between
two endpoints. IKE uses two protocols for peer authentication and
https://sites.google.com/site/amitsciscozone/home/ipsec/site-to-site-ipsec-vpn-using-sta... 4/08/2014
Page 2 of 5
key-generation(a) ISAKMP- The Internet Security Association and Key

Management Protocol defines procedures on how to establish,
negotiate, modify and delete SA. The ISAKMP performs peer
authentication but does not involve key exchange.
(b) Oakley- The Oakley protocol uses Diffie-Hellman (DH)
algorithm to manage key exchanges over IPSec SA. DH is a
cryptographic protocol that permits the two endpoints to exchange
shared-secret key over insecure channel.
The IKE Phases are broken into two phases which create a secure
communication channel between two IPSec endpoints.
Step 2: IKE Phase 1:

IKE Phase 1 is the manadatory phase. A bidirectional SA is established
between IPSec peers in phase 1. Data sent between the devices uses
the same key material. Phase 1 may also perform peer authentication
to validate the identity of the IPSec endpoint. Phase 1 consists of
following exchangesThe first two exchanges negotiate the security parameters used to
establish the IKE tunnel. The two endpoints exchange proposals in the
form of transform-sets (using IKE policies).
The second pair of packets exchange the DH public-keys needed to
create the secure IKE tunnel. This tunnel is later used to exchange
keys for IPSec SA.
The final pair of packets perform peer authentication.
Step 2: IKE Phase 1

Site1:
crypto isakmp policy 10
authentication pre-share
encryption des
hash md5
group 2
default is set to 1.
!
! by default, set to DES

! Diffie-Hellman group 2, by
Site 2:
encryption des
hash md5
group 2
!
! The policy number is not required to match on endpoints,
however, the corresponding parameters should match.
Page 3 of 5
Step 3: IKE Phase 2:

The actual IPSec tunnel is established in IKE Phase 2. IKE Phase 1
creates a secure communication channel (its own SA) so that IPSec
tunnels (SAs) can be created for data encryption and transport.
The following functions are performed in IKE Phase 2(a) Negotiation of IPSec security parameters via IPSec transformset
(b) Establish IPSec SA (unidirectional IPSec tunnel)
(c) Periodic renegotiation of IPSec SAs to ensure security
(d) An additional DH exchange (optional)
Step 3: IKE Phase 2

Site1:
crypto isakmp key MY_K3Y address 123.1.1.2
!
crypto ipsec transform-set TS esp-des esp-md5-hmac
!
crypto map CRYPTO 10 ipsec-isakmp
set peer 123.1.1.2
set transform-set TS
match address Traffic_1to2
!
interface serial 0/0
crypto map CRYPTO
!
Site2:
crypto isakmp key MY_K3Y address 92.1.1.1
!
!
set peer 92.1.1.1
match address Traffic_2to1
!
crypto map CRYPTO
!
Step 4: Secure data transfer:

After IKE Phase 2 is successfully completed, all the interesting traffic
will flow through IPSec tunnel, meaning the interesting traffic will be
sent encrypted to the endpoint.
When PING from Site1 router's Loopback 0 interface is sent to Site2
Page 4 of 5
router's Loopback 0 interface, the Site1 router starts the IKE Phase 1
and once that is successful, it initiates IKE Phase 2. After successful
IKE Phase 2, traffic is sent through the IPSec tunnel.
The show crypto isakmp sa command shows the current IKE SAs.
"Active" status means ISAKMP SA is in active state. The Source IP
address indicates which endpoint initiated the IKE negotiation. The
QM_IDLE mode indicates Quick Mode exchange (there is also
Aggressive Mode exchange), meaning the IPSec SA remains
authenticated and can be used for several quick mode exchanges.
Site1# show crypto isakmp sa

dst
src
status
123.1.1.2
92.1.1.1
ACTIVE
state
conn-id slot
QM_IDLE
The show crypto ipsec sa command is used to show current SA

settings.
Site1# show crypto ipsec sa

interface: Serial0/0
Crypto map tag: CRYPTO, local addr 92.1.1.1
protected vrf: (none)
local ident (addr/mask/prot/port):
(10.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port):
(10.2.2.0/255.255.255.0/0/0)
current_peer 123.1.1.2 port 500
PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
#pkts
#pkts
#pkts
#send
compressed: 0, #pkts decompressed: 0

not compressed: 0, #pkts compr. failed: 0
not decompressed: 0, #pkts decompress failed: 0
errors 1, #recv errors 0
local crypto endpt.: 92.1.1.1, remote crypto endpt.:

123.1.1.2
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0
current outbound spi: 0x7FAD546D(2142065773)
inbound esp sas:
spi: 0xBDD4C094(3184836756)
transform: esp-des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: SW:1, crypto map: CRYPTO
sa timing: remaining key lifetime (k/sec):
(4596305/3586)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
Page 5 of 5
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x7FAD546D(2142065773)
sa timing: remaining key lifetime (k/sec):
(4596305/3584)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
Step 5: IPSec tunnel termination:

There are two events which can terminate an IPSec tunnel.
(a) It is possible to manually delete an IPSec tunnel.
(b) If the SA Lifetime timer expires, the tunnel is torn down.
However, if traffic transfer is still required, new pair of SA is created
before old SA is retired.
The SA Lifetime can be viewed using show crypto ipsec securityassociation lifetime command.
Sign in | Recent Site Activity | Report Abuse | Print Page | Powered By Google Sites
Site-to-site IPSec VPN using Digital Certificates - Knowledge Base
Knowledge Base
Page 1 of 9
Search this site
Home
BGP
Data Center
Site-to-site IPSec VPN using Digital Certificates
GPON
IPSec with digital certificate provides the most secure and scalable way to implement a VPN.
Authentication in IPSec can be provided through pre-shared keys (easy to implement) or digital
Hadoop
certificate (requires a CA Server trusted by both parties).
IP Multicast
IPv6
The following scenario demonstrates IPSec VPN between two Branch routers who obtain a Digital
Certificate from a CA Server (Windows Server 2003) based in their Central Office.
IS-IS
Juniper-JUNOS
L2VPN
LAN
Link Aggregation
LTE Notes
MPLS
NAT
OAM
OSPF
PBB
PPP
QoS
Obtaining Digital Certificates for the Branch routers
Security
Traffic Engineering
VPLS
VPN
Attachments
First step is to obtain a digital certificate from the trusted CA Server. This requires a hostname and
domain-name on both Branch routers. It also requires time synchronization between routers and CA
Server.
hostname Branch1
ip domain-name amit.com
!
ntp server 192.168.1.9
Then we generate general-purpose RSA keys. This process generates a Public Key and a Private
Key.
Branch1(config)# crypto key generate rsa general-keys modulus 1024 label BRANCH_KEY
exportable
! generating a general-purpose key pair of 1024 bits labelled as
BRANCH_KEY.
Then we create a trustpoint on the routers to define the trusted CA Server.
crypto pki trustpoint WIN2003

! Windows Server 2003 (192.168.1.9). This trustpoint name is
user-defined and has local significance.
enrollment url http://192.168.1.9/certsrv/mscep/mscep.dll
enrollment mode ra
! Required as Server 2003 provides Registration Authority
(RA) when SCEP is installed
rsakeypair BRANCH_KEY
revocation-check none
!
After creating the trustpoint, we request the CA Certificate for this trustpoint. This is to validate the CA
Server.
Branch1(config)# crypto pki authenticate WIN2003

Certificate has the following attributes:
Fingerprint MD5: 7D39EB83 CE48ECF4 91E5E5F7 A0022760
Fingerprint SHA1: D27CD5D2 865FC153 26CA66A2 197AABF6 922510BF
% Do you accept this certificate? [yes/no]: yes
https://sites.google.com/site/amitsciscozone/home/ipsec/site-to-site-ipsec-vpn-using-di...
4/08/2014
Page 2 of 9
Trustpoint CA certificate accepted.

Branch1(config)#
And the last step in the process of obtaining certificate is to actually request a digital certificate from
the CA Server for the router itself using crypto pki enroll WIN2003 command. The CA Server will
generate a unique digital certificate for each routers.
The following output shows the digital certificates available on the routers.
Branch1# show crypto pki certificates

Certificate
Status: Available
Certificate Serial Number: 0x614C662A000000000009
Certificate Usage: General Purpose
Issuer:
cn=WIN2003
dc=amit
dc=com
Subject:
Name: Branch1.amit.com
hostname=Branch1.amit.com
CRL Distribution Points:
ldap:///CN=WIN2003,CN=amit-ed0d48583a,CN=CDP,CN=Public%20Key%20Services,CN=S
ervices,CN=Configuration,DC=amit,DC=com?certificateRevocationList?base?
objectClass=cRLDistributionPoint
http://amit-ed0d48583a.amit.com/CertEnroll/WIN2003.crl
Validity Date:
start date: 04:00:18 AEST Jun 5 2010
end
date: 04:10:18 AEST Jun 5 2011
Associated Trustpoints: WIN2003
CA Certificate
Status: Available
Certificate Serial Number: 0x6462CFFA77B593A74DB4E13D530CBC02
Certificate Usage: Signature
Issuer:
cn=WIN2003
dc=amit
dc=com
Subject:
cn=WIN2003
dc=amit
dc=com
ldap:///CN=WIN2003,CN=amit-ed0d48583a,CN=CDP,CN=Public%20Key%
20Services,CN=Services,CN=Configuration,DC=amit,DC=com?certificateRevocationList?base?
Validity Date:
start date: 03:31:18 AEST May 21 2010
end
date: 03:40:13 AEST May 21 2020
Branch2# show crypto pki certificates
Certificate
Status: Available
Certificate Serial Number: 0x614AE084000000000008
Certificate Usage: General Purpose
Issuer:
cn=WIN2003
dc=amit
dc=com
Subject:
Name: Branch2.amit.com
hostname=Branch2.amit.com
Validity Date:
start date: 03:58:38 AEST Jun 5 2010
end
date: 04:08:38 AEST Jun 5 2011
CA Certificate
Status: Available
4/08/2014
Page 3 of 9
Certificate Serial Number: 0x6462CFFA77B593A74DB4E13D530CBC02

Certificate Usage: Signature
Issuer:
cn=WIN2003
dc=amit
dc=com
Subject:
cn=WIN2003
dc=amit
dc=com
Validity Date:
start date: 03:31:18 AEST May 21 2010
end
date: 03:40:13 AEST May 21 2020
Configuring IKE Policies

The crypto isakmp policy <number> command creates IKE Phase 1 policy. The range of "number"
parameters is 1-10000. The authentication command specifies the type of authentication to use
when validating the identity of the remote IPSec peer.
1. rsa-sig : This method specifies that digital certificates are used for authentication.
2. rsa-encr: This method specifies that RSA encrypted nonces (random numbers) are used.
3. pre-share: This method specifies that a single pre-shared key is used.

encryption 3des
authentication rsa-sig
hash md5
group 1
!
IKE Phase 1 policies can be verified using show crypto isakmp policy command.
Configuring Transform-set and Defining Interesting Traffic

A transform-set defines how data traffic is protected in IKE Phase 2. The transform set protection
parameters implemented here areesp-3des: ESP encryption with 3DES
esp-md5-hmac: ESP packet integrity check with MD5
All traffic from 192.168.11.0/24 to 192.168.22.0/24, and vice versa, should go through IPSec tunnel.
crypto ipsec transform-set TS esp-3des esp-md5-hmac

!
ip access-list extended ACL
permit ip 192.168.11.0 0.0.0.255 192.168.22.0 0.0.0.255
The transform-set can be verified using show crypto ipsec transform-set command.
Configuring Static Crypto Map

A crypto map ties together all the IKE Phase 2 components to build protected data connections to
remote IPSec peer.

match address ACL
set peer 10.2.2.1
!
4/08/2014
Page 4 of 9
ip address 10.1.1.1 255.255.255.0

crypto map CRYPTO
Verification
When Branch1 router initiates a Ping to remote LAN using the source-interface as its LAN interface,
the traffic matches the ACL and is considered interesting traffic. IKE Phase 1 begins at this stage. No
traffic is sent successfully until IKE Phase 1 and 2 are successfully completed.
The purpose of IKE Phase 1 is to establish a secure communication channel (sometimes called
management connection) and generate keys for IPSec.
Branch1 router initiates IKE negotiation by sending a Policy Proposal message to its peer. This
message contains one or more IKE policies containing parameters such as encryption algorithm,
authentication method, hash algorithm, Diffie-Hellman group and SA lifetime. The peer router
examines the IKE policy information and attempts to find a match within its own locally configured IKE
policies. It responds with a Policy Acceptance message of acceptance of one of the sender's policies.
The IKE policy is now negotiated.
IKE Policy Negotiated

Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
6
6
6
6
6
6
6
6
6
6
6
6
6
6
10:21:50.071:
10:21:50.071:
10:21:50.071:
10:21:50.071:
10:21:50.075:
10:21:50.075:
10:21:50.087:
10:21:50.087:
10:21:50.091:
10:21:50.091:
10:21:50.095:
10:21:50.095:
10:21:50.095:
10:21:50.095:
ISAKMP:(0): SA request profile is (NULL)

ISAKMP: Created a peer struct for 10.2.2.1, peer port 500
ISAKMP: New peer created peer = 0x6735D84C peer_handle = 0x80000002
ISAKMP: Locking peer struct 0x6735D84C, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
insert sa successfully sa = 66BF8998
ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
ISAKMP:(0):No pre-shared key with 10.2.2.1!
ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
Jun 6 10:21:50.095: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1

! Indicates
IKE negotiation has begun and first ISAKMP message in Main Mode is about to be sent
Jun
Jun
6 10:21:50.099: ISAKMP:(0): beginning Main Mode exchange

6 10:21:50.099: ISAKMP:(0): sending packet to 10.2.2.1 my_port 500 peer_port 500 (I)
MM_NO_STATE
Jun
Jun
! Indicates Branch1 router is sending IKE Policy Proposal message
6 10:21:50.099: ISAKMP:(0):Sending an IKE IPv4 Packet.

6 10:21:50.307: ISAKMP (0:0): received packet from 10.2.2.1 dport 500 sport 500 Global
(I) MM_NO_STATE
peer
Jun
! Indicates Branch1 router received IKE Policy Acceptance message from remote
6 10:21:50.319: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Jun 6 10:21:50.319: ISAKMP:(0):Old State = IKE_I_MM1

that first two messages were exchanged successfully
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
6
6
6
6
6
6
6
6
6
6
6
6
New State = IKE_I_MM2
! Indicates
10:21:50.323: ISAKMP:(0): processing SA payload. message ID = 0

10:21:.!50.327: ISAKMP:(0): processing vendor id payload
10:21:50.327: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
10:21:50.327: ISAKMP (0:0): vendor ID is NAT-T RFC 3947
10:21:50.327: ISAKMP : Scanning profiles for xauth ...
10:21:50.331: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
10:21:50.331: ISAKMP:
encryption 3DES-CBC
10:21:50.331: ISAKMP:
hash MD5
10:21:50.331: ISAKMP:
default group 1
10:21:50.331: ISAKMP:
auth RSA sig
10:21:50.331: ISAKMP:
life type in seconds
10:21:50.335: ISAKMP:
life duration (VPI) of 0x0 0x1 0x51 0x80
Jun 6 10:21:50.335: ISAKMP:(0):atts are acceptable. Next payload is 0

the attributes received are acceptable
10:21:50.335:
10:21:50.339:
10:21:50.339:
10:21:50.339:
10:21:50.339:
10:21:50.343:
! Indicates that
Jun
Jun
Jun
Jun
Jun
Jun
6
6
6
6
6
6
ISAKMP:(0):Acceptable atts:actual life: 0

ISAKMP:(0):Acceptable atts:life: 0
ISAKMP:(0):Fill atts in sa vpi_length:4
ISAKMP:(0):Fill atts in sa life_in_seconds:86400
ISAKMP:(0):Returning Actual lifetime: 86400
ISAKMP:(0)::Started lifetime timer: 86400
Jun
Jun
6 10:21:50.395: ISAKMP:(0): processing vendor id payload

6 10:21:50.395: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
4/08/2014
Jun
Jun
Jun
Page 5 of 9
6 10:21:50.395: ISAKMP (0:0): vendor ID is NAT-T RFC 3947

6 10:21:50.395: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
6 10:21:50.395: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM2
The next two message serve to exchange Diffie-Hellman Public-Key values. Diffie-Hellman is a publickey algorithm that allows peers to exchange Public Key values over an insecure network. Combined
together with their own Private Keys, both routers derive a same shared secret key (also called
session key).
Diffie-Hellman Key Exchange

Jun
Jun
6 10:21:50.395: ISAKMP (0:0): constructing CERT_REQ for issuer cn=WIN2003,dc=amit,dc=com

6 10:21:50.399: ISAKMP:(0): sending packet to 10.2.2.1 my_port 500 peer_port 500 (I)
MM_SA_SETUP ! Indicates Branch1 router is sending its Diffie-Hellman Public Key and Nonce
value to remote peer
Jun
Jun
6 10:21:50.399: ISAKMP:(0):Sending an IKE IPv4 Packet.

6 10:21:50.399: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

third message in IKE Phase 1 is sent
Jun
! Indicates
(I) MM_SA_SETUP
! Indicates Branch1 router receives Diffie-Hellman Public Key and Nonce
value from remote peer- Branch2 router
Jun 6 10:21:50.587: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Jun 6 10:21:50.591: ISAKMP:(0):Old State = IKE_I_MM3 New State = IKE_I_MM4
that four messages have been exchanged successfully in IKE Phase 1
Jun 6 10:21:50.595: ISAKMP:(0): processing KE payload. message ID = 0
contains Diffie-Hellman Public Key of Branch2 router
! Indicates
! This payload
Jun 6 10:21:50.659: ISAKMP:(0): processing NONCE payload. message ID = 0

contains the Nonce (random value) of Branch2 router
! This payload
The last two messages of IKE Phase 1 between IKE peers using RSA-Signature exchange
Identification, Digital Certificate and Digital Signature. The ID can be the peer IP Address or fully
qualified domain name (FQDN). The messages are encrypted using the encryption method negotiated
in IKE Policy and the key used is the session-key derived using Diffie-Hellman key exchange.
ID and Certificate Exchange in IKE Phase 1

Jun
6 10:21:50.659: ISAKMP:(1001): processing CERT_REQ payload. message ID = 0
Jun 6 10:21:50.659: ISAKMP:(1001): peer wants a CT_X509_SIGNATURE cert

! Indicates the peer
has requested a Digital Certificate as the authentication method used is RSA-SIG
Jun 6 10:21:50.659:
Jun 6 10:21:50.659:
Jun 6 10:21:50.659:
Jun 6 10:21:50.659:
Jun 6 10:21:50.663:
Jun 6 10:21:50.663:
Jun 6 10:21:50.663:
Jun 6 10:21:50.667:
Jun 6 10:21:50.667:
Jun 6 10:21:50.667:
Jun 6 10:21:50.667:
Jun 6 10:21:50.671:
Jun 6 10:21:50.675:
Jun 6 10:21:50.691:
Jun 6 10:21:50.691:
Jun 6 10:21:50.691:
ID_FQDN
Jun 6 10:21:50.691:
next-payload
type
FQDN name
protocol
port
length
Jun 6 10:21:50.691:
Jun 6 10:21:50.707:
Jun 6 10:21:50.707:
ISAKMP:(1001): peer wants cert issued by cn=WIN2003,dc=amit,dc=com

Choosing trustpoint WIN2003 as issuer
ISAKMP:(1001): processing vendor id payload
ISAKMP:(1001): vendor ID is Unity
ISAKMP:(1001): vendor ID is DPD
ISAKMP:(1001): speaking to another IOS box!
ISAKMP:received payload type 20
ISAKMP:received payload type 20
ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1001):Old State = IKE_I_MM4 New State = IKE_I_MM4
ISAKMP:(1001):Send initial contact
ISAKMP:(1001):My ID configured as IPv4 Addr, but Addr not in Cert!
ISAKMP:(1001):Using FQDN as My ID
ISAKMP:(1001):SA is doing RSA signature authentication using id type
ISAKMP (0:1001): ID payload
: 6
: 2
: Branch1.amit.com
: 17
: 500
: 24
ISAKMP:(1001):Total payload length: 24
ISAKMP (0:1001): constructing CERT payload for hostname=Branch1.amit.com
ISKAMP: growing send buffer from 1024 to 3072
Jun 6 10:21:50.707: ISAKMP:(1001): using the WIN2003 trustpoint's keypair to sign !

Indicates the Digital Certificate is signed by the Public Key of the CA Server (Windows Server
4/08/2014
Page 6 of 9
2003)
Jun 6 10:21:50.751: ISAKMP:(1001): sending packet to 10.2.2.1 my_port 500 peer_port 500 (I)
MM_KEY_EXCH
Jun 6 10:21:50.755: ISAKMP:(1001):Sending an IKE IPv4 Packet.
Jun 6 10:21:50.755: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Jun 6 10:21:50.759: ISAKMP:(1001):Old State = IKE_I_MM4 New State = IKE_I_MM5 ! Indicates
the Branch1 router has sent the fifth message of IKE Phase 1 containing the Digital
Certificate
Jun
(I) MM_KEY_EXCH
Jun
Jun
Jun
! This router has received the Digital Certificate from the peer
6 10:21:51.083: ISAKMP:(1001): processing ID payload. message ID = 0

6 10:21:51.083: ISAKMP (0:1001): ID payload
next-payload : 6
type
: 2
FQDN name
: Branch2.amit.com
protocol
: 17
port
: 500
length
: 24
6 10:21:51.087: ISAKMP:(0):: peer matches *none* of the profiles
Jun 6 10:21:51.087: ISAKMP:(1001): processing CERT payload. message ID = 0

payload contains the Digital Certificate
Jun
Jun
Jun
Jun
Jun
6
6
6
6
6
10:21:51.087:
10:21:51.143:
10:21:51.187:
10:21:51.191:
10:21:51.191:
! The CERT
ISAKMP:(1001): processing a CT_X509_SIGNATURE cert

ISAKMP:(1001): peer's pubkey isn't cached
ISAKMP:(1001): Unable to get DN from certificate!
ISAKMP:(1001): Cert presented by peer contains no OU field.
ISAKMP:(0):: peer matches *none* of the profiles
Jun 6 10:21:51.199: ISAKMP:(1001): processing SIG payload. message ID = 0 ! This router is

processing the Digital Signature of the Certificate contained in SIG payload
Jun
6 10:21:51.215: ISAKMP:(1001):SA authentication status:

authenticated
Jun 6 10:21:51.215: ISAKMP:(1001):SA has been authenticated with 10.2.2.1

the peers have authenticated themselves
Jun 6 10:21:51.219: ISAKMP: Trying to insert a peer 10.1.1.1/10.2.2.1/500/,
successfully 6735D84C.
Jun 6 10:21:51.219: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
the sixth message has been exchanged in IKE Phase 1
! This indicates
and inserted
! Indicates
Jun
Jun
6 10:21:51.223: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

6 10:21:51.223: ISAKMP:(1001):Old State = IKE_I_MM6 New State = IKE_I_MM6
Jun
Jun
6 10:21:51.231: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

6 10:21:51.231: ISAKMP:(1001):Old State = IKE_I_MM6 New State = IKE_P1_COMPLETE
Jun 6 10:21:51.247:
Jun 6 10:21:51.251:
Jun 6 10:21:51.255:
QM_IDLE
Jun 6 10:21:51.255:
Jun 6 10:21:51.259:
Jun 6 10:21:51.259:
Jun 6 10:21:51.259:
Jun 6 10:21:51.263:
ISAKMP:(1001):beginning Quick Mode exchange, M-ID of -1512312688

ISAKMP:(1001):QM Initiator gets spi
ISAKMP:(1001): sending packet to 10.2.2.1 my_port 500 peer_port 500 (I)
ISAKMP:(1001):Sending an IKE IPv4 Packet.
ISAKMP:(1001):Node -1512312688, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
ISAKMP:(1001):Old State = IKE_QM_READY New State = IKE_QM_I_QM1
ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1001):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
4/08/2014
Page 7 of 9
The completion of IKE Phase 1 can be verified using show crypto isakmp sa command.
show crypto isakmp sa

Branch1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst
src
10.2.2.1
10.1.1.1
state
QM_IDLE
conn-id slot status

1001
0 ACTIVE
At this point a bidirectional SA is established between the peers. This is used to secure IKE Phase 2
negotiations which are used to negotiate IPSec SAs.
In IKE Phase 2, three messages are exchanged between IPSec peers. IKE Phase 2 occurs in only
Quick Mode. The first message contains a Hash, IPSec proposals (configured using crypto ipsec
transform-set command), a Nonce value and ID. The Hash authenticates the message to the remote
peer. The IPSec proposals used to specify the security protocol like AH or ESP, encryption algorithm
like DES/3DES/AES, and IPSec tunnel mode like Transport mode or Tunnel mode. The Nonce value is
used to protect against replay attacks.
An additional Diffie-Hellman Key Exchange can also occur if Perfect Forward Secrecy (PFS) is enabled
in IPSec Proposal. This is configured as below. Group 1/2/5 indicates Diffie-Hellman groups.
Enabling PFS
crypto map CRYPT0 10 ipsec-isakmp
match address ACL
set peer 10.2.2.1
set pfs {group 1 | group 2 | group 5}
The ID payload contains the identities like address, port, protocol for which this IPSec SA is being
established. This is defined using crypto access-list (configured using match address <acl>
command).
The remote peer then responds with a Hash, an IPSec Proposal Acceptance, a Nonce value, and
identities. This is the second message of IKE Phase 2.
The last message contains a Hash, and it is used to acknowledge to the remote peer.
IKE Phase 2 messages

Jun 6 10:21:51.247: ISAKMP:(1001):beginning Quick Mode exchange, M-ID of -1512312688
Phase 2 begins in Quick Mode
! IKE
Jun 6 10:21:51.251: ISAKMP:(1001):QM Initiator gets spi

QM_IDLE
! This router (initiator)
sends the first message in IKE Phase 2
Jun
Jun
Jun
Jun
Jun
6
6
6
6
6
10:21:51.259:
10:21:51.259:
10:21:51.259:
10:21:51.263:
10:21:51.447:
(I) QM_IDLE
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
6
6
6
6
6
6
6
6
6
6
6
ISAKMP:(1001):Node -1512312688, Input = IKE_MESG_INTERNAL, IKE_INIT_QM

ISAKMP:(1001):Old State = IKE_QM_READY New State = IKE_QM_I_QM1
ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1001):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
ISAKMP (0:1001): received packet from 10.2.2.1 dport 500 sport 500 Global
! This is the second message in IKE Phase 2
10:21:51.451:
10:21:51.451:
10:21:51.455:
10:21:51.455:
10:21:51.455:
10:21:51.455:
10:21:51.455:
10:21:51.455:
10:21:51.459:
10:21:51.459:
10:21:51.459:
ISAKMP:(1001): processing HASH payload. message ID = -1512312688

ISAKMP:(1001): processing SA payload. message ID = -1512312688
ISAKMP:(1001):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_3DES
ISAKMP:
attributes in transform:
ISAKMP:
encaps is 1 (Tunnel)
ISAKMP:
SA life type in seconds
ISAKMP:
SA life duration (basic) of 3600
ISAKMP:
SA life type in kilobytes
ISAKMP:
SA life duration (VPI) of 0x0 0x46 0x50 0x0
ISAKMP:
authenticator is HMAC-MD5
Jun 6 10:21:51.463: ISAKMP:(1001):atts are acceptable.

acceptable by this router
! The transform-set parameters are
4/08/2014
Jun
Jun
Jun
Jun
Jun
Page 8 of 9
6
6
6
6
6
10:21:51.463: ISAKMP:(1001): processing NONCE payload. message ID = -1512312688

10:21:51.463: ISAKMP:(1001): processing ID payload. message ID = -1512312688
10:21:51.467: ISAKMP:(1001): processing ID payload. message ID = -1512312688
10:21:51.471: ISAKMP:(1001): Creating IPSec SAs
10:21:51.475:
inbound SA from 10.2.2.1 to 10.1.1.1 (f/i) 0/ 0
(proxy 192.168.22.0 to 192.168.11.0)
Jun 6 10:21:51.475:
has spi 0xAC4D6EB3 and conn_id 0
Jun 6 10:21:51.475:
lifetime of 3600 seconds
Jun 6 10:21:51.475:
lifetime of 4608000 kilobytes
Jun 6 10:21:51.479:
outbound SA from 10.1.1.1 to 10.2.2.1 (f/i) 0/0
(proxy 192.168.11.0 to 192.168.22.0)
Jun 6 10:21:51.479:
has spi 0x34F84D56 and conn_id 0
Jun 6 10:21:51.479:
Jun 6 10:21:51.479:
QM_IDLE
IKE Phase 2
! This is the last message in
Jun 6 10:21:51.487: ISAKMP:(1001):deleting node -1512312688 error FALSE reason "No Error"
Jun 6 10:21:51.487: ISAKMP:(1001):Node -1512312688, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
Jun 6 10:21:51.487: ISAKMP:(1001):Old State = IKE_QM_I_QM1 New State =
IKE_QM_PHASE2_COMPLETE
At this stage a uni-directional SA is established between two entities. An SA is uniquely identified by a

unique 32-bit number called Security Parameter Index (SPI), destination address and security
protocol.
IPSec uses Security Policy Database (SPD) and Security Association Database (SAD). The SPD defines
traffic that should be dropped, traffic that should be protected by IPSec and traffic that should not be
protected by IPSec. The SAD contains the SA parameters like SPI, algorithms and keys.
If during traffic processing, the outbound traffic that should be protected by IPSec has no SA in SAD,
this will trigger IKE protocol to negotiate IPSec SA with remote peer.
The show crypto ipsec sa command shows parameters of IPSec SA including the number of packets
that passed through IPSec tunnel successfully.
show crypto ipsec sa

Branch1# show crypto ipsec sa
Crypto map tag: CRYPTO, local addr 10.1.1.1
local ident (addr/mask/prot/port): (192.168.11.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.22.0/255.255.255.0/0/0)
PERMIT, flags={origin_is_acl,}
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.2.2.1
current outbound spi: 0x34F84D56(888687958)
4/08/2014
Page 9 of 9
inbound esp sas:

spi: 0xAC4D6EB3(2890755763)
transform: esp-3des esp-md5-hmac ,
sa timing: remaining key lifetime (k/sec): (4506395/3539)
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x34F84D56(888687958)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
All the actual data traffic is encrypted using the encryption algorithm negotiated in IPSec proposal.
Comments
You do not have permission to add comments.
4/08/2014
HA for site-to-site VPN using HSRP - Knowledge Base
Knowledge Base
Page 1 of 6
Search this site
Home
BGP
High-Availability for site-to-site VPN using HSRP
Data Center
HSRP is used to track router's interface status to achieve failover between routers.
GPON
However, no correlation exists between IPSec and HSRP, and so HSRP cannot track
Hadoop
IPSec's SA state and IPSec requires schemes in order to synchronize HSRP failover when
IP Multicast
IPv6
IS-IS
it occurs. Here, the HA for site-to-site VPN using HSRP is illustrated which is a scheme
that provides a correlation between HSRP and IPSec.
Network topology:
Juniper-JUNOS
L2VPN
LAN
Link Aggregation
LTE Notes
MPLS
NAT
OAM
OSPF
PBB
PPP
QoS
Security
Traffic Engineering
The Remote site R4 router negotiates an IPSec tunnel at the Headend site to access the
internal network behind R3 router. But, redundancy is configured using HSRP on R1 and
VPLS
R2 routers. So, R4 router initiates IPSec negotiation with the Virtual IP address
VPN
10.1.1.1/24. In case of link-failure or device-failure, the standby HSRP router takes over
the role of active router.
Attachments
The initial configuration of all routers is as follows-
Initial configuration on R1
interface fastethernet 0/0
ip address 172.16.1.1 255.255.255.0
!
ip address 10.1.1.2 255.255.255.0
standby 1 ip 10.1.1.1
standby 1 preempt
standby 1 priority 105
standby 1 timers 1 3
standby 1 track fastethernet 0/0 10
!
ip address 172.16.1.2 255.255.255.0
!
ip address 10.1.1.3 255.255.255.0
standby 1 preempt
standby 1 timers 1 3
standby 1 track fastethernet 0/0 10
!
https://sites.google.com/site/amitsciscozone/home/ipsec/ha-for-site-to-site-vpn-using-hsr 4/08/2014
Page 2 of 6
ip address 172.16.1.3 255.255.255.0
!
interface Loopback 0
ip address 192.168.1.1 255.255.255.0
!
ip address 172.16.2.2 255.255.255.0
!
ip address 192.168.2.1 255.255.255.0
!
Dynamic crypto-map and RRI:

Dynamic crypto-map is configured on R1 and R2 routers. It accepts IPSec sessions
dynamically from an arbitrary source without specifying the peer address manually. The
dynamic crypto-maps is always assigned to a static crypto-map. Here, a Reverse-route
injection (RRI) is configured under crypto-map configuration. RRI is the ability for the
static routes to be automatically inserted into the routing process for those networks and
hosts that are protected by the remote tunnel endpoint. These protected hosts and
networks are called remote proxy identities.
Each route is created based on the remote proxy network and mask, with next-hop to this
network being the remote tunnel endpoint. By using the remote tunnel endpoint as the
next-hop, traffic is forced through the crypto process to be encrypted.
Dynamic crypto-map configuration on R1

encryption des
hash md5
group 2
!
crypto isakmp key 0 MY_K3Y address 0.0.0.0
!
!
crypto dynamic-map DM 10
match address Traffic_to_remote
reverse-route
!
! The wildcard address 0.0.0.0 is used which is not a good practice. Instead, RSA
signature authentication method is recommended.
!
ip access-list extended Traffic_to_remote
permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
!
crypto map CRYPTO 10 ipsec-isakmp dynamic DM
!
! The dynamic crypto-map DM is assigned to a static crypto-map CRYPTO.
Dynamic crypto-map configuration on R2

encryption des
Page 3 of 6
hash md5
group 2
!
!
!
reverse-route
!
permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
!
!
crypto map CRYPTO 10 ipsec-isakmp dynamic DM
!
Static crypto map configuration on R4

encryption des
hash md5
group 2
!
!
!
crypto map CRYPTO
set peer 10.1.1.1
match address Traffic_to_headend
!
! The peer address 10.1.1.1 is set to the Virtual IP address of the HSRP group.
!
ip access-list extended Traffic_to_headend
permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
!
crypto map CRYPTO
!
Now, these static crypto-maps are assigned to HSRP. However, an additional information
is required- HSRP name. HSRP name is configured using standby <group-number>
name <name> command under interface configuration mode. It assigns a unique name
for HSRP group which will be used to assign along with the crypto-map.
This HSRP name when assigned to the crypto-map, forces the crypto-map to source IKE
Phase 1 and IKE Phase 2 packets off the HSRP Virtual IP address 10.1.1.1. This can be
done using crypto map <map-name> redundancy <group-name> command from
interface configuration mode.
R1 router:
standby 1 name INTERNAL
crypto map CRYPTO redundancy INTERNAL
!
R2 router:
standby 1 name INTERNAL
crypto map CRYPTO redundancy INTERNAL
Page 4 of 6
!
!HSRP group names should match on both routers.
Routing Protocol configuration:

Both, headend and remote, sites use RIP internally. Both sites connect to the ISP using
EIGRP. Now, upon successful establishment of IPSec SA for remote proxies, static routes
are created due to RRI. The next hop for those remote proxies is via the remote VPN
router whose address is learned and applied during the creation of dynamic crypto-map
template. The routes are deleted after the SAs are deleted.
The idea is to redistribute this static route created by RRI internally on the headend site
so that internal routers like R3 can forward the packets through the active HSRP router. In
order to do this, the static routes are redistributed with better metric into RIP by R1 and
R2 routers using offset-list <ACL-number> <in | out> <offset-value> command
under router configuration mode. This command matches the ACL and adds the offsetvalue to the metric to the prefix. Of course, this can also be done using redistribute
static metric <metric-value> router configuration command.
R2 router redistributes static routes with default value.
RIP & EIGRP configuration on R1

router rip
version 2
no auto-summary
network 172.16.1.0
redistribute eigrp 10 metric 10
redistribute static
offset-list 10 out 2
!
router eigrp 10
no auto-summary
network 10.1.1.0
redistribute rip metric 100000 0 255 1 1500
!
access-list 10 permit 192.168.2.0 0.0.0.255
!
RIP configuration on R3
router rip
version 2
no auto-summary
network 172.16.1.0
network 192.168.1.0
!
RIP and EIGRP configuration on R4

router rip
version 2
no auto-summary
network 192.168.2.0
redistribute eigrp 10 metric 10
!
router eigrp 10
no auto-summary
network 172.16.2.0
redistribute rip metric 100000 0 255 1 1500
!
Before any SAs are created, the routing protocols exchange prefixes with each router.
Page 5 of 6
However, when R4 router attempts to ping the network 192.168.1.0/24 sourcing from its
Loopback 0 interface 192.168.2.1, it classifies as the interesting traffic and R4 negotiates
IKE Phase 1 & 2 with the peer 10.1.1.1. Here, 10.1.1.1 is the Virtual IP address of the
HSRP group and since R1 router is the active HSRP router, it will respond to R4 router's
negotiations and form the IPSec SA. Since RRI is configured on R1, it will create a static
route to 192.168.2.0/24 network with next-hop as R4's tunnel endpoint 172.16.2.2.
Before failover: R1 & R3

R1# show ip route | begin Gateway
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 2 subnets

172.16.1.0 is directly connected, FastEthernet0/0
172.16.2.0 [90/307200] via 10.1.1.4, 00:16:59, FastEthernet0/1

C
R

192.168.1.0/24 [120/1] via 172.16.1.3, 00:00:16, FastEthernet0/0
192.168.2.0/24 [1/0] via 172.16.2.2
R1# show crypto isakmp sa

dst
10.1.1.1
src
172.16.2.2
state
QM_IDLE
conn-id slot status

1001
0 ACTIVE

C
R


C
R
192.168.1.0/24 is directly connected, Loopback0

Now, Fastethernet 0/0 of R1 fails, HSRP fails over to R2 router and changes the HSRP
state from "standby" to "active". R4 deletes the SA since R1 relinquishes the "active" state
and R2 becomes the "active" router. This causes R2 router to respond to R4 router for
virtual IP address 10.1.1.1. R1 deletes the static route while R2 creates the same static
route and redistributes to R3 router.
After failover: R1, R2 & R3

D EX
D

C
D EX 192.168.1.0/24 [170/281600] via 10.1.1.3, 00:01:54, FastEthernet0/1
D EX 192.168.2.0/24 [170/307200] via 10.1.1.4, 00:00:48, FastEthernet0/1
dst
10.1.1.1
src
172.16.2.2
state
QM_IDLE
conn-id slot status

1004
0 ACTIVE

Page 6 of 6


C
R

192.168.2.0/24 [1/0] via 172.16.2.2



R
C

192.168.1.0/24 is directly connected, Loopback0
Although HSRP timers are tuned, it takes a lot longer for IPSec tunnel to recreate again
after failover. This method is not recommended for high-availability in IPSec VPN.
Ping result from R4

R4# ping 192.168.1.1 source loopback 0 repeat 720
Type escape sequence to abort.
Sending 2000, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..........................
........!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 95 percent (684/720), round-trip min/avg/max = 80/171/300 ms
HA for IPSec VPN using IP SLA - Knowledge Base
Knowledge Base
Page 1 of 5
Search this site
Home
BGP
Data Center
HA for IPSec VPN using IP SLA

Network Topology:
GPON
Hadoop
IP Multicast
IPv6
IS-IS
Juniper-JUNOS
L2VPN
LAN
Link Aggregation
LTE Notes
MPLS
NAT
OAM
OSPF
PBB
PPP
QoS
Security
Traffic Engineering
VPLS
High-availability for IPSec VPN can also be provided using IP SLA object
tracking. Here, the remote site R4 router first attempts to set up an IPSec
tunnel with R1 router at the Central Site. When the path to reach R1 router is
unreachable, R4 router deletes IPSec SA for R1 router and tries to negotiate an
IPSec tunnel through backup path via R2 router.
All the traffic for the network behind R3 router sourced from the network behind
R4 router and vice versa will be encrypted by IPSec.
VPN
Attachments
Dynamic crypto-map configuration on R1 & R2

encryption des
hash md5
group 2
!
!
!
reverse-route
!
permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
!
crypto map STATIC 10 ipsec-isakmp dynamic DM
!
interface Serial 0/0
crypto map STATIC
!
https://sites.google.com/site/amitsciscozone/home/ipsec/ha-for-ipsec-vpn-using-ip-sla
4/08/2014
Page 2 of 5
Static crypto-map configuration on R4

encryption des
hash md5
group
!
crypto
crypto
!
crypto
!
crypto
2
isakmp key 0 MY_K3Y address 10.1.1.1
isakmp key 0 MY_K3Y address 10.1.1.5
ipsec transform-set TS esp-des esp-md5-hmac
map PRIMARY 10 ipsec-isakmp
set peer 10.1.1.1

match address Traffic_to_central
!
crypto map BACKUP 10 ipsec-isakmp
set peer 10.1.1.5
match address Traffic_to_central
!
ip access-list extended Traffic_to_central
permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
!
crypto map PRIMARY
!
crypto map BACKUP
!
Cisco IOS IP SLA:

Cisco IOS IP SLA is an active network performance measurement and diagnostic
tool that uses active monitoring, which includes the generation of traffic in
continuous, reliable and predictable manner. It actively sends data across the
network to measure performance between multiple network locations or across
multiple network paths. It uses the timestamp information to calculate
performance metrics such as jitter, latency, network and server response times,
packet loss, MOS (Mean Opinion Score) voice quality scores.
A destination router running Cisco IOS is configured to function as an IP SLA
Responder, which processes measurement packets and provide detailed
timestamp information.
R1 & R2 IP SLA Responders

R1 router:
ip sla responder
!
R2 router:
ip sla responder
!
4/08/2014
Page 3 of 5
IP SLA configuration on R4
ip sla 1
icmp-echo 10.1.1.1
timeout 1000
frequency 3
threshold 2
!
ip sla schedule 1 life forever start-time now
!
track 10 rtr 1 reachability
!
! Tagging the static route with the tracking object 10 and adjusting the
AD of the floating static route to a higher value
!
ip route 0.0.0.0 0.0.0.0 172.16.1.1 track 10
!
ip route 0.0.0.0 0.0.0.0 172.16.1.5 254
!
The static route is available only if the status of tracking object is UP.
IP SLA Statistics and Tracking output

R4# show ip sla statistics
Round Trip Time (RTT) for
Index 1
Latest RTT: 4 milliseconds
Latest operation start time: *02:13:11.671 UTC Fri Mar 1 2002
Latest operation return code: Over threshold
Number of successes: 486
Number of failures: 0
Operation time to live: Forever
R4# show track
Track 10
Response Time Reporter 1 reachability
Reachability is Up
1 change, last change 00:23:48
Latest operation return code: Over threshold
Latest RTT (millisecs) 60
Tracked by:
STATIC-IP-ROUTING 0
When traffic is sent from R4 router's Loopback 0 interface (192.168.2.1) to R1

router's Loopback 0 (192.168.1.1), R4 negotiates IPSec tunnel with R1 router.
Due to RRI, R1 creates a static route for 192.168.2.0/24 network with next-hop
as tunnel remote endpoint 172.16.1.2. This static route is redistributed into RIP
with a metric of 2 using redistribute static metric 2 command under RIP
router configuration mode.
Before Failover: Routing table output

R4# show ip route static
S*
0.0.0.0/0 [1/0] via 172.16.1.1
S
192.168.2.0/24 [1/0] via 172.16.1.2
R2#
R3# show ip route rip
4/08/2014
R
R
R
R
R
Page 4 of 5

172.16.1.4 [120/10] via 10.2.2.2, 00:00:04,
172.16.1.0 [120/10] via 10.2.2.1, 00:00:27,
10.0.0.0/8 is variably subnetted, 3 subnets, 2
10.1.1.0/30 [120/1] via 10.2.2.1, 00:00:27,
10.1.1.4/30 [120/1] via 10.2.2.2, 00:00:04,
192.168.2.0/24 [120/3] via 10.2.2.1, 00:00:27,
FastEthernet0/0
FastEthernet0/0
masks
FastEthernet0/0
FastEthernet0/0
FastEthernet0/0
During a continuous Ping to remote end, interface Fastethernet 0/0 (10.2.2.1) is

shutdown which causes the track status to go down, essentially, causing the
static route to fail. So, the floating static route becomes active. Since Serial 0/1
on R4 router is configured with a BACKUP static crypto-map and since the
interesting traffic is identified, R4 router negotiates backup IPSec tunnel with R2
router (10.1.1.5). Once the negotiation is successful, an IPSec tunnel is
configured and traffic is sent encrypted over the tunnel through R2 router to
192.168.1.0 network.
Ping output on R4
..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!.
*Mar 1 02:33:52.183: %TRACKING-5-STATE: 10 rtr 1 reachability
Up->Down..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 98 percent (298/303), round-trip min/avg/max = 4/108/404
ms
After Failover: Routing table output

S*
0.0.0.0/0 [254/0] via 172.16.1.5
S
192.168.2.0/24 [1/0] via 172.16.1.6
R3# show ip route rip
R
172.16.1.4 [120/10] via 10.2.2.2, 00:00:13,
R
172.16.1.0/30 is possibly down,
routing via 10.2.2.1, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2
R
10.1.1.0/30 is possibly down,
routing via 10.2.2.1, FastEthernet0/0
R
10.1.1.4/30 [120/1] via 10.2.2.2, 00:00:13,
R
192.168.2.0/24 [120/1] via 10.2.2.2, 00:00:13,
FastEthernet0/0
masks
FastEthernet0/0
FastEthernet0/0
ISAKMP output on R4
dst
src
10.1.1.1
172.16.1.2
10.1.1.5
172.16.1.6
state
QM_IDLE
QM_IDLE
conn-id slot status

1005
0 ACTIVE
1006
0 ACTIVE
4/08/2014
Page 5 of 5
As seen above, the failover is very quick and this solution provides highavailability (HA) with great results.
4/08/2014
IPSec with IPv6-in-IPv4 GRE tunnel - Knowledge Base
Knowledge Base
Page 1 of 10
Search this site
Home
BGP
Data Center
IPSec with IPv6-in-IPv4 GRE tunnel

Theory:
GPON
Hadoop
RFC 4891 discusses about IPSec with IPv6-in-IPv4 tunnels. It points out two
IP Multicast
different types of threats with IPv6-in-IPv4 tunnels which mandates the use of IPSec.
The two types of threats are-
IPv6
IS-IS
1) The IPv4 source address of the encapsulating (outer) packet can be spoofed
Juniper-JUNOS
L2VPN
2) The IPv6 source address of the encapsulated (inner) packet can be spoofed.
LAN
Link Aggregation
RFC 4891 discusses two ways to use IPSec- in transport and tunnel modes.
LTE Notes
MPLS
IPSec in Transport mode:
NAT
OAM
OSPF
PBB
PPP
QoS
Security
Traffic Engineering
VPLS
VPN
Attachments
In transport mode, the IPSec ESP or AH SA are established to protect traffic with the
header {IPv4 Source address, IPv4 Destination address, Protocol = 41}. On receiving
an IPSec packet, the receiver applies the IPSec transform (e.g. ESP or AH) and
matches the packet against Security Parameter Index (SPI) and the inbound selectors
associated with the SA to verify that the packet is appropriate for the SA via which it
was received. The successful verification ensures that the packet came from correct
IPv4 endpoint.
The transport mode takes care of threat # 1. But IPSec in Transport mode does not
verify the payload of the IPSec packet which carries IPv6 addresses. Hence, the inner
payload can be spoofed. The packet will be decapsulated and accepted. This
shortcoming can be mitigated by Ingress filtering which is a check to ensure packet is
received on the correct interface like RPF in IP multicasting.
IPSec in Tunnel mode:

In Tunnel mode, the IPSec SA is established to protect the traffic defined by {IPv6
Source address, IPv6 Destination address}. On receiving such an IPSec packet, the
receiver first applies the IPSec transform and matches the packet against SPI and
inbound selectors associated with the SA. The successful verification ensures that the
packet came from correct endpoint.
In tunnel mode, the outer IPv4 addresses can be spoofed and IPSec cannot detect
this in tunnel mode.
Network topology:
https://sites.google.com/site/amitsciscozone/home/ipsec/ipsec-with-ipv6-in-ipv4-gre-tu... 4/08/2014
Page 2 of 10
An IPv6-in-IPv4 GRE tunnel needs to be setup between R1 & R2 router connecting

the two IPv6 domains separated by an IPv4 network.
ipv6 unicast-routing
!
ip address 1.1.1.1 255.255.255.255
!
description IPv4 WAN Interface
ip address 10.1.1.1 255.255.255.252
!
description Internal IPv6 network
ipv6 address CAFE:1::1/64
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 10.1.1.0 0.0.0.3 area 0
!
ipv6 unicast-routing
!
ip address 2.2.2.2 255.255.255.255
!
description IPv4 WAN Interface
ip address 10.2.2.2 255.255.255.252
!
description Internal IPv6 network
ipv6 address CAFE:2::1/64
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 10.2.2.0 0.0.0.3 area 0
!
GRE Tunnel configuration:

A GRE tunnel is setup between R1 and R2. The tunnel interfaces will have IPv6
addresses and they belong to the same network. IPv6 traffic for remote sites is
manually forwarded over GRE tunnel using an IPv6 static route.
Tunnel configuration on R1
interface Tunnel 0
tunnel mode gre ip
ipv6 address 2001::1/64
tunnel source Loopback 0
tunnel destination 2.2.2.2
!
ipv6 route CAFE:2::/64 2001::2
!
Tunnel configuration on R2
Page 3 of 10
interface Tunnel 0
tunnel mode gre ip
ipv6 address 2001::2/64
tunnel source Loopback 0
tunnel destination 1.1.1.1
!
ipv6 route CAFE:1::/64 2001::1
!
When traffic is generated from R1 router's IPv6 domain towards R2 router's IPv6
network, ICMPv6 packets are encapsulated in a GRE packet (protocol= 0x2F or
decimal value 47) with packet's source IP address as R1's Loopback 0 interface and
destination IP address as R2's Loopback 0 interface. At R2 router, these GRE packets
are decapsulated and forwarded to the correct destination.
GRE Ping results

R1# ping
CAFE:2::1 source fa 0/0

Sending 5, 100-byte ICMP Echos to CAFE:2::1, timeout is 2 seconds:
Packet sent with a source address of CAFE:1::1
!!!!!
R1# debug ip packet detail
IP:
IP:
IP:
IP:
IP:
s=1.1.1.1
s=1.1.1.1
s=1.1.1.1
s=1.1.1.1
s=1.1.1.1
(Tunnel0),
(Tunnel0),
(Tunnel0),
(Tunnel0),
(Tunnel0),
d=2.2.2.2
d=2.2.2.2
d=2.2.2.2
d=2.2.2.2
d=2.2.2.2
(Serial0/0),
(Serial0/0),
(Serial0/0),
(Serial0/0),
(Serial0/0),
len
len
len
len
len
124,
124,
124,
124,
124,
sending,
sending,
sending,
sending,
sending,
proto=47
proto=47
proto=47
proto=47
proto=47
Page 4 of 10
IPSec over IPv6-in-IPv4 GRE tunnel:

Over this GRE tunnel, IPSec is configured using static crypto-map to encrypt the
traffic on the GRE tunnel. This essentially adds extra overhead since the GRE packet
is encapsulated by ESP (protocol value 50). All the traffic that travels over the GRE
tunnel get encrypted hence no access-list is configured to match interesting traffic.
Also, the peer address is set to the Loopback 0 interfaces of the routers since they
are used as the source IP addresses for the GRE tunnel.
IPSec configuration on R1
encryption des
hash md5
group 2
!
!
!
crypto ipsec profile PROFILE
!
interface tunnel 0
Page 5 of 10
tunnel protection ipsec profile PROFILE

!
IPSec configuration on R2
encryption des
hash md5
group 2
!
!
!
crypto ipsec profile PROFILE
!
interface tunnel 0
tunnel protection ipsec profile PROFILE
!
When traffic is generated from R1 router's IPv6 domain towards R2 router's IPv6
network, ICMPv6 packets are encapsulated in GRE packets, which are then
encapsulated in an ESP packet. R1 router also initiates an IKE negotiation with R2
router, meanwhile all packets are dropped.
The debugging on R2 router shows how it negotiates SA with R1 router. It shows that
when R2 router receives a packet from 1.1.1.1 peer, it checks to see if it has a preshared key. It initiates IKE Phase 1 during which it checks whether the policy sent by
R1 matches any of its policy and if it agrees to the policy. After successful IKE Phase
1, it initiates IKE Phase 2 during which it checks IPSec transform-set. After successful
transform-set negotiation IKE Phase 2 is completed after which communication is
possible.
"debug crypto isakmp" on R2

ISAKMP (0:0): received packet from 1.1.1.1 dport 500 sport 500 Global (N) NEW
SA
ISAKMP: Created a peer struct for 1.1.1.1, peer port 500
ISAKMP: New peer created peer = 0x64BB250C peer_handle = 0x80000004
ISAKMP: Locking peer struct 0x64BB250C, IKE refcount 1 for
crypto_isakmp_process_block
ISAKMP: local port 500, remote port 500 insert sa successfully sa = 64BB6094
ISAKMP:(0:0:N/A:0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0:0:N/A:0):Old State = IKE_READY New State = IKE_R_MM1
ISAKMP:(0:0:N/A:0): processing SA payload. message ID = 0
ISAKMP:(0:0:N/A:0): processing vendor id payload
ISAKMP:(0:0:N/A:0): vendor ID seems Unity/DPD but major 245 mismatch
ISAKMP (0:0): vendor ID is NAT-T v7
ISAKMP:(0:0:N/A:0): vendor ID is NAT-T v3
ISAKMP:(0:0:N/A:0): vendor ID is NAT-T v2
ISAKMP:(0:0:N/A:0):found peer pre-shared key matching 1.1.1.1
ISAKMP:(0:0:N/A:0): local preshared key found
ISAKMP : Scanning profiles for xauth ...
ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP:
encryption DES-CBC
ISAKMP:
hash MD5
ISAKMP:
default group 2
ISAKMP:
auth pre-share
ISAKMP:
Page 6 of 10
ISAKMP:
ISAKMP:(0:0:N/A:0):atts are acceptable. Next payload is 0
ISAKMP:(0:1:SW:1): processing vendor id payload
ISAKMP:(0:1:SW:1): vendor ID seems Unity/DPD but major 245 mismatch
ISAKMP (0:134217729): vendor ID is NAT-T v7
ISAKMP:(0:1:SW:1): vendor ID is NAT-T v3
ISAKMP:(0:1:SW:1): vendor ID is NAT-T v2
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM1 New State = IKE_R_MM1
ISAKMP:(0:1:SW:1): constructed NAT-T vendor-07 ID
ISAKMP:(0:1:SW:1): sending packet to 1.1.1.1 my_port 500 peer_port 500 (R)
MM_SA_SETUP
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
(R) MM_SA_SETUP
ISAKMP:(0:1:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0:1:SW:1): processing KE payload. message ID = 0
ISAKMP:(0:1:SW:1): processing NONCE payload. message ID =0
ISAKMP:(0:1:SW:1):found peer pre-shared key matching 1.1.1.1
ISAKMP:(0:1:SW:1):SKEYID state generated
ISAKMP:(0:1:SW:1): vendor ID is Unity
ISAKMP:(0:1:SW:1): vendor ID is DPD
ISAKMP:(0:1:SW:1): speaking to another IOS box!
MM_KEY_EXCH
(R) MM_KEY_EXCH
ISAKMP:(0:1:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0:1:SW:1): processing ID payload. message ID = 0
next-payload : 8
type
: 1
address
: 1.1.1.1
protocol
: 17
port
: 500
length
: 12
ISAKMP:(0:1:SW:1):: peer matches *none* of the profiles
ISAKMP:(0:1:SW:1): processing HASH payload. message ID = 0
ISAKMP:(0:1:SW:1): processing NOTIFY INITIAL_CONTACT protocol 1
spi 0, message ID = 0, sa = 64BB6094
ISAKMP:(0:1:SW:1):SA authentication status:authenticated
ISAKMP:(0:1:SW:1): Process initial contact,bring down existing phase 1 and 2
SA's with local 2.2.2.2 remote 1.1.1.1 remote port 500
ISAKMP:(0:1:SW:1):SA authentication status: authenticated
ISAKMP:(0:1:SW:1):SA has been authenticated with 1.1.1.1
ISAKMP: Trying to insert a peer 2.2.2.2/1.1.1.1/500/, and inserted
successfully 64BB250C.
ISAKMP:(0:1:SW:1):SA is doing pre-shared key authentication using id type
Page 7 of 10
ID_IPV4_ADDR
next-payload : 8
type
: 1
address
: 2.2.2.2
protocol
: 17
port
: 500
length
: 12
ISAKMP:(0:1:SW:1):Total payload length: 12
MM_KEY_EXCH
ISAKMP:(0:1:SW:1):Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE
ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(0:1:SW:1):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
(R) QM_IDLE
ISAKMP: set new node 1046004050 to QM_IDLE
ISAKMP:(0:1:SW:1): processing HASH payload. message ID = 1046004050
ISAKMP:(0:1:SW:1): processing SA payload. message ID = 1046004050
ISAKMP:(0:1:SW:1):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_DES
ISAKMP:
attributes in transform:
ISAKMP:
encaps is 1 (Tunnel)
ISAKMP:
SA life type in seconds
ISAKMP:
SA life duration (basic) of 3600
ISAKMP:
SA life type in kilobytes
ISAKMP:
SA life duration (VPI) of 0x0 0x46 0x50 0x0
ISAKMP:
authenticator is HMAC-MD5
ISAKMP:(0:1:SW:1):atts are acceptable.
ISAKMP:(0:1:SW:1): processing NONCE payload. message ID =1046004050
ISAKMP:(0:1:SW:1): asking for 1 spis from ipsec
ISAKMP:(0:1:SW:1):Node 1046004050, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
ISAKMP:(0:1:SW:1):Old State = IKE_QM_READY New State = IKE_QM_SPI_STARVE
ISAKMP: received ke message (2/1)
ISAKMP: Locking peer struct 0x64BB250C, IPSEC refcount 1 for for stuff_ke
ISAKMP:(0:1:SW:1): Creating IPSec SAs
inbound SA from 1.1.1.1 to 2.2.2.2 (f/i) 0/ 0
(proxy 1.1.1.1 to 2.2.2.2)
has spi 0x4F11F20E and conn_id 0 and flags 2
has client flags 0x0
outbound SA from 2.2.2.2 to 1.1.1.1 (f/i) 0/0
(proxy 2.2.2.2 to 1.1.1.1)
has client flags 0x0
QM_IDLE
ISAKMP:(0:1:SW:1):Node 1046004050, Input = IKE_MESG_FROM_IPSEC, IKE_SPI_REPLY
ISAKMP:(0:1:SW:1):Old State = IKE_QM_SPI_STARVE New State = IKE_QM_R_QM2
ISAKMP: Locking peer struct 0x64BB250C, IPSEC refcount 2 for from
create_transforms
ISAKMP: Unlocking IPSEC struct 0x64BB250C from create_transforms, count 1
(R) QM_IDLE
ISAKMP:(0:1:SW:1):deleting node 1046004050 error FALSE reason "QM done
(await)"
ISAKMP:(0:1:SW:1):Node 1046004050, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
ISAKMP:(0:1:SW:1):Old State = IKE_QM_R_QM2 New State = IKE_QM_PHASE2_COMPLETE
The show crypto isakmp peer [detail] command shows peer description.
Page 8 of 10
show crypto isakmp peers

R1# show crypto isakmp peers
Peer: 2.2.2.2 Port: 500 Local: 1.1.1.1
Phase1 id: 2.2.2.2
The show crypto session detail command provides details on currently active
crypto sessions.
show crypto session detail

R1# show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 2.2.2.2 port 500 fvrf: (none) ivrf: (none)
Phase1_id: 2.2.2.2
Desc: (none)
IKE SA: local 1.1.1.1/500 remote 2.2.2.2/500 Active
Capabilities:(none) connid:1 lifetime:23:59:34
IPSEC FLOW: permit 47 host 1.1.1.1 host 2.2.2.2
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 9 drop 0 life (KB/Sec) 4586052/3575
Outbound: #pkts enc'ed 9 drop 11 life (KB/Sec) 4586052/3575
The show crypto isakmp sa and show crypto ipsec sa commands show IKE Phase
1 and Phase 2 SA respectively.
IKE Phase 1 & 2 SA

dst
src
2.2.2.2
1.1.1.1
state
QM_IDLE
conn-id slot status

1
0 ACTIVE
R1# show crypto ipsec sa

interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 1.1.1.1
path mtu 1514, ip mtu 1514, ip mtu idb Loopback0
current outbound spi: 0x4F11F20E(1326576142)
inbound esp sas:
spi: 0x3861DD57(945937751)
conn id: 2001, flow_id: SW:1, crypto map: Tunnel0-head-0
Page 9 of 10
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x4F11F20E(1326576142)
conn id: 2002, flow_id: SW:2, crypto map: Tunnel0-head-0
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
The following output shows R1 sending ESP encapsulated packets (protocol 50).
debug ip packet detail

IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB
IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), g=10.1.1.2,len 176, forward,
proto=50
IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 124, rcvd 4, proto=47
proto=50
proto=50
proto=50
proto=50
Page 10 of 10
DMVPN with dual ISPs - Knowledge Base
Knowledge Base
Page 1 of 8
Search this site
Home
BGP
Data Center
GPON
DMVPN with dual ISPs

This article demonstrates DMVPN with 2 ISPs where the Hub has dual ISP connections. Also,
each Spoke router is connected to a separate ISP.
Hadoop
IP Multicast
IPv6
IS-IS
Juniper-JUNOS
L2VPN
LAN
Link Aggregation
LTE Notes
MPLS
NAT
OAM
OSPF
PBB
Configuration
PPP
QoS
PE11, PE12, PE21 and PE22 routers have a very simple and similar VRF configuration. There is
Security
an eBGP connection between PE and CE routers. A sample configuration on PE11 follows.
Traffic Engineering
VPLS
VRF Configuration on PE11 router
VPN
Attachments
mpls label protocol ldp

mpls ldp router-id Loopback 0 force
!
ip vrf CUST
rd 1:1
route-target both 1:1
!
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
ip vrf forwarding CUST
ip address 172.11.1.2 255.255.255.0
!
router bgp 100
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source Loopback 0
!
address-family vpnv4
neighbor 2.2.2.2 activate
exit-address-family
!
address-family ipv4 vrf CUST
redistribute connected
exit-address-family
!
PE100 and PE200 routers act as Route-Reflectors (RR) for their respective ASes. To exchange
VPNv4 routes, they run MP-eBGP connection across the two physical connections- one
preferred over the other achieved by setting higher local-preference value for prefixes learnt
via one connection.
https://sites.google.com/site/amitsciscozone/home/ipsec/dmvpn-with-dual-isps
4/08/2014
Page 2 of 8
PE100 Configuration
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
router ospf 1
passive-interface FastEthernet1/0
network 10.100.1.0 0.0.0.255 area 0
network 10.100.2.0 0.0.0.255 area 0
!
router bgp 100
no bgp route-target default filter
! Accept all VPNv4 routes
! PE11 router
! PE12 router
neighbor 10.100.1.2 send-label
! eBGP connection with PE200 router.
The "send-label" keyword allows the router to send label with BGP VPNv4 prefixes
!
neighbor 1.1.1.1 route-reflector-client
neighbor 1.1.1.1 next-hop-self
neighbor 10.100.1.2 route-map LOCAL_PREF in
! Set Local-Preference to 150 for all
incoming VPNv4 prefixes from this neighbor
!
route-map LOCAL_PREF permit 10
set local-preference 150
!
Configuration on PE200 router is very similar to PE100 router.
PE200 Configuration
ip address 5.5.5.5 255.255.255.255
ip ospf 2 area 0
!
router ospf 2
network 10.100.1.0 0.0.0.255 area 0
network 10.100.2.0 0.0.0.255 area 0
!
router bgp 200
no bgp route-target default filter
!
neighbor 10.100.1.1 route-map LOCAL_PREF in
! PE21 router
! PE22 router
! eBGP connection to PE100
4/08/2014
Page 3 of 8

!
route-map LOCAL_PREF permit 10
set local-preference 150
!
The following output shows the VPNv4 prefixes learnt by PE100 and PE200 routers. Note the
prefixes with higher local-preference value are preferred.
VPNv4 Prefixes on PE100 and PE200

PE100# show ip bgp vpnv4 all summary
BGP router identifier 2.2.2.2, local AS number 100
BGP table version is 13, main routing table version 13
4 network entries using 560 bytes of memory
6 path entries using 408 bytes of memory
4/2 BGP path/bestpath attribute entries using 496 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
1 BGP extended community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 3) using 32 bytes of memory
BGP using 1544 total bytes of memory
BGP activity 4/0 prefixes, 10/4 paths, scan interval 15 secs
Neighbor
1.1.1.1
3.3.3.3
10.100.1.2
10.100.2.2
V
4
4
4
4
AS MsgRcvd MsgSent
100
41
47
100
41
47
200
51
52
200
40
41
TblVer
13
13
13
13
InQ OutQ Up/Down State/PfxRcd

0
0 00:36:36
1
0
0 00:35:42
1
0
0 00:15:47
2
0
0 00:15:43
2
PE100# show ip bgp vpnv4 all

BGP table version is 13, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Route Distinguisher: 1:1
*>i172.11.1.0/24
1.1.1.1
* 172.12.1.0/24
10.100.2.2
*>
10.100.1.2
*>i172.22.1.0/24
3.3.3.3
* 172.33.1.0/24
10.100.2.2
*>
10.100.1.2
Metric LocPrf Weight Path

0
100
150
100
150
0
0
0
0
0
0
?
200
200
?
200
200
?
?
?
?
PE200# show ip bgp vpnv4 all

BGP table version is 13, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Route Distinguisher: 1:1
* 172.11.1.0/24
10.100.2.1
*>
10.100.1.1
*>i172.12.1.0/24
4.4.4.4
* 172.22.1.0/24
10.100.2.1
*>
10.100.1.1
*>i172.33.1.0/24
6.6.6.6
Metric LocPrf Weight Path
150
100
150
100
0
0
0
0
0
0
100
100
?
100
100
?
?
?
?
?
DMVPN Hub and Spoke Configuration

Since the Hub router has 2 connections to the ISP, two tunnel interfaces are created on each
Hub and Spoke routers. However, only one tunnel is operational at any time.
DMVPN Hub Configuration

encryption 3des
4/08/2014
Page 4 of 8
hash md5
group 2
!
crypto isakmp key 0 cisco address 0.0.0.0 0.0.0.0
!
mode transport
!
crypto ipsec profile DMVPN
!
interface Tunnel10
! Primary Tunnel
ip address 192.168.100.1 255.255.255.0
no ip next-hop-self eigrp 1020
ip nhrp map multicast dynamic
ip nhrp network-id 123
no ip split-horizon eigrp 1020
delay 5
tunnel source Serial1/0
tunnel mode gre multipoint
tunnel key 123
tunnel protection ipsec profile DMVPN shared
!
interface Tunnel20
! Backup Tunnel
ip address 192.168.200.1 255.255.255.0
delay 10
tunnel key 456
!
router eigrp 1020
no auto-summary
network 192.168.0.0
network 192.168.100.0
network 192.168.200.0
!
router bgp 65001
neighbor 172.11.1.2 filter-list 10 out
neighbor 172.12.1.2 filter-list 10 out
!
ip as-path access-list 10 permit ^$
! Allows only local routes to be advertised
!
Now, since the Spoke routers have a single connection to the ISP, they share the same
interface for both tunnels.
DMVPN Configuration on Spoke1 router

encr 3des
hash md5
group 2
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
mode transport
!
!
interface Tunnel10
ip address 192.168.100.2 255.255.255.0
ip nhrp map 192.168.100.1 172.11.1.1
ip nhrp map multicast 172.11.1.1
ip nhrp nhs 192.168.100.1
4/08/2014
Page 5 of 8
delay 5
tunnel key 123
!
interface Tunnel20
ip address 192.168.200.2 255.255.255.0
ip nhrp map 192.168.200.1 172.12.1.1
ip nhrp nhs 192.168.200.1
delay 10
tunnel key 456
!
router bgp 65002
!
DMVPN Configuration on Spoke2 router

encryption 3des
hash md5
group 2
!
mode transport
!
!
interface Tunnel10
ip address 192.168.100.3 255.255.255.0
ip nhrp map 192.168.100.1 172.11.1.1
ip nhrp nhs 192.168.100.1
delay 5
tunnel key 123
!
interface Tunnel20
ip address 192.168.200.3 255.255.255.0
ip nhrp map 192.168.200.1 172.12.1.1
ip nhrp nhs 192.168.200.1
delay 10
tunnel key 456
!
router bgp 65003
!
The major issue with this setup is that if the primary connection to ISP at Hub site goes down,
the tunnel interface (tunnel 10) goes down as well. EIGRP adjacency with Spoke routers fall.
However, the Spoke routers still have primary tunnel interface as functional. Hence, a tracking
mechanism is required on Spoke routers to track the reachability of the source address of
primary tunnel interface. IP SLA with tracking can do the job. Further, this reachability
information can be used to administer the functionality of tunnel interfaces on Spoke routers.
For example, if primary tunnel interface goes down on Hub, the Spoke routers shut down their
primary tunnel interface and bring the secondary tunnel up. This can be done using
4/08/2014
Page 6 of 8
Embedded Event Manager EEM. Before any IP SLA configuration on Spoke routers, ip sla
responder command is required on the Hub router. The configuration is as below:
IP SLA on Hub
ip sla responder
!
IP SLA + Tracking + EEM on Spoke1 router

track 1 ip sla 1 reachability
delay down 180 up 180
!
ip sla 1
icmp-echo 172.11.1.1 source-interface Serial1/0
timeout 300
threshold 300
frequency 3
!
event manager applet UP_TUNNEL_10
event track 1 state up
action 1.0 cli command "enable"
action 1.1 cli command "config t"
action 1.2 cli command "interface Tunnel20"
action 1.3 cli command "shutdown"
action 1.5 cli command "no shutdown"
action 1.6 cli command "do clear crypto isakmp"
event manager applet SHUT_TUNNEL_10
event track 1 state down
!
IP SLA + Tracking + EEM on Spoke2 router

track 1 ip sla 1 reachability
delay down 180 up 180
!
ip sla 1
icmp-echo 172.12.1.1 source-interface Serial1/0
timeout 300
threshold 300
frequency 3
!
event manager applet UP_TUNNEL_10
event track 1 state up
event manager applet SHUT_TUNNEL_10
event track 1 state down
!
4/08/2014
Page 7 of 8
Verification
Since the primary tunnel interface is UP, all the Spoke routers register their NHRP mappings
with the Hub router over primary tunnel interface 10. Also, all internal prefixes are learnt over
primary tunnel as EIGRP adjacency is established over that interface.
Hub# show ip nhrp

192.168.100.2/32 via 192.168.100.2
Tunnel10 created 00:29:51, expire 01:30:28
Type: dynamic, Flags: unique registered
NBMA address: 172.22.1.1
192.168.100.3/32 via 192.168.100.3
Type: dynamic, Flags: unique registered used
Hub# show ip route eigrp
D
192.168.1.0/24 [90/25603840] via 192.168.100.2, 00:10:34, Tunnel10
D
192.168.2.0/24 [90/25603840] via 192.168.100.3, 00:10:34, Tunnel10
Spoke1# show ip route eigrp
D
192.168.0.0/24 [90/25603840] via 192.168.100.1, 00:14:19, Tunnel10
D
192.168.2.0/24 [90/25605120] via 192.168.100.3, 00:11:08, Tunnel10
D
192.168.0.0/24 [90/25603840] via 192.168.100.1, 00:11:34, Tunnel10
D
192.168.1.0/24 [90/25605120] via 192.168.100.2, 00:11:34, Tunnel10
When the source address of primary tunnel interface on the Hub router is
unreachable (data-link between Hub and PE11 is down), the tracking object discovers that
the Hub is not reachable over Tunnel 10. The Spoke routers shut down Tunnel 10 and bring up
Tunnel 20. The Hub router receives NHRP mapping over Tunnel 20. EIGRP adjacency is formed
over this interface and routes are exchanged.
Spoke1#
*Jul 15 15:42:45.734: %TRACKING-5-STATE: 1 ip sla 1 reachability Up->Down
*Jul 15 15:42:45.982: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is OFF
*Jul 15 15:42:46.434: %SYS-5-CONFIG_I: Configured from console by vty0
*Jul 15 15:42:47.898: %LINK-5-CHANGED: Interface Tunnel10, changed state to
administratively down
*Jul 15 15:42:48.186: %LINK-3-UPDOWN: Interface Tunnel20, changed state to up
*Jul 15 15:42:48.286: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
*Jul 15 15:42:48.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel10, changed
state to down
*Jul 15 15:42:49.194: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel20, changed
state to up
*Jul 15 15:42:52.614: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1020: Neighbor 192.168.200.1
(Tunnel20) is up: new adjacency
Spoke1# show track
Track 1
IP SLA 1 reachability
Reachability is Down
99 changes, last change 00:00:33
Delay up 180 secs, down 180 secs
Latest operation return code: Timeout
Tracked by:
EEM applet UP_TUNNEL_10
EEM applet SHUT_TUNNEL_10
Hub# show ip nhrp
192.168.200.2/32 via 192.168.200.2
192.168.200.3/32 via 192.168.200.3
4/08/2014
Page 8 of 8

During Spoke-to-Spoke traffic forwarding, dynamic tunnel is formed via Tunnel 20.
Dynamic Spoke-to-Spoke tunnel

Spoke1# ping 192.168.2.1 source fa 0/0
!!!!!
Spoke1# show ip nhrp
192.168.200.1/32 via 192.168.200.1
Tunnel20 created 00:04:41, never expire
Type: static, Flags: used
192.168.200.2/32 via 192.168.200.2
Type: dynamic, Flags: router unique local
(no-socket)
192.168.200.3/32 via 192.168.200.3
Type: dynamic, Flags: router
Comments
4/08/2014
Dual DMVPN - Knowledge Base
Knowledge Base
Page 1 of 19
Search this site
Home
BGP
Dual DMVPN
Data Center
DMVPN stands for Dynamic Multipoint Virtual Private Network. It is basically a concept
GPON
involving three different technologies- multipoint GRE (mGRE), Next-Hop Resolution
Hadoop
Protocol (NHRP) and IPSec.
IP Multicast
IPv6
Traditional site-to-site IPSec VPNs require individual (point-to-point GRE or IPSec) tunnels
between a pair of Hub and Branch routers. For all new branch routers, configurations need
IS-IS
to be added on the Branch router as well as the Hub router. Also, traffic between Branch
Juniper-JUNOS
routers go through the Hub router.
L2VPN
LAN
Link Aggregation
LTE Notes
MPLS
NAT
OAM
OSPF
PBB
Conversely, DMVPN uses mGRE tunnel which has multiple end-points and is treated as a
non-broadcast multi-access (NBMA) network. DMVPN has evolved into 3 phasesPhase 1: Hub and Spoke - mGRE at the Hub and p2p GRE at the Branch routers
Phase 2: Hub and Spoke with Spoke-to-spoke tunnels (mGRE at the Hub and Branch
routers)
Phase 3: Same as Phase 2 but now Spoke routers can also respond to NHRP Requests.
This article discusses Phase 2.
PPP
QoS
DMVPN Components
Security
Traffic Engineering
VPLS
VPN
Attachments
1. mGRE - Multipoint GRE

mGRE serves as a one-to-many interface for the creation of multiple hub-and-spoke
tunnels. The tunnel destination for an mGRE tunnel does not have to be configured. mGRE
tunnel is effectively NBMA medium like Frame-Relay. A mechanism like ARP is required to
map logical (tunnel) IP addresses to physical (NBMA) IP addresses. This is taken care by
NHRP.
All the Hub routers are configured with mGRE tunnel interface. If Hub-and-Spoke model is
to be deployed, the Branch routers are configured with p2p GRE tunnel interface only.
However, if Spoke-to-Spoke model is to be deployed, the Branch routers must be
configured with mGRE tunnel interface.
2. NHRP - Next-Hop Resolution Protocol

NHRP (RFC 2332) is a Layer-2 address resolution protocol like ARP and Frame-relay
Inverse-ARP. NHRP is used by a Branch router connected to NBMA network to determine
the IP address of the NBMA Next-Hop (physical address)- this could be the Hub router or
another Branch router.
All Branch routers register their physical (NBMA) IP addresses mapped to logical (tunnel)
IP addresses with the Next-Hop Server (NHS). The IP address of the NHS is preconfigured on the Branch routers. These Branch routers become Next-Hop Clients
(NHC). The NHS stores all registered mappings and replies to NHRP Requests from NHCs.
An NHS can be an NHC to another NHS and can forward NHRP Requests to its NHS if it
cannot find a registered mapping in its database.
NHRP facilitates in building mGRE tunnels. NHRP allows mGRE tunnel endpoints to
discover each other's physical IP address.
Sample Scenario - Dual DMVPN
https://sites.google.com/site/amitsciscozone/home/ipsec/dual-dmvpn
4/08/2014
Page 2 of 19
A dual DMVPN cloud topology with spoke-to-spoke model consists of two Hub routers,
each with mGRE tunnel interface(s) connecting all Branch routers. Each DMVPN cloud
represents a unique subnet. One DMVPN cloud is considered Primary- this is preferred by
all Branch routers to send traffic. The second DMVPN cloud is implemented to provide
resiliency to the Primary DMVPN cloud.
mGRE Tunnel and IP Addressing

Tunnel 11 is the Primary tunnel while Tunnel 22 is the Backup tunnel. The tunnel mode
gre multipoint command configures the tunnel as multipoint GRE tunnel. The tunnel
destination is not configured; destination endpoints (Branch routers) are dynamically
discovered.
All LAN subnets on all routers belong to 192.168.x.0/24 network. The Primary cloud
belongs to 10.1.0.0/24 subnet and the Backup cloud belongs to 10.2.0.0/24 subnet. The
WAN interfaces use public addresses.
Primary router
description WAN Interface
ip address 172.16.1.1 255.255.255.0
!
interface Fastethernet 0/0
description LAN Interface
ip address 192.168.0.1 255.255.255.0
!
interface Tunnel 11
ip address 10.0.1.1 255.255.255.0
tunnel source serial 0/0
tunnel key 123
!
Backup router
ip address 172.26.1.1 255.255.255.0
!
description LAN Interface
ip address 192.168.0.2 255.255.255.0
4/08/2014
Page 3 of 19
!
interface Tunnel 22
ip address 10.0.2.1 255.255.255.0
tunnel key 456
!
Branch1 router
ip address 172.36.1.1 255.255.255.0
!
ip address 192.168.1.1 255.255.255.0
!
interface Tunnel 11
ip address 10.0.1.2 255.255.255.0
tunnel key 123
!
interface Tunnel 22
ip address 10.0.2.2 255.255.255.0
tunnel key 456
!
Branch2 router
ip address 172.46.1.1 255.255.255.0
!
ip address 192.168.2.1 255.255.255.0
!
interface Tunnel 11
ip address 10.0.1.3 255.255.255.0
tunnel key 123
!
interface Tunnel 22
ip address 10.0.2.3 255.255.255.0
tunnel key 456
!
Branch3 router
ip address 172.56.1.1 255.255.255.0
!
ip address 192.168.3.1 255.255.255.0
!
interface Tunnel 11
ip address 10.0.1.4 255.255.255.0
tunnel key 123
!
interface Tunnel 22
4/08/2014
Page 4 of 19
ip address 10.0.2.4 255.255.255.0

tunnel key 456
!
NHRP Configuration
The most basic commands to implement NHRP are as follows1) ip nhrp map <tunnel-ip> <physical-ip> command creates a static binding between
a tunnel IP address and physical IP address. This command is usually configured on the
Branch routers (who act as NHRP Clients) to provide the information to Branch routers to
reach the tunnel address of the Hub.
2) ip nhrp map multicast <dynamic | static-ip> command specifies the destination(s)
that will receive multicast/broadcast traffic. Spokes map multicast to the physical IP
address of the Hub, and the Hub maps multicast packets to the dynamic mappings i.e. to
all NHRP Clients registered to the Hub (NHRP Server). This is important for routing
protocols to form adjacency and exchange routing updates.
3) ip nhrp nhs <server-ip> command specifies the NHRP Server to the Branch routers.
The "Server IP Address" is the tunnel IP address.
4) ip nhrp authentication <key> command is optional. The key is in plain-text and is
used to authenticate the NHRP Client. This must be same on all NHRP routers.
5) ip nhrp network-id <id> command identifies the logical network. This must be same
on all NHRP routers.
6) ip nhrp holdtime <seconds> command specifies the hold-time value in registration
requests. The NHS will keep the registration request cache for the hold-time period, and if
no updates are received, it will flush them out.
Primary router
interface Tunnel11
......
ip nhrp holdtime 60
!
Backup router
interface Tunnel22
.....
ip nhrp holdtime 60
!
The NHRP configuration on all Branch routers looks same.
All Branch routers

interface Tunnel11
....
ip nhrp map 10.0.1.1 172.16.1.1
Physical IP Addresses
ip nhrp nhs 10.0.1.1
! Statically mapping Primary Hub Tunnel IP and
! Pre-configured NHRP Server- Primary Hub

ip nhrp holdtime 60
4/08/2014
Page 5 of 19
!
interface Tunnel22
....
ip nhrp map 10.0.2.1 172.26.1.1
Physical IP Addresses
! Statically mapping Backup Hub Tunnel IP and

ip nhrp nhs 10.0.2.1
! Pre-configured NHRP Server- Backup Hub

ip nhrp holdtime 60
!
Routing Instances
We will use two separate instance of routing protocol on Hub and Branch routers- one for
WAN domain (OSPF) and another for VPN domain (EIGRP).
For EIGRP, we need to disable split-horizon on Hub mGRE tunnel interface to ensure
optimal forwarding. We also need to disable the default EIGRP behavior to overwrite the
next-hop as itself. And lastly, we also need to tweak the metric in EIGRP for tunnels to
prefer Primary over Backup.
Primary router
router ospf 1
! WAN domain
!
network 172.16.1.0 0.0.0.255 area 0
!
router eigrp 1
! VPN domain
!
no auto-summary
network 10.0.0.0
network 192.168.0.0
!
interface Tunnel11
....
! This command is not required in DMVPN Phase 1
delay 5
!
Backup router
router ospf 1
! WAN domain
!
network 172.26.1.0 0.0.0.255 area 0
!
router eigrp 1
! VPN domain
!
no auto-summary
network 10.0.0.0
network 192.168.0.0
!
interface Tunnel22
....
delay 10
! This command is not required in DMVPN Phase 1
Branch routers
4/08/2014
Page 6 of 19
Branch1 router:
router ospf 1
network 172.36.1.0 0.0.0.255 area 0
!
router eigrp 1
no auto-summary
network 10.0.0.0
network 192.168.1.0
!
interface Tunnel11
....
delay 5
!
interface Tunnel22
....
delay 10
!
Branch2 router:
router ospf 1
network 172.46.1.0 0.0.0.255 area 0
!
router eigrp 1
no auto-summary
network 10.0.0.0
network 192.168.2.0
!
interface Tunnel11
....
delay 5
!
interface Tunnel22
....
delay 10
!
Branch3 router:
router ospf 1
network 172.56.1.0 0.0.0.255 area 0
!
router eigrp 1
no auto-summary
network 10.0.0.0
network 192.168.3.0
!
interface Tunnel11
....
delay 5
!
interface Tunnel22
....
delay 10
!
All the Spoke routers try to register their logical IP address to NBMA IP address mapping
with the Hub. Each Spoke router has 2 tunnel interfaces to two different Hubs- Primary
and Backup. Hence all Spoke routers send Registration Request packets to both
Primary and Backup with its logical-to-NBMA address mapping. The following output
shows Spoke1 router registering with two Hubs. The Hubs respond with Registration Reply
packet to the Spoke routers.
NHRP Registration
Primary#
*Mar 1 09:55:23.589: NHRP: Receive Registration Request via Tunnel11 vrf 0, packet
size: 92
*Mar
*Mar
1 09:55:23.589: NHRP: netid_in = 123, to_us = 1

1 09:55:23.589: NHRP: Tu11: Creating dynamic multicast mapping
NBMA:
4/08/2014
Page 7 of 19
172.36.1.1
*Mar
*Mar
1 09:55:23.589: NHRP: Attempting to send packet via DEST 10.0.1.2

1 09:55:23.593: NHRP: Encapsulation succeeded. Tunnel IP addr 172.36.1.1
*Mar 1 09:55:23.593: NHRP: Send Registration Reply via Tunnel11 vrf 0, packet
size: 112
*Mar
*Mar
1 09:55:23.597:
src: 10.0.1.1, dst: 10.0.1.2
1 09:55:23.597: NHRP: 112 bytes out Tunnel11
Backup#
*Mar 1 09:54:59.585: NHRP: Receive Registration Request via Tunnel22 vrf 0, packet
size: 92
*Mar 1 09:54:59.585: NHRP: netid_in = 456, to_us = 1
*Mar 1 09:54:59.585: NHRP: Tu22: Creating dynamic multicast mapping
172.36.1.1
*Mar
*Mar
NBMA:

1 09:54:59.589: NHRP: Encapsulation succeeded. Tunnel IP addr 172.36.1.1
*Mar 1 09:54:59.593: NHRP: Send Registration Reply via Tunnel22 vrf 0, packet
size: 112
*Mar
*Mar
1 09:54:59.593:
src: 10.0.2.1, dst: 10.0.2.2
This registration on the mGRE interface on the Hub router to build a dynamic tunnel back
to the registering Branch/Spoke router without having to know the Branch tunnel
destination statically. NHRP tells mGRE interface where to tunnel a packet to reach a
certain address.
The NHRP cache can be viewed using show ip nhrp command. The Hubs learn the
mappings dynamically and the Spoke routers have only a single static mapping via each
tunnel interface in their NHRP cache.
NHRP Cache
Primary# show ip nhrp
10.0.1.2/32 via 10.0.1.2, Tunnel11 created 07:57:45, expire 00:00:58
10.0.1.1/32 via 10.0.1.1, Tunnel11 created 00:14:53, never expire
The unique flag indicates that the Registration Request message had unique flag enabled.
The NHS rejects all Registration Requests if the mapping in the message is already
present or not unique. The used flag indicates that the router uses this mapping to switch
IP packets.
All Branch routers learn about remote 192.168.x.0/24 networks via EIGRP over Tunnel 11
(Primary tunnel).
EIGRP routes
D
D
192.168.0.0/24 [90/284471296] via 10.0.1.1, 00:05:58, Tunnel11

192.168.2.0/24 [90/284472576] via 10.0.1.3, 00:05:53, Tunnel11
192.168.3.0/24 [90/284472576] via 10.0.1.4, 00:03:56, Tunnel11
4/08/2014
Page 8 of 19
192.168.0.0/24 [90/284471296] via 10.0.1.1, 00:25:18, Tunnel11
D
D
192.168.1.0/24 [90/284472576] via 10.0.1.2, 00:06:11, Tunnel11

192.168.3.0/24 [90/284472576] via 10.0.1.4, 00:04:15, Tunnel11

D
D
192.168.0.0/24 [90/284471296] via 10.0.1.1, 00:04:38, Tunnel11

192.168.1.0/24 [90/284472576] via 10.0.1.2, 00:04:38, Tunnel11
192.168.2.0/24 [90/284472576] via 10.0.1.3, 00:04:38, Tunnel11
However, the CEF adjacency for prefixes connected to remote Branch router over the
DMVPN cloud, are seen as invalid adjacency on the Branch3 routers. While the CEF
adjacency for the next-hop is valid punt adjacency which means that the packet cannot
be CEF-switched and need to be fast-switched or process-switched.
Spoke3# show ip cef 192.168.1.0

192.168.1.0/24, version 33, epoch 0
0 packets, 0 bytes
via 10.0.1.2, Tunnel11, 0 dependencies
next hop 10.0.1.2, Tunnel11
invalid adjacency
10.0.1.0/24, version 22, epoch 0, attached, connected
0 packets, 0 bytes
via Tunnel11, 0 dependencies
valid punt adjacency
When Branch3 router tries to send packet to 192.168.1.0/24, it finds out that it has a
punt adjacency for its next-hop of 10.0.1.2. Then Branch3 router attempts to send NHRP
Resolution Request directly to its next-hop 10.0.1.2 i.e. Spoke1 router, but it fails as the
NBMA address of Branch1 router is unknown. However, the Branch3 router continues to
send packets via the NHS.
*Mar
1 08:36:58.865: NHRP: MACADDR: if_in null netid-in 0 if_out Tunnel11 netid-
out 123
*Mar 1 08:36:58.865: NHRP: Checking for delayed event 0.0.0.0/10.0.1.2 on list
(Tunnel11).
*Mar 1 08:36:58.869: NHRP: No node found.
*Mar
*Mar
1 08:36:58.869: NHRP: Sending packet to NHS 10.0.1.1 on Tunnel11

1 08:36:58.881: NHRP: Checking for delayed event 0.0.0.0/10.0.1.2 on list
(Tunnel11).
*Mar
*Mar

1 08:36:58.885: NHRP: Send Resolution Request via Tunnel11 vrf 0, packet
size: 72
*Mar 1 08:36:58.885:
src: 10.0.1.4, dst: 10.0.1.2
*Mar
*Mar
1 08:36:58.885:
1 08:36:58.889:
(F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

shtl: 4(NSAP), sstl: 0(NSAP)
*Mar
*Mar
1 08:36:58.889:
1 08:36:58.889:
(M) flags: "router auth src-stable nat ", reqid: 129

src NBMA: 172.56.1.1
*Mar
*Mar
1 08:36:58.889:
1 08:36:58.893:
src protocol: 10.0.1.4, dst protocol: 10.0.1.2

(C-1) code: no error(0)
*Mar
*Mar
1 08:36:58.893:
1 08:36:58.893:
prefix: 0, mtu: 1514, hd_time: 60

addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0,
pref: 0
*Mar 1 08:36:58.893: NHRP: Encapsulation failed for destination 10.0.1.2 out
Tunnel11
*Mar 1 08:36:58.897: NHRP: Attempting to send packet via NHS 10.0.1.1
*Mar
1 08:36:58.897: NHRP: Encapsulation succeeded.
Tunnel IP addr 172.16.1.1
An NHRP packet contains 3 parts1. Fixed Part (F): It specifies the address-family (afn), protocol type (IP) as well as
subnetwork type and length.
2. Mandatory Part (M): It specifies the flags and the request ID (reqid). It also includes
the source NBMA address and source/destination protocol IP addresses.
4/08/2014
Page 9 of 19
3. Client Information Element (CIE C-1) part: It contains information about networks
connected to requesting/responding routers.
The Spoke3 router then tries to send the Resolution Request to NHS. It contains the
source NBMA address of Spoke3 router (itself) and tunnel source address of Spoke3 router
and tunnel destination address of Spoke1 router.
*Mar 1 08:36:58.897: NHRP: Send Resolution Request via Tunnel11 vrf 0, packet
size: 72
*Mar
*Mar
1 08:36:58.901:
1 08:36:58.901:
src: 10.0.1.4, dst: 10.0.1.1

*Mar
*Mar
1 08:36:58.901:
1 08:36:58.901:

*Mar
*Mar
1 08:36:58.905:
1 08:36:58.905:
*Mar
*Mar
1 08:36:58.905:
1 08:36:58.905:
*Mar 1 08:36:58.909:
pref: 0
*Mar
*Mar
src NBMA: 172.56.1.1


1 08:36:59.125: NHRP: MACADDR: if_in null netid-in 0 if_out Tunnel11 netid-
out 123
*Mar 1 08:36:59.125: NHRP: Checking for delayed event 0.0.0.0/10.0.1.2 on list
(Tunnel11).
*Mar
1 08:36:59.129: NHRP: Sending packet to NHS 10.0.1.1 on Tunnel11
The request arrives at NHS. The NHS has a mapping for 10.0.1.2 in its NHRP cache. It
responds with a Resolution Reply message with correct mapping in the Mandatory part.
*Mar 1 08:36:59.133: NHRP: Receive Resolution Request via Tunnel11 vrf 0, packet
size: 92
*Mar
*Mar
1 08:36:59.137:
1 08:36:59.137:

*Mar
*Mar
1 08:36:59.137:
1 08:36:59.137:

src NBMA: 172.36.1.1
*Mar
*Mar
1 08:36:59.137:
1 08:36:59.141:

*Mar
*Mar
1 08:36:59.141:
1 08:36:59.141:

pref: 0
*Mar 1 08:36:59.141: NHRP: netid_in = 123, to_us = 1
The Spoke3 router receives the Resolution Reply packet and hence its CEF adjacency is
now completed for 10.0.1.2. It now attempts to send the packet directly to Spoke1 router
rather than through Hub router.
*Mar 1 08:36:59.285: NHRP: Receive Resolution Reply via Tunnel11 vrf 0, packet
size: 120
*Mar
*Mar
1 08:36:59.289:
1 08:36:59.289:
*Mar 1 08:36:59.289:
reqid: 129
*Mar
*Mar
1 08:36:59.289:
1 08:36:59.293:
*Mar
*Mar
1 08:36:59.293:
1 08:36:59.293:

(M) flags: "router auth dst-stable unique src-stable nat ",
src NBMA: 172.56.1.1
*Mar 1 08:36:59.293:
pref: 0
*Mar
*Mar
1 08:36:59.297:
1 08:36:59.297:
client NBMA: 172.36.1.1

client protocol: 10.0.1.2
*Mar
*Mar

1 08:36:59.297: NHRP: Checking for delayed event 0.0.0.0/10.0.1.2 on list
(Tunnel11).
*Mar 1 08:36:59.301: NHRP: No need to delay processing of resolution event nbma
src:172.56.1.1 nbma dst:172.36.1.1
4/08/2014
Page 10 of 19
The show ip cef command now shows that the CEF adjacency is completed. Also, the
show ip nhrp command shows a dynamically learnt NHRP entry.

192.168.1.0/24, version 65, epoch 0
0 packets, 0 bytes
valid adjacency
(no-socket)
The router flag means that the mapping is either for the remote router or for a network
behind the remote router.
Backup Hub into picture

When the Primary Hub is not available, all Spoke routers learn about remote prefixes
through Tunnel 22 rather than Tunnel 11.
Prefixes learnt through Tunnel 22

Spoke1# show ip route eigrp 1
D
D
192.168.0.0/24 [90/284472576] via 10.0.2.1, 00:06:04, Tunnel22

192.168.2.0/24 [90/284475136] via 10.0.2.3, 00:00:26, Tunnel22
192.168.3.0/24 [90/284475136] via 10.0.2.4, 00:06:02, Tunnel22

D
192.168.0.0/24 [90/284472576] via 10.0.2.1, 00:00:43, Tunnel22
D
D
192.168.1.0/24 [90/284475136] via 10.0.2.2, 00:00:43, Tunnel22

192.168.3.0/24 [90/284475136] via 10.0.2.4, 00:00:43, Tunnel22

D
D
192.168.0.0/24 [90/284472576] via 10.0.2.1, 00:06:35, Tunnel22

192.168.1.0/24 [90/284475136] via 10.0.2.2, 00:06:32, Tunnel22
192.168.2.0/24 [90/284475136] via 10.0.2.3, 00:00:57, Tunnel22

192.168.1.0/24, version 72, epoch 0
0 packets, 0 bytes
invalid adjacency
Once again when Spoke3 router attempts to send packet to 192.168.1.0/24 prefix
connected to Spoke1 router, first it tries to send the packet directly to Spoke1 router but
since the CEF adjacency is not complete, the packets are forwarded to the Hub. However,
the Spoke3 router also sends a Resolution Request packet for Backup NHS via Tunnel 22.
Backup#
*Mar 1 18:11:13.611: NHRP: Receive Resolution Request via Tunnel22 vrf 0, packet
size: 72
4/08/2014
Page 11 of 19
*Mar
1 18:11:13.615:
*Mar
*Mar
1 18:11:13.615:
1 18:11:13.615:

*Mar
*Mar
1 18:11:13.615:
1 18:11:13.615:
*Mar
*Mar
1 18:11:13.619:
1 18:11:13.619:
src NBMA: 172.56.1.1

*Mar 1 18:11:13.619:
pref: 0
The Backup NHS receives the Resolution Reply packet. It looks up its NHRP cache and
finds a valid mapping. It responds with a Resolution Reply packet back to the Spoke3
router with correct mapping.
*Mar
1 18:11:13.623: NHRP: Forwarding Resolution Request via Tunnel22 vrf 0,
packet size: 92
*Mar 1 18:11:13.627:
src: 10.0.2.1, dst: 10.0.2.2
*Mar
*Mar
1 18:11:13.627:
1 18:11:13.627:

*Mar
*Mar
1 18:11:13.627:
1 18:11:13.631:

src NBMA: 172.56.1.1
*Mar
*Mar
1 18:11:13.631:
1 18:11:13.631:

*Mar
*Mar
1 18:11:13.631:
1 18:11:13.631:

pref: 0
The show ip nhrp command confirms the dynamically learnt mapping on Spoke3 router.
show ip nhrp
(no-socket)
Adding IPSec
For simplicity, we will use pre-shared keys for authentication for IKE Phase 1 in IPSec.
For most scalability, X.509 digital certificates and PKI must be used. For IKE Phase 2, we
use IPSec Profiles with tunnel interfaces. This can be applied to tunnel interfaces using
tunnel protection ipsec profile <profile-name> [shared] command. The shared
keyword is used on Branch routers as the two mGRE tunnel interfaces use the same
tunnel source (Serial 0/0). All the traffic passing through the tunnel will be protected by
IPSec.
Since mGRE adds new IP header, the transport mode is used with IPSec. The IPSec
configuration on all routers is as follows:
IPSec Configuration on Primary router

encr 3des
hash md5
4/08/2014
Page 12 of 19
group 2
!
mode transport
!
!
interface Tunnel 11
....
tunnel protection ipsec profile DMVPN
IPSec Configuration on Backup router

encr 3des
hash md5
group 2
!
mode transport
!
!
interface Tunnel 22
....
tunnel protection ipsec profile DMVPN
All Branch routers share the same IPSec configuration.
IPSec Configuration on Branch routers

encr 3des
hash md5
group 2
!
mode transport
!
!
interface Tunnel 11
....
!
interface Tunnel 22
....
Since all Branch routers send mGRE encapsulated EIGRP Hello multicast packets towards
the Hub routers over both tunnels, ISAKMP negotiations start between Branch routers and
Hub routers.
Both, Branch and Hub routers will create IPSec SA for GRE protocol (value = 47).
Spoke3# show crypto isakmp sa

4/08/2014
Page 13 of 19
dst
src
state
172.26.1.1
172.16.1.1
172.56.1.1
172.56.1.1
QM_IDLE
QM_IDLE
conn-id slot status

1002
1001
0 ACTIVE
0 ACTIVE
Spoke3# show crypto ipsec sa

interface: Tunnel11
Crypto map tag: DMVPN-head-1, local addr 172.56.1.1
current outbound spi: 0x6D677A69(1835498089)
inbound esp sas:
spi: 0x171FDA10(387963408)
in use settings ={Transport, }
conn id: 3, flow_id: SW:3, crypto map: DMVPN-head-1
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x6D677A69(1835498089)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
current outbound spi: 0xB4509812(3025180690)
inbound esp sas:
4/08/2014
Page 14 of 19
spi: 0xEF9D4CCB(4020063435)
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB4509812(3025180690)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
interface: Tunnel22
inbound esp sas:
spi: 0x171FDA10(387963408)
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x6D677A69(1835498089)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
4/08/2014
Page 15 of 19

inbound esp sas:
spi: 0xEF9D4CCB(4020063435)
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB4509812(3025180690)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
When Branch3 router sends packets to 192.168.1.0/24 connected to Branch1 router,

Branch3 router tries to resolve the next-hop IP address using NHRP Resolution Request
packets. The NHS provides the correct mapping- NBMA address 172.36.1.1 and tunnel IP
address 10.0.1.2. Now Branch3 router tries to send the packets directly to Branch1 router.
This triggers ISAKMP negotiation with NBMA address 172.36.1.1. This results in an IPSec
SA corresponding to IP address pair 172.56.1.1,172.36.1.1 and GRE protocol (47).

dst
src
state
172.56.1.1
172.26.1.1
172.36.1.1
172.56.1.1
QM_IDLE
QM_IDLE
1003
1002
0 ACTIVE
0 ACTIVE
172.36.1.1
172.16.1.1
172.56.1.1
172.56.1.1
QM_IDLE
QM_IDLE
1004
1001
0 ACTIVE
0 ACTIVE
conn-id slot status

interface: Tunnel11
4/08/2014
Page 16 of 19

inbound esp sas:
spi: 0x171FDA10(387963408)
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x6D677A69(1835498089)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
current outbound spi: 0x665BD18E(1717293454)
inbound esp sas:
spi: 0xDED5217E(3738509694)
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x665BD18E(1717293454)
4/08/2014
Page 17 of 19

IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
inbound esp sas:
spi: 0xEF9D4CCB(4020063435)
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB4509812(3025180690)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
interface: Tunnel22
4/08/2014
Page 18 of 19

inbound esp sas:
spi: 0x171FDA10(387963408)
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x6D677A69(1835498089)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
current outbound spi: 0x665BD18E(1717293454)
inbound esp sas:
spi: 0xDED5217E(3738509694)
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x665BD18E(1717293454)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
4/08/2014
Page 19 of 19

inbound esp sas:
spi: 0xEF9D4CCB(4020063435)
IV size: 8 bytes
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB4509812(3025180690)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
Comments
4/08/2014
DMVPN: Dual Tier Headend Architecture - Knowledge Base
Knowledge Base
Page 1 of 6
Search this site
Home
BGP
DMVPN: Dual Tier Headend Architecture
Data Center
The Dual Tier architecture splits the mGRE and crypto functions to two different routers (or
GPON
chasses). DMVPN usually involves 3 different control planes- Routing Control plane (NHRP), GRE
Hadoop
Control plane (mGRE) and IPSec Control plane (Dynamic Crypto map). The routing and GRE control
IP Multicast
planes are on one router and IPSec control plane is on another.
IPv6
IS-IS
Sample Scenario
Juniper-JUNOS
L2VPN
LAN
Link Aggregation
LTE Notes
This scenario deals with Dual Tier Headend architecture. The Crypto functions are handled by Crypto
Headend routers. There are two possible options to implement IPSec in the sample scenario- a)
Dynamic Crypto maps on the Crypto Headend routers and Static Crypto maps on Spoke routers,
and, b) implementing a GET VPN style architecture over DMVPN networks.
MPLS
The issue with option-(a) is that if Static Crypto maps pointing to HSRP Virtual IP address at the
NAT
Headend site is applied to Spoke routers, the whole advantage of dynamic Spoke-to-Spoke tunnel of
OAM
DMVPN is lost. Hence, option-(b) is used which is more scalable and an appropriate choice. The
OSPF
PBB
PPP
Crypto Headend routers and Spoke routers become the group members of the Key Server. Note that
the mGRE Headend router does not need to be a group member of the Key Server as it wont
perform any IPSec functions.
QoS
Security
Traffic Engineering
VPLS
VPN
Attachments
Key Server (KS) Configuration

The Key Server is responsible to distribute IPSec policies to its group members. The configuration of
KS is as below:
KS Configuration
ip address 1.1.1.1 255.255.255.255
!
crypto key generate rsa general-keys label GDOI_KEYS modulus 1024 exportable
!
!
crypto isakmp key 0 cisco address 3.3.3.3
! Crypto Headend-1 router

! Crypto Headend-2 router
! Spoke1 router

! Spoke2 router
!
!
crypto ipsec profile GDOI_PROFILE
!
crypto gdoi group GDOI_GROUP
https://sites.google.com/site/amitsciscozone/home/ipsec/dmvpn-dual-tier-headend-arch... 4/08/2014
Page 2 of 6
identity number 123

server local
rekey retransmit 60 number 2
rekey transport unicast
rekey authentication mypubkey rsa GDOI_KEYS
sa ipsec 1
profile GDOI_PROFILE
match address ipv4 ACL
replay time window-size 5
!
address ipv4 1.1.1.1
!
!
permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
!
mGRE Configuration
The mGRE Headend router houses the Routing and GRE Control plane. The configuration is as
below:
mGRE Headend Router Configuration

ip address 172.17.1.1 255.255.255.0
!
ip address 10.1.1.4 255.255.255.0
!
interface Tunnel 10
ip address 172.168.100.1 255.255.255.0
tunnel source Serial 0/0
tunnel key 123
!
router eigrp 10
no auto-summary
network 172.168.100.0
network 10.1.1.0
redistribute static
!
ip route 192.168.1.0 255.255.255.0 10.1.1.1
! Forwards all traffic for 192.168.1.0/24
network to HSRP Virtual IP Address 10.1.1.1

!
The configuration on Spoke routers is as below:
mGRE Configuration on Spoke1 Router

ip address 11.11.11.11 255.255.255.255
!
interface Tunnel 10
ip address 172.168.100.2 255.255.255.0
tunnel key 123
ip nhrp nhs 172.168.100.1
ip nhrp map 172.168.100.1 172.17.1.1
!
router eigrp 10
no auto-summary
network 11.0.0.0
network 172.168.100.0
network 192.168.2.0
!
Page 3 of 6
mGRE Configuration on Spoke2 router

ip address 12.12.12.12 255.255.255.255
!
interface Tunnel 10
ip address 172.168.100.3 255.255.255.0
tunnel key 123
ip nhrp nhs 172.168.100.1
ip nhrp map 172.168.100.1 172.17.1.1
!
router eigrp 10
no auto-summary
network 12.0.0.0
network 172.168.100.0
network 192.168.3.0
!
IPSec Configuration
The Crypto Headend routers houses the crypto control plane. Also, at the Hub site, HSRP is
implemented between the two crypto Headend routers to provide high-availability.
IPSec Configuration on Crypto Headend-1 router

!
!
crypto gdoi group GDOI_GM
identity number 123
server address ipv4 1.1.1.1
!
crypto map CRYPTO
set group GDOI_GM
!
ip address 10.1.1.2 255.255.255.0
standby 1 priority 105
standby 1 preempt
standby 1 timers msec 15 msec 50
standby 1 track fastethernet 0/1
crypto map CRYPTO
!
router eigrp 10
no auto-summary
network 10.1.1.0
network 192.168.1.0
!
IPSec Configuration on Crypto Headend-2 router

!
!
identity number 123
!
crypto map CRYPTO 10 gdoi
set group GDOI_GM
!
ip address 10.1.1.3 255.255.255.0
standby 1 timers msec 15 msec 50
Page 4 of 6
standby 1 track fastethernet 0/1

standby 1 preempt
crypto map CRYPTO
!
router eigrp 10
no auto-summary
network 10.1.1.0
network 192.168.1.0
!
The crypto-map is applied to the Tunnel interfaces as 10.1.1.0/24 and 192.168.1.0/24 networks are
reachable through the tunnel. The active HSRP router at the Headend will respond to the Spoke
routers.
IPSec Configuration on Spoke1 router

!
!
identity number 123
!
set group GDOI_GM
!
interface Tunnel 10
ip address 172.168.100.2 255.255.255.0
....
crypto map CRYPTO
!
IPSec Configuration on Spoke2 router

!
!
identity number 123
!
set group GDOI_GM
!
interface Tunnel 10
ip address 172.168.100.3 255.255.255.0
....
crypto map CRYPTO
!
Verification
All the group members register with the Key Server and download IKE Policies after successful IKE
Phase 1. The below output shows the IKE Policy downloaded by Spoke1 router.
IKE Policy downloaded by Spoke1 router

Spoke1# show crypto gdoi
GROUP INFORMATION
Group Name
Group Identity
: GDOI_GM
: 123
Rekeys received
IPSec SA Direction
: 0
: Both
Active Group Server

Group Server list
: 1.1.1.1
: 1.1.1.1
GM Reregisters in
: 3357 secs
Rekey Received
Page 5 of 6
: never
Rekeys received
Cumulative
After registration
Rekey Acks sent
: 0
: 0
: 0
ACL Downloaded From KS 1.1.1.1:

access-list
permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
KEK POLICY:
Rekey Transport Type
: Unicast
Lifetime (secs)
Encrypt Algorithm
Key Size
: 86399
: 3DES
: 192
Sig Hash Algorithm

Sig Key Length (bits)
: HMAC_AUTH_SHA
: 1024
TEK POLICY:
Tunnel10:
IPsec SA:
sa direction:inbound
spi: 0x6ECBE7BC(1858856892)
transform: esp-3des esp-md5-hmac
sa timing:remaining key lifetime (sec): (3475)
Anti-Replay(Time Based) : 5 sec interval
IPsec SA:
sa direction:outbound
spi: 0x6ECBE7BC(1858856892)
The Crypto Headend-1 router becomes the active HSRP router due to its higher priority (105 as
compared to 100 of Crypto Headend-2 router).
Active HSRP router

Crypto_Headend_1# show standby
FastEthernet0/1 - Group 1
State is Active
2 state changes, last state change 00:15:03
Virtual IP address is 10.1.1.1
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.488 secs
Preemption enabled
Active router is local
Standby router is 10.1.1.3, priority 100 (expires in 7.224 sec)
Priority 105 (configured 105)
Group name is "CRYPTO_FOR_HSRP" (cfgd)
The Spoke routers also register to mGRE Headend router using NHRP and hence the router learns
about the Tunnel IP Address to NBMA IP address mapping dynamically.
When Spoke1 router sends ICMP traffic to 192.168.1.0/24 network sourced from 192.168.2.0/24,
and half-way, if Crypto Headend-1 router dies, Crypto Headend-2 router becomes the active HSRP
router, and since mGRE router is configured to forward the traffic to 10.1.1.1, Crypto Headend-2
router will accept the encrypted traffic, decrypt it and forward to proper destination.
Failover test
Crypto_Headend_2# show standby
FastEthernet0/1 - Group 1
State is Active
7 state changes, last state change 00:00:46
Virtual IP address is 10.1.1.1
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 15 msec, hold time 50 msec
Next hello sent in 0.003 secs
Preemption enabled
Page 6 of 6
Active router is local

Standby router is unknown
Priority 100 (default 100)
Group name is "CRYPTO_FOR_HSRP" (cfgd)
Spoke1# ping 192.168.1.3 source fa 0/0 repeat 500

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!U.......!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Comments
GET VPN - Knowledge Base
Knowledge Base
Page 1 of 10
Search this site
Home
BGP
Data Center
GPON
Hadoop
IP Multicast
IPv6
IS-IS
GET VPN
GET (Group Encrypted Transport) VPN is a VPN technology which introduces the concept to eliminate point-topoint tunnels (site-to-site VPN) and associated overlay routing (DMVPN) since it relies on WAN routing. It enables
any-to-any VPN connectivity using a group IPSec security paradigm.
In addition to IPSec, the following are the building blocks for GET VPN solution:
1. Group Domain Of Interpretation (GDOI)
Juniper-JUNOS
L2VPN
LAN
Link Aggregation
LTE Notes
MPLS
NAT
OAM
OSPF
PBB
PPP
QoS
GDOI is a group key management protocol used to provide a set of IPSec keys to a group of IOS devices called
Group Members (GM) that wish to communicate securely i.e. GDOI is run between a GM and a Key Server (KS).
These keys are periodically refreshed on all devices using a process called rekey.
GDOI is a "Phase 2" protocol which is protected by "Phase 1 Security Association (SA)". IKE Phase 1 remains the
same as in traditional IPSec. All Group Members authenticate themselves using IKE to the device providing keys
(called a Key Server) which is statically configured for all Group Members. All IKE authentication methods are
supported - Pre-Shared Keys (PSK) or RSA-Signature (PKI) or RSA-Encryption.
GDOI introduces two different types of encryption keys- the Key Encryption Key (KEK) is used to secure GET VPN
control plane, and the Traffic Encryption Key (TEK) which encrypts the data traffic.
RFC 3547 defines GDOI. GDOI runs on UDP port 848. There are six new payloads for GDOI:
Security
Traffic Engineering
VPLS
VPN
Attachments
a) GDOI SA
b) SA KEK which follows the SA payload
c) SA TEK which follows the SA payload
d) Key Download Array (KD)
e) Sequence Number (SEQ)
f) Proof of Possession (POP)
2. Key Server (KS)

A Key Server is a Cisco IOS device which is responsible for creating and maintaining GET VPN control plane. All IPSec
policies like interesting traffic, IPSec security protocols, rekey timers, etc are manually defined on the Key Server,
and are downloaded by Group Members using registration.
Even if a Group Member owns a particular network or not, it downloads the interesting traffic defined on the Key
Server (using ACL).
3. Co-operative Key Server (COOP KS)

GET VPN supports multiple KS if a KS fails or becomes unreachable. A Group Member can be configured to register
with a list of KSs.
When COOP KSs boot, all KSs assume a "secondary" role and begin election process. A KS with highest priority wins
the election (in case of a tie, the KS with highest IP Address wins) and becomes the "primary" KS. Other KSs remain
in "secondary" state.
A GM can register with either a Primary or Secondary KS. However, only Primary KS sends rekey messages. If a
Secondary KS does not "hear" from the Primary KS for a period of time, the Secondary KS tries to contact Primary KS
for updated information. If the Secondary KS still does not hear from Primary KS, re-election takes place and a
Primary KS is elected.
4. Group Member (GM)

A GM is an IOS device responsible to handle GET VPN data plane. These are the actual devices who forms IPSec
connections between them. A GM is statically configured with IKE Phase 1 parameters and Key Server information.
The GMs download IPSec policies and keys from the KS during registration.
5. Rekeying
A KS performs rekey process (sending new keys when existing keys are about to expire) which includes refreshing
keys and distributing to the GMs. GET VPN supports two types of rekey messages:
a) Unicast rekey: In this process, the KS generates a rekey message and sends multiple copies of the message, one
for each GM. The GM sends an ACK message upon receiving the rekey message.
b) Multicast rekey: In this process, the KS generates a rekey message and sends a single copy of the message to the
multicast address defined in the configuration. Each GM joins the multicast group at the time of registration and
hence receives the rekey message. No ACK messages are sent by GM upon receiving the rekey message.
https://sites.google.com/site/amitsciscozone/home/ipsec/get-vpn
4/08/2014
Page 2 of 10
6. Time-based Anti-Replay (TBAR)

In traditional IPSec, anti-replay capability is available using counter-based sliding window. When the sender sends a
packet with a sequence number, the receiver uses a sliding window to determine whether a packet is acceptable, or
has arrived out-of-sequence.
Due to group SA in GET VPN, counter-based sliding window is ineffective. In GET VPN, all GMs can communicate
with each other using a common IPSec policy and a shared SA. Hence, there is no need to negotiate IPSec between
GMs. GET VPN uses time-based anti-replay which is based on a pseudotime clock maintained on the KS.
GET VPN uses Tunnel mode of IPSec, but instead of using the tunnel endpoints in the new IP header, it reuses the
original IP header as the new Tunnel header (much like IPSec Transport mode). This provides an advantage as the
existing routing infrastructure can be used and no separate routing instance needs to be run for GET VPN.
Note
GET VPN is not suitable to run over Internet since it reuses the original IP header as Tunnel IP header.
This can cause end-to-end routing issues as the traffic from Private network will not be able to reach the
remote end.
Hence, GET VPN is best suited for Private infrastructure like MPLS VPN or VPLS.
How GDOI Works

RFC 3547 defines two new exchanges for GDOI:
i) GROUPKEY-PULL Exchange
This exchange is also called Registration. This Phase 2 exchange downloads keys for a group's Re-key SA and Datasecurity SA. The Re-key SA includes Key Encryption Key (KEK) common to the group, and the Data-security SA
includes Traffic Encryption Key (TEK) used to encrypt/decrypt data traffic.
The Group Member (Initiator) initiates and contacts the Key Server. The GM is configured with the group identifier
and acceptable Phase 1 policy. Once Phase 1 is complete, the initiator moves to GDOI protocol. The initiator builds a
NONCE payload by choosing the Ni (Nonce value by initiator), builds an ID payload using the group identifier, and
generates HASH(1). The first GDOI message is also called Request message.
Upon receipt of the GDOI message, the Key Server (Responder) processes the NONCE and ID payloads. It verifies
that its database contains the group information for the group ID. It constructs the second GDOI message, chooses
the Nr (Nonce value by responder) for NONCE payload, the policy for the group in the ID payload, followed by SA TEK
payload for traffic SAs and SA KEK payload, and generates HASH(2). The second GDOI message is also called
Push message.
The GM receives the second GDOI message, validates the HASH(2) and process NONCE and SA payloads. If the
group policy uses Certificates for authorization, the GM generates a hash with Ni and Nr, and signs it. This becomes
the POP payload. The CERT payload holds the Public Key. The GM creates the third GDOI message using POP and
CERT payloads, and generates HASH(3). The third GDOI messages is also called ACK message.
Upon receipt of the third GDOI message, the KS validates the hash. It constructs a fourth GDOI message including
the SEQ payload containing the sequence number, the KD payload containing keys corresponding to policy previously
sent in SA TEK and KEK, and POP and CERT payloads (if needed), and generates HASH(4). The fourth message is
also called Key Download message.
The GM receives the fourth GDOI message and validates the hash. It then processes the SA TEK and KEK payloads.
The ISAKMP Header is protected by IKE Phase1 while everything after the header is encrypted. KE payload is used if
Perfect Forward Secrecy (PFS) is set.
4/08/2014
Page 3 of 10
ii) GROUPKEY-PUSH Exchange

The GROUPKEY-PUSH message replaces a Re-key SA &/or Data-security SA, and it can be pushed using unicast or
multicast. It is only a single message generated by the KS. It includes new keys when the key-lifetime is about to
finish.
Sample Scenario
A Key Server is present at the Central Site. To demonstrate unicast rekeying process with Key Server, this scenario
has Group Members GM-1 and GM-2 register with Key Server (KS).

1. Configuring IKE Policy on KS
The IKE Phase 1 remains exactly the same as traditional IPSec. Authentication methods supported are pre-shared
keys or digital certificates. In this case, we will use the pre-shared keys.
IKE Policy on KSs

!
!
! Central router
! GM-1 router
! GM-2 router
2. Configuring GDOI Group

A KS must generate exportable RSA Key-pair. This key-pair will be used for rekeying. If a redundant KS is present,
these keys (Public and Private Keys) must also be exported to this redundant KS manually.
Generating RSA Key-pair

crypto key generate rsa general-keys label GDOI_KEYS modulus 1024 exportable
Then an access-list policy needs to be defined on the KS which will identify the interesting traffic. This ACL Policy will
also be downloaded by all GMs for this KS. A Symmetric ACL policy is recommended on the KS which includes all the
networks from the GMs as source and destination. In this case, it would be as below:
Symmetric ACL Policy

permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
4/08/2014
Page 4 of 10
Lastly, we create a GDOI group on KSs. Each group defined on the KS has an identity that is shared among the GMs
within the group. Here, the identity is set to 123 for the group GDOI_GROUP.
KS will be responsible for sending rekey messages. Here, rekey messages are sent through unicast transport
mechanism with 2 retransmit messages every 60 seconds.
KS GDOI Configuration
crypto ipsec transform-set GDOI_TS esp-3des esp-md5-hmac
!
set transform-set GDOI_TS
set security-association lifetime seconds 3600
! Indicates how long IPSec SAs remain valid before they
are renegotiated (can be set to default)

!
identity number 123
server local
! Group SA identifier
! Indicates this is a Key Server
!
! Rekey configuration
! Indicates if a change is made on KS, rekey messages will be sent in 60
seconds, twice..default is 10 seconds, 2 times.

rekey lifetime seconds 86400
! Indicates how often to rekey (can be set to default- 24 hours)
! Specifies the keys to be used for a rekey to GDOI GMs
!
! Configuring Security Policies
sa ipsec 1
! Use IPSec Profile configured above
! Indicates interesting traffic to be encrypted
! Anti-replay window-size is set to 5
!
! Use this address to source rekey packets
!
!
GM Configuration
1. Configuring IKE Policies
All GMs authenticate with the KS using pre-shared keys.
IKE Policy on GMs

!
!
! KS Router
2. Configuring GDOI Group

A GM is configured using the same group SA identity number as on the KS and Server IP address.
GDOI Group Configuration on GM-1 and GM-2

identity number 123
!
! Key Server KS
3. Configuring Crypto Map

This step involves creating a crypto-map and applying the crypto-map to the physical interface.
Configuring and Applying Crypto Map on GMs

crypto map GETVPN local-address Loopback 0
!
crypto map GETVPN 10 gdoi
set group GDOI_GROUP
!
description Connection to PE
....
crypto map GETVPN
!
! Use Loopback 0 IP address when contacting the KS
4/08/2014
Page 5 of 10
Verification
When the crypto-map is applied to the physical interface on GM-1, it immediately sends a Register message to the KS
and downloads the policies. All GMs follow the same process. The below output is taken from KS using debug crypto
gdoi command.
debug crypto gdoi command on KS

*Jun 28 23:46:51.247: ISAKMP (0): received packet from 11.11.11.11 dport 848 sport 848 Global (N) NEW SA
*Jun 28 23:46:51.251: ISAKMP: Created a peer struct for 11.11.11.11, peer port 848
*Jun 28 23:46:51.251: ISAKMP: New peer created peer = 0x678DBAAC peer_handle = 0x80000006
*Jun 28 23:46:51.255: ISAKMP: Locking peer struct 0x678DBAAC, refcount 1 for crypto_isakmp_process_block
*Jun 28 23:46:51.259: ISAKMP: local port 848, remote port 848
*Jun 28 23:46:51.263: ISAKMP:(0):insert sa successfully sa = 66CCDB50
*Jun 28 23:46:51.267: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jun 28 23:46:51.267: ISAKMP:(0):Old State = IKE_READY
New State = IKE_R_MM1
! KS receives an IKE
Proposal from GM-1

*Jun 28 23:46:51.283: ISAKMP:(0): processing SA payload. message ID = 0
*Jun 28 23:46:51.287: ISAKMP:(0):Switching to SW IKE SA: sa is 66CCDB50, ce_id is 80000002
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
23:46:51.291:
23:46:51.291:
23:46:51.295:
23:46:51.295:
23:46:51.299:
23:46:51.303:
23:46:51.303:
23:46:51.307:
23:46:51.307:
23:46:51.311:
23:46:51.315:
23:46:51.315:
23:46:51.319:
23:46:51.323:
23:46:51.323:
23:46:51.327:
23:46:51.327:
23:46:51.327:
23:46:51.331:
23:46:51.331:
23:46:51.335:
23:46:51.335:
23:46:51.339:
23:46:51.343:
23:46:51.343:
23:46:51.347:
23:46:51.347:
23:46:51.351:
23:46:51.355:

ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
ISAKMP (0): vendor ID is NAT-T RFC 3947
ISAKMP (0): vendor ID is NAT-T v7
ISAKMP:(0): vendor ID is NAT-T v3
ISAKMP:(0):found peer pre-shared key matching 11.11.11.11
ISAKMP:(0): local preshared key found
ISAKMP : Scanning profiles for xauth ...
ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP: encryption DES-CBC
ISAKMP:
hash SHA
ISAKMP:
default group 1
ISAKMP:
auth pre-share
ISAKMP:
ISAKMP:
ISAKMP:(0):atts are acceptable. Next payload is 0
ISAKMP:(0):Acceptable atts:actual life: 0
ISAKMP:(0):Acceptable atts:life: 0
ISAKMP:(0):Fill atts in sa vpi_length:4
ISAKMP:(0):Fill atts in sa life_in_seconds:86400
ISAKMP:(0):Returning Actual lifetime: 86400
ISAKMP:(0)::Started lifetime timer: 86400.
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
28
28
28
28
28
28
28
28
28
28
28
28
28
23:46:51.355:
23:46:51.359:
23:46:51.359:
23:46:51.363:
23:46:51.367:
23:46:51.367:
23:46:51.371:
23:46:51.375:
23:46:51.375:
23:46:51.379:
23:46:51.383:
23:46:51.383:
23:46:51.387:

ISAKMP (0): vendor ID is NAT-T RFC 3947
ISAKMP (0): vendor ID is NAT-T v7
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Jun 28 23:46:51.391: ISAKMP:(0):Old State = IKE_R_MM1
*Jun 28 23:46:51.395: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

*Jun 28 23:46:51.399: ISAKMP:(0): sending packet to 11.11.11.11 my_port 848 peer_port 848 (R) MM_SA_SETUP
*Jun 28 23:46:51.403: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Jun 28 23:46:51.407: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Jun 28 23:46:51.407: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM2
! KS matches the IKE
Proposal, and if, the attributes matches, it sends a Policy Acceptance message to GM-1 router
*Jun 28 23:46:51.667: ISAKMP (0): received packet from 11.11.11.11 dport 848 sport 848 Global (R)
MM_SA_SETUP
! KS receives a sharedsecret key from GM-1 router
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
*Jun
28
28
28
28
28
28
28
28
23:46:51.687:
23:46:51.731:
23:46:51.739:
23:46:51.747:
23:46:51.751:
23:46:51.755:
23:46:51.755:
23:46:51.759:
ISAKMP:(0): processing KE payload. message ID = 0

ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(0):found peer pre-shared key matching 11.11.11.11
ISAKMP:(1003): vendor ID is DPD
ISAKMP:(1003): speaking to another IOS box!
4/08/2014
Page 6 of 10
*Jun 28 23:46:51.759: ISAKMP:(1003): vendor ID seems Unity/DPD but major 221 mismatch
*Jun 28 23:46:51.759: ISAKMP:(1003): vendor ID is XAUTH
*Jun 28 23:46:51.759: ISAKMP:received payload type 20
*Jun 28 23:46:51.759: ISAKMP (1003): His hash no match - this node outside NAT
*Jun 28 23:46:51.759: ISAKMP:received payload type 20
*Jun 28 23:46:51.759: ISAKMP (1003): No NAT Found for self or peer
*Jun 28 23:46:51.759: ISAKMP:(1003):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Jun 28 23:46:51.759: ISAKMP:(1003): sending packet to 11.11.11.11 my_port 848 peer_port 848 (R) MM_KEY_EXCH
! KS also derives the
same shared-secret key and sends it to GM-1

!--- Both peers now authenticate each other using Messages 5 and 6
!
MM_KEY_EXCH
*Jun 28 23:46:51.939: ISAKMP:(1003): processing ID payload. message ID = 0

*Jun 28 23:46:51.939: ISAKMP (1003): ID payload
next-payload : 8
type
: 1
address
: 11.11.11.11
protocol
: 17
port
: 848
length
: 12
*Jun 28 23:46:51.947: ISAKMP:(0):: peer matches *none* of the profiles
*Jun 28 23:46:51.947: ISAKMP:(1003): processing HASH payload. message ID = 0
*Jun 28 23:46:51.955: ISAKMP:(1003): processing NOTIFY INITIAL_CONTACT protocol 1
spi 0, message ID = 0, sa = 66CCDB50
*Jun 28 23:46:51.955: ISAKMP:(1003):SA authentication status:
authenticated
*Jun 28 23:46:51.959: ISAKMP:(1003):SA has been authenticated with 11.11.11.11
*Jun 28 23:46:51.963: ISAKMP:(1003):SA authentication status:
authenticated
*Jun 28 23:46:51.967: ISAKMP:(1003): Process initial contact,
bring down existing phase 1 and 2 SA's with local 1.1.1.1 remote 11.11.11.11 remote port 848
*Jun 28 23:46:51.971: ISAKMP: Trying to insert a peer 1.1.1.1/11.11.11.11/848/, and inserted successfully
678DBAAC.
*Jun 28 23:46:51.975: ISAKMP:(1003):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Jun 28 23:46:51.991: ISAKMP:(1003):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
*Jun 28 23:46:51.995: ISAKMP (1003): ID payload
next-payload : 8
type
: 1
address
: 1.1.1.1
protocol
: 17
port
: 500
length
: 12
*Jun 28 23:46:52.003: ISAKMP:(1003):Total payload length: 12
*Jun 28 23:46:52.007: ISAKMP:(1003): sending packet to 11.11.11.11 my_port 848 peer_port 848 (R) MM_KEY_EXCH
*Jun 28 23:46:52.019: ISAKMP:(1003):Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE
*Jun 28 23:46:52.031: ISAKMP:(1003):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
*Jun 28 23:46:52.035: ISAKMP:(1003):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
!---- Once IKE Phase 1 is completed, GDOI protocol starts. The GM-1 sends a Register message to KS for
group-identity 123
!
GDOI_IDLE
*Jun 28 23:46:52.295: ISAKMP: set new node 847121871 to GDOI_IDLE
*Jun 28 23:46:52.307: ISAKMP:(1003): processing NONCE payload. message ID = 847121871
!---- The KS sends the second GDOI message- PUSH message. It carries the policy for the group-identity, and
KEK and TEK policy
*Jun 28 23:46:52.319: ISAKMP:(1003): sending packet to 11.11.11.11 my_port 848 peer_port 848 (R) GDOI_IDLE
*Jun 28 23:46:52.327: ISAKMP:(1003):Node 847121871, Input = IKE_MESG_FROM_PEER, IKE_GDOI_EXCH
*Jun 28 23:46:52.327: ISAKMP:(1003):Old State = GDOI_KS_LISTEN New State = GDOI_KS_AWAIT_ACK
!---- KS receives a GDOI ACK message from GM-1
GDOI_IDLE
!---- KS now sends the Key Download GDOI message carrying the KEK and TEK Keys for policies distributed
earlier
*Jun 28 23:46:52.591: ISAKMP:(1003): sending packet to 11.11.11.11 my_port 848 peer_port 848 (R) GDOI_IDLE
*Jun 28 23:46:52.599: ISAKMP:(1003):deleting node 847121871 error TRUE reason ""
4/08/2014
Page 7 of 10
*Jun 28 23:46:52.603: ISAKMP:(1003):Node 847121871, Input = IKE_MESG_FROM_PEER, IKE_GDOI_EXCH

*Jun 28 23:46:52.603: ISAKMP:(1003):Old State = GDOI_KS_AWAIT_ACK
New State = GDOI_KS_AWAIT_ACK
The show crypto gdoi command displays all the basic configuration about a GDOI group. The output vary
depending on KS or GM.
show crypto gdoi on KS

KS# show crypto gdoi group GDOI_GROUP
Group Name
: GDOI_GROUP (Unicast)
Group Identity
Group Members
: 123
: 3
IPSec SA Direction
: Both
Active Group Server
: Local
Group Rekey Lifetime
: 86400 secs
Group Rekey
Remaining Lifetime
Rekey Retransmit Period
: 83307 secs
: 60 secs
Rekey Retransmit Attempts: 2

Group Retransmit
Remaining Lifetime
: 0 secs
IPSec SA Number
:
IPSec SA Rekey Lifetime:
Profile Name
:
Replay method
:
Replay Window Size
:
SA Rekey
Remaining Lifetime :
ACL Configured
:
Group Server list
1
3600 secs
GDOI_PROFILE
Time Based
5
508 secs
access-list ACL
: Local
This GDOI policy is downloaded on GM. The below output shows GDOI group on GM-1.
show crypto gdoi on GM-1

GM-1# show crypto gdoi
GROUP INFORMATION
Group Name
Group Identity
Rekeys received
IPSec SA Direction
Active Group Server
Group Server list
:
:
:
:
:
:
GDOI_GROUP
123
1
Both
1.1.1.1
1.1.1.1
GM Reregisters in
: 2607 secs
Rekey Received(hh:mm:ss) : 00:14:18
Rekeys received
Cumulative
: 1
After registration
Rekey Acks sent
: 1
: 1

access-list permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
KEK POLICY:
Lifetime (secs)
Encrypt Algorithm
Key Size
Sig Hash Algorithm
: Unicast
: 83284
: 3DES
: 192
: HMAC_AUTH_SHA
: 1024
TEK POLICY for the current KS-Policy ACEs Downloaded:

Serial1/0:
IPsec SA:
spi: 0xAA96A792(2862000018)
The show crypto gdoi ks command shows number of GMs registered with the KS for a particular group.
show crypto gdoi ks on KS

KS# show crypto gdoi ks
Total group members registered to this box: 3
Key Server Information For Group GDOI_GROUP:
Group Name
: GDOI_GROUP
Group Identity
: 123
4/08/2014
Page 8 of 10
Group Members
: 3
IPSec SA Direction
: Both
ACL Configured:
access-list ACL
The show crypto gdoi gm command displays GDOI information on GM.
show crypto gdoi gm on GM-1

GM-1# show crypto gdoi gm
Group Member Information For Group GDOI_GROUP:
IPSec SA Direction
ACL Received From KS
: Both
: gdoi_group_GDOI_GROUP_temp_acl
Last rekey seq num
: 1
Re-register
Remaining time
: 2593 secs
Retry Timer
:NOT RUNNING
Rekey Messages
When the key lifetime is about to expire on KS, the KS sends new keys via unicast or multicast (depending on the
mechanism configured). Here, KS sends unicast rekey messages to all GMs (Central, GM-1 and GM-2 routers). All
GMs responds back with an ACK message to the KS.
debug crypto gdoi on KS

KS#
*Jun 28
*Jun 28
*Jun 28
*Jun 28
*Jun 28
*Jun 28
*Jun 28
*Jun 28
*Jun 28
*Jun 28
1.1.1.1
23:59:35.927:
23:59:35.927:
23:59:35.931:
23:59:36.043:
23:59:36.043:
23:59:36.191:
23:59:36.191:
23:59:36.351:
23:59:36.355:
23:59:36.359:
with seq # 1
ISAKMP:(0):insert sa successfully sa = 66CCE314

ISAKMP:(0):Node 0, Input = IKE_MESG_FROM_TIMER, IKE_GDOI_REKEY_TIMER_EXPIRED
ISAKMP:(0):Old State = UNKNOWN New State = GDOI_KS_REKEY_READY
ISAKMP:(0): sending packet to my_port 848 peer_port 848 (I) GDOI_REKEY
%GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group GDOI_GROUP from address
!---- KS receives ACK

*Jun 28 23:59:36.531:
*Jun 28 23:59:36.971:
*Jun 28 23:59:37.059:
messages from GMs

ISAKMP (0): received packet from 2.2.2.2 dport 848 sport 848 Global (I) GDOI_REKEY
The following output is taken from Central router receiving rekey messages from KS. It basically contains the Key
Download (KD) payload which contains new keys for KEK and TEK policies.
Rekey message received on Central router

Central#
*Jun 28 23:59:45.523:
*Jun 28 23:59:45.551:
*Jun 28 23:59:45.555:
*Jun 28 23:59:45.555:
*Jun 28 23:59:45.559:
*Jun 28 23:59:45.559:
*Jun 28 23:59:45.563:
*Jun 28 23:59:45.563:
*Jun 28 23:59:45.571:
*Jun 28 23:59:45.575:
kek_sa->dst 2.2.2.2
*Jun 28 23:59:45.579:
*Jun 28 23:59:45.583:
*Jun 28 23:59:45.583:
*Jun 28 23:59:45.587:
*Jun 28 23:59:45.587:
*Jun 28 23:59:45.587:
*Jun 28 23:59:45.591:
*Jun 28 23:59:45.591:
*Jun 28 23:59:45.595:
GDOI:INFRA:(GDOI_GROUP:1004):Received Rekey Message!

GDOI:INFRA:(GDOI_GROUP:1004):Signature Valid!
GDOI:INFRA:(1004):received payload type 18
GDOI:INFRA:(1004):processing GDOI Seq Payload, message_id 0
GDOI:REPLAY:(GDOI_GROUP:0):
KS PSEUDOTIME is 5265.50 (secs)
GDOI:INFRA:(1004):Completed SEQ Processing for seq 1
GDOI:INFRA:(1004):processing GDOI SA Payload, message ID + 0
GDOI:REKEY:(0):Received Rekey Cookies matched our Group Info
GDOI:INFRA:(1004):processing GDOI SA KEK Payload
GDOI:INFRA:(1004): kek_sa->src 1.1.1.1
GDOI:INFRA:(1004):
KEK_ALGORITHM 5
GDOI:INFRA:(1004):
KEY_LENGTH 192
GDOI:INFRA:(1004):
KEY_LIFETIME 83284
GDOI:INFRA:(1004):
UNICAST REKEY TRANSPORT
GDOI:INFRA:(1004):
SIG_HASH_ALG 2
GDOI:INFRA:(1004):
SIG_ALG 1
GDOI:INFRA:(1004):
SIG_KEY_LEN 1024
GDOI:INFRA:(1004): Completed KEK Processing
GDOI:REKEY:(0):Received Rekey Cookies matched our Group Info
*Jun 28 23:59:45.599: GDOI:INFRA:(GDOI_GROUP:1004): TEK SPI is 0xB8F577EF

*Jun 28 23:59:45.603: GDOI:INFRA:(GDOI_GROUP:1004): Completed processing GDOI SA TEK Payload - PERMIT
*Jun 28 23:59:45.607: GDOI:REKEY:(0):Received Rekey Cookies matched our Group Info
*Jun
*Jun
*Jun
*Jun
*Jun
28
28
28
28
28
23:59:45.607:
23:59:45.611:
23:59:45.611:
23:59:45.615:
23:59:45.619:
GDOI:INFRA:(GDOI_GROUP:1004): TEK SPI is 0xAA96A792

GDOI:INFRA:(GDOI_GROUP:1004): Completed processing GDOI SA TEK Payload - PERMIT
GDOI:INFRA:(1004):processing GDOI Private Attribute Payload
GDOI:INFRA:(1004): Completed GDOI Attribute Processing
GDOI:INFRA:(GDOI_GROUP:1004):Completed processing 2 GDOI SA TEK Payloads
*Jun 28 23:59:45.619: GDOI:INFRA:(1004):received payload type 17
4/08/2014
Page 9 of 10

*Jun 28 23:59:45.623: GDOI:INFRA:(1004):processing GDOI KD Payload, message_id
*Jun 28 23:59:45.627: GDOI:INFRA:(1004):processing GDOI Key Packet, message_id
0
1694900728
*Jun 28 23:59:45.627: GDOI:INFRA:(1004):processing TEK KD: spi is 0xB8F577EF

*Jun 28 23:59:45.631: GDOI:INFRA:(1004):processing LIST of TEK SA spis
*Jun 28 23:59:45.635: GDOI:INFRA:(1004): SA TEK spi is 0xB8F577EF
, current KD TEK spi is 0xB8F577EF
*Jun 28 23:59:45.635: GDOI:INFRA:(1004):

lifetime is 485 seconds
*Jun 28 23:59:45.639: GDOI:INFRA:(1004):TEK Integrity Key 16 bytes
*Jun 28 23:59:45.643: GDOI:INFRA:(1004):Completed KeyPkt Processing
1694900728
*Jun 28 23:59:45.651: GDOI:INFRA:(1004):processing TEK KD: spi is 0xAA96A792

*Jun 28 23:59:45.651: GDOI:INFRA:(1004):processing LIST of TEK SA spis
*Jun 28 23:59:45.655: GDOI:INFRA:(1004): SA TEK spi is 0xB8F577EF , current KD TEK spi is 0xAA96A792
*Jun 28 23:59:45.659: GDOI:INFRA:(1004): SA TEK spi is 0xAA96A792
, current KD TEK spi is 0xAA96A792
*Jun 28 23:59:45.659: GDOI:INFRA:(1004):

*Jun 28 23:59:45.663: GDOI:INFRA:(1004):TEK Integrity Key 16 bytes
1694900728
*Jun 28 23:59:45.671: GDOI:INFRA:(1004): Processing KEK KD

*Jun 28 23:59:45.679: GDOI:INFRA:(1004):Unicast Rekey from KS 1
*Jun 28 23:59:45.687: GDOI:INFRA:(GDOI_GROUP:1004):GDOI : Sending GDOI_REKEYACK_PUSH
from 2.2.2.2 to 1.1.1.1 for seq # 1
*Jun 28 23:59:45.691: GDOI:GM_REKEY:(0):What's in the pre-hash packet?
*Jun 28 23:59:45.691: GDOI:GM_REKEY:(0):message start is
: 52
*Jun 28 23:59:45.695: GDOI:GM_REKEY:(0):Length being hashed : 16

What's being sent to hash on the GM side?
*Jun 28 23:59:45.695: GDOI:GM_REKEY:(0):What's in the payload to hash?
*Jun 28 23:59:45.699: GDOI:REKEY:(0):Digest being copied into ack payload :
*Jun 28 23:59:45.703: GDOI:GM_REKEY:(0):Total payload sent to KS
68
*Jun 28 23:59:45.711: GDOI:INFRA:(GDOI_GROUP:1004):GDOI REKEY ACK sent successfully by GM from

2.2.2.2 to 1.1.1.1 for seq # 1 using spi B955AD0B7CD84DAB
*Jun 28 23:59:45.715: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GDOI_GROUP from 1.1.1.1 to 2.2.2.2
with seq # 1
*Jun 28 23:59:45.719: GDOI:INFRA:(GDOI_GROUP:1004): using SPI B955AD0B7CD84DAB
*Jun 28 23:59:45.747: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match: ipsec identities
src addr
: 192.168.0.0
dst addr
: 192.168.0.0
src mask addr
: 255.255.0.0
dst mask addr
*Jun 28 23:59:45.751: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match: ipsec identities
protocol
: 0
src port
: 0
dst port
: 0
*Jun 28 23:59:45.755: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match: ks ace
ace src addr
: 192.168.0.0
ace dst addr
: 192.168.0.0
ace src mask addr
: 0.0.255.255
ace dst mask a
*Jun 28 23:59:45.759: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match: ks ace
ace protocol
: 256
ace src port
: 0
ace dst port
: 0
*Jun 28 23:59:45.763: GDOI:INFRA:(GDOI_GROUP:0):crypto exact match ace number : 1
*Jun 28 23:59:45.779: GDOI:INFRA:(GDOI_GROUP:0):Crypto
src addr
: 192.168.0.0
dst addr
: 192.168.0.0
src mask addr
: 255.255.0.0
dst mask addr
protocol
: 0
src port
: 0
dst port
: 0
ace src addr
: 192.168.0.0
ace dst addr
: 192.168.0.0
ace src mask addr
: 0.0.255.255
ace dst mask a
ace protocol
: 256
ace src port
: 0
ace dst port
: 0
*Jun 28 23:59:45.795: GDOI:INFRA:(GDOI_GROUP:0):crypto
gdoi exact match: ipsec identities
gdoi exact match: ipsec identities
gdoi exact match: ks ace
gdoi exact match: ks ace
exact match ace number : 1
4/08/2014
Page 10 of 10
*Jun 28 23:59:45.803: GDOI:GM:(0):Unicast Rekey installed 1 new ipsec SA(s) for group GDOI_GROUP.
*Jun 28 23:59:45.807: GDOI:GM:(GDOI_GROUP:0):If no rekey is received in 3482 seconds, group GDOI_GROUP will
re-register to KS
Further reading:
1. http://www.securemulticast.org/msec2_ietf51_gdoi_update.pdf
2. http://www.wr-mem.com/?p=307
3. http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/ps7180/deployment_guide
Comments
4/08/2014
GDOI-based DMVPN - Knowledge Base
Knowledge
Base
Page 1 of 20
Search this site
Home
BGP
Data Center
GPON
Hadoop
IP Multicast
IPv6
IS-IS
Juniper-JUNOS
L2VPN
LAN
Link Aggregation
LTE Notes
MPLS
NAT
OAM
OSPF
PBB
PPP
QoS
Security
Traffic Engineering
VPLS
VPN
GDOI-based DMVPN
In traditional DMVPN, if Spoke-to-Spoke direct connectivity is
enabled (i.e DMVPN Phase 2), a permanent IPSec tunnel is
maintained between the Spoke and the Hub, and a dynamic
IPSec tunnel is created on demand between the Spokes. When a
Spoke router wishes to send traffic to another Spoke router, it
sends a NHRP Resolution Request message to the DMVPN Hub for
the destination Spoke router. Once the mapping is received, the
Spoke router will initiate a dynamic IPSec tunnel with the
destination Spoke router. Until this dynamic IPSec tunnel is
created, traffic flows through the Hub. If traffic needs to come in
reverse direction, the destination Spoke router follows the same
process towards the originating Spoke router.
When a dynamic IPSec tunnel is created for Spoke-to-Spoke
connectivity, it introduces a slight delay caused by IPSec
negotiation which can lead to poor performance for certain realtime applications like VOIP. GDOI eliminates this delay.
With GDOI, the DMVPN Hub and Spokes are the Group Members
(GMs). Group Keys and security policies are distributed to GMs by
the Key Server (KS)- a separate Cisco IOS router. This eliminates
the point-to-point IPSec session between the GMs. Once NHRP
resolution is completed, the Spokes can communicate using the
same key. This reduces delay between Spoke-to-Spoke
communication by eliminating creation of dynamic IPSec
tunnels between them.
Attachments
Sample Scenario
https://sites.google.com/site/amitsciscozone/home/ipsec/gdoi-based-dmvpn
4/08/2014
Page 2 of 20

All GMs register with the KS and the KS is responsible for
distributing keys and security policies. Since all traffic must flow
through mGRE tunnel, the interesting traffic can be categorized
as GRE traffic from any DMVPN router to other DMVPN router.
The configuration of KS is as below:
KS Configuration
crypto key generate rsa general-keys label GDOI_KEYS
modulus 1024 exportable
!
!
!---- Manually configuring pre-shared keys for all GMs
!
! Hub
router
! Spoke1
router
! Spoke2
router
! Spoke3
router
!
crypto ipsec transform-set GDOI_TS edp-3des esp-md5-hmac
!
!
4/08/2014
Page 3 of 20

identity number 123
server local
!
sa ipsec 1
!
packets
! Use this address to send rekey
!
!
permit gre any any
! Encrypt all GRE packets
!
GM (Hub and Spoke) Tunnel and GDOI

Configuration
The Hub and Spoke routers must be configured with a mGRE
tunnel for DMVPN.
Tunnel Configuration on Hub

interface Tunnel 10
ip address 192.168.100.1 255.255.255.0
tunnel key 123
ip nhrp holdtime 240
overwrite
! Disable next-hop
advertised to Spoke routers
! Allow routes to be re-
!
router eigrp 10
! routing instance for DMVPN
no auto-summary
network 192.168.100.0
network 192.168.1.0
!
The following shows configuration on Spoke1 router. A similar

configuration applies to other Spoke routers.
4/08/2014
Page 4 of 20
Tunnel Configuration on Spoke1

interface Tunnel 10
ip address 192.168.100.2 255.255.255.0
tunnel key 123
ip nhrp nhs 192.168.100.1
ip nhrp map 192.168.100.1 172.17.1.1
ip nhrp holdtime 240
!
router eigrp 10
no auto-summary
network 192.168.100.0
network 192.168.2.0
!
Then GDOI configuration on Hub and Spoke routers is as follows:
GDOI Configuration
!
!
identity number 123
! Address of KS
!
crypto map DMVPN local-address Loopback0
crypto map DMVPN 10 gdoi
set group GDOI_GM
!
....
crypto map DMVPN
!
Verification
First all routers (Hub and Spokes) register with the KS and
download the policies configured on the KS. All routers complete
IKE Phase 1 with the KS and start GDOI protocol by sending
Register messages to the KS. In the end, the KS sends the Key
Download Payload which contains the KEK and TEK keys. The
below output shows successful IKE Phase 1 with all routers, but
no IKE Phase 2 on KS.
4/08/2014
Page 5 of 20
KS# show crypto isakmp sa

dst
status
src
state
conn-id
1.1.1.1
ACTIVE
13.13.13.13
GDOI_IDLE
1004
1.1.1.1
ACTIVE
11.11.11.11
GDOI_IDLE
1002
1.1.1.1
ACTIVE
12.12.12.12
GDOI_IDLE
1003
1.1.1.1
ACTIVE
2.2.2.2
GDOI_IDLE
1001

KS# show crypto ipsec sa
No SAs found
The following output shows GDOI policy downloaded by GM

Spoke1 router. The output will be similar for all GMs.
GDOI Policy on Spoke1

Spoke1# show crypto gdoi
GROUP INFORMATION
Group Name
Group Identity
: GDOI_GM
: 123
Rekeys received
IPSec SA Direction
: 1
: Both
Active Group Server

Group Server list
: 1.1.1.1
: 1.1.1.1
GM Reregisters in
: 2287 secs
Rekey Received(hh:mm:ss) : 00:19:59
Rekeys received
Cumulative
After registration
Rekey Acks sent
: 1
: 1
: 1

access-list permit gre any any
KEK POLICY:
Lifetime (secs)
: Unicast
: 86399
Encrypt Algorithm
Key Size
: 3DES
: 192
Sig Hash Algorithm

: HMAC_AUTH_SHA
: 1024
4/08/2014
Page 6 of 20

Serial1/0:
IPsec SA:
spi: 0x42CE20E(70050318)
All GMs have a single IKE session with KS. Notice that the remote
endpoint peer is 0.0.0.0 i.e. Spoke1 is open for any other GM.
IKE Session on Spoke1

dst
status
src
state
conn-id
1.1.1.1
ACTIVE
11.11.11.11
GDOI_IDLE
1001
11.11.11.11
ACTIVE
1.1.1.1
GDOI_REKEY
1002
11.11.11.11
ACTIVE
1.1.1.1
GDOI_REKEY
1003

PFS (Y/N): N, DH group: none
Crypto map tag: DMVPN, local addr 11.11.11.11
local ident (addr/mask/prot/port):
(0.0.0.0/0.0.0.0/47/0)
remote ident (addr/mask/prot/port):
(0.0.0.0/0.0.0.0/47/0)
#pkts encaps: 708, #pkts encrypt: 708, #pkts digest:
708
#pkts decaps: 777, #pkts decrypt: 777, #pkts verify:
777
local crypto endpt.: 11.11.11.11, remote crypto
endpt.: 0.0.0.0
current outbound spi: 0x42CE20E(70050318)
inbound esp sas:
4/08/2014
Page 7 of 20
spi: 0x42CE20E(70050318)
conn id: 5, flow_id: SW:5, sibling_flags 80000040,
crypto map: DMVPN
sa timing: remaining key lifetime (sec): (2359)
IV size: 8 bytes
replay window size: 5
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x42CE20E(70050318)
conn id: 6, flow_id: SW:6, sibling_flags 80000040,
crypto map: DMVPN
sa timing: remaining key lifetime (sec): (2359)
IV size: 8 bytes
Status: ACTIVE
replay window size: 5
outbound ah sas:
outbound pcp sas:
Then all Spoke routers then register with DMVPN_Hub router

using NHRP Registration Request messages. The Hub router
learns the Tunnel IP Address-to-NBMA address mapping
dynamically. These messages are GRE encapsulated and hence
encrypted by GDOI policies.
Hub learns NHRP mappings dynamically

DMVPN_Hub# show ip nhrp
192.168.100.2/32 via 192.168.100.2
192.168.100.3/32 via 192.168.100.3
192.168.100.4/32 via 192.168.100.4
This forms EIGRP adjacency over the tunnel interface and routes
are exchanged between DMVPN routers. Note that these EIGRP
packets are also encapsulated in GRE as they travel over tunnel
4/08/2014
Page 8 of 20
interface, and hence encapsulated by ESP. Notice the next-hop

remains unchanged when these routes are advertised to Spoke
routers.
EIGRP Routes learnt by Hub router via Tunnel

interface
DMVPN_Hub# show ip route eigrp
D
192.168.4.0/24 [90/26882560] via 192.168.100.4,
00:04:16, Tunnel10
D
192.168.2.0/24 [90/26882560] via 192.168.100.2,
00:04:07, Tunnel10
D
192.168.3.0/24 [90/26882560] via 192.168.100.3,
00:00:40, Tunnel10
Spoke3 to Spoke1 Communication

Before Spoke3 sends traffic to Spoke1 router, there is only a
static NHRP mapping to the Hub router (the same is true for
Spoke1 router as well).
Static NHRP mapping on Spoke3 router

192.168.100.1/32 via 192.168.100.1
When Spoke3 router sends traffic to the network behind

(192.168.2.0/24) Spoke1 router sourced from the network
behind it (192.168.4.0/24), it looks up its routing table and finds
the next-hop as Spoke2 router. However, it does not have NHRP
mapping for Spoke1 router. Hence it devices to send a Resolution
Request to the NHS and meanwhile still send the packets to
Spoke1 through the Hub.
debug NHRP
Spoke3# debug nhrp
NHRP protocol debugging is on
Spoke3#
Spoke3# ping 192.168.2.1 source fastethernet 0/0
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2
seconds:
*Jul
1 00:02:32.959: NHRP: Attempting to send packet via
4/08/2014
Page 9 of 20
DEST 192.168.100.1
*Jul 1 00:02:32.959: NHRP: NHRP successfully resolved
192.168.100.1 to NBMA 172.17.1.1
*Jul 1 00:02:32.963: NHRP: Encapsulation succeeded.
*Jul 1 00:02:32.963: NHRP: Send Registration Request via
Tunnel10 vrf 0, packet size: 92
*Jul 1 00:02:32.963: NHRP: 120 bytes out Tunnel10
*Jul 1 00:02:33.199: NHRP: Receive Registration Reply via
*Jul
*Jul

1 00:02:34.279: NHRP: MACADDR: if_in null netid-in 0
if_out Tunnel10 netid-out 123

*Jul 1 00:02:34.279: NHRP: Sending packet to NHS
192.168.100.1 on Tunnel10
192.168.100.1 to NBMA 172.17.1.1
*Jul 1 00:02:34.283: NHRP: Checking for delayed
event /192.168.100.2 on list (Tunnel10).
*Jul 1 00:02:34.283: NHRP: No node found.
*Jul 1 00:02:34.287: NHRP: Adding Tunnel Endpoints (VPN:
192.168.10!0.2, NBMA: 172.17.1.1)
*Jul 1 00:02:34.295: NHRP: Enqueued NHRP Resolution
Request for destination: 192.168.100.2
*Jul 1 00:02:34.307: NHRP: Checking for delayed
*Jul
*Jul
1 00:02:34.307: NHRP: No node found.

1 00:02:34.311: NHRP: Sending NHRP Resolution Request
for dest: 192.168.100.2 to NHS: 192.168.100.1 using our

src: 192.168.100.4
*Jul 1 00:02:34.311: NHRP: Attempting to send packet via
DEST 192.168.100.1
192.168.100.1 to NBMA 172.17.1.1
*Jul 1 00:02:34.315: NHRP: Encapsulation succeeded.
*Jul 1 00:02:34.315: NHRP: Send Resolution Request via
*Jul
*Jul

1 00:02:34.951: NHRP: NHRP successfully resolved
192.168.100.2 to NBMA 172.17.1.1

*Jul 1 00:02:35.219: NHRP: Receive Resolution Request via
*Jul 1 00:02:35.219: NHRP: netid_in = 123, to_us = 1
*Jul
*Jul
1 00:02:35.223: NHRP: nhrp_rtlookup yielded Tunnel10

1 00:02:35.223: NHRP: request was to us, responding
with ouraddress
*Jul 1 00:02:35.223: NHR!!!P: Checking for delayed event
192.168.100.2/192.168.100.4 on list (Tunnel10).
*Jul 1 00:02:35.227: NHRP: No need to delay processing of
resolution event nbma src:172.47.1.1 nbma dst:172.27.1.1
*Jul 1 00:02:35.231: NHRP: Attempting to send packet via
DEST 192.168.100.2
192.168.100.2 to NBMA 172.17.1.1
*Jul
1 00:02:35.235: NHRP: Encapsulation succeeded.
4/08/2014
Page 10 of 20

*Jul 1 00:02:35.235: NHRP: Send Resolution Reply via
*Jul 1 00:02:35.239: NHRP: 148 bytes out Tunnel10
Once Spoke3 router receives Resolution Reply message back

from NHS with NHRP mapping for Spoke1 router, it attempts to
send the packet directly to Spoke1 router rather than through
Hub router.
*Jul 1 00:02:35.247: NHRP: Receive Resolution Reply via

*Jul
*Jul

1 00:02:35.251: NHRP: Checking for delayed

*Jul 1 00:02:35.255: NHRP: No need to delay processing of
resolution event nbma src:172.47.1.1 nbma dst:172.27.1.1
*Jul 1 00:02:35.255: NHRP: Adding Tunnel Endpoints (VPN:
192.168.100.2, NBMA: 172.27.1.1)
192.168.100.2 to NBMA 172.27.1.1
192.168.100.2 to NBMA 172.27.1.1!
Success rate is 100 percent (5/5), round-trip min/avg/max =
280/483/700 ms
Spoke3#
192.168.100.2 to NBMA 172.27.1.1
192.168.100.1/32 via 192.168.100.1
192.168.100.2/32 via 192.168.100.2
192.168.100.4/32 via 192.168.100.4
(no-socket)
Note that all NHRP communication and data-traffic are encrypted

using GDOI policies. Also, no IPSec tunnels are created between
Spoke3 and Spoke1 routers.
Comments
4/08/2014
Page 11 of 20
4/08/2014
Page 12 of 20
4/08/2014
Page 13 of 20
4/08/2014
Page 14 of 20
4/08/2014
Page 15 of 20
4/08/2014
Page 16 of 20
4/08/2014
Page 17 of 20
4/08/2014
Page 18 of 20
4/08/2014
Page 19 of 20
4/08/2014
Page 20 of 20
4/08/2014
GET VPN: Rekey using Multicast - Knowledge Base
Knowledge
Base
Page 1 of 10
Search this site
Home
BGP
GET VPN: Rekey using Multicast
Data Center
When a Group Member (GM) registers with a Key Server (KS) in GET
GPON
VPN, the KS pushes two IKE SAs - GDOI_IDLE and GDOI_REKEY to

the GMs. GDOI_IDLE is used to push initial IPSec SAs and GDOI_REKEY
Hadoop
IP Multicast
IPv6
IS-IS
is used to download new group IPSec SAs (rekey SAs). The advantage of
enabling GDOI rekey is that the GMs do not need to re-register with the
KS every time the group IPSec SA lifetime expires. New group IPSec SAs
are downloaded even before the existing IPSec SAs expire.
Juniper-JUNOS
L2VPN
The KS can either unicast these rekey SAs to all GMs or just multicast to
LAN
a pre-configured multicast group address. Using multicast transport

greatly enhances the usability and is very efficient in medium-to-large
Link Aggregation
LTE Notes
MPLS
NAT
OAM
OSPF
PBB
networks.
However, using multicast transport requires entire network to be
multicast enabled. This is could be an issue when the part of the network
belongs to the Service Provider. Even with GDOI-based DMVPN, it is not
possible as the Customer routers are directly connected to the Service
Provider routers.
PPP
The best way is to enable multicasting on the mGRE tunnel itself. This
QoS
article demonstrates the approach of GET VPN rekeying using multicast

over DMVPN network. The underlying Service Provider network could be
Security
Traffic Engineering
VPLS
either IP or MPLS VPN; it merely provides connectivity between

Customer sites.
VPN
There are 3 considerations for this to work-
Attachments
1. Tunnel interface(s) must support Multicast. This is required as

tunnel interfaces will be carrying multicast rekey SAs across DMVPN
network. This allows us to have multicast-free SP network.
2. Tunnel interface(s) must join multicast group for which rekey
SAs are sent. This is required, otherwise, rekey SAs will not be received
if no interfaces join the IGMP group. This can be achieved using ip igmp
join-group <multicast-address> command under the tunnel interface.
3. On all Spoke routers (if the KS is directly connected to the
Hub), the multicast source (KS) must be reachable through the
tunnel interface. This is required as all Spoke routers will do Reverse
Path Forwarding check when a multicast packet is received to see if the
multicast packets are received on the correct interface or not. By
default, the multicast source address (KS) will be reachable through the
physical interface rather than the tunnel interface, and hence, RPF check
https://sites.google.com/site/amitsciscozone/home/ipsec/get-vpn-rekey-using-multicast
4/08/2014
Page 2 of 10
will fail. To overcome this, a static multicast entry is created to trick the
router into thinking that the source address is reachable through the
tunnel interface. This can be done using ip mroute command.
Sample Scenario
This scenario demonstrates rekey using multicast. RP election is based
on Cisco Auto-RP, however, only KS is configured as the Candidate-RP.
The KS is also the Mapping Agent (MA). The Mapping Agent is
responsible to send Group-to-RP mappings to the PIM routers.
It is very essential that the MA is located at the Hub site otherwise the
Cisco-RP-Discovery messages would not be sent across to other Spoke
routers if the MA was located behind a Spoke router, for example.
KS Configuration
The KS configuration is as follows:
KS Configuration
ip multicast-routing
!
ip address 1.1.1.1 255.255.255.255
ip pim sparse-mode
!
description Connection to Central router
ip address 10.1.1.2 255.255.255.0
ip pim sparse-mode
!
crypto key generate rsa general-keys label GDOI_KEYS modulus 1024
exportable
!
4/08/2014
Page 3 of 10
!
! Central router
! GM-1 router
! GM-2 router
!
crypto ipsec transform-set GDOI_TS esp-3des esp-md5-hmac
!
!
identity number 123
server local
!
rekey address ipv4 MULTICAST_REKEY
! Indicates
multicast address to which Rekey SAs must be sent
rekey lifetime seconds 300
! Rekeys will be
sent after 300 seconds
!
sa ipsec 1
!
!
!
ip access-list extended MULTICAST_REKEY
remark Multicast address to which Rekey SAs will be sent
permit ip any host 239.10.10.1
!
remark Interesting traffic to be encrypted
permit gre any any
!
ip pim send-rp-announce Loopback 0 scope 10 group-list 1
!
Advertise this router as Candidate-RP for the range defined in ACL
1
ip pim send-rp-discovery Loopback 0 scope 10
! Indicates
this router is the RP Mapping Agent
!
access-list 1 permit 239.0.0.0 0.255.255.255
!
DMVPN Configuration
The Central router is the Hub for DMVPN network. The configuration is as
below:
Central Router Configuration

!
ip address 2.2.2.2 255.255.255.255
ip pim sparse-mode
4/08/2014
Page 4 of 10
!
!
!
identity number 123
!
crypto map DMVPN local-address Loopback 0
set group GDOI_GM
!
ip address 172.17.1.1 255.255.255.0
crypto map DMVPN
!
interface Tunnel 10
ip address 192.168.100.1 255.255.255.0
tunnel key 123
ip pim dr-priority 100
ip pim sparse-mode
ip pim nbma-mode
ip igmp join-group 239.10.10.1
!
router eigrp 10
! Routing instance for DMVPN network
no auto-summary
network 192.168.1.0
network 192.168.100.0
!
Some important commands worth knowing about:

1. ip pim dr-priority <priority-value> : This command sets the
priority on the interface connected to multi-access network. As the
tunnel is a mGRE interface which is essentially a non-broadcast multiaccess network, it is important that the Central router is elected as the
DR for the network. The DR is responsible for sending Join/ Prune
messages to the RP for the group. The router with the highest priority
becomes the DR. By default, the priority is set to 1. In case of a tie, the
router with the highest IP address becomes the DR.
2. ip pim nbma-mode : This command allows the router to send
packets to only those neighbors that want to receive them on an NBMA
network. A router in PIM NBMA mode treats each neighbor as if it were
connected to the router through a point-to-point link. The reason this is
important is that if a Spoke router sends a Prune message back to the
Hub, the Hub router will set the Prune flag for that interface, and so it
wont send any multicast packets for the group over that interface. This
will cause other Spoke router to not receive any multicast packets for
that group either. This command allows the router to track the IP
address of each neighbor when a PIM Join message is received from that
neighbor. This information allows the router to forward data destined for
4/08/2014
Page 5 of 10
a multicast group to only those neighbors that have joined that

particular group.
The configuration on the GM-1 and GM-2 routers is as below:
GM-1 Router Configuration

!
ip address 11.11.11.11 255.255.255.255
ip pim sparse-mode
!
!
!
identity number 123
!
set group GDOI_GM
!
ip address 172.27.1.1 255.255.255.0
crypto map DMVPN
!
interface Tunnel 10
ip address 192.168.100.2 255.255.255.0
tunnel key 123
ip nhrp nhs 192.168.100.1
ip nhrp map 192.168.100.1 172.17.1.1
ip pim sparse-mode
!
router eigrp 10
no auto-summary
network 192.168.11.0
network 192.168.100.0
!
ip mroute 1.1.1.1 255.255.255.255 192.168.100.1
!
GM-2 Router Configuration

!
ip address 12.12.12.12 255.255.255.255
ip pim sparse-mode
!
4/08/2014
Page 6 of 10

!
!
identity number 123
!
set group GDOI_GM
!
ip address 172.37.1.1 255.255.255.0
crypto map DMVPN
!
interface Tunnel 10
ip address 192.168.100.3 255.255.255.0
tunnel key 123
ip nhrp nhs 192.168.100.1
ip nhrp map 192.168.100.1 172.17.1.1
ip pim sparse-mode
!
router eigrp 10
no auto-summary
network 192.168.12.0
network 192.168.100.0
!
ip mroute 1.1.1.1 255.255.255.255 192.168.100.1
!
Verification
When the ip mroute 1.1.1.1 255.255.255.255 192.168.100.1
command is not applied to GM-2 router, all the PIM packets received on
its Tunnel interface will be dropped due to RPF check failure.
RPF Check Failure

GM-2#
*Jul 7 22:57:13.167: PIM(0): Received RP-Reachable on Tunnel10
from 1.1.1.1
*Jul 7 22:57:13.171: PIM(0): Received RP-Reachable on Tunnel10
from 1.1.1.1
*Jul 7 22:57:13.171:
for group 239.10.10.1
*Jul 7 22:57:13.175: PIM(0): RP not known, or mismatch
GM-2#
*Jul 7 22:57:43.127: PIM(0): Prune Tunnel10/239.10.10.1 from (*,
239.10.10.1) - deleted
*Jul 7 22:57:43.131: PIM(0): Prune Tunnel10/224.0.1.40 from (*,
224.0.1.40) - deleted
GM-2#
4/08/2014
Page 7 of 10
*Jul 7 22:58:03.727: PIM(0): Prune Tunnel10/224.0.1.40 from

(1.1.1.1/32, 224.0.1.40) - deleted
RP Election
In this case, the KS is configured as the Candidate-RP. So, the KS starts
sending out RP-Discovery messages on multicast address 224.0.1.39 to
the RP Mapping Agent. Since, it is setup as the RP Mapping Agent as
well, it elects the RP based on the available information. The KS
becomes the RP for the range 239.0.0.0/8. It starts advertising itself as
the RP for the range in RP-Announce messages to multicast address
224.0.1.40 to other PIM routers. All PIM enabled routers receive this
Group-to-RP mapping.
Group-to-RP mapping
KS# show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)
Group(s) 239.0.0.0/8
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), elected via Auto-RP
Uptime: 00:06:03, expires: 00:02:54
Central# show ip pim rp mapping
Group(s) 239.0.0.0/8
RP 1.1.1.1 (?), v2v1
Uptime: 00:00:57, expires: 00:01:58
GM-1# show ip pim rp mapping
Group(s) 239.0.0.0/8
RP 1.1.1.1 (?), v2v1
Uptime: 00:00:43, expires: 00:02:14
GM-2# show ip pim rp mapping
Group(s) 239.0.0.0/8
RP 1.1.1.1 (?), v2v1
Uptime: 00:01:28, expires: 00:02:30
When all GMs register with the KS, they download the KEK and TEK
policies using GDOI. The KS is setup as below:
KS Policy
4/08/2014
Page 8 of 10
KS# show crypto gdoi

GROUP INFORMATION
Group Name
:
Group Identity
:
Group Members
:
IPSec SA Direction
:
Active Group Server
:
Group Rekey Lifetime
:
Group Rekey
Remaining Lifetime
:
Rekey Retransmit Period :
Rekey Retransmit Attempts:
Group Retransmit
Remaining Lifetime
:
IPSec SA Number
:
IPSec SA Rekey Lifetime:
Profile Name
:
Replay method
:
Replay Window Size
:
SA Rekey
Remaining Lifetime :
ACL Configured
:
Group Server list
GDOI_GROUP (Multicast)
123
3
Both
Local
300 secs
71 secs
60 secs
2
0 secs
1
3600 secs
GDOI_PROFILE
Time Based
5
3072 secs
access-list ACL
: Local
KS# show crypto gdoi ks rekey

Group GDOI_GROUP (Multicast)
Number of Rekeys sent
Number of Rekeys retransmitted
KEK rekey lifetime (sec)
Remaining lifetime (sec)
Retransmit period
Number of retransmissions
IPSec SA 1 lifetime (sec)
Remaining lifetime (sec)
Number of registrations after rekey
Multicast destination address
:
:
:
:
:
:
:
:
:
:
4
8
300
22
60
2
3600
2123
0
239.10.10.1
All the GMs download this policy and can be displayed as below on
Central router:
Policy on Central router

Central# show crypto gdoi
GROUP INFORMATION
Group Name
Group Identity
Rekeys received
IPSec SA Direction
Active Group Server
Group Server list
:
:
:
:
:
:
GDOI_GM
123
0
Both
1.1.1.1
1.1.1.1
GM Reregisters in
Rekey Received
: 3436 secs
: never
Rekeys received
4/08/2014
Cumulative
After registration
Page 9 of 10
: 0
: 0

access-list permit gre any any
KEK POLICY:
Lifetime (secs)
Encrypt Algorithm
Key Size
Sig Hash Algorithm
:
:
:
:
:
:
Multicast
299
3DES
192
HMAC_AUTH_SHA
1024

IPsec SA:
spi: 0xF25434BF(4065604799)
Multicast Rekeying
When the rekey lifetime is about to expire, the KS sends new rekey
messages. In this case, it will be sent to multicast address 239.10.10.1
configured on the KS router. Since the GMs are tuned to this multicast
address, they will also receive this message via Tunnel 10.
Multicast Rekey message

KS#
*Jul 7 23:23:36.355: %GDOI-5-KS_SEND_MCAST_REKEY: Sending
Multicast Rekey for group GDOI_GROUP from address 1.1.1.1 to
239.10.10.1 with seq # 1
GM-1# debug crypto gdoi ks rekey
*Jul 7 23:23:36.975: GDOI:INFRA:(GDOI_GM:1004):Received Rekey
Message!
*Jul 7 23:23:37.019: GDOI:INFRA:(GDOI_GM:1004):Signature Valid!
*Jul 7 23:23:37.023: GDOI:INFRA:(1004):received payload type 18
*Jul 7 23:23:37.023: GDOI:INFRA:(1004):processing GDOI Seq
Payload, message_id 0
*Jul 7 23:23:37.027: GDOI:INFRA:(1004):Completed SEQ Processing
for seq 1
*Jul 7 23:23:37.027: GDOI:INFRA:(1004):processing GDOI SA
Payload, message ID + 0
*Jul 7 23:23:37.035: GDOI:INFRA:(1004):processing GDOI SA KEK
Payload
*Jul 7 23:23:37.039: GDOI:INFRA:(0): kek_sa->src 1.1.1.1
kek_sa->dst 239.10.10.1
*Jul 7 23:23:37.043: GDOI:INFRA:(0):
KEK_ALGORITHM 5
*Jul 7 23:23:37.043: GDOI:INFRA:(0):
KEY_LENGTH 192
*Jul 7 23:23:37.047: GDOI:INFRA:(0):
KEY_LIFETIME 299
*Jul 7 23:23:37.047: GDOI:INFRA:(0):
SIG_HASH_ALG 2
*Jul 7 23:23:37.051: GDOI:INFRA:(0):
SIG_ALG 1
*Jul 7 23:23:37.051: GDOI:INFRA:(0):
SIG_KEY_LEN 1024
*Jul 7 23:23:37.055: GDOI:INFRA:(0): New Kek is received, reset
last_seq_num to 0
4/08/2014
Page 10 of 10
*Jul 7 23:23:37.055: GDOI:INFRA:(0): Completed KEK Processing

*Jul 7 23:23:37.063: GDOI:INFRA:(1004):processing GDOI Private
Attribute Payload
*Jul 7 23:23:37.063: GDOI:INFRA:(1004): Completed GDOI Attribute
Processing
*Jul 7 23:23:37.067: GDOI:INFRA:(GDOI_GM:1004):Completed
processing 1 GDOI SA TEK Payloads
*Jul 7 23:23:37.067: GDOI:INFRA:(1004):received payload type 17
*Jul 7 23:23:37.071: GDOI:INFRA:(1004):processing GDOI KD
Payload, message_id 0
*Jul 7 23:23:37.075: GDOI:INFRA:(1004):processing GDOI Key
Packet, message_id 1694874040
*Jul 7 23:23:37.075: GDOI:INFRA:(1004):processing TEK KD: spi is
0xDE2B7089
*Jul 7 23:23:37.079: GDOI:INFRA:(1004):
*Jul 7 23:23:37.079: GDOI:INFRA:(1004):TEK Integrity Key 16 bytes
*Jul 7 23:23:37.087: GDOI:INFRA:(1004):Completed KeyPkt
Processing
*Jul 7 23:23:37.091: GDOI:INFRA:(1004):processing GDOI Key
Packet, message_id 1694874040
*Jul 7 23:23:37.091: GDOI:INFRA:(1004): Processing KEK KD
*Jul 7 23:23:37.095: GDOI:INFRA:(1004):KEK Alg Key 32 bytes
*Jul 7 23:23:37.095: GDOI:INFRA:(1004):KEK Sig Key 162 bytes
*Jul 7 23:23:37.107: GDOI:INFRA:(1004):Completed KeyPkt
Processing
*Jul 7 23:23:37.107: GDOI:INFRA:(1004):Multicast Rekey from KS 2
*Jul 7 23:23:37.115: %GDOI-5-GM_RECV_REKEY: Received Rekey for
group GDOI_GM from 1.1.1.1 to 239.10.10.1 with seq # 1
*Jul 7 23:23:37.119: GDOI:INFRA:(GDOI_GM:1004): using SPI
8D8385D6C8FF4A10
*Jul 7 23:23:37.151: GDOI:INFRA:(GDOI_GM:0):crypto exact match
ace number : 1
Comments
4/08/2014

VPNs

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

VPNs

Hochgeladen von

Copyright:

Verfügbare Formate

Site-to-site IPSec VPN using Static Crypto-maps - Knowledge Base

Search this site

Site-to-site IPSec VPN using Static Cryptomaps

There are 5 steps in the life-cycle of an IPSec VPN-

Step 1: Specifying interesting traffic using accesslist:

network 10.2.2.0/24 will be regarded as interesting traffic, and vice

Step 1: Interesting traffic

ip access-list extended Traffic_1to2

The IKE (Internet Key Exchange) protocol is a means to

Site-to-site IPSec VPN using Static Crypto-maps - Knowledge Base

key-generation(a) ISAKMP- The Internet Security Association and Key

Step 2: IKE Phase 1:

Step 2: IKE Phase 1

! by default, set to DES

Site-to-site IPSec VPN using Static Crypto-maps - Knowledge Base

Step 3: IKE Phase 2:

Step 3: IKE Phase 2

Step 4: Secure data transfer:

Site-to-site IPSec VPN using Static Crypto-maps - Knowledge Base

Site1# show crypto isakmp sa

The show crypto ipsec sa command is used to show current SA

Site1# show crypto ipsec sa

compressed: 0, #pkts decompressed: 0

local crypto endpt.: 92.1.1.1, remote crypto endpt.:

Site-to-site IPSec VPN using Static Crypto-maps - Knowledge Base

Step 5: IPSec tunnel termination:

Site-to-site IPSec VPN using Digital Certificates - Knowledge Base

Search this site

Site-to-site IPSec VPN using Digital Certificates

certificate (requires a CA Server trusted by both parties).

Obtaining Digital Certificates for the Branch routers

Then we create a trustpoint on the routers to define the trusted CA Server.

crypto pki trustpoint WIN2003

Branch1(config)# crypto pki authenticate WIN2003

Site-to-site IPSec VPN using Digital Certificates - Knowledge Base

Trustpoint CA certificate accepted.

Branch1# show crypto pki certificates

Site-to-site IPSec VPN using Digital Certificates - Knowledge Base

Certificate Serial Number: 0x6462CFFA77B593A74DB4E13D530CBC02

Configuring IKE Policies

crypto isakmp policy 10

Configuring Transform-set and Defining Interesting Traffic

crypto ipsec transform-set TS esp-3des esp-md5-hmac

Configuring Static Crypto Map

crypto map CRYPTO 10 ipsec-isakmp

Site-to-site IPSec VPN using Digital Certificates - Knowledge Base

ip address 10.1.1.1 255.255.255.0

IKE Policy Negotiated

ISAKMP:(0): SA request profile is (NULL)

Jun 6 10:21:50.095: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1

6 10:21:50.099: ISAKMP:(0): beginning Main Mode exchange

! Indicates Branch1 router is sending IKE Policy Proposal message

6 10:21:50.099: ISAKMP:(0):Sending an IKE IPv4 Packet.

6 10:21:50.319: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

Jun 6 10:21:50.319: ISAKMP:(0):Old State = IKE_I_MM1

New State = IKE_I_MM2

10:21:50.323: ISAKMP:(0): processing SA payload. message ID = 0

Jun 6 10:21:50.335: ISAKMP:(0):atts are acceptable. Next payload is 0

ISAKMP:(0):Acceptable atts:actual life: 0

6 10:21:50.395: ISAKMP:(0): processing vendor id payload

Site-to-site IPSec VPN using Digital Certificates - Knowledge Base

6 10:21:50.395: ISAKMP (0:0): vendor ID is NAT-T RFC 3947

Diffie-Hellman Key Exchange

6 10:21:50.395: ISAKMP (0:0): constructing CERT_REQ for issuer cn=WIN2003,dc=amit,dc=com