Share:

Replies

According to a router performance doc from Cisco the 262x may get up to 12 Mbps. These figures are based on 64 byte packets when no services are configured and all traffic is CEF switched. The throughput drops to less than 1 Mbps when traffic is process switched. Depending on your traffic (and FTP should be sending maximum size packets) and how the router is configured your performance would be different. And given your observation that router CPU goes to 99% it strongly suggests that something is configured that is making the router do something that is impacting performance.

I am not clear in your post whether the switch ports where the servers are connected are in the same VLAN or whether you configured separate VLANs for them.

If all it were doing were forwarding the traffic and only using CEF I would certainly not expect the CPU to go that high. The high CPU suggests that the router is doing something other than just CEF forwarding packets. Is there any possibility that it is logging anything about the traffic? Is there any possibility that it is having to fragment packets?

Thanks for posting config information. That certainly seems to indicate that logging is not an issue. I do not know why it would need to fragment or do anything to the packets but I am wondering what would drive CPU so high. I wonder if you would clear the counters, run a transfer and check the number of packets in on each interface against the number of packets out on the other interface?

When you are doing these transfers and you look at those 100 meg router uplinks are they pretty much buried ? You also have to remember you have gigabit nics and you are trying to shove all that information up a 100 meg pipe , so I calculate at best you would get maybe 12 megabytes per second transfer with overhead . In your first post are you talking bits or bytes ????

My understanding is, as packet size increases, and with a constant PPS rate, effective transfer bandwidth should increase. The increase isn't exactly linear, but the table I provided in a prior post (from Cisco) has the required PPS rates to obtain Ethernet gig line rates for different packet sizes. (You can scale it divide by 10 for fast Ethernet.)

Personally tested, no. Nor could I guarantee, nor do I actually know, a 2621 will maintain its PPS rate regardless of actual packet size. However, effective bandwidth usually jumps with increased packet size.

PPS for 64 byte packets are often quoted since for IP it normally represents the worst case to provide line rate. (For 100 Mbps Ethernet, for 64 byte sized packets, requires about 148,809 PPS; 1500 byes size packets only require about 8,100 PPS.)

What's interesting in table 1 and table 2, we do see the actual PPS rate fall with increased packet sizes, but the necessary PPS often decreases even more. So, the graphs show a higher percentage of theoretical line rate being achieved as packet size increases. (Your mileage, err bandwidth, might vary.)

You are basing this argument on the 7500 with a VIP? LOL - talk about comparing apples and apples.

The bottom line is this, we've circulated the routerperformance document many times. No need to repost it. There are numbers published on such document and the values that were used to come up with those numbers.

On a regular router 2621 (No VIP, No Layer3 Distributed Switching), you get a maximum of 12.80Mbps based on 25k PPS * 64Byte Size.

I don't disagree about the math on how the reference sheet you refer to arrives at 12 Mbps for the 2621 for fast path switching. Nor do I know anything beyond the sheet's 25 Kpps rating for a 2621's fast path switching; except for the much, much lower rating for process switching.

I wasn't directly comparing a 2621 against a 7500, either. What I was arguing was effective bandwidth normally improves as packet size increases (if for no other reason the improved ratio between actual payload vs. packet/frame overhead). What the 7500 VIP document showed was both the reduced PPS requirements to obtain line rate as packet sizes increases and one example such impact to a particular piece of hardware makes.

I see David did try your suggestion to decrease packet size to 64 bytes and saw a 5:1 performance reduction. Although, I wouldn't be able to predict whether there would be any reduction, from my argument, I'm not surprised there was. I would have been surprised if there was an improvement.

"It is sending broadcast WINS and other chatty Microsoft protocols. That should NOT have any effect on the router."

Well, from the link both I and Glen provided contains under:

IP Input

Traffic that cannot be interrupt-switched arrives

Broadcast traffic

Check the number of broadcast packets in the show interfaces command output. If you compare the amount of broadcasts to the total amount of packets that were received on the interface, you can gain an idea of whether there is an overhead of broadcasts. If there is a LAN with several switches connected to the router, then this can indicate a problem with Spanning Tree.

So, uncertain it wouldn't have any effect on the router. (What's the CPU load on the router when there is no transfer?)

Yes, it's normal. I was trying to have an exact match on packet size per the routeperformance document. The test was done on 64 Bytes and the 2621 spec was 12Mbps with CEF enabled - FastEthernet to FastEthernet.