Network & Infrastructure / BGP Policy & Internet Edge
Route refresh versus hard clear after a policy correction
An engineer considers resetting a busy BGP session to apply a corrected import rule. The avoidable reset could withdraw thousands of otherwise valid routes and disrupt convergence.
Environment and inputs: BGP speakers and route reflectors; policy syntax, RPKI integration and address-family behavior depend on the implementation. Diagnostic/design example; not tested on production equipment.
Collect the evidence
Check negotiated route-refresh capability, implementation behavior, retained inbound routes and the exact policy direction. Capture baseline accepted and advertised counts before requesting reevaluation.
Explain the result
Refreshing policy and rebuilding transport are different operations. Supported soft reevaluation can apply a change without terminating the session, but behavior depends on capability and local configuration.
Plan the fix
Use the platform's documented minimal reevaluation procedure after validating the policy. Reserve a hard reset for an established requirement rather than treating it as the default diagnostic action.
Check the result and rollback
Verify the target prefix and route counts while monitoring update load and peer stability. Restore the prior policy if reevaluation has unintended scope; do not repeatedly refresh all peers during saturation.