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.

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.

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.

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).

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.

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.

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.

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.

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