Is there any calculations, formulas etc that can be used to "size" your router to the amount of traffic you anticipate running through it?
We have a router running at or near 100% under full load and are planning to upgrade it but would like to accurately as possible, predict what we need to handle what we are doing and then allow for growth.
Figuring out what router is necessary for a given bandwidth requirement is hard because Cisco doesn't publish the maximum bandwidth potential of their routers. The only performance metric they tend to give is packets-per-second forwarding capability with 64-byte packets. This does little to help answer the question "how much bandwidth can a given router route" because the average packet size in any real network is (almost) always going to be significantly above 64 bytes, and the packets-per-second capability of any given router tends to drop substantially as packet size increases.
So as end users we're essentially left to performing our own bandwidth tests on our routers and sharing the results. We can then make some approximate guesses at the peformance of other routers based on their pps ratings relative to the pps ratings of routers that we have tested. But these are only estimations and when it comes down to it you can't know for sure what bandwidth a given router is capable of acheiving until you test it.
Two quick examples (and if you give some more details about your bandwidth requirements we may be able to help further):
The Cisco 2621 is rated at 25k pps, which comes to about 12.5Mbps with 64 byte packets. Per my own testing, the 2621 is capable of around 40Mbps with full-sized (1500 byte) Ethernet packets. The 3620, rated at 20-40k pps (10-20Mbps) can do around 75Mbps or so per testing done by someone other than me.
So it gets to the point where you can look at a given router's pps rating and maybe hopefully be able to kinda ballpark the bandwidth potential. But it's far from an exact science, and the "bandwidth capability with full-sized packets" numbers aren't the most useful thing in the world anyway since very few routers have only full-sized packets going through them. And it gets even more complicated when throughput-reducing features like ACLs need to be taken into account. (The tests above were done with no such features enabled. CEF was enabled.)
So, there are all these things to consider and for the most part it's all just guesswork. But it's about the best you can do unless you're fortunate enough to be able to get a loaner or two beforehand, configure them as they would be configured on your network, and test their bandwidth capability with traffic streams that roughly match the traffic that is currently flowing (and/or what you're expecting to be flowing in the future) through your network.
Thanks alot. This was very helpful. I guess estimated baselines are better than nothing. In my case, I can already see by the numbers you furnished that we are far excedding our current routers capabilities.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...