Introduction
BGP Multisession is the capability of BGP having multiple BGP sessions (and hence TCP sessions) between one pair of BGP speakers, even if there is only one BGP neighbor statement defined between the BGP speakers in the configuration. This feature was introduced together with Multi Topology Routing (MTR). The BGP multisession functionality is needed to make MTR work when BGP is used as the routing protocol where MTR is enabled.
Introduction to MTR
A topology is defined as an independent routing domain that defines a path that the traffic will take across a common physical network. Each topology has its own routing table (RIB) and data forwarding table (CEF table). Figure 1 shows an example network with MTR enabled. There are 3 topologies throughout the network.
BGP and the IGPs have been made MTR-aware, so that they can all exchange prefixes per topology. For BGP to be able to exchange the prefixes per topology and keep them separated from one another, one separate BGP session is created between a pair of BGP speakers per topology. At the same time of introducing topologies, the feature was added for BGP to create one session per address family shared between a pair of BGP speakers. So, there could be as many BGP sessions as the number of topologies times the number of address families which are shared between a pair of BGP speakers. Multisession BGP is explained in the draft draft-ietf-idr-bgp-multisession-05 (expired).
There is always the base topology. The user can further add topologies as needed.
Figure 2 shows the topology used throughout this document.
Capability
The multisession capability exchanged in the OPEN message by a BGP speaker indicates if it is capable of running multisession BGP. The capability code is 131.
Let's have a look at this capability exchanged in the OPEN message, in the topology of Figure 2.
R1#debug ip bgp 10.100.1.2
BGP debugging is on for neighbor 10.100.1.2 for address family: IPv4 Unicast
We clear the BGP session.
BGP: 10.100.1.2 passive rcv OPEN, version 4, holdtime 180 seconds
BGP: 10.100.1.2 passive rcv OPEN w/ OPTION parameter len: 35
BGP: 10.100.1.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 4
BGP: 10.100.1.2 passive OPEN has CAPABILITY code: 132, length 2
BGP: 10.100.1.2 passive OPEN has TID CAP for: 2
BGP: 10.100.1.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.2 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.2 passive OPEN has MP_EXT CAP for afi/safi: 1/1
BGP: 10.100.1.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 10.100.1.2 passive OPEN has CAPABILITY code: 128, length 0
BGP: 10.100.1.2 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 10.100.1.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 10.100.1.2 passive OPEN has CAPABILITY code: 2, length 0
BGP: 10.100.1.2 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 10.100.1.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 10.100.1.2 passive OPEN has CAPABILITY code: 131, length 1
BGP: 10.100.1.2 passive OPEN has MULTISESSION capability, without grouping
BGP: 10.100.1.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.2 passive OPEN has CAPABILITY code: 65, length 4
BGP: 10.100.1.2 passive OPEN has 4-byte ASN CAP for: 1
BGP: nbr global 10.100.1.2 neighbor does not have IPv4 MDT topology activated
BGP: 10.100.1.2 passive rcvd OPEN w/ remote AS 1, 4-byte remote AS 1
R1#show ip bgp neighbors 10.100.1.2
BGP neighbor is 10.100.1.2, remote AS 1, internal link
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
Multisession Capability: advertised and received
Example of MTR with BGP
Here's an example where MTR is configured for BGP in the network used in this document. Address family IPv4 has three topologies, base, voice and video.
R1#
!
global-address-family ipv4
topology video
!
topology voice
!
iterface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
!
topology ipv4 unicast voice
!
!
topology ipv4 unicast video
!
!
router bgp 1
!
scope global
neighbor 10.100.1.2 remote-as 1
neighbor 10.100.1.2 update-source Loopback0
!
address-family ipv4
!
topology base
neighbor 10.100.1.2 activate
!
topology voice
bgp tid 32
neighbor 10.100.1.2 activate
!
topology video
bgp tid 33
neighbor 10.100.1.2 activate
!
!
!
There is only one address family (IPv4) shared between the pair of BGP speakers, but there are 3 shared topologies. This leads to three BGP sessions.
R2#show bgp ipv4 unicast neighbors
BGP neighbor is 10.100.1.1, remote AS 1, internal link
BGP version 4, remote router ID 10.200.200.1
Session state = Established, up for 00:05:43
Last read 00:00:09, last write 00:00:06, hold time is 180, keepalive interval is 60 seconds
BGP multisession with 3 sessions (3 established), first up for 00:05:43
Neighbor sessions:
3 active, is multisession capable
Session: 10.100.1.1 session 1
Topology IPv4 Unicast
Session: 10.100.1.1 session 2
Topology IPv4 Unicast voice
Session: 10.100.1.1 session 3
Topology IPv4 Unicast video
BGP Multisession without MTR
If MTR is not deployed for BGP, BGP does not have topologies. However, there could still be multiple address families shared between a pair of BGP speakers. Multisession BGP is enabled by default in IOS releases where the MTR feature is present, until CSCsz76118. This can lead to multiple sessions between the the pair of BGP speakers. If there are for example 3 shared address families, then there could be up to a maximum of 3 BGP sessions. This is a maximum, there could be less than 3 sessions. It could be 2 or only 1 session. Let's have a look at the reason behind these different possibilities.
In the following example, MTR is not enabled, and the set of shared address families are IPv4, IPv6 and vpnv4. Depending on the way BGP starts up the address families, there will be 1, 2 or 3 sessions.
R1#
router bgp 1
neighbor 10.100.1.2 remote-as 1
neighbor 10.100.1.2 update-source Loopback0
!
address-family ipv4
neighbor 10.100.1.2 activate
exit-address-family
!
address-family vpnv4
neighbor 10.100.1.2 activate
neighbor 10.100.1.2 send-community extended
exit-address-family
!
address-family ipv6
neighbor 10.100.1.2 activate
exit-address-family
R2#
router bgp 1
neighbor 10.100.1.1 remote-as 1
neighbor 10.100.1.1 update-source Loopback0
!
address-family ipv4
neighbor 10.100.1.1 activate
exit-address-family
!
address-family vpnv4
neighbor 10.100.1.1 activate
neighbor 10.100.1.1 send-community extended
exit-address-family
!
address-family ipv6
neighbor 10.100.1.1 activate
exit-address-family
Possibility 1 : one BGP session
In this example, the configuration for all 3 address families is added on both routers. We then enable the neighbor.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 1
R1(config-router)#no neighbor 10.100.1.2 shutdown
%BGP-5-ADJCHANGE: neighbor 10.100.1.2 Up
R1(config-router)#end
We see that the BGP OPEN message contains all 3 address families. The result is that BGP opens one session, containing all 3 address families. AFI/SAFI 1/1 for IPv4 unicast, AFI/SAFI 2/1 for IPv6 unicast and AFI/SAFI 1/128 for vpnv4.
R2#
BGP: 10.100.1.1 passive open to 10.100.1.2
BGP: ses global 10.100.1.1 (0x461CC60:0) pas Receive OPEN
...
BGP: 10.100.1.1 passive rcv OPEN, version 4, holdtime 180 seconds
BGP: 10.100.1.1 passive rcv OPEN w/ OPTION parameter len: 45
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 1/128
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 2/1
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 1/1
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 128, length 0
BGP: 10.100.1.1 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 2, length 0
BGP: 10.100.1.1 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 131, length 1
BGP: 10.100.1.1 passive OPEN has MULTISESSION capability, without grouping
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 65, length 4
BGP: 10.100.1.1 passive OPEN has 4-byte ASN CAP for: 1
BGP: nbr global 10.100.1.1 neighbor does not have IPv4 MDT topology activated
BGP: 10.100.1.1 passive rcvd OPEN w/ remote AS 1, 4-byte remote AS 1
BGP: ses global 10.100.1.1 (0x461CC60:1) Up
%BGP-5-ADJCHANGE: neighbor 10.100.1.1 Up
R2#show ip bgp neighbors 10.100.1.1 | include session|address family
Neighbor sessions:
1 active, is multisession capable
Multisession Capability: advertised and received
For address family: IPv4 Unicast
Session: 10.100.1.1 session 1
For address family: IPv6 Unicast
Session: 10.100.1.1 session 1
For address family: VPNv4 Unicast
Session: 10.100.1.1 session 1
Last reset 00:01:57, due to Peer closed the session of session 1
Possibility 2 : two BGP sessions
In this example, we start with the neighbor activated in the first 2 address families.
R1#sh run | s bgp
router bgp 1
neighbor 10.100.1.2 remote-as 1
neighbor 10.100.1.2 update-source Loopback0
!
address-family ipv4
neighbor 10.100.1.2 activate
exit-address-family
!
address-family ipv6
neighbor 10.100.1.2 activate
exit-address-family
R2#sh run | s bgp
router bgp 1
neighbor 10.100.1.1 remote-as 1
neighbor 10.100.1.1 update-source Loopback0
!
address-family ipv4
neighbor 10.100.1.1 activate
no auto-summary
exit-address-family
!
address-family vpnv4
neighbor 10.100.1.1 activate
neighbor 10.100.1.1 send-community extended
exit-address-family
!
address-family ipv6
neighbor 10.100.1.1 activate
exit-address-family
R2#show ip bgp neighbors 10.100.1.1 | include session|address family
Neighbor sessions:
1 active, is multisession capable
Multisession Capability: advertised and received
For address family: IPv4 Unicast
Session: 10.100.1.1 session 1
For address family: IPv6 Unicast
Session: 10.100.1.1 session 1
For address family: VPNv4 Unicast
We see that there is one BGP session for the 2 address families IPv4 and IPv6.
We now activate the neighbor in address family vpnv4.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 1
R1(config-router)#address-family vpnv4
R1(config-router-af)#neighbor 10.100.1.2 activate
R1(config-router-af)#end
R2#
BGP: ses global 10.100.1.1 (0x4FC2198:0) pas Receive OPEN
BGP: 10.100.1.1 passive rcv OPEN, version 4, holdtime 180 seconds
BGP: 10.100.1.1 passive rcv OPEN w/ OPTION parameter len: 29
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 1/128
...
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 131, length 1
BGP: 10.100.1.1 passive OPEN has MULTISESSION capability, without grouping
...
BGP: ses global 10.100.1.1 (0x4FC2198:2) Up
R2#
%BGP-5-ADJCHANGE: neighbor 10.100.1.1 session 2 Up
We see that the routers created a second BGP session, carrying address family vpnv4. This new OPEN message only carried AFI/SAFI 1/128. We end up with 2 BGP sessions.
R2#show ip bgp neighbors 10.100.1.1 | include session|address family
BGP multisession with 2 sessions (2 established), first up for 00:03:35
Neighbor sessions:
2 active, is multisession capable
Session: 10.100.1.1 session 1
Session: 10.100.1.1 session 2
Route refresh: advertised and received(new) on session 1, 2
Four-octets ASN Capability: advertised and received on session 1, 2
Multisession Capability: advertised and received
Message statistics for 10.100.1.1 session 1, state Established:
Message statistics for 10.100.1.1 session 2, state Established:
For address family: IPv4 Unicast
Session: 10.100.1.1 session 1
session 1 member
For address family: IPv6 Unicast
Session: 10.100.1.1 session 1
session 1 member
For address family: VPNv4 Unicast
Session: 10.100.1.1 session 2
session 2 member
Possibility 3 : three BGP sessions
In this example, we activate the neighbor in each address family one by one. We start with the following configuration.
R1#sh run | s bgp
router bgp 1
neighbor 10.100.1.2 remote-as 1
neighbor 10.100.1.2 update-source Loopback0
!
address-family ipv4
neighbor 10.100.1.2 activate
exit-address-family
R2#show ip bgp neighbors 10.100.1.1 | include session|address family
Neighbor sessions:
1 active, is multisession capable
Multisession Capability: advertised and received
For address family: IPv4 Unicast
Session: 10.100.1.1 session 1
For address family: IPv6 Unicast
For address family: VPNv4 Unicast
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 1
R1(config-router)#address-family ipv6
R1(config-router-af)# neighbor 10.100.1.2 activate
R1(config-router-af)#end
R2#
BGP: 10.100.1.1 passive open to 10.100.1.2
...
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 2/1
...
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 131, length 1
BGP: 10.100.1.1 passive OPEN has MULTISESSION capability, without grouping
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 65, length 4
BGP: 10.100.1.1 passive OPEN has 4-byte ASN CAP for: 1
BGP: nbr global 10.100.1.1 neighbor does not have IPv4 MDT topology activated
BGP: 10.100.1.1 passive rcvd OPEN w/ remote AS 1, 4-byte remote AS 1
BGP: ses global 10.100.1.1 (0x4FC2198:0) pas Adding topology IPv6 Unicast:base
...
%BGP-5-ADJCHANGE: neighbor 10.100.1.1 session 2 Up
R2#show ip bgp neighbors 10.100.1.1 | include session|address family
BGP multisession with 2 sessions (2 established), first up for 00:01:49
Neighbor sessions:
2 active, is multisession capable
Session: 10.100.1.1 session 1
Session: 10.100.1.1 session 2
Route refresh: advertised and received(new) on session 1, 2
Four-octets ASN Capability: advertised and received on session 1, 2
Multisession Capability: advertised and received
Message statistics for 10.100.1.1 session 1, state Established:
Message statistics for 10.100.1.1 session 2, state Established:
For address family: IPv4 Unicast
Session: 10.100.1.1 session 1
session 1 member
For address family: IPv6 Unicast
Session: 10.100.1.1 session 2
session 2 member
For address family: VPNv4 Unicast
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 1
R1(config-router)# address-family vpnv4
R1(config-router-af)# neighbor 10.100.1.2 activate
R1(config-router-af)#end
R2#
BGP: 10.100.1.1 passive open to 10.100.1.2
...
BGP: ses global 10.100.1.1 (0x3FBFF98:0) pas Receive OPEN
...
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 1/128
...
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 131, length 1
BGP: 10.100.1.1 passive OPEN has MULTISESSION capability, without grouping
...
BGP: 10.100.1.1 passive rcvd OPEN w/ remote AS 1, 4-byte remote AS 1
BGP: ses global 10.100.1.1 (0x3FBFF98:0) pas Adding topology VPNv4 Unicast:base
...
%BGP-5-ADJCHANGE: neighbor 10.100.1.1 session 3 Up
R2#show ip bgp neighbors 10.100.1.1 | include session|address family
BGP multisession with 3 sessions (3 established), first up for 00:02:29
Neighbor sessions:
3 active, is multisession capable
Session: 10.100.1.1 session 1
Session: 10.100.1.1 session 2
Session: 10.100.1.1 session 3
Route refresh: advertised and received(new) on session 1, 2, 3
Four-octets ASN Capability: advertised and received on session 1, 2, 3
Multisession Capability: advertised and received
Message statistics for 10.100.1.1 session 1, state Established:
Message statistics for 10.100.1.1 session 2, state Established:
Message statistics for 10.100.1.1 session 3, state Established:
For address family: IPv4 Unicast
Session: 10.100.1.1 session 1
session 1 member
For address family: IPv6 Unicast
Session: 10.100.1.1 session 2
session 2 member
For address family: VPNv4 Unicast
Session: 10.100.1.1 session 3
session 3 member
We see that there is one BGP session for each of the 3 address families IPv4, IPv6 and vpnv4. However, if you now clear the BGP neighbor, then the OPEN message will contain all address families, leading to one session for all 3 address familes again.
R1#clear ip bgp 10.100.1.2
R2#
BGP: 10.100.1.1 passive open to 10.100.1.2
...
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 1/128
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 2/1
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 1/1
...
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 131, length 1
BGP: 10.100.1.1 passive OPEN has MULTISESSION capability, without grouping
...
BGP: ses global 10.100.1.1 (0x461CC60:0) pas Adding topology IPv4 Unicast:base
BGP: ses global 10.100.1.1 (0x461CC60:0) pas Adding topology IPv6 Unicast:base
BGP: ses global 10.100.1.1 (0x461CC60:0) pas Adding topology VPNv4 Unicast:base
...
%BGP-5-ADJCHANGE: neighbor 10.100.1.1 Up
R2#show ip bgp neighbors 10.100.1.1 | include session|address family
Neighbor sessions:
1 active, is multisession capable
Multisession Capability: advertised and received
For address family: IPv4 Unicast
Session: 10.100.1.1 session 1
For address family: IPv6 Unicast
Session: 10.100.1.1 session 1
For address family: VPNv4 Unicast
Session: 10.100.1.1 session 1
Last reset 00:00:23, due to Peer closed the session of session 3
Multi Session vs Single Session
Multisession BGP is enabled by default in IOS with MTR-capable code, until CSCsz76118. If you want to have strictly one session per address family, then configure "transport multisession" for the BGP neighbor. This will force the OPEN message to contain only one address family. Hence, this will force one session per address family at all times.
R1#sh run | s bgp
router bgp 1
neighbor 10.100.1.2 remote-as 1
neighbor 10.100.1.2 transport multi-session
neighbor 10.100.1.2 update-source Loopback0
!
address-family ipv4
neighbor 10.100.1.2 activate
exit-address-family
!
address-family vpnv4
neighbor 10.100.1.2 activate
neighbor 10.100.1.2 send-community extended
exit-address-family
!
address-family ipv6
neighbor 10.100.1.2 activate
exit-address-family
R2#
BGP: 10.100.1.1 passive open to 10.100.1.2
...
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 1/1
...
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 131, length 1
BGP: 10.100.1.1 passive OPEN has MULTISESSION capability, without grouping
BGP: ses global 10.100.1.1 (0x461CC60:0) pas Adding topology IPv4 Unicast:base
%BGP-5-ADJCHANGE: neighbor 10.100.1.1 Up
BGP: 10.100.1.1 passive open to 10.100.1.2
...
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 passive OPEN has MP_EXT CAP for afi/safi: 2/1
...
BGP: 10.100.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 10.100.1.1 passive OPEN has CAPABILITY code: 131, length 1
BGP: 10.100.1.1 passive OPEN has MULTISESSION capability, without grouping
...
BGP: ses global 10.100.1.1 (0x4FC2198:0) pas Adding topology IPv6 Unicast:base
%BGP-5-ADJCHANGE: neighbor 10.100.1.1 session 2 Up
BGP: 10.100.1.1 active went from Idle to Active
...
BGP: 10.100.1.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.100.1.1 active OPEN has CAPABILITY code: 1, length 4
BGP: 10.100.1.1 active OPEN has MP_EXT CAP for afi/safi: 1/128
...
BGP: 10.100.1.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 3
BGP: 10.100.1.1 active OPEN has CAPABILITY code: 131, length 1
BGP: 10.100.1.1 active OPEN has MULTISESSION capability, without grouping
%BGP-5-ADJCHANGE: neighbor 10.100.1.1 session 3 Up
R2 received 3 separate OPEN messages, each containing one of the 3 address families. Hence, this forces one session per address family.
Hower, if MTR is not used, one can revert back to the old behavior of always having only one BGP session between a pair of BGP speakers by configuring the following command neighbor x.x.x.x transport single-session under router bgp.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 1
R1(config-router)# neighbor 10.100.1.2 transport single-session
R1(config-router)#end
R1#show ip bgp neighbors 10.100.1.2 | include session|address family
Neighbor sessions:
1 active, is multisession capable (disabled)
Multisession Capability: and received
For address family: IPv4 Unicast
For address family: IPv6 Unicast
For address family: VPNv4 Unicast
Last reset 00:00:51, due to Capability changed of session 3
Benefits of Multisession BGP
Multisession BGP allows more granularity in managing BGP.
In one of the previous examples we saw one benefit of multisession BGP, namely that address families can be added incrementally to a pair of BGP speakers, without having BGP to reset completely between the pair of speakers and therefore resetting all the address families.
When address families are each on a separate TCP session, one can have the opportunity to reset only one TCP session and hence only one address family between a pair of BGP speakers without interrupting the other address families.
Also, if BGP receives a malformed update, it needs to reset the session. In the case of one session per address family, then only the session for the address family where the malformed update was seen, needs to be reset. At the same time, the other sessions are left intact.
In the last example, there were 3 BGP sessions, hence 3 TCP sessions, between the pair of BGP speakers.
R2#show tcp brief
TCB Local Address Foreign Address (state)
04FA2BB0 10.100.1.2.179 10.100.1.1.19690 ESTAB
049AFD98 10.100.1.2.37284 10.100.1.1.179 ESTAB
03FBF968 10.100.1.2.179 10.100.1.1.56475 ESTAB
TCP port 179 is the port used by BGP. So, these 3 TCP sessions are BGP sessions. Let's have a look at one of them.
R2#show tcp tcb 04FA2BB0
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled
Mininum incoming TTL 0, Outgoing TTL 255
Local host: 10.100.1.2, Local port: 179
Foreign host: 10.100.1.1, Foreign port: 19690
Connection tableid (VRF): 0
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x839E68):
Timer Starts Wakeups Next
Retrans 4 0 0x0
TimeWait 0 0 0x0
AckHold 3 1 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
iss: 3729262629 snduna: 3729262774 sndnxt: 3729262774 sndwnd: 16240
irs: 4070011050 rcvnxt: 4070011195 rcvwnd: 16240 delrcvwnd: 144
SRTT: 124 ms, RTTO: 1405 ms, RTV: 1281 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle, path mtu capable
Datagrams (max data segment is 1460 bytes):
Rcvd: 9 (out of order: 0), with data: 5, total data bytes: 144
Sent: 7 (retransmit: 0 fastretransmit: 0),with data: 5, total data bytes: 144
One could clear only one of these TCP sessions.
R2#clear tcp tcb 04FA2BB0
[confirm]
[OK]
%BGP-5-ADJCHANGE: neighbor 10.100.1.1 session 2 Up
R2#show tcp brief
TCB Local Address Foreign Address (state)
049AFD98 10.100.1.2.37284 10.100.1.1.179 ESTAB
03FBF968 10.100.1.2.179 10.100.1.1.56475 ESTAB
04FA2BB0 10.100.1.2.59982 10.100.1.1.179 ESTAB
We see that one TCP session/BGP session re-established.
New behavior
In later IOS code -code with CSCsz76118- the default behavior is to use single-session. You'll get multi-session only when explicitely configuring "transport multi-session".
The command neighbor x.x.x.x transport single-session will get removed/obsoleted gradually.It will be hidden first (by CSCtn66618) and then removed in a later IOS release.
Conclusion:
IOS without MTR feature
A pair of BGP speakers always have one TCP session between them.
IOS with MTR feature, before CSCsz76118
When multi-session is configured, we have one session for each shared address family.
When single-session is configured, there is always only one session.
When in the default mode (no transport session command), there could be one or multiple sessions, depending on the conditions described above.
IOS after CSCsz76118
By default, the transport mode is single-session, hence there is one session.
When multisession is configured, we have one session for each shared address family.
