Configure BGP Routing with Soft-reconfiguration Limitations on FTD
Author: Cisco Systems, Inc.
Date: 2026-09-18T05:00:00+00:00
Description: When a user attempts to configure Border Gateway Protocol (BGP) soft-reconfiguration on a BGP peer in Firewall Threat Defense (FTD) using Firewall

Contents

Issue

Environment

Resolution

Feature Limitations

Alternative Approach (Route Refresh capability)

Cause

Related Content

- Issue
- Environment
- Resolution
- Feature Limitations

- Alternative Approach (Route Refresh capability)

- Cause

- Related Content

Issue

When a user attempts to configure Border Gateway Protocol (BGP) soft-reconfiguration on a BGP peer in Firewall Threat Defense (FTD) using Firewall Management Center (FMC), the configuration cannot be completed through the standard FMC BGP interface. Additionally, attempts to implement this functionality using FlexConfig objects result in errors during text input for various parts of the BGP neighbor soft-reconfiguration command. The specific requirement is to enable soft-reconfiguration inbound on BGP neighbors to store received routes for policy evaluation and troubleshooting purposes.

Environment

- Hardware: Secure Firewall 3100. Other hardware platforms are also affected.

- Software: FTD (this limitation is also applicable to Adaptive Security Appliance (ASA)).

- FMC version 7.4.6. Other software versions are also affected.

- FTD version 7.4.6. Other software versions are also affected.

- FTD has BGP routing protocol configuration.

Resolution

At the time of this writing, classic BGP neighbor inbound soft-reconfiguration (BGP command neighbor x.x.x.x soft-reconfiguration inbound) is not supported on FTD devices, either through the FMC BGP user interface or as a supported FlexConfig method.

Feature Limitations

These BGP soft-reconfiguration capabilities are not available:

- FMC BGP configuration does not provide a configuration option for neighbor soft-reconfiguration inbound.

- Attempting to configure the equivalent CLI through FlexConfig fails because it is not a supported FTD/FMC-managed BGP configuration item.

Alternative Approach (Route Refresh capability)

FTD does support BGP Route Refresh capability when negotiated with BGP peers. This provides the supported mechanism for dynamic soft reset behavior after policy changes, although it differs from classic soft-reconfiguration inbound functionality.

The recommended approach includes:

- Continue configuring BGP neighbors, prefix lists, route maps, and filtering through FMC's supported BGP configuration workflow.

- Confirm that BGP peers negotiate Route Refresh capability:

device# show bgp neighbors 192.0.2.2

BGP neighbor is 192.0.2.2,  context single_vf,  remote AS 65535, internal link

BGP version 4, remote router ID 192.0.2.2

BGP state = Established, up for 00:17:39

Last read 00:00:31, last write 00:00:31, hold time is 180, keepalive interval is 60 seconds

Neighbor sessions:

1 active, is not multisession capable (disabled)

Neighbor capabilities:

Route refresh: advertised and received(new)       <------- BGP Route Refresh capability is enabled on both peers

Four-octets ASN Capability: advertised and received

Address family IPv4 Unicast: advertised and received

Multisession Capability:

Message statistics:

InQ depth is 0

OutQ depth is 0

Sent       Rcvd

Opens:         1          1

Notifications: 0          0

Updates:       1          3

Keepalives:    17         20

Route Refresh: 1          0         <------- The neighbor sent 1 BGP Route Refresh message

Total:         20         24

- Use Route Refresh behavior for policy re-evaluation instead of attempting to enable inbound soft-reconfiguration, e.g.:

device# clear bgp 192.0.2.2 in

- For operational requirements to audit all received and rejected routes, verify from the BGP peer/router side.

Comparison

Feature

BGP Route Refresh Capability

Inbound Soft Reconfiguration

Supported on FTD/ASA

Yes

No

How it Works

The router sends an explicit BGP Route Refresh request message to the neighbor, asking it to re-advertise its routing table.

The router allocates extra RAM to save a raw, unfiltered copy of the neighbor's BGP table in local memory.

Configuration Requirement

None. Enabled automatically by default on FTD and ASA.

Manual configuration required (neighbor x.x.x.x soft-reconfiguration inbound), but the command is not supported on FTD/ASA.

Memory Consumption

Extremely Low. No extra routing tables are stored in RAM.

Very High. Consumes much more memory for that neighbor's paths.

Trigger Command

# clear bgp x.x.x.x in

Not supported on ASA/FTD.

Neighbor Dependency

Yes. The remote BGP peer must also support and accept the Route Refresh capability.

No. It is completely local to the firewall; the peer neighbor has no idea it is enabled.

Command: show bgp neighbor x.x.x.x received-routes

Not Supported / Fails. The router does not store a local copy. Running this command returns an error (% Inbound soft reconfiguration not enabled on x.x.x.x).

Supported. Instantly displays the raw, unfiltered routes currently cached in the router's RAM before policies were applied.

Cause

This is a feature limitation on FTD and ASA devices. The BGP neighbor inbound soft-reconfiguration functionality has not been implemented in the FMC BGP configuration interface or as a supported FlexConfig option for FTD devices. This limitation is tracked as a software enhancement Cisco bug ID CSCvy97220.

Related Content

- FMC BGP Configuration Guide (10.x)

- FTD Command Reference for BGP Neighbor and Summary Visibility

- Cisco bug ID CSCvy97220 - Enhancement Request for BGP Neighbor Inbound Soft-Reconfiguration Support

- Cisco Technical Support & Downloads