BGP Clears: Soft Resets vs Hard Resets, and why are they necessary?

BGP resets are a common operational tool employed to manipulate exchanged routing tables and to troubleshoot faulty routing operation. Here I hope to explain what these resets are, how they work, and why you may choose to trigger one...

BGP Session Establishment 101

So BGP, our favourite Internet routing protocol, works by first establishing a Layer 3 TCP/179 connection between the two BGP speakers and exchanging BGP Open messages. The exchange of these messages form the identification and authentication phase of BGP peering, where each speaker declares their Router ID (RID) and Autonomous System Number (ASN), combined with some optional extension parameters like Route Refresh capabilities. Once each speaker has processed the received Open message and responded with a friendly Keepalive, they proceed to exchanging routes.

In the next phase, the Local RIB (Loc-RIB) is fed into the BGP process and each prefix is passed through the BGP Decision Process one by one to be analysed and have path attributes assigned. Once processed, a BGP Update message is crafted for each prefix containing all it's path attributes, and the two BGP speakers begin the length processes of exchanging these BGP Updates over the TCP session, with all of the error handling and windowing that comes with TCP. While a large number of routes can be un-advertised in a single Route Withdrawal message, the fact that each prefix requires it's own Update message means that this phase of the session establishment can often take up to a few minutes to complete, and a good amount of RAM to maintain from there on.

Once all Update messages have been exchanged, the session will move into Established state, where the TCP/179 connection remains stable and dormant, save for the regular exchange of Keepalive messages and the odd Update and Route Withdrawal message.

At this point it is important to grasp the fact that all Update messages have been exchanged, and will never be sent a second time for any given prefix. The protocol is based on the assumption that each speaker will have no problem recalling the prefixes that were swapped when the session was first established, though over 30 years since it's invention in 1989, occasional technical anomalies mean that sometimes odd behaviour can be noticed in BGP, especially when running outdated firmware versions and maintaining BGP sessions with uptimes of many years. Sometimes BGP needs a restart, and here we will discuss the "hows" and "whys" of resetting BGP sessions....

The different types of BGP clear

A Soft Reset is a means to emulate the reestablishment of a BGP session, and there are two variations of Soft Reset:

• Dynamic Soft Reset
• Soft Reset

Dynamic Soft Resets (RFC 2918)

If both BGP Speakers support the BGP extension capabilities as defined in RFC 2918, then this method allows the exchange of Route-Refresh requests.

You can check whether whether the neighbour supports this BGP extension with show ip bgp neighbors:

BGP neighbor is X.X.X.X,  remote AS YYYY, external link
 Description: BGP Neighbor
  BGP version 4, remote router ID X.X.X.X
  BGP state = Established, up for XwXd

  Neighbor capabilities:
    Route refresh: advertised and received(new)

This method can be triggered either outbound or inbound:

• Inbound: A Dynamic Soft Clear Inbound will send a Route-Refresh request which will instruct the remote neighbour to resend the entire BGP table again as Update messages. These Updates will be processed one by one in the same manner as a new session establishment, while routing operation will continue based on entries stored in the current BGP Table.
• Outbound: A Dynamic Soft Clear Outbound will trigger the local router to run the Loc-RIB through the BGP process, as well as any applied outbound prefix-sets, max-prefix limits and route-maps, and will resend Update messages for each prefix again, which it turn will be re-processed by the remote Speaker and passed through their Inbound configuration once again.

Soft Resets

If neither device supports the Route-Refresh extension, a traditional Soft Reset provides a means of achieving the same effect with what is effectively a software trick:

• Inbound: A Soft Clear Inbound will allocate RAM for the creation of a second copy of the BGP table and will pass it into the BGP process again, running it through all prefix-sets, max-prefix limits and route-maps attached to this session. This method is useful for re-configuring the BGP session parameters without interrupting routing decisions.
• Outbound: A Soft Clear Outbound is identical to the method used in a Dynamic Soft Clear Outbound, and the Loc-RIB will be processed and sent to the remote neighbour as Update messages.

Neither Soft Reset method will take down the TCP connection or change the BGP state, and are entirely single-sided operations. When one BGP speaker is completing an outbound or inbound Soft Reset, the remote speaker is entirely unaware and unaffected, and will continue normal routing operation.

Hard Resets

A Hard Reset will instruct the local router to terminate the TCP/179 connection to the remote neighbour, effectively tearing down the routing adjacency. Once terminated, a BGP Open message is sent to the remote neighbour and the session establishment process is completed from scratch.

This method is impacting and routing operation will be halted until the BGP sessions move to Established state, and so Hard Resets are usually only employed as a last resort.

When to use which

Here are a few scenarios to demonstrate and explain when and why a BGP reset may be employed:

I hope this has managed to provided some sort of informative insight into BGP operation and share some valuable experience with regards to resetting BGP sessions.

Thanks for reading!