Resetting BGP Sessions

BGP often handles huge volumes of routing information. A BGP router unable to go through the huge BGP table to recalculate the invalid entries upon a BGP routing policy change occurs, eg: when distribute lists, prefix lists, and filter lists are changed. The BGP router also unable to determine the advertised routes that should be withdrawn from a neighbor. Also imagine that a configuration change after another would cause the whole process to start all over again. To avoid these problems, Cisco IOS enforces the new routing policy only upon routes that received and transmitted after the BGP routing policy configuration change has been performed.

If the routing policy change wanted to be applied upon all routes, we must force the router to process all routes through the new filter. If the filter is applied upon incoming information, the router wants its neighbor to resend its BGP table so that it passes through the new filter; if the filter is applied upon outgoing information, the router will resend its BGP table through the new filter. Resetting the affected established BGP sessions after a BGP routing policy changes performs the mentioned actions. When the BGP sessions are reset, all information received from those sessions will be removed from the BGP table; the remote neighbor detects a BGP session DOWN state and also removes the received routes. After a while (30 – 60 seconds), the BGP sessions are reestablished automatically, and the BGP table is exchanged again and the routing information is being passed through and processed by the new filter.

The clear ip bgp {* | ip-addr} [{in | out} | {soft [in | out]}] privileged command resets BGP sessions and removes entries from the BGP table. Issue this command upon a routing policy change to ensure that the change is activated and the peers are informed regarding the change. The * keyword resets all current BGP sessions; while the ip-addr identifies a specific neighbor for which the BGP session will be reset. The optional soft keyword performs a soft reset, along with the optional in and out keywords trigger inbound or outbound soft reset. If both the keywords not specified, both inbound and outbound soft resets will be triggered.

The clear ip bgp {ip-addr} out and clear ip bgp {ip-addr} soft out privileged commands perform the same function – cause the router to reevaluate its existing BGP table and create a new BGP Update for the specified neighbor. Both the clear ip bgp {ip-addr} in and clear ip bgp {ip-addr} soft in privileged commands perform soft reset either through the dynamic soft reset with the Route Refresh feature or soft reconfiguration depends upon whether the soft-reconfiguration inbound option has been configured for the particular neighbor.

The clear ip bgp peer-group {peer-group-name} privileged command resets the BGP sessions for all members of a BGP peer group.

Resetting BGP sessions and clearing the BGP table disrupts routing and packet forwarding. Resetting a BGP session is a method of information the neighbor(s) regarding a policy change. The clear ip bgp command without the soft keyword performs a hard reset of BGP sessions, which means that the router on which this command is issued closes and reestablishes the corresponding TCP connections, and resends all information to the affected neighbor(s).

Issuing the clear ip bgp * command causes a very disastrous event. It completely deleted the BGP table on the router on which this command is issued, forces it to relearn all networks from every neighbor, which will take a considerable number of CPU cycles to process all the information that sent by all neighbors about the same time. If the clear ip bgp {ip-addr} command is issued, only one neighbor is reset and affected at a time, at the impact is less severe. However, this approach takes longer time for the routing policy to take effect to all neighbors, as the reset must be done individually rather than all at once using the clear ip bgp * command.

Below shows the output of the debug ip bgp updates and clear ip bgp * commands on RT1:

RT1#debug ip bgp updates
BGP updates debugging is on
RT1#
RT1#clear ip bgp *
RT1#
00:01:58: %BGP-5-ADJCHANGE: neighbor 12.12.12.2 Down User reset
00:02:34: %BGP-5-ADJCHANGE: neighbor 12.12.12.2 Up
00:02:35: BGP(0): 12.12.12.2 rcvd UPDATE w/ attr: nexthop 12.12.12.2, origin i, metric 0, path 65002
00:02:35: BGP(0): 12.12.12.2 rcvd 192.168.2.0/24
00:02:35: BGP(0): nettable_walker 192.168.1.0/24 route sourced locally
00:02:35: BGP(0): Revise route installing 1 of 1 route for 192.168.2.0/24 -> 12.12.12.2 to main IP table
00:02:35: BGP(0): 12.12.12.2 computing updates, afi 0, neighbor version 0, table version 3, starting at 0.0.0.0
00:02:35: BGP(0): 12.12.12.2 send UPDATE (format) 192.168.1.0/24, next 12.12.12.1, metric 0, path
00:02:35: BGP(0): 12.12.12.2 1 updates enqueued (average=52, maximum=52)
00:02:35: BGP(0): 12.12.12.2 update run completed, afi 0, ran for 8ms, neighbor version 0, start version 3, throttled to 3
00:02:35: BGP(0): 12.12.12.2 initial update completed
RT1#
======================================================================
RT2#
00:01:59: %BGP-5-ADJCHANGE: neighbor 12.12.12.1 Down Peer closed the session
00:02:34: %BGP-5-ADJCHANGE: neighbor 12.12.12.1 Up
RT2#

The soft out option allows BGP to perform a soft reset for outbound updates, in which it creates a new version of the BGP table are sends the new set of updates to the specified neighbors. The update includes the withdrawn routes in which the neighbors must not use anyone based on the new outbound policy. Outbound soft reconfiguration does not have any memory overhead. An outbound reconfiguration can also be triggered on the other side of the BGP session to make the new inbound policy on the local router to take effect.

The soft in option generates new inbound updates without resetting the BGP sessions, but it can be memory-intensive as it requires the storing of unprocessed routing table update information. BGP does not allow a router to force its peer to send its entire table. Inbound soft reconfiguration must be configured on a router for it to process the routes in the BGP table upon changing the inbound BGP policy without performing a hard reset.

There are 2 ways to perform an inbound soft reconfiguration – using the stored routing update information and dynamically using the Route Refresh feature. The neighbor {ip-addr | peer-group-name} soft-reconfiguration inbound command configures the BGP process to save all updates learned from the specified neighbor(s) in case the inbound policy is changed. The BGP process retains an unfiltered table of what the neighbor(s) is sent in the BGP table. Hence it is no need to force the other side to resend everything upon the inbound policy change. After configured the neighbor soft-reconfiguration inbound command for the first time, reset all the current BGP sessions so that all the routing update information will be resent by all neighbors and can then be stored in the local BGP table.
Note: If the BGP routers support the BGP Route Refresh capability, it is not necessary to perform a hard reset after configured the neighbor soft-reconfiguration inbound command.
Note: In general, don’t ever implement soft reconfiguration to prevent high memory utilization and most BGP speakers nowadays already support the Route Refresh capability.

The BGP Dynamic Soft Reset feature that available in Cisco IOS Software Release 12.1 and later utilizes the BGP Route Refresh capability to allow the dynamic requests of inbound BGP routing updates that does not require storing of unprocessed routing table update information and therefore has no memory overhead. This new method does not require any pre-configuration. Use the show ip bgp neighbors {ip-addr} command to determine whether a neighbor supports the Route Refresh capability. If the BGP routers support the Route Refresh capability, both the clear ip bgp in and clear ip bgp soft in commands can be issued to perform dynamic soft reconfiguration.

The BGP Route Refresh capability provides a mechanism to request a re-advertisement of the Adj-RIB-Out from a BGP peer. The Adj-RIB-In stores the unprocessed routing information that has been learned via inbound update messages; the Loc-RIB contains the local routing information that has been processed by applying the local routing policies upon the routing information contained in the Adj-RIB-In; and the Adj-RIB-Out stores the routing information that the local router has selected for advertisement to its peers; in which the routing information in the Loc-RIB has been processed through the outbound policies, eg: filtering and path attributes manipulation.

BGP routers implement RFC 2842 – Capabilities Advertisement with BGP-4 to advertise the RFC 2918 BGP Route Refresh capability between BGP peers using the Optional Parameters field in the BGP Open messages. BGP Route Refresh message is a new BGP message type defined using the BGP message Type Code 5.