Oli,
Well spotted! ughhh.. the rate-limit statement that results in the
0.2mbps throughput is :
rate-limit
input 10000000 5000 5000 conform-action transmit exceed-action drop
Thanks,
Christopher Hunt
Oliver Boehmer (oboehmer) wrote:
Christopher,
in your email, both rate-limit statements are identical, but you said
one works while the other one doesn't? doesn't make sense to me? ;-)
copy&paste error?
oli
Christopher Hunt <> wrote on Thursday, June 19, 2008 5:12 PM:
Please excuse me if this is off-topic. I'm needing some expert TCP
analysis and not sure where to turn. I'm experimenting with CAR
rate-limiting using the Cisco IOS. I am using Iperf to test TCP
throughput, PRTG to poll the Cisco interface traffic levels each
second and Wireshark to capture the packets. This is a lab, so there
are no public IPs in use. Using the rate-limit statement
"rate-limit input 10000000 1875000 3750000 conform-action transmit
exceed-action drop" I see expected behavior, that is an average of
10mbps with bursts up to ~18mbps.
Using the rate-limit statement "rate-limit input 10000000 1875000
3750000 conform-action transmit exceed-action drop" I see an average
of
0.02mbps (200 bits/second) with no bursting at all.
I expected that the cause would be excessive drops by the Cisco
interface causing the TCPs on either end to negotiate a low
tcp_receive_window, but the packets don't bear that out. The window
sizes are staying high. The cisco interface doesn't show many drops
nor does it ever seem to receive the 10mbps rate, even for a second.
I expect that even retransmits, duplicate ACKS etc. would increment
packet counters on the Cisco.Any ideas what else could cause low
throughput besides a low tcp_receive_window?
--
Christopher Hunt
_______________________________________________
cisco-nsp mailing list cisco-nsp@xxxxxxxxxxxxxxx
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
|
