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 tutorial. 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 tutorial 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 655 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

535 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. question:

    why we need “R2#clear ip bgp in” here to make R2 sent Route-refresh? it should send automatically if route-refresh is supported and negotiated, thanks

  2. 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


  3. Hi NL Team,

    If using the route refresh option inbound, I assume any filters we have Inbound will be processed before routes are installed in the actual routing table? Is there any reason one would use soft reconfiguration over route refresh apart from it either being supported / not supported on the platform?
    Lastly, for route refresh to work do we need the peer router to be able to support this or only our own local router?
    Thanks :grin:

  4. 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.


  5. Thanks Rene,

    Do we have a way of checking if the remote peer supports route refresh by any commands? Or would it be a case of having to ask the Provider of the peer link if their device supports route refresh?

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