VTI Tunnels lagging problem

Unanswered Question
May 25th, 2012

Hello there,

I have some problem with IPSec VTI tunnels, here is my configuration.

There is a hub and spoke network with to hubs 3945E routers and spoke routers mostly 881 configured with two VTI tunnels,

with each hub router, and running eigrp over it. There are about 12 spoke routers.

At some point VTI tunnels started lagging, and some tunnels require "shut, no shut" command to make them work again. It seems

that when tunnel lag happens, first phase is up, and it is failing to negotiate second phase. Here is config and debug:

!

interface GigabitEthernet0/2.11

description WAN

encapsulation dot1Q 11

ip address x.x.x.x 255.255.255.252

!

crypto isakmp policy 502

encr 3des

authentication pre-share

group 2

!

crypto isakmp key key address y.y.y.y no-xauth

!

crypto ipsec transform-set AES256-SHA esp-aes 256 esp-sha-hmac

!

crypto ipsec profile AES256-SHA

set transform-set AES256-SHA

!

interface Tunnel999

description TUNNEL

ip vrf forwarding ipsec.vrf

ip address 1.1.1.1 255.255.255.252

ip mtu 1400

ip virtual-reassembly in

ip tcp adjust-mss 1300

delay 50

tunnel source x.x.x.x

tunnel mode ipsec ipv4

tunnel destination y.y.y.y

tunnel path-mtu-discovery

tunnel protection ipsec profile AES256-SHA

!

ip route y.y.y.y 255.255.255.255 c.c.c.c name to.branch

!

007563: May 24 17:26:57.380 GMT+4: ISAKMP:(1500): processing HASH payload. message ID = 2213601260

007564: May 24 17:26:57.380 GMT+4: ISAKMP:(1500): processing SA payload. message ID = 2213601260

007565: May 24 17:26:57.380 GMT+4: ISAKMP:(1500):Checking IPSec proposal 1

007566: May 24 17:26:57.380 GMT+4: ISAKMP: transform 1, ESP_AES

007567: May 24 17:26:57.380 GMT+4: ISAKMP:   attributes in transform:

007568: May 24 17:26:57.380 GMT+4: ISAKMP:      encaps is 1 (Tunnel)

007569: May 24 17:26:57.380 GMT+4: ISAKMP:      SA life type in seconds

007570: May 24 17:26:57.380 GMT+4: ISAKMP:      SA life duration (basic) of 3600

007571: May 24 17:26:57.380 GMT+4: ISAKMP:      SA life type in kilobytes

007572: May 24 17:26:57.380 GMT+4: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0

007573: May 24 17:26:57.380 GMT+4: ISAKMP:      authenticator is HMAC-SHA

007574: May 24 17:26:57.380 GMT+4: ISAKMP:      key length is 256

007575: May 24 17:26:57.380 GMT+4: ISAKMP:(1500):atts are acceptable.

007576: May 24 17:26:57.380 GMT+4: ISAKMP:(1500): IPSec policy invalidated proposal with error 1024

007577: May 24 17:26:57.380 GMT+4: ISAKMP:(1500): phase 2 SA policy not acceptable! (local x.x.x.x remote y.y.y.y)

007578: May 24 17:26:57.380 GMT+4: ISAKMP: set new node -598356966 to QM_IDLE

007579: May 24 17:26:57.380 GMT+4: ISAKMP:(1500):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3 spi 537931020, message ID = 3696610330

007622: May 24 17:27:12.425 GMT+4: ISAKMP:(1500): seq. no 0x2D328AC4

007623: May 24 17:27:12.425 GMT+4: ISAKMP:(1500): sending packet to y.y.y.y my_port 500 peer_port 500 (I) QM_IDLE

007624: May 24 17:27:12.425 GMT+4: ISAKMP:(1500):Sending an IKE IPv4 Packet.

007625: May 24 17:27:12.425 GMT+4: ISAKMP:(1500):purging node -1313452134

007626: May 24 17:27:12.429 GMT+4: ISAKMP (1500): received packet from y.y.y.y dport 500 sport 500 Global (I) QM_IDLE

007627: May 24 17:27:12.429 GMT+4: ISAKMP: set new node 587467273 to QM_IDLE

007628: May 24 17:27:12.429 GMT+4: ISAKMP:(1500): processing HASH payload. message ID = 587467273

007629: May 24 17:27:12.429 GMT+4: ISAKMP:(1500): processing NOTIFY DPD/R_U_THERE_ACK protocol 1 spi 0, message ID = 587467273, sa = 0x22196288

007630: May 24 17:27:12.429 GMT+4: ISAKMP:(1500): DPD/R_U_THERE_ACK received from peer y.y.y.y, sequence 0x2D328AC4

007631: May 24 17:27:12.429 GMT+4: ISAKMP:(1500):deleting node 587467273 error FALSE reason "Informational (in) state 1"

007632: May 24 17:27:12.429 GMT+4: ISAKMP:(1500):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY

007633: May 24 17:27:12.429 GMT+4: ISAKMP:(1500):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

007650: May 24 17:27:25.370 GMT+4: ISAKMP:(1499):purging node -1082779481

007651: May 24 17:27:27.257 GMT+4: ISAKMP (1500): received packet from y.y.y.y dport 500 sport 500 Global (I) QM_IDLE

007652: May 24 17:27:27.257 GMT+4: ISAKMP: set new node 1075838180 to QM_IDLE

007653: May 24 17:27:27.257 GMT+4: ISAKMP:(1500): processing HASH payload. message ID = 1075838180

007654: May 24 17:27:27.257 GMT+4: ISAKMP:(1500): processing SA payload. message ID = 1075838180

007655: May 24 17:27:27.257 GMT+4: ISAKMP:(1500):Checking IPSec proposal 1

007656: May 24 17:27:27.257 GMT+4: ISAKMP: transform 1, ESP_AES

007657: May 24 17:27:27.257 GMT+4: ISAKMP:   attributes in transform:

007658: May 24 17:27:27.257 GMT+4: ISAKMP:      encaps is 1 (Tunnel)

007659: May 24 17:27:27.257 GMT+4: ISAKMP:      SA life type in seconds

007660: May 24 17:27:27.257 GMT+4: ISAKMP:      SA life duration (basic) of 3600

007661: May 24 17:27:27.257 GMT+4: ISAKMP:      SA life type in kilobytes

007662: May 24 17:27:27.257 GMT+4: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0

007663: May 24 17:27:27.257 GMT+4: ISAKMP:      authenticator is HMAC-SHA

007664: May 24 17:27:27.257 GMT+4: ISAKMP:      key length is 256

007665: May 24 17:27:27.257 GMT+4: ISAKMP:(1500):atts are acceptable.

007666: May 24 17:27:27.257 GMT+4: ISAKMP:(1500): IPSec policy invalidated proposal with error 1024

007667: May 24 17:27:27.257 GMT+4: ISAKMP:(1500): phase 2 SA policy not acceptable! (local x.x.x.x remote y.y.y.y)

007668: May 24 17:27:27.257 GMT+4: ISAKMP: set new node -1250799219 to QM_IDLE

007669: May 24 17:27:27.257 GMT+4: ISAKMP:(1500):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3 spi 537931020, message ID = 3044168077

007670: May 24 17:27:27.257 GMT+4: ISAKMP:(1500): sending packet to y.y.y.y my_port 500 peer_port 500 (I) QM_IDLE

007671: May 24 17:27:27.257 GMT+4: ISAKMP:(1500):Sending an IKE IPv4 Packet.

007672: May 24 17:27:27.257 GMT+4: ISAKMP:(1500):purging node -1250799219

007673: May 24 17:27:27.257 GMT+4: ISAKMP:(1500):deleting node 1075838180 error TRUE reason "QM rejected"

007674: May 24 17:27:27.257 GMT+4: ISAKMP:(1500):Node 1075838180, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH

007675: May 24 17:27:27.257 GMT+4: ISAKMP:(1500):Old State = IKE_QM_READY  New State = IKE_QM_READY

007676: May 24 17:27:30.922 GMT+4: ISAKMP: DPD received KMI message.

007677: May 24 17:27:30.922 GMT+4: ISAKMP: set new node 1679854850 to QM_IDLE

007678: May 24 17:27:30.922 GMT+4: ISAKMP:(1500):Sending NOTIFY DPD/R_U_THERE protocol 1 spi 531655060, message ID = 1679854850

007679: May 24 17:27:30.922 GMT+4: ISAKMP:(1500): seq. no 0x2D328AC5

007680: May 24 17:27:30.922 GMT+4: ISAKMP:(1500): sending packet to y.y.y.y my_port 500 peer_port 500 (I) QM_IDLE

007681: May 24 17:27:30.922 GMT+4: ISAKMP:(1500):Sending an IKE IPv4 Packet.

007682: May 24 17:27:30.922 GMT+4: ISAKMP:(1500):purging node 1679854850

007683: May 24 17:27:30.926 GMT+4: ISAKMP (1500): received packet from y.y.y.y dport 500 sport 500 Global (I) QM_IDLE

007684: May 24 17:27:30.926 GMT+4: ISAKMP: set new node 717038199 to QM_IDLE

007685: May 24 17:27:30.926 GMT+4: ISAKMP:(1500): processing HASH payload. message ID = 717038199

007686: May 24 17:27:30.926 GMT+4: ISAKMP:(1500): processing NOTIFY DPD/R_U_THERE_ACK protocol 1 spi 0, message ID = 717038199, sa = 0x22196288

007687: May 24 17:27:30.926 GMT+4: ISAKMP:(1500): DPD/R_U_THERE_ACK received from peer y.y.y.y, sequence 0x2D328AC5

007688: May 24 17:27:30.926 GMT+4: ISAKMP:(1500):deleting node 717038199 error FALSE reason "Informational (in) state 1"

007689: May 24 17:27:30.926 GMT+4: ISAKMP:(1500):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY

007690: May 24 17:27:30.926 GMT+4: ISAKMP:(1500):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

IOS version on 3945E routers is c3900e-universalk9-mz.SPA.151-4.M4.bin.

There are some tunnels configures with 3DES encryption and I have noticed that they never lag.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
rizwanr74 Fri, 05/25/2012 - 15:08

Hi Franco,

Please remove those two highlighted lines and replace the "x" with your EIGRP process ID.

interface Tunnel999

description TUNNEL

ip vrf forwarding ipsec.vrf

ip address 1.1.1.1 255.255.255.252

ip mtu 1400

ip virtual-reassembly in

ip tcp adjust-mss 1300

no ip split−horizon eigrp x

delay 50

tunnel source x.x.x.x

tunnel mode ipsec ipv4

tunnel destination y.y.y.y

tunnel path-mtu-discovery

tunnel protection ipsec profile AES256-SHA

Please let me know, if this helps.

thanks

frpolosr1 Sat, 05/26/2012 - 06:27

Hello,

Thank you for helping,

If I disable these features won't i have problems with fragmentation ?

rizwanr74 Sat, 05/26/2012 - 08:07

These both lines do the same things one is being explicitly value is defined and other is set for auto-discovery, however when it comes tunnel interface all you need is to set the mtu size to 1400.

one:  ip tcp adjust-mss 1300

two:  tunnel path-mtu-discovery

Now when an additional command, which you need to disable split-horizon on eigrp and the "x" is your process ID, which you need for spoke-to-spoke communication, to pass via the hub.

no ip split−horizon eigrp x

"If I disable these features won't i have problems with fragmentation ?"

Which is taken care by setting mtu size to 1400.

Now you set the "ip tcp adjust-mss 1380" on your physical interfaces facing toward your internal switch.

Have you tried it?

thanks

Message was edited by: Rizwan Mohamed

rizwanr74 Sun, 05/27/2012 - 07:56

"crypto isakmp key key address y.y.y.y no-xauth"

I assume, you have posted your hub configuration on your very first post above on this thread.

Please change it to as shown below.

crypto isakmp key yourkey-goes-here address 0.0.0.0 0.0.0.0

crypto isakmp nat keepalive 20

On your tunnel on the hub.

interface Tunnel999

tunnel mode gre multipoint

It is better you post your hub and spoke config as I only see the pieces of the picture on this thread.

Please post as an attachement.

thanks

frpolosr1 Sun, 05/27/2012 - 09:09

Hello,

All tunnels are site to site, with very simple config. I think if I implement this command "

crypto isakmp key yourkey-goes-here address 0.0.0.0 0.0.0.0 " I will lost my remoute VPN connections.

What about this command as i know it is implemented in DMVP hub router " tunnel mode gre multipoint " ?

rizwanr74 Mon, 05/28/2012 - 08:29

Hi Franco,

"crypto isakmp key yourkey-goes-here address 0.0.0.0 0.0.0.0 " I will lost my remoute VPN connections."

Assume, that your hub-site router will accept VTI tunnel neigtiation to 100 or 200 sites, in which case you would have to create 200 static-tunnel configuration but the command I showed you replaces to one.

"What about this command as i know it is implemented in DMVP hub router " tunnel mode gre multipoint " ?"

If you choose go along with static tunnel for each and every spoke-router then you would not need multipoint.

Hope that answers your question.

thanks

Actions

Login or Register to take actions

This Discussion

Posted May 25, 2012 at 1:40 PM
Stats:
Replies:8 Avg. Rating:
Views:1039 Votes:0
Shares:0
Tags: tunnels, vti
+

Related Content

Discussions Leaderboard