Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

BGP Multisession

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.

Figure1.jpg

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.

Figure2.jpg


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.

Version history
Revision #:
1 of 1
Last update:
‎03-16-2011 07:11 AM
Updated by:
 
Labels (1)
Everyone's tags (2)