Routing protocols help “glue” the internet together, and one of the most important of these is the Border Gateway Protocol (BGP). This article explains the BGP states that represent the neighborship between two devices and how to establish a successful session.
These states are mandatory. Every new session goes through various phases until it creates a successful BGP connection.
Overview of BGP States
Six states are involved in the BGP process as defined by the BGP finite state machine (FSM). The FSM illustrates what actions play a role at each stage of BGP session establishment. The diagram below shows how the transition between the states might occur.
The table below summarizes all the BGP states and the pertinent processes associated with each. It is worth noting that the first three states are concerned more with TCP, while the last three have more to do with BGP only. It is not uncommon to hear them referred to as two distinct sets: TCP phases and BGP phases.
Deep Dive into BGP States
Here, we will explore each of the BGP states in depth and explain how the transition between them occurs.
The first BGP state listens for an incoming connection request from its peer router. This connection request is expected when a new BGP session is configured or when the ConnectRetry timer is restarted.
BGP may also get stuck in this state for many reasons. TCP port 179 or ports over 1023 being closed for any reason will result in connections being rejected.
The ConnectRetry timer allows 120 seconds by default for connection requests between the routers to complete before shifting to the next state. During this time, BGP will listen for incoming connections and will try to connect with the remote neighbor actively. When the two routers start the TCP connection, BGP shifts to the Connect state.
In the Connect state, BGP tries to complete the three-way TCP handshake. If successful, it resets the ConnectRetry timer and shifts to the OpenSent state.
If the timer elapses before a TCP connection is established, the time is reset, and BGP moves to the Active State.
If anything unexpected occurs, BGP will go back to the Idle state and start the process again.
BGP will kick off and attempt a new TCP connection in the Active state. If it is established successfully, it will send an Open message to its peer and move to the OpenSent state.
The progress may revert to the Connect state if the ConnectRetry timer expires before the TCP session is established, or it may go back to Idle in case of a BGP reset event.
In the OpenSent state, BGP is listening for an Open message from its neighbor. Once received, it checks for matching parameters and potential errors. The most notable variables in the Open message are as follows:
- BGP version (which should match on both ends).
- The autonomous system (AS) numbers.
- The source IP address of the configured neighbor.
- Router-ID uniqueness (there should be no duplicates).
- Security parameters (TTL, password, etc.).
- Capabilities (e.g., use AS numbers on 4 bytes instead of 2 bytes, enable multiprotocol for IPv6).
If there are no errors, BGP starts to send Keepalive messages and negotiates the hold time.
BGP will send a Notification and return to the Idle state if errors or mismatches are found in the Open message. If the TCP session drops for some reason, BGP will go to the Active state and attempt to complete the three-way handshake.
In the OpenConfirm state, BGP listens for Keepalive messages from its peer. If they are sent and received successfully, BGP shifts to the final Established state.
At this point, if a Notification (error message) is received, BGP will jump back to the Idle state again.
In the Established state, BGP neighbor adjacency has been created. Update and Keepalive messages are exchanged, and the Hold timer is reset with every message.
If the Hold timer expires before one of these messages is received, BGP will revert to the Idle state. Receiving a Notification message will also result in going back to Idle.
In this section, we will demonstrate how to configure BGP in a lab environment and look under the hood with Wireshark to see how BGP states come into play.
We have already pre configured our two routers with IP addresses and verified connectivity.
Next, we configure BGP on R20 and specify its neighbor.
At this point, we can see how R20 is trying to establish a TCP session, but it’s failing as we haven’t configured R21 yet.
Configuring BGP on the R21 side:
Almost immediately, we see the adjacency forming successfully.
Inspecting the traffic in Wireshark, we can see some of the states and messages we discussed earlier. This is the best-case scenario when the BGP connection is brought up smoothly:
- TCP connection
- Open message
- Keepalive/Update messages
Now suppose something happens and tears the BGP session down. We will simulate that with the command below.
Now R21 sends a Notification message to R20 along with a FIN message to cut the TCP session.
Now suppose we configure R21 to expect an iBGP session (same AS) instead of eBGP (different AS). R20 is still in AS20, but R21 will expect it to be in AS21.
We get another Notification message saying Bad Peer AS.
Next, we fix that and get BGP back to working order. Now we decide to create a loopback address and advertise it over BGP.
R20 sends an Update message to its neighbor with the new prefix.
Here are some key points to consider when configuring BGP to avoid session issues and optimize performance:
- The BGP version should match on both ends.
- Use the correct AS numbers.
- Configure BGP using loopback addresses instead of physical interfaces.
- Summarize routes to avoid large routing tables.
- Filter the advertised and accepted routes.
In this article, we discussed the BGP states and described in detail how they operate during session establishment. We demonstrated these principles in a lab environment to see how they play out in real time. We also touched on best practices for configuring a BGP session and optimizing for performance.
This BGP monitoring guide provides network administrators and engineers with the technical and informational background necessary to successfully and responsibly monitor BGP in their own networks.
Learn about the six states of the BGP protocol and follow instructions with examples to learn how to configure BGP correctly.
Learn the benefits and best practices for implementing BGP multipath along with step by step configuration examples.
Learn how the BGP protocol chooses the best route for forwarding traffic, understand its use cases, and follow configuration instructions along with examples.
Learn BGP hijacking in depth, including how BGP advertisements work, how bad actors perform hijacks, and how you can detect and prevent BGP route hijacking.
Understand the unintentional causes and the repercussions of BGP resets and learn the best practices for safely executing them.
Learn the top tips, and tricks to assist you in quickly diagnosing and fixing BGP session issues using features ranging from ACLs to multihop TTL.
Understand how the BGP local preference attribute determines the preferred outbound path from the local AS by following examples and instructions.
Learn how a BGP tunnel broker is used to provide IPv6 connectivity to a network that exists in a region of the Internet that supports only IPv4.
Follow a detailed explanation of the BGP MED attributes and follow examples and instructions for correctly configuring it in your environment.