cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
536
Views
0
Helpful
7
Replies

QoS and rate limited

anitachoi3
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

7 Replies 7

Joseph W. Doherty
Hall of Fame
Hall of Fame

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.

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

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.

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

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%.

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

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.

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: