Re: How do I limit the bandwidth on a Cisco 3550 switch?
A few comments that might help...
1) You have created an aggregate policer and applied the same policer both inbound an outbound. I believe that this means (for example) that you will share the 3Mbps rate for the in and out traffic combined, you will not get 3Mpps in and 3Mbps out. If you want to do that, try to use a separate policer inbound and outbound (ie create a separate aggregate policer & policy map with a different name for the in and out direction)
2) How are you measuring the rates in/out of the interfaces? Are you sure that you have 2 or 3 Mbps in/out even without the policer applied?
To monitor whether the policer is truely dropping traffic and how much on the 3550 you can configure the “mls qos monitor dscpdscp1 ... dscp8” interface configuration command under the interface of interest, and then you can use the “show mls qos interfaceinterface-idstatistics” privileged EXEC command. For example in the following example I had a very aggressive 48k policer applied inbound to an interface while sending wire rate GE traffic via a traffic generator. As a result almost all the traffic was dropped by the policer... interface GigabitEthernet0/12 switchport trunk encapsulation dot1q switchport mode trunk flowcontrol send off mls qos monitor dscp 0 24 40 service-policy input ingress1
3550# show mls qos interface gig 0/12 statistics GigabitEthernet0/12 Ingress dscp: incoming no_change classified policed dropped bytes 0 : 960000 960000 0 0 959424 24: 0 0 0 0 0 40: 640000 640000 0 0 631552 Others: 0 0 0 0 0 Note: The “classified” field is used when traffic is remarked by a policy map. The “policed” field is used if the policer was configured to mark down instead of drop non-conforming traffic.
2) check to make sure the traffic is not being dropped by the egress interface queues of the outgoing interface instead of by the policer.
To monitor whether the egress qos queues on the outgoing interface are dropping traffic on the 3550 you can again configure the “mls qos monitor dscpdscp1 ... dscp8” interface configuration command under the interface of interest, and then you can use the “show mls qos interfaceinterface-idstatistics” privileged EXEC command. For example, in the below output the 2 drop thresholds (thresh1 & thresh2) for the 4 egress queues (qid = 1 to 4) of the interface show zero drops... 3550(config-if)# int gig 0/11 mls qos monitor dscp 0 24 40 3550# show mls qos interface gig 0/11 statistics GigabitEthernet0/11 Egress dscp: incoming no_change classified policed dropped (in bytes) 0 : 1591728 n/a n/a 0 0 24: 576 n/a n/a 0 0 40: 8448 n/a n/a 0 0 Others: 240 n/a n/a 0 0 WRED drop counts: qid thresh1 thresh2 FreeQ 1 : 0 0 1844 2 : 0 0 1229 3 : 0 0 614 4 : 0 0 409 3) Try a bigger burst size in your policer config.
Your burst size looks pretty good to me already which is why I listed this step last but still it is something to try. Typically for TCP traffic burst is set to the largest expected packet size times 2 times the TCP window size [1518 bytes x (TCP window size x2)]. The issue with TCP windowing is that if we start dropping traffic right at the specified rate then the user devices involved will react to this perceived congestion and slow down by decreasing their window size (TCP flow controlling). This will cause the users to experience less then the specified rate until their window size gradually increases again. Setting a larger burst for TCP traffic compensates for this. Think of the burst as a buffer of the size you specify (in bytes) that allows user traffic to momentarily extend beyond the specified rate. Only if a user constantly transmits beyond the specified rate will the burst buffer quickly fill and the user will be policed. If the user transmits beyond the specified rate only briefly (a burst of traffic) the burst buffer can handle that little extra traffic without policing kicking in.
I believe that with your current config all of your traffic may be getting reset to DSCP = 0. This would still match your class map since you are matching on "default and 63" (ie all traffic would match default) and so the policer would still work, but all the traffic would leave the switch set to DSCP = 0. You could use the show commands I gave previously (above) to verify this is happening. For example, to monitor FastEthernet0/1 configure "mls qos monitor dscp 0 63" under the FastEthernet0/1 interfaces to specify what DSCP values you want statistics for and then use “show mls qos interface fast 0/1 statistics” to take a look. I think you will see all traffic "classified" with DSCP = 0.
Once you add the above trust statement to the incoming interfaces I think your config will still work and in addition the traffic will leave the switch with the same DSCP value it arrived with. This is because my understanding is that using an individual policer (as you have above) in combination with a "match ip dscp" class map means that all dscp values matched (in your case default and 63) will share the policed rate as you desire. I have not seen any examples in the config guide, etc where the same policy map is applied both in and out on the same interface as you are doing but my understanding is that it should work as you desire where you would get 2Mbps in & 2Mbps out and not 2Mbps shared by the combined in/out traffic.
So to recap, your config should still work fine you just need to add the trust dscp statement to all the incoming interfaces.
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...
I am going to design and build an LAN network under a tunnel underground with long distance between the switches.
I will have 2 Catalyst switches and 8 Industrial IE3000, and they will be connected with fiber.
For now I am planning on use Layer-2 s...