Dual-Hub DMVPN Design – BGP Adjacency Drops Despite Stable IPSec/NHRP

[bravealikhan]

Hi everyone,

We’re running a dual-hub DMVPN (Phase 3) environment on Cisco ISR 4400 routers (IOS-XE 17.9.x).
All spoke routers are dual-homed — each forms tunnels to both DC-A and DC-B hubs.

Recently, several spokes lost their BGP peering with DC-A, while DC-B remains completely stable.
DMVPN tunnels are fully up — NHRP and IPSec sessions are established, and the hub shows all spoke entries in the NHRP database.

However, when checking BGP, the spoke neighbors under DC-A:

• Establish successfully, exchange a few updates,

• Then disconnect within a few seconds,

• And immediately try to re-establish again (continuous flap).

There were no configuration changes or maintenance activities prior to this behavior — it started suddenly across multiple spokes.

We’ve verified and cross-checked both hubs:
DMVPN tunnel configuration identical (including tunnel vrf, protection ipsec profile, NHRP parameters).
IPSec and IKEv2 profiles match on both hubs.
MTU and TCP MSS settings are correct.
ACLs and NAT rules are consistent
Route-reflector setup, VRFs, and BGP policies are identical.

The following observations were made:

• show dmvpn confirms all spoke tunnels UP and stable on DC-A.

• show ip bgp all summary shows dynamic neighbors forming under the DMVPN subnet, but each session drops after a few seconds.

• No related syslog or crypto session drops.

• BGP and NHRP timers are default.

• DC-B hub continues to maintain BGP peering with the same spokes without any issue.

Has anyone seen this before — DMVPN tunnels up but dynamic BGP peers continuously resetting on one hub only?

Any suggestions, insights, or similar experiences would be greatly appreciated.

Thanks

[M02@rt37]

Hello @bravealikhan 

Do telnet x.x.x.x179 command from spokes to hub A. Share result please.

Also, since you modify nothing on your side, if the WAN path changes or MTU decreases, IPsec may continue to working while protocols relying on TCP, as your BGP, experience resets.

"MTU and TCP MSS settings are correct"

Do you perform an MSS clamp on the tunnel interface ?

[paul driver]

Hello
Have you verified that your underlay connection stable ?
Also can you confirm if your overlay tunnel NHRP peering is either iBGP/eBGP 
you are using static or dynamic bgp peering

[bravealikhan]

Hi - follow are some details:

• DMVPN underlay and NHRP sessions are fully stable — all spokes show as up on both hubs.

• IPSec/IKEv2 tunnels are established and remain stable without rekeying or drops.

• BGP is running as dynamic iBGP over the DMVPN overlay.

• The issue occurs only on one hub, while the second hub remains completely stable using identical configuration and policies.

• Telnet to TCP/179 from spokes toward the affected hub fails to complete, even though the tunnel is up.

• Path MTU testing (DF-bit pings) shows fragmentation or loss beyond a certain payload size, while the second hub passes all tests.

• MTU and MSS settings are identical and correct on both hubs (ip tcp adjust-mss 1360, ip mtu 1400).

• Cisco TAC observed asymmetric ESP (Encapsulating Security Payload) counters on the affected hub — significantly more packets encrypted than decrypted, suggesting possible one-way loss or path asymmetry at the underlay level.

• The ISP confirmed no congestion, filtering, or interface errors on the access circuits, though inbound traffic for our public range may enter their network through multiple aggregation points, potentially introducing asymmetric return paths.

At this point, DMVPN and IPSec remain operational, but TCP sessions encapsulated within ESP never complete the full three-way handshake, causing dynamic BGP peers to flap on the affected hub only.

[bravealikhan · Accepted solution]

The issue has now been resolved. We discovered that the Hub Tunnel IP was also being advertised from one of the branch sites due to a static route configured there. As a result, DMVPN spokes were receiving the tunnel IP from both the Hub and that branch site. Removing the static route from the branch office has fully resolved the problem.

[M02@rt37]

Hello @bravealikhan 

Thanks a lot for your feedback.

[nicolesilvera]

BGP adjacency drops in a dual-hub DMVPN often occur despite stable IPSec/NHRP, usually due to next-hop reachability, BGP timers, or split-horizon issues. Even if tunnels are up, brief delays or route recalculations can cause flaps.

Quick checks:

• Ensure BGP next-hops are always reachable from spokes.

• Tune BGP keepalive/hold timers for DMVPN latency.

• Verify NHRP resolution stability and hub split-horizon settings.

• Monitor CPU/IPSec for transient delays.

Stable IPSec alone doesn’t guarantee BGP stability; adjusting timers and next-hop handling usually resolves this.