In plain English: Your router keeps knocking on the neighbor's door and nobody answers. BGP itself is fine — the problem is always the road to the door: no route to get there, a firewall standing in the way, or the two sides expecting the session to come from different addresses.
The symptom
A BGP session never comes up. Every time you check, the neighbor sits in Active — BGP's 'still trying to connect' state — and zero prefixes are received. The router it should reach might be a partner, a cloud on-ramp, or your own second site.
R1# show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
203.0.113.1 4 65001 0 0 0 0 0 never Active
Check first — in this order
show ip bgp summaryConfirm Active. Idle usually means the router is not trying (shutdown, or backing off after errors); Active means it IS trying to open the connection and failing.
ping 203.0.113.1Basic question first: can this router reach the neighbor's address at all? No reply means a plain routing problem — BGP is innocent.
ping 203.0.113.1 source Loopback0(or whichever interface is your update-source) If the plain ping works but the sourced ping fails, the session will be built from an address the far side does not expect or cannot reach.
traceroute 203.0.113.1Watch where the trail dies. Stopping at a firewall or an edge device points straight at the box that is eating the connection.
Ask the far side what they seeTheir log will say whether your connection attempts arrive at all. Attempts arriving and being refused is a different fault from attempts never arriving.
show ip route 203.0.113.1If the neighbor is more than one hop away and this is eBGP, remember plain eBGP assumes a directly connected neighbor (TTL 1) — a multi-hop path needs an explicit setting.
What the evidence means
BGP itself is simple here: it rides on a normal TCP connection to port 179. Active means the TCP connection cannot be completed — SYN packets go out and nothing usable comes back. So this is never a 'BGP tuning' problem. It is a reachability problem, a filtering problem, or an identity problem (the two sides disagree about which addresses the session runs between).
Root causes, ranked
Root cause
How you recognize it
No route, or the wrong neighbor address
A typo in the neighbor statement, an address changed at the far end, or a missing route. The ping tests expose this in seconds.
A firewall or ACL blocks TCP 179 somewhere on the path
The single most common cause in enterprise networks — a new firewall rule, an edge ACL, or a cloud security group that nobody told the BGP change about.
Update-source mismatch
Your router builds the session from interface A; the far side has your neighbor statement written for interface B's address. Both configs look 'right' in isolation.
eBGP neighbor is more than one hop away, with no multihop setting
Through a firewall pair or a load balancer, the neighbor is reachable but not directly connected, and TTL 1 packets die at the first hop.
Authentication (MD5/TCP-AO) mismatch
The connection gets actively refused or reset instead of ignored. Often shows as the state cycling between Active and Idle rather than sitting in Active.
Before you touch production: Reconfiguring or clearing a BGP session drops the routes learned from that neighbor. If this session is the only path to those prefixes, schedule the work — do not experiment on it during business hours.
The fix
Fix reachability first: a working route to the neighbor address, from the exact source address the session will use.
Open TCP 179 on every firewall and ACL on the path, in both directions (the session can be started from either side).
Align the identities: neighbor address, remote-as, and update-source must describe the same pair of addresses on both routers.
For a multi-hop eBGP neighbor, add 'neighbor <ip> ebgp-multihop 2' (use the real hop count — no more than needed).
Match the authentication password exactly on both ends if one is used.
Verify it worked
show ip bgp summaryState reads Established and the PfxRcd column shows a growing, then stable, prefix count.
show ip bgp neighbors 203.0.113.1 | include Established'Connections established' has incremented once and is not climbing — one clean session, not a flapping one.
show ip bgpRoutes from that neighbor are in the BGP table and the best ones are being used.
Did this fix it for you? One tap — anonymous, nothing to type, and nothing you send is ever published.
Which cause was yours?
Thanks — your tap helps the next engineer. A run of "still broken" reports sends this page back to the top of our re-check list.
Going deeper — production notes
Swipe sideways to see the full diagram →
One telnet command, three verdicts. Connects, refused, or silence — each answer points at a different layer, before you change a single BGP setting.
Each state indicts a layer
Know the neighboring states, because each one indicts a different layer. Idle: BGP is not trying (administrative shutdown, or backing off after repeated errors — the neighbor detail says which). Connect: a TCP attempt is in flight right now. OpenSent or OpenConfirm: TCP is UP and the routers are negotiating BGP itself — a session stuck there is an authentication, version, or capability problem, not this case. Established: done.
Test TCP directly
Test the TCP layer directly from the router where the platform allows it: 'telnet 203.0.113.1 179'. Three outcomes, three different faults: it connects — the path and the far listener are fine, so look at the BGP layer; 'connection refused' — packets arrive but nothing is listening, so the far side has no matching neighbor configured or BGP is down there; it hangs until timeout — packets are being silently dropped on the path, the firewall/ACL signature.
The richest single screen
'show ip bgp neighbors 203.0.113.1' is the richest single screen: it names the exact local address BGP sources from, the configured remote AS, the number of connection attempts, and the last reset reason. Compare its local-address line against what the far side expects — that one comparison resolves the update-source cause in seconds.
Authentication fails silently
Authentication failures hide. With TCP MD5 or TCP-AO, segments carrying a bad signature are silently discarded by the receiver, so the session cycles between Active and Idle with no clean error anywhere. If a password was 'just rotated' on one side, put this at the top of the list even though no log line says the word authentication.
The dual-firewall trap
Stateful firewalls add a trap: the SYN leaves through firewall A and the reply returns through firewall B, which never saw the SYN and drops it. On dual-firewall paths, confirm routing is symmetric for the peering addresses before re-checking a single BGP setting.
The TAC / NOC bundle
For TAC or the far provider's NOC, collect: 'show ip bgp summary', the full 'show ip bgp neighbors' output, 'show ip route' to the neighbor, pings sourced from the exact update-source address, and ACL hit counters for port 179 along the path. That set separates 'your side', 'their side', and 'the path' in one exchange.
BGP's states at a glance — where it sticks tells you the layer
Idle not trying→Connect TCP in flight→Active TCP failing — this case→OpenSent BGP negotiating→OpenConfirm nearly there→Established done
Reproduce this failure: Packet Path's hands-on labs run this class of fault in a simulated network, so you can break it, run the checks above, and fix it there before touching production. Open the labs.
Prevention
Peer from loopbacks with an explicit update-source, and document the expected source/destination pair for every session.
Include 'BGP port 179' in the standard firewall checklist for any new path between sites or to a cloud on-ramp.
Alert when a neighbor stays out of Established for more than a few minutes — Active is silent unless something watches it.
Still stuck? Before you open a TAC case
Work this ladder before you open a case. Sessions stuck in Active are almost never a BGP defect — they are a path, a firewall, or a one-digit mistake. Prove which, and TAC becomes the last resort it should be.
The last checks — the ones that close most "unsolvable" cases
Borrow a known-good comparison: if another BGP session from the same router — or to the same provider — is Established, your router is innocent. Diff the two neighbor configs line by line; the difference is the answer nine times out of ten.
Test from a different source: ping and telnet the neighbor from a second interface, or a second router on the same segment. Works from elsewhere? The first router's source address or local routing is the fault.
Read the far side's looking glass: most providers publish one. If they show your session as Idle — or not configured at all — the ticket belongs to their NOC, and you can say so with evidence instead of opinion.
Ask the firewall team exactly one question: 'did anything change on this path this week?' Stateful-inspection and NAT changes break more healthy sessions than BGP ever has.
Re-read the remote AS number digit by digit against the provider's welcome letter or LOA. A transposed AS is the most embarrassing cause in this fault class — and one of the most common.
It really is a TAC case when
A capture proves TCP connects and OPEN messages are exchanged, yet the session still resets with a notification pointing at software.
The session flaps on a perfect timer that no configuration explains — a classic defect signature.
The provider confirms in writing that their side is configured and listening, captures at both ends prove the path is clean, and it still will not establish.
If you do open one, hand them this bundle
'show ip bgp summary' and the full 'show ip bgp neighbors' output
The telnet-to-179 result from the router itself, plus pings sourced from the exact update-source address
'show ip route' to the neighbor, and ACL / firewall hit counters for port 179
A capture of the TCP handshake at your edge (and the far side's, if the provider will share it)
The provider's ASN confirmation and both sides' exact software versions