BGP Route Refresh Capability

A long time ago there was no method to dynamically request a readvertisement of the prefixes of one of your BGP neighbors. When you
change your policy, somehow you have to compare all the prefixes from your
BGP neighbor against your new policy.
To solve this problem, the soft reconfiguration method was created which
stores an unmodified version of the prefixes from your BGP neighbor. This
works but youll need additional memory since you are saving an additional
table for each BGP neighbor. Since 2000 we also have the route refresh
capability, simply saidyour router will ask its BGP neighbor to re-send its
prefixes.
Here are the 3 options that we have to refresh our BGP table when our policy
changes:

Hard reset

Soft reconfiguration

Route refresh capability

The hard reset is the most simple method (clear ip bgp command). It kills the
TCP session with your BGP neighbor which forces it to restart and as a result
youll receive all prefixes from your neighbor again. It works but will interrupt
your network, not a good idea.
The soft reconfiguration will store everything that you receive from a BGP
neighbor in a separate table before applying the policy. I explain this in my
soft reconfiguration tutorial. This works but its not very efficient. Your router
will store an entire table for each BGP neighbor with the unmodified prefixes,
youll need extra memory.
Route refresh capability is the most preferred methodwhen you change
your BGP policy you just send a message to your BGP neighbor and it will resend you all its prefixes, there will be no disruption at all.
In this tutorial well look at the route refresh capability, its described in RFC
2918 and supported on most routers.

Configuration
I will use two routers for this, R1 and R2. I have added two loopback
interfaces on R1 so that we have something to advertise:

L
ets start with a default BGP configuration:
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 remote-as 2
R1(config-router)#network 1.1.1.1 mask 255.255.255.255
R1(config-router)#network 11.11.11.11 mask 255.255.255.255
R2(config)#router bgp 2
R2(config-router)#neighbor 192.168.12.1 remote-as 1

Route refresh is enabled by default, you can verify this by using the following
show command:
R1#show ip bgp neighbors 192.168.12.2 | begin capabilities
Neighbor capabilities:
Route refresh: advertised and received(new)

This router can do a route refresh for inbound prefixes (what you learn from
you BGP neighbor) or outbound (the prefixes that you send to them). On my
IOS 15.x router you see (new) which means this router supports the RFC
2918 version of route refresh. Some older IOS versions might show (old &
new) which means they also support a version of route refresh that Cisco
implemented before the RFC was created.
Lets see if R2 learned those prefixes on the loopback interfaces:
R2#show ip bgp
BGP table version is 3, local router ID is 192.168.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network

Next Hop

Metric LocPrf Weight Path

*> 1.1.1.1/32
192.168.12.1
*> 11.11.11.11/32 192.168.12.1

0
0

01i
01i

Thats looking good. Now I will create a route-map that changes one of the
BGP attributes. This means the router will have to update its BGP table
somehow:
R2(config)#route-map METRIC permit 10
R2(config-route-map)#set metric 222
R2(config)#router bgp 2
R2(config-router)#neighbor 192.168.12.1 route-map METRIC in

This route-map will set the metric to 222 for all prefixes that we receive from
R1. Lets look at he BGP table again:
R2#show ip bgp
BGP table version is 3, local router ID is 192.168.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric LocPrf Weight Path
*> 1.1.1.1/32
192.168.12.1
0
01i
*> 11.11.11.11/32 192.168.12.1
0
01i

As you can see nothing has changed yet. Well use the route refresh method
to fix this but before I do so, lets enable a debug so you can see in realtime
what is going on:
R1 & R2#debug ip bgp
BGP debugging is on for address family: IPv4 Unicast

Ill enable the debug on both routers, now we can do a reset:

R2#clear ip bgp 192.168.12.1 ?
all
All address families
flap-statistics Clear flap statistic
in
Soft reconfig inbound updates
ipv4
Address family
ipv6
Address family
l2vpn
Address family
nsap
Address family
out
Soft reconfig outbound updates
rtfilter
Address family
slow
Forcefully clear slow-peer status and move it to original
update group
soft
Soft reconfig inbound and outbound updates
topology
Routing topology instance
vpnv4
Address family
vpnv6
Address family
<cr>

You can choose between inbound, outbound or both. Lets do inbound: