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

[Adam Vitkovsky]

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/