A community college district must adjust inbound BGP policy without flapping sessions. Which contrast should they recall between soft reconfiguration and route-refresh?
Select an answer to reveal the explanation.
Short Explanation
Soft-reconfig inbound is keeping a full carbon copy of everything the peer said so you can re-filter offline—handy but memory-hungry. Route-refresh is calling the peer and saying ‘send that again’ after a policy change, without dropping the session. Same goal, different storage bill.
Full Explanation
Soft reconfiguration inbound retains a pre-policy copy of received routes so new inbound filters can be applied without a session reset, at the cost of additional memory. Route-refresh (dynamic capability) asks the peer to resend Adj-RIB-In so policy can be re-evaluated without that permanent extra store. A community college district adjusting inbound BGP policy without flapping sessions should recall: route-refresh requests a fresh Adj-RIB-In from the peer without a hard reset, while soft-reconfiguration inbound stores a pre-policy copy that consumes extra memory.
Soft reconfiguration does not always tear down TCP while route-refresh never stores routes—that reverses the memory trade-off. Route-refresh does not require permanently storing an unfiltered inbound copy of every prefix. Neither feature forces a hard clear ip bgp * before a new route-map can apply when soft mechanisms are available.
Exam caveat: prefer route-refresh when peers support it; use soft-reconfig when they do not and memory allows; still avoid unnecessary hard resets in production. Operational check: verify route-refresh capability on ISP peers, apply a new inbound route-map, soft-clear or refresh, confirm new policy without TCP teardown, and watch memory if soft-reconfig is enabled.