QoS and rate limited

Answered Question
Nov 11th, 2008
User Badges:

Hi,


I config the autoQoS and change the setting below.


The rate limited is controlled the ip (except ACL 15) to consume 6M max.

the AutoQoS, I config 8M for voice traffic.


If it has 6M voice traffic (RTP) and 5M data traffic (non RTP traffic) to FE0/0, what happen?


rdgs


!R1

policy-map AutoQoS-Policy-Trust

class AutoQoS-VoIP-RTP-Trust

priority percent 80

class AutoQoS-VoIP-Control-Trust

bandwidth percent 8

class class-default

fair-queue

!

Interface faste 0/0

decription 10M bandwidth

rate-limit output access-group 15 6000000 50000 50000 conform-action continue exceed-action drop

service-policy output AutoQoS-Policy-Trust



access-list 15 deny 192.168.1.32 0.0.0.31

access-list 15 deny 192.168.1.96

access-list 15 deny 192.168.1.99





Correct Answer by Joseph W. Doherty about 8 years 7 months ago

Rate limiters, or policers, don't block traffic although they can control bandwidth utilization. If there's abusive traffic you want to block, that's better done using an ACL to drop all of it.


With regard to using a rate limiter or policer to keep some heavy bandwidth flows, such as a FTP file copy, from taking too much bandwidth, a rate limiter or policer can be used for that purpose, but using proportional bandwidth queuing is a much better method I believe, if it's available. (Older equipment and/or some swithes QoS features can be very limited; a reason I asked in my earlier post for you to describe the device you're using.)


If, for example, we believe FTP could be a real problem, the example policy as admended, below, would be better.


class-map yourClassname

use match criteria to identify your RTP traffic


class-map match-any bandwidthHog

match protocol FTP


policy-map yourpolicyname

class yourClassname

priority percent 80

class bandwidthHog

bandwidth remaining percent 1

class class-default

fair-queue


The bandwidthHog class guarantees minimal bandwidth but allows 100% usage of the link's bandwidth if it's available. I.e. FTP could use all the link's bandwidth but would be pushed aside by more important traffic.


Normally, the original policy, using FQ within class-default, would also keep a single or couple heavy traffic flows from taking too much bandwidth from other flows, but it tends to not work well if there are lots of heavy flows.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joseph W. Doherty Tue, 11/11/2008 - 16:45
User Badges:
  • Super Bronze, 10000 points or more

What I believe will happen, traffic matching ACL 15 and that exceeds 6 Mbps will be dropped.


If there's interface congestion, traffic matching class AutoQoS-VoIP-RTP-Trust should obtain up to 80% of the interface's bandwidth and also be rate limited to that amount.


Also when there's interface congestion, class AutoQoS-VoIP-Control-Trust is supposed to obtain a minimum of 8% of the interface's bandwidth, but I believe FQ in class class-default could preclude that.


PS:

Normally, wouldn't expect the policy to be accepted since defaults usually only allow defined classes to allocate 75% interface bandwidth unless overridden.

anitachoi3 Tue, 11/11/2008 - 23:50
User Badges:

Hi Joseph,


Question 1:

I have 10M bandwidth. If there are 6M voice traffic (RTP) and 5M data traffic (non RTP) to FE0/0. The AutoQoS will allow 6M (RTP) traffic in FE0/0.


The 5M data traffic, it allows 4M data traffic only in FE0/0 (because the 6M is allocated for RTP traffic).


Is that the correct result?


Question 2:

"PS: Normally, wouldn't expect the policy to be accepted since defaults usually only allow defined classes to allocate 75% interface bandwidth unless overridden. "


Base on the configuration, the total bandwidth is


10M x 80% = 8M


because I change the default (75%) to 80%.


rdgs


Joseph W. Doherty Wed, 11/12/2008 - 05:35
User Badges:
  • Super Bronze, 10000 points or more

I probably could answer your questions, but if you're trying to accomplish something useful, describe what you want to happen and I might better be able to suggest what to try (also describe the device and its installed software). Your existing combination of a defined rate limiter and service policy is unusual since policy maps can often contain policers and/or shapers.

anitachoi3 Wed, 11/12/2008 - 08:30
User Badges:

Hi,


I would like to config the AutoQoS and rate limited. The AutoQoS is for voice traffic running on FE 100M bandiwdth. The rate limited to control the data traffic (no RTP) to use pre-defined bandwidth. Our objective is that:


1. max. 80M bandwidth for voice traffice


2. the max 60M traffic for non-RTP (e.g. ftp/email, ...)


3. if the voice traffic grow to 80M, the router must allocate 80M bandwidth for voice. the router must drop the non-RTP to 20M


4. if the voice traffic is below 40M, the non-RTP traffic can consume bandwidth to 60M for max.


How do I config the router to match above requirements?


rdgs






Joseph W. Doherty Wed, 11/12/2008 - 09:53
User Badges:
  • Super Bronze, 10000 points or more

class-map yourClassname

use match criteria to identify your RTP traffic


policy-map yourpolicyname

class yourClassname

priority percent 80

class class-default

fair-queue


interface (Fast)Ethernet #

max-reserved-bandwidth 80

service-policy output yourpolicyname


You could place a shaper within the class-default to limit that traffic to 60%, but there's no real need since the LLQ will preempt bandwidth up to 80%.

anitachoi3 Wed, 11/12/2008 - 23:15
User Badges:

Hi Joseph,


The vendor told me that the "rate limited" could block the abuse / abnormal traffic, e.g. pc infect virus, ftp huge file (e.g. 150G data from backup server to local segment). That's why I enable the rate limited. Any idea or comment if the rate limited are implement on the FE interface?


rdgs

Correct Answer
Joseph W. Doherty Thu, 11/13/2008 - 04:59
User Badges:
  • Super Bronze, 10000 points or more

Rate limiters, or policers, don't block traffic although they can control bandwidth utilization. If there's abusive traffic you want to block, that's better done using an ACL to drop all of it.


With regard to using a rate limiter or policer to keep some heavy bandwidth flows, such as a FTP file copy, from taking too much bandwidth, a rate limiter or policer can be used for that purpose, but using proportional bandwidth queuing is a much better method I believe, if it's available. (Older equipment and/or some swithes QoS features can be very limited; a reason I asked in my earlier post for you to describe the device you're using.)


If, for example, we believe FTP could be a real problem, the example policy as admended, below, would be better.


class-map yourClassname

use match criteria to identify your RTP traffic


class-map match-any bandwidthHog

match protocol FTP


policy-map yourpolicyname

class yourClassname

priority percent 80

class bandwidthHog

bandwidth remaining percent 1

class class-default

fair-queue


The bandwidthHog class guarantees minimal bandwidth but allows 100% usage of the link's bandwidth if it's available. I.e. FTP could use all the link's bandwidth but would be pushed aside by more important traffic.


Normally, the original policy, using FQ within class-default, would also keep a single or couple heavy traffic flows from taking too much bandwidth from other flows, but it tends to not work well if there are lots of heavy flows.

Actions

This Discussion