BGP Neighbor States: Why a Session Sticks in Idle or Active
A BGP neighbor that is down shows a word where its prefix count should be, nearly always Idle or Active. The rule of thumb says Idle is a configuration problem and Active a reachability problem, but real routers do not follow it: a failing session keeps retrying and moves between the two, so the word you read depends on when you looked. This guide explains what each state is waiting for, then breaks one eBGP session six ways on IOS XE 17.16 and shows each fault with the commands and log messages that name it. For first-time setup, see how to configure eBGP peering.
Part of the BGP learning hub. Practice on hands-on CCNP labs.
What each neighbor state is waiting for
BGP has no neighbor discovery. Each neighbor is a TCP connection to port 179 that you configure by hand, and RFC 4271 defines the finite state machine a neighbor walks through before a single route is exchanged. Each state waits for one event, and that event is what to check when the neighbor stays put.
In show ip bgp summary you mostly see Idle, Active or a number, because Connect, OpenSent and OpenConfirm usually last milliseconds. IOS XE adds Idle (Admin) for a neighbor you shut down, Idle (PfxCt) for one over its prefix limit, and Closing while it tears down a connection it has just rejected. A number means Established: it is the count of prefixes received from that neighbor.
A session that is Established but carries no routes is not a state machine problem. For that, see why a network statement does not advertise.
| State | Waiting for | If the neighbor stays here |
|---|---|---|
| Idle | A start event or the retry timer. Every neighbor starts here and returns here after any error. | The router will not try (neighbor shut down, over its prefix limit, peer not on a connected subnet, no route to the peer), or its last attempt was refused. |
| Connect | Its own TCP connection to the peer to complete. | Rarely visible. A failed attempt moves on within seconds. |
| Active | A TCP connection that has not completed yet. | Segments to or from the peer are discarded without a reply: a filter, an MD5 key the other side rejects, or no device at that address. |
| OpenSent | The peer's OPEN message, after sending its own. | Visible only briefly, just before a bad OPEN is rejected. |
| OpenConfirm | The first KEEPALIVE, after both OPEN messages were accepted. | Rarely seen for long. The session either comes up or the hold timer expires. |
| Established | Nothing. UPDATE and KEEPALIVE messages flow. | Healthy. Zero prefixes is an advertising or filtering question. |
The lab behind the examples
All output below comes from four iol-xe routers on IOS XE 17.16. R1 and R2 are in AS 65001 and peer over iBGP between their Loopback0 addresses (10.255.0.1 and 10.255.0.2), with OSPF area 0 carrying the loopbacks. R3 is in AS 65002 and R4 in AS 65003.
Every fault is introduced on R1, mostly against its eBGP session to R3 across 10.0.13.0/30 (R1 Ethernet0/1 is 10.0.13.1, R3 is 10.0.13.2). Here is R1's working configuration and the healthy summary it produces.
R1(config)# router bgp 65001
R1(config-router)# bgp router-id 10.255.0.1
R1(config-router)# neighbor 10.255.0.2 remote-as 65001
R1(config-router)# neighbor 10.255.0.2 update-source Loopback0
R1(config-router)# neighbor 10.255.0.2 next-hop-self
R1(config-router)# neighbor 10.0.13.2 remote-as 65002
R1(config-router)# network 172.16.1.0 mask 255.255.255.0
R1# show ip bgp summary
BGP router identifier 10.255.0.1, local AS number 65001
BGP table version is 6, main routing table version 6
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.13.2 4 65002 5 5 3 0 0 00:01:22 1
10.255.0.2 4 65001 6 6 6 0 0 00:00:45 3Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.
Step 1 — Read the state, then read it again
Start with show ip bgp summary and look at the last column. A word there turns the session into a question. Idle asks why the router is not trying. Active asks what is swallowing the connection.
Then run it again a few seconds later. An attempt the far end refuses, with a TCP reset or an ICMP unreachable, drops the neighbor back to Idle, while one that gets no answer holds it in Active, so a peer that refuses you mostly reads Idle and a peer that ignores you mostly reads Active. Neither word names the fault.
Two other columns help. Up/Down is the time since the last state change, so on a broken neighbor it counts the seconds since the last failed attempt, not the age of the fault. MsgRcvd counts BGP messages from the peer: zero means nothing got past TCP, and a nonzero count means TCP works and the OPEN exchange is failing.
Step 2 — Ask the router for the reason
show ip bgp neighbors 10.0.13.2 prints close to a hundred lines. Filter it down to the few that answer most questions:
BGP staterepeats the state and says how long the neighbor has been in it.- The address-tracking line, caught by
RIB, says whether the routing table has a route to the neighbor. - For an eBGP neighbor, the connected-check lines. IOS XE will not open a single-hop eBGP session to an address outside its connected subnets, and when that check fails it prints
External BGP neighbor not directly connected. Last resetgives a time and a reason for the last drop, but treat the reason as a hint: in the wrong-AS example below it readdue to BGP Notification received of session 1, peer in wrong ASwhile R1's log held only notifications it had sent.
R1# show ip bgp neighbors 10.0.13.2 | include BGP state|Last reset|RIB|connectedThe filtered neighbor detail used in the steps below.
Then read the log
A router that rejects an OPEN logs a %BGP-3-NOTIFICATION line with an error code and says whether it sent or received it. An MD5 problem never gets that far: TCP discards the segments before BGP sees them, so no %BGP-3-NOTIFICATION appears and the router that expects the password logs %TCP-6-BADAUTH for every unsigned segment instead. IOS XE buffers log messages, so show logging has them even if nobody was watching the console.
R1# show logging | include wrong AS
R1# show logging | include SESSION_PARSE|BADAUTHThe two log searches used in Steps 4 and 5.
Step 3 — Faults that hold a session in Idle
An Idle state that never changes means the router has decided not to try, or its attempts are refused the moment they leave.
The neighbor is shut down
neighbor 10.0.13.2 shutdown keeps a session down on purpose, and the summary says so with Idle (Admin). R1 also sends R3 a Cease notification, code 6 subcode 2, Administrative Shutdown, so the log records that the drop was deliberate. no neighbor 10.0.13.2 shutdown brings the session back on its own, with no clear required.
R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.13.2 shutdown
R1(config-router)# end
R1# show ip bgp summary | include Neighbor|10.0.13.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.13.2 4 65002 0 0 1 0 0 00:00:04 Idle (Admin)
R1# show logging | include Administrative Shutdown
*Sep 17 17:12:33.330: %BGP-3-NOTIFICATION: sent to neighbor 10.0.13.2 6/2 (Administrative Shutdown) 0 bytes Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.
The peer sent too many prefixes
maximum-prefix shuts a neighbor down when it advertises more routes than the limit allows, and the summary marks it Idle (PfxCt). By default it does not retry: the neighbor stays down until the session is cleared, which sets this fault apart from every other one on this page.
The neighbor detail names the limit and the reason; Last reset does not, and reads BGP protocol initialization instead. Below, R1 allows two prefixes from a neighbor that sends more.
R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.13.2 maximum-prefix 2
R1(config-router)# end
R1# clear ip bgp 10.0.13.2
R1# show ip bgp summary
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.13.2 4 65002 0 0 1 0 0 00:00:02 Idle (PfxCt)
10.255.0.2 4 65001 19 19 17 0 0 00:07:59 4
R1# show ip bgp neighbors 10.0.13.2 | include BGP state|reset|prefixes
BGP state = Idle, down for 00:00:03
Peer had exceeded the max. no. of prefixes configured.
Maximum prefixes allowed 2
Threshold for warning message 75% (1 prefixes)
SNMP trap cleared below 70% (1 prefixes)
Last reset 00:00:03, due to BGP protocol initializationOutput captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.
The peer is not on a connected subnet
eBGP sends its packets with a TTL of 1, so IOS XE checks that the neighbor address sits inside a connected subnet before it opens a connection. A shut or failed interface, a mistyped neighbor address, a mask that leaves the peer outside the subnet, and eBGP between loopbacks without multihop all fail that check. Below, R1's Ethernet0/1 is shut: the session drops at once and the neighbor detail names the failed check.
R1(config)# interface Ethernet0/1
R1(config-if)# shutdown
R1(config-if)# end
R1# show ip bgp summary | include Neighbor|10.0.13.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.13.2 4 65002 0 0 1 0 0 00:00:04 Idle
R1# show ip bgp neighbors 10.0.13.2 | include BGP state|Last reset|RIB|connected
BGP state = Idle, down for 00:00:04
...
Address tracking is enabled, the RIB does not have a route to 10.0.13.2
Last reset 00:00:04, due to Interface flap of session 1
External BGP neighbor not directly connected.
External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
R1# show ip route 10.0.13.2
% Subnet not in tableOutput captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.
An iBGP session over loopbacks
iBGP skips the connected check, but the router still needs a route to the neighbor address. On R1, show ip route 10.255.0.2 should return an OSPF route; % Subnet not in table means the IGP is the problem, not BGP.
The other half is the source address. A router accepts an incoming connection only from an address that matches one of its neighbor statements, so without update-source Loopback0 a router opens the session from its outgoing interface, 10.0.12.1 on R1, and the peer expecting 10.255.0.1 resets it. That reads as Idle, not Active, and a ping between the loopbacks still succeeds. The fix, and the next-hop problem that comes with it, is covered in iBGP update-source and next-hop-self.
Step 4 — Faults that show Active
An Active state that keeps coming back means the router keeps sending and nothing useful returns: something discards TCP segments without answering.
A filter drops TCP port 179
An inbound ACL on the peering interface is the most common cause, and it has a giveaway: ping works. EDGE-IN below permits ICMP and denies everything else, so R1 can ping R3 while every BGP segment from R3 is dropped. After clear ip bgp 10.0.13.2 the session does not come back, and the deny counter rises with every retry.
Neither state names the router holding the filter. R1 waits for replies that it discards itself, and R3 gets no answer to its own attempts, because those are dropped on the way in. Read the ACL counters on both ends instead of inferring the direction from the state.
R1(config)# ip access-list extended EDGE-IN
R1(config-ext-nacl)# permit icmp any any
R1(config-ext-nacl)# deny ip any any
R1(config-ext-nacl)# exit
R1(config)# interface Ethernet0/1
R1(config-if)# ip access-group EDGE-IN in
R1(config-if)# end
R1# clear ip bgp 10.0.13.2
R1# show ip bgp summary | include Neighbor|10.0.13.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.13.2 4 65002 0 0 1 0 0 00:00:06 Active
R1# ping 10.0.13.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.13.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R1# show ip access-lists EDGE-IN
Extended IP access list EDGE-IN
10 permit icmp any any (10 matches)
20 deny ip any any (7 matches)Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.
Fix: permit BGP in both directions
Permit BGP from the peer ahead of the deny, in both directions. A segment sent to port 179 belongs to a connection R3 opened; one sent from port 179 is R3 answering a connection R1 opened. Either router may open the session, so an ACL with only one of the two lines blocks half the attempts. Sequence numbers 5 and 6 put the new lines first, and the clear below only shortens the wait; how to configure an extended ACL covers sequencing and placement.
R1(config)# ip access-list extended EDGE-IN
R1(config-ext-nacl)# 5 permit tcp host 10.0.13.2 host 10.0.13.1 eq bgp
R1(config-ext-nacl)# 6 permit tcp host 10.0.13.2 eq bgp host 10.0.13.1
R1(config-ext-nacl)# end
R1# clear ip bgp 10.0.13.2
R1# show ip bgp neighbors 10.0.13.2 | include BGP state
BGP state = Established, up for 00:00:05
R1# show ip access-lists EDGE-IN
Extended IP access list EDGE-IN
5 permit tcp host 10.0.13.2 host 10.0.13.1 eq bgp (2 matches)
6 permit tcp host 10.0.13.2 eq bgp host 10.0.13.1 (7 matches)
10 permit icmp any any
20 deny ip any anyOutput captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.
The MD5 passwords do not match
With a password configured, a router signs every segment of the session and discards any that arrive unsigned or signed with a different key. It sends nothing back, so the neighbor sits in Active. Below, R1 has a password and R3 does not.
A new password does not apply itself to a session that is already up. IOS XE logs %BGP-4-BGP_SESSION_PARSE ending "Session reset required for change to take effect", hence the clear ip bgp 10.0.13.2. After that, R1 logs a BADAUTH line for every segment from R3: port 179 after R3's address is R3 answering R1, port 179 after R1's address is R3 opening its own connection, so both directions fail.
The mirror case reads the same from the other side: with the password on R3 instead, R3 logged No MD5 digest from 10.0.13.1(179) to 10.0.13.2(50171) and its neighbor showed Active. Whichever router holds the password is the one that logs BADAUTH, and the address in the message is the peer that is not signing.
Configure the same key on both ends, or remove it from both. R3's matching line is neighbor 10.0.13.1 password GOLDFISH under router bgp 65002. Removing the key from R1 is no neighbor 10.0.13.2 password.
R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.13.2 password GOLDFISH
R1(config-router)# end
R1# clear ip bgp 10.0.13.2
R1# show logging | include SESSION_PARSE|BADAUTH
*Sep 17 17:18:05.417: %BGP-4-BGP_SESSION_PARSE: Failed to parse password neighbor config for neighbor 10.0.13.2 IPv4 Unicast (Password configuration changed for neighbor. Session reset required for change to take effect.)
*Sep 17 17:18:05.942: %TCP-6-BADAUTH: No MD5 digest from 10.0.13.2(179) to 10.0.13.1(62352) tableid - 0
...
*Sep 17 17:18:11.941: %TCP-6-BADAUTH: No MD5 digest from 10.0.13.2(179) to 10.0.13.1(62352) tableid - 0
*Sep 17 17:18:17.443: %TCP-6-BADAUTH: No MD5 digest from 10.0.13.2(16225) to 10.0.13.1(179) tableid - 0
R1# show ip bgp summary | include Neighbor|10.0.13.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.13.2 4 65002 0 0 1 0 0 00:00:14 ActiveOutput captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.
Nothing answers
If the neighbor address is inside a connected subnet but nothing replies there, the attempt goes unanswered and the neighbor shows Active. A wrong host address on a shared segment, or a peer whose own interface is down, looks like this. Unlike a filter, ping fails too.
Step 5 — A session that resets every few seconds
When TCP completes but the session still fails, the problem is in the OPEN message: each router checks the peer's OPEN against its own configuration and, on a mismatch, sends a NOTIFICATION and closes the connection. Both ends retry seconds later, so the neighbor never settles — here the summary caught it in Closing, with MsgRcvd and MsgSent at 2: enough messages to prove TCP works, not enough to reach Established.
A wrong remote-as is the usual cause. Below, R1 expects AS 65005 but R3 is in 65002. R1 logs 2/2 (peer in wrong AS): code 2 is an OPEN message error, subcode 2 is Bad Peer AS, and the two bytes FDEA are the AS number R3 actually sent, in hex. 0xFDEA is 65002, the value R1 should have.
Each line also says active, a connection R1 opened, or passive, one R3 opened: both fail the same check, which rules out a filter that blocks one direction only. Every line says sent, so R1 is the router doing the rejecting, and the router holding the wrong number.
R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.13.2 remote-as 65005
R1(config-router)# end
R1# show logging | include wrong AS
*Sep 17 17:20:55.942: %BGP-3-NOTIFICATION: sent to neighbor 10.0.13.2 active 2/2 (peer in wrong AS) 2 bytes FDEA
*Sep 17 17:21:06.417: %BGP-3-NOTIFICATION: sent to neighbor 10.0.13.2 passive 2/2 (peer in wrong AS) 2 bytes FDEA
*Sep 17 17:21:07.213: %BGP-3-NOTIFICATION: sent to neighbor 10.0.13.2 active 2/2 (peer in wrong AS) 2 bytes FDEA
R1# show ip bgp summary | include Neighbor|10.0.13.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.13.2 4 65005 2 2 1 0 0 00:00:01 Closing
R1# show ip bgp neighbors 10.0.13.2 | include BGP state|Last reset
Last reset 00:00:12, due to BGP Notification received of session 1, peer in wrong ASOutput captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.
Fix: set the AS the peer really uses
Enter neighbor 10.0.13.2 remote-as 65002. IOS XE replaces the old value, resets the neighbor, and the next attempt succeeds: three seconds after the change the session was Established with three prefixes. Changing remote-as on a live session resets it the same way, which is how the broken example above began, and Last reset names it afterwards as Other Configuration Change.
R1(config)# router bgp 65001
R1(config-router)# neighbor 10.0.13.2 remote-as 65002
R1(config-router)# end
R1# show ip bgp neighbors 10.0.13.2 | include BGP state|Last reset
BGP state = Established, up for 00:00:03
Last reset 00:00:04, due to BGP Notification received of session 1, Other Configuration Change
R1# show ip bgp summary | include Neighbor|10.0.13.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.13.2 4 65002 5 8 29 0 0 00:00:04 3Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.
Symptom to cause at a glance
The faults above, side by side: read the state with one extra clue.
| What you see | Most likely cause | Confirm with |
|---|---|---|
| Idle (Admin) | A neighbor ... shutdown line | show running-config | section router bgp |
| Idle (PfxCt) | The peer sent more prefixes than maximum-prefix allows | The max-prefix lines in show ip bgp neighbors, then a clear |
| Idle on a single-hop eBGP neighbor | Peering interface down, wrong neighbor address or mask, or loopback peering without multihop | show ip route for the neighbor address, then the not directly connected line |
| Idle on an iBGP loopback neighbor | No IGP route to the loopback, or update-source missing | show ip route, then the peer's neighbor statement |
| Active, and ping works | An ACL or firewall dropping TCP 179 | show ip access-lists counters |
| Active, and the log shows BADAUTH | Password on one side only, or different keys | show logging | include BADAUTH |
| Resets every few seconds, with a BGP notification | OPEN rejected, most often a wrong remote-as | show logging | include wrong AS |
| Established with 0 prefixes | The session is fine. Nothing is advertised, or a filter removes it. | show ip bgp on the peer |
Prove the fix
A repaired session shows a prefix count again, and Up/Down restarts from zero. In show tcp brief, a foreign port of 179 means this router opened the connection and a local port of 179 means it accepted one; R1 opened both sessions here. show running-config | section router bgp confirms that no test lines, such as a leftover password, remain.
Most fixes need no extra step: removing the shutdown, bringing the interface back up and correcting remote-as all take effect on their own, because the neighbor keeps retrying. Two need a reset — a password change, which IOS XE applies only to the next session, and a neighbor parked in Idle (PfxCt). clear ip bgp 10.0.13.2 is a hard reset: it sends the peer a Cease notification and withdraws every prefix learned from the neighbor until the session returns, so use it only when a change requires it.
The BGP commands cheat sheet keeps these commands in one place.
R1# show ip bgp neighbors 10.0.13.2 | include BGP state
BGP state = Established, up for 00:00:05
R1# show ip bgp summary | include Neighbor|10.0.13.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.13.2 4 65002 10 8 32 0 0 00:00:06 3
R1# show tcp brief
TCB Local Address Foreign Address (state)
...
7A38D8C08810 10.255.0.1.49266 10.255.0.2.179 ESTAB
7A38D8C8F378 10.0.13.1.19084 10.0.13.2.179 ESTAB
...
R1# show running-config | section router bgp
router bgp 65001
bgp router-id 10.255.0.1
bgp log-neighbor-changes
network 172.16.1.0 mask 255.255.255.0
neighbor 10.0.13.2 remote-as 65002
neighbor 10.255.0.2 remote-as 65001
neighbor 10.255.0.2 update-source Loopback0
neighbor 10.255.0.2 next-hop-selfOutput captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.
Frequently asked questions
Is Active a good BGP neighbor state?
No. Despite the name, Active means the router has no working TCP connection to the neighbor and is still trying to build one. A healthy session shows a number in the State/PfxRcd column of show ip bgp summary, and that number is the count of prefixes received while the session is Established.
Why does a BGP neighbor move between Idle and Active?
Because the router retries every few seconds. Each attempt starts from Idle, shows Active while the TCP connection is pending, and returns to Idle when the attempt fails. Which state you see depends on timing, so read the neighbor detail and the log for the cause instead of relying on the state name.
Can ping work while a BGP session stays down?
Yes. Ping uses ICMP and BGP uses TCP port 179, so an access list that permits ICMP but not TCP 179 lets ping succeed while the session never forms. Check the ACL counters on the peering interfaces and permit TCP 179 from the peer as both the source and the destination port.
What does peer in wrong AS mean in a BGP notification?
The AS number in the neighbor's OPEN message does not match the remote-as configured for it. The notification is error 2/2, Bad Peer AS, and IOS XE prints the AS the neighbor actually sent as two hexadecimal bytes, so FDEA means 65002. Correct the remote-as on the router that logged the notification as sent.
Do I need to clear the BGP session after fixing the configuration?
Usually not. Fixes such as a corrected remote-as, a removed neighbor shutdown or an interface brought back up take effect on their own, because a failing neighbor keeps retrying. Two cases do need a reset: a password change, which IOS XE applies only after the session resets, and a neighbor that a maximum-prefix limit has parked in Idle (PfxCt). Both use clear ip bgp with the neighbor address, and a hard clear withdraws every route learned from that neighbor until the session returns.
Now build it
Bring up a first eBGP peering, then troubleshoot a graded eBGP and iBGP topology.
This is what grading your config looks like
A sample result — 4 of 5 requirements met. This is exactly what you see the moment you submit.
bgp-lab-export.yaml — read 3 device configs
- Passed: BGP process running as AS 65001 on R1
- Passed: eBGP neighbor 10.0.13.2 in AS 65002
- Passed: Session to 10.0.13.2 is Established
- Passed: 172.16.1.0/24 originated by an exact match
- Failed: next-hop-self toward the iBGP peer — missing on R2
Solution revealed
The full node-by-node answer key unlocks the moment you submit — so you see exactly what you missed.
Don't just read it — configure it
Reading is step one. Build BGP on real Cisco IOS and have your own config graded.