Day 5 — BGP Finite-State Machine: States, Transitions and Session Troubleshooting
Learning objective
Use the BGP finite-state machine as a troubleshooting model: identify what a current state proves, what it does not prove, and which layer of evidence should be collected next.
 |
| BGP Finite-State Machine |
1. Opening — a BGP state is evidence, not a diagnosis
BGP state = Active is one of the most misunderstood lines in routing operations.
The word *Active* sounds healthy. In BGP it is not the desired steady state. The desired operational state is Established. Active is part of the connection-establishment process and often appears when the speaker is repeatedly trying to create the underlying TCP session.
Likewise, Idle does not automatically mean “interface down,” and OpenSent does not mean “routes are being sent.” Each state represents a particular stage in the BGP finite-state machine (FSM). The state narrows the investigation, but the state alone is not the root cause.
The best BGP troubleshooters therefore ask two questions:
- What has already succeeded if the session reached this state?
- What is the next protocol event that must succeed before the state can advance?
That turns the FSM into a diagnostic map instead of a list to memorize.
2. Why BGP has a finite-state machine
BGP session establishment includes several independent mechanisms:
- local configuration and administrative enablement;
- TCP connection establishment;
- BGP OPEN exchange;
- version/ASN/hold-time/identifier/optional-parameter processing;
- capability negotiation;
- KEEPALIVE confirmation;
- and, finally, ongoing UPDATE exchange.
An FSM gives the implementation a deterministic way to react to events such as:
- start or stop;
- successful or failed TCP connection;
- TCP connection loss;
- OPEN received;
- KEEPALIVE received;
- NOTIFICATION received;
- timer expiry;
- and protocol errors.
RFC 4271 defines the core BGP FSM. RFC 9687 later defines the SendHoldTimer and an associated FSM event to address cases where a BGP speaker is unable to send messages for too long even though the remote side has not closed the connection. That extension is useful standards context, but platform implementation/support must be verified before assuming a specific Cisco release exposes or implements it in a particular way.
3. The six core states
3.1 Idle
Idle is the starting/reset state of the BGP FSM.
Conceptually, in Idle the speaker is not in a usable BGP relationship with the peer. Depending on events and configuration, the implementation initializes resources and waits for a start event before attempting transport establishment.
Operational interpretation:
- The session is not established.
- Do not assume the cause is physical connectivity.
- Check whether the neighbor is administratively configured/activated, whether the process is running, whether a reset just occurred, and what the last reset reason says.
3.2 Connect
In Connect, BGP is waiting for the TCP connection to complete.
What reaching Connect suggests:
- the BGP process is attempting session establishment;
- the transport connection is the immediate dependency.
What it does not prove:
- that IP reachability is bidirectional;
- that TCP/179 is permitted;
- that the peer address is correct;
- that the remote ASN matches;
- or that BGP OPEN negotiation will succeed.
3.3 Active
In Active, the speaker is also working on transport establishment, generally after a connection attempt has failed or while retry behavior continues.
The crucial operational rule:
> Active does not mean Established and it does not mean routes are being exchanged.
If a session repeatedly appears in Connect/Active, focus first on transport and peer reachability rather than route policy.
Typical areas to check:
- routing to the peer address;
- return routing;
- source address/update-source;
- TCP/179 ACL/firewall handling;
- multihop/TTL design;
- peer availability;
- duplicate or incorrect neighbor configuration.
3.4 OpenSent
OpenSent means the TCP transport has progressed far enough for BGP OPEN processing to be underway.
This is a major troubleshooting boundary. If you reliably reach OpenSent, the problem is no longer simply “TCP cannot connect.” Now inspect BGP session parameters and OPEN validation:
- BGP version compatibility;
- configured/received ASN;
- BGP Identifier validity;
- hold-time negotiation constraints;
- optional parameters;
- capability requirements;
- and NOTIFICATION information.
An ASN mismatch frequently manifests around OPEN processing, although the exact visible state may be brief because the peer can immediately send a NOTIFICATION and reset.
3.5 OpenConfirm
OpenConfirm means OPEN negotiation has succeeded sufficiently for the speaker to wait for confirmation through KEEPALIVE processing.
At this point:
- TCP has succeeded;
- OPEN has been accepted;
- the session is close to Established.
If a session repeatedly reaches OpenConfirm and fails, investigate KEEPALIVE/timer behavior, transport stability, protocol errors and any reset reason rather than basic neighbor IP configuration alone.
3.6 Established
Established is the operational state in which BGP peers can exchange UPDATE, KEEPALIVE and other negotiated/defined BGP messages as applicable.
But Established proves only that the session is operational.
It does not prove:
- required prefixes were received;
- received prefixes passed import policy;
- the expected path became best;
- the route entered the RIB;
- the route entered the FIB;
- or end-to-end forwarding works.
This distinction will appear throughout the entire series.
4. Troubleshooting map by state
| State | What to investigate first | Common evidence |
|---|---|---|
| Idle | configuration/start/reset cause | running config, logs, neighbor detail |
| Connect | TCP establishment | routing, ping, TCP capture, ACLs |
| Active | failed/retrying transport | route to peer, source address, TCP/179, TTL/multihop |
| OpenSent | OPEN parameters | remote AS, BGP Identifier, NOTIFICATION, capabilities |
| OpenConfirm | KEEPALIVE/transport stability | message counters, timers, resets |
| Established | route exchange and forwarding | received/accepted/best routes, RIB/FIB, traffic tests |
This table is a starting point, not a substitute for evidence. A fast state transition may never be visible in a periodic CLI poll. Logs or packet capture can reveal events that show ip bgp summary misses.
5. Scenario — RETICUX Lab FND-005
Two directly connected eBGP routers form a stable session. We then apply an interface ACL that blocks BGP TCP traffic between them while leaving ICMP permitted.
Topology
 |
| BGP Finite-State Machine: States, Transitions and Session Troubleshooting |
+----------------+ 203.0.113.0/30 +----------------+
| EDGE-A AS64512 |---------------------------| EDGE-B AS64513 |
| 203.0.113.1 | eBGP | 203.0.113.2 |
+----------------+ +----------------+Success criteria before fault
- Ping works both ways.
- BGP is Established.
- Neighbor detail shows normal message activity.
Fault objective
Demonstrate that IP reachability can remain healthy while TCP/BGP establishment fails, causing the FSM to remain outside Established.
6. Baseline configuration
EDGE-A
hostname EDGE-A
!
interface GigabitEthernet0/0
ip address 203.0.113.1 255.255.255.252
no shutdown
!
router bgp 64512
bgp log-neighbor-changes
neighbor 203.0.113.2 remote-as 64513
address-family ipv4
neighbor 203.0.113.2 activate
exit-address-familyEDGE-B
hostname EDGE-B
!
interface GigabitEthernet0/0
ip address 203.0.113.2 255.255.255.252
no shutdown
!
router bgp 64513
bgp log-neighbor-changes
neighbor 203.0.113.1 remote-as 64512
address-family ipv4
neighbor 203.0.113.1 activate
exit-address-family7. Verification before modification
On both routers:
show ip bgp summary
show ip bgp neighborsExpected relevant evidence:
- state Established;
- remote AS correct;
- connection uptime increasing;
- KEEPALIVE/OPEN message counters present;
- no recent unexpected reset.
Verify IP connectivity:
ping 203.0.113.2from EDGE-A and the reverse from EDGE-B.
8. Controlled modification — block only BGP TCP on EDGE-A inbound
Apply this ACL on EDGE-A:
configure terminal
ip access-list extended BLOCK-BGP-FSM-LAB
deny tcp host 203.0.113.2 host 203.0.113.1 eq bgp
deny tcp host 203.0.113.2 eq bgp host 203.0.113.1
permit ip any any
!
interface GigabitEthernet0/0
ip access-group BLOCK-BGP-FSM-LAB in
endThen allow the existing session to fail naturally or, in a controlled lab only, perform a BGP reset to force immediate re-establishment testing.
Do not casually clear production BGP sessions merely to make a lab symptom appear faster.
Expected control-plane result
The session cannot complete/re-establish the TCP connection. The exact instantaneous FSM state can vary as the implementation retries, but the session should not remain Established while the ACL blocks the required TCP exchange.
Expected data-plane observation
ICMP can still pass because the ACL permits other IP traffic. This creates the important troubleshooting clue: ping succeeds but BGP transport fails.
9. Fault injection
Illustrative lab
 |
| BGP Finite-State Machine: States, Transitions and Session Troubleshooting |
Fault
An inbound ACL on EDGE-A blocks TCP traffic associated with BGP between the two peer addresses while permitting other IP traffic.
Symptoms
- Ping succeeds.
- BGP is not Established.
- FSM may cycle through connection-establishment states.
- Route exchange stops.
- Logs can show neighbor down/reset events.
Why this fault is useful
It proves that “I can ping the neighbor” is necessary evidence for IP reachability but is not sufficient evidence for BGP transport.
10. Evidence-based troubleshooting
Step 1 — scope
show ip bgp summaryConfirm that the problem is the session, not merely a missing prefix.
Step 2 — confirm Layer 3
ping 203.0.113.2
show ip route 203.0.113.2If ping succeeds and the route is connected, do not stop troubleshooting.
Step 3 — inspect FSM and reset reason
show ip bgp neighbors 203.0.113.2
show loggingRecord the state and recent connection/reset information.
Step 4 — inspect interface policy
show ip interface GigabitEthernet0/0
show access-lists BLOCK-BGP-FSM-LABACL counters can provide direct evidence that the BGP TCP packets are hitting the deny statements.
Step 5 — packet capture where available
A controlled capture can show repeated TCP SYN attempts without successful completion. Do not fabricate packet details if no capture was taken.
Step 6 — correct the proven layer
Remove the ACL or modify it to permit the authorized BGP transport. Do not change ASNs, timers or BGP path policy when the failure is clearly at transport filtering.
11. Root cause and correction
Root cause
The interface ACL blocked the TCP exchange required for BGP while permitting ICMP. IP reachability therefore looked healthy even though BGP could not complete transport/session establishment.
Correction
configure terminal
interface GigabitEthernet0/0
no ip access-group BLOCK-BGP-FSM-LAB in
endOr, in a production design, replace the test ACL with a deliberate control-plane policy that permits only authorized BGP peers rather than removing protection entirely.
12. Post-fix verification
show ip bgp summary
show ip bgp neighbors 203.0.113.2
show loggingConfirm:
- state returns to Established;
- uptime begins increasing;
- message counters increment;
- no recurring reset reason appears.
Then verify any expected routes and forwarding separately.
13. Rollback
The rollback for the fault is the ACL removal shown above.
If the ACL itself is part of a broader security policy, rollback should instead restore the previous known-good ACL version. Preserve:
- the ACL before/after;
- hit counters;
- BGP neighbor detail;
- syslog timestamps;
- packet capture if taken.
Independent management access is mandatory when testing control-plane ACLs remotely.
14. Production lessons
Troubleshooting lesson
Use the FSM to identify the next dependency, not to guess the root cause.
Transport lesson
Ping success does not prove TCP/179 success.
Observability lesson
Fast FSM states may be missed by CLI polling. Logs, neighbor reset reasons and packet captures can show the actual sequence.
Change-management lesson
Control-plane ACL changes deserve the same rollback discipline as BGP policy changes because they can drop every route from a peer at once.
Standards lesson
The core FSM comes from RFC 4271, while later standards such as RFC 9687 can extend behavior. Always separate baseline protocol rules from implementation/version support.
15. Knowledge check
Q1
A BGP peer is repeatedly in Active. Should you first inspect LOCAL_PREF or TCP reachability?
Answer: TCP/peer reachability. LOCAL_PREF affects path selection after routes are exchanged; it does not establish the BGP transport session.
Q2
A peer reaches OpenSent and then resets. What category of configuration becomes more likely than a simple missing route to the peer?
Answer: OPEN/session-parameter problems such as ASN mismatch, BGP Identifier/OPEN validation, capability requirements or a received NOTIFICATION.
Q3
A peer is Established but receives zero expected routes. Is the FSM still the primary troubleshooting focus?
Answer: No. The session is operational. Move to route origination, received/accepted route state, policy, best path, next hop, RIB/FIB and forwarding.
16. Sources
- RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)*, Section 8 FSM and related message processing.
- RFC 9687 — *Border Gateway Protocol 4 (BGP-4) Send Hold Timer*.
- Cisco — *BGP Command Reference: show ip bgp neighbors*.
- Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x*.
Accessed: 2026-08-11.
