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 <[email protected]> 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:[email protected]] 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
