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.
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-familyBelow is the configuration of R2.
1R2#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 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.
1Frame 11: 116 bytes on wire (928 bits), 116 bytes captured (928 bits)
2Ethernet 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)
3Internet Protocol Version 4, Src: 172.25.1.1, Dst: 172.25.2.2
4Transmission Control Protocol, Src Port: 32888, Dst Port: 179, Seq: 1, Ack: 1, Len: 62
5Border Gateway Protocol - OPEN Message
6 Marker: ffffffffffffffffffffffffffffffff
7 Length: 62
8 Type: OPEN Message (1)
9 Version: 4
10 My AS: 65100
11 Hold Time: 180
12 BGP Identifier: 172.25.1.1
13 Optional Parameters Length: 33
14 Optional Parameters
15 Optional Parameter: Capability
16 Optional Parameter: Capability
17 Optional Parameter: Capability
18 Optional Parameter: Capability
19 Parameter Type: Capability (2)
20 Parameter Length: 3
21 Capability: Multisession (Cisco)
22 Type: Multisession (Cisco) (131)
23 Length: 1
24 Flag: 0x00
25 Optional Parameter: Capability
26 Optional Parameter: CapabilityThese 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.
1R1#show ip bgp 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:23:26
5 Last read 00:00:30, last write 00:00:10, hold time is 180, keepalive interval is 60 seconds
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 Enhanced Refresh Capability: advertised and received
13 Multisession Capability:
14 Stateful switchover support enabled: NO for session 1
15 Message statistics:
16 InQ depth is 0
17 OutQ depth is 0
18
19 Sent Rcvd
20 Opens: 1 1
21 Notifications: 0 0
22 Updates: 2 1
23 Keepalives: 28 27
24 Route Refresh: 0 0
25 Total: 31 29
26 Do log neighbor state changes (via global configuration)
27 Default minimum time between advertisement runs is 30 seconds
28
29 For address family: IPv4 Unicast
30 Session: 172.25.2.2
31 BGP table version 2, neighbor version 2/0
32 Output queue size : 0
33 Index 24, Advertise bit 0
34 24 update-group member
35 Slow-peer detection is disabled
36 Slow-peer split-update-group dynamic is disabled
37 Sent Rcvd
38 Prefix activity: ---- ----
39 Prefixes Current: 1 0
40 Prefixes Total: 1 0
41 Implicit Withdraw: 0 0
42 Explicit Withdraw: 0 0
43 Used as bestpath: n/a 0
44 Used as multipath: n/a 0
45 Used as secondary: n/a 0
46
47 Outbound Inbound
48 Local Policy Denied Prefixes: -------- -------
49 Total: 0 0
50 Number of NLRIs in the update sent: max 1, min 0
51 Last detected as dynamic slow peer: never
52 Dynamic slow peer recovered: never
53 Refresh Epoch: 1
54 Last Sent Refresh Start-of-rib: never
55 Last Sent Refresh End-of-rib: never
56 Last Received Refresh Start-of-rib: never
57 Last Received Refresh End-of-rib: never
58 Sent Rcvd
59 Refresh activity: ---- ----
60 Refresh Start-of-RIB 0 0
61 Refresh End-of-RIB 0 0
62
63 Address tracking is enabled, the RIB does have a route to 172.25.2.2
64 Route to peer address reachability Up: 1; Down: 0
65 Last notification 6d22h
66 Connections established 16; dropped 15
67 Last reset 00:23:32, due to BGP Notification received of session 1, Administrative Reset
68 External BGP neighbor not directly connected.
69 External BGP neighbor NOT configured for connected checks (single-hop disable-connected-check)
70 Interface associated: (none) (peering address NOT in same link)
71 Transport(tcp) path-mtu-discovery is enabled
72 Graceful-Restart is disabled
73 SSO is disabled
74Connection state is ESTAB, I/O status: 1, unread input bytes: 0
75Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
76Local host: 172.25.1.1, Local port: 14764
77Foreign host: 172.25.2.2, Foreign port: 179
78Connection tableid (VRF): 0
79Maximum output segment queue size: 50
80
81Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
82
83Event Timers (current time is 0x6124C783):
84Timer Starts Wakeups Next
85Retrans 30 0 0x0
86TimeWait 0 0 0x0
87AckHold 29 25 0x0
88SendWnd 0 0 0x0
89KeepAlive 0 0 0x0
90GiveUp 0 0 0x0
91PmtuAger 589 588 0x6124CAB1
92DeadWait 0 0 0x0
93Linger 0 0 0x0
94ProcessQ 0 0 0x0
95
96iss: 1198039233 snduna: 1198039900 sndnxt: 1198039900
97irs: 530643033 rcvnxt: 530643627
98
99sndwnd: 15718 scale: 0 maxrcvwnd: 16384
100rcvwnd: 15791 scale: 0 delrcvwnd: 593
101
102SRTT: 982 ms, RTTO: 1129 ms, RTV: 147 ms, KRTT: 0 ms
103minRTT: 1 ms, maxRTT: 1000 ms, ACK hold: 200 ms
104uptime: 1406699 ms, Sent idletime: 10076 ms, Receive idletime: 9874 ms
105Status Flags: active open
106Option Flags: nagle, path mtu capable
107IP Precedence value : 6
108
109Datagrams (max data segment is 1460 bytes):
110Rcvd: 59 (out of order: 0), with data: 29, total data bytes: 593
111Sent: 58 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 30, total data bytes: 666
112
113 Packets received in fast path: 0, fast processed: 0, slow path: 0
114 fast lock acquisition failures: 0, slow path: 0
115TCP Semaphore 0x7F193B70BE70 FREEBGP Address Family Dependency
Looking at the previous output, one might assume that capabilities are features independent of the address family. As noted earlier, they are indeed reported in a dedicated section. However, this assumption does not hold in general. There are, in fact, capabilities that are dependent on the address family. One such capability, which we will briefly mention, is Outbound Route Filtering (RFC 5291). This feature allows a filter to be advertised in order to limit the announcements sent to the remote peer. In other words, instead of one of the peers receiving all announcements and then discarding them locally, the filter is shared with the remote peer so that only the desired announcements are sent.
This capability, as can be seen below, can only be enabled within the address family configuration mode.
1R1(config-router-af)#neighbor 172.25.2.2 capability orf prefix-list bothFor address family: IPv4 Unicast Session: 172.25.2.2 BGP table version 1, neighbor version 1/0 Output queue size : 0 Index 2, Advertise bit 0 2 update-group member AF-dependant capabilities: Outbound Route Filter (ORF) type (128) Prefix-list: Send-mode: advertised Receive-mode: advertised
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.
1Frame 17: 75 bytes on wire (600 bits), 75 bytes captured (600 bits)
2Ethernet 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)
3Internet Protocol Version 4, Src: 172.25.1.1, Dst: 172.25.2.2
4Transmission Control Protocol, Src Port: 53939, Dst Port: 179, Seq: 63, Ack: 77, Len: 21
5Border Gateway Protocol - NOTIFICATION Message
6 Marker: ffffffffffffffffffffffffffffffff
7 Length: 21
8 Type: NOTIFICATION Message (3)
9 Major error Code: OPEN Message Error (2)
10 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.
1*Dec 29 11:17:07.583: %BGP-3-NOTIFICATION: sent to neighbor 172.25.2.2 passive 2/7 (unsupported/disjoint capability) 0 bytes
2*Dec 29 11:17:07.584: %BGP-4-MSGDUMP: unsupported or mal-formatted message received from 172.25.2.2:
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*Dec 29 11:17:12.462: %BGP-5-NBR_RESET: Neighbor 172.25.2.2 passive reset (BGP Notification sent)
6*Dec 29 11:17:12.463: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 passive Down BGP Notification sent
7*Dec 29 11:17:13.487: %BGP-5-NBR_RESET: Neighbor 172.25.2.2 active reset (BGP Notification sent)
8*Dec 29 11:17:13.488: %BGP-5-ADJCHANGE: neighbor 172.25.2.2 active Down BGP Notification sent
9*Dec 29 11:17:13.488: %BGP_SESSION-5-ADJCHANGE: neighbor 172.25.2.2 IPv4 Unicast topology base removed from session BGP Notification sentNon-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.
1Frame 11: 83 bytes on wire (664 bits), 83 bytes captured (664 bits)
2Ethernet 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)
3Internet Protocol Version 4, Src: 172.25.1.1, Dst: 172.25.2.2
4Transmission Control Protocol, Src Port: 14816, Dst Port: 179, Seq: 1, Ack: 1, Len: 29
5Border Gateway Protocol - OPEN Message
6 Marker: ffffffffffffffffffffffffffffffff
7 Length: 29
8 Type: OPEN Message (1)
9 Version: 4
10 My AS: 65100
11 Hold Time: 180
12 BGP Identifier: 172.25.1.1
13 Optional Parameters Length: 0The 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.
1R1#show bgp neighbors 172.25.2.2 | section Neighbor capabilities
2 Neighbor capabilities:
3 Route refresh: advertised and received(new)
4 Address family IPv4 Unicast: advertised and received
5 Address family IPv6 Unicast: advertised
6 Enhanced Refresh Capability: advertised and received
7 Multisession Capability:
8 Stateful switchover support enabled: NO for session 1Single-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.