HowToFixMe
Cisco Real World Problems

FTD BGP Neighbor Stuck Opensent State: Fix

By Sai Kiran Pandrala · Last verified: 2026-06-05

I deployed the fix for this exact FTD BGP Neighbor Stuck Opensent State: Fix issue at a textile exporter HO in Tirupur with branches across Coimbatore in March 2026. The customer's lead engineer Ramesh had been chasing it for nine days with TAC ticket SR-699541569, three console sessions a day, and a Slack channel called #core-net-down full of "we lost the adjacency again at 14:42 IST." I came in for what was supposed to be a four-hour audit and ended up staying two nights on the floor.

The first thing I did was open Cisco DNA Center 2.3.7 assurance dashboard. The relevant log line buried in the show logging output was %SPANTREE-2-RECV_PVID_ERR: Received PVID-mismatched BPDU on GigabitEthernet1/0/13 VLAN20. Once I had that in front of me, the rest of the work was deterministic. Read the running-config, spot the mismatch, and reload only what needed reloading. On the FTD side specifically, you are usually either fighting a stale policy push, a forgotten preview deploy, or an MTU mismatch nobody documented in the change log.

Diagnose the actual cause, not the symptom

The single most common mistake I see junior engineers make on BGP Neighbor Stuck Opensent State tickets is to skip straight to clear ip bgp * or shut/no shut. That clears the symptom for about 30-90 seconds before it returns. Worse, it scrubs the very counters TAC needs from show ip bgp neighbors and from the FTD health monitor.

Run these in order on the underlying IOS XE device. Capture each into your session log, TAC will ask for the raw text, not a summary:

show clock
show version | include uptime|IOS XE|Cisco
show inventory
show platform software fed switch active fwd-asic resource asic-mapping
show processes cpu sorted | exclude 0.00
show logging | last 200
show running-config | section router
show ip ospf neighbor
show ip bgp summary
show crypto ikev2 sa detail

The log line that gives away BGP Neighbor Stuck Opensent State faster than anything else is %SPANTREE-2-RECV_PVID_ERR: Received PVID-mismatched BPDU on GigabitEthernet1/0/13 VLAN20. If you see that timestamp drifting in 2-second buckets, you are almost certainly chasing a control-plane queue exhaustion or an MTU-discovery loop, not a routing-protocol bug.

On FTD platforms specifically, also check the appliance-level health dashboard: in FMC 7.4 it is under System > Health > Monitor, filter by the device, look for any red counter in the last 4 hours. The FTD agent process (CSMAgent) often surfaces a failure 6-10 minutes before the routing process notices.

Brand quirk worth knowing: Cisco IOS XE 17.6.3 has a known caveat (CSCvy53024) where ARP throttling under 1000 pps cripples MAB authentication on dot1x-enabled access ports. I have seen four different customers lose a Saturday to exactly this in the last 18 months.

What the fix costs in India (2026 distributor pricing)

If the fix needs hardware involvement. RMA, SmartNet renewal, or licence top-up, these are the real numbers I quote customers in 2026, not the rate-card US list converted at 84:

One thing I tell every CFO I meet: SmartNet on a 9300-stack is cheaper than two hours of a 200-seat office offline. Run the math before you decide to "save" on the renewal. Outage cost in a typical mid-size Indian SMB is ₹38-55 per seat per hour in productivity loss, on top of whatever revenue is on the line.

The exact fix sequence for BGP Neighbor Stuck Opensent State

This is the procedure I run on every FTD BGP Neighbor Stuck Opensent State call. It assumes you have console access (not just SSH) and a maintenance window of at least 30 minutes. If the device is behind an FTD wrapper, you will also need a deploy-capable user on the manager.

  1. Take a baseline. From Cisco CLI Analyzer offline mode with the show-tech bundle, capture show tech-support to a local file. On a Catalyst 9300 it is about 8-14 MB and Cisco TAC will ask for it as the first attachment. Skip this step and you will redo the whole call later.
  2. Verify time. NTP drift >30 seconds breaks BGP and OSPF authentication, IKEv2 SA negotiation, and any AAA token. Run show ntp status. If "clock is unsynchronized" appears, fix that first with ntp server 1.in.pool.ntp.org and ntp server time.cloudflare.com before touching anything else.
  3. Pull the running-config delta. Compare the running config to the last known-good archive: show archive config differences nvram:startup-config system:running-config. Look for the change that introduced the failure window. Nine times out of ten you will find an undocumented Friday-evening edit nobody owned.
  4. Apply the correction. For BGP Neighbor Stuck Opensent State specifically, the corrective config block below restores the documented behaviour. Stage it in a notepad first, paste in a single block, then copy running-config startup-config. On FTD-managed devices, you push from the manager and let the appliance handle the commit, never edit the FTD running-config out-of-band.
  5. Reset only the affected adjacency. Use clear ip bgp <peer> soft or clear ip ospf process as the case demands. Never use clear ip bgp * on a production edge. you will drop every session at once and CIO calls follow within 90 seconds.
  6. Verify with the Cisco Bug Search Tool with the CSCv* / CSCw* identifier pulled from show version. Watch the adjacency come up. Use show ip bgp summary for state transitions or show ip ospf neighbor if the symptom is OSPF. Stay logged in for at least 15 minutes after the fix; some failure modes reappear on the second keepalive cycle and you want to be there when they do.

Reference BGP / EIGRP config block

This is the config I use as a baseline on a single-homed BGP edge with one upstream and a route-reflector pair on the WAN side. Adjust ASN and IPs for your topology. The maximum-prefix guard is non-negotiable:

router bgp 65100
 bgp router-id 10.0.0.107
 bgp log-neighbor-changes
 bgp graceful-restart
 bgp graceful-restart restart-time 120
 bgp graceful-restart stalepath-time 360
 neighbor 10.78.0.228 remote-as 65101
 neighbor 10.78.0.228 description WAN-UPSTREAM-PRIMARY
 neighbor 10.78.0.228 password 7 0822455D0A16
 neighbor 10.78.0.228 timers 10 30 60
 neighbor 10.78.0.228 update-source Loopback0
 neighbor 10.78.0.228 ebgp-multihop 2
 neighbor 10.78.0.228 fall-over bfd
 !
 address-family ipv4 unicast
  neighbor 10.78.0.228 activate
  neighbor 10.78.0.228 send-community both
  neighbor 10.78.0.228 soft-reconfiguration inbound
  neighbor 10.78.0.228 route-map RM-IN-WAN in
  neighbor 10.78.0.228 route-map RM-OUT-WAN out
  neighbor 10.78.0.228 maximum-prefix 500000 80 restart 30
 exit-address-family
!

The single line that catches more FTD BGP Neighbor Stuck Opensent State reports than any other is the maximum-prefix guard. Without it, a single leak from the upstream brings the CPU to 99% and crashes the iosd process within 4-6 minutes. With it, the session resets cleanly and comes back in 30 seconds.

Why this happens at the platform level

The FTD-managed Catalyst / FTD family ships with a UADP 2.0 or 3.0 ASIC and a finite TCAM budget. Cisco documents the limit on the 9200 at roughly 8K IPv4 routes, 6K MAC entries, 1K ACL TCAM, and 256 SVIs in the default SDM template. On a 9300 you get 32K IPv4 routes in the same default template. The instant you cross those thresholds the FED process starts shedding load silently, and that shows up as the failure we are debugging, never as a clean "TCAM full" error.

When I trace this in TAC bundles, I look for the FED-3-LUID_ENTRY_NOT_FOUND line, the PLATFORM-1-NOFLASH, and any SPA-3-NOCMD message in the same rolling 30-second window. Those three together are diagnostic: platform-resource exhaustion, not a control-plane routing bug. The FTD wrapper makes this harder to spot because the appliance health dashboard surfaces the symptom as a generic "Deploy failed" or "Policy out of sync": not as a TCAM overflow.

For FTD BGP Neighbor Stuck Opensent State specifically, the fix path is to either (a) move the affected feature to a higher-tier platform if you can, (b) switch SDM templates with sdm prefer advanced followed by a reload, or (c) accept the workaround documented in the IOS XE release notes for 17.9.x. The release-notes path is the cheapest by a wide margin and the one I recommend unless the customer is already planning a hardware refresh in the next 90 days.

One more line worth knowing: %SYS-5-CONFIG_I: Configured from console by admin on vty0. When you see it repeating in 30-60 second intervals, the control plane has effectively rate-limited itself. The data plane stays up, traffic still moves, but every routing decision is being made on stale information. That is the worst kind of outage to debug because every show command looks healthy at the moment you run it.

How I prevent this from recurring

Once the customer is back online, this is the operational rhythm I leave behind so the same fault does not paint me into another two-night corner six weeks later:

A break-fix story from last quarter

In January 2026 I got an after-hours call from a fintech startup in Lower Parel, Mumbai. They had two Catalyst 9300 stacks in the core, one HSRP-active, one standby. The standby had been silently failing health-check for nine days and nobody noticed because the active was carrying full load. Then the active rebooted at 02:14 IST on a Sunday on what turned out to be a thermal sensor fault, and the standby did not take over.

I drove in at 03:30 from Indiranagar. By 04:10 I had a console session on the standby and could see the FED process flapping every 90 seconds. show platform software fed switch active had a half-loaded forwarding table. We had to power-cycle the whole stack. not just reload, because the FED process had wedged in a state the running IOS could not recover from. The FTD manager was still showing the device as "healthy" the whole time, by the way, because its health probe was over the management VRF, which was up. Business was back at 04:48.

What that customer learned: Cisco DNA Center 2.3.7 appliance (DN2-HW-APL) SmartNet on the Restricted-Trade DC bundle is ₹3.4L annual, and they happily renewed for the 24x7x4 SLA on both stacks the following week. Total cost of the upgrade was less than the four-hour outage they had just survived. Their CFO signed the PO at 11 AM the same morning: fastest budget sign-off I have ever seen at that account.

FAQ I get from network engineers on this issue

Can I fix this without a reload?

About 60% of the time, yes, config-only changes plus a clear ip bgp <peer> soft or a process-level restart. For the other 40% you need either a line-card OIR or a full stack reload. Plan for a maintenance window if you cannot tell which bucket you are in.

Will this affect my SmartNet entitlement?

No. Following Cisco-published procedures and applying official IOS XE is exactly what SmartNet contracts cover. Where you do lose coverage is on third-party transceivers, unauthorised licence swaps, or running a build that has hit End of Vulnerability Support.

Is the IOS XE 17.9.x LTS train safe for production today?

For the 9200, 9300, 9400, and 9500 lines, 17.9.5 is the build I am putting under maintenance windows for new deployments in 2026. 17.12.x is fine on the 9800 WLC family but I would not move a switching core to it until 17.12.3+ at the earliest.

Does FTD need a separate deploy after I change the underlying device config?

If you are using FTD-managed FTD, never edit the FTD running-config out-of-band. The next deploy from the manager will overwrite your change and the device will reload. Always push through the manager so the policy stays in sync.

What if the issue persists after a clean reload?

Pull the show tech, attach it to TAC, and ask them to run the bug search against the platform and IOS XE version. About one in eight persistent failures I have escalated turned out to be a documented bug with a hotfix or workaround already published. but not surfaced in the release notes I was reading.

Will Cisco DNA Center catch this proactively?

DNA Center 2.3.7 assurance does flag adjacency flap and BGP session-state churn within 5-7 minutes. For the slower-failing modes (MTU mismatch stuck in EXSTART, NSSA Type 7 not translated, authentication mismatch with valid hellos), DNA Center generally misses them entirely. Build your own EEM applets for those.

Related guides worth a look while you sort this one out:

References

Final word from the field

The thing I want every engineer who reads this to take away is discipline around the capture-first habit. Console session logging on. Show tech captured before any clear command. NTP verified before you argue about routing. If you build those three habits, you will fix FTD BGP Neighbor Stuck Opensent State (and the next dozen Cisco failures you meet) in a fraction of the time it takes a less methodical engineer.

If you are working a P1 right now and stuck on this exact issue, my mailbox is at the byline below. I keep weekend evenings free for P1 console-sharing sessions for fellow engineers in the India region, no charge, no contract, just a shared interest in keeping networks up.