Module 4: BGP Policy·Lesson 4.7 (7 of 8 in this module)·29 of 43 in the BGP course
Applying policy changes: route refresh and soft reconfiguration
You change a route map and nothing happens. BGP does not re-run policy on routes it already accepted. There is a safe way to make it, and a heavy-handed way you should avoid.
Advanced · 11 min read
You'll learn to apply a new inbound or outbound policy with a soft reset, explain how route refresh works, and say when soft-reconfiguration inbound is needed.
Policy is not retroactive
When a route arrives, BGP runs your inbound policy once and stores the result. Edit the route map afterwards and the stored routes keep their old attributes. Outbound is the same: routes already advertised are not re-evaluated. Something has to ask for them again.
Where each show command looks in the BGP pipeline
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Soft reconfiguration inbound keeps the pre-policy copy, which is why received-routes only works when it is configured.
The wrong way and the right way
A hard reset (clear ip bgp 192.0.2.1) closes the TCP connection. The session drops, every route from that neighbour is withdrawn, and the full table is exchanged again. On a router with two providers, that is an outage for the traffic that depended on that neighbour.
A soft reset keeps the session up and re-runs policy. The outbound and inbound directions work differently.
Applying a policy change with a soft reset
On small screens, swipe sideways or focus the diagram and use the arrow keys.
A soft inbound reset asks the neighbour to resend. A hard reset closes the TCP session and rebuilds everything.
clear ip bgp 192.0.2.1 soft in
clear ip bgp 192.0.2.1 soft out
Privileged EXEC mode. soft in asks the neighbour to send its routes again so inbound policy can be applied. soft out re-runs outbound policy on the routes you hold and sends the differences.
Behind soft in is the route refresh capability (RFC 2918). Both routers say they support it when the session opens. Your router then sends a ROUTE-REFRESH message and the neighbour replies with its full set of routes for that address family, which is why this works even though your router did not keep a copy.
Check support and timing
Check before you refresh
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Confirm the capability, then request the refresh, then watch the counters.
Illustrative Cisco IOS XE output written for this lesson, not a router capture
R1#show ip bgp neighbors 192.0.2.1 | include refresh
Route refresh: advertised and received(new)
The first line confirms both sides support route refresh, so soft in will work. If the capability is missing, soft in needs the older soft-reconfiguration approach below.
Soft-reconfiguration inbound: a cost
The older method stores an unmodified copy of everything the neighbour sent, so policy can be re-run locally without asking. It costs memory in proportion to the number of routes received.
Two ways to reapply inbound policy
On small screens, swipe sideways or focus the diagram and use the arrow keys.
R1. Needed only if a neighbour lacks route refresh, or if you want show ip bgp neighbors received-routes to show routes before your policy.
Illustrative Cisco IOS XE output written for this lesson, not a router capture
R1#show ip bgp neighbors 192.0.2.1 received-routes
Network Next Hop Metric LocPrf Weight Path
203.0.113.0 192.0.2.1 0 0 64501 i
Total number of prefixes 1
This only works if soft-reconfiguration inbound is configured. It shows routes as received, before inbound policy. Compare it with show ip bgp neighbors 192.0.2.1 routes, which shows what was accepted.
You edited an inbound route map. show ip bgp still shows old attributes. What is the least disruptive fix?
Predict · scenario 2
Why does soft out not need a message to the neighbour first?
Predict · scenario 3
What is the main drawback of soft-reconfiguration inbound?
FAQ
Is clear ip bgp * safe in production?
A hard reset tears down every session, withdraws all routes and forces full table exchange again, which causes an outage. Use a soft reset unless the session is genuinely broken.
How do I know if my neighbour supports route refresh?
Look in show ip bgp neighbors for Route refresh: advertised and received under neighbor capabilities. Current IOS XE does by default.
Do I still need soft-reconfiguration inbound?
Only to see the routes a neighbour sent before your inbound policy changed them, or if the neighbour does not support route refresh. It stores a second copy of every received route.