Hi Ranji,
The original BGPv4 specification did not specify any means by which a router could ask its BGP peer to resend its routes. Yet, this functionality is crucial whenever you update your inbound BGP policies because these policies have to be applied to all inbound route information from that neighbor. It would not be sufficient to subject the existing routes in your BGP RIB to the updated policies because the previous policy could have filtered some networks out, or changed their attributes, and you do not remember the original attributes or the filtered routes anymore. Therefore, the only reliable way of applying an updated inbound policy in BGP is to have the neighbor send all its routes again, and subject those routes to the updated policy.
The simplest way of accomplishing this is simply to tear down the BGP peering and let it come up again. This is what is described as a hard reset. However, this approach is rather heavyweight and causes outages in orders of seconds or minutes (and perhaps more) until the BGP peering comes up again and the routes are readvertised in both directions. In big BGP deployments, this is a no-no. Therefore, a more clever approach is required.
Vendors have tried to work around this BGP deficiency by implementing a single hack: Keep a separate, unfiltered and unmodified copy of all routes received from a neighbor, and whenever an inbound policy for that neighbor is changed, take this unfiltered database and "distill" it through the updated inbound policy. This has the same effect as having the neighbor resend all routes again, yet it is accomplished purely by local means - storing the unmodified copy of all received routes in a separate place in memory and just reuse it whenever the inbound policy changes. This is what Cisco calls Soft Reconfiguration and is configured on a per-neighbor basis using the neighbor X.X.X.X soft-reconfiguration inbound command. The obvious advantage is that Soft Reconfiguration does not require any change to the BGP protocol itself and it is fast because the routes do not need to be downloaded again as you already have them. The major disadvantage is the huge memory footprint: For each neighbor configured for Soft Reconfiguration, you keep a separate unmodified database of all its routes, plus you keep your normal BGP RIB. With Soft Reconfiguration, you are unable to save RAM by filtering out unnecessary routes, as you will still keep them, and the routes you have accepted will be kept twice: First in the unmodified database for the neighbor, second in the RIB.
A different approach was chosen by authors of RFC 2918 that proposed a new BGP message called Route Refresh. This message can be used to ask a BGP peer to resend all routes of a particular address family (say, IPv4 or IPv6). As this was a new BGP message, its adoption required that vendors implemented the support for it into their products. However, the RFC is from September 2000 and now, all major vendors support it. If using the Route Refresh, a router does not need to store a separate unmodified copy of all routes from a BGP peer. Whenever it needs to reapply a new inbound policy, it simply sends the peer a Route Refresh message, and the peer will automatically resend all routes of a particular address family. Clearly, this is the way it should have been implemented in the first place.
The term soft reset refers to the use of either Soft Reconfiguration or Route Refresh - in any case, the ability to reapply an inbound policy without tearing down the BGP peering itself. More precisely, however, Cisco likes to use the term soft reset for Soft Reconfiguration (the separate unmodified database per neighbor), and dynamic inbound soft reset for Route Refresh. Confusing? I would say so :) That is why I like to call these features directly: either Soft Reconfig or Route Refresh, and you know what I mean.
The Soft Reconfig has to be explicitly configured for a neighbor, otherwise it is not performed. The Route Refresh is automatically negotiated between BGP peers as they establish a peering, and will be used automatically when both peers declare that they support it.
Many people are confusing these two, and more seriously, they keep configuring neighbor X.X.X.X soft-reconfig inbound all the time, perhaps thinking that this is the Route Refresh, or that if the neighbor supports Route Refresh, no separate unmodified database will be kept for it. However, this is a serious mistake. The Route Refresh requires no configuration and will be used automatically. If a neighbor is configured with Soft Reconfig, this Soft Reconfig will take precedence and the router will keep a separate database for it even if the neighbor supports Route Refresh, voiding all its advantages. I keep seeing people configuring the Soft Reconfig, unknowingly losing all advantages of Route Refresh as a direct result, even though their routers support Route Refresh for years.
So to sum up: Soft Reconfig maintains a separate unmodified database for a neighbor, and is used only when explicitly configured. Route Refresh adds another message to BGP allowing a router to ask its peer to resend the routes again, and requires no configuration whatsoever. Soft Reconfig should not be used anymore, as it was just a workaround. Simply do nothing, and you get Route Refresh ;)
Best regards,
Peter
Depends whether your BGP peers support the route refresh option. Most modern BGP implementations should.
True. However, RFC 2918 is almost 17 years old - it would be my understanding that any decent BGP implementation supports this. In fact, I haven't come across a BGP implementation that does not.
In case of any doubts, however, the show ip bgp neighbor X.X.X.X is very helpful here: It shows the capabilities advertised and received with this neighbor, so if there is the Route Refresh advertised and received, it's okay to be used.
route-views>show ip bgp neighbors 4.69.184.193
BGP neighbor is 4.69.184.193, remote AS 3356, external link
Description: Level3
BGP version 4, remote router ID 4.69.184.193
BGP state = Established, up for 7w0d
Last read 00:00:12, last write 00:00:10, hold time is 180, keepalive interval is 60 seconds
Configured hold time is 600, keepalive interval is 100 seconds
Minimum holdtime from neighbor is 0 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised
Address family IPv4 Unicast: advertised and received
Address family IPv4 Multicast: advertised and received
Enhanced Refresh Capability: advertised
Multisession Capability:
Stateful switchover support enabled: NO for session 1
Message statistics:
[ ... cut ... ]
There is one exception where the soft-reconfiguration inboud might be useful: It allows to use the show ip bgp neighbor X.X.X.X received-routes to see all unfiltered and unmodified routes received from that neighbor. It can be a valuable troubleshooting and diagnostic tool, but the added value of this tool has to be carefully weighed against the potentially huge increase in the memory footprint.
In any case, the bottom line stands - to get Route Refresh, you don't need to do anything. If both BGP neighbors support it, you're likely using it already without even knowing.
Best regards,
Peter