Hello Gert, On Thu, 11 Nov 2021 at 08:18, Gert Doering <[email protected]> wrote: > > Hi, > > On Thu, Nov 11, 2021 at 08:27:44AM +0200, Mark Tinka wrote: > > We have nothing against the forwarding performance of the ASR9001. It's > > the control/management plane that seems to be slowing down (at least for > > us, anyway) with newer code and a growing Internet DFZ. > > "newer code" might be the key issue here - what version are you on? > > Our 9001 have been extremely well-behaved in regards to BGP performance > and robustness. Not as fast as the RSP440, but still well up to the > job. > > We're on 6.5.3 ("nothing interesting in newer versions, and still > supported").
When I tested RTR on IOS-XR I hit some strange bugs in the RTR client, specifically the RTR session would hang in certain scenarios (router restart, RTR server reboot, etc), requiring manual intervention with a "clear bgp rpki-server 1.2.3.4". It was *a lot* better in more recent releases, but 6.5.3 was not part of those better releases. I still did not have a lot of trust in XR for this reason, so I wrote a NETCONF script that would make some sanity checks on the RTR session state on XR boxes (nagios friendly): https://gist.github.com/lukastribus/695c9e780d118755271519d4d3cb54f3 (minimum number of absolute v4 and v6 VRPs on each RTR server, maximum v4/v6 VRP deviation between the RTR servers, RTR servers not in "connected" state). cheers, lukas _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
