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 three 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, 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 explained 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, and there will be no disruption at all.

In this lesson, we’ll look at the route refresh capability, it is 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:

Let’s 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 your 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 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             0 1 i
*> 11.11.11.11/32   192.168.12.1             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 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. Let’s 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             0 1 i
*> 11.11.11.11/32   192.168.12.1             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 real time 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 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. Let’s do inbound: