Best thing you can do is not estimate, but actually test.
Source identical server that your production RRs are running at for LAB
purposes, run the CSR1000v on it and perform scaling testing to a breakpoint
with some opensource route generator.
That will give you an idea of how much headroom you have with the numbers you
quoted above. (e.g. if it breaks at 20M prefixes you might set yourself a
conservative limit of 10M)
You can also carry out performance testing with the same setup to, for example,
get an idea of how long would your RR take to establish sessions to say 20
clients and pump 3M prefixes to each, etc...
Tests like these will give you real life expectations for the performance of
your production RRs setup.
With a lab setup like this you can then test effects of adding new
features/AFs/or update groups.
RRs is a critical piece of infrastructure and an absolute must have in a lab
setup, so one can test changes to the setup in a safe environment prior to
rolling these into production.
In my experience estimating is useless, each setup is unique, heck even had to
do some fine tuning of lab setup to replicate some specific scaling problems in
production.
adam
Thank you, Adam!
I agree that lab testing would be a good move. Actually I was thinking
about spinning up test topology in AWS, they have CSR1000v, XR9000v and
other machines in AWS Marketplace.
However, this way I won't be comparing apples to apples, because of
differences in underlying hardware.
Is there any particular open source route generator you had in mind? Exabgp?
Kind regards,
Marcin
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
