Sorry,
The rate-limit statement that results in 0.2mbps throughput is:
rate-limit input 10000000 5000 5000 conform-action transmit
exceed-action drop
-------- Original Message --------
Subject: TCP behavior under strict CAR rate-limiting
Date: Thu, 19 Jun 2008 08:11:36 -0700
From: Christopher Hunt <[EMAIL PROTECTED]>
Organization: ReachONE Internet Inc.
To: cisco-nsp@puck.nether.net
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
--
Christopher Hunt
ReachONE Internet, Inc.
(888)820-7559
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
