Day 6 — BGP Message Types: OPEN, UPDATE, KEEPALIVE, NOTIFICATION and ROUTE-REFRESH

at

Learning objective

Identify the purpose of each major BGP message, relate messages to the FSM and routing lifecycle, and use counters/captures to distinguish session-negotiation failures from route-update failures.


BGP Message Types


1. Opening — every BGP outage eventually becomes a message story

When a BGP neighbor fails, the CLI summarizes the outcome. The wire explains the sequence.

A peer did not merely “go down.” Perhaps TCP established, an OPEN was exchanged, the receiver rejected an ASN or capability and sent a NOTIFICATION. Perhaps the session stayed Established but an UPDATE withdrew a critical prefix. Perhaps a policy change required the peer to re-advertise routes through ROUTE-REFRESH. Perhaps malformed UPDATE information triggered modern error handling rather than an unnecessary full-session reset.

Learning BGP message types gives engineers a protocol-level language for those events.

The base BGP-4 specification defines four message types:

  1. OPEN
  2. UPDATE
  3. NOTIFICATION
  4. KEEPALIVE

The ROUTE-REFRESH message was defined later by RFC 2918 as part of the route-refresh capability. Modern BGP also relies heavily on capability advertisement in OPEN as defined by RFC 5492 and updated by subsequent standards.

2. Common BGP message header

BGP messages share a common header defined by RFC 4271. At a conceptual level it contains:

  • a Marker field;
  • a Length field;
  • a Type field.

The Type tells the receiver how to interpret the remaining message body.

For packet analysis, the practical lesson is to first identify the BGP message type, then decode the fields relevant to that type. Do not jump directly to AS_PATH or NLRI if the packet is an OPEN or KEEPALIVE.

3. OPEN — negotiate the session

After TCP establishes, each BGP speaker sends an OPEN message.

The OPEN contains essential session information including:

  • BGP version;
  • sender’s autonomous-system information in the base field, with four-octet support handled through the four-octet ASN capability/transition mechanisms;
  • hold time;
  • BGP Identifier;
  • optional parameters.

Capabilities

RFC 5492 defines capability advertisement using an Optional Parameter in the OPEN message. Capabilities allow peers to determine whether both sides support functions needed for the session or address family.

Examples of capabilities encountered in modern BGP include:

  • multiprotocol AFI/SAFI support;
  • route refresh;
  • four-octet ASN support;
  • graceful restart;
  • Add-Path.

A capability being supported locally is not automatically enough. Many capabilities are usable only when appropriately advertised/negotiated with the peer.

Troubleshooting OPEN

If TCP succeeds but the session resets during OPEN processing, inspect:

show ip bgp neighbors <peer>
show logging

and, in a lab or approved capture environment, decode the OPEN and any subsequent NOTIFICATION.

4. KEEPALIVE — confirm and maintain the session

KEEPALIVE is intentionally small. It carries only the common BGP header and no additional data payload.

Its roles include:

  • confirming progression through session establishment after OPEN processing;
  • preventing the negotiated Hold Timer from expiring when no other BGP messages are being exchanged.

A network can therefore have an Established BGP session with ongoing KEEPALIVE traffic even when there are no route changes.

Important distinction:

> KEEPALIVE maintains session liveness; it does not mean a useful prefix is present or forwarding.

5. UPDATE — advertise and withdraw reachability

UPDATE is where BGP carries routing changes.

A base IPv4-unicast UPDATE can contain, conceptually:

  • withdrawn routes;
  • path attributes;
  • NLRI for newly advertised/re-advertised prefixes.

Modern multiprotocol BGP uses attributes such as MP_REACH_NLRI and MP_UNREACH_NLRI to carry reachability for additional address families. Those mechanisms receive dedicated coverage later.

Path attributes

UPDATE messages carry attributes that can include:

  • ORIGIN;
  • AS_PATH;
  • NEXT_HOP;
  • MED;
  • LOCAL_PREF where appropriate within the relevant scope;
  • communities and many extensions.

The series will later separate each important attribute into its own operational treatment.

Withdrawals

When reachability is no longer valid, BGP can withdraw the route. A withdrawal is not a session failure. It is normal control-plane behavior.

This distinction matters during incidents: “the prefix disappeared” could be caused by a valid UPDATE withdrawal while the session remains perfectly Established.

6. NOTIFICATION — report a fatal session/protocol error

A NOTIFICATION communicates an error condition and is associated with terminating the BGP connection under the applicable protocol rules.

The message contains an error code, error subcode and optional data relevant to the error.

Examples of categories include:

  • message header errors;
  • OPEN message errors;
  • UPDATE message errors;
  • hold timer expiry;
  • finite-state machine errors;
  • cease conditions.

Operators should preserve the received/sent NOTIFICATION information before repeatedly resetting the session. It may be the strongest evidence of the actual fault.

Modern UPDATE error handling

RFC 7606 revises error handling for malformed UPDATE messages to reduce cases where a single bad route causes excessive session reset and collateral loss of all routes from the peer. Depending on the specific error, approaches such as treating affected routes as withdrawn or discarding an attribute can be used instead of always resetting the session.

The exact behavior depends on the error type and implementation support. Do not generalize “malformed UPDATE never resets BGP”; that would be incorrect.

7. ROUTE-REFRESH — ask the peer to re-advertise

RFC 2918 defines the Route Refresh Capability and a ROUTE-REFRESH message.

The operational use case is important: an operator changes inbound policy and wants the peer to re-advertise routes so the new policy can be applied, without necessarily tearing down the BGP session.

Route refresh is therefore closely tied to safe policy operations and soft re-evaluation.

Later posts will compare:

  • route refresh;
  • inbound soft reconfiguration;
  • soft reset;
  • hard reset;
  • and the memory/operational trade-offs of each approach.

8. Message lifecycle during normal establishment



BGP Message Types: OPEN, UPDATE, KEEPALIVE, NOTIFICATION and ROUTE-REFRESH
BGP Message Types: OPEN, UPDATE, KEEPALIVE, NOTIFICATION and ROUTE-REFRESH


A simplified successful sequence is:

TCP three-way handshake
        |
        v
OPEN <-------------> OPEN
        |
        v
KEEPALIVE <-------> KEEPALIVE
        |
        v
      Established
        |
        +---- UPDATE advertisements/withdrawals
        |
        +---- KEEPALIVE when needed for liveness
        |
        +---- ROUTE-REFRESH when negotiated/requested

A NOTIFICATION may interrupt the sequence when a relevant protocol/session error occurs.

This diagram is intentionally simplified. Simultaneous connection attempts, implementation timing, multiple UPDATEs and other details can make real captures more complex.

9. Scenario — RETICUX Lab FND-006

Two eBGP routers establish normally. The lab then changes a route origination so the operator can observe message counters and, where an authorized packet capture is available, compare the normal OPEN/KEEPALIVE sequence with an UPDATE withdrawal.

Topology

192.0.2.0/24                                  198.51.100.0/24
    |                                                |
+--------+        203.0.113.0/30                +--------+
| EDGE-A |--------------------------------------| EDGE-B |
|AS64512 |                 eBGP                 |AS64513 |
+--------+                                      +--------+


RETICUX Lab FND-006
RETICUX Lab FND-006


Lab objective

  • Establish the session.
  • Inspect neighbor capabilities and message counters.
  • Remove one originated route without dropping the session.
  • Verify the peer processes a route withdrawal while BGP remains Established.

10. Baseline configuration

EDGE-A

hostname EDGE-A
!
interface GigabitEthernet0/0
 ip address 203.0.113.1 255.255.255.252
 no shutdown
!
interface Loopback10
 ip address 192.0.2.1 255.255.255.0
!
router bgp 64512
 bgp log-neighbor-changes
 neighbor 203.0.113.2 remote-as 64513
 address-family ipv4
  network 192.0.2.0 mask 255.255.255.0
  neighbor 203.0.113.2 activate
 exit-address-family

EDGE-B

hostname EDGE-B
!
interface GigabitEthernet0/0
 ip address 203.0.113.2 255.255.255.252
 no shutdown
!
interface Loopback10
 ip address 198.51.100.1 255.255.255.0
!
router bgp 64513
 bgp log-neighbor-changes
 neighbor 203.0.113.1 remote-as 64512
 address-family ipv4
  network 198.51.100.0 mask 255.255.255.0
  neighbor 203.0.113.1 activate
 exit-address-family

11. Verification before modification

Neighbor capabilities and message statistics

On EDGE-A:

show ip bgp neighbors 203.0.113.2

Inspect fields for:

  • BGP version;
  • state Established;
  • negotiated/advertised capabilities;
  • hold/keepalive information;
  • message statistics including OPEN, KEEPALIVE, UPDATE and NOTIFICATION counters where displayed.

Do not treat the example counter values in vendor documentation as expected exact values for this lab. Counts depend on session history and timing.

Route state

show ip bgp 198.51.100.0 255.255.255.0
show ip route 198.51.100.0 255.255.255.0

Optional packet capture

If the virtual platform permits an authorized capture, capture only the lab link and filter for TCP port 179/BGP. A useful capture should show:

  • TCP setup;
  • OPEN from both directions;
  • KEEPALIVE exchange;
  • UPDATE messages;
  • later withdrawal activity.

No packet capture in this article is represented as actually executed; the post remains LAB VALIDATION RECOMMENDED.

12. Controlled modification — withdraw a route without dropping the session

On EDGE-A:

configure terminal
interface Loopback10
 shutdown
end

Expected control-plane result

The local route 192.0.2.0/24 disappears, so the BGP origin is withdrawn. EDGE-A should communicate the loss of reachability to EDGE-B through UPDATE processing while the BGP session itself can remain Established.

Verify on EDGE-B

show ip bgp summary
show ip bgp 192.0.2.0 255.255.255.0
show ip route 192.0.2.0 255.255.255.0
show ip bgp neighbors 203.0.113.1

Expected evidence:

  • session still Established;
  • route no longer present after withdrawal processing;
  • UPDATE/message counters may increment.

This is the operational difference between route failure and session failure.

13. Fault injection

Illustrative lab — not a real incident.

Lab name

FND-006-PREFIX-WITHDRAWN-SESSION-UP

Fault

The source route for 192.0.2.0/24 is removed by shutting Loopback10 on EDGE-A.

Symptoms

  • BGP session stays Established.
  • One prefix disappears from EDGE-B.
  • Other BGP reachability can remain intact.
  • No NOTIFICATION is required because this is a normal reachability change, not necessarily a protocol error.

Why this fault matters

NOC dashboards often overemphasize neighbor up/down state. Prefix monitoring is equally important because a business-critical route can disappear without the peer resetting.

14. Troubleshooting sequence

``text show ip bgp summary ``

``text show ip route 192.0.2.0 255.255.255.0 ``

``text show ip bgp 192.0.2.0 255.255.255.0 ``

``text show ip bgp neighbors 203.0.113.2 advertised-routes ``

  1. Check whether the neighbor is Established.
  2. Check whether the target prefix exists locally on the originator.
  3. Check local BGP origination.
  4. Check advertised routes.
  5. On the receiver, check whether the route is present in BGP and RIB.
  6. Inspect neighbor message counters for evidence of UPDATE activity.
  7. Use packet capture only if CLI evidence is insufficient or packet-level learning is the objective.
  8. Restore the route source; do not reset the whole BGP session for a normal withdrawal.

15. Root cause and correction

Root cause

The route source disappeared on EDGE-A. BGP correctly withdrew the prefix through UPDATE processing while preserving the session.

Correction

configure terminal
interface Loopback10
 no shutdown
end

After the connected route returns, BGP can advertise the prefix again.

16. Post-fix verification

On EDGE-A:

show ip route 192.0.2.0 255.255.255.0
show ip bgp 192.0.2.0 255.255.255.0
show ip bgp neighbors 203.0.113.2 advertised-routes

On EDGE-B:

show ip bgp summary
show ip bgp 192.0.2.0 255.255.255.0
show ip route 192.0.2.0 255.255.255.0

Then perform an appropriate forwarding test with a source that has a return route.

17. Route refresh operational preview

The lab above demonstrates UPDATE withdrawal and re-advertisement. A separate later lab will change an inbound policy and use route refresh/soft mechanisms to request re-advertisement without a destructive hard reset.

For now, verify capability information using:

show ip bgp neighbors <peer>

and identify whether route-refresh capability is advertised/received on the selected platform.

Do not assume a capability is negotiated merely because the software family supports it generally; verify the actual neighbor session.

18. Rollback

Restore the loopback:

configure terminal
interface Loopback10
 no shutdown
end

Preserve before/after:

show ip bgp summary
show ip bgp neighbors
show ip bgp
show ip route
show logging

If packet capture was used, store the capture with timestamps and topology metadata so it can be correlated with CLI evidence.

19. Production lessons

Protocol lesson

OPEN negotiates, KEEPALIVE maintains, UPDATE changes reachability, NOTIFICATION reports defined error conditions, and ROUTE-REFRESH requests re-advertisement when the capability is available.

Troubleshooting lesson

A missing route does not imply a failed session. Determine whether the event was a withdrawal, policy rejection, best-path change or transport reset.

Observability lesson

Monitor message activity, prefix counts and route changes—not only peer state.

Error-handling lesson

Modern BGP error handling is more nuanced than “bad UPDATE always resets the session.” RFC 7606 defines revised handling for several malformed UPDATE conditions.

Change-management lesson

Use non-destructive refresh/re-evaluation mechanisms where appropriate rather than habitually hard-resetting peers after policy changes.

20. Knowledge check

Q1

Which BGP message carries new reachability and withdrawals?

Answer: UPDATE.

Q2

TCP is established, but the peer rejects session parameters and sends an error before Established. Which messages are most relevant to inspect?

Answer: The OPEN exchange and the resulting NOTIFICATION, along with its error code/subcode and data.

Q3

Why is route refresh operationally valuable?

Answer: It can request re-advertisement of routes so updated inbound policy can be applied without necessarily tearing down the BGP session, provided the capability is supported/negotiated.

21. Sources

  1. RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)*.
  2. RFC 5492 — *Capabilities Advertisement with BGP-4*.
  3. RFC 2918 — *Route Refresh Capability for BGP-4*.
  4. RFC 7606 — *Revised Error Handling for BGP UPDATE Messages*.
  5. Cisco — *BGP Command Reference: show ip bgp neighbors*.
  6. Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x*.

Accessed: 2026-08-11.

Labels:

Featured Post

Day 41 — BGP Confederations: Sub-AS Design, External View and Migration

1. Opening Confederations are another way to scale BGP inside a large administrative domain. They divide the domain into member autonomous systems while presenting a single confederation identifier to external peers. They are powerful, but their operational model is more complex than simply 'using private ASNs inside.' The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture . 2. Concept and standards behavior RFC 5065 defines AS_CONFED_SEQUENCE and AS_CONFED_SET and how member-AS relationships are represented. Confederation external sessions have eBGP-like properties inside the confederation, while the confederation is presented externally as one AS. Modern guidance must also account for the fact that RFC 9774 prohibits new origination of AS_SET/AS_CONFED_SET in ordinary aggregation c...