BGP has six states, and every page lists all six. That is a poor way to learn them, because three of the six are transitional by construction: each waits on a single message or timer and leaves the moment it arrives or fails.
What you find on screen when something is broken is almost always Idle, Active or Established, and each points at a different layer. Idle means the router is not trying, which is configuration or an unroutable peer.
Active means it is trying and TCP is failing, which is a firewall, an address or an access list. Established means the session is fine, so any missing routes are a policy problem rather than a neighbor problem.
- The six are Idle, Connect, Active, OpenSent, OpenConfirm, Established
- Connect, OpenSent and OpenConfirm pass in milliseconds or fail onward
- Idle is the router not trying, and it refuses incoming connections too
- Active is the failure state, despite the name: TCP is not completing
- Established proves the session, not that your prefixes arrived
On this page
- The six, and which of them you will ever meet
- Idle, which means nothing is being attempted
- Active, which is the one that sounds healthy
- Established, and why it is not the end of the argument
- What the router says when a session leaves a state
- Reading a stuck state as a diagnosis
- Where people go wrong
- Comparison
- FAQ
The sixThe six, and which of them you will ever meet
RFC 4271 defines the BGP finite state machine in section 8.2.2. Here is the whole list of BGP states, with the part every other page leaves out: whether you will ever catch a neighbor sitting in it.
| State | What it means | Will you see it |
|---|---|---|
| Idle | The router is not attempting the session at all | Yes, and it is a real answer |
| Connect | Waiting for a TCP connection the router has already started | Rarely, it resolves or fails immediately |
| Active | Trying to get a TCP connection up, and not succeeding | Yes, and this is the common failure |
| OpenSent | TCP is up, an OPEN has been sent, waiting for the reply | Rarely, unless the OPEN is being rejected |
| OpenConfirm | The OPEN was accepted, waiting for a KEEPALIVE message | Rarely |
| Established | The session is up and routes are being exchanged | Yes, this is the working state |
The three marked rarely are not less important, they are less observable. Each waits on exactly one thing: a TCP handshake to complete, an OPEN message to arrive, a KEEPALIVE message to arrive. On a working network that takes milliseconds, and on a broken one the state machine drops to Idle or Active rather than sitting there.
A state you can catch by typing a command twice is a state worth understanding; the other three are worth recognizing when they do stick, which is a narrower and more specific signal covered below.
IdleIdle, which means nothing is being attempted
RFC 4271 is blunt about this state. In Idle, the machine refuses all incoming BGP connections for that peer, and no resources are allocated to it.
That word refuses matters. Idle is not a router waiting patiently. It is a router that has decided not to participate in the neighbor session, and it will not accept a connection from the other side either. So a session stuck in Idle is not going to be fixed by the far end trying harder.
The causes are all local and all administrative rather than networky:
The neighbor is administratively shut down. Somebody disabled it, and BGP is doing exactly what it was told.
There is no route to the peer address. BGP needs to reach its neighbor before it can talk to it. If the peer address is not in the routing table, there is nothing to connect to. This is the most common cause on an internal session, where the neighbor address is a loopback learned from an interior routing protocol.
The configuration is incomplete or wrong. A missing remote AS number in the neighbor config, a peer group that was never applied, a neighbor statement pointing at an address that belongs to nobody.
The session was damped after repeated failures. Some implementations hold a peer in Idle for a growing interval after it flaps, which is a feature and looks identical to a fault.
ActiveActive, which is the one that sounds healthy
This is the state worth the whole page. RFC 4271 says that in the Active state the machine is trying to acquire a peer by listening for, and accepting, a TCP connection.
Read that against the word. Active does not mean the session is active. It means the router is still actively attempting to get a TCP connection and has not got one. It is a failure state wearing an encouraging name, and a session that alternates between Connect and Active is a session that is not working at all.
Because the problem is TCP, the causes are TCP causes, and they are the same list you would work through for any port that will not open:
Something is blocking TCP 179. A firewall between the two routers, or an access list on one of them. BGP has no way to distinguish a blocked network path from the neighbor being switched off.
The neighbor address is wrong or unreachable. A typo, or a peering address that has moved, or a route that exists in one direction only. Return traffic matters: a TCP connection needs both directions.
The far end is not configured for you. It is refusing the connection because it does not know who you are, which from your side looks like a network problem.
The source address does not match what the remote router expects. The remote neighbor config expects connections from a specific address, often a loopback, and the router is sourcing them from a physical interface instead. The remote end rejects a connection it cannot match to a configured neighbor.
The diagnostic that separates these in one step is to test TCP 179 to the peer directly rather than reading the BGP state again. If the port does not open, this is not a BGP problem yet, and every minute spent in the BGP configuration is a minute spent in the wrong place.
EstablishedEstablished, and why it is not the end of the argument
Established means the two routers have exchanged OPEN messages, agreed the parameters and are exchanging routing updates. The neighbor session works.
It does not mean the routes you expected have arrived. This is where a great deal of time is lost, because Established looks like success and the next question is a different subject entirely.
If the session is up and a prefix is missing, the cause is in policy rather than in the state machine: a filter, a route map, a prefix list, a missing network statement, a next hop that is not reachable, or the far end simply not sending it.
The useful discipline is to treat Established as the boundary between two kinds of problem. Below it, the question is whether the routers can talk. Above it, the question is what they have chosen to say, and how a route gets chosen is the subject that answers it.
NotificationsWhat the router says when a session leaves a state
The states tell you where a neighbor is. They do not tell you why it moved, and there is a message that does.
When BGP tears a session down it sends a NOTIFICATION message and closes the connection. That message carries an error code and a subcode saying what went wrong: a hold timer that expired, an OPEN message it would not accept, a malformed attribute, an administrative reset.
The state then drops back to Idle, which is the part people see, and the NOTIFICATION is the part that says why.
So a session that keeps returning to Idle is not really a question about Idle. The router logged a reason at the moment it left Established, and the logs are where that reason is. Watching the state cycle again produces the same information a second time.
This is also why the hold timer matters more than its obscurity suggests. If KEEPALIVE messages stop arriving for longer than the agreed hold time, the router concludes the neighbor is gone and sends a NOTIFICATION, and a path that drops occasional packets can trigger that without ever failing outright.
DiagnosisReading a stuck state as a diagnosis
The value of these names is that each one eliminates most of the possible causes, which is what a good diagnostic signal does.
| Stuck in | What is already proven | Where to look |
|---|---|---|
| Idle | Nothing has been attempted | The configuration, and whether the peer address is routable |
| Active | The router is trying and TCP is not completing | Firewalls, access lists, the peer address, the source address |
| Connect | A TCP connection is in progress | Packet loss or a very slow network path, since this should not persist |
| OpenSent | TCP works, so the network is fine | The OPEN parameters: AS number mismatch, router ID conflict, capabilities |
| OpenConfirm | The parameters were accepted | Authentication and the timer values, since only the final KEEPALIVE is left |
| Established | Everything about the session works | Policy, filters and next hop reachability |
The two middle rows are the specific signal mentioned earlier. If a session genuinely sits in OpenSent, that is unusually informative: it proves the network path and TCP are healthy and narrows the fault to what the two routers disagree about in the OPEN message. That is a much smaller problem than the one you started with.
PitfallsWhere people go wrong
Reading Active as good news. It is the failure state. A session in Active has no TCP connection and is not exchanging anything.
Debugging BGP when TCP is the problem. If the state is Active, test port 179 first. The BGP configuration is not where a blocked port gets fixed.
Treating Idle as a network fault. Idle is local and administrative. The peer address may not even be routable, and nothing on the wire will change that.
Stopping at Established. The session being up says nothing about which prefixes arrived. That is a policy question and it starts where the state machine ends.
Watching the state instead of testing it. Typing the same show command repeatedly tells you the BGP states are still wrong. Testing reachability, then the port, then the OPEN parameters tells you why.
Assuming both ends see the same state. They frequently do not. One side can be in Active while the other is in Idle because it was never configured, and comparing the two is often the fastest diagnosis available.
ComparisonA BGP state, an interface state and a routing table entry, side by side
| Criterion | BGP state | Interface state | Routing table entry |
|---|---|---|---|
| What it describes | A session with one peer | A physical or logical link | One learned destination |
| Can be up while nothing works | Yes, Established with no routes | Yes, up with no traffic | No |
| Depends on TCP | Yes, on port 179 | No | No |
| Tells you about policy | No | No | Indirectly |
| Where it comes from | RFC 4271 | The hardware and the driver | The routing process |
The row that catches people is the second. Three different layers can all report themselves healthy while the thing you actually wanted is not happening, which is why the answer to "is BGP up" is rarely the answer to the question being asked.
FAQFrequently asked questions
What are the BGP states?
Idle, Connect, Active, OpenSent, OpenConfirm and Established, defined by the finite state machine in RFC 4271 section 8.2.2. In practice the BGP states you observe on a neighbor are Idle, Active and Established.
What does BGP Active mean?
That the router is still trying to establish a TCP connection to the peer and has not succeeded. Despite the name it is a failure state, not a working one.
Why is my BGP session stuck in Active?
Because TCP to the peer is not completing. Look at firewalls and access lists on port 179, the peer address, whether return traffic can get back, and whether the source address matches what the peer expects.
What does BGP Idle mean?
That the router is not attempting the session. RFC 4271 says it refuses incoming connections for that peer and allocates no resources to it. The causes are configuration, an unroutable peer address, or an administrative shutdown.
What is the difference between Idle and Active?
Idle is not trying. Active is trying and failing at TCP. That distinction sends you to two completely different places: configuration for one, the network path for the other.
What does Established mean?
The session is up and the two routers are exchanging routes. It does not mean the routes you wanted have arrived.
Why do I never see OpenSent or OpenConfirm?
Because each waits on a single message that either arrives in milliseconds or does not, and if it does not the machine moves on rather than waiting. Catching one is unusual and it is a strong signal when you do.
What does it mean if BGP sits in OpenSent?
That TCP is working and the two routers disagree about the OPEN message. Check the AS numbers, the router IDs and the capabilities each side expects.
What port does BGP use?
TCP 179. Because the session runs over TCP, a session that will not come up is often a TCP problem rather than a BGP one.
Does a flapping BGP session cycle through all six states?
It normally alternates between the early BGP states, typically Connect and Active, without reaching Established. Reaching Established and dropping back is a different problem, usually the hold timer, authentication or an unstable network path.
Is Established enough to prove routing works?
No. It proves the neighbor relationship works. Whether a given prefix arrives depends on filters, route maps, next hop reachability and what the far end chose to advertise.
Should both routers show the same state?
Not necessarily, and the difference is useful. One end in Active while the other is in Idle usually means the second end has no configuration for the first.
What are the BGP neighbor states in order?
The BGP neighbor states are Idle, Connect, Active, OpenSent, OpenConfirm and Established. These BGP session states describe how far the TCP connection and the OPEN exchange have got. Only Established carries routes. A neighbor stuck in the BGP Idle state usually has no route to its peer or has been shut down administratively.
Keep readingRelated concepts
Read next · Protocols TCP vs UDP Why a session stuck in Active is a TCP problem, and what the connectionless alternative would have changed. Open this next10 min- Routing · 12 min What Is BGP? What the session carries once it reaches Established, and how a router picks one path over another.
- Routing · 12 min OSPF Explained The interior protocol that usually carries the loopback address BGP is trying to reach, which is why an internal session sits in Idle.
- Routing · 9 min BGP Community, the Tag That Signals Routing Policy The session that must be up before any community is exchanged.