BGP Session Stuck in Idle or Active: Causes and Fixes

A BGP session that never reaches Established is a TCP problem before it is a routing problem. "Active" means the local router is still trying to open TCP/179; "Idle" means it is not even attempting, or it has just been reset. This article walks the seven causes that account for nearly all of these cases, in the order that finds the fault fastest.

Read the State First

show bgp summary
show bgp neighbors 10.10.10.2
show tcp brief | include 179
show ip route 10.10.10.2

In the neighbour output, four lines do most of the work: the state, the last reset reason, whether the peer is "not directly connected", and the number of connections established versus dropped. Keep an eye on the reset reason changing on every attempt - a fast flip between Active and Connect often means an ACL or TTL problem, not a routing one.

The state machine, in one paragraph

BGP never jumps straight to Established. It passes through Idle, Connect, Active, OpenSent, OpenConfirm and finally Established, and the state you see tells you which half of the problem you have:

• Idle - the router is not trying at all, or has just been reset and the ConnectRetry timer is running. Sessions that sit in Idle permanently usually have a configuration error that prevents the attempt from being scheduled.
• Connect - a TCP connection is being attempted. If it lingers, the SYN is not getting a reply.
• Active - the router is listening for the peer to initiate. It is misleadingly named: Active does not mean "working", it means "waiting". This is the state where an outbound attempt failed and the router is now allowing the far side to try.
• OpenSent - TCP is up and an OPEN has been sent. A session stuck here is waiting on the peer's OPEN.
• OpenConfirm - both OPENs exchanged, waiting on the KEEPALIVE. Stuck here points at capability negotiation or a NOTIFICATION.

Session states that oscillate between Connect and Active with a fast ConnectRetry mean something is actively rejecting the connection, not that routing is missing.

Cause 1 - The neighbour statement or AS number is wrong

A typo in the neighbour address, or a local AS that does not match the peer's view of you, blocks the session before any policy matters. Chapter one of any BGP change review: re-read the neighbour statement against the peer's own configuration.

The most common variant is not a typo but an inheritance trap. A neighbour inside a peer-group picks up whatever the peer-group specifies, and if the peer-group has the wrong remote-as, every member is affected while the individual statements look correct. Read the effective configuration, not the intended one:

show bgp neighbors 10.10.10.2 configuration | include "remote AS|peer-group|update-source"
show run | section router bgp
show ip bgp peer-group

Cause 2 - No route, or a default route, to the peer address

show ip route 10.10.10.2
show ip route 0.0.0.0

If the lookup resolves via the default route, the neighbour is not truly reachable in the IGP sense. Sessions that ride a default route look established until the first failure, then never come back cleanly. Fix the IGP advertisement of the peering loopback.

The dangerous case is not an absent route but a recursive one. A route to the neighbour address that resolves through an interface that itself depends on the session - a route learned over the link you are trying to build, or a route that points back at the same next hop - produces a session that comes up and immediately tears down. Check the recursion explicitly with show ip route 10.10.10.2 longer-prefixes and show ip cef 10.10.10.2 detail.

Cause 3 - Missing update-source

router bgp 65001
 neighbor 10.10.10.2 remote-as 65002
 neighbor 10.10.10.2 update-source Loopback0
 neighbor 10.10.10.2 ebgp-multihop 2

Peering to a loopback without update-source means the OPEN arrives with the wrong source address and the peer rejects it. Peering across more than one hop also needs ebgp-multihop (and often a matching TTL on the far side).

On Junos the equivalent is set protocols bgp group X local-address <loopback>; on IOS-XR it is neighbor <ip> update-source Loopback0 plus neighbor <ip> ebgp-multihop 2. The invariant is the same everywhere: the source address used for the TCP connection must be the address the peer expects, and it must be reachable in both directions.

Cause 4 - TTL security or ACL on TCP/179

show ip access-lists | include 179
show bgp neighbors 10.10.10.2 | include TTL

Under an interface ACL, show tcp brief shows SYN-SENT that never advances. Check both directions: inbound permit to the local address on 179, and the return path for the ephemeral port range.

Two subtleties catch people out. First, GTSM (neighbor ttl-security hops 1) sets the TTL to 255 on outgoing packets and enforces a minimum on incoming; if one side has GTSM and the other has ebgp-multihop, the two mechanisms conflict and the session will never come up, with no ACL in sight. Second, a stateless ACL that permits TCP/179 inbound must also permit the return traffic, and with reflexive or established-only rules the ORDER of rules matters more than their content. Test with an ACL that logs, then read the log - guessing at ACL behaviour wastes an hour.

Cause 5 - Passive neighbours and colliding connection attempts

router bgp 65002
 neighbor 10.10.10.1 remote-as 65001
 neighbor 10.10.10.1 transport connection-mode passive

If one side is configured active-only and the other is behind a device that blocks its outbound 179, nothing comes up. Mixed passive configuration is a frequent issue in provider-to-customer edges and in firewalled data-centre borders.

TCP collision resolution is designed to handle both sides connecting simultaneously - it compares the router IDs and one side's connection is closed - so two active sides are fine. The problem is asymmetry: a passive-only side never initiates, so if the active side's outbound packets are filtered anywhere, no connection is ever possible. Where a firewall sits between the peers, verify that at least one direction can complete a full TCP handshake and that the firewall does not time out the idle BGP session before KEEPALIVEs arrive.

Cause 6 - The session comes up, then resets

show logging | include BGP_SESSION
show bgp neighbors 10.10.10.2 | include "Notification|error"

A session that reached Established and immediately dropped is a different fault class: hold-timer expiry under CPU load, a NOTIFICATION due to an unacceptable capability or prefix-limit breach, or interface flapping taking the route away. The generic flowcharts for this branch are in common BGP troubleshooting issues, and repeated resets are covered in BGP neighbour flapping root causes.

The NOTIFICATION code and subcode is the fastest path to the answer. Code 6 (cease) with subcode 6 (other configuration change) is routine; code 2 (open message error) with subcode 7 (unsupported capability or bad AS path in OPEN) points at a capability mismatch, often an unnegotiated address family such as IPv6 or an unrecognised capability from a new code version; code 4 (hold timer expired) points at a control-plane stall, which on modern hardware usually means a queue backed up behind a logging storm or a CPU-hogging process rather than a slow link.

Cause 7 - Router ID problems

show bgp all summary | include "BGP router identifier"

BGP needs a router ID before it can build sessions; if none is available (no IPv4 address on any interface or loopback, and no bgp router-id configured), sessions stay down. Duplicate router IDs inside the same AS cause iBGP sessions to be refused - an easy thing to inherit when cloning configurations. Route-reflector designs should be reviewed together with cluster ID configuration.

There is a fourth, less obvious case: a router ID change on a live device. Changing the router ID because a loopback was renumbered resets BGP sessions on many platforms, so the "fix" for one problem becomes an outage. Schedule router ID changes with the same discipline as an interface change.

Fast triage sequence

1. show bgp summary - confirm the peer is even in the table and note the state.
2. show ip route <peer> - confirm a real, non-default, non-recursive route exists.
3. show tcp brief | include 179 - if the socket is absent, the problem is configuration; if it is SYN-SENT, it is the path or an ACL.
4. ping <peer> and ping <peer> source <update-source> - proves reachability and the source address.
5. show bgp neighbors <peer> | include "TTL|update-source|not directly" - confirms the multihop and source design.
6. show logging | include BGP - the reset reason and NOTIFICATION codes.
7. Only after all of the above, look at policy: prefix lists, distribute lists and route maps cannot prevent a session from establishing, so if the session is down, policy is a distraction.

That ordering matters because policy is where people look first and it is almost never the cause. Sessions fail at the TCP and capablity layer; routes are filtered later.

MTU and other problems that disguise themselves

A handful of issues produce BGP symptoms without being BGP faults:

• MTU mismatch. TCP negotiates MSS from the path MTU, but a hop that silently drops large packets while still forwarding small ones - a tunnel, a policy router, or an MTU-reduced link - lets the session establish and then kills it when the first large UPDATE is sent. Test with a large, DF-bit ping before blaming BGP.
• Management-plane policing. CoPP policies that rate-limit BGP to the control plane look correct until a full table or a flapping peer pushes the rate over the threshold, at which point UPDATEs are dropped and the session resets on hold-timer expiry.
• Duplicate IP addressing. A second device advertising the peering address makes the ARP entry flip and the TCP session reset repeatedly. Syndromes include a session that looks up but never carries routes.
• Asymmetric return path. A source address that is reachable forward but not backward produces a TCP handshake that never completes - the classic SYN-SENT with SYN-ACK discarded silently.

Platform-specific notes

Preventive configuration

! Make the common failures observable before they bite
router bgp 65001
 bgp log-neighbor-changes
 neighbor 10.10.10.2 description CORE-RTR-1 lo0 peering
 neighbor 10.10.10.2 password <key>
 neighbor 10.10.10.2 timers 10 30
 ! and monitor the reset counter
show bgp neighbors 10.10.10.2 | include "resets|Reset"     ! EOS / FRR
show bgp neighbors 10.10.10.2 | include "reset|Reset"      ! IOS-XR uses the same word

Logging neighbour changes, describing every neighbour, and authenticating TCP with MD5 turn three classes of silent failure into visible events. The description is not decoration: in a real incident it is the fastest way to know whether the far end of a stuck session is a core router, a customer edge or a lab device someone left plugged in.

Frequently asked questions

My session shows Established but I see no routes. Is that the same problem? No. That is a policy or AF-activation problem - prefix lists, route maps, an address family not activated, or the peer sending nothing. See the troubleshooting flow referenced above.

Why does the state flip between Active and Connect so fast? Something is rejecting the TCP connection: an ACL, a firewall, or waiting on a socket that times out quickly. A slow oscillation is usually a routing or reachability problem.

Can a BGP session stay up over a flapping link? With BFD it can be torn down far faster than the hold timer, which is usually what you want for convergence and usually not what you want over an unstable link with no alternate path. Consider bfd slow-timers on genuinely marginal links.

Do passive-only neighbours ever come up? Yes, as long as the far side initiates and nothing in the path drops the inbound SYN. In practice, make at least one side active so the session has a deterministic initiator.

Related reading: the common BGP troubleshooting issues and BGP neighbour flapping root causes and fixes articles linked above continue this flow, and TCP MSS clamping and PMTUD troubleshooting covers the MTU class of fault that disguises itself as BGP.

原文链接：https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13752-24.html