BGP keeps its protocol machinery lean — four message types handle everything from session negotiation to route exchange to error reporting. Each message rides on the TCP session established during the FSM process we covered in How BGP Works. Understanding these messages at the field level makes debug output and packet captures far more readable.
BGP Message Header
Every BGP message starts with a fixed 19-byte header:
- Marker (16 bytes): All ones (0xFF) when no authentication is used. With MD5 authentication, this field carries the authentication digest.
- Length (2 bytes): Total message length including the header. Minimum 19 bytes (KEEPALIVE), maximum 4096 bytes.
- Type (1 byte): 1 = OPEN, 2 = UPDATE, 3 = NOTIFICATION, 4 = KEEPALIVE.
OPEN Message
Sent immediately after the TCP three-way handshake completes. The OPEN is BGP's handshake — it proposes session parameters that both sides must agree on.
Key Fields
- Version: Always 4 (BGP-4, RFC 4271).
- My Autonomous System: The sender's ASN. For 4-byte ASNs, this field contains AS_TRANS (23456) and the real ASN is carried in an optional capability.
- Hold Time: Proposed hold timer in seconds. The lower value of the two peers' proposals wins. Setting this to 0 disables keepalives entirely (not recommended). Default on IOS XE is 180 seconds.
- BGP Identifier: The router ID, a 32-bit value typically set to the highest loopback IP or manually configured.
- Optional Parameters: Capabilities advertisements — this is where multiprotocol extensions (IPv6, VPNv4), 4-byte ASN support, route refresh, graceful restart, and other features are negotiated.
Verifying on IOS XE
R1-HQ# show ip bgp neighbors 203.0.113.1 | section opens
Opens: 3 3
Notifications: 1 0
Updates: 156 42
Keepalives: 1842 1756
Route Refresh: 0 2
Total: 2002 1803R1-HQ# show ip bgp neighbors 203.0.113.1 | include hold
Configured hold time is 180, keepalive interval is 60 seconds
Minimum holdtime from neighbor is 0 seconds
My hold time is 180 secondsUPDATE Message
The UPDATE is BGP's workhorse — it carries routing information. A single UPDATE can advertise one set of prefixes (that share the same path attributes) and withdraw previously advertised prefixes, all in one message.
Key Fields
- Withdrawn Routes Length + Withdrawn Routes: A list of prefixes the sender is removing. Each prefix is encoded as a length/prefix pair. An empty field means nothing is being withdrawn.
- Total Path Attribute Length + Path Attributes: The attributes that apply to the advertised prefixes — AS_PATH, NEXT_HOP, ORIGIN, LOCAL_PREF, MED, COMMUNITY, and others. We cover these in detail in BGP Path Attributes Explained.
- Network Layer Reachability Information (NLRI): The prefixes being advertised, encoded as length/prefix pairs. All prefixes in a single UPDATE share the same path attributes.
An UPDATE with only withdrawn routes and no NLRI is a withdrawal message. An UPDATE with NLRI but no withdrawals is a pure advertisement. Both can coexist in one message.
UPDATE Processing Pipeline
When R1-HQ receives an UPDATE from ISP-A-PE1:
- Parse withdrawn routes — remove them from the Adj-RIB-In for this peer
- Parse path attributes and NLRI — add/update entries in the Adj-RIB-In
- Apply inbound route-map/filter-list/prefix-list
- Run best path selection across all Adj-RIB-In entries for each prefix
- Install best paths in Loc-RIB and (if best) in the IP routing table
- Apply outbound policy and generate UPDATEs to other peers as needed
KEEPALIVE Message
The simplest BGP message — it's just the 19-byte header with type 4. No payload. Its sole purpose is to tell the peer "I'm still here."
Keepalives are sent at one-third the negotiated hold time. With the default hold time of 180 seconds, keepalives go out every 60 seconds. If the hold timer expires without receiving a KEEPALIVE or UPDATE from the peer, the session is declared dead.
R1-HQ# show ip bgp neighbors 203.0.113.1 | include timer
Configured hold time is 180, keepalive interval is 60 seconds
Last read 00:00:22, last write 00:00:14, hold time is 180, keepalive interval is 60 secondsThe last read counter tells you how long since the last message was received from this peer. If this climbs toward 180 seconds, you're about to lose the session.
NOTIFICATION Message
NOTIFICATION means something is wrong — and the session is being torn down. This is the only BGP message that always results in session termination. After sending a NOTIFICATION, the router closes the TCP connection and returns the FSM to Idle.
Key Fields
- Error Code: The category of error (1 = Message Header, 2 = OPEN, 3 = UPDATE, 4 = Hold Timer Expired, 5 = FSM, 6 = Cease).
- Error Subcode: More specific detail within the category.
- Data: Optional field containing the problematic portion of the message that triggered the error.
Common NOTIFICATION Codes
| Code | Subcode | Meaning | Typical Cause |
|---|---|---|---|
| 2 | 2 | Bad Peer AS | Configured remote-as doesn't match peer's actual ASN |
| 2 | 4 | Unsupported Optional Parameter | Capability mismatch between peers |
| 4 | 0 | Hold Timer Expired | Peer stopped sending keepalives — link issue, CPU overload, or MTU problem |
| 6 | 2 | Administrative Shutdown | Peer was shut down with neighbor shutdown |
| 6 | 4 | Administrative Reset | Peer was cleared with clear ip bgp |
| 6 | 6 | Other Configuration Change | Policy change requiring hard reset |
R1-HQ# show ip bgp neighbors 203.0.113.1 | include Notification
Notification: 2/2 (OPEN Message Error/Bad Peer AS) 0 times
Last reset 00:45:12, due to BGP Notification sent, hold time expiredMessage Flow During Session Establishment
Here's the complete message sequence when R1-HQ peers with ISP-A-PE1:
- TCP SYN → SYN-ACK → ACK (three-way handshake)
- R1-HQ sends OPEN (AS 65001, hold 180, router-id 1.1.1.1, capabilities)
- ISP-A-PE1 sends OPEN (AS 65010, hold 180, router-id 203.0.113.1, capabilities)
- Both sides validate the OPEN — AS numbers match config, capabilities compatible
- Both send KEEPALIVE to confirm
- State moves to Established
- Both sides send UPDATE messages with their full Adj-RIB-Out
- Periodic KEEPALIVEs every 60 seconds to maintain the session
Key Takeaways
- BGP uses exactly four message types — OPEN for negotiation, UPDATE for routes, KEEPALIVE for liveness, NOTIFICATION for errors.
- UPDATE is the most complex message, carrying both advertisements (NLRI + path attributes) and withdrawals in a single message.
- KEEPALIVE is the simplest — just a 19-byte header with no payload, sent every 60 seconds by default.
- NOTIFICATION always tears down the session. The error code and subcode tell you exactly what went wrong — memorize the common ones (Hold Timer Expired, Bad Peer AS, Administrative Shutdown).
- Use
show ip bgp neighbors [ip]to see message counters, hold timer status, and last notification reason.