BGP · · 4 min read

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

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:

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

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

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

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

Read next

© 2025 Ping Labz. All rights reserved.