> ## Content Index
> Fetch the complete content index at: https://www.pinglabz.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# BGP Message Types: OPEN, UPDATE, KEEPALIVE, and NOTIFICATION
- URL: https://www.pinglabz.com/bgp-message-types/
- Published: 2026-03-28T06:52:01.000Z
- Updated: 2026-07-04T22:56:41.000Z
- Description: 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.
- Author: Jaime
- Tags: BGP, #Import 2026-08-01 19:54

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](https://www.pinglabz.com/how-bgp-works/). Understanding these messages at the field level makes debug output and packet captures far more readable.

If you want the bigger picture first, the [BGP complete guide](https://www.pinglabz.com/bgp/) covers the architecture this article plugs into.

## 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](https://www.pinglabz.com/bgp-path-attributes/).
- **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

2

Code2

MeaningBad Peer AS

Typical Cause

Configured remote-as doesn't match peer's actual ASN

4

Code2

Meaning

Unsupported Optional Parameter

Typical Cause

Capability mismatch between peers

0

Code4

MeaningHold Timer Expired

Typical Cause

Peer stopped sending keepalives - link issue, CPU overload, or MTU problem

2

Code6

Meaning

Administrative Shutdown

Typical Cause

Peer was shut down with `neighbor shutdown`

4

Code6

MeaningAdministrative Reset

Typical Cause

Peer was cleared with `clear ip bgp`

6

Code6

Meaning

Other Configuration Change

Typical Cause

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 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.