If you’ve ever typed show ip bgp summary and noticed your BGP neighbor sitting in Active or Connect, you might have wondered:
“Why does BGP go through so many steps before finally exchanging routes?”
You’re not alone — almost every network engineer has stared at these states at some point and scratched their head.
The truth is… these states aren’t “delays” or “issues” — they’re part of a well-structured handshake process that ensures both routers are ready before sending even a single route.
So, let’s walk through these six BGP neighbor states together, one step at a time, so that by the end of this blog, you’ll be able to confidently explain them to anyone (including an interviewer).
Why BGP Has States in the First Place
BGP isn’t like OSPF or EIGRP, which send out hellos and discover neighbors automatically.
It’s TCP-based (port 179), and the neighbor relationship must be explicitly configured.
You can think of BGP as setting up a business contract — it requires formal introductions, capability checks, and agreement on terms before any real business (routing) happens.
This is why the states exist — each one is a checkpoint in the process.
The 6 BGP Neighbor States
When two BGP routers try to become neighbors, they move through six main states in a very specific order:
- Idle
- Connect
- Active
- OpenSent
- OpenConfirm
- Established
Let’s walk through them in plain, human language.
1. Idle State – “The Calm Before the Storm”
This is where everything starts.
Your router knows that it’s supposed to form a BGP session with a neighbor, but it hasn’t started the TCP connection yet.
In Idle:
- The BGP process initializes.
- The router checks the neighbor configuration (IP and ASN).
- It waits for the perfect moment to start the TCP handshake.
Analogy: You’ve got someone’s phone number saved, but you haven’t dialed yet.
If all is good, we move to Connect.
2. Connect State – “Dialing the Number”
Here, your router tries to establish a TCP connection to the neighbor on port 179.
Two possibilities:
- Success → Move to OpenSent (progressing).
- Failure → Move to Active (retrying).
Why Connect is Important:
Without this state, there’s no first handshake attempt. It’s the initial “Let’s talk” moment.
3. Active State – “Redialing”
The name can be misleading — “Active” sounds like everything’s fine, but actually, it means the first attempt failed, and the router is trying again.
Possible reasons for being stuck here:
- No IP route to the neighbor.
- Wrong AS number in configuration.
- Firewall blocking TCP port 179.
If TCP connection succeeds now, we go to OpenSent.
4. OpenSent State – “Introducing Ourselves”
With TCP now established, the routers send OPEN messages.
This contains:
- BGP version
- AS number
- Router ID
- Hold timers
- BGP capabilities
Analogy: Two people meeting for the first time, shaking hands, and saying:
“Hi, I’m R1, I’m from AS65001, and here’s what I can do.”
If both sides like what they hear → OpenConfirm.
5. OpenConfirm State – “Final Handshake”
Here, both routers have exchanged OPEN messages and are now sending KEEPALIVE messages.
This is the “I can still hear you” check before starting real route exchange.
If everything is fine, the relationship moves to Established.
6. Established State – “Let’s Do Business”
This is the final goal.
Routers start exchanging UPDATE messages with actual routing information.
From this point:
- Routes are added based on policies.
- The session stays established unless something breaks (like a TCP failure, timer expiry, or policy change).
The Connect and Active states in BGP sometimes confuse people because they both sound like “trying to connect.”
But they actually serve different purposes in the TCP session establishment process.
Let’s break it down simply:
1. Connect State – First Attempt to Establish TCP
- What happens here:
The router has IP reachability to the neighbor and is actively trying to initiate a TCP connection on port 179. - Goal:
Establish a TCP handshake successfully. - Next step:
- If TCP connection succeeds → Move to OpenSent.
- If TCP connection fails (e.g., timeout) → Move to Active to retry.
Think of it like: You have the right phone number, you dial it, and you’re waiting for the other person to pick up.
2. Active State – Retrying After Failure
- What happens here:
The router failed to establish TCP in the Connect state and is now retrying. - Goal:
Attempt TCP connection again and recover from the failed attempt. - Next step:
- If retry is successful → Move to OpenSent.
- If retry fails again → Go back to Connect and try again (loop).
Think of it like: The call didn’t go through the first time, so you hang up and redial.
Key Difference
| State | Purpose | When It Occurs |
| Connect | First attempt to initiate a TCP connection with the neighbor. | Right after BGP neighbor command and IP reachability is confirmed. |
| Active | Retry attempt after TCP connection in Connect state fails. | After a failed Connect attempt due to timeout or rejection. |
Why both are needed:
BGP uses them to handle connection retries gracefully instead of continuously hammering TCP connection attempts. It’s a controlled process:
Connect → (Fail) → Active → (Retry) → Connect … until either success or the admin intervenes.
Quick Troubleshooting by State
- Idle → Check neighbor config and reachability.
- Connect → Verify TCP 179 reachability and IP correctness.
- Active → Confirm routing path exists to neighbor.
- OpenSent → Mismatched BGP versions or timers.
- OpenConfirm → Keepalive blocked/dropped.
- Established → All good — exchange routes.
Final Thoughts
BGP states aren’t random — they’re a safety checklist for routers.
If you understand what each state means, you can pinpoint exactly where the problem is when a neighbor won’t establish.