Because nothing ruins your day quite like a BGP session stuck in Active state
As a network engineer, you know BGP is the backbone of the internet and pretty much all modern enterprise networks. When it's humming along, it's smooth sailing. But when it hiccups? It can be a real headache.
The trick to fixing BGP issues is understanding its Finite State Machine (FSM).
This guide covers the basics of BGP, why it's important, and then dives deep into each BGP state. You'll get a step-by-step rundown on how BGP sessions form, what each state means, and the essential Cisco commands you'll need to figure out what's going wrong. We'll throw in sample outputs and talk about what all this means for performance and troubleshooting.
Table of contents
Border Gateway Protocol (BGP) is the Internet's interdomain routing protocol. It's a path-vector protocol designed for policy-based routing and scalability. Instead of shortest path like OSPF/IS-IS, this BGP routing protocol lets you prefer or avoid paths using attributes (AS-PATH, LOCAL_PREF, MED, communities).
BGP is crucial in three main areas:
The whole global internet runs on External BGP (eBGP) sessions between different organizations. When you browse a website, BGP is working behind the scenes, figuring out the best path for your packets to hop between different Autonomous Systems to reach their destination.
Enterprise Networks: Modern companies use both Internal BGP (iBGP) and eBGP. Why? To connect multiple office locations, manage MPLS VPNs, handle backup internet connections from different ISPs, and build modern data center fabrics using EVPN-VXLAN. Understanding Cisco ACI architecture components helps illustrate how BGP underpins these modern fabric designs.
Service Providers use BGP for everything – connecting customers, steering traffic, setting up route reflectors, and managing the whole complex web of peering relationships that make up the internet.
The main difference between iBGP and eBGP is simple: eBGP connects different organizations (with different AS Numbers or ASNs), while iBGP connects routers within the same organization (using the same ASN). A key rule for iBGP is that it won't re-advertise routes learned from one iBGP peer to another iBGP peer (this prevents routing loops). That's why, in bigger iBGP networks, you need route reflectors or confederations.
Knowing how BGP transitions between states is a critical skill for debugging routing issues efficiently. Each state in the BGP Finite State Machine (FSM) gives you specific clues about what’s going wrong, helping you target your fixes.
BGP state machine troubleshooting: If you see a BGP neighbor stuck in the Active state or constantly bouncing between Connect and Active, you immediately know where to look: Layer 3 reachability, TCP port 179 issues, a wrong ASN, or an authentication mismatch.
Operations & Automation: Your monitoring and automation systems can keep an eye on BGP neighbor states and timers. This helps them quickly flag failing peers or trigger automated recovery actions.
Design & Performance: A solid understanding of the FSM helps you design BGP peerings that are more stable and avoid those annoying route flaps that can slow down your network.
BGP works like a "finite state machine"—its sessions move through a predictable, ordered series of states. Each state shows you where the BGP relationship between two routers currently stands. Here are the six BGP states:
When everything works perfectly, BGP sessions move through these states in order and settle into the Established state, exchanging routes until something breaks. When things go wrong, sessions can get stuck in one state or bounce endlessly between a couple of states.
Before we dive into each state, here's the single most important command for BGP troubleshooting. On Cisco IOS, IOS-XE, and NX-OS, this should always be your first stop:
Router# show ip bgp summary
This command gives you a super quick, bird's-eye view of all your BGP neighbors and their current states. Here’s what normal output looks like:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.2 4 65002 123 130 9 0 0 01:22:13 25
10.1.1.3 4 65003 0 0 0 0 0 00:00:34 Active
10.1.1.4 4 65004 0 0 0 0 0 00:00:15 Idle
The first neighbor (10.1.1.2) is healthy—it's been Established for over an hour and received 25 prefixes. The second neighbor is stuck in Active, and the third is in Idle. That State/PfxRcd column is crucial. If you see a number, the session is up. If you see a state name, something's broken, and that's where you need to focus.
For Cisco NX-OS, the commands are very similar:
N9K# show bgp ipv4 unicast summary
N9K# show bgp neighbors
Pro tip: Always run show ip bgp summary first. It's the quickest way to check the health of your BGP setup and will immediately tell you which neighbors need a closer look.
Let's break down each BGP state, what it means, and what commands to use for troubleshooting on Cisco gear.
What it means: BGP is ready to go but hasn't started anything yet. It's the starting and ending point for all sessions.
Cisco CLI:
R1# show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.4 4 65004 0 0 0 0 0 00:00:12 Idle
Notice those zeros? No messages received, none sent, and the session has been down for 12 seconds.
If you turn on debugging (and I mean if—be careful with debug commands in production), you might see something like:
R1# debug ip bgp
*Mar 1 00:00:35.123: BGP: 10.1.1.4 open failed: Connection timed out
Common causes of Idle state issues:
Performance impact: Minimal. It just means no routes are being exchanged, which is bad if that session is critical.
What it means: BGP has tried to start a TCP connection and is waiting for it to complete. This state should be super brief. If it lingers, you've got TCP connectivity issues.
Debug hint:
R1# debug ip tcp transactions
*Mar 1 00:00:40.019: TCP connection to 10.1.1.2(179) initiated
The Connect state has a built-in timer (often 120 seconds). If the TCP handshake doesn't complete within that time, the session moves to the Active state to retry.
You can quickly verify TCP connectivity from your CLI:
R1# ping 10.1.1.2
R1# telnet 10.1.1.2 179
If the telnet command fails, you know TCP port 179 is not reachable. This could be due to ACLs, firewalls, or the remote router not running BGP on that interface.
Performance impact: Minimal, but if it's stuck here, it's wasting time due to the TCP connect timer.
What it means: This is a common "stuck" state. The initial TCP connection attempt failed, and the router is actively retrying. You'll often see sessions stuck in a loop between Connect and Active if the neighbor isn't reachable or configured correctly.
Summary view:
R1# show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.3 4 65003 0 0 0 0 0 00:00:34 Active
The Active state often creates a "Connect/Active death spiral." The session tries to connect (Connect state), fails (Active), then retries (Connect), fails again (Active), and so on. If you see this pattern, you have a fundamental connectivity or configuration problem.
What causes sessions to get stuck in Active:
IP reachability issues are the most common culprit. Even if you can ping the neighbor, TCP port 179 may not be reachable. Check your routing tables, ensure there are no asymmetric routing problems, and verify intermediate devices are not blocking traffic.
Configuration mismatches can also cause Active state loops. If your router is configured with remote-as 65003 but the actual remote AS is 65004, the TCP connection might establish, but BGP will immediately tear it down when it sees the wrong AS number in the received OPEN message.
A missing neighbor configuration on the remote side is another classic. Your router is trying to connect to 10.1.1.3, but if that router doesn't have a reciprocal neighbor 10.1.1.2 remote-as configuration, it will reject the connection attempt.
Don't forget basic networking issues like an incorrect interface status, firewall rules, or NAT configurations that might interfere with BGP traffic.
Performance impact: Uses more CPU than Idle because it's actively trying to connect. More importantly, it delays route convergence.
What it means: The TCP connection is up, and your router has sent its BGP OPEN message. Now it's just waiting for the neighbor's OPEN message back. This state should be very short. If it gets stuck here, check BGP parameter mismatches.
What triggers the transition to OpenSent:
The TCP three-way handshake must complete successfully. Your router sends a BGP OPEN message containing its BGP version (almost always 4), its AS number, its BGP router ID, its configured hold and keepalive timers, and any optional capabilities it supports. The BGP hold timer starts counting down. By default, this is 180 seconds, so if the neighbor doesn't respond within 3 minutes, the session will reset.
Debug hint:
R1# debug ip bgp
*Mar 1 00:01:12.233: BGP: 10.1.1.2 sending OPEN, version 4, holdtime 180, ID 192.168.1.1
Common issues in OpenSent state:
BGP version mismatches are rare since virtually everyone uses version 4. AS number mismatches are more common.
If your configuration says the neighbor should be in AS 65002, but it sends an OPEN message claiming to be in AS 65003, the session will reset.
Always double-check your remote-as configuration on both sides.
Authentication mismatches will also cause problems. If one side expects MD5 authentication but the other doesn't have it configured (or has the wrong password), the session will fail.
Performance impact: OpenSent uses minimal resources as your router is just waiting for a response. The main performance consideration is the hold timer, if sessions frequently time out in OpenSent, you're wasting 3 minutes each time before the session resets and tries again.
What it means: Both routers have successfully exchanged OPEN messages and are now sending KEEPALIVE messages. This is the final step before the session becomes fully Established. It should also be very brief.
Debug hint:
R1# debug ip bgp
*Mar 1 00:01:14.100: BGP: 10.1.1.2 rcv KEEPALIVE
What can go wrong in OpenConfirm:
Authentication problems can still surface here if there are subtle issues with the MD5 configuration. Both sides might accept each other's OPEN messages but then fail when trying to authenticate the subsequent KEEPALIVE messages.
Timer mismatches can occasionally cause issues, though modern BGP implementations are generally good at negotiating compatible timer values. Network instability can also cause problems. If there's packet loss or high latency, KEEPALIVE messages might not make it through reliably, causing the session to time out.
Performance impact: OpenConfirm uses minimal resources and should last only a few seconds. If sessions are getting stuck here, it usually indicates intermittent connectivity issues that will likely cause problems even after the session establishes.
What it means: The session is up, both sides are exchanging KEEPALIVE messages to maintain the session, and UPDATE messages are flowing to exchange routing information.
Summary & neighbors detail:
R1# show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.2 4 65002 123 130 9 0 0 01:22:13 25
See that "25" in the State/PfxRcd column? That means the session is established and has received 25 prefixes from the neighbor. The session has been up for 1 hour, 22 minutes, and 13 seconds.
Detailed neighbor information:
R1# show ip bgp neighbors 10.1.1.2 | include BGP state|Remote AS|Hold time|Keepalive
BGP state = Established, up for 01:22:13
Remote AS 65002, external link
Hold time is 180, keepalive interval is 60 seconds
Routes present:
R1# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.0/24 10.1.1.2 0 0 65002 i
Here's the typical, successful progression of BGP states:
Real packets on the wire for a successful session:
The beauty of BGP is that the protocol itself works the same way regardless of the vendor. The Active state means the same thing on a Cisco ASR as it does on a Juniper MX or an Arista switch. The challenge for network engineers is that each vendor has slightly different commands and output formats for viewing this information.
Cisco platforms keep their commands relatively simple. IOS and IOS-XE use the same basic commands (show ip bgp summary, show ip bgp neighbors), while NX-OS often adds "ipv4 unicast" to many commands to be more explicit about the address family.
Juniper tends to be more verbose in their output and state descriptions. Where Cisco might just show "Active," Juniper might provide additional context about the specific reason for the active state.
Arista EOS generally follows Cisco's command structure quite closely, which makes it easier for network engineers already familiar with Cisco syntax to adapt.
The key takeaway is that regardless of the exact command syntax, you are always looking for the same fundamental pieces of information: the current session state, message counters (sent/received), uptime, and prefix counts.
Check neighbor IP, interface status, basic IP reachability (ping, telnet 179), and if the BGP process is running on the peer.
Fix example:
R1(config)# router bgp 65001
R1(config-router)# no neighbor 10.1.1.4
R1(config-router)# neighbor 10.1.1.4 remote-as 65004
TCP port 179 is likely blocked, or the remote AS/neighbor configuration is wrong. Double-check everything on both sides.
Configuration verification:
R1(config)# router bgp 65001
R1(config-router)# neighbor 10.1.1.3 remote-as 65003
Look for AS number mismatches, authentication errors, or network instability causing KEEPALIVEs to fail.
Authentication (MD5) Mismatch:
R1(config-router)# neighbor 10.1.1.2 password cisco123
Both ends must use the same password.
Debug authentication failures:
R1# debug ip bgp
*Mar 1 00:03:12: %BGP-4-MD5FAIL: No MD5 digest from peer 10.1.1.2
*Mar 1 00:03:12: BGP: 10.1.1.2 open failed: Bad authentication
Version/parameter mismatch (rare):
R1(config-router)# neighbor 10.1.1.2 version 4
our problem is likely with route maps, prefix lists, or filters blocking the updates. Check received-routes and advertised-routes.
Check policy:
R1# show run | sec router bgp
R1# show ip bgp neighbors 10.1.1.2 received-routes
R1# show ip bgp neighbors 10.1.1.2 advertised-routes
Confirm next-hop reachability for any routes you have received. Carefully check your route-maps, prefix-lists, and distribute-lists for any deny statements.
|
Problem |
Symptom |
What to Check |
|---|---|---|
|
Wrong neighbor IP |
Idle/Active; TCP fails |
show ip int bri, ping/telnet 179, ACLs |
|
Wrong remote-as |
OpenSent/OpenConfirm then reset; NOTIFICATION "peer in wrong AS" |
neighbor x remote-as <AS> on both sides
|
|
Missing neighbor on peer |
Active loop |
Confirm reciprocal config on the other router |
|
MD5 password mismatch |
Drops back to Idle; |
Set identical |
|
eBGP multihop missing (loopback peering) |
Active (TTL=1 dies enroute) |
neighbor x ebgp-multihop + update-source loopback |
|
TTL security (GTSM) mismatch |
Resets on keepalives |
neighbor x ttl-security hops <n> on both ends |
|
Route-maps/filters deny |
Established but |
show ... received-routes, show ... advertised-routes, route-maps, prefix-lists |
Design Recommendations:
show ip bgp summary: This is your quickest and most valuable signal for the overall health of your BGP sessions.Security & Stability:
clear ip bgp soft in|out.Scaling Considerations:
Finally remember that most BGP problems can be diagnosed using show commands and systematic testing. Proper network configuration and change management practices can help prevent many issues from occurring in the first place.
Let's quickly demo how states work with a simple eBGP peering between R1 and R2.
Configs (Cisco IOS):
R1(config)# router bgp 65001
R1(config-router)# neighbor 10.1.1.2 remote-as 65002
R1(config-router)# neighbor 10.1.1.2 description eBGP-to-R2
R1(config-router)# network 192.0.2.0 mask 255.255.255.0
R2(config)# router bgp 65002
R2(config-router)# neighbor 10.1.1.1 remote-as 65001
R2(config-router)# neighbor 10.1.1.1 description eBGP-to-R1
R2(config-router)# network 198.51.100.0 mask 255.255.255.0
Session Establishment Debug Output:
You'll see BGP messages showing the progression: sending OPEN, rcv OPEN, state OpenConfirm, rcv KEEPALIVE, and finally state Established.
R1# debug ip bgp
*Mar 1 00:01:12.001: BGP: 10.1.1.2 open active, local address 10.1.1.1
*Mar 1 00:01:12.433: BGP: 10.1.1.2 sending OPEN, version 4, AS 65001, holdtime 180, ID 203.0.113.1
*Mar 1 00:01:12.701: BGP: 10.1.1.2 rcv OPEN, version 4, AS 65002, holdtime 180, ID 203.0.113.2
*Mar 1 00:01:12.702: BGP: 10.1.1.2 state OpenConfirm
*Mar 1 00:01:12.903: BGP: 10.1.1.2 rcv KEEPALIVE
*Mar 1 00:01:12.903: BGP: 10.1.1.2 state Established
Verification Commands:
show ip bgp summary will show a number for PfxRcd, and show ip bgp will display learned routes.
R1# show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.2 4 65002 35 41 3 0 0 00:15:23 1
R1# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 198.51.100.0 10.1.1.2 0 0 65002 i
R1# show ip bgp neighbors 10.1.1.2 | inc BGP state|Remote AS|Hold|Keepalive|Prefixes
BGP state = Established, up for 00:15:23
Remote AS 65002, external link
Hold time is 180, keepalive interval is 60 seconds
Prefixes Current: 1, Received 1, Sent 1
Let's Break It! Change R2's ASN to 65099. On R1, you'll see a NOTIFICATION: received from neighbor ... 2/2 (peer in wrong AS) message in the logs, and the session will likely drop back to Active or Idle. Fixing the ASN on R2 will usually get the session back up.
R2(config-router)# neighbor 10.1.1.1 remote-as 65099
Debug output on R1:
R1# debug ip bgp
*Mar 1 00:16:01.110: %BGP-3-NOTIFICATION: received from neighbor 10.1.1.2 2/2 (peer in wrong AS) 0 bytes
*Mar 1 00:16:01.111: BGP: 10.1.1.2 active open failed - Notification received
The session will drop back to the Active / Idle state, exactly as expected. If you fix the ASN, it will re-establish.
CloudMyLab's Role: If you want to practice these scenarios without messing with real gear or spending hours on local setups, CloudMyLab's hosted GNS3 or EVE-NG environments are perfect. You can spin up and break BGP sessions all day long, safely learning how to diagnose and fix common state issues.
Quick Tip: iBGP over Loopbacks (and why TTL matters) When peering between loopback interfaces, you typically need to add a couple of extra commands, especially for eBGP:
R1(config-router)# neighbor 192.0.2.2 remote-as 65001
R1(config-router)# neighbor 192.0.2.2 update-source Loopback0
R1(config-router)# neighbor 192.0.2.2 ebgp-multihop 2 ! Only for eBGP via loopbacks
R1(config-router)# neighbor 192.0.2.2 ttl-security hops 2 ! Use GTSM for eBGP
For iBGP, you do not need ebgp-multihop, but you still must use update-source Loopback0 on both sides.
Ensure the loopback addresses are reachable via an underlying IGP (like OSPF or EIGRP) or static routes.
While the troubleshooting process is the same, here are some key commands for different vendors:
Cisco platforms provide good visibility into BGP performance through commands like show processes cpu | include BGP for CPU usage and show memory summary | include BGP for memory consumption
show ip bgp summary ! First look
show ip bgp neighbors [A.B.C.D] ! Parameters, timers, caps, error codes
show ip bgp neighbors A.B.C.D received-routes
show ip bgp neighbors A.B.C.D advertised-routes
show bgp ipv4 unicast summary ! Newer IOS/NX-OS style
show ip tcp brief / show control-plane host open-ports
debug ip bgp / debug ip bgp events / debug ip tcp transactions
show logging | include BGP|179
Juniper offers detailed process monitoring with show system processes extensive | match rpd and memory usage with show task memory detail | match bgp.
show bgp summary ! Concise state view
show bgp neighbor ! Detailed peer info
show route receive-protocol bgp ! Received routes
show route advertising-protocol bgp ! Advertised routes
show log messages | match bgp ! BGP log events
Arista provides similar information through show processes top and show platform cpu utilization.
show ip bgp summary ! State summary
show ip bgp neighbors ! Neighbor details
show ip bgp neighbors routes ! Route details
show bgp instance detail ! BGP process info
System Resource Monitoring:
Cisco
show processes cpu sorted | include BGP show memory platform summary
Juniper
show system processes extensive | match rpd show chassis routing-engine
Arista
show processes top once show platform cpu utilization
Soft resets (policy changes without dropping the session):
clear ip bgp <ip> soft in
clear ip bgp <ip> soft out
BGP state management is about keeping them secure and stable as well. BGP security issues often manifest as state problems, so understanding the security implications of each state helps with both troubleshooting and hardening.
Security considerations by state:
Idle state can indicate potential reconnaissance or misconfigurations. Monitor for unauthorized neighbor configuration attempts and log all state change events for security auditing.
Connect and Active states are where many attacks can target your BGP process. Implement TCP access control lists to limit which IP addresses can attempt to establish BGP connections to your routers.
Established state sessions require ongoing security monitoring. Log all state changes, monitor for unexpected route advertisements, and implement strict inbound and outbound route filtering policies.
GTSM (Generalized TTL Security Mechanism) provides protection against remote attacks:
neighbor A.B.C.D ttl-security hops 2
BGP session authentication:
MD5 authentication is the most common method for securing BGP sessions. Both neighbors must be configured with identical passwords:
neighbor A.B.C.D password <secret>
Network security hardening:
Limit TCP port 179 access with ingress ACLs on your peering interfaces. Only allow BGP traffic from your expected neighbor addresses.
Implement strict route filtering policies. Don't accept routes you don't expect to receive, and don't advertise routes you shouldn't be originating.
Log and monitor all BGP state changes. Export your BGP events to your SIEM system for correlation with other security events.
Check Basic Connectivity
ping A.B.C.D
telnet A.B.C.D 179
Verify Session State
show ip bgp summary
Diagnose State-Specific Issues
show ip bgp neighbors A.B.C.D
debug ip tcp transactions
debug ip bgp
Check Route Exchange
show ip bgp neighbors A.B.C.D received-routes
show ip bgp neighbors A.B.C.D advertised-routes
show ip bgp
Apply State-Specific Fixes
clear ip bgp A.B.C.D soft in|out
Understanding BGP states is about developing an intuition for how sessions establish, what can go wrong at each step, and how to fix problems fast.
Remember the journey: Idle means you're not trying yet; Connect/Active point to TCP issues; OpenSent/OpenConfirm suggest config mismatches; and Established with zero prefixes means you need to check your policies.
Always start with show ip bgp summary. Before diving into complex route maps, double-check the basics: IP reachability, correct ASNs, and TCP port 179 access. BGP is the internet's backbone, and knowing its state machine is a crucial skill for any serious network engineer.
Reading about BGP states is just the beginning. True mastery comes from hands-on practice in realistic network topologies. CloudMyLab's learning labs provide enterprise-grade BGP scenarios where you can:
Key Takeaways:
show ip bgp summary is your first stop for troubleshooting.debug ip bgp, debug ip tcp transactions) to see BGP messages in real-time.
No, BGP is not an application layer protocol. It operates at the network layer for routing decisions but uses TCP as its transport protocol (port 179). While BGP applications run in user space on a router, the protocol's function is to handle network layer routing decisions between autonomous systems.
Yes, BGP is an inter-domain routing protocol or an Exterior Gateway Protocol (EGP). It's the standard for exchanging routing information between different autonomous systems on the internet. Unlike OSPF or EIGRP, BGP specializes in policy-based routing.
Internal BGP (iBGP) needs another routing protocol because BGP isn't designed to provide next-hop reachability within an autonomous system. It relies on an Interior Gateway Protocol (IGP) like OSPF, EIGRP, or IS-IS to establish IP reachability to BGP next-hop addresses, provide fast convergence for internal network changes, handle the internal network topology, and ensure iBGP speakers can reach each other's loopback addresses for peering.
It involves systematically checking each state to diagnose problems: Idle / Active states (check IP/TCP connectivity), OpenSent / OpenConfirm states (verify authentication and BGP parameters), Established state with no routes (check filtering policies). Use commands like show ip bgp summary and show ip bgp neighbors to diagnose issues.
Repeated transitions between Active and OpenSent typically indicate unstable TCP connectivity or intermittent BGP parameter mismatches. Causes include intermittent network connectivity, BGP timer mismatches, authentication issues, capability negotiation failures, and network congestion. The impact includes route instability, high CPU overhead, extended convergence delays, and potential traffic black-holing.
BGP state changes have significant performance implications: route withdrawals, convergence delay, CPU spikes, and memory fluctuations during transitions. Performance metrics affected include packet loss, increased latency, reduced throughput, and jitter.
BGP state changes directly impact routing convergence time. Total convergence time is a sum of detection time (1 second with BFD to 180 seconds with default hold timers), propagation time, processing time, and installation time. Typical convergence times range from 1-5 seconds for a local link failure with fast fallover to 60-300 seconds for a full session re-establishment with a large number of routes.