A lab IOS XE tunnel to a Google Cloud HA VPN gateway passes traffic for a while, then both IPsec SAs drop at the first rekey and traffic stops. Ping to the gateway's public address still works. What should be compared?
Select an answer to reveal the explanation.
Short Explanation
The first conversation worked, and the renewal used a different script. You compare the IPsec lifetime and the PFS setting with the HA VPN tunnel, because the public address still answers ping. BGP and OSPF do not run the rekey.
Full Explanation
Traffic that works and then dies at the first rekey points at a phase-2 parameter the initial SA tolerated and the renegotiation does not. Compare the IPsec lifetime and the PFS group on the IOS XE router with the HA VPN tunnel configuration. A mismatch there drops the new SA while the gateway's public address still answers ping, because ping does not need the tunnel. The BGP ASN is unrelated to rekey. Cloud Router may drop its BGP session because the tunnel died. The ASN was not the cause. Google Cloud VPN does not use an OSPF dead interval as a rekey timer, and the campus LAN timer is not consulted. This router is standalone IOS XE. It has no SD-WAN BFD poll interval driving IPsec. Exam caveat: fix the match and also confirm both HA VPN tunnels, not only the one that failed. A second tunnel with the same mismatch will fail on its own rekey. Operational check: after the lifetime and PFS match, the SA should rekey in place and show crypto ipsec sa should stay up through a forced rekey.