BGP doesn't discover neighbors automatically like OSPF does with multicast hellos. Every BGP peering session is deliberately configured, runs over a TCP connection on port 179, and progresses through a strict finite state machine before a single route is exchanged. Understanding this process is the foundation for everything else in BGP — from configuration to troubleshooting.
TCP — BGP's Transport
BGP is the only major routing protocol that runs over TCP. This gives it reliable, ordered delivery without needing to build that into the protocol itself. When two BGP speakers are configured to peer, one initiates a TCP connection to port 179 on the other. The three-way TCP handshake (SYN, SYN-ACK, ACK) must complete before any BGP messages flow.
This has practical implications: firewalls and ACLs must permit TCP/179 in both directions. If you're peering over a transit link, the source IP must match the configured neighbor address exactly. Mismatches here are the number one cause of peers stuck in Active state — more on that in Troubleshooting BGP Neighbor Adjacency Issues.
The BGP Finite State Machine
Once the TCP session is attempted, each BGP speaker tracks the peer's state through six stages:
1. Idle
The router has a neighbor configured but hasn't started connecting. BGP initializes resources and waits for a Start event (administrative enable or retry timer expiry). If something goes wrong at any later stage, the peer drops back to Idle and a ConnectRetry timer starts.
2. Connect
The router is actively attempting the TCP three-way handshake to port 179 on the peer. If TCP connects successfully, the router sends a BGP OPEN message and moves to OpenSent. If the TCP connection fails, the router moves to Active.
3. Active
The router is retrying the TCP connection. Despite the name, Active is actually a problem state — it means the TCP handshake keeps failing. Common causes: wrong neighbor IP, ACL blocking TCP/179, interface down, or a routing issue preventing reachability to the peer address.
4. OpenSent
TCP is established and the local router has sent its OPEN message. It's waiting for the peer's OPEN in return. If the peer's OPEN is acceptable (matching AS numbers, compatible capabilities), the router sends a KEEPALIVE and moves to OpenConfirm. If the OPEN is rejected (wrong AS, bad parameters), a NOTIFICATION is sent and the peer drops to Idle.
5. OpenConfirm
Both OPEN messages have been exchanged and accepted. The router is waiting for a KEEPALIVE from the peer to confirm the session. Once received, the state moves to Established.
6. Established
The session is up. UPDATE messages carrying NLRI (routes) begin flowing. KEEPALIVE messages maintain the session at regular intervals (default every 60 seconds). If the hold timer expires (default 180 seconds — three missed keepalives), the session tears down with a NOTIFICATION and returns to Idle.
BGP Message Types
BGP uses four message types (detailed in BGP Message Types: OPEN, UPDATE, KEEPALIVE, and NOTIFICATION):
| Message | Purpose | When Sent |
|---|---|---|
| OPEN | Negotiate session parameters (ASN, hold time, router ID, capabilities) | After TCP connects |
| UPDATE | Advertise new prefixes or withdraw previously advertised ones | After Established state |
| KEEPALIVE | Confirm the peer is alive | Every 60s by default |
| NOTIFICATION | Signal an error and tear down the session | On error condition |
BGP Tables: Adj-RIB-In, Loc-RIB, Adj-RIB-Out
Each BGP speaker maintains three conceptual tables per address family:
- Adj-RIB-In: All routes received from a specific peer, before any inbound policy is applied. View with
show ip bgp neighbors [ip] received-routes. - Loc-RIB: The main BGP table after inbound policy and best path selection. This is what
show ip bgpdisplays. Only the best path (marked with>) is installed in the routing table. - Adj-RIB-Out: Routes advertised to a specific peer after outbound policy. View with
show ip bgp neighbors [ip] advertised-routes.
The flow is: Adj-RIB-In → inbound route-map/filter → best path selection → Loc-RIB → outbound route-map/filter → Adj-RIB-Out. Understanding this pipeline is essential for troubleshooting why a route isn't being advertised or received — a topic we cover extensively in Troubleshooting BGP Route Advertisement Problems.
Verifying BGP on IOS XE
On our PingLabz BGP Lab, R1-HQ (AS 65001) peers with ISP-A-PE1 (AS 65010). Here's what a healthy session looks like:
R1-HQ# show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 24, main routing table version 24
12 network entries using 2976 bytes of memory
14 path entries using 1792 bytes of memory
4/3 BGP path/bestpath attribute entries using 1088 bytes of memory
2 BGP AS-PATH entries using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
203.0.113.1 4 65010 1842 1756 24 0 0 1d02h 8
10.1.1.2 4 65001 945 948 24 0 0 1d02h 4The State/PfxRcd column shows a number — that means the session is Established and the peer has sent that many prefixes. If you see a state name (Active, OpenSent, Idle) instead of a number, the session isn't up.
R1-HQ# show ip bgp neighbors 203.0.113.1 | include state
BGP state = Established, up for 1d02h
BGP table version 24, neighbor version 24/0Key Takeaways
- BGP runs over TCP port 179 — both sides must be reachable and firewalls must permit the traffic bidirectionally.
- The six-state FSM (Idle → Connect → Active → OpenSent → OpenConfirm → Established) tells you exactly where a session is failing.
- A peer stuck in Active means the TCP handshake is failing — check reachability, ACLs, and source IP matching.
- BGP maintains three tables per peer: Adj-RIB-In (received), Loc-RIB (best paths), and Adj-RIB-Out (advertised).
- In
show ip bgp summary, a number in State/PfxRcd means the session is healthy; a state name means it's not.