We have a stable P2P GRE + IPSec configuration with multiple spokes using rsa-signatures for ISAKMP authentication, and EIGRP as the routing protocol. We are transitioning to an mGRE configuration (DMVPN). The P2P GRE tunnel interfaces are administratively shutdown, the crypto maps on the physical interfaces have been removed, and the crypto database has been cleared.
When we bring up the mGRE tunnel interfaces (hub and spoke), we are able to complete ISAKMP phase I and II (briefly). However, ~ 1-1/2 minutes later, we see a debug message on the hub, such as:
Jul 21 13:56:49.601 EDT: IPSEC(cleanup_tun_decap_oce): unlock and null out Tunnel0 tun_decap_oce 86742E48 from ident 86FB990C
... and then the IPSec SAs are deleted, the tunnel comes down, IKE_PHASE2_DEL and IKE_PHASE1_DEL messages are generated, and we start over with ISAKMP phase I negotiation.
Anyone know what the "oce" stands for?
Debug (ISAKMP & IPSec) Highlights
Jul 21 13:55:13.188 EDT: ISAKMP:(2597):SA authentication status: authenticated Jul 21 13:55:13.236 EDT: ISAKMP:(2597):Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE Jul 21 13:55:13.356 EDT: IPSEC(create_sa): sa created, Jul 21 13:55:13.356 EDT: IPSEC(create_sa): sa created, Jul 21 13:55:13.356 EDT: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP . Peer <spoke-physical-ip>:500 Id: spoke.domain.null Jul 21 13:55:13.356 EDT: %DMVPN-7-CRYPTO_SS: Tunnel0-<hub-physical-ip> socket is UP Jul 21 13:55:13.700 EDT: ISAKMP:(2597):Old State = IKE_QM_R_QM2 New State = IKE_QM_PHASE2_COMPLETE Jul 21 13:56:49.601 EDT: IPSEC(cleanup_tun_decap_oce): unlock and null out Tunnel0 tun_decap_oce 86742E48 from ident 86FB990C Jul 21 13:56:49.601 EDT: IPSEC(delete_sa): deleting SA, Jul 21 13:56:49.601 EDT: IPSEC(delete_sa): deleting SA, Jul 21 13:56:49.601 EDT: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is DOWN. Peer <spoke-physical-ip>:500 Id: spoke.domain.null Jul 21 13:56:49.601 EDT: ISAKMP:(2597):Input = IKE_MESG_FROM_IPSEC, IKE_PHASE2_DEL Jul 21 13:56:49.605 EDT: ISAKMP:(2597):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
Note: A more complete debug output is attached.
General Observations (sh crypto isakmp sa, sh crypto ipsec sa)
ISAKMP SA reaches a state of QM_IDLE, and a status of ACTIVE. However, the SA is deleted and a new one is spawned within ~ minute.
IPSec SAs are negotiated on the hub and spoke. However, only the spoke has packet encaps, and only the hub has decaps. Wireshark confirms that the hub is not placing any ESP packets on the wire. The IPSec SAs are deleted, and new ones are spawned every ~1-1/2 minutes.
Re: mGRE tunnel SAs negotiated, but don't survive.
We've resolved the issue, and learned a lesson.
We were migrating from a P2P GRE to mGRE configuration. In doing so, we defined new tunnel interfaces for mGRE, and shutdown the P2P tunnel interfaces. We migrated configuration parameters we wished to retain, including the "tunnel key". We assumed erroneously, that we could do so given that the P2P tunnels were administratively shutdown. NOT!
On a hunch, we shutdown the mGRE tunnel interfaces, modified the tunnel key to a value different than that configured on the shutdown P2P tunnel interfaces, and then brought the mGRE interfaces out of shutdown. The tunnel came up, stayed up, NHRP registration took place, routes were exchanged, and we breathed a sigh of relief.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...