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/
