BGP

BGP Message Types: OPEN, UPDATE, KEEPALIVE, and NOTIFICATION

BGP uses just four message types: OPEN, UPDATE, KEEPALIVE, and NOTIFICATION. Understanding the field-level format of each makes debug output and packet captures far more readable for anyone troubleshooting BGP.
BGP Message Types: OPEN, UPDATE, KEEPALIVE, and NOTIFICATION
In: BGP

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       1803
R1-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 seconds

UPDATE 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:

  1. Parse withdrawn routes — remove them from the Adj-RIB-In for this peer
  2. Parse path attributes and NLRI — add/update entries in the Adj-RIB-In
  3. Apply inbound route-map/filter-list/prefix-list
  4. Run best path selection across all Adj-RIB-In entries for each prefix
  5. Install best paths in Loc-RIB and (if best) in the IP routing table
  6. 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 seconds

The 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

CodeSubcodeMeaningTypical Cause
22Bad Peer ASConfigured remote-as doesn't match peer's actual ASN
24Unsupported Optional ParameterCapability mismatch between peers
40Hold Timer ExpiredPeer stopped sending keepalives — link issue, CPU overload, or MTU problem
62Administrative ShutdownPeer was shut down with neighbor shutdown
64Administrative ResetPeer was cleared with clear ip bgp
66Other Configuration ChangePolicy 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 expired

Message Flow During Session Establishment

Here's the complete message sequence when R1-HQ peers with ISP-A-PE1:

  1. TCP SYN → SYN-ACK → ACK (three-way handshake)
  2. R1-HQ sends OPEN (AS 65001, hold 180, router-id 1.1.1.1, capabilities)
  3. ISP-A-PE1 sends OPEN (AS 65010, hold 180, router-id 203.0.113.1, capabilities)
  4. Both sides validate the OPEN — AS numbers match config, capabilities compatible
  5. Both send KEEPALIVE to confirm
  6. State moves to Established
  7. Both sides send UPDATE messages with their full Adj-RIB-Out
  8. 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.
Written by
More from Ping Labz
MPLS L3VPN with MP-BGP and VPNv4
MPLS

MPLS L3VPN with MP-BGP and VPNv4

MPLS L3VPN architecture: VRFs, Route Distinguishers, Route Targets, MP-BGP for VPNv4, the two-label stack, PE-CE routing, and the Cisco IOS XE configuration.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Ping Labz.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.