Idle: not even trying
A session in Idle isn't even trying to connect, and the reason is almost always written down for you: in the summary's state column, and in the Last reset line of show bgp neighbors. This section shows three common ways to end up there, and one that looks like it should be Idle but isn't.
Shut down on purpose
neighbor 192.0.2.1 shutdown takes a session down and keeps it down. It's the right way to take a peer out of service for maintenance, and it's easy to forget to undo. The summary says so plainly: Idle (Admin).
Too many prefixes
maximum-prefix protects a router from a peer that suddenly sends far more routes than it should, like a customer leaking a full table. When the limit is crossed, FRR sends a NOTIFICATION and holds the session in Idle (PfxCt). It does not come back on its own: once the peer has fixed its side (or you've raised the limit), you clear the session.
In the lab, r1 limits r2 to 3 prefixes. r2 sends 4.
Two habits make this safe in production: set the limit well above the normal count (but below "a full table"), and consider maximum-prefix <n> warning-only while you learn what normal is. A restart timer (maximum-prefix <n> restart <minutes>) brings the session back automatically.
A typo in the neighbour address
If the neighbour address is wrong, so that nothing on a connected network matches it, you might expect Idle. FRR actually shows Active, and you have to read the detail to see why: No path to specified Neighbor. The next-hop cache explains it: an eBGP neighbour must be directly connected by default ("Must be Connected"), and 192.0.2.9 isn't on any of r1's networks.
r1# show bgp summary
IPv4 Unicast Summary:
BGP router identifier 198.51.100.241, local AS number 64500 VRF default vrf-id 0
BGP table version 9
RIB entries 3, using 384 bytes of memory
Peers 1, using 17 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.0.2.1 4 64501 9 6 0 0 0 00:00:03 Idle (Admin) 0 r2
Total number of neighbors 1
r1:~# vtysh -c "show bgp neighbors 192.0.2.1" | grep -E "BGP state|Administratively|Last reset"
Administratively shut down
BGP state = Idle
Last reset 00:00:03, Admin. shutdown (n/a)- Line 10:
Idle (Admin): shut down by configuration. Nothing is wrong with r2 or the link. - Line 17: The last reset reason says the same.
r1# show bgp summary
IPv4 Unicast Summary:
BGP router identifier 198.51.100.241, local AS number 64500 VRF default vrf-id 0
BGP table version 17
RIB entries 3, using 384 bytes of memory
Peers 1, using 17 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.0.2.1 4 64501 14 11 0 0 0 00:00:06 Idle (PfxCt) 0 r2
Total number of neighbors 1
r1:~# grep -E "MAXPFX|ADJCHANGE|NOTIFICATION" /var/log/frr/frr.log | tail -4
2026/10/18 03:27:55 BGP: [N9HHH-F8H1M] %ADJCHANGE: neighbor 192.0.2.1(r2) in vrf default Up
2026/10/18 03:28:00 BGP: [QAZ2C-BZRW5] %MAXPFXEXCEED: No. of IPv4 Unicast prefix received from 192.0.2.1(r2) 4 exceed, limit 3
2026/10/18 03:28:00 BGP: [HZN6M-XRM1G] %NOTIFICATION(Hard Reset): sent to neighbor 192.0.2.1 6/1 (Cease/Maximum Number of Prefixes Reached) 7 bytes 00 01
2026/10/18 03:28:00 BGP: [PXVXG-TFNNT] %ADJCHANGE: neighbor 192.0.2.1(r2) in vrf default Down BGP Notification send
r1:~# vtysh -c "show bgp neighbors 192.0.2.1" | grep -E "BGP state|Last reset|Idle|Maximum|prefix"
BGP state = Idle
0 accepted prefixes
Maximum prefixes allowed 3
Last reset 00:00:06, Notification sent (Cease/Maximum Number of Prefixes Reached/Hard Reset)
Peer had exceeded the max. no. of prefixes configured.
Reduce the no. of prefix and clear ip bgp 192.0.2.1 to restore peering
r1# clear bgp 192.0.2.1
r1# show bgp summary
IPv4 Unicast Summary:
BGP router identifier 198.51.100.241, local AS number 64500 VRF default vrf-id 0
BGP table version 21
RIB entries 9, using 1152 bytes of memory
Peers 1, using 17 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.0.2.1 4 64501 19 15 21 0 0 00:00:08 4 1 r2
Total number of neighbors 1- Line 10:
Idle (PfxCt): held down because of the prefix count. - Lines 16–18: The log tells the story: 4 received, limit 3, NOTIFICATION 6/1 (Cease / Maximum Number of Prefixes Reached), session down.
- Lines 25–26: FRR even tells you what to do.
- Lines 28–39: After raising the limit to 10, a
clearbrings the session straight back with all 4 prefixes.
r1# show bgp summary
IPv4 Unicast Summary:
BGP router identifier 198.51.100.241, local AS number 64500 VRF default vrf-id 0
BGP table version 5
RIB entries 9, using 1152 bytes of memory
Peers 2, using 33 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.0.2.1 4 64501 10 8 5 0 0 00:00:33 4 1 r2
192.0.2.9 4 64501 0 0 0 0 0 never Active 0 typo for 192.0.2.1
Total number of neighbors 2
r1:~# vtysh -c "show bgp neighbors 192.0.2.9" | grep -E "BGP state|Last reset|nexthop|No path|connect|Connect"
BGP state = Active
Connections established 0; dropped 0
Last reset 00:00:15, No path to specified Neighbor (n/a)
BGP Connect Retry Timer in Seconds: 120
Next connect timer due in 105 seconds
r1# show ip route 192.0.2.9
r1# show bgp nexthop
Current BGP nexthop cache:
192.0.2.1 valid [IGP metric 0], #paths 4, peer 192.0.2.1
Resolved prefix 192.0.2.0/31
if eth0
Last update: Sun Oct 18 03:28:20 2026
192.0.2.9 invalid, #paths 0, peer 192.0.2.9
Must be Connected
Last update: Sun Oct 18 03:28:39 2026- Line 11: Not Idle but Active, and never up.
- Line 18: The real reason is only in the detail.
- Line 22: No route at all to 192.0.2.9: the command prints nothing.
- Lines 30–31: The next-hop cache: an eBGP neighbour must be on a connected network unless you say otherwise.
Check your understanding
A customer session drops to Idle (PfxCt) at 3 a.m. The customer says they've fixed their leak. What brings the session back?
- Nothing: it will come back on its own once the prefixes are withdrawn.
- clear bgp <address> (or a restart timer configured in advance).
- Removing and re-adding the neighbour.
- Raising the limit, which restarts the session automatically.