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