I85PREP
⌘ K
Cisco 300-730 SVPN study materials
Cisco 300-730 SVPN study resources

IPsec VTI with BGP Flapping at Rekey Time

Cisco 300-730 SVPN · Put your knowledge to work in context.

All case studies

IPsec VTI with BGP Flapping at Rekey Time

Two ASR 1001-X routers build an IPsec VTI tunnel with IKEv2 between AS 65001 and AS 65002. The design uses BGP over the tunnel with hold time 90 and keepalive 30. The tunnel has ip mtu 1400 and ip tcp adjust-mss 1360. Every 60 minutes, BGP resets for 5–10 seconds; show crypto ikev2 sa shows the IKE SA rekey at 3600 seconds, and show crypto ipsec sa shows IPsec SA rekey at 3600 seconds. The underlay is a 1 Gbps provider handoff with a 1500-byte MTU; ICMP is filtered by the provider. After the last maintenance, one side was moved behind NAT, and the problem became more frequent. The customer wants BGP to stay up and asks whether to change BGP timers, IKEv2 rekey, or MTU settings.

1. How would you determine whether the BGP resets are caused by IKEv2 rekey, IPsec rekey, or an MTU/PMTUD problem?

Read the worked answer

Correlate the BGP reset time with the crypto timers and logs. Because both IKEv2 and IPsec SA lifetimes are 3600 seconds, the hourly reset is suspicious, but the NAT change makes MTU/PMTUD a strong secondary possibility.

Steps:

  1. On both routers, check show crypto ikev2 sa detailed and show crypto ipsec sa before and after the reset. If the IKE SA disappears and is rebuilt, focus on IKEv2 rekey or DPD. If the IKE SA stays up but the IPsec SA is deleted/rebuilt, focus on IPsec rekey.
  2. Enable debug crypto ikev2 and debug crypto ipsec in a maintenance window, or use show logging to look for IKEv2 rekey, DPD, NAT-T, and SA deletion messages at the reset time.
  3. Check BGP logs: show log | include BGP and show ip bgp summary. A hold-timer expiry means keepalives were lost; a BGP notification or route change means a different cause.
  4. Test MTU with ping <peer> size 1400 df-bit and larger sizes. ICMP is filtered, so PMTUD blackholes will not show up as ICMP unreachable; large BGP updates or full tables can be dropped while small keepalives pass.
  5. Because one side is behind NAT, confirm UDP 4500 is stable and that NAT-T is detected (show crypto ikev2 sa detailed shows NAT-T). A NAT mapping timeout can drop IKEv2/ESP and trigger BGP resets.

2. What changes would you recommend to stabilize BGP, and in what order should they be applied?

Read the worked answer

Do not start by lengthening BGP timers; that hides the problem and slows convergence. First determine whether the failure is crypto rekey or MTU, then make the smallest change that addresses the root cause.

Recommended order:

  1. Fix MTU/PMTUD exposure: verify the tunnel MTU against the real encapsulation and lower it if needed, keep ip tcp adjust-mss 1360, and test with DF-bit pings. Because the provider filters ICMP, ensure the tunnel MTU is conservative enough that large BGP updates do not rely on PMTUD. This is the first change if large packets correlate with the resets.
  2. Stabilize NAT-T: confirm crypto ikev2 nat keepalive is configured on the spoke side and that UDP 4500 is permitted in both directions. If the NAT mapping times out, keepalives prevent the mapping from expiring.
  3. Align or separate rekey timers: if IKEv2 and IPsec rekeys coincide every hour and the devices cannot make-before-break cleanly, adjust the IPsec SA lifetime or IKEv2 rekey interval so they do not overlap. Do not disable rekey; that weakens the security posture.
  4. Only then consider BGP timers. If the root cause is a brief crypto rekey, BGP hold time 90 should survive 5–10 seconds; if it does not, the outage is longer than reported. Tuning BGP timers without fixing crypto or MTU will just move the failure.
  5. Validate by running for at least two rekey cycles and confirming show ip bgp summary stays up and show crypto ikev2 sa/show crypto ipsec sa rekey cleanly.