On 11/10/21 20:00, Tom Hill wrote:
I may live to regret asking this, but... I've run a lot more than that on a 9001, and it handled it all with aplomb. They're not as fast as an RSP440 (or RSP880) but in no way did I find them to be liabilities when running alongside measurably faster routers in the same ASN. They were extremely competent, in fact. So how are you measuring this, and/or how is the issue manifesting?
At various peering locations where the ASR9001 had been running for some years, it was starting to struggle to manage several hundred sessions (none of which were a full table). The router kept sending too many Refresh notices to neighbors, across a number of versions of IOS XR code. Cisco couldn't figure it out, and we kept losing sessions due to the nuisance we'd become across the exchange fabric. What was clear was that the issue kept growing as peers increased routes, or as we added neighbors.
In applications where we had just 2x full BGP sessions, IS-IS would hang and blackhole traffic. The issue was hard to reproduce, but every time it happened, we knew that rebooting the router was the only solution. We still see this issue in the few nodes we have running. The good news it does not happen often, but also, it shouldn't.
Is the ASR9001 CPU as slow as the MX80? I would say no, but considering it's the only non-x86 box we have, the performance delta of the control and management plane is visible.
Mark. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
