BGP Messages

What Are BGP Messages?

BGP peers exchange messages over a TCP session on port 179. Every message begins with a common 19-byte header whose Type field identifies the message. RFC 4271 defines four types; ROUTE-REFRESH (RFC 2918) is an extension. This article explains the structure of each and confirms the contents in a capture from IOS XR (XRd) (for the basics, see BGP (Border Gateway Protocol)).

Type	Message	Role
1	OPEN	Sent first after the session is established; conveys the AS number, Hold Time, and supported capabilities.
2	UPDATE	Advertises and withdraws routes.
3	NOTIFICATION	Reports an error and tears down the session.
4	KEEPALIVE	Sent periodically to maintain the session.
5	ROUTE-REFRESH	Asks a peer to resend its routes without tearing down the session (RFC 2918).

Common Header

Field	Size	Description
Marker	16 bytes	All bits are set to `1`. RFC 4271 keeps this field for compatibility; if the value is not as expected, the receiver treats it as a synchronization error and returns Message Header Error (Error code 1) with subcode 1, Connection Not Synchronized.
Length	2 bytes	The total length of the message in bytes, including the header. Minimum 19 (KEEPALIVE), maximum 4096.
Type	1 byte	The message type (1 to 5).

The 4096 maximum is the value in RFC 4271. On a session where both sides exchange the BGP Extended Message capability (code 6, RFC 8654), every message except OPEN and KEEPALIVE may be up to 65535 bytes.

OPEN Message

Once the TCP session is established, both sides first send an OPEN message. If a peer can accept the other’s OPEN, it replies with a KEEPALIVE and the session becomes Established.

Field	Size	Description
Version	1 byte	The BGP version, currently `4`.
My Autonomous System	2 bytes	The sender’s AS number. When a 4-byte AS number that does not fit in two bytes is used, `23456` (AS_TRANS) goes here and the real number is conveyed in a capability.
Hold Time	2 bytes	If neither a KEEPALIVE nor an UPDATE is received within this time (seconds), the session is torn down. The smaller of the two proposed values is used. The value must be either `0` or at least three seconds, and `0` means no KEEPALIVEs are sent. The Cisco default is `180`.
BGP Identifier	4 bytes	The sender’s BGP Router ID.
Opt Parm Len	1 byte	The length of the Optional Parameters in bytes.
Optional Parameters	variable	Lists the supported capabilities.

The Optional Parameters list the router’s supported features as capabilities (RFC 5492). Common ones are shown below.

Capability	Code	Description
Multiprotocol Extensions	1	The address families (AFI / SAFI) the router can handle. IPv4 unicast is AFI 1 / SAFI 1.
Route Refresh	2	Allows requesting that a peer resend its routes without a reset.
Route Refresh (Cisco proprietary)	128	Used before RFC 2918 standardized the capability. IOS XR advertises both 2 and 128, which `show bgp neighbor` reports as `advertised (old + new)`.
Enhanced Route Refresh	70	Lets a speaker mark the beginning (BoRR) and end (EoRR) of a route refresh (RFC 7313).
Extended Next Hop Encoding	5	Allows an IPv6 address as the next hop of IPv4 routes.
4-octet AS Number	65	Indicates support for 4-byte AS numbers and conveys the router’s real AS number.

UPDATE Message

An UPDATE carries routing information. One UPDATE can carry both routes to withdraw (Withdrawn Routes) and routes (NLRI) that share one set of path attributes.

Field	Size	Description
Withdrawn Routes Length	2 bytes	The length of the Withdrawn Routes in bytes.
Withdrawn Routes	variable	The list of prefixes being withdrawn.
Total Path Attribute Length	2 bytes	The length of the Path Attributes in bytes.
Path Attributes	variable	The path attributes shared by the NLRI that follows (`ORIGIN`, `AS_PATH`, `NEXT_HOP`, and so on).
NLRI	variable	The list of prefixes being advertised (Network Layer Reachability Information).

The types and roles of path attributes are covered in BGP Path Attributes and Best Path Selection.

Advertising and Withdrawing Routes

Purpose	Withdrawn Routes	Path Attributes / NLRI
Advertising a route	empty	contains the prefixes being advertised and their path attributes
Withdrawing a route	contains the prefixes being withdrawn	empty

When an advertised route becomes unusable, the router sends an UPDATE with it in the Withdrawn Routes. No path attributes are needed, so Total Path Attribute Length is 0. The receiver removes the route from its BGP table and passes the withdrawal to its own peers, so it propagates across ASes.

An UPDATE with neither Path Attributes nor NLRI (Length = 23) is the End-of-RIB marker, which says that the initial advertisement after session establishment is complete (RFC 4724).

KEEPALIVE Message

A KEEPALIVE is the common header alone, 19 bytes. It is sent every third of the Hold Time (60 seconds with the Cisco defaults), and a peer that receives nothing within the Hold Time tears the session down. It also signals acceptance of the peer’s OPEN.

NOTIFICATION Message

A NOTIFICATION is sent when an error is detected, and the TCP session is closed afterwards.

Error code	Meaning	Typical subcodes
1	Message Header Error	Connection not synchronized, bad message length, bad message type
2	OPEN Message Error	Unsupported version, bad peer AS, bad BGP Identifier, unacceptable Hold Time
3	UPDATE Message Error	Malformed attribute list, missing well-known attribute, invalid `NEXT_HOP`, malformed `AS_PATH`, and so on
4	Hold Timer Expired	Nothing was received within the Hold Time
5	Finite State Machine Error	A message was received that is not allowed in the current state
6	Cease	Teardown for any other reason, such as an administrative `shutdown` or reset, or exceeding the maximum prefix count (RFC 4486)

ROUTE-REFRESH Message

A ROUTE-REFRESH asks a peer to resend its routes without tearing down the session. It is used after changing an inbound policy, to re-apply it to routes already received, and works between peers that exchanged the Route Refresh Capability (code 2) in their OPENs. Only an AFI / SAFI follows the common header.

Field	Size	Description
AFI	2 bytes	Address family. IPv4 is `1`.
Subtype (Reserved)	1 byte	Reserved in RFC 2918. RFC 7313 (Enhanced Route Refresh) redefines it as the Message Subtype: `0` for a normal request, `1` for the beginning of a route refresh (BoRR) and `2` for its end (EoRR).
SAFI	1 byte	Subsequent address family. Unicast is `1`.

The peer that receives the request resends every route it advertises to that peer.

Verification on Real Devices

Four XRd routers sit in three ASes: R1 - R2 is iBGP, while R2 - R3 and R3 - R4 are eBGP. Each router advertises 192.168.N.0/24.

The capture was taken on the R2 - R3 link, plus the R3 - R4 link for the steps where a route crosses two ASes. Each eBGP neighbor has its own outbound route policy name (all of them contain only pass). Applying one policy name to several neighbors puts them in a single update group, and a route learned from one peer is then advertised back to that same peer.

STEP	Action	What it shows
0	Initial state	All sessions are `Established`
1	`clear bgp 10.2.3.3` on R2	NOTIFICATION / OPEN / KEEPALIVE / UPDATE / End-of-RIB
2	`shutdown` on R4’s `interface Loopback1`	The withdrawal of `192.168.4.0/24` crossing two ASes, and traffic stopping
3	`no shutdown` on R4’s `interface Loopback1`	Re-advertisement and restored reachability
4	Add `Loopback11`-`Loopback15` on R4 and advertise five prefixes	Several NLRI inside one UPDATE
5	Remove the five prefixes from R4 at once	Several prefixes inside one UPDATE’s Withdrawn Routes
6	`clear bgp ipv4 unicast 10.2.3.3 soft` on R2	With `soft-reconfiguration inbound always`, no ROUTE-REFRESH is sent inbound
7	Remove `soft-reconfiguration inbound always` on R2, then `soft in`	A ROUTE-REFRESH is sent
8	Put `soft-reconfiguration inbound always` back on R2	The configuration change itself triggers a ROUTE-REFRESH
9	`shutdown` R3’s neighbor toward R2	The NOTIFICATION subcode differs from the `clear` case
10	`no shutdown` R3’s neighbor toward R2	The session restarts from OPEN
11	`timers 30 90` on R3’s neighbor toward R2, then `clear bgp`	Hold Time negotiation
12	Remove `timers 30 90` from R3 (final state)	Back to `180` seconds, and the KEEPALIVE interval with it

Establishing the Session (STEP 1)

These are the packets from clear bgp to re-establishment. Four of the five message types appear here; only ROUTE-REFRESH is missing.

R2 - R3 packet capture (STEP 1, tshark listing, ACK-only TCP lines omitted)
 0.000000     10.2.3.2 → 10.2.3.3     BGP 75 NOTIFICATION Message
 0.000202     10.2.3.2 → 10.2.3.3     TCP 54 179 → 40551 [FIN, ACK] Seq=22 Ack=1 Win=32134 Len=0
 0.012856     10.2.3.3 → 10.2.3.2     TCP 54 40551 → 179 [FIN, ACK] Seq=1 Ack=23 Win=32042 Len=0
 1.126688     10.2.3.2 → 10.2.3.3     TCP 62 47528 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=1
 1.130646     10.2.3.3 → 10.2.3.2     TCP 62 179 → 47528 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=1
 1.134115     10.2.3.2 → 10.2.3.3     BGP 129 OPEN Message
 1.219856     10.2.3.3 → 10.2.3.2     TCP 54 179 → 47528 [RST, ACK] Seq=1 Ack=1 Win=16384 Len=0
30.000850     10.2.3.2 → 10.2.3.3     TCP 54 179 → 40551 [RST, ACK] Seq=23 Ack=2 Win=32134 Len=0
32.938376     10.2.3.3 → 10.2.3.2     TCP 62 30318 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
32.941808     10.2.3.2 → 10.2.3.3     TCP 62 179 → 30318 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1240 WS=1
32.946208     10.2.3.3 → 10.2.3.2     BGP 129 OPEN Message
34.952104     10.2.3.2 → 10.2.3.3     BGP 129 OPEN Message
34.956468     10.2.3.3 → 10.2.3.2     BGP 73 KEEPALIVE Message
34.959407     10.2.3.2 → 10.2.3.3     BGP 73 KEEPALIVE Message
34.993300     10.2.3.3 → 10.2.3.2     BGP 194 UPDATE Message, UPDATE Message, UPDATE Message
34.995936     10.2.3.2 → 10.2.3.3     BGP 190 UPDATE Message, UPDATE Message, UPDATE Message
94.989534     10.2.3.2 → 10.2.3.3     BGP 73 KEEPALIVE Message
94.993812     10.2.3.3 → 10.2.3.2     BGP 73 KEEPALIVE Message

No.	What happens
1-4	R2 sends a NOTIFICATION and closes the TCP session
6-10	R2 retries immediately, but R3 refuses with an RST right after the reset
12-15	About 32 seconds later R3’s TCP handshake succeeds and R3 sends its OPEN
18-20	R2 returns its OPEN, both send a KEEPALIVE, and the session reaches `Established`
21-22	Both advertise their routes; the third UPDATE is the End-of-RIB marker for the initial advertisement
77 onward	KEEPALIVEs flow every 60 seconds

R3 sends R2 only two routes here, 192.168.3.0/24 and 192.168.4.0/24. The 192.168.1.0/24 and 192.168.2.0/24 it learned from R2 are not sent back to R2.

Inside the OPEN Message

The OPEN R3 sent as No.15: Type 1, Version 4, AS number 65002, Hold Time 180 seconds, BGP Identifier 10.0.0.3, and five capabilities in the Optional Parameters.

No.15 OPEN (R3 to R2), tshark -V
Border Gateway Protocol - OPEN Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 75
    Type: OPEN Message (1)
    Version: 4
    My AS: 65002
    Hold Time: 180
    BGP Identifier: 10.0.0.3
    Optional Parameters Length: 46
    Optional Parameters
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 6
            Capability: Multiprotocol extensions capability
                Type: Multiprotocol extensions capability (1)
                Length: 4
                AFI: IPv4 (1)
                Reserved: 00
                SAFI: Unicast (1)
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 2
            Capability: Route Refresh Capability (Cisco)
                Type: Route Refresh Capability (Cisco) (128)
                Length: 0
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 2
            Capability: Route refresh capability
                Type: Route refresh capability (2)
                Length: 0
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 6
            Capability: Support for 4-octet AS number capability
                Type: Support for 4-octet AS number capability (65)
                Length: 4
                AS Number: 65002
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 20
            Capability: Extended Next Hop Encoding
                Type: Extended Next Hop Encoding (5)
                Length: 18
<snip>

Download the pcap of the packet in the tshark output above (No.15 OPEN)

Route Refresh appears twice, as 128 and as 2, because the router advertises both the pre-standard Cisco code and the standard one; show bgp neighbor reports this as advertised (old + new). Enhanced Route Refresh (70) and BGP Extended Message (6) were not advertised by XRd 26.1.1.

Inside the KEEPALIVE Message

No.19 is the KEEPALIVE R3 sent when it accepted the OPEN: the common header alone, 19 bytes.

No.19 KEEPALIVE (R3 to R2), tshark -V
Border Gateway Protocol - KEEPALIVE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 19
    Type: KEEPALIVE Message (4)

Download the pcap of the packet in the tshark output above (No.19 KEEPALIVE)

Inside the UPDATE Message (Advertising a Route)

The TCP segment of No.21 carries three UPDATEs. The first one is R3’s own 192.168.3.0/24, with ORIGIN, AS_PATH and MULTI_EXIT_DISC.

No.21 UPDATE (R3 to R2, first one), tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 60
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 37
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.2.3.3
                IPv4 Address: 10.2.3.3
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.3.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.3.0
        Path Attribute - ORIGIN: IGP
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65002 
<snip>
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 65002
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 65002
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0

Download the pcap of the packet in the tshark output above (No.21, three UPDATEs)

Even for IPv4 unicast routes, XRd puts the prefix and the next hop in the MP_REACH_NLRI attribute (RFC 4760) rather than in the UPDATE’s own NLRI field. In the base form of RFC 4271 the next hop is the NEXT_HOP attribute and the prefix goes in the NLRI field.

The second UPDATE forwards 192.168.4.0/24, learned from R4, with R3’s own AS prepended. The third is the 23-byte End-of-RIB marker with no attributes and no NLRI.

No.21 UPDATE (R3 to R2, third one = End-of-RIB), tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 23
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 0

Several Routes in One UPDATE (STEP 4 and 5)

STEP 4 adds Loopback11 to Loopback15 (192.168.40.0/24 to 192.168.44.0/24) on R4 and advertises all five at once. Only one UPDATE crosses the R3 - R4 link, and it carries five NLRI. The path attributes are common to all five routes, so there is only one set of them.

STEP 4 No.1 UPDATE (R4 to R3), tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 76
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 53
    Path attributes
        Path Attribute - MP_REACH_NLRI
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 29
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.3.4.4
                IPv4 Address: 10.3.4.4
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.44.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.44.0
                192.168.43.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.43.0
                192.168.42.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.42.0
                192.168.41.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.41.0
                192.168.40.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.40.0
        Path Attribute - ORIGIN: IGP
<snip>
        Path Attribute - AS_PATH: 65003 
<snip>
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>

Download the pcap of the packet in the tshark output above (STEP 4 No.1 UPDATE)

STEP 5 removes all five at once, and the withdrawal is also a single UPDATE. Withdrawn Routes Length is 20 (4 bytes x 5) and there are no path attributes.

STEP 5 No.3 UPDATE (R4 to R3, five routes withdrawn), tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 43
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 20
    Withdrawn Routes
        192.168.40.0/24
            Withdrawn route prefix length: 24
            Withdrawn prefix: 192.168.40.0
        192.168.41.0/24
            Withdrawn route prefix length: 24
            Withdrawn prefix: 192.168.41.0
        192.168.42.0/24
            Withdrawn route prefix length: 24
            Withdrawn prefix: 192.168.42.0
        192.168.43.0/24
            Withdrawn route prefix length: 24
            Withdrawn prefix: 192.168.43.0
        192.168.44.0/24
            Withdrawn route prefix length: 24
            Withdrawn prefix: 192.168.44.0
    Total Path Attribute Length: 0

Download the pcap of the packet in the tshark output above (STEP 5 No.3 UPDATE)

Withdrawing a Route and Its Effect on Forwarding (STEP 2 and 3)

Shutting down R4’s Loopback1 in STEP 2 makes 192.168.4.0/24 unavailable. The withdrawal propagates R4 to R3 to R2 to R1, and appears as No.1 of STEP 2 on the R2 - R3 link.

STEP 2 No.1 UPDATE (R3 to R2, withdrawing a route), tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 27
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 4
    Withdrawn Routes
        192.168.4.0/24
            Withdrawn route prefix length: 24
            Withdrawn prefix: 192.168.4.0
    Total Path Attribute Length: 0

Download the pcap of the packet in the tshark output above (STEP 2 No.1 UPDATE)

The prefix is gone from R2’s BGP table, and from R1 two ASes away as well.

R2 show bgp (STEP 2, after the withdrawal)
RP/0/RP0/CPU0:R2#show bgp
Sun Sep 20 13:46:28.839 UTC
<snip>
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    100      0 i
*> 192.168.2.0/24     0.0.0.0                  0         32768 i
*> 192.168.3.0/24     10.2.3.3                 0             0 65002 i

Processed 3 prefixes, 3 paths

R1 show bgp 192.168.4.0/24 (STEP 2, after the withdrawal)
RP/0/RP0/CPU0:R1#show bgp 192.168.4.0/24
Sun Sep 20 13:44:48.165 UTC
%% Network not in table

With the route gone, forwarding stops too. The ping taken in the same step from R1 loses every packet.

R1 ping 192.168.4.1 (STEP 2, after the withdrawal)
RP/0/RP0/CPU0:R1#ping 192.168.4.1 source 192.168.1.1 count 50 timeout 1
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.4.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)

Restoring Loopback1 in STEP 3 re-advertises the prefix, and R1’s routing table and reachability come back.

R1 show route bgp (STEP 3, after re-advertisement)
RP/0/RP0/CPU0:R1#show route bgp
Sun Sep 20 13:50:18.672 UTC

B    192.168.2.0/24 [200/0] via 10.0.0.2, 00:36:56
B    192.168.3.0/24 [200/0] via 10.2.3.3, 00:12:13
B    192.168.4.0/24 [200/0] via 10.2.3.3, 00:01:45

Inside the NOTIFICATION Message (STEP 1 and 9)

A NOTIFICATION carries the reason for the teardown as an error code and a subcode. Both cases below are Cease (6), but a re-establishment with clear bgp and a neighbor shutdown use different subcodes.

STEP 1 No.1 NOTIFICATION (R2 to R3), tshark -V
Border Gateway Protocol - NOTIFICATION Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 21
    Type: NOTIFICATION Message (3)
    Major error Code: Cease (6)
    Minor error Code (Cease): Administratively Reset (4)

STEP 9 No.1 NOTIFICATION (R3 to R2), tshark -V
Border Gateway Protocol - NOTIFICATION Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 21
    Type: NOTIFICATION Message (3)
    Major error Code: Cease (6)
    Minor error Code (Cease): Administratively Shutdown (2)

Download the pcap of the STEP 1 packet (No.1 NOTIFICATION)

Download the pcap of the STEP 9 packet (No.1 NOTIFICATION)

show bgp neighbor keeps a record on both the sending and the receiving side.

R2 show bgp neighbor (excerpt, STEP 1)
BGP neighbor is 10.2.3.3
  BGP state = Established, up for 00:02:02
  Received 37 messages, 0 notifications, 0 in queue
  Sent 39 messages, 1 notifications, 0 in queue
  Connections established 2; dropped 1
  Time since last notification sent to neighbor: 00:02:37
  Error Code: administrative reset

R3 show bgp neighbor (excerpt, STEP 1)
BGP neighbor is 10.2.3.2
  Received 38 messages, 1 notifications, 0 in queue
  Last reset 00:03:21, due to BGP Notification received: administrative reset
  Time since last notification received from neighbor: 00:03:21
  Error Code: administrative reset

R2 show bgp neighbor (excerpt, STEP 9)
BGP neighbor is 10.2.3.3
  BGP state = Active
  Received 80 messages, 1 notifications, 0 in queue
  Last reset 00:04:16, due to BGP Notification received: administrative shutdown

In STEP 9 the neighbor stays shut down on R3, so R2 sits in Active and keeps retrying. STEP 10 releases it and the session comes back from OPEN.

Inside the ROUTE-REFRESH Message (STEP 6 to 8)

On IOS XR, clear bgp <peer> soft in sends one. No.1 of STEP 7 is that message: 23 bytes, with AFI / Subtype / SAFI after the common header.

STEP 7 No.1 ROUTE-REFRESH (R2 to R3), tshark -V
Border Gateway Protocol - ROUTE-REFRESH Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 23
    Type: ROUTE-REFRESH Message (5)
    Address family identifier (AFI): IPv4 (1)
    Subtype: Normal route refresh request [RFC2918] with/without ORF [RFC5291] (0)
    Subsequent address family identifier (SAFI): Unicast (1)

Download the pcap of the packet in the tshark output above (STEP 7 No.1 ROUTE-REFRESH)

Whether one is sent depends on soft-reconfiguration inbound always. Comparing R2’s counters in show bgp neighbor across the three steps:

STEP	Configuration and action on R2	ROUTE-REFRESH in the capture	`Route refresh request: sent`
6	Configured. `clear bgp ipv4 unicast 10.2.3.3 soft`	0	0
7	Removed, then `clear bgp ipv4 unicast 10.2.3.3 soft in`	1	1
8	Put back (no `clear`)	1	2

With soft-reconfiguration inbound always, soft in sends no ROUTE-REFRESH (STEP 6). The router keeps a local copy of the routes as received before the inbound policy, so it can re-evaluate them on its own. show bgp neighbor shows this as Inbound soft reconfiguration allowed (override route-refresh).

Removing the configuration also disables received routes.

R2 show bgp neighbors 10.2.3.3 received routes (STEP 7, with the configuration removed)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.2.3.3 received routes
Sun Sep 20 14:10:26.738 UTC
% The 'show bgp neighbor received routes' command is only available when inbound soft reconfiguration is active.  To activate inbound soft reconfiguration, use the 'soft-reconfiguration inbound' command.  If the neighbor supports route-refresh, the 'always' option to the command must also be specified.

It is a trade-off between keeping a copy at all times, which makes received routes available, and asking for the routes with a ROUTE-REFRESH when needed. Note that putting the configuration back in STEP 8 did send a ROUTE-REFRESH, to line up the routes the router was not holding: the setting does not mean ROUTE-REFRESH is never sent.

Hold Time Negotiation (STEP 11 and 12)

Both sides propose a Hold Time in their OPEN, and the smaller value wins. STEP 11 sets only R3’s neighbor toward R2 to 90 seconds.

R3 Hold Time change (STEP 11)
router bgp 65002
 neighbor 10.2.3.2
  timers 30 90

Committing alone does not switch it over. Hold Time is exchanged in the OPEN, so it does not take effect until the session is re-established.

R3 right after the commit (STEP 11, before the clear)
RP/0/RP0/CPU0:R3#show bgp neighbor 10.2.3.2 | include Hold time
Sun Sep 20 14:29:10.928 UTC
  Hold time is 180, keepalive interval is 60 seconds

After clear bgp, R3 proposes 90 and R2 proposes 180, and both end up at 90 seconds. On R2, which was not reconfigured, Configured hold time stays at 180 while the effective Hold time becomes 90, and the KEEPALIVE interval follows at a third of it, 30 seconds.

R2 show bgp neighbor (excerpt, STEP 11)
BGP neighbor is 10.0.0.1
  Hold time is 180, keepalive interval is 60 seconds
  Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
BGP neighbor is 10.2.3.3
  Hold time is 90, keepalive interval is 30 seconds
  Configured hold time: 180, keepalive: 60, min acceptable hold time: 3

R3 show bgp neighbor (excerpt, STEP 11)
BGP neighbor is 10.2.3.2
  Hold time is 90, keepalive interval is 30 seconds
  Configured hold time: 90, keepalive: 30, min acceptable hold time: 3
BGP neighbor is 10.3.4.4
  Hold time is 180, keepalive interval is 60 seconds
  Configured hold time: 180, keepalive: 60, min acceptable hold time: 3

The negotiation is per session. R3’s neighbor toward R4 stays at 180, and R2’s iBGP session toward R1 is unaffected.

The proposed values are visible in the capture as well.

Download the pcap of the OPEN R3 sent (Hold Time 90)

Download the pcap of the OPEN R2 sent (Hold Time 180)

The KEEPALIVE interval changes with it. Capturing STEP 11 through STEP 12 in one file shows 30-second intervals while the Hold Time is 90, and 60-second intervals once STEP 12 puts it back to 180.

KEEPALIVE intervals from R2 to R3 (STEP 11 to 12, tshark listing)
   No.20      32.2s
   No.24      62.2s   interval 30.0s
   No.27      92.2s   interval 30.0s
   No.142    122.2s   interval 30.0s
   No.258    152.2s   interval 30.0s
   No.261    182.2s   interval 30.0s
   No.380    242.2s   interval 30.0s
   No.383    272.2s   interval 30.0s
   No.405    333.2s   interval 61.0s
   No.520    393.2s   interval 60.0s
   No.635    453.2s   interval 60.0s
   No.638    513.2s   interval 60.0s

Checking the Message Counters

show bgp neighbor reports the number of messages exchanged, the capabilities negotiated in the OPEN, and the Hold Time and KEEPALIVE interval. These are R2’s values in the final step.

R2 show bgp neighbor (excerpt, STEP 12)
BGP neighbor is 10.2.3.3
 Remote AS 65002, local AS 65001, external link
 Description: eBGP to R3
 Remote router ID 10.0.0.3
  BGP state = Established, up for 00:04:33
  Hold time is 180, keepalive interval is 60 seconds
  Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
<snip>
  Neighbor capabilities:
    Route refresh: advertised (old + new) and received (old + new)
    4-byte AS: advertised and received
    Address family IPv4 Unicast: advertised and received
  Received 110 messages, 3 notifications, 0 in queue
  Sent 108 messages, 1 notifications, 0 in queue

Note that IOS XR has no command that clears these message counters. What clear bgp offers is peer-drops (the established and dropped counts), performance-statistics and similar; the sent and received message counts only return to 0 when the session is reset.

Verification Config and Command Outputs

For every step, the following files were collected from all four routers, one per router. The verification config is the ..._run.txt file (the final state is the one from STEP 12).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` / `show bgp` / `show bgp summary` / `show bgp <prefix>` / `show bgp neighbors` / per-peer `advertised-routes`, `routes` and `received routes` / `show bgp update-group` / `show rpl route-policy`. R1 and R2 also include `show ospf neighbor`, as they run OSPF
`..._log.txt`	`show logging` limited to that step. A `logmsg` marker is written at the start of each step and its timestamp passed to `show logging start`
`..._run.txt`	`show running-config` at that step (that is, the verification config for the step)
`..._ping.txt`	The `ping` and `traceroute` of that step (50 packets from R1, R2 and R4 toward `192.168.4.1` or `192.168.1.1`)
`..._trace.txt`	`show bgp trace neighbor` and `show bgp trace error` (internal events of the BGP process)
`..._commit.cfg`	The configuration actually committed in that step (only for the router that was changed)
`..._exec.txt`	The `clear bgp` command run in that step, with its timestamp

The final state is the same as the initial one: R1 - R2 iBGP (Loopback0 peering, OSPF area 0), R2 - R3 and R3 - R4 eBGP, and each router advertising 192.168.N.0/24.

STEP 0: Initial state

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	—
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	—

STEP 1: clear bgp 10.2.3.3 on R2 (re-establishing the session)

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	exec
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	—

STEP 2: shutdown on R4’s interface Loopback1 (withdrawing a route)

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	—
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	commit

STEP 3: no shutdown on R4’s interface Loopback1 (re-advertising the route)

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	—
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	commit

STEP 4: Add Loopback11 to Loopback15 on R4 and advertise five prefixes

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	—
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	commit

STEP 5: Remove the five prefixes from R4 at once

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	—
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	commit

STEP 6: clear bgp ipv4 unicast 10.2.3.3 soft on R2

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	exec
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	—

STEP 7: Remove soft-reconfiguration inbound always on R2, then soft in

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	commit
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	—

STEP 8: Put soft-reconfiguration inbound always back on R2

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	commit
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	—

STEP 9: shutdown R3’s neighbor toward R2

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	—
R3	show	log	run	—	trace	commit
R4	show	log	run	ping	trace	—

STEP 10: no shutdown R3’s neighbor toward R2

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	—
R3	show	log	run	—	trace	commit
R4	show	log	run	ping	trace	—

STEP 11: timers 30 90 on R3’s neighbor toward R2, then clear bgp

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	—
R3	show	log	run	—	trace	commit
R4	show	log	run	ping	trace	—

STEP 12: Remove timers 30 90 from R3 (final state)

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	—
R3	show	log	run	—	trace	commit
R4	show	log	run	ping	trace	—

Packet captures were taken per step (a dash means no capture on that link). STEP 11 and STEP 12 share one file, so that the KEEPALIVE intervals before and after the Hold Time change can be compared.

STEP	R2 - R3	R3 - R4
0	pcap	—
1	pcap	—
2	pcap	pcap
3	pcap	pcap
4	pcap	pcap
5	pcap	pcap
6	pcap	—
7	pcap	—
8	pcap	—
9	pcap	—
10	pcap	—
11	included in STEP 12	—
12	pcap	—

References

Source	Title	Summary
IANA	Border Gateway Protocol (BGP) Parameters	The registry of numbers used by BGP: message types, path attributes, capability codes, NOTIFICATION error codes and subcodes, and more.
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	The base specification of BGP-4, defining the format of each message.
RFC 5492	Capabilities Advertisement with BGP-4	Defines the capabilities carried in the OPEN message.
RFC 4486	Subcodes for BGP Cease Notification Message	Defines the subcodes of the Cease NOTIFICATION.
RFC 2918	Route Refresh Capability for BGP-4	Defines the ROUTE-REFRESH message and its capability.
RFC 7313	Enhanced Route Refresh Capability for BGP-4	Redefines the Reserved field as the Message Subtype and adds BoRR / EoRR.
RFC 8654	Extended Message Support for BGP	Defines capability 6, which raises the maximum message length to 65535 bytes.
RFC 4724	Graceful Restart Mechanism for BGP	Defines the End-of-RIB marker.
RFC 4760	Multiprotocol Extensions for BGP-4	Defines the `MP_REACH_NLRI` / `MP_UNREACH_NLRI` attributes.