GETVPN overlay upon FTTC router issue

[Ian Terry]

Hi 

We have a private DSL/FTTC infrastructure and we are currently testing FTTC upon Cisco 887 platforms - I should also add that we cannot use VDSL as the UK carrier doesn't allow this, so the IP connection utilises FastEthernet0 for physical connectivity of the carrier. the Fastethernet0 port is configured with an access Vlan and the VLaN includes the PPPoE client configuration that points to the Dialer0

The IP works fine and communication is achieved to the rest of the network 

The issue that we have is when we try and launch GETVPN, we have an extensive GETVPN infrastructure and the GM configurations are pretty much the same throughout with the exception of the local GM IP addressing.

When we attempt to use GETVPN in conjunction with our FTTC Ethernet (non VDSL) configuration, the GM registration fails

Is there a limitation within Cisco 887 for GETVPN services, or GETVPN cannot run over vlan? All other configurations including DSL, Cisco 2921 routers etc work fine.

Here is a sample from the debugs that we have running:

Dec  2 15:51:15.035: ISAKMP:(2041):Sending an IKE IPv4 Packet.

Dec  2 15:51:15.035: GDOI:GM REGISTRATION:EVT:(2041:1000):GDOI: GDOI ID sent successfully

Dec  2 15:51:15.035: ISAKMP:(2041):Node 560096193, Input = IKE_MESG_INTERNAL, IKE_INIT_GDOI

Dec  2 15:51:15.035: ISAKMP:(2041):Old State = GDOI_GM_AWAIT_SA  New State = GDOI_GM_AWAIT_SA

Dec  2 15:51:15.039: ISAKMP:(2041):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE

Dec  2 15:51:15.039: ISAKMP:(2041):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Dec  2 15:51:25.034: ISAKMP:(2041): retransmitting phase 2 GDOI_IDLE       560096193 ...

Dec  2 15:51:25.034: ISAKMP (2041): incrementing error counter on node, attempt 1 of 3: retransmit phase 2

Dec  2 15:51:25.034: ISAKMP (2041): incrementing error counter on sa, attempt 1 of 3: retransmit phase 2

Dec  2 15:51:25.034: ISAKMP:(2041): retransmitting phase 2 560096193 GDOI_IDLE

Dec  2 15:51:25.034: ISAKMP:(2041): sending packet to 10.220.55.129 my_port 848 peer_port 848 (I) GDOI_IDLE

Any thoughts are most welcome

[Steve11]

Hi Ian,

Did you get this resolved? I'm coming with a very similar issue on IOS 15.2.4(M9) on CISCO887VA-SEC-K9 platform. Interesting this issue doesn't appear when using 15.4 code on C887VA platforms but I'm restricted to 15.2 based on the DRAM of these older routers.

001292: *Feb 5 2016 09:37:34.905 GMT: ISAKMP:(2005):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
001293: *Feb 5 2016 09:37:34.905 GMT: ISAKMP:(2005):Old State = IKE_I_MM4 New State = IKE_I_MM5

001294: *Feb 5 2016 09:37:34.937 GMT: ISAKMP (2004): received packet from X.X.X.X dport 848 sport 848 WAN-VRF (I) MM_NO_STATE
001295: *Feb 5 2016 09:37:44.905 GMT: ISAKMP:(2005): retransmitting phase 1 MM_KEY_EXCH...
001296: *Feb 5 2016 09:37:44.905 GMT: ISAKMP (2005): incrementing error counter on sa, attempt 1 of 3: retransmit phase 1
001297: *Feb 5 2016 09:37:44.905 GMT: ISAKMP:(2005): retransmitting phase 1 MM_KEY_EXCH
001298: *Feb 5 2016 09:37:44.905 GMT: ISAKMP:(2005): sending packet to X.X.X.X my_port 848 peer_port 848 (I) MM_KEY_EXCH
001299: *Feb 5 2016 09:37:44.905 GMT: ISAKMP:(2005):Sending an IKE IPv4 Packet

001300: *Feb 5 2016 09:37:54.905 GMT: ISAKMP:(2005): retransmitting phase 1 MM_KEY_EXCH...
001301: *Feb 5 2016 09:37:54.905 GMT: ISAKMP (2005): incrementing error counter on sa, attempt 2 of 3: retransmit phase 1

[Ian Terry]

Hi Steven, 

Did get the GETVPN to work over VLAN but found that the internal ethernet0 could not handle the throughput when attempting anything relatively intensive. 

From memory I tried different versions of code and got different results, similar to you by the sound of it. Eventually spoke to Cisco and (at that time) they confirmed that it wasn't a support feature to run GETVPN over VLAN. So it worked to a point but not stable enough for a production environment that we had. 

I suspect you are correct when you highlight the DRAM shortfall as clearly that would be used in processing but the only option was to upgrade! 

Sorry that I can't be more help

Ian

[Steve11]

Thanks for getting in touch Ian much appreciated.

We are using the 887 as the vdsl modem and find no issues with the throughput or reliability, at least for the C887VA platform, this is the first cisco887va-sec I've tested on vdsl with bt wholesale. By the sounds of it skipping the bt vdsl modem is doing us a favour.

I spoke to TAC earlier and I'm waiting to hear back but essentially the problem we have is the key server is fragmenting the payload that contains the keyserver's cert, and the 887 isn't seeing the first fragment, therefor unable to reassemble the packet.  Seemingly it's just going missing, and it's not just the crypto, even a fragmented icmp can't be reassembled.

If I upgrade the code to 15.3 it works fine. Problem is halfway through the 15.3 train the dram requirement doubles so the max we can goto is 15.3.3M3 which is rather old.

I'll update this thread with their response once I get one but it's looking like a dram upgrade is going to be required to allow us to go to the latest 15.3 image.

thanks again