BGP Route Refresh Capability

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 can be found at the BGP Soft Reconfiguration Lesson. To perform a route refresh, simply use the clear ip bgp command as you normally would.

Route refresh is enabled by default on all Cisco BGP routers, so it doesn’t need to actually be enabled or configured. More about how it works can be found in the BGP Route Refresh Capability lesson.

As mentioned before, route refresh is enabled by default. If you disable it, then when you apply the clear ip bgp command, a hard reset will take place.

Note here that the soft-reconfig inbound command is not involved in the route refresh feature of BGP, but in the soft reconfiguration feature. This command actually enables the soft reconfiguration feature, essentially telling the router to save the routing information from that particular neighbour in a new table called the adj-RIB-in table so that when a BGP session is cleared, that information will remain. Note that the information in this table is unmodified, meaning that it does not include any changes that may have been made by route maps that may be configured. In other words, this table shows the information as it appears in the neighbour’s BGP table.

Now you can use the show ip bgp neighbors <ip address of neighbor> received-routes command to see that table, but you can also get that information without the received-routes keyword. In such a case, any modifications made would not be shown. This is shown in much more detail in the BGP Soft Reconfiguration lesson.

I hope this has been helpful!

Laz

1 Like

Hi Ren
If route refresh is support and enabled on both router. when we made change on policy inbound but we didn’t manually request route by clear ip bgp in command. Will router auto send route request from neighbor ? and if it will auto send route request how long will it send after we modify the policy ?
Regard,

1 Like

Thanks for the information.
In summary:

  • Soft-reconfiguration and route refresh are two different things.
  • Soft-reconfiguration stores an unmodified copy of all received routes from a neighbor in a separate table in memory and just reuse it whenever the inbound policy changes. This is configured on per neighbor basis using the command neighbor x.x.x.x soft-reconfiguration inbound.
  • A router using route refresh don’t need to store a separate unmodified copy of all routes from a BGP peer, the BGP peer will simply resend all routes of a particular address family.
  • The route refresh requires no configuration and will be used automatically.
  • In order to perform a route refresh we simply issue the clear ip bgp x.x.x.x soft in, the hard reset is not recommended because it’s disruptive.
  • Soft-reconfiguration shouldn’t be used anymore.

Hello Luis

Yes, it seems that you’ve got it! Just one clarification.

It’s not that it shouldn’t be used, but simply it is not the best choice. For small to medium sized networks, it should be fine, but for very large networks, it uses way too many resources on devices, so the better choice would be route refresh.

I hope this has been helpful!

Laz

Hello Heng

The INE blog describes this very well:

BGP does not utilize periodic updates, and thus route invalidation is not based on expiring any sort of soft state information (e.g prefix-related timers like in RIP). Instead, BGP uses explicit withdrawal section in the triggered UPDATE message to signal neighbors of the loss of the particular path. In addition to the explicit withdrawals, BGP also support implicit signaling, where newer information for the same prefix from the same peer replaces the previously learned information.

So to answer your question directly, if you modify an inbound policy, it is unknown when the prefixes will be sent again so that the new policy can take effect on the incoming BGP updates. This is the reason why it is advisable to always perform a reset on the BGP peering whenever such changes are made. And this in turn, makes features such as route refresh and soft reconfiguration necessary.

I hope this has been helpful!

Laz

Hi Laz,

In a scenario without soft-reconfig inbound, the command show ip bgp neighbors x.x.x.x received-routes will always show a prefix’s attributes as changed by the BGP inbound policy, right? So, its output would be similar to show ip bgp?

There is no way to see the prefixes as they were sent by the neighbor.

Thanks.

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 192.168.12.2 received-routes  
% Inbound soft reconfiguration not enabled on 192.168.12.2
R1#

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

R1#show ip bgp neighbors 192.168.12.2 routes

This command will show you the routes received and accepted from that particular neighbour, and includes any alterations that have been made using inbound policies. When soft reconfig is not configured, there is no way to see the raw BGP information that has been sent from the neighbor since that info is not stored anywhere.

I hope this has been helpful!

Laz

2 Likes

Hi team,

Just to be sure i understood everything correctly. Route-refresh capability is negotiated with Open messages. If a customer of mine has a router no supporting route-refresh and if i didn’t configure soft-reconfiguration, the only way to update my BGP table is a hard reset, is that correct? Thanks !

Hello David

A BGP router can inform its neighbors of its route refresh capability by including the “Route Refresh Capability” optional parameter in the OPEN message when establishing a BGP session with the neighbor. The OPEN message is the first message sent by a BGP router to its neighbor when establishing a BGP session, and it contains various parameters that are used to negotiate the BGP session. If the “Route Refresh Capability” optional parameter is included in the OPEN message, it indicates to the neighbor that the router supports the route refresh capability.

If the soft-reconfiguration feature is not configured on your router, and your neighbor does not support route refresh, then yes, only a hard reset will update your BGP table.

I hope this has been helpful!

Laz

1 Like

Hello!

Once we apply an inbound policy to routes received from a neighbor, such as Weight, is it really necessary to issue the clear ip bgp x.x.x.x soft in command?

In my lab, these policies take effect automatically for some reason. I don’t even need to issue the command and my routers just send out a route refresh message.

Kind regards,
David

Hello @davidilles ,

Good question. I just tried this again on two IOS 15.x routers. After attaching the route-map on R2, it automatically requested a route refresh:

R2#
*Jul  7 08:43:26.257: BGP: 192.168.12.1 sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 0
*Jul  7 08:43:26.260: BGP: 192.168.12.1 rcv message type 5, length (excl. header) 4
*Jul  7 08:43:26.260: BGP: 192.168.12.1 rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 1
*Jul  7 08:43:26.260: BGP: 192.168.12.1 rcv message type 5, length (excl. header) 4
*Jul  7 08:43:26.260: BGP: 192.168.12.1 rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 2
*Jul  7 08:43:26.260: BGP_Router: unhandled major event code 128, minor 0
R1#
*Jul  7 08:43:25.354: BGP: 192.168.12.2 rcv message type 5, length (excl. header) 4
*Jul  7 08:43:25.354: BGP: 192.168.12.2 rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 0
*Jul  7 08:43:25.354: BGP: 192.168.12.2 sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 1
*Jul  7 08:43:25.355: BGP: 192.168.12.2 sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 2

I’m not 100% sure if this was always the case. The way it is now, it is event-based. You apply a new policy, and it requests a route refresh. I’m wondering if the behavior is similar on IOS 12.4…

Rene