Untangling Soft Reconfiguration and Dynamic Inbound Soft Reset (RFC 2918) in BGP

In BGP routing, the terms soft reconfiguration and dynamic inbound soft reset often get conflated, but they refer to distinct capabilities. In this post, I’ll clarify the difference between these two methods for clearing BGP sessions.

Soft Reconfiguration

Soft reconfiguration is the older method, requiring the command “neighbor x.x.x.x soft-reconfiguration inbound” to be manually configured for each BGP neighbor. When enabled, this stores an unfiltered copy of all routes advertised by that neighbor. Then when clearing BGP with “clear ip bgp * soft in“, the session is re-established, and the stored routes are filtered again per the current inbound policy.

The downside is that soft reconfiguration is resource intensive, especially for memory. Every advertised route must be stored twice – once filtered and once unfiltered. As routing tables grow, so does the memory footprint.

Dynamic Inbound Soft Reset

With the dynamic inbound soft reset, also known as route refresh (RFC 2918), no configuration is needed. Routers automatically negotiate the route refresh capability when establishing a BGP session. When clearing BGP, the router sends a ROUTE-REFRESH message to compatible neighbors, prompting them to re-advertise their routes.

Functionally, “clear ip bgp * soft” works the same for both methods. But route refresh is more efficient since it avoids storing duplicate sets of routes.

Essentially all of the latest routers automatically do route refresh RFC 2918. There is no need to configure it manually. This is because RFC 2918 is a standard BGP capability, and most router vendors support it by default.

Redundant Configuration

Here’s the catch – many guides and configs still include “neighbor x.x.x.x soft-reconfiguration inbound” even when route refresh is supported. This is redundant and wasteful yet persists as a common misconfiguration. If both soft reconfig and route refresh are enabled, route refresh is ignored to maintain separate filtered/unfiltered tables.

The only case where soft reconfig is needed is if the neighbor does not support route refresh. Otherwise, take advantage of dynamic inbound soft reset to optimize memory usage.

In summary, make sure to avoid redundant soft reconfig commands. Leverage built-in route refresh instead for efficient BGP session clearing. Understanding the distinction between these two features will allow you to utilize them properly.

Adj-RIB-In Table

bgp-soft-recon.png

Keep in mind that BGP routers utilize an Adj-RIB-In table to store all received routes before applying routing policies. While this approach ensures a comprehensive understanding of all available routes, it can demand significant memory resources, especially in older or memory-limited modern routers. This issue intensifies when policy changes occur, as routers may temporarily store old and new routing information, doubling the memory requirements.

To maintain network stability, network operators must meticulously plan for capacity and consistently monitor router memory usage. When memory resources are insufficient, upgrading router memory or employing strategies like route summarization and selective route, advertisement can help mitigate potential issues. Understanding these aspects is crucial for effectively managing large network connections with BGP.

Cisco Specific

In networking, Cisco’s implementation of the Border Gateway Protocol (BGP) differs slightly from other vendors regarding storing inbound routing information. Specifically, Cisco’s IOS, IOS XE, and IOS XR do not maintain an Adj-RIB-In (Adjacent Routing Information Base – Inbound) by default for BGP neighbors. This means that they don’t automatically keep an unaltered record of all routes advertised by their neighbors.

Cisco provides the ‘soft-reconfiguration inbound‘ command to mimic the Adj-RIB-In functionality. When configured for each BGP neighbor, this command enables the router to store an unaltered copy of all routes advertised by that neighbor. While this feature offers similar functionality to Adj-RIB-In found in other vendor platforms, it is not an identical implementation.

However, there’s a trade-off. The ‘soft-reconfiguration inbound‘ command is more resource-intensive as it keeps duplicate sets of routes. Therefore, for most modern network deployments, an alternative method known as route refresh, as per RFC 2918, is typically preferred. Route refresh allows BGP peers to request a re-advertisement of routes from their neighbors, thereby avoiding constantly storing unaltered routes.

While Cisco doesn’t implement a true Adj-RIB-In by default, it offers the ‘soft-reconfiguration inbound‘ command as a workaround. This command is required if you need to view unmodified advertised routes, such as for troubleshooting. Nevertheless, the route refresh capability is generally recommended for efficiency due to its resource consumption.

The key takeaway is that the ‘soft-reconfiguration inbound‘ command enables the storage of unmodified advertised routes, while route refresh provides an efficient mechanism for resetting BGP sessions. Understanding when and where each is applicable will empower network operators to make the most of these features in maintaining their BGP routing infrastructure.