Route Refresh in BGP

December 27, 2016

When configuring new policies for BGP peers it is necessary to bounce the BGP session to make sure the policy is active. There are several ways of doing this:

Each of these have drawbacks, but the newest and currently recommended method is using route refresh.

Hard reset

Hard reset is using the clear ip bgp command and this is disruptive to the service. The BGP session is terminated towards the neighbour peer before brought back up again. The time for your session to get back up again will vary on the size of the routing table. A hard reset is recommended only as a last resort.

Soft configuration

Soft configuration is a feature to avoid having to do a hard reset of the BGP session to force a new incoming policy to take effect. The configuration creates two different tables, the Adj-RIB-in and loc-RIB. The Adj-RIB-in contains all prefixes, before any routing policy is applied. The loc-RIB is the table after routing policies has been applied.

As soft reconfiguration keeps two tables, the memory consumption increases. This is the biggest drawback with soft reconfiguration.

However, the soft reconfiguration feature enables the use of the command show ip bgp neighbor x.x.x.x received-routes, a very handy command when troubleshooting routing issues toward a neighbor. The command will show all received routes before any routing policy is applied, so it is easy to show this to the neighbouring peer admin and prove the issue is with their network announcements.

To configure soft reconfiguration with a peer:

router bgp 64512
    neighbor 10.3.0.2 soft-reconfiguration in

Check for soft configuration:

loading-rtr01#show ip bgp neighbors 10.3.0.2
BGP neighbor is 10.3.0.2,  remote AS 64513, external link

...

 For address family: IPv4 Unicast
  Session: 10.3.0.2
  BGP table version 59, neighbor version 59/0
  Output queue size : 0
  Index 5, Advertise bit 0
  5 update-group member
  Inbound soft reconfiguration allowed <--- SOFT RECONFIGURATION CONFIGURED

And when soft configuration is configured the received-routes command can be used:

loading-rtr01#show ip bgp neighbors 10.3.0.2 received-routes
BGP table version is 59, local router ID is 10.90.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *   10.3.0.0/30      10.3.0.2                               0 64513 ?
 *   10.255.255.0/24  10.3.0.2                               0 64513 ?
 *>  172.16.99.0/26   10.3.0.2                               0 64513 ?
 *>  192.168.0.0      10.3.0.2                               0 64513 ?

Total number of prefixes 5

Compared to when the feature isn’t activated:

loading-rtr01#show ip bgp neighbors 10.3.0.2 received-routes
% Inbound soft reconfiguration not enabled on 10.3.0.2

We can try running a clear ip bgp 10.3.0.2 soft in to force a reconfiguration:

loading-rtr01#clear ip bgp 10.3.0.2 soft in
*Dec 26 18:16:14.330: BGP(0): start inbound soft reconfiguration for
*Dec 26 18:16:14.330: BGP(0): process 10.3.0.0/30, next hop 10.3.0.2, metric 0 from 10.3.0.2
*Dec 26 18:16:14.330: BGP(0): No inbound policy. Prefix 10.3.0.0/30 accepted unconditionally
*Dec 26 18:16:14.330: BGP(0): process 10.255.255.0/24, next hop 10.3.0.2, metric 0 from 10.3.0.2
*Dec 26 18:16:14.330: BGP(0): No inbound policy. Prefix 10.255.255.0/24 accepted unconditionally
*Dec 26 18:16:14.330: BGP(0): process 172.16.99.0/26, next hop 10.3.0.2, metric 0 from 10.3.0.2
*Dec 26 18:16:14.330: BGP(0): No inbound policy. Prefix 172.16.99.0/26 accepted unconditionally
*Dec 26 18:16:14.330: BGP(0): process 192.168.0.0/24, next hop 10.3.0.2, metric 0 from 10.3.0.2
*Dec 26 18:16:14.330: BGP(0): No inbound policy. Prefix 192.168.0.0/24 accepted unconditionally
*Dec 26 18:16:14.330: BGP(0): complete inbound soft reconfiguration, ran for 0ms

And looking at the summary we see that the BGP session has not been “touched”:

loading-rtr01#show ip bgp sum
BGP router identifier 10.90.1.1, local AS number 64512
BGP table version is 59, main routing table version 59
12 network entries using 1728 bytes of memory
14 path entries using 1120 bytes of memory
2/2 BGP path/bestpath attribute entries using 288 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 3160 total bytes of memory
BGP activity 14/2 prefixes, 41/27 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.3.0.2        4        64513   53099   50364       59    0    0 2w2d            5

Soft reset (route refresh)

Route refresh is a reaction to the soft configuration feature, introduced to standardise the feature. However, the route refresh feature does not store a copy of all the prefixes like soft configuration and it therefore avoids the additional CPU and memory consumption. The feature is standardised in RFC 2918 published in 2000, long enough ago so there should be no excuse for not implementing the feature.

In Cisco IOS there is no need to explicitly enable the feature, the BGP peers will communicate the feature between them and enable it if both peers have the capability. If you enable soft configuration the route refresh feature is not enabled, they are mutually exclusive.

Check that the feature is enabled:

loading-rtr01#show ip bgp neighbors
BGP neighbor is 10.3.0.2,  remote AS 64513, external link
 Description: loading-pa01
  BGP version 4, remote router ID 10.3.0.2
  BGP state = Established, up for 1d01h
  Last read 00:00:00, last write 00:00:04, hold time is 90, keepalive interval is 30 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)

If the BGP peer is unable to do route refresh it will only show advertised, not received:

loading-rtr01#show ip bgp vpnv4 vrf BIG-BGP nei
BGP neighbor is 10.4.0.2,  vrf BIG-BGP,  remote AS 64514, external link
  BGP version 4, remote router ID 10.4.0.2
  BGP state = Established, up for 00:00:25
  Last read 00:00:10, last write 00:00:25, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised

When the feature is enabled you can force a BGP refresh:

loading-rtr01#clear ip bgp 10.3.0.2 in
*Dec 27 20:52:11.279: BGP: 10.3.0.2 sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 0

As you can see the router is now sending a refresh request to its neighbour.

Summary

BGP is a crucial protocol and it is important to be able to do changes without forcing a disruption with each policy change. This is where the soft configuration and soft reset comes to play. Both these features enables on-the-fly changes without causing disruption to the service.

When choosing which of these two features to use you need to evaluate the requirements and your capacity. If you are planning on doing lots of policy changes and have the capacity to keep the second prefix table I say you go for it. If your BGP session is simple and big the route refresh feature is a more likely fit as you will save some memory and CPU.

Resources:
Cisco BGP commands
RFC 2918 Route Refresh Capability for BGP-4
Routing TCP/IP Volume II
CCIE Blog: Route Refresh vs Soft Reconfiguration

2088