Route Refresh, Soft Reconfiguration, and Staggered Update Visibility

Introduction

Route Refresh (RFC 2918), soft reconfiguration, and staggered update visibility are three mechanisms that affect how a BGP policy change becomes visible across the network. Together they can make a policy edit appear active on a router before the entire network has converged on a new best‑path.

Route Refresh

How it works

1. Capability advertisement – During session establishment each peer advertises the Route‑Refresh capability (code = 2). When both peers advertise it, the capability is negotiated.
2. Trigger – The operator changes an inbound or outbound policy and wants to see the effect without tearing down the session.
3. Route‑Refresh message – The router sends a Route‑Refresh message:
   • Type = 1 (inbound) – asks the peer to resend all routes it has advertised to the local router.
   • Type = 2 (outbound) – asks the peer to resend all routes it has received from the local router (rarely used).
4. Peer response – The peer retransmits all routes currently in its Adj‑RIB‑Out that satisfy its outbound policy, as if sending a full update. The local router processes these routes through its inbound policy engine, rebuilds Adj‑RIB‑In, runs the best‑path algorithm, and installs any changes into the Loc‑RIB and FIB.
5. State – The BGP FSM stays in Established; only the RIB tables are refreshed.

Benefits

• Avoids traffic disruption and reconvergence caused by a hard BGP reset.
• Enables rapid validation of policy changes in production.
• Works even when the peer lacks soft reconfiguration, because the refresh is initiated locally.

CLI example (Cisco IOS XR)

# Verify that route refresh is enabled (default)
show bgp neighbors 10.0.0.1 | include "Route Refresh"

# If explicitly disabled, re‑enable:
router bgp 65001
  neighbor 10.0.0.1
    capability route-refresh
  !

Soft Reconfiguration

How it works

1. Configuration – Enable soft-reconfiguration inbound (or outbound) on a BGP neighbor.
2. Receipt of routes – As routes arrive, the router stores a copy of each NLRI in Adj‑RIB‑In before applying inbound policy. The post‑policy route is also placed in Adj‑RIB‑In for normal processing.
3. Policy change – When the inbound policy is altered, the router re‑runs the policy engine against the stored copy of routes; no refresh request is sent to the peer.
4. Loc‑RIB update – The reevaluation may admit new routes, reject previously admitted ones, or change attributes. The resulting set forms a new Loc‑RIB, triggering a best‑path recalculation and FIB update.
5. No peer interaction – The peer’s session remains unchanged; no Route‑Refresh or reset is required.

Benefits

• Immediate reapplication of inbound policy changes without consuming peer bandwidth.
• Useful when peers do not support Route‑Refresh or when minimizing update traffic is critical.
• Provides a deterministic point‑in‑time view of the exact routes received from a neighbor, helpful for auditing.

CLI example (Cisco IOS)

# Inbound soft reconfiguration
router bgp 65001
  neighbor 10.0.0.1
    soft-reconfiguration inbound
  !

# Outbound soft reconfiguration (rarely needed)
router bgp 65001
  neighbor 10.0.0.1
    soft-reconfiguration outbound
  !

Staggered Update Visibility

How it works

1. Update‑group formation – BGP groups peers that share identical outbound policy, replication requirements, and address family into the same update group. A single update message is built per group and replicated to all members.
2. MinRouteAdvertisementInterval (MRAI) – Each update group is governed by an MRAI timer. When a route change triggers an update, the speaker (re)starts the MRAI timer for that group; the update is sent only after the timer expires, preventing rapid bursts.
3. Staggered effect – If a policy change affects multiple update groups with different MRAI values (e.g., eBGP peers with a 30‑second MRAI vs. iBGP peers with a 0‑second MRAI), the groups send updates at different times. Per‑neighbor advertisement‑interval tuning can increase the stagger further.
4. Observed visibility – A router in a low‑MRAI group sees the new routes (and thus the new policy effect) sooner than peers in a high‑MRAI group. During the intervening interval the network appears partially converged: some paths reflect the new policy, others still reflect the old policy.

Benefits

• Natural rate‑limiting reduces update churn during frequent policy flaps.
• Operators can tune convergence speed per‑peer or per‑group (e.g., faster convergence for critical iBGP peers, slower for external peers to limit ISP‑side load).

CLI example (Cisco IOS)

# Adjust MRAI for a specific neighbor (in seconds)
router bgp 65001
  neighbor 10.0.0.1
    advertisement-interval 0   # disables MRAI; sends updates immediately
  !

# Global timers (keepalive, holdtime, min holdtime)
router bgp 65001
  timers bgp 30 90 30
  # MRAI is derived from advertisement-interval; default is 0s but many
  # implementations apply a minimum of 30s for eBGP unless overridden.

Policy Edit Visibility vs. Network Convergence

Why the policy can appear active before full convergence

When an operator changes an outbound route‑map or community‑set:

• The local router immediately applies the new policy to its Adj‑RIB‑Out and begins sending updated routes to peers according to the update‑group/MRAI schedule.
• If the policy influences best‑path selection (e.g., by altering MED or local‑pref), the router’s own Loc‑RIB may be updated right away, so its forwarding table already reflects the new intent.
• Peers in low‑MRAI update groups receive the updated routes quickly and may adjust their forwarding tables.
• Peers in high‑MRAI groups continue to advertise the old routes until their timers expire, causing transient forwarding paths that still follow the old policy.

Thus, from the perspective of the router that made the change, the policy appears active, while the network as a whole has not yet converged on a uniform set of paths.

Factors influencing convergence time

Troubleshooting checklist

1. Check update‑group timers – show bgp update-group (or equivalent) to see MRAI values per group.
2. Verify advertisement‑interval – show bgp neighbors <ip> for per‑neighbor settings.
3. Inspect BGP state – Ensure sessions are Established; look for flaps that could delay convergence.
4. Monitor CPU and memory – High utilization can slow best‑path recalculation.
5. Validate IGP convergence – Use show ip route or IGP‑specific commands to confirm next‑hop reachability.
6. Review policy complexity – Simplify route‑maps or prefix‑lists if processing time is excessive.

By understanding how Route Refresh, soft reconfiguration, and staggered update visibility interact, operators can predict when a policy change will be locally visible and anticipate the time required for network‑wide convergence.