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

[Adam Vitkovsky]

Well "multi-instance BGP" is basically running multiple separate "complete
BGP process suites" on a single RP or on multiple DRPs. 
Not to be mistaken with "distributed BGP" where only "BGP speaker process"
could be distributed among multiple DRPs. 
I believe the multi-instance BGP was created mainly to cope with the 4G
limit per process in 32bit XR. 
It has to be configured manually via cmd: router bgp 123 instance
<instance_name>. 
And XR should respond back that it's starting a separate process. 
IPv4 AFs have to be configured under one instance same applies for IPv6 AFs
and Multicast related AFs, VPNv4 and VPNv6 AFs can appear in multiple
instances. 

So I guess the equivalent of IOS multi-session where a separate TCP session
is created for each AF is nonexistent in XR. 


adam
-----Original Message-----
From: Jason Lixfeld [mailto:jason at lixfeld.ca] 
Sent: Friday, August 09, 2013 12:37 AM
To: Adam Vitkovsky
Cc: 'Tassos Chatzithomaoglou'; 'Nick Hilliard'; 'cisco-nsp'
Subject: Re: [c-nsp] behavior of BGP when new address families are enabled
(BGP dynamic capability)

I went through this a few months back.

XR has had something called multi-instance BGP since 4.2. I'm not sure if
it's enabled by default or in conjunction with nsr and/or graceful-restart.
It seems to works just like multi-session BGP in IOS, but it's not the same.
The two do not interoperate.  If one enables multi-session in IOS and
multi-instance in XR, the session will never establish.  It won't even try
to fall back to single session.

With multi-instance, you can add AFs with no adverse effects to existing
sessions in any other AF.

On 2013-08-08, at 10:14 AM, Adam Vitkovsky <adam.vitkovsky at swan.sk> wrote:

> 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/