Understanding the BGP Peering Process

When routers run BGP , they don’t start exchanging route information right away. Before they can share anything, they need to form a stable connection, called a BGP peering session. This process involves multiple states, each indicating what’s happening behind the scenes as the routers try to establish a session.

To make this easier to understand, it helps to compare with how OSPF forms its neighbor relationships – it also goes through defined states like Init, 2-Way, and Full. BGP has its own set of states that a router goes through as it tries to form a session with its neighbor.

Unlike OSPF, BGP doesn’t use multicast or any hello mechanism to discover neighbors. Every BGP neighbor must be configured manually, and the whole communication happens over TCP (port 179). So, let’s go step by step and see what happens internally when we configure BGP.

---

Initial State – Idle

As soon as we configure the BGP process on a router and define a neighbor using the neighbor command, BGP goes into the Idle state.

In the Idle state, BGP is basically doing all the background preparations:

• It’s checking the configuration,
• Setting up internal resources,
• And most importantly, it tries to initiate a TCP connection with the neighbor by sending a TCP SYN packet.

Once this TCP SYN is sent, BGP will move on to the Connect state.

---

Connect State – Waiting for TCP Handshake

In the Connect state, BGP is waiting for the TCP three-way handshake to complete.

If the TCP handshake is successful (meaning the neighbor replied with SYN-ACK and we sent back ACK), then we have a TCP session ready between the two routers.

This is the basic transport layer connectivity that BGP needs. Once this is ready, BGP will immediately send an OPEN packet to the neighbor and transition to the OpenSent state.

---

But what if the handshake fails?

Active State – Retry TCP Connection

If the TCP handshake fails (maybe because the neighbor is not configured yet or the peer IP is unreachable), BGP will move from Connect state to Active state.

Active state doesn’t mean that everything is fine — in fact, it means BGP is trying again to re-establish the connection.

You’ll usually see BGP stuck in Active state when:

• Only one side is configured for BGP
• TCP port 179 is blocked
• There’s a mismatch in the neighbor IP
• There’s a routing issue

If BGP is able to retry and establish TCP successfully from here, it will go back to the Connect state and continue the process.

---

OpenSent – Exchanging Open Messages

Once the TCP handshake is done and BGP sends the OPEN packet, it will enter the OpenSent state.

In this state:

• We have already sent our OPEN message
• We are waiting to receive the OPEN message from the neighbor

The OPEN packet includes several important parameters:

• BGP version (usually version 4)
• AS number
• BGP Router ID
• Hold time
• Optional parameters (like authentication/password, if configured)

Once we receive the OPEN message from the neighbor, we will compare all the fields. If there’s a mismatch (say, different AS number), the connection will be reset. If everything is fine, BGP will respond and move to the OpenConfirm state.

---

OpenConfirm – Waiting for Keepalive

In the OpenConfirm state:

• Both routers have exchanged their OPEN messages
• Now they are just waiting for a KEEPALIVE message from each other to confirm that everything is good

This is a short and simple state. If we receive a valid KEEPALIVE message from the neighbor, it means the neighbor has accepted our OPEN message, and the peering is now fully established.

At this point, BGP will move to the final state – Established.

---

Established – Peering Complete

In the Established state, BGP peering is up.

This is the state where:

• BGP will start sending UPDATE messages, which include route advertisements (NLRI)
• BGP will also receive updates from the neighbor

From now on, KEEPALIVE messages will be sent periodically to maintain the session, and any change in routes will be communicated through UPDATE packets.

But one thing to note – BGP does not have a separate state to indicate that route exchange is complete (unlike OSPF, which uses Full state). So once you’re in the Established state, BGP might still be in the middle of exchanging routes — there’s no way to know just from the state itself.

---

Quick Summary of All BGP States

State	Description
Idle	Initial state. Prepares resources and sends TCP SYN.
Connect	Waiting for TCP handshake to complete.
Active	TCP failed. Retrying connection.
OpenSent	Sent OPEN packet, waiting for neighbor’s OPEN.
OpenConfirm	Exchanged OPENs, waiting for KEEPALIVE.
Established	Peering is up. Routes are exchanged.

---

What Happens If Something Goes Wrong?

• If TCP fails: BGP stays in Active
• If OPEN message parameters mismatch: BGP resets the session, goes back to Idle
• If KEEPALIVE not received within Hold time: session is dropped
• If password (MD5) mismatch: session never reaches OpenConfirm

So, every stage has checks. If something fails, BGP will drop the session and restart from Idle.

---

A Note on Troubleshooting

If BGP is stuck in Idle or Active, it usually means:

• The neighbor is not reachable (routing or interface issue)
• The neighbor is not configured with a matching BGP session
• TCP port 179 is blocked (ACLs or firewalls)
• Authentication mismatch (password not matching)
• AS number mismatch in the neighbor configuration