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.
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.
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:
|A new route-map or prefix list has been applied inbound||Any Inbound Reset||Once applied, any new prefix being received will be passed through the applied route-maps or prefix lists. This can be triggered with a Hard/Soft inbound reset or a Route-Refresh.|
|A new prefix list has been applied outbound||Hard Reset||If an outbound prefix list has been applied that aims to filter out some prefixes that have already been sent, this requires a Hard Reset to instruct the remote router to clear all prefixes and to pass each prefix through the new outbound prefix list. A Soft Reset outbound will correctly filter out the intended prefixes, but they will not be withdrawn from the remote router.|
|A historic prefix can still be seen in the received routes, and it needs removing||Hard Reset or Route-Refresh||If some sort of bug or glitch in the BGP operation has meant that a Route Withdrawal has not been properly processed, this can only be remedied with a Hard Reset. A Route-Refresh will not resend the Route Withdrawal message, and a Soft Reset will only cache the current table with the historic prefix.|
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!