[c-nsp] behavior of BGP when new address families are enabled (BGP dynamic capability)

[Tassos Chatzithomaoglou]

And an interesting doc about BGP Multisession.

https://supportforums.cisco.com/docs/DOC-15725

--
Tassos

Tassos Chatzithomaoglou wrote on 09/08/2013 15:39:
> Having a BGP session with multisession capability enabled between 7200s (SRE6), brought up automatically another BGP session when the new address family got configured.
>
> BGP neighbor is x.x.x.x,  vrf TEST-VRF,  remote AS 65121, external link
>   BGP version 4, remote router ID x.x.x.x
>   Session state = Established, up for 30w3d
>   Last read 00:00:39, last write 00:00:02, hold time is 180, keepalive interval is 60 seconds
>   BGP multisession with 2 sessions (2 established), first up for 30w3d
>   Neighbor sessions:
>     2 active, is multisession capable
>   Neighbor capabilities:
>     Route refresh: advertised and received(new) on session 1, 2
>     Four-octets ASN Capability: advertised and received on session 1, 2
>     Address family IPv4 Unicast: advertised and received
>     Address family IPv6 Unicast: advertised and received
>     Multisession Capability: advertised and received
> ...
>  For address family: VPNv4 Unicast
>   Translates address family IPv4 Unicast for VRF TEST-VRF
>   Session: x.x.x.x session 1
> ....
>  For address family: VPNv6 Unicast
>   Translates address family IPv6 Unicast for VRF TEST-VRF
>   Session: x.x.x.x session 2
>
>
> Interesting...but also a little bit confusing....
>
> --
> Tassos
>
> Adam Vitkovsky wrote on 08/08/2013 17:14:
>> There's a 'suppress capability' knob in XR, but unfortunately only for
>> 4-byte-asn. 
>> You can try 'transport multi-session' in IOS, but I can't find it in XR. 
>>
>> adam
>> -----Original Message-----
>> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
>> Tassos Chatzithomaoglou
>> Sent: Thursday, August 08, 2013 3:07 PM
>> To: Nick Hilliard
>> Cc: cisco-nsp
>> Subject: Re: [c-nsp] behavior of BGP when new address families are enabled
>> (BGP dynamic capability)
>>
>> Nick, that's what also i'm doing in case of dual RRs. But, as you say, it's
>> pain in the a**.
>> I was hoping for at least a simple knob like "activate-on-reset" which would
>> enable this and similar capabilities only after the BGP session was reset
>> (for whatever reason).
>> Then i could pre-configure all sessions with the new address families and
>> just do a bgp reset on the RRs to activate them.
>>
>> Nick Hilliard wrote on 08/08/2013 15:49:
>>> On 08/08/2013 13:36, Tassos Chatzithomaoglou wrote:
>>>> Can anyone provide any inside info what we should expect in this area?
>>> broadly speaking, you need to plan on lots of bgp session resets.  As 
>>> you note there is no option in the bgp protocol at the moment to 
>>> renegotiate capabilities after session startup.  So each side would 
>>> need to be aware of all future AFIs that you would want to run on each
>> session.
>>> In practice, I've been handling this recently having a preexisting 
>>> configuration which uses multiple RRs for each client bgp speaker.  
>>> This means that you can upgrade one RR to supporting the new afi / 
>>> capability, then upgrade each session, one by one, then when 
>>> everything is configured up on the migrated RR, you can shift the 
>>> other side over.  This is very messy though.  It means that you need 
>>> to disentangle the peer-group configurations for each RR session, and 
>>> then reconfigure them once the work is done.  So while it can be done 
>>> hitlessly (and in many cases scriptably) with some planning, it's still a
>> pain.
>>> Nick
>>>
>>>
>>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>