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:
Check for soft configuration:
And when soft configuration is configured the received-routes command can be used:
Compared to when the feature isn’t activated:
We can try running a clear ip bgp 10.3.0.2 soft in to force a reconfiguration:
And looking at the summary we see that the BGP session has not been “touched”:
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:
If the BGP peer is unable to do route refresh it will only show advertised, not received:
When the feature is enabled you can force a BGP refresh:
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.