packet drop when using srr-queue bandwidth limit command in Catalyst 3750

syip · ‎07-18-2005

I experience unexpected packet drop after using the srr-queue bandwidth limit command on a fastethernet interface in Catalyst 3750.

Here is part of the configuration:

mls qos

interface FastEthernet1/0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 80-82,90-92

switchport mode trunk

switchport nonegotiate

duplex full

speed 100

srr-queue bandwidth limit 60

FastEthernet1/0/1 is the link via my service provider to my remote site. The service provided is 100Mbps access link with a 60Mbps CIR. I tested the link before I use the srr-queue bandwidth limit command and verified that I can send up to 60Mbps across the link to my remote site. After I put in the command, I started testing by sending 5Mbps of data and saw only about 3Mbps reaching the remote site. Then I sent 10Mbps of data and only seeing about 6Mbps. I checked the interface statistics and found data drop with the switch 3750 - 5 minute output rate of fa1/0/1 was only about 60% of the 5 minute input rate of the interface connected to my packet generator.

Here is the show version output:

Cisco IOS Software, C3750 Software (C3750-IPSERVICESK9-M), Version 12.2(25)SEB2, RELEASE SOFTWARE (fc1)

Compiled Wed 08-Jun-05 04:49 by yenanh

ROM: Bootstrap program is C3750 boot loader

BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.1(14r)EA1a, RELEASE SOFTWARE (fc1)

nc-ced uptime is 2 hours, 29 minutes

System returned to ROM by power-on

System restarted at 10:59:57 MDT Fri Jul 15 2005

System image file is "flash:c3750-ipservicesk9-mz.122-25.SEB2/c3750-ipservicesk9-mz.122-25.SEB2.bin"

This product contains cryptographic features and is subject to United

States and local country laws governing import, export, transfer and

use. Delivery of Cisco cryptographic products does not imply

third-party authority to import, export, distribute or use encryption.

Importers, exporters, distributors and users are responsible for

compliance with U.S. and local country laws. By using this product you

agree to comply with applicable laws and regulations. If you are unable

to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to

export@cisco.com.

*****

Is there any success in using the srr-queue bandwidth limit command by anyone? The command is supposed to shape traffic to the specified limit e.g. srr-queue bandwidth limit 80 used for a 1000Mbps link is supposed to shape the traffic to a maximum 800Mbps and buffer excess traffic if possible.

s-doyle · ‎07-22-2005

This is a known issue. Is "mls Qos" enabled on the device. if so try disabling this command and check if the packet drops are happening. This is the only workaround available.

tmoffett · ‎10-04-2005

Can anyone else validate this? I haven't seen anything in the TAC Case Collection regarding this...

johgill · ‎10-10-2005

Hello Tim,

There are actually two issues at play that we need to understand.

1.) what enabling QoS on any catalyst switch does

2.) the operation of srr-queue bandwidth limit

[1]To address the first issue, we have to understand that a switch does not operate at all like a router in its QoS capabilities. Since MLS operations in a switch are done in hardware, there are certain capabilities and methods of implementing features that differ from software routers.

QoS on a switch by default will take the port buffers and carve them up into different "queues". These queues are of a finite space but are adjustable. By default, these settings may not be appropriate for your traffic class mix. As far as the 3750 having a known issue with enabling "mls qos", that is a bit misleading. While there is a bug opened to change the default settings for the queue thresholds, this is easily changed in the configuration. The bug id is: CSCeg29704. Basically Q1 gets 25% of queue space (which is normal) when qos is enabled, but the default traffic is set to use threshold 1 (which is at 50% of queue 1) and queue 1 is actually in shaped mode as far as bandwidth. This means it cannot exceed the "srr-queue bandwidth" setting and is usually pretty noticeable without a distributed range of traffic classes.

[2] "srr-queue bandwidth limit" is actually not the same as a shaper or policer, but it is similar. This command will literally make the transmit port idle for a percentage of the time. It is not used to guarantee a certain amount of bandwidth, rather it is used to scale down the total time that can be used to transmit traffic. Its operation varies based on what QoS settings you have in place at the time. Basically you would use this command to limit bandwidth if you know your traffic is at level X and you needed to reduce it by a certain amount. srr-queue bandwidth limit Y gives you (100-y)% of rate X. This number should coincide with the speed of the next device for which you are throttling this traffic.

This enables us to reduce traffic but unlike a policer or shaper, we drop lower priority traffic first. We know we drop lower priority traffic first because it is basically shutting down the transmit side of that port for a period of time. When this happens, traffic is queued up and lower priority traffic drops first. When the port transmits again, the higher priority traffic starts transmitting again. With policers, we simply look at a bitrate and ignore precedence values.

Needless to say, this is expected behavior and is unrelated to the bug that another user mentioned. The defaults have been changed as of 12.2(25)SEB for that bug I mentioned.