Is Enabling a New BGP Address Family Really Safe?

Introduction

Through a combination of industry discussions and hands-on experience gained from real-world projects, I was led to explore the topic introduced in this post. It is often assumed that enabling a specific address family between two neighbors, where a BGP session is already in the Established state, has no impact. But is this claim entirely correct? To answer this question, we first review a key component exchanged between the two neighbors during session establishment: the BGP capabilities.

Before diving into the content of this post, the topology used for the analysis is shown below. In this scenario, R1 and R2, belonging to two different Autonomous Systems, have established an external MP-BGP session using their Loopback 0 interfaces.

Below is the configuration of R1.

R1#show running-config | s r b
router bgp 65100
 bgp log-neighbor-changes
 neighbor 172.25.2.2 remote-as 65200
 neighbor 172.25.2.2 disable-connected-check
 neighbor 172.25.2.2 update-source Loopback0
 !
 address-family ipv4
  neighbor 172.25.2.2 activate
 exit-address-family

Below is the configuration of R2.

R2#show running-config | s r b
router bgp 65200
 bgp log-neighbor-changes
 neighbor 172.25.1.1 remote-as 65100
 neighbor 172.25.1.1 disable-connected-check
 neighbor 172.25.1.1 update-source Loopback0
 !
 address-family ipv4
  neighbor 172.25.1.1 activate
 exit-address-family

BGP Capabilities

Capabilities that are negotiated by BGP neighbors are exchanged during the establishment of the BGP session through the initial OPEN message sent between the two peers. Once these capabilities have been advertised, they are not re-advertised for the lifetime of the session. The only way to advertise them again is by performing a hard reset of the session, which forces the peers to repeat all the steps required to establish the BGP session.

Multiple attempts have been made, through various draft versions, to introduce a new type of BGP message that would allow capabilities to be exchanged dynamically, without requiring the BGP session to be reset and re-established. At the time of writing, the relevant document (draft-ietf-idr-dynamic-cap-17), also discussed in this post by Ivan Pepelnjak, is still in draft status and is set to expire on January 5, 2026.

By way of example, the following shows a BGP OPEN message (from R1 to R2) along with its associated attributes. Among these, classified as “Optional Parameters”, are the BGP capabilities. In particular, the example below highlights capability 131, named Prestandard Multisession (deprecated), which will be examined in greater detail in the following sections. The term deprecated indicates that this capability has been declared obsolete by RFC 8810.

Frame 11: 116 bytes on wire (928 bits), 116 bytes captured (928 bits)
Ethernet II, Src: 52:54:00:98:36:c5 (52:54:00:98:36:c5), Dst: 52:54:00:4a:1c:da (52:54:00:4a:1c:da)
Internet Protocol Version 4, Src: 172.25.1.1, Dst: 172.25.2.2
Transmission Control Protocol, Src Port: 32888, Dst Port: 179, Seq: 1, Ack: 1, Len: 62
Border Gateway Protocol - OPEN Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 62
    Type: OPEN Message (1)
    Version: 4
    My AS: 65100
    Hold Time: 180
    BGP Identifier: 172.25.1.1
    Optional Parameters Length: 33
    Optional Parameters
        Optional Parameter: Capability
        Optional Parameter: Capability
        Optional Parameter: Capability
        Optional Parameter: Capability
            Parameter Type: Capability (2)
            Parameter Length: 3
            Capability: Multisession (Cisco)
                Type: Multisession (Cisco) (131)
                Length: 1
                Flag: 0x00
        Optional Parameter: Capability
        Optional Parameter: Capability

These capabilities can be verified using the show ip bgp neighbors <remote-peer-IP> command. In the initial section of the output, there is a dedicated area named Neighbor capabilities that lists the capabilities exchanged between the neighbors. An example of this section is shown below. For each capability, the output indicates whether it is Advertised or Received. If a capability is included in the OPEN message sent to the remote peer, it is classified as Advertised. If it is included in the OPEN message received from the remote peer, it is classified as Received. When the capability is present in both OPEN messages, it is reported as Advertised and Received. It is also possible for a given capability to be neither Advertised nor Received. In this case, the capability is not associated with either keyword. In the example shown, the Multisession Capability is not negotiated between R1 and R2.

R1#show ip bgp neighbors 172.25.2.2 
BGP neighbor is 172.25.2.2,  remote AS 65200, external link
  BGP version 4, remote router ID 172.25.2.2
  BGP state = Established, up for 00:23:26
  Last read 00:00:30, last write 00:00:10, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability: 
    Stateful switchover support enabled: NO for session 1
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                2          1
    Keepalives:            28         27
    Route Refresh:          0          0
    Total:                 31         29
  Do log neighbor state changes (via global configuration)
  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  Session: 172.25.2.2
  BGP table version 2, neighbor version 2/0
  Output queue size : 0
  Index 24, Advertise bit 0
  24 update-group member
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               1          0
    Prefixes Total:                 1          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0
    Used as secondary:            n/a          0
          
                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 1, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: never
  Last Sent Refresh End-of-rib: never
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                       Sent       Rcvd
        Refresh activity:              ----       ----
          Refresh Start-of-RIB          0          0
          Refresh End-of-RIB            0          0

  Address tracking is enabled, the RIB does have a route to 172.25.2.2
  Route to peer address reachability Up: 1; Down: 0
    Last notification 6d22h
  Connections established 16; dropped 15
  Last reset 00:23:32, due to BGP Notification received of session 1, Administrative Reset
  External BGP neighbor not directly connected.
  External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
  Interface associated: (none) (peering address NOT in same link)
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
  SSO is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 172.25.1.1, Local port: 14764
Foreign host: 172.25.2.2, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x6124C783):
Timer          Starts    Wakeups            Next
Retrans            30          0             0x0
TimeWait            0          0             0x0
AckHold            29         25             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger          589        588      0x6124CAB1
DeadWait            0          0             0x0
Linger              0          0             0x0
ProcessQ            0          0             0x0

iss: 1198039233  snduna: 1198039900  sndnxt: 1198039900
irs:  530643033  rcvnxt:  530643627

sndwnd:  15718  scale:      0  maxrcvwnd:  16384
rcvwnd:  15791  scale:      0  delrcvwnd:    593

SRTT: 982 ms, RTTO: 1129 ms, RTV: 147 ms, KRTT: 0 ms
minRTT: 1 ms, maxRTT: 1000 ms, ACK hold: 200 ms
uptime: 1406699 ms, Sent idletime: 10076 ms, Receive idletime: 9874 ms 
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 59 (out of order: 0), with data: 29, total data bytes: 593
Sent: 58 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 30, total data bytes: 666
          
 Packets received in fast path: 0, fast processed: 0, slow path: 0
 fast lock acquisition failures: 0, slow path: 0
TCP Semaphore      0x7F193B70BE70  FREE

Unsupported BGP Capabilities

In some cases, particularly when interfacing devices from two different vendors, the set of supported capabilities may differ slightly. As a result, certain capabilities supported by Vendor A might not be supported by Vendor B. In these situations, the BGP session, whether iBGP or eBGP, does not successfully establish. For demonstration purposes, the previously introduced topology is used to emulate a scenario in which R2 lacks support for a capability advertised by R1. To reproduce this behavior, a configuration adjustment using a specific command was performed, which will be presented later starting from section Single-Session BGP. The packet exchange sequence observed during the BGP session establishment is shown below.

As soon as R1 receives the BGP OPEN message containing R2’s advertised capabilities, it detects the incompatibility. In accordance with the standard behavior, R1 then sends a BGP NOTIFICATION message, the content of which is shown below. The TCP session is subsequently terminated through the four-way handshake.

Frame 17: 75 bytes on wire (600 bits), 75 bytes captured (600 bits)
Ethernet II, Src: 52:54:00:98:36:c5 (52:54:00:98:36:c5), Dst: 52:54:00:4a:1c:da (52:54:00:4a:1c:da)
Internet Protocol Version 4, Src: 172.25.1.1, Dst: 172.25.2.2
Transmission Control Protocol, Src Port: 53939, Dst Port: 179, Seq: 63, Ack: 77, Len: 21
Border Gateway Protocol - NOTIFICATION Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 21
    Type: NOTIFICATION Message (3)
    Major error Code: OPEN Message Error (2)
    Minor error Code (Open Message): Unsupported Capability (7)

At the CLI level, the following log messages are displayed on the terminal to inform the administrator of this issue.

*Dec  29 11:17:07.583: %BGP-3-NOTIFICATION: sent to neighbor 172.25.2.2 passive 2/7 (unsupported/disjoint capability) 0 bytes 
*Dec  29 11:17:07.584: %BGP-4-MSGDUMP: unsupported or mal-formatted message received from 172.25.2.2: 
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0039 0104 FEB0 00B4 AC19 0202 1C02 0601 
0400 0100 0102 0280 0002 0202 0002 0246 0002 0641 0400 00FE B0
*Dec  29 11:17:12.462: %BGP-5-NBR_RESET: Neighbor 172.25.2.2 passive reset (BGP Notification sent)
*Dec  29 11:17:12.463: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 passive Down BGP Notification sent
*Dec  29 11:17:13.487: %BGP-5-NBR_RESET: Neighbor 172.25.2.2 active reset (BGP Notification sent)
*Dec  29 11:17:13.488: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 active Down BGP Notification sent
*Dec  29 11:17:13.488: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv4 Unicast topology base removed from session  BGP Notification sent

Non-Negotiated BGP Capabilities

In some specific scenarios, it may be useful to disable the exchange of BGP capabilities. Under the initial conditions described at the beginning of this post, this can be achieved by using the neighbor <remote-peer-IP> dont-capability-negotiate command in BGP configuration mode, which disables the capability exchange between the peers.

Frame 11: 83 bytes on wire (664 bits), 83 bytes captured (664 bits)
Ethernet II, Src: 52:54:00:98:36:c5 (52:54:00:98:36:c5), Dst: 52:54:00:4a:1c:da (52:54:00:4a:1c:da)
Internet Protocol Version 4, Src: 172.25.1.1, Dst: 172.25.2.2
Transmission Control Protocol, Src Port: 14816, Dst Port: 179, Seq: 1, Ack: 1, Len: 29
Border Gateway Protocol - OPEN Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 29
    Type: OPEN Message (1)
    Version: 4
    My AS: 65100
    Hold Time: 180
    BGP Identifier: 172.25.1.1
    Optional Parameters Length: 0

The Multisession BGP Concept

Returning to the core topic of this post: why do BGP capabilities matter? When a new address family is enabled for a neighbor under the AFI/SAFI configuration mode using the neighbor <remote-peer-IP> activate command, the device informs its remote peer of its ability to support that address family. This information is conveyed through BGP capabilities.

For completeness, in the scenario initially considered, the IPv6 Unicast address family has been enabled solely on R1 (after IPv6 routing was activated using the ipv6 unicast-routing command). As shown in the Neighbor Capabilities section, the IPv6 capability now appears, whereas it was absent in the previous output.

R1#show bgp neighbors 172.25.2.2 | section Neighbor capabilities
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Address family IPv4 Unicast: advertised and received
    Address family IPv6 Unicast: advertised
    Enhanced Refresh Capability: advertised and received
    Multisession Capability: 
    Stateful switchover support enabled: NO for session 1

Single-Session vs. Multi-Session

In order to advertise the capability associated with the IPv6 Unicast address family, a new exchange of BGP OPEN messages is required. This OPEN message exchange can be handled in two different ways, depending on an important characteristic of the established session: whether it is configured as a single-session or multi-session. These two session types are mutually exclusive and determine how BGP sessions are managed at the TCP level:

• In a single-session BGP setup, there is a single TCP session between the two peer IP addresses, which is used to exchange information for multiple address families.
• In a multi-session BGP setup, multiple TCP sessions can coexist between the same two IP addresses, with each session capable of carrying one address family.

To illustrate this concept, consider the following examples.

In the first scenario, representing a single-session BGP, there is a single TCP session (a single socket created between the two peer IPs) through which network announcements for multiple address families are exchanged via UPDATE messages

In the second scenario, representing multi-session BGP, three TCP sessions are established between the two peers, each associated with a different address family. For instance, IPv4 Unicast and IPv6 Unicast announcements are carried over separate TCP sessions.

This session-type characteristic is also negotiated through the BGP OPEN message by means of a specific capability, already introduced at the beginning of this post. This capability is identified by code 131 and is defined as Multisession (Cisco). This capability has a fundamental intrinsic property that can affect the successful establishment of the BGP session. Specifically, it must be advertised by both peers in order for the BGP session to be successfully created. In other words, it is not possible for one peer to attempt to establish a single-session BGP relationship while the other peer attempts to establish a multi-session one. The table below summarizes the points just discussed. If this condition is not met, the issue described in the Unsupported BGP Capabilities section will occur.

Single-Session BGP

Given the initial conditions outlined at the beginning of this post, this session mode is used by default. This can be verified by referring to the output of the show ip bgp neighbors 172.25.2.2 command previously examined on R1 in section BGP Capabilities.

R1#show ip bgp neighbors 172.25.2.2 
BGP neighbor is 172.25.2.2,  remote AS 65200, external link
  [OUPUT OMITTED]
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    [OUPUT OMITTED]
    Multisession Capability: 

The session is considered multisession not capable, and the capability is neither Advertised nor Received. For reference, if the BGP session is not already operating in single-session mode, it can be configured as such by using the neighbor <remote-peer-IP> transport single-session command within BGP configuration mode. Once this command is applied, the following message is displayed. In this specific case, the command was configured on R1 toward the peer R2.

*Dec  29 12:01:17.218:: %PARSER-5-HIDDEN: Warning!!! ' neighbor 172.25.2.2 transport single-session ' is a hidden command. Use of this command is not recommended/supported and will be removed in future.

This warning is also presented to the user through the contextual help, before the command is entered.

R1(config-router)#neighbor 172.25.2.2 transport ?
  connection-mode     Specify passive or active connection
  multi-session       Use Multi-session for transport
  path-mtu-discovery  Use transport path MTU discovery
  single-session      [DEPRECATED]Use only a single session for transport

If the BGP session is not currently single-session, applying this command will trigger a forced reset of the session. Additionally, once the command is applied, it will appear in the running configuration as well, as illustrated below using R1 as an example. It is important to note that this command does not appear by default and is only displayed when explicitly configured.

R1#show running-configuration | s r b
router bgp 65100
 bgp log-neighbor-changes
 neighbor 172.25.2.2 remote-as 65200
 neighbor 172.25.2.2 transport single-session
 neighbor 172.25.2.2 disable-connected-check
 neighbor 172.25.2.2 update-source Loopback0
 !
 address-family ipv4
  neighbor 172.25.2.2 activate
 exit-address-family

Let us now examine the impact of enabling a new address family between two peers that already have an established session for a different address family. In this example, the session has been established using the IPv4 Unicast AFI/SAFI, while the new address family to be enabled is IPv6 Unicast. Shown below is a truncated output illustrating the session state.

R1#show ip bgp neighbors 172.25.2.2
BGP neighbor is 172.25.2.2,  remote AS 65200, external link
  BGP version 4, remote router ID 172.25.2.2
  BGP state = Established, up for 00:01:17
  Last read 00:00:21, last write 00:00:19, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability: 
    Stateful switchover support enabled: NO for session 1
  [OUTPUT OMITTED]

The IPv6 Unicast address family is now enabled by applying the standard neighbor <remote-peer-IP> activate command on both R1 and R2.

R1(config)#router bgp 65100    
R1(config-router)#address-family ipv6 unicast 
R1(config-router-af)#neighb 172.25.2.2 activate

The same configuration is applied on R2 as well.

R2(config)#router bgp 65200    
R2(config-router)#address-family ipv6 unicast 
R2(config-router-af)#neighb 172.25.1.1 activate

The logs shown below immediately clarify what is occurring. Since the session is operating in single-session mode, all address families must be carried over a single TCP session. To accommodate the newly enabled address family, R1 performs a hard reset in order to renegotiate the capabilities through a new exchange of BGP OPEN messages. ** This behavior has a significant impact on the BGP neighborship between the two peers and, more broadly, can be disruptive to the logical topology of the network.**

*Dec 29 12:15:23.342: %BGP-5-NBR_RESET: Neighbor 172.25.2.2 reset (Capability changed)
*Dec 29 12:15:23.342: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Down Capability changed
*Dec 29 12:15:23.342: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv4 Unicast topology base removed from session  Capability changed
*Dec 29 12:15:23.569: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Up

For completeness, the following table shows the sequence of packets exchanged between the two peers after the new address family was enabled.

Rechecking the session status shows that:

• The IPv6 Unicast AFI/SAFI (2/1) has been successfully negotiated between the 2 peers.
• A single TCP session exists between the 2 peers.

R1#show ip bgp neighbors 172.25.2.2
BGP neighbor is 172.25.2.2,  remote AS 65200, external link
  [OUTPUT OMITTED]
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    [OUTPUT OMITTED]
    Address family IPv6 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability: 
    Stateful switchover support enabled: NO for session 1
  [OUTPUT OMITTED]

For further verification, the show tcp brief command can be used, which displays all TCP sessions managed by the device. As noted earlier, in this scenario, a single TCP session exists between the two peers.

R1#show tcp brief          
TCB       Local Address               Foreign Address             (state)
7F193DA754A0  172.25.1.1.14169           172.25.2.2.179              ESTAB

This information is also reflected in the output obtained when checking the BGP session status with the neighbor. The output of the command show ip bgp neighbors 172.25.2.2 | include port: is shown below.

R1#show ip bgp neighbors 172.25.2.2 | include port: 
Local host: 172.25.1.1, Local port: 14169
Foreign host: 172.25.2.2, Foreign port: 179

Multi-Session BGP

Let us now explore the second option for managing the activation of new address families, first disabling the previously enabled IPv6 Unicast address family from the prior section. As mentioned earlier, the multi-session characteristic of a BGP session is negotiated at session establishment via the capabilities included in the BGP OPEN messages. To enable this feature, the command neighbor <remote-peer-IP> transport multi-session can be used, which must be entered in BGP configuration mode. In this case, once the command is applied, no forced session reset occurs. This is because only a single AFI/SAFI is currently negotiated within the BGP session, namely IPv4 Unicast. In general, a forced reset is triggered when:

• At least two address families are negotiated within the current BGP session.
• The session is not already configured as multi-session.

Once configured, it will also be reflected in the running configuration, as shown below using R1 as an example.

router bgp 65100
 bgp log-neighbor-changes
 neighbor 172.25.2.2 remote-as 65200
 neighbor 172.25.2.2 transport multi-session
 neighbor 172.25.2.2 disable-connected-check
 neighbor 172.25.2.2 update-source Loopback0
 !
 address-family ipv4
  neighbor 172.25.2.2 activate
 exit-address-family

To clearly observe the effect of applying this command, the session must be reconfigured in single-session mode and an additional address family must be enabled (IPv6 in this case). The updated configuration serving as our new baseline is provided below. As an example, the revised configuration of R1 is shown.

R1#show running-config | s r b
router bgp 65100
 bgp log-neighbor-changes
 neighbor 172.25.2.2 remote-as 65200
 neighbor 172.25.2.2 transport single-session
 neighbor 172.25.2.2 disable-connected-check
 neighbor 172.25.2.2 update-source Loopback0
 !
 address-family ipv4
  neighbor 172.25.2.2 activate
 exit-address-family
 !
 address-family ipv6
  neighbor 172.25.2.2 activate
 exit-address-family

By now applying the command, and thus changing the session type, the following logs are generated.

*Dec 29 12:34:53.394: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Down Capability changed
*Dec 29 12:34:53.394: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv6 Unicast topology base removed from session  Capability changed
*Dec 29 12:34:53.394: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv4 Unicast topology base removed from session  Capability changed
*Dec 29 12:34:54.352: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Up 
*Dec 29 12:35:03.025: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 session 2 Up

A significant difference can be observed compared to the logs from the previous section. In this case, an additional log entry appears corresponding to the newly activated address family. As previously explained, the number of sessions now matches the number of address families, which in this example is 2. The ID used to indicate which session is up (Session <ID> Up) is assigned sequentially and can be verified using the standard command for checking session status. Below is the complete output, where substantial differences can be observed.

R1#sh ip bgp neighbors 172.25.2.2
BGP neighbor is 172.25.2.2,  remote AS 65200, external link
  BGP version 4, remote router ID 172.25.2.2
  Session state = Established, up for 00:45:46
  Last read 00:00:17, last write 00:00:17, hold time is 180, keepalive interval is 60 seconds
  BGP multisession with 2 sessions (2 established), first up for 00:45:46
  Neighbor sessions:
    2 active, is multisession capable
  Neighbor capabilities:
    Route refresh: advertised and received(new) on session 1, 2
    Four-octets ASN Capability: advertised and received on session 1, 2
    Address family IPv4 Unicast: advertised and received
    Address family IPv6 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability: advertised and received
    Stateful switchover support enabled: NO for session 1, 2
  Message statistics for 172.25.2.2 session 1, state Established:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                1          1
    Keepalives:            52         52
    Route Refresh:          0          0
    Total:                 54         54
  Message statistics for 172.25.2.2 session 2, state Established:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                1          1
    Keepalives:            52         52
    Route Refresh:          0          0
    Total:                 54         54
  Do log neighbor state changes (via global configuration)
  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  Session: 172.25.2.2 session 1
  BGP table version 1, neighbor version 1/0
  Output queue size : 0
  Index 68, Advertise bit 0
  session 1 member
  68 update-group member
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               0          0
    Prefixes Total:                 0          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0
    Used as secondary:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 1, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: never
  Last Sent Refresh End-of-rib: never
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                       Sent       Rcvd
        Refresh activity:              ----       ----
          Refresh Start-of-RIB          0          0
          Refresh End-of-RIB            0          0

 For address family: IPv6 Unicast
  Session: 172.25.2.2 session 2
  BGP table version 1, neighbor version 1/0
  Output queue size : 0
  Index 19, Advertise bit 0
  session 2 member
  19 update-group member
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               0          0
    Prefixes Total:                 0          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0
    Used as secondary:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 0, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: never
  Last Sent Refresh End-of-rib: never
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                                       Sent       Rcvd
        Refresh activity:              ----       ----
          Refresh Start-of-RIB          0          0
          Refresh End-of-RIB            0          0

  Address tracking is enabled, the RIB does have a route to 172.25.2.2
  Route to peer address reachability Up: 1; Down: 0
    Last notification 1w4d
  Connections established 72; dropped 70
  Last reset 00:45:47, due to Capability changed of session 1
  External BGP neighbor not directly connected.
  External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
  Interface associated: (none) (peering address NOT in same link)
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
  SSO is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 172.25.1.1, Local port: 30398
Foreign host: 172.25.2.2, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x78B20400):
Timer          Starts    Wakeups            Next
Retrans            54          0             0x0
TimeWait            0          0             0x0
AckHold            53         50             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger         1862       1861      0x78B206D3
DeadWait            0          0             0x0
Linger              0          0             0x0
ProcessQ            0          0             0x0

iss: 1325303835  snduna: 1325304909  sndnxt: 1325304909
irs:   13608430  rcvnxt:   13609504

sndwnd:  15311  scale:      0  maxrcvwnd:  16384
rcvwnd:  15311  scale:      0  delrcvwnd:   1073

SRTT: 999 ms, RTTO: 1006 ms, RTV: 7 ms, KRTT: 0 ms
minRTT: 1 ms, maxRTT: 1000 ms, ACK hold: 200 ms
uptime: 2746074 ms, Sent idletime: 17020 ms, Receive idletime: 17220 ms 
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 105 (out of order: 0), with data: 54, total data bytes: 1073
Sent: 108 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 54, total data bytes: 1073

 Packets received in fast path: 0, fast processed: 0, slow path: 0
 fast lock acquisition failures: 0, slow path: 0
TCP Semaphore      0x7F193B70BDA0  FREE

As reflected in the output, there are a total of 2 sessions, along with the Multisession capability, which is both Advertised and Received. The output also includes information regarding the session uptime. In scenarios with 2 or more sessions, this uptime refers, as the name implies, to the first session established between the two peer IP addresses.

BGP multisession with 2 sessions (2 established), first up for 00:45:46
Multisession Capability: advertised and received

Furthermore, each session corresponding to a specific address family is assigned a unique ID, which can then be referenced both in the various sections of the output and in the logs.

For address family: IPv4 Unicast
  Session: 172.25.2.2 session 1
For address family: IPv6 Unicast
  Session: 172.25.2.2 session 2

Finally, it is worth noting that the final section of the output provides information about a TCP session. These details again correspond to the first session established between the 2 peers.

Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 172.25.1.1, Local port: 30398
Foreign host: 172.25.2.2, Foreign port: 179

As with the Single-Session case, the TCP sockets can be verified, using R1 as an example. This output shows that 2 separate sockets have been created, corresponding to the 2 sessions over which the information for the 2 address families is exchanged.

R1#show tcp brief 
TCB       Local Address               Foreign Address             (state)
7F193DC21620  172.25.1.1.179             172.25.2.2.25444            ESTAB
7F193DBCB4E0  172.25.1.1.30398           172.25.2.2.179              ESTAB

A closer analysis of the message exchange following the activation of the Multi-Session Capability reveals the following:

• Packets #1 through #4 show the four-way handshake used to close the previous TCP session (single-session).
• Starting from packet #5, the three-way handshake for the new session begins, using TCP source port 30398. This confirms the previous observation that the TCP session information displayed via the command show ip bgp neighbors 172.25.2.2 corresponds to the first session established.
• Starting from packet #20, the creation of the second TCP session begins, corresponding to the second address family.

Enabling a New Address Family in Multi-Session BGP

Now that the functionality of Multi-Session BGP has been verified, it is important to examine the behavior when a new address family is enabled. In this scenario, the AFI/SAFI 1/128 (VPNv4 Unicast) is considered. On both R1 and R2, the standard command neighbor <remote-peer-IP> activate is applied. As a result, the CLI displays the following single log entry.

*Dec 29 12:48:52.192: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 session 3 Up 

In contrast to the previous scenarios, this activation did not result in any disruption to the pre-existing, active BGP sessions. It is noteworthy that the session ID has incremented sequentially. An examination of the TCP sockets on R1 confirms that three sessions are now in the ESTABLISHED state.

R1#show tcp brief 
TCB       Local Address               Foreign Address             (state)
7F193DC21620  172.25.1.1.179             172.25.2.2.25444            ESTAB
7F193DD26BE0  172.25.1.1.179             172.25.2.2.27539            ESTAB
7F193DBCB4E0  172.25.1.1.30398           172.25.2.2.179              ESTAB

Examining also the session status confirms that the addition has been successfully applied.

R1#show ip bgp neighbors 172.25.2.2
BGP neighbor is 172.25.2.2,  remote AS 65200, external link
  [OUTPUT OMITTED]
  BGP multisession with 3 sessions (3 established), first up for 00:59:24
  Neighbor sessions:
    3 active, is multisession capable
  Neighbor capabilities:
    Route refresh: advertised and received(new) on session 1, 2, 3
    Four-octets ASN Capability: advertised and received on session 1, 2, 3
    Address family IPv4 Unicast: advertised and received
    Address family IPv6 Unicast: advertised and received
    Address family VPNv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability: advertised and received
    Stateful switchover support enabled: NO for session 1, 2, 3
  [OUTPUT OMITTED]

As a final reference, the packet capture taken just before enabling the third address family between the 2 neighbors is shown below. Starting from packet #5, the standard three-way handshake begins, which subsequently establishes the third TCP and BGP session.

Final takeaway

After examining the differences between the two mechanisms, which one should be preferred?

From a dependency standpoint, Multi-Session BGP allows each address family to be managed independently. This independence, for instance, applies both when activating new address families and when performing hard resets using the command clear ip bgp <AFI> <SAFI> <ASN>.

From a scalability perspective, in scenarios where infrastructure expansion is expected, such as extending services to IPv6 or migrating a legacy L2VPN-based infrastructure toward more modern and scalable solutions like EVPN, Multi-Session BGP enables a more structured and controlled operational model.

For these reasons, it is advisable to establish Multi-Session BGP from the outset, rather than introducing it later during the lifecycle of the network infrastructure.

I hope this post has been helpful. If you have any additional information to share, feel free to reach out via social media. See you in the next one! 🙂