cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8823
Views
0
Helpful
3
Replies

How do I limit the bandwidth on a Cisco 3550 switch?

comentum
Level 1
Level 1
Hello,
I need to limit the bandwidth (up and down) on a Cisco 3550 switch to 2 Mbps on some of the ports and 3Mbps on some other ports.
I used below configuration on a port that supposed to get 3 Mbps up and down, but I'm getting 1.7 Mbps download and 0.61 Mbps upload which is not anything close to my configuration bandwidth limit.
I tried this several times and I never receive the supposedly configuration bandwidth.
I appreciate any help.
Bernie
!     
!     
mls qos aggregate-policer 2000k 2000000 25000 exceed-action drop
mls qos aggregate-policer 3000k 3000000 25000 exceed-action drop
mls qos
!     
class-map match-all traffic1
match ip dscp default  cs1  cs2  cs3  cs4  cs5  cs6  cs7
!     
!     
policy-map traffic_2000k
class traffic1
police aggregate 2000k
!     
policy-map traffic_3000k
class traffic1
police aggregate 3000k
!     
!     
interface FastEthernet0/1
switchport mode access
service-policy input traffic_2000k
service-policy output traffic_2000k
load-interval 30
spanning-tree portfast
!     
interface FastEthernet0/2
switchport mode access
service-policy input traffic_3000k
service-policy output traffic_3000k
load-interval 30
spanning-tree portfast
3 Replies 3

Mike Pavlovich
Cisco Employee
Cisco Employee

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 dscp dscp1 ... dscp8” interface configuration command under the interface of interest, and then you can use the “show mls qos interface interface-id statistics” 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 dscp dscp1 ... dscp8” interface configuration command under the interface of interest, and then you can use the “show mls qos interface interface-id statistics” 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.

Thank you for your help.

I changed the configuration to below and it seems to be working – am I doing this configuration correctly?

I appreciate your help.

mls qos
!
class-map match-all 2mb
  match ip dscp default  63
class-map match-all 3mb
  match ip dscp default  63
class-map match-all 5mb
  match ip dscp default  63
!
policy-map 2mb
  class 2mb
    police 2000000 375000 exceed-action drop
policy-map 3mb
  class 3mb
    police 3000000 375000 exceed-action drop
policy-map 5mb
  class 5mb
    police 5000000 375000 exceed-action drop
!
interface FastEthernet0/1
switchport mode dynamic desirable
service-policy input 2mb
service-policy output 2mb
!        
interface FastEthernet0/2
switchport mode dynamic desirable
service-policy input 3mb
service-policy output 3mb
!        
interface FastEthernet0/3
switchport mode dynamic desirable
service-policy input 5mb
service-policy output 5mb
!       

One thing that is missing is a trust statement on the incoming interfaces. For example...

interface FastEthernet0/1
switchport mode dynamic desirable
service-policy input 2mb
service-policy output 2mb
mls qos trust dscp <--------------- *****

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: