Is Enabling a New BGP Address Family Really Safe?
Introduction
This post was inspired by a recurring assumption in real-world BGP deployments: that enabling a new address family on an already-established BGP session is a harmless operation. But is it really? To explore this question, a key component exchanged between the two neighbors during session establishment is first reviewed: BGP capabilities. Understanding whether a specific capability is exchanged is essential to predict the behavior when a new address family is activated.
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 (AS 65100 and AS 65200 respectively), have established an external BGP session with IPv4 Unicast as the active address family, using their Loopback 0 interfaces.
The configuration of the two routers is shown below.
1R1#show running-config | s r b
2router bgp 65100
3 bgp log-neighbor-changes
4 neighbor 172.25.2.2 remote-as 65200
5 neighbor 172.25.2.2 disable-connected-check
6 neighbor 172.25.2.2 update-source Loopback0
7 !
8 address-family ipv4
9 neighbor 172.25.2.2 activate
10 exit-address-family1R2#show running-config | s r b
2router bgp 65200
3 bgp log-neighbor-changes
4 neighbor 172.25.1.1 remote-as 65100
5 neighbor 172.25.1.1 disable-connected-check
6 neighbor 172.25.1.1 update-source Loopback0
7 !
8 address-family ipv4
9 neighbor 172.25.1.1 activate
10 exit-address-familyBGP 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 are 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-19), also discussed in this post by Ivan Pepelnjak, is still in draft status and is set to expire on August 20, 2026. In brief, this draft introduces a new BGP message type, DYNAMIC CAPABILITY (DCAP), that enables capability revision on a live session in Established state, limited to capabilities that do not change the format of existing BGP messages. The mechanism is a two-way handshake: the Initiator sends a DCAP message to add or remove a capability; the Receiver validates it, applies the change, and sends back an acknowledgment; upon receiving the Ack, the Initiator also applies the revision. No session reset required.
As an example, the following shows an OPEN message from R1 to R2 along with its associated parameters. The relevant fields are discussed in detail throughout the post.
How can the exchange of these capabilities be verified via the CLI? These capabilities can be verified using the show bgp <AFI> <SAFI> neighbors <remote-peer-IP> command. In the initial section of the output, there is a dedicated section 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.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2
2BGP neighbor is 172.25.2.2, remote AS 65200, external link
3 BGP version 4, remote router ID 172.25.2.2
4 BGP state = Established, up for 00:02:06
5 Last read 00:00:10, last write 00:00:16, hold time is 180, keepalive interval is 60 seconds
6 Last update received: 00:02:06
7 Neighbor sessions:
8 1 active, is not multisession capable (disabled)
9 Neighbor capabilities:
10 Route refresh: advertised and received(new)
11 Four-octets ASN Capability: advertised and received
12 Address family IPv4 Unicast: advertised and received
13 Enhanced Refresh Capability: advertised and received
14 Multisession Capability:
15 Stateful switchover support enabled: NO for session 1
16 Message statistics:
17 InQ depth is 0
18 OutQ depth is 0
19
20 Sent Rcvd
21 Opens: 1 1
22 Notifications: 0 0
23 Updates: 1 1
24 Keepalives: 4 4
25 Route Refresh: 0 0
26 Total: 6 6
27 Do log neighbor state changes (via global configuration)
28 Default minimum time between advertisement runs is 30 seconds
29
30 For address family: IPv4 Unicast
31 Session: 172.25.2.2
32 BGP table version 1, neighbor version 1/0
33 Output queue size : 0
34 Index 3, Advertise bit 0
35 3 update-group member
36 Slow-peer detection is disabled
37 Slow-peer split-update-group dynamic is disabled
38 Sent Rcvd
39 Prefix activity: ---- ----
40 Prefixes Current: 0 0
41 Prefixes Total: 0 0
42 Implicit Withdraw: 0 0
43 Explicit Withdraw: 0 0
44 Used as bestpath: n/a 0
45 Used as multipath: n/a 0
46 Used as secondary: n/a 0
47
48 Outbound Inbound
49 Local Policy Denied Prefixes: -------- -------
50 Total: 0 0
51 Number of NLRIs in the update sent: max 0, min 0
52 Last detected as dynamic slow peer: never
53 Dynamic slow peer recovered: never
54 Refresh Epoch: 1
55 Last Sent Refresh Start-of-rib: never
56 Last Sent Refresh End-of-rib: never
57 Last Received Refresh Start-of-rib: never
58 Last Received Refresh End-of-rib: never
59 Sent Rcvd
60 Refresh activity: ---- ----
61 Refresh Start-of-RIB 0 0
62 Refresh End-of-RIB 0 0
63
64 Address tracking is enabled, the RIB does have a route to 172.25.2.2
65 Route to peer address reachability Up: 1; Down: 0
66 Last notification 00:46:03
67 Connections established 3; dropped 2
68 Last reset 00:11:36, due to Active open failed
69 External BGP neighbor not directly connected.
70 External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
71 Interface associated: (none) (peering address NOT in same link)
72 Transport(tcp) path-mtu-discovery is enabled
73 Graceful-Restart is disabled
74 SSO is disabled
75Connection state is ESTAB, I/O status: 1, unread input bytes: 0
76Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
77Local host: 172.25.1.1, Local port: 179
78Foreign host: 172.25.2.2, Foreign port: 47953
79Connection tableid (VRF): 0
80Maximum output segment queue size: 50
81
82Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
83
84Event Timers (current time is 0x33CC4E):
85Timer Starts Wakeups Next
86Retrans 6 0 0x0
87TimeWait 0 0 0x0
88AckHold 5 3 0x0
89SendWnd 0 0 0x0
90KeepAlive 0 0 0x0
91GiveUp 0 0 0x0
92PmtuAger 0 0 0x0
93DeadWait 0 0 0x0
94Linger 0 0 0x0
95ProcessQ 0 0 0x0
96
97iss: 2658011998 snduna: 2658012155 sndnxt: 2658012155
98irs: 3762306664 rcvnxt: 3762306821
99
100sndwnd: 16228 scale: 0 maxrcvwnd: 16384
101rcvwnd: 16228 scale: 0 delrcvwnd: 156
102
103SRTT: 551 ms, RTTO: 3075 ms, RTV: 2524 ms, KRTT: 0 ms
104minRTT: 16 ms, maxRTT: 1000 ms, ACK hold: 120 ms
105uptime: 126928 ms, Sent idletime: 10958 ms, Receive idletime: 11090 ms
106Status Flags: passive open, gen tcbs
107Option Flags: nagle, path mtu capable, SACK option permitted
108 win-scale
109IP Precedence value : 6
110Window update Optimisation : Enabled
111ACK Optimisation : Dynamic ACK Tuning Enabled
112
113Datagrams (max data segment is 1460 bytes):
114Peer MSS: 1460
115Rcvd: 11 (out of order: 0), with data: 6, total data bytes: 156
116Sent: 12 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 6, total data bytes: 156
117
118 Packets received in fast path: 0, fast processed: 0, slow path: 0
119 fast lock acquisition failures: 0, slow path: 0
120TCP Semaphore 0x758D8F87AA00 FREEBGP Address Family Dependency
From the previous output, one might assume that capabilities are features independent of the address family, as they are indeed reported in a dedicated section. However, this assumption does not hold in general. The relationship between capabilities and address families is in fact layered: address families themselves are a capability; specifically, the Multiprotocol Extensions capability (RFC 4760, capability code 1), where each AFI/SAFI pair is advertised as a separate instance.
Beyond that, several other capabilities encode AFI/SAFI tuples within their value field, making them scoped per address family even though they exist as independent capability codes. One such capability, briefly introduced here, is Outbound Route Filtering (RFC 5291). This feature allows a BGP speaker to send a filter to its remote neighbor in order to constrain the announcements received from that peer. In other words, instead of receiving all prefixes and filtering locally, the speaker pushes its inbound filter to the neighbor, which applies it outbound before sending updates, thus reducing unnecessary announcements and saving bandwidth and processing on both sides. This capability, as can be seen below, can only be enabled within the AFI/SAFI configuration mode.
1R1(config-router)#neighbor 172.25.2.2 capa?
2% Unrecognized command
3R1(config-router)#address-family ipv4 unicast
4R1(config-router-af)#neighbor 172.25.2.2 capability ?
5 orf Advertise ORF capability to the peer
6R1(config-router-af)#neighbor 172.25.2.2 capability orf prefix-list bothOnce the capability is enabled, the corresponding information appears in the address family section of the output produced by the usual command.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2
2 [OUTPUT OMITTED]
3 For address family: IPv4 Unicast
4 Session: 172.25.2.2
5 BGP table version 1, neighbor version 1/0
6 Output queue size : 0
7 Index 4, Advertise bit 0
8 4 update-group member
9 AF-dependant capabilities:
10 Outbound Route Filter (ORF) type (128) Prefix-list:
11 Capability code received: IETF pre-standard
12 Send-mode: advertised
13 Receive-mode: advertised
14 [OUTPUT OMITTED]Forced Session Teardown on Capability Modification
As introduced earlier in this post, BGP capabilities are currently exchanged only during the OPEN message exchange phase between BGP neighbors. However, the session reset can occur automatically in some cases. The behavior can be examined by triggering a capability modification on R1 (under default conditions on an eBGP session), specifically by enabling the ORF capability briefly described in the previous section.
1R1(config-router-af)# neighbor 172.25.2.2 capability orf prefix-list both
2R1(config-router-af)#
3*May 24 15:05:48.766: %BGP-3-NOTIFICATION: sent to neighbor 172.25.2.2 6/6 (Other Configuration Change) 0 bytes
4*May 24 15:05:48.801: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Down Capability changed
5*May 24 15:05:48.802: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv4 Unicast topology base removed from session Capability changed
6*May 24 15:05:49.141: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Up Below is the packet capture showing the message exchange during the activation of this capability.
From both sources above, it is evident that as soon as the modification occurs, the local peer (R1) sends a NOTIFICATION message (Code 6, Subcode 6) to inform the neighbor of the change in session characteristics (packet #1). After sending this message, the local peer closes the TCP session by initiating the four-way handshake (packets #2 - #5). Subsequently, the same local peer initiates a new TCP/BGP session, including the new capability within the OPEN message sent to R2 (packet #9).
Automatic vs. Manual Session Reset
In some cases, the forced session reset does not occur automatically when modifying, adding, or removing a capability. In such scenarios, the session must be reset manually (for example, using the clear bgp <AFI> <SAFI> <remote-peer-IP> command) to trigger a new capability exchange. One example of this behavior is when enabling the multi-session capability via the command described in the Multi-Session BGP section in the BGP configuration mode for a specific neighbor. Another example is when enabling BGP Graceful-Restart using the bgp graceful-restart command in BGP configuration mode.
Unsupported BGP Capabilities
In some cases, particularly when interfacing devices from two different vendors, the supported capabilities may be slightly different. 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, typically fails to establish. An exception is shown in the Unsupported BGP Capabilities with Single-Session BGP section, where the session is established despite the capability asymmetry. For demonstration purposes, the previously introduced topology is used to emulate a scenario in which R2 lacks support for the ORF capability. To reproduce this behavior, the ORF capability is enabled on R1 using the command neighbor 172.25.2.2 capability orf prefix-list both, while R2 is configured not to support this capability. The packet exchange sequence observed during the BGP session establishment is shown below.
In this case, the first packet of the TCP three-way handshake is sent by R2. If, instead, the initial TCP SYN were sent by R1, the sequence of exchanged packets would be slightly different. However, the final outcome would remain unchanged. As soon as R2 receives the OPEN message containing R1’s advertised capabilities, it detects the incompatibility. In accordance with the standard behavior, R2 then sends a NOTIFICATION message (Code 2, Subcode 7). As a consequence, the TCP session is terminated by R1 through the four-way handshake.
At the CLI level, the following log messages are displayed on R2 to inform the network administrator of this session compatibility issue.
1*May 24 17:02:13.476: %BGP-3-NOTIFICATION: sent to neighbor 172.25.1.1 passive 2/7 (unsupported/disjoint capability) 0 bytes
2*May 24 17:02:13.476: %BGP-4-MSGDUMP: unsupported or mal-formatted message received from 172.25.1.1:
3FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0039 0104 FEB0 00B4 AC19 0202 1C02 0601
40400 0100 0102 0280 0002 0202 0002 0246 0002 0641 0400 00FE B0
5*May 24 17:02:13.710: %BGP-5-NBR_RESET: Neighbor 172.25.1.1 active reset (BGP Notification sent)
6*May 24 17:02:13.718: %BGP-5-ADJCHANGE: neighbor 172.25.1.1 active Down BGP Notification sent
7*May 24 17:02:13.719: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.1.1 IPv4 Unicast topology base removed from session BGP Notification sent
8*May 24 17:02:17.820: %BGP-5-NBR_RESET: Neighbor 172.25.1.1 passive reset (BGP Notification sent)
9*May 24 17:02:17.832: %BGP-5-ADJCHANGE: neighbor 172.25.1.1 passive Down BGP Notification sentNon-Negotiated BGP Capabilities
In some specific (and remote) scenarios, it may be useful to disable the exchange of BGP capabilities. 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. For this example, the command is applied on R1.
Those curious about the behavior might wonder what happens when trying to establish an eBGP session between two neighbors, where one is configured with the previous command not to exchange any capabilities. In this case, the session still reaches the Established state.
When examining the output, a notable difference lies in the result of the show bgp ipv4 unicast neighbors 172.25.2.2 command on R1.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2
2BGP neighbor is 172.25.2.2, remote AS 65200, external link
3 BGP version 4, remote router ID 172.25.2.2
4 BGP state = Established, up for 00:07:24
5 Last read 00:00:11, last write 00:00:02, hold time is 180, keepalive interval is 60 seconds
6 Last update received: 00:07:23
7 Neighbor sessions:
8 1 active, is not multisession capable (disabled)
9 Stateful switchover support enabled: NO for session 1
10 Message statistics:
11 InQ depth is 0
12 OutQ depth is 0
13 [OUTPUT OMITTED]Unlike in the typical scenario, the Neighbor capabilities section is completely absent from this output.
BGP Session Types: Impact on Address Family Activation
Several fundamental details about how BGP capabilities function have been explored. Now, returning to the core topic: why do BGP capabilities matter when enabling a new address family?
As demonstrated earlier, address families are themselves capabilities. Therefore, when a new address family is enabled for a neighbor using the neighbor <remote-peer-IP> activate command, the local peer must communicate this capability to the remote peer. How this capability exchange is handled depends critically on the BGP session type configured between the peers. Broadly speaking, two BGP session types determine this behavior: single-session and multi-session. The sections below examine both types, using IPv6 Unicast, to illustrate their behavioral differences.
Single-Session vs. Multi-Session
To advertise the new capability associated with the IPv6 Unicast address family, a new OPEN message exchange is required. However, how this exchange proceeds and whether it disrupts the existing session depend on the BGP session type. The two available options are mutually exclusive, and each determines a fundamentally different approach to TCP-level session management:
- 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 dedicated to a single address family
To illustrate this concept, the following examples are provided.
In the first scenario, representing a single-session BGP setup, there is a single TCP session (a single pair of sockets created between the two peer IPs) through which network announcements for multiple address families are exchanged via UPDATE messages.
In the second scenario, representing a multi-session BGP setup, multiple TCP sessions are established between the two peers, each associated with a different address family.
How is multi-session BGP support communicated to the remote peer? Through a specific capability negotiated in the OPEN message: the Multisession BGP Capability (Cisco), identified by code 131.
This capability has a fundamental 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 this point. If this condition is not met, the issue described in the Unsupported BGP Capabilities section would occur in a similar way.
| Peer 1 Config. | Peer 2 Config. | BGP Session Status |
|---|---|---|
| Single-Session | Multi-Session | Not Established |
| Single-Session | Single-Session | Established |
| Multi-Session | Multi-Session | Established |
Single-Session BGP
The first of the two options, referred to as single-session, is examined below. This mode is used by default for all sessions (both internal and external). Using the initial configuration from the introduction, the following output from the show bgp ipv4 unicast neighbors 172.25.2.2 command on R1 demonstrates this.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2
2BGP neighbor is 172.25.2.2, remote AS 65200, external link
3 [OUTPUT OMITTED]
4 Neighbor sessions:
5 1 active, is not multisession capable (disabled)
6 Neighbor capabilities:
7 [OUTPUT OMITTED]
8 Multisession Capability:
9 [OUTPUT OMITTED]This session is considered multisession not capable, and the capability is neither Advertised nor Received. Additionally, the number of sessions is equal to 1 (1 active). 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 the BGP configuration mode. Once this command is applied, the following message is displayed. In this specific case, the command is configured on R1 toward the peer R2.
1*May 24 18:41:58.547: %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.
1R1(config-router)#neighbor 172.25.2.2 transport ?
2 connection-mode Specify passive or active connection
3 multi-session Use Multi-session for transport
4 path-mtu-discovery Use transport path MTU discovery
5 single-session [DEPRECATED]Use only a single session for transportOnce the command is applied, it will appear in the running configuration as well, as illustrated below. It is important to note that this command does not appear by default and is only displayed when explicitly configured.
1R1#show running-config | s r b
2router bgp 65100
3 bgp log-neighbor-changes
4 neighbor 172.25.2.2 remote-as 65200
5 neighbor 172.25.2.2 transport single-session
6 neighbor 172.25.2.2 disable-connected-check
7 neighbor 172.25.2.2 update-source Loopback0
8 !
9 address-family ipv4
10 neighbor 172.25.2.2 activate
11 exit-address-familyEnabling a New Address Family in Single-Session BGP
The behavior of enabling a new address family on peers with an already-established session for at least one address family is examined below. 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 as previously mentioned. Shown below is a truncated output illustrating the session state before activating the IPv6 Unicast address family.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2
2BGP neighbor is 172.25.2.2, remote AS 65200, external link
3 BGP version 4, remote router ID 172.25.2.2
4 BGP state = Established, up for 00:00:13
5 Last read 00:00:13, last write 00:00:12, hold time is 180, keepalive interval is 60 seconds
6 Last update received: 00:00:13
7 Neighbor sessions:
8 1 active, is not multisession capable (disabled)
9 Neighbor capabilities:
10 Route refresh: advertised and received(new)
11 Four-octets ASN Capability: advertised and received
12 Address family IPv4 Unicast: advertised and received
13 Enhanced Refresh Capability: advertised and received
14 Multisession Capability:
15 Stateful switchover support enabled: NO for session 1
16 [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.
1R1(config)#router bgp 65100
2R1(config-router)#address-family ipv6 unicast
3R1(config-router-af)#neighbor 172.25.2.2 activate1R2(config)#router bgp 65200
2R2(config-router)#address-family ipv6 unicast
3R2(config-router-af)#neighbor 172.25.1.1 activateThe 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 OPEN messages. This behavior has a significant impact on the BGP neighborship between the two peers and, more broadly, can be disruptive and cause service interruption if not properly planned.
1*May 24 19:02:54.328: %BGP-5-NBR_RESET: Neighbor 172.25.2.2 reset (Capability changed)
2*May 24 19:02:54.354: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Down Capability changed
3*May 24 19:02:54.363: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv4 Unicast topology base removed from session Capability changed
4*May 24 19:02:55.299: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Up For completeness, the following packet capture shows the sequence of packets exchanged between the two peers after the new address family is enabled.
Rechecking the session status shows that:
- The IPv6 Unicast AFI/SAFI (2/1) has been successfully exchanged between the two peers (Advertised and Received)
- A single TCP session exists between the two peers (note the not multisession capable)
1R1#show bgp ipv4 unicast neighbors 172.25.2.2
2BGP neighbor is 172.25.2.2, remote AS 65200, external link
3 BGP version 4, remote router ID 172.25.2.2
4 BGP state = Established, up for 00:08:17
5 Last read 00:00:31, last write 00:00:00, hold time is 180, keepalive interval is 60 seconds
6 Last update received: 00:08:17
7 Neighbor sessions:
8 1 active, is not multisession capable (disabled)
9 Neighbor capabilities:
10 Route refresh: advertised and received(new)
11 Four-octets ASN Capability: advertised and received
12 Address family IPv4 Unicast: advertised and received
13 Address family IPv6 Unicast: advertised and received
14 Enhanced Refresh Capability: advertised and received
15 Multisession Capability:
16 Stateful switchover support enabled: NO for session 1
17 [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.
1R1#show tcp brief
2TCB Local Address Foreign Address (state)
3758D1A8E6E98 172.25.1.1.39859 172.25.2.2.179 ESTAB
4[OUTPUT OMITTED]This information is also reflected in the output obtained when checking the BGP session status with the neighbor. The output of the command show bgp ipv4 unicast neighbors 172.25.2.2 | include port: is shown below.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2 | include port:
2Local host: 172.25.1.1, Local port: 39859
3Foreign host: 172.25.2.2, Foreign port: 179Unsupported BGP Capabilities with Single-Session BGP
Before proceeding with additional details, it is useful to examine how a single-session BGP session behaves when an address family, specifically IPv6 Unicast, is enabled on only one peer (for example, R1). To establish a clean baseline for this test, the IPv6 Unicast address family is first disabled on both nodes. With that baseline in place, the address family is re-enabled only on R1, and the session state is verified using the standard command.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2 | section Neighbor capabilities
2 Neighbor capabilities:
3 Route refresh: advertised and received(new)
4 Four-octets ASN Capability: advertised and received
5 Address family IPv4 Unicast: advertised and received
6 Address family IPv6 Unicast: advertised
7 Enhanced Refresh Capability: advertised and received
8 Multisession Capability:
9 Stateful switchover support enabled: NO for session 1Because AFI/SAFI 2/1 (IPv6 Unicast) is enabled only on R1, the capability is Advertised but not Received.
As shown by the log messages in the R1 CLI, the BGP session still reaches the Established state despite the asymmetric configuration. This behavior differs from what is shown in the Unsupported BGP Capabilities section, where the capability mismatch prevented the BGP session from being established.
1*May 24 07:11:45.978: %BGP-5-NBR_RESET: Neighbor 172.25.2.2 reset (Capability changed)
2*May 24 07:11:45.983: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Down Capability changed
3*May 24 07:11:45.984: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv4 Unicast topology base removed from session Capability changed
4*May 24 07:11:46.714: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv6 Unicast topology base removed from session Capability changed
5*May 24 07:11:46.718: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Up Looking at the output of the show bgp ipv6 unicast summary command on R1, a reduced set of information is displayed because no NLRIs have been exchanged, with the NoNeg tag shown in the last column. The same command entered on R2 produces no output.
1R1#show bgp ipv6 unicast summary
2BGP router identifier 172.25.1.1, local AS number 65100
3BGP table version is 1, main routing table version 1
4
5Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
6172.25.2.2 4 65200 0 0 1 0 0 never (NoNeg)If, instead, the session information on R1 is verified using the command show bgp ipv6 unicast neighbors 172.25.2.2, it is possible to observe that some fields are null, empty, or initialized to 0.
1R1#show bgp ipv6 unicast neighbors 172.25.2.2
2BGP neighbor is 172.25.2.2, remote AS 65200, external link
3 BGP version 4, remote router ID 172.25.2.2
4 BGP state = Idle, down for never
5 Last update received: n/a
6 Neighbor sessions:
7 1 active, is not multisession capable (disabled)
8 Neighbor capabilities:
9 Route refresh: advertised and received(new)
10 Four-octets ASN Capability: advertised and received
11 Address family IPv4 Unicast: advertised and received
12 Address family IPv6 Unicast: advertised
13 Enhanced Refresh Capability: advertised and received
14 Multisession Capability:
15 Stateful switchover support enabled: NO for session 1
16 Message statistics:
17 InQ depth is 0
18 OutQ depth is 0
19
20 Sent Rcvd
21 Opens: 1 1
22 Notifications: 0 0
23 Updates: 1 1
24 Keepalives: 3 3
25 Route Refresh: 0 0
26 Total: 5 5
27 Do log neighbor state changes (via global configuration)
28 Default minimum time between advertisement runs is 30 seconds
29
30 For address family: IPv4 Unicast
31 Session: 172.25.2.2
32 BGP table version 1, neighbor version 1/0
33 Output queue size : 0
34 Index 79, Advertise bit 0
35 79 update-group member
36 Slow-peer detection is disabled
37 Slow-peer split-update-group dynamic is disabled
38 Sent Rcvd
39 Prefix activity: ---- ----
40 Prefixes Current: 0 0
41 Prefixes Total: 0 0
42 Implicit Withdraw: 0 0
43 Explicit Withdraw: 0 0
44 Used as bestpath: n/a 0
45 Used as multipath: n/a 0
46 Used as secondary: n/a 0
47
48 Outbound Inbound
49 Local Policy Denied Prefixes: -------- -------
50 Total: 0 0
51 Number of NLRIs in the update sent: max 0, min 0
52 Last detected as dynamic slow peer: never
53 Dynamic slow peer recovered: never
54 Refresh Epoch: 1
55 Last Sent Refresh Start-of-rib: never
56 Last Sent Refresh End-of-rib: never
57 Last Received Refresh Start-of-rib: never
58 Last Received Refresh End-of-rib: never
59 Sent Rcvd
60 Refresh activity: ---- ----
61 Refresh Start-of-RIB 0 0
62 Refresh End-of-RIB 0 0
63
64 For address family: IPv6 Unicast
65 BGP table version 1, neighbor version 1/0
66 Output queue size : 0
67 Index 0, Advertise bit 0
68 Slow-peer detection is disabled
69 Slow-peer split-update-group dynamic is disabled
70 Sent Rcvd
71 Prefix activity: ---- ----
72 Prefixes Current: 0 0
73 Prefixes Total: 0 0
74 Implicit Withdraw: 0 0
75 Explicit Withdraw: 0 0
76 Used as bestpath: n/a 0
77 Used as multipath: n/a 0
78 Used as secondary: n/a 0
79
80 Outbound Inbound
81 Local Policy Denied Prefixes: -------- -------
82 Total: 0 0
83 Number of NLRIs in the update sent: max 0, min 0
84 Last detected as dynamic slow peer: never
85 Dynamic slow peer recovered: never
86 Refresh Epoch: 1
87 Last Sent Refresh Start-of-rib: never
88 Last Sent Refresh End-of-rib: never
89 Last Received Refresh Start-of-rib: never
90 Last Received Refresh End-of-rib: never
91 Sent Rcvd
92 Refresh activity: ---- ----
93 Refresh Start-of-RIB 0 0
94 Refresh End-of-RIB 0 0
95
96 Address tracking is enabled, the RIB does have a route to 172.25.2.2
97 Route to peer address reachability Up: 1; Down: 0
98 Last notification 1d07h
99 Connections established 82; dropped 81
100 Last reset 00:01:25, due to Capability changed of session 1
101 External BGP neighbor not directly connected.
102 External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
103 Interface associated: (none) (peering address NOT in same link)
104 Transport(tcp) path-mtu-discovery is enabled
105 Graceful-Restart is disabled
106 SSO is disabled
107 No active TCP connectionThe Idle state indicates that no BGP session has been established for this address family because the corresponding capability has not been received from the peer. Consequently, the final section containing TCP session statistics is absent from the output and replaced by the No active TCP connection statement.
Before proceeding to the next section, the IPv6 Unicast address family on R1 is disabled to restore the lab configuration to its initial state.
Multi-Session BGP
The second option for managing the activation of new address families is now examined. As mentioned earlier, the multi-session characteristic of a BGP session is negotiated at session establishment via the capabilities included in the OPEN messages. To enable this feature, the command neighbor <remote-peer-IP> transport multi-session can be used, which should be entered in BGP configuration mode. It should be noted that this command can also be entered directly within the AFI/SAFI configuration mode. In such cases, the command is hidden and therefore not suggested by the context-sensitive help. If entered anyway, it is accepted but is reconfigured at the BGP configuration level.
The application of this command can lead to two different effects: either an automatic session reset or no effect. When the configuration is present only for one address family (for example, only IPv4 Unicast is enabled), the reset is not triggered automatically. However, if at least two address families have already been activated within the session, then an automatic forced reset occurs.
In the current scenario, 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 the following conditions are met:
- 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.
1router bgp 65100
2 bgp log-neighbor-changes
3 neighbor 172.25.2.2 remote-as 65200
4 neighbor 172.25.2.2 transport multi-session
5 neighbor 172.25.2.2 disable-connected-check
6 neighbor 172.25.2.2 update-source Loopback0
7 !
8 address-family ipv4
9 neighbor 172.25.2.2 activate
10 exit-address-familyTo clearly observe the effect of applying this command, it is necessary to start with a single-session BGP configuration. The updated configuration of R1, serving as the new baseline, is provided below.
1R1#show running-config | s r b
2router bgp 65100
3 bgp log-neighbor-changes
4 neighbor 172.25.2.2 remote-as 65200
5 neighbor 172.25.2.2 transport single-session
6 neighbor 172.25.2.2 disable-connected-check
7 neighbor 172.25.2.2 update-source Loopback0
8 !
9 address-family ipv4
10 neighbor 172.25.2.2 activate
11 exit-address-familyUpon applying the command for enabling the multi-session capability and thus changing the session type, no change occurs since only a single address family is currently configured. In order to enable the BGP peers to exchange these capabilities, a hard reset is required using the clear bgp ipv4 unicast * command.
The session information can now be verified using the standard show command.
1R1#show bgp ipv4 unicast neighbors 172.25.2.2
2BGP neighbor is 172.25.2.2, remote AS 65200, external link
3 BGP version 4, remote router ID 172.25.2.2
4 BGP state = Established, up for 00:00:04
5 Last read 00:00:04, last write 00:00:04, hold time is 180, keepalive interval is 60 seconds
6 Last update received: 00:00:04
7 Neighbor sessions:
8 1 active, is multisession capable
9 Neighbor capabilities:
10 Route refresh: advertised and received(new)
11 Four-octets ASN Capability: advertised and received
12 Address family IPv4 Unicast: advertised and received
13 Enhanced Refresh Capability: advertised and received
14 Multisession Capability: advertised and received
15 Stateful switchover support enabled: NO for session 1
16 Message statistics, state Established:
17 InQ depth is 0
18 OutQ depth is 0
19
20 Sent Rcvd
21 Opens: 1 1
22 Notifications: 0 0
23 Updates: 1 1
24 Keepalives: 2 2
25 Route Refresh: 0 0
26 Total: 4 4
27 Do log neighbor state changes (via global configuration)
28 Default minimum time between advertisement runs is 30 seconds
29
30 For address family: IPv4 Unicast
31 Session: 172.25.2.2 session 1
32 BGP table version 1, neighbor version 1/0
33 Output queue size : 0
34 Index 109, Advertise bit 0
35 109 update-group member
36 Slow-peer detection is disabled
37 Slow-peer split-update-group dynamic is disabled
38 Sent Rcvd
39 Prefix activity: ---- ----
40 Prefixes Current: 0 0
41 Prefixes Total: 0 0
42 Implicit Withdraw: 0 0
43 Explicit Withdraw: 0 0
44 Used as bestpath: n/a 0
45 Used as multipath: n/a 0
46 Used as secondary: n/a 0
47
48 Outbound Inbound
49 Local Policy Denied Prefixes: -------- -------
50 Total: 0 0
51 Number of NLRIs in the update sent: max 1, min 0
52 Last detected as dynamic slow peer: never
53 Dynamic slow peer recovered: never
54 Refresh Epoch: 1
55 Last Sent Refresh Start-of-rib: never
56 Last Sent Refresh End-of-rib: never
57 Last Received Refresh Start-of-rib: never
58 Last Received Refresh End-of-rib: never
59 Sent Rcvd
60 Refresh activity: ---- ----
61 Refresh Start-of-RIB 0 0
62 Refresh End-of-RIB 0 0
63
64 Address tracking is enabled, the RIB does have a route to 172.25.2.2
65 Route to peer address reachability Up: 1; Down: 0
66 Last notification 1d09h
67 Connections established 113; dropped 112
68 Last reset 00:00:12, due to Active open failed
69 External BGP neighbor not directly connected.
70 External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
71 Interface associated: (none) (peering address NOT in same link)
72 Transport(tcp) path-mtu-discovery is enabled
73 Graceful-Restart is disabled
74 SSO is disabled
75Connection state is ESTAB, I/O status: 1, unread input bytes: 0
76Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
77Local host: 172.25.1.1, Local port: 179
78Foreign host: 172.25.2.2, Foreign port: 39749
79Connection tableid (VRF): 0
80Maximum output segment queue size: 50
81
82Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
83
84Event Timers (current time is 0x737469F):
85Timer Starts Wakeups Next
86Retrans 4 0 0x0
87TimeWait 0 0 0x0
88AckHold 3 1 0x0
89SendWnd 0 0 0x0
90KeepAlive 0 0 0x0
91GiveUp 0 0 0x0
92PmtuAger 0 0 0x0
93DeadWait 0 0 0x0
94Linger 0 0 0x0
95ProcessQ 0 0 0x0
96
97iss: 195381025 snduna: 195381149 sndnxt: 195381149
98irs: 4002680028 rcvnxt: 4002680152
99
100sndwnd: 16261 scale: 0 maxrcvwnd: 16384
101rcvwnd: 16261 scale: 0 delrcvwnd: 123
102
103SRTT: 413 ms, RTTO: 3205 ms, RTV: 2792 ms, KRTT: 0 ms
104minRTT: 30 ms, maxRTT: 1000 ms, ACK hold: 130 ms
105uptime: 6822 ms, Sent idletime: 6467 ms, Receive idletime: 6448 ms
106Status Flags: passive open, gen tcbs
107Option Flags: nagle, path mtu capable, SACK option permitted
108 win-scale
109IP Precedence value : 6
110Window update Optimisation : Enabled
111ACK Optimisation : Dynamic ACK Tuning Enabled
112
113Datagrams (max data segment is 1460 bytes):
114Peer MSS: 1460
115Rcvd: 7 (out of order: 0), with data: 4, total data bytes: 123
116Sent: 8 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 4, total data bytes: 123
117
118 Packets received in fast path: 0, fast processed: 0, slow path: 0
119 fast lock acquisition failures: 0, slow path: 0
120TCP Semaphore 0x758D8F87A860 FREEIn this case, as is evident from the initial section of the output, the multi-session capability is supported and advertised by both peers. Additionally, in the section dedicated to the IPv4 Unicast address family, a new field appears that references the session number Session: 172.25.2.2 session 1. Each address family is sequentially assigned an ID and is referenced throughout the output accordingly. In this case, the IPv4 Unicast address family is associated with ID 1.
Enabling a New Address Family in Multi-Session BGP
The behavior observed when enabling the IPv6 Unicast address family on both peers is now examined. To enable the new address family, the same remote peer IP address configured for IPv4 Unicast is referenced. For completeness, the BGP log messages collected on R1 and the packet capture are shown below.
1R1(config-router-af)# neighbor 172.25.2.2 activate
2R1(config-router-af)#
3*May 26 05:29:26.585: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 session 2 Up From the output above, the expected behavior is evident. The first important observation is the absence of a forced reset from either router. When this behavior is compared with the scenario described in the Enabling a New Address Family in Single-Session BGP section, it is clear from both sources that the previously established session (the one related to IPv4 Unicast) remains unaffected. This confirms what is explained earlier and highlights the substantial difference in behavior between the two BGP session types.
The number of established sessions equals the number of address families enabled on both routers; in this case, two. From the BGP log message displayed on the CLI after neighbor activation, the session ID associated with this new session can already be determined: session 2.
The output of the show bgp ipv6 unicast neighbors 172.25.2.2 command entered on R1 now reveals different information compared to the previous scenarios.
1R1#show bgp ipv6 unicast neighbors 172.25.2.2
2BGP neighbor is 172.25.2.2, remote AS 65200, external link
3 BGP version 4, remote router ID 172.25.2.2
4 Session state = Established, up for 00:10:15
5 Last read 00:00:56, last write 00:00:17, hold time is 180, keepalive interval is 60 seconds
6 BGP multisession with 2 sessions (2 established), first up for 00:15:36
7 Last update received: 00:10:15
8 Neighbor sessions:
9 2 active, is multisession capable
10 Neighbor capabilities:
11 Route refresh: advertised and received(new) on session 1, 2
12 Four-octets ASN Capability: advertised and received on session 1, 2
13 Address family IPv4 Unicast: advertised and received
14 Address family IPv6 Unicast: advertised and received
15 Enhanced Refresh Capability: advertised and received
16 Multisession Capability: advertised and received
17 Stateful switchover support enabled: NO for session 1, 2
18 Message statistics for 172.25.2.2 session 1, state Established:
19 InQ depth is 0
20 OutQ depth is 0
21
22 Sent Rcvd
23 Opens: 1 1
24 Notifications: 0 0
25 Updates: 1 1
26 Keepalives: 19 19
27 Route Refresh: 0 0
28 Total: 21 21
29 Message statistics for 172.25.2.2 session 2, state Established:
30 InQ depth is 0
31 OutQ depth is 0
32
33 Sent Rcvd
34 Opens: 1 1
35 Notifications: 0 0
36 Updates: 1 1
37 Keepalives: 13 13
38 Route Refresh: 0 0
39 Total: 15 15
40 Do log neighbor state changes (via global configuration)
41 Default minimum time between advertisement runs is 30 seconds
42
43 For address family: IPv4 Unicast
44 Session: 172.25.2.2 session 1
45 BGP table version 1, neighbor version 1/0
46 Output queue size : 0
47 Index 110, Advertise bit 0
48 session 1 member
49 110 update-group member
50 Slow-peer detection is disabled
51 Slow-peer split-update-group dynamic is disabled
52 Sent Rcvd
53 Prefix activity: ---- ----
54 Prefixes Current: 0 0
55 Prefixes Total: 0 0
56 Implicit Withdraw: 0 0
57 Explicit Withdraw: 0 0
58 Used as bestpath: n/a 0
59 Used as multipath: n/a 0
60 Used as secondary: n/a 0
61
62 Outbound Inbound
63 Local Policy Denied Prefixes: -------- -------
64 Total: 0 0
65 Number of NLRIs in the update sent: max 1, min 0
66 Last detected as dynamic slow peer: never
67 Dynamic slow peer recovered: never
68 Refresh Epoch: 1
69 Last Sent Refresh Start-of-rib: never
70 Last Sent Refresh End-of-rib: never
71 Last Received Refresh Start-of-rib: never
72 Last Received Refresh End-of-rib: never
73 Sent Rcvd
74 Refresh activity: ---- ----
75 Refresh Start-of-RIB 0 0
76 Refresh End-of-RIB 0 0
77
78 For address family: IPv6 Unicast
79 Session: 172.25.2.2 session 2
80 BGP table version 1, neighbor version 1/0
81 Output queue size : 0
82 Index 3, Advertise bit 0
83 session 2 member
84 3 update-group member
85 Slow-peer detection is disabled
86 Slow-peer split-update-group dynamic is disabled
87 Sent Rcvd
88 Prefix activity: ---- ----
89 Prefixes Current: 0 0
90 Prefixes Total: 0 0
91 Implicit Withdraw: 0 0
92 Explicit Withdraw: 0 0
93 Used as bestpath: n/a 0
94 Used as multipath: n/a 0
95 Used as secondary: n/a 0
96
97 Outbound Inbound
98 Local Policy Denied Prefixes: -------- -------
99 Total: 0 0
100 Number of NLRIs in the update sent: max 0, min 0
101 Last detected as dynamic slow peer: never
102 Dynamic slow peer recovered: never
103 Refresh Epoch: 1
104 Last Sent Refresh Start-of-rib: never
105 Last Sent Refresh End-of-rib: never
106 Last Received Refresh Start-of-rib: never
107 Last Received Refresh End-of-rib: never
108 Sent Rcvd
109 Refresh activity: ---- ----
110 Refresh Start-of-RIB 0 0
111 Refresh End-of-RIB 0 0
112
113 Address tracking is enabled, the RIB does have a route to 172.25.2.2
114 Route to peer address reachability Up: 1; Down: 0
115 Last notification 1d16h
116 Connections established 117; dropped 115
117 Last reset 00:10:58, due to Neighbor deleted of session 2
118 External BGP neighbor not directly connected.
119 External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
120 Interface associated: (none) (peering address NOT in same link)
121 Transport(tcp) path-mtu-discovery is enabled
122 Graceful-Restart is disabled
123 SSO is disabled
124Connection state is ESTAB, I/O status: 1, unread input bytes: 0
125Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
126Local host: 172.25.1.1, Local port: 31275
127Foreign host: 172.25.2.2, Foreign port: 179
128Connection tableid (VRF): 0
129Maximum output segment queue size: 50
130
131Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
132
133Event Timers (current time is 0x8C6F24B):
134Timer Starts Wakeups Next
135Retrans 15 0 0x0
136TimeWait 0 0 0x0
137AckHold 15 11 0x0
138SendWnd 0 0 0x0
139KeepAlive 0 0 0x0
140GiveUp 0 0 0x0
141PmtuAger 18 17 0x8C6F5F9
142DeadWait 0 0 0x0
143Linger 0 0 0x0
144ProcessQ 0 0 0x0
145
146iss: 3167507810 snduna: 3167508149 sndnxt: 3167508149
147irs: 1517696036 rcvnxt: 1517696375
148
149sndwnd: 16046 scale: 0 maxrcvwnd: 16384
150rcvwnd: 16046 scale: 0 delrcvwnd: 338
151
152SRTT: 865 ms, RTTO: 1866 ms, RTV: 1001 ms, KRTT: 0 ms
153minRTT: 26 ms, maxRTT: 1000 ms, ACK hold: 120 ms
154uptime: 632241 ms, Sent idletime: 14621 ms, Receive idletime: 14742 ms
155Status Flags: active open
156Option Flags: nagle, path mtu capable, SACK option permitted
157 win-scale
158IP Precedence value : 6
159Window update Optimisation : Enabled
160ACK Optimisation : Dynamic ACK Tuning Enabled
161
162Datagrams (max data segment is 1460 bytes):
163Peer MSS: 1460
164Rcvd: 29 (out of order: 0), with data: 15, total data bytes: 338
165Sent: 29 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 15, total data bytes: 338
166
167 Packets received in fast path: 0, fast processed: 0, slow path: 0
168 fast lock acquisition failures: 0, slow path: 0
169TCP Semaphore 0x758D8F87A790 FREE As reflected in the output, there are a total of two sessions, along with the Multisession Capability, which is both Advertised and Received. The output also includes uptime information for both sessions. The uptime of the newly established session is indicated in the entry Session state = Established, up for 00:10:15. The uptime of the first established session (associated with the IPv4 Unicast address family) is shown in the entry BGP multisession with 2 sessions (2 established), first up for 00:15:36.
A dedicated section is provided for each of the two sessions, containing statistics about the messages exchanged between the two peers.
1 [OUTPUT OMITTED]
2 Message statistics for 172.25.2.2 session 1, state Established:
3 InQ depth is 0
4 OutQ depth is 0
5
6 Sent Rcvd
7 Opens: 1 1
8 Notifications: 0 0
9 Updates: 1 1
10 Keepalives: 19 19
11 Route Refresh: 0 0
12 Total: 21 21
13 Message statistics for 172.25.2.2 session 2, state Established:
14 InQ depth is 0
15 OutQ depth is 0
16
17 Sent Rcvd
18 Opens: 1 1
19 Notifications: 0 0
20 Updates: 1 1
21 Keepalives: 13 13
22 Route Refresh: 0 0
23 Total: 15 15
24 [OUTPUT OMITTED]As with the single-session case, the TCP sockets can be verified, using R1 as reference. The following output shows that two separate sockets have been created, corresponding to the two sessions over which the information for the two address families is exchanged.
1R1#sh tcp brief
2TCB Local Address Foreign Address (state)
3758D1A8E7AB8 172.25.1.1.31275 172.25.2.2.179 ESTAB
4758D1A9C23B0 172.25.1.1.179 172.25.2.2.33120 ESTAB
5[OUTPUT OMITTED]Configuring Multi-Session with Multiple Address Families Already Active
In the previous section, it has been verified that enabling the multi-session capability is essential to preserve the state of sessions already in the Established state. In this section, the behavior mentioned in the Multi-Session BGP section is examined: that an automatic reset occurs following the activation of multi-session when at least two address families are already enabled. To demonstrate this behavior, the following configuration is used as the baseline (the configuration of R2 is identical with mirrored parameters).
1R1#show running-config | s r b
2router bgp 65100
3 bgp log-neighbor-changes
4 neighbor 172.25.2.2 remote-as 65200
5 neighbor 172.25.2.2 disable-connected-check
6 neighbor 172.25.2.2 update-source Loopback0
7 !
8 address-family ipv4
9 neighbor 172.25.2.2 activate
10 exit-address-family
11 !
12 address-family ipv6
13 neighbor 172.25.2.2 activate
14 exit-address-familyThe multi-session capability is now enabled on both peers by inserting the command neighbor <remote-peer-IP> transport multi-session within the BGP configuration mode. The following shows the logs obtained via CLI and the associated packet capture.
1R1(config-router)#neighbor 172.25.2.2 transport multi-session
2R1(config-router)#
3*May 26 06:13:39.653: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Down Capability changed
4*May 26 06:13:39.664: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv6 Unicast topology base removed from session Capability changed
5*May 26 06:13:39.669: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv4 Unicast topology base removed from session Capability changed
6*May 26 06:13:40.044: %BGP-3-NOTIFICATION: sent to neighbor 172.25.2.2 active 2/7 (unsupported/disjoint capability) 0 bytes
7*May 26 06:13:40.065: %BGP-4-MSGDUMP: unsupported or mal-formatted message received from 172.25.2.2:
8FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0039 0104 FEB0 00B4 AC19 0202 1C02 0601
90400 0100 0102 0280 0002 0202 0002 0246 0002 0641 0400 00FE B0
10*May 26 06:13:44.825: %BGP-5-NBR_RESET: Neighbor 172.25.2.2 active reset (BGP Notification sent)
11*May 26 06:13:44.843: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 active Down BGP Notification sent
12*May 26 06:13:44.843: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv4 Unicast topology base removed from session BGP Notification sent
13*May 26 06:13:51.257: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 Up
14*May 26 06:13:53.270: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 session 2 Up At first glance, there might appear to be an error given the BGP-4-MSGDUMP entry. In reality, this is expected behavior and can be attributed to a very brief transitory state. In this specific case, the multi-session command is not entered at the same instant on both peers but with a slight delay. This delay is the underlying reason for this behavior. The packet capture shown below is analyzed step-by-step to describe the steps that lead to the creation of the two sessions.
For clarity, a chronological summary of the packet capture is provided below:
- At packet #58, a standard TCP session closure request is sent by R1, concluding with packet #62. This occurs because the activation command is entered on R1 before R2
- At packet #61, R1 (having already closed its session with packets #58 – #59) begins to open a new TCP session, concluding with packet #64
- At packet #65, R1 sends an OPEN message that includes the multi-session capability
- At packet #67, R1 receives the corresponding message from R2; however, the multi-session capability is not present. This absence is because the activation of this capability does not occur at the same instant on both peers; there is a small delay
- At NOTIFICATION message #69, R1 informs R2 of a discrepancy in the negotiated capabilities. The TCP session must therefore be closed
- From packet #70 to #73, the TCP session closure initiated by R2 occurs
- At packet #74, after the transitory state, a new TCP session is initiated (up to #76)
- At packets #77 and #79, the two peers exchange OPEN messages that include the new capability. The presence of this capability in both messages leads to the completion of the session establishment (packet #88)
- At packets #89–91, a new TCP session is opened, this time by R1. This behavior is directly related to the activation of the multi-session feature
- At packet #92, R1 sends an OPEN message that includes both the multi-session capability and the Multiprotocol extensions capability announcing IPv6 Unicast. The same content is presented in the OPEN message sent by R2 (#94)
- Through the subsequent packets, the opening of this second session dedicated to another address family concludes
Unsupported BGP Capabilities with Multi-Session BGP
As described in the Unsupported BGP Capabilities section, unsupported capabilities in a single-session BGP scenario result in session failure in most cases. The same condition is analyzed in a multi-session BGP context, specifically when an address family is enabled on only one peer.
For this validation, the neighbor <remote-peer-IP> transport multi-session command is maintained on both R1 and R2. The IPv6 Unicast address family is then disabled on both nodes using the no neighbor <remote-peer-IP> activate command.
After both peers return to the baseline state (multi-session mode with only IPv4 Unicast enabled), the IPv6 Unicast address family is enabled on R2 in AFI/SAFI configuration mode with the neighbor <remote-peer-IP> activate command. The BGP log messages observed on both peers are shown below:
1*May 26 17:44:40.269: %BGP-3-NOTIFICATION: sent to neighbor 172.25.2.2 passive 2/8 (no supported AFI/SAFI) 3 bytes 000201
2*May 26 17:44:44.763: %BGP-5-NBR_RESET: Neighbor 172.25.2.2 passive reset (BGP Notification sent)
3*May 26 17:44:44.763: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 passive Down AFI/SAFI not supported1R2(config-router-af)# neighbor 172.25.1.1 activate
2R2(config-router-af)#
3*May 26 17:44:40.215: %BGP-5-NBR_RESET: Neighbor 172.25.1.1 active reset (BGP Notification received)
4*May 26 17:44:40.216: %BGP-5-ADJCHANGE: neighbor 172.25.1.1 active Down BGP Notification received
5*May 26 17:44:40.217: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.1.1 IPv6 Unicast topology base removed from session BGP Notification received
6*May 26 17:45:40.633: %BGP-3-NOTIFICATION: received from neighbor 172.25.1.1 active 2/8 (no supported AFI/SAFI) 3 bytes 000201 (timer expired)To analyze the message exchange in greater detail, the packet capture of the packets exchanged between the two peers is provided below.
As is evident from the packet capture, the first packet sent by R2 upon entering the IPv6 Unicast address family activation command is a TCP session opening. This behavior is a direct result of the multi-session configuration. At packet #6, sent by R1, a difference can be observed compared to the scenario described in the Unsupported BGP Capabilities section. In this case, R1 does not send a NOTIFICATION message with code/subcode 2/7 but rather with code/subcode 2/8. This code, as shown in the packet capture, corresponds to the value No supported AFI/SAFI (Cisco) (8). The difference lies in the specific error subcode used: code 2/8 is a Cisco-proprietary subcode, No supported AFI/SAFI, applied when the advertised AFI/SAFI is not supported by the peer, whereas code 2/7 (Unsupported Capability, defined in RFC 5492) is used for generic capability incompatibilities such as the ORF feature shown in the Unsupported BGP Capabilities section.
The essential point to understand here is that the previously established session remains unaffected. Consequently, upon receiving the NOTIFICATION message, R2 proceeds to close the TCP session.
The output of the show bgp ipv6 unicast neighbors 172.25.1.1 command entered on R2 reveals information not typically seen in other scenarios. The output is truncated for brevity.
1R2#show bgp ipv6 unicast neighbors 172.25.1.1
2 [OUTPUT OMITTED]
3 Address family IPv6 Unicast: advertised
4 Enhanced Refresh Capability: advertised and received
5 Multisession Capability: advertised and received
6 Stateful switchover support enabled: NO for session 1
7 [OUTPUT OMITTED]
8 For address family: IPv6 Unicast
9 BGP table version 1, neighbor version 1/0
10 Output queue size : 0
11 Index 0, Advertise bit 0
12 Address family unwanted by neighbor
13 Slow-peer detection is disabled
14 [OUTPUT OMITTED]
15 No active TCP connectionThe following points should be noted from this output:
- The IPv6 Unicast address family is Advertised only
- The IPv6 Unicast address family is marked as unwanted by neighbor
- There is no TCP session information associated with the IPv6 Unicast address family because no TCP session was established, as confirmed earlier by the packet capture
Takeaways
After examining the differences between the two mechanisms, which one is more suitable for an enterprise-grade network? As always, it depends.
From a dependency standpoint, multi-session BGP allows each address family to be managed independently. This independence applies both when activating new address families and when performing hard resets using the clear bgp <AFI> <SAFI> * command. During maintenance windows where modifications are necessary, or more generally, when operating on a specific address family, this configuration allows the scope of the intervention to be limited.
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 recommended to establish multi-session BGP from the outset, rather than introducing it later during the network infrastructure lifecycle. If it has not been enabled, it is advisable to schedule a maintenance window to configure it and benefit from it in the future.
I hope this post has been helpful. If you have any additional information or experience with this feature, feel free to reach out via social media.
See you in the next one! 🙂