BGP Route Refresh Capability

A long time ago there was no method to dynamically request a re-advertisement 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 you’ll need additional memory since you are saving an additional table for each BGP neighbor. Since 2000 we also have the route refresh capability, simply said…your 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:

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 you’ll 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 lesson. This works but it’s not very efficient. Your router will store an entire table for each BGP neighbor with the unmodified prefixes, you’ll need extra memory.

Route refresh capability is the most preferred method…when you change your BGP policy you just send a message to your BGP neighbor and it will re-send you all its prefixes, there will be no disruption at all.

In this lesson, we’ll look at the route refresh capability, it’s described in RFC 2918 and supported on most routers.


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:

AS1 AS2 R1 R2 BGP ExternalLet’s start with a default BGP configuration:

R1(config)#router bgp 1
R1(config-router)#neighbor remote-as 2
R1(config-router)#network mask
R1(config-router)#network mask
R2(config)#router bgp 2
R2(config-router)#neighbor remote-as 1

Route refresh is enabled by default, you can verify this by using the following show command:

R1#show ip bgp neighbors | 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.

Let’s see if R2 learned those prefixes on the loopback interfaces:

R2#show ip bgp
BGP table version is 3, local router ID is
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
*>             0             0 1 i
*>             0             0 1 i

That’s 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 route-map METRIC in

This route-map will set the metric to 222 for all prefixes that we receive from R1. Let’s look at he BGP table again:

R2#show ip bgp
BGP table version is 3, local router ID is
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
*>             0             0 1 i
*>             0             0 1 i

As you can see nothing has changed yet. We’ll use the route refresh method to fix this but before I do so, let’s 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

I’ll enable the debug on both routers, now we can do a reset:

R2#clear ip bgp ?
  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

You can choose between inbound, outbound or both. Let’s do inbound:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 739 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

542 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Hi Xin,

    Using the clear ip bgp in command is a nice way to manually request a route refresh from your neighbor.

    Once you do this, you can see it in the debug that R2 is requesting R1 for a refresh:

    BGP: sending REFRESH_REQ(5) for afi/safi: 1/1


  2. Hello Robert,

    That’s right. When you receive a refreshed route, filters are applied and then it gets installed in the BGP table, and in the routing table.

    Today, there is no reason to use soft reconfiguration instead of route refresh. Soft reconfiguration was a bit of a workaround so you didn’t have to do a hard reset. Nowadays, all routers support route refresh so there’s no reason not to use it. Both peers need to support this.


  3. Hello Jennifer

    If you make a change to a routing policy (policy attributes or filters) then in order to make those policies take effect you must apply one of the three solutions stated in the lesson. If you do not, these policies will never be applied.

    Note that the changing of the policies is different than the updating

    ... Continue reading in our forum

  4. Hello Luis

    The route refresh capability and the soft reconfiguration feature are two different operations and are configured differently. Soft reset, or soft reconfiguration, stores all the information received from BGP neighbours in a separate table before the reset occurs. It works well, but it requires more memory, since an entire table is maintained for each BGP neighbour. More about this c

    ... Continue reading in our forum

  5. Hello Luis

    If you issue the show ip bgp neighbors command using the received-routes keyword and you don’t have soft-reconfig configured, then you will get the following result (I just tested it out…):

    R1#show ip bgp neighbors received-routes  
    % Inbound soft reconfiguration not enabled on

    So the command can only be used if soft reconfig is configured. However, you can use the following command:

    R1#show ip bgp neighbors routes

    This command will show you the routes received and accepted from that particular neighbour,

    ... Continue reading in our forum

21 more replies! Ask a question or join the discussion by visiting our Community Forum