Anyone know any documents that mentioned the maximum WAN throughput of 3845?
From the MIERCOM Lab Testing in 2006, the maximum WAN throughput is 50Mbps (with additional processor capacity to spare) but this is by putting the router in a "stress test" by virtually enabling all its features/services and modules.
In my case, I'm only running OSPF and BGP (full internet route from 3 carriers) and I'm not using any EtherSwitch Module (or installed).
The maximum throughput for this platform (Fast/CEF switched) is 500,000pps (256Mbps) using 64Byte packets. That's the "never-to-exceed" value, so the real value will be somewhat less.
In my experience it can easily handle an OC-3 with no problems, but it depends on the services.
Thank you for your quick reply.
I see that throughput from the router performance table. I look at it as backplane performance (not actually WAN/LAN bandwidth throughput).
I'm looking into putting a GE (MetroE Service) for Internet Link, I would like to know the maximum WAN bandwidth throughput before I start experiencing performance degradation.
I doubt the 3845 is up substaining gig thoughput. The product performance sheet I've attached (found within these forums), has the bandwidth performance as 256 Mbps.
If you need do need to use higher end routers, and if you're moving to pure MetroE, you might also want to look at the various metro switches.
Thanks for your reply.
If what you are saying that the 256Mbps Switching/Forwarding Rate equates to bandwidth performance/troughput (total for all interfaces that can possibly load in the router) why have GE interfaces and why have Switching Modules then?
I load test the two integrated GE interface in Full-duplex in LAN/Backup environment and I hit 320Mbps+ both ways without experiencing packet drops while the CPU remains below 10% using ADV ENT IOS.
Q. What is the maximum throughput on the Gigabit Ethernet HWIC?
A. The HWIC bus interface is limited to 400 Mbps of full duplex. The actual throughput of the Gigabit Ethernet HWIC is limited by the throughput of individual platforms. Under bidirectional traffic of 1518 bytes or larger, the Gigabit Ethernet HWIC can support up to an aggregate of 350 Mbps on Cisco 2811 and 2821 routers, 400 Mbps on Cisco 2851 routers, and 500 Mbps on Cisco 3800 Series platforms.
The above is for the HWIC, the NM and the integrated GE sure has a different throughput.
My understanding, the bandwidth should be the total throughput capacity of the box. What's not clear is whether it's limited based on the pps rate, or whether effective bandwidth varies based on the packet's size, or some hardware limitation such as a bus capacity, or some other combination.
Why have Gig interface and switching modules? Well often other features make them attractive as for instance the better implementation of auto negotiation on gig vs. 100 Mbps. A gig interface should send/receive the bits of a packet at gig speed, different question whether the router's other components can sustain the rate for multiple packets. The limitation of bandwidth of the various Ethernet modules, I believe, don't pertain to some modules that can L2 switch on the module itself.
For your performance test, what was the packet size? (I had thought to suggest a gig to gig performance test, but wasn't sure what Ethernet interfaces came standard.)
Hi, having done quite a bit of perf. test while at cisco, let me give you some "insight".
If you look at the famous router performance sheet, you find that for all the ISR router at least, the throughput figure is probably
calculated and not measured.
What they did, is to take the max pps value (that should be measured with the smaller 64 bytes packets), multiplied by 512, and got the figure.
That doesn't mean that it is the maximum throughput of the box, but it is an indication of what you can expect as a rule of thing in a typical environment.
So, it's quite possible to have the 320+ mbps that Medan has observed, using a larger packet size.
A correct, complete measurement do specify the packet size used for all test, do specify is the tests are are mono or bi-directional, and across two or more interfaces. And possibly graphs showing the correlation between factors! All these things are clearly outside the scope of the leaflet.
One last think I would like to say about the applicability of routers to MetroE services.
MetroE doesn't necessarily mean gigabit or even fastethernet. In many cases we have services contractually limited to 10 or even 5 mbps. So if you have a fast router, you can surely handle some fast-ethernet voulem of traffic.
Paolo good points.
What's your thoughts on how much weight should be given to Cisco's noting a 3845 is suitable for T3 line rates with services, e.g.: http://www.cisco.com/en/US/products/ps5855/prod_models_comparison.html?
Agree about the difficulty of truly benchmarking a router's performance capacity, so what are your thoughts about how much weight should be given to a 3rd party report such as the Miercom report as noted in Danilo's original post?
Also agree that MetroE often is often contracted for service rate less that line rate but what are your thoughts on whether the device should be sized to handle the possible growth to line rate within what timeframe?
Another thing to add, cisco doesn't like to release hard numbers about performances. The leaflet we continuously reference, was supposed to be "cisco confidential" for partners only. Now it has leaked out, thing that ultimately is probably good too.
Why is that, one reason is that is not wanted to give competition an easy target for a marketing attack.
Another reason, it is not wanted to have customers to design on paper numbers, instead the idea is that an experienced pre-sale person do suggest the right box for each application (and budget). An AM/SE job, not AM or SE alone if you get what I mean.
Then about the possible growth, that is a reasonable approach to try to buy a bigger box, but it doesn't work all the time. Ultimately, if budget doesn't allow that, you will have to deal with the "bandwidth growth" when and if it happens.
About the third-party reports. Without even entering the the discussion if these are to be trusted or not, just consider them collateral marketing. One technical person can decide even without them. I mean, Miercom tells us that it works as advertised, sometime they mention that they needed Cisco's intervention to make so. Nothing new in that.
Paulo, thank you.
Dandy, looks like it's difficult to determine just one maximum bandwidth performance number for your 3845. The proverbial "your milage may vary" seems to apply here too.
Doubt your at too much risk trying your 3845 with the Gig MetroE. As Paulo also notes, you can always deal with bandwidth growth when and if it happens.
One reason I mentioned the metro series swithes, their feature sets for Ethernet WAN ports are often a bit WAN richer than an ordinary LAN switch's Ethernet LAN ports.
I think Cisco is playing safe by not putting the hard numbers in the table. The wire speed throughput T3/E3 full-duplex is the safest in case some jokers turn ON most of the services or those resource hungry services :)
In my testing I only turn on BGP with full internet route from three ISPs plus OSPF and CEF enabled with no other services running in the router like IPSec VPN, the only ACL are the bogons - pretty much boring but I like my core routers and distribution switches to perform routing and switching as fast as possible. I use 1500B packets for testing bidirectional UDP between two Linux hosts directly connected to two on-board GE interfaces using opensource traffic generator, Cricket to monitor the router performance (CPU, RAM, INTERFACE IN/OUT OCTETS and ERRORS), I'm planning to try other combinations but no time to perform testing futher.
I post this query when my numbers doesn't add up with Cisco's and Benchmarking numbers plus I read some documents about positioning 3845 as MetroE customer premise equipment, NM and HWICS bandwidth throughput, I think I even read documents mentioned higher throughput in L2 if no other services are turned ON.
Thanks Joseph for keeping this post active and your views :) and Paulo as always "well said" and thanks.