BGP Soft Reconfiguration vs Route Refresh

Changing an inbound policy on a BGP session used to mean one of two bad options: a hard reset that tears the session down, or keeping a second, unfiltered copy of every route the peer sent. Soft reconfiguration and the route-refresh capability both solve the same problem in different ways, and picking the wrong one quietly costs you memory or convergence time. This article explains what each mechanism actually does, where the route copies live, and the exact commands to verify which one is in play on Cisco, Juniper and FRR.

Why an inbound policy change needs a soft reset

BGP stores only the post-policy result in the Adj-RIB-In table by default. Once route-map IN permit 10 has dropped a prefix, the router has no idea that prefix ever existed, so re-applying a modified policy cannot recover it. Both mechanisms exist purely to make that raw, pre-policy copy available again.

Soft reconfiguration: keep a second copy of the table

neighbor 10.0.0.1 soft-reconfiguration inbound tells the router to store an unmodified copy of every route received from that neighbor, before any inbound filter is applied. A soft reset then re-runs the policy out of that stored copy, with no messages sent to the peer and no coordination required.

router bgp 65001
 neighbor 10.0.0.1 remote-as 65002
 neighbor 10.0.0.1 soft-reconfiguration inbound

! re-apply inbound policy from the stored copy
clear ip bgp 10.0.0.1 soft in

! re-apply outbound policy (never needs route copies)
clear ip bgp 10.0.0.1 soft out

The cost is memory and CPU: the full unfiltered Adj-RIB-In is held per neighbor, which on a full-table peering is roughly a second copy of ~950k IPv4 prefixes. On routers with many peers this is the single most common cause of unexplained BGP memory growth.

Route refresh: ask the peer to resend

Route refresh (RFC 2918) advertises a capability so either side can ask its peer to re-send the Adj-RIB-Out. No local storage is needed, because the copy you want lives on the remote router.

! check whether the capability was negotiated
show ip bgp neighbors 10.0.0.1 | include Route Refresh
!  Route Refresh Capability: advertised and received

! trigger a refresh instead of a hard reset
clear ip bgp 10.0.0.1 in

Two practical differences matter. First, refresh consumes CPU on both routers and can take seconds to minutes on very large tables, so it is not free. Second, and more subtly, a refresh re-delivers everything the peer currently advertises, including prefixes and attributes it changed since the last update. A local soft reset out of a stored table cannot see those upstream changes.

Caveats specific to each mechanism

• Refresh needs both sides to support it. If the capability was not negotiated (older or broken implementations), clear ip bgp <peer> in silently degrades to a hard reset on IOS. Check the capability line before you rely on it.
• Alternative ways to get a refresh. clear ip bgp 10.0.0.1 in is a refresh when capable; the older clear ip bgp 10.0.0.1 soft in requires the stored table. Do not assume they are interchangeable.
• Policy applied to route-reflector clients. A refresh works per neighbor, so on a route reflector you must refresh each client that needs the new policy.

Which one should you configure

Modern practice: use route refresh, and only add soft-reconfiguration inbound where a peer will not negotiate the capability, or where you must guarantee re-application without any upstream coordination (for example, a maintenance window where the peer's control plane is itself suspect). Where inbound policy churn is routine, the stored table is convenient — just budget the memory. Measuring it is easy: show ip bgp summary shows total memory in use, and per-neighbor detail is in show ip bgp neighbors 10.0.0.1.

! correlation when things go wrong
show ip bgp neighbors 10.0.0.1 received-routes   ! only exists with soft-reconfig
show ip bgp neighbors 10.0.0.1 routes            ! post-policy view
show ip bgp summary | include Mem

Equivalent configuration on other platforms

! Juniper Junos - route refresh is the default behaviour
set protocols bgp group EBGP neighbor 10.0.0.1 import-policy REJECT-BOGONS
run clear bgp neighbor 10.0.0.1 soft-inbound
run show bgp neighbor 10.0.0.1 | match "Refresh"

! FRR / Cumulus Linux
neighbor 10.0.0.1 soft-reconfiguration inbound
clear bgp 10.0.0.1 in

! FortiGate
config router bgp
  config neighbor
    edit 10.0.0.1
      set soft-reconfiguration enable
    next
  end
end

Troubleshooting symptoms and their cause

• received-routes returns "No received-routes" → soft-reconfiguration inbound is not configured on that neighbor.
• Memory climbs steadily with each new peer → soft reconfiguration on full-table peers. Remove it where refresh is available.
• A prefix reappears after a refresh but not after a local soft reset → the peer changed what it advertises; the local stored copy was stale.
• Soft in triggers a full session flap → the refresh capability was never negotiated; verify with the neighbor capability output first.

Related reading on this site: the BGP best-path selection algorithm explains what happens to routes after the inbound policy has run, and BGP route flap damping parameters covers the other half of keeping a large table stable.

原文链接：https://community.fortinet.com/fortigate-3/technical-tip-bgp-soft-reconfiguration-vs-route-refresh-182391