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:[email protected]] 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 <[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/
