vrf Aware GET VPN with COOP KS

[pemasirid]

Hi,

We are trying to configure vrf aware GET VPN with COOP having primary and secondary key servers and also 3 GM routers. All GM routers we use are Cisco 888 and Key servers we use cisco 2911 routers. All GMs crypto maps have been applied into Vlan interface as there's no L3 interface on 888 routers.

Always members can form a tunnel with primary KS, we have configured redundancy with secondary key server and listed on each GM primary and secondary KS on GDOI group.

The issue we facing is that whenever we shutdown the primary or secondary servers the tunnel is not forming with available KS unless otherwise we mannually clear the crypto session. In another way when primary KS down it doest not fall back to secondary KS and no GM get registered. We have already played with all the timers such as DPD, SA lifetimes, GDOI rekey lifetime etc and also exchanging the keys (import/export) with KS and COOPs but there's no luck. We could see the following message was seen on both KS.

on KS1 (Primary)

Jun 19 08:52:23.071: %GDOI-3-COOP_KS_UNREACH: Cooperative KS 192.168.1.6 Unreachable in group test-g. IKE SA Status = Failed to establish

on KS2 (Secondary)

Jun 19 08:54:26.074: %GDOI-3-COOP_KS_UNREACH: Cooperative KS 192.168.1.3 Unreachable in group test-g. IKE SA Status = Failed to establish

192.168.1.3 is the primary KS and 192.168.1.6 is the secondary KS.

I captured attached debug output from 1 GM and secondary KS while I shutdonw the primary KS and also attached is our senario we were trying get work.

Also attached is the show output from both KSs when it form a tunnel with GM.

Appreciate if someone can advise us what exactly causing the above issue/error.

thanks in advance

[jonathan.ruano]

Hello,

From the 'debug-spoke.txt' file, I see the GM tries to register with the primary .3, then with the secondary .6. However, 'show cry gdoi gm' doesn't show any rekey info. Does it work in a normal scenario? Is the acl received at all ('show cry gdoi gm acl')?

I've been playing in the lab with a 2-ks, 3-gm unicast GETVPN scenario. As the documentation states, even though a GM may register to any of the available KS, only the primary KS sends rekeys. As output of 'show isakmp sa detail' on the GM, the SA with lifetime is the one used for register, whereas the other two - with no lifetime - are for rekeying (why there are two, I don't know).

If the primary KS becomes isolated (main interface is shutdown), the secondary one will eventually notice (via keepalives) and take over. As far as I've seen, only when it's time to rekey the new primary will act (unicast or multicast).

The GMs will not notice the outage until they try to re-register, in which case (if configured) will then try any other KS configured in their 'crypto gdoi group x'. For any rekeys before re-register time, they will just come from the new primary KS.

Last (but not least) is that, if IKE cannot be established between the KS (e.g. wrong credentials, pre-shared-key), both KS will ignore the other one and consider themselves as primary.

HtH,

Jon

[pemasirid]

Hi Jon,

Thanks for your time and reply.

When it was associated to primary KS, following was the output I can see on GM, Im wondering the ACL name recieved from KS as in our case it has to be ACL 101 and dont know how the below ACL comes and from where..?

SPOKE#sh crypto gdoi gm

Group Member Information For Group test-g:

    IPSec SA Direction       : Both

    ACL Received From KS     : gdoi_group_test-g_temp_acl

    Group member             : 10.10.10.2       vrf: VPN

       Registration status   : Registered

       Registered with       : 192.168.1.3

       Re-registers in       : 3345 sec

       Succeeded registration: 3

       Attempted registration: 5

       Last rekey from       : 0.0.0.0

       Last rekey seq num    : 0

       Unicast rekey received: 0

       Rekey ACKs sent       : 0

       Rekey Received        : never

I have tweat the following lifetime parameters to available minimum values:

SA lifetime, rekey lifetime and dead peer detection.

Out of above values I just want to know which should 1st expire to start registering the secondary KS when primary KS down and also want to know what are the current values taken..

Also I still could not find any clue related to below error massage I see on both KS each other..?

on KS1 (Primary)

Jun 19 08:52:23.071: %GDOI-3-COOP_KS_UNREACH: Cooperative KS 192.168.1.6 Unreachable in group test-g. IKE SA Status = Failed to establish

on KS2 (Secondary)

Jun 19 08:54:26.074: %GDOI-3-COOP_KS_UNREACH: Cooperative KS 192.168.1.3 Unreachable in group test-g. IKE SA Status = Failed to establish

Regards,