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/
