09-18-2013 03:10 AM - edited 02-21-2020 07:09 PM
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
Solved! Go to Solution.
09-18-2013 05:00 AM
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.
09-18-2013 05:00 AM
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.
09-19-2013 04:31 PM
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?
09-19-2013 11:51 PM
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 ... ;-)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide