A BGP session that sits in Active or Connect forever is a TCP problem, not a BGP problem. That single sentence resolves half of the r/Juniper threads on the topic, including the classic "eBGP neighboring issue (stuck in Active)" where an engineer peers to a loopback. Here is the field method to find exactly why TCP is not forming.
What the States Mean
In show bgp summary, Idle means BGP has not even started (often "no route to peer"). Connect means BGP knows how to reach the peer and is attempting TCP. Active means the first TCP attempt failed and BGP is listening and retrying. Neither state means the session is half-broken — it means port 179 is unreachable or refused.
Check 1: Is There a Route to the Peer?
show route 203.0.113.2
ping 203.0.113.2 rapid count 5No route (or a route out the wrong VRF) explains most Idle and Connect cases. If the peer address is a loopback, confirm it exists in the IGP or a static route before anything else.
Check 2: Loopback Peering Needs local-address
The single most common loopback-peering mistake: BGP sources its TCP from the egress interface, so the peer sees a connection from a physical IP it does not recognize and resets it — your side shows Active forever. Source your connections explicitly:
set protocols bgp group EBGP type external
set protocols bgp group EBGP local-address 10.255.0.1
set protocols bgp group EBGP peer-as 65002
set protocols bgp group EBGP neighbor 10.255.0.2For eBGP over loopbacks you must also raise the TTL, because eBGP defaults to TTL 1:
set protocols bgp group EBGP multihop ttl 2Missing multihop on eBGP-over-loopback produces precisely the stuck-Active symptom — the TTL-exceeded reply never looks like a refusal from the peer.
Check 3: Is TCP 179 Reachable?
telnet 10.255.0.2 port 179 source 10.255.0.1If telnet connects and immediately closes, TCP works and the problem is BGP-level (authentication, AS number). If it times out, something between the peers filters 179 — an intermediate ACL, a carrier, or an SRX in the path. On an SRX, remember zones and host-inbound-services: our zone and policy guide shows how to permit BGP into a zone.
Check 4: Authentication and Open Failures
show bgp neighbor 10.255.0.2 detail | match "last|error"When TCP forms but Open fails (auth key mismatch, unexpected AS), the session cycles Connect, OpenSent, Idle rather than sitting in Active — a distinguishing clue. Fix the key or the configured peer-as and the session establishes on the next attempt.
Check 5: One Side Configured, One Side Missing
The dull but common case: the neighbor exists on one router only. BGP still retries (Connect/Active) because the local config is valid. Always confirm the peer actually has your address configured — in carrier handoffs this is the majority of stuck sessions.
Fast Verification Matrix
| Symptom | Most likely cause |
|---|---|
| Idle, no route | Missing IGP or static route to peer |
| Connect forever | Wrong peer IP, or peer not configured |
| Active forever, loopback peering | Missing local-address or multihop |
| Active forever, direct link | TCP/179 filtered between peers |
| Cycling Idle/Connect/OpenSent | Auth key or peer-as mismatch |
Once the session establishes but keeps dropping, switch from this guide to our BGP flap field method, which hunts transport-layer instability, MTU black holes and interface errors. If high CPU accompanies the churn, check the routing engine process guide — and for the underlying link quality, use show interfaces extensive before blaming BGP.
Discussion (0)