Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

DMVPN ISAKMP SA Question

Hi all,

I have set up a basic full mesh DMVPN, similar to the config used int the packet life

http://packetlife.net/blog/2008/jul/23/dynamic-multipoint-vpn-dmvpn/ tutorial.

I have one Hub and two spokes. Everything seems to be functioing ok. I have included  the config  below for the tunnels.

My Question is, when I do a show crypto isakmp sa, for example on Spoke 2, I have three ISAKMP SA's with three different SRC addresses...

How is this possible when I only have tunnels to two other devices, the hub and spoke 1??? and why is a foriegn source address showing up as an ISAKMP SA on this router?

dst             src             state          conn-id slot status

172.16.1.2      172.16.2.2      QM_IDLE              1    0 ACTIVE

172.16.2.2      172.16.3.2      QM_IDLE              3    0 ACTIVE

172.16.2.2      172.16.1.2      QM_IDLE              2    0 ACTIVE

A similar result on the Hub

dst             src             state          conn-id slot status

172.16.2.2      172.16.1.2      QM_IDLE              2    0 ACTIVE

172.16.1.2      172.16.2.2      QM_IDLE              1    0 ACTIVE

172.16.1.2      172.16.3.2      QM_IDLE              3    0 ACTIVE

Yet Spoke 1 only has 2

172.16.1.2      172.16.3.2      QM_IDLE              1    0 ACTIVE

172.16.2.2      172.16.3.2      QM_IDLE              2    0 ACTIVE

Crypto config for all:

crypto isakmp policy 10
 authentication pre-share
crypto isakmp key P4ssw0rd address 172.16.0.0 255.255.0.0
!
crypto ipsec transform-set MyTransformSet esp-aes esp-sha-hmac
!
crypto ipsec profile MyProfile
 set transform-set MyTransformSet
!
interface Tunnel0
 tunnel protection ipsec profile MyProfile

Hub Tunnel Config

interface Tunnel0

ip address 10.0.100.1 255.255.255.0

ip nhrp map multicast dynamic

ip nhrp network-id 1

tunnel source fa0/0

tunnel mode gre multipoint

Spoke 1 Tunnel Config

!

interface FastEthernet0/0

ip address 172.16.3.2 255.255.255.0

duplex auto

speed auto

!

interface Tunnel0

ip address 10.0.100.2 255.255.255.0

no ip redirects

ip nhrp map 10.0.100.1 172.16.1.2

ip nhrp map multicast 172.16.1.2

ip nhrp network-id 1

ip nhrp nhs 10.0.100.1

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel protection ipsec profile MyProfile

Spoke 2 Tunnel Config

!

interface FastEthernet0/0

ip address 172.16.2.2 255.255.255.0

duplex auto

speed auto

!

interface Tunnel0

ip address 10.0.100.3 255.255.255.0

no ip redirects

ip nhrp map 10.0.100.1 172.16.1.2

ip nhrp map multicast 172.16.1.2

ip nhrp network-id 1

ip nhrp nhs 10.0.100.1

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel protection ipsec profile MyProfile

Everyone's tags (2)
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

DMVPN ISAKMP SA Question

SRC and DST IP addresses indicate who was originator and who was responder. They do not represent socket information (in the traditional sense).

You might get duplicate IKE sessions in couple of scenarios, the most common are.

1) Negotiation started from both ends at "same time".

2) Renegotiation of IKE.

What is odd to me is that you seem to have session initiated and responsed by the hub.

What I would do is add:

- ip nhrp server-only (on hub, provided this is not a ASR)

- DPDs (on all devices).

We makes sure that hub does not initiate anything in NHRP and that unneeded/defunct sessions are torn down eventually.

3 REPLIES
Cisco Employee

DMVPN ISAKMP SA Question

SRC and DST IP addresses indicate who was originator and who was responder. They do not represent socket information (in the traditional sense).

You might get duplicate IKE sessions in couple of scenarios, the most common are.

1) Negotiation started from both ends at "same time".

2) Renegotiation of IKE.

What is odd to me is that you seem to have session initiated and responsed by the hub.

What I would do is add:

- ip nhrp server-only (on hub, provided this is not a ASR)

- DPDs (on all devices).

We makes sure that hub does not initiate anything in NHRP and that unneeded/defunct sessions are torn down eventually.

New Member

DMVPN ISAKMP SA Question

Thanks Marcin,

I have looked at a few DMVPN's in Production and they have similar ISAKMP SAs in their table. So it is expected behaviour and I was thinking in terms of a traditional socket.

One more question. Why does the HUB not initiate sessions. What if you have networks and hosts behind the Hub that need to reach networks on the SpokeS?

Cisco Employee

DMVPN ISAKMP SA Question

DMVPN's hub (in typical configuration), does not contain information about endpoints (unlike spokes who have statically configured NHS and NHRP mapping), it only learns about those during NHRP registration exchnage.

So there should not be a need/possibility for hub to initiate IKE sessions (hence additional enforcement of "ip nhrp server-only").

Now, what can happen is that IKE renegotiation is not triggered by spoke on time and hub tries to initiate a rekey. It typically should not happen.

DMVPN is routing based VPN, hub will always follow routnig to determine where to send traffic, typically it will send traffic out it's default route where it will be dropped (in situation you describe).

A few best practices:

- Lower NHRP holdtime

- Configure MTU and adjust MSS.

- If you're running ISR G2, and it's a setup "for the future":

http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html

AES and SHA are still acceptable, but you migh consider kicking it up an notch ... ;-)

1099
Views
4
Helpful
3
Replies