On Fri, 29 Mar 2019 at 08:03, Leigh Harrison <[email protected]> wrote: > > Morning all, > > Update to the below. We’ve been talking to the engineering teams at Cisco and > the limitations are soft limitations that are being slowly raised per > software release after exhaustive testing. > > The current limit of unique QoS policies per box that were running into, > which is 64 per NPU, so 128 in total is set to rise to 256 in the next > software release, which makes it far more relevant for the density of the box. > > I’ll keep you all posted as to how we get on. Currently, they seem like a > great box at a great price, but they have some design constraints to bear in > mind. > > Best, Leigh
Hi Leigh, Having worked with Cisco ASR9Ks a lot, line card / NPU scaling limits is something I have now gotten into the habit of always checking with Cisco. > Update to the below. We’ve been talking to the engineering teams at Cisco and > the limitations are soft limitations that are being slowly raised per > software release after exhaustive testing. I guess the only problem with this is that you’ll have to be on bleeding edge code to get the feature-bump or apply SMUs (yuk!). When you say 64 per NPU, at what level does it apply? For example; certain ASR9K cards will have a limit on the number of port level policies you can apply, lets say its 64, but you can apply hundreds of child and grandchild level policies. This means that if you have <64 physical interfaces everything is fine (rather than applying a policy to every sub-interface you apply a 2/3/4 level policy to the physical interface). Is this the best idea ever? Maybe not, but if it is the difference between QoS and no QoS and you need (read: "have sold") QoS then that's what we have to do. I don't know the fixed chassis NCS5Ks that well, only used the 5001s and modular chassis but, if you ask your Cisco SE or equivalent, they have NDA stats they can share with you about all manner of scaling limits. In the case of my ASR9K experiences they were definitely worth reading. I have discovered limits that were unexpectedly close to what we were planning to use. Some of them so close, i.e. we planned to use 1900 instances of feature ‘x’ and it turns out the NPUs only supports 2000, which is just %5 difference, it’s actually worth my time scale testing that feature in the lab because, NPUs are PPS bound flexible performance pipelines and not ASIC + features-in-TCAM fixed performance pipelines. > I’ll keep you all posted as to how we get on. Currently, they seem like a > great box at a great price, but they have some design constraints to bear in > mind. Good luck with your testing and keep us posted! Cheers, James.
