cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
609
Views
19
Helpful
12
Replies

Is this QoS possible?

pnicolette
Level 1
Level 1

I'd like to mark some traffic so any other traffic has priority, except that my marked-down traffic has a guaranteed minimum rate. When there's no other traffic, my marked traffic can use the full TLS Ethernet bandwidth.

Possible? If so, can someone point me in the right direction? Router/L2/L3 switch are all available. Thanks!

Paul

1 Accepted Solution

Accepted Solutions

bmcginn
Level 3
Level 3

Hi Paul,

What you're asking seems to be no problem at all.

Let me get this straight, you would like to mark some traffic (lets call it traffic type A) so that all Other traffic has a higher priority?

Do you already have a QoS policy set up for your network? ie, marking voice with ef, or DSCP 46 or IPP 5, video with 34 or AF41 or IPP4 etc?

I assume the TLS link is entirely yours? ie, no shared bandwidth through a carrier etc?

If you own the link completely, then you can set your own QoS policy however you want it.

To do what you're asking you will need to set ALL traffic to a higher priority than your selected traffic.

ip access-list extended ALL_TRAFFIC

permit ip any any

ip access-list extended SELECTED_TRAFFIC

permit ip X.X.X.X 0.0.0.XX Y.Y.Y.Y 0.0.0.YY

deny ip any any

class-map match-any ALL-TRAFFIC

match ip ALL_TRAFFIC

class-map match-any SELECTED-TRAFFIC

match ip SELECTED_TRAFFIC

policy-map MY-QOS

class ALL_TRAFFIC

bandwidth percent <75%-min bwidth>

set dscp cs2

class SELECTED_TRAFFIC

bandwidth

set dscp cs1

class default

fair-queue

Assign the policy map to your outgoing interface in an the outgoing direction and it should work.

I hope :)

Hope that answers your question!

Brad

View solution in original post

12 Replies 12

Joseph W. Doherty
Hall of Fame
Hall of Fame

In theory, what you want to do is possible. In practice, very dependent on both whether performed at L2 or L3 and the capabilities of the equipment.

L3 with routers is usually the most capable. Multilayer switches usually trade off capabilities for performance.

bmcginn
Level 3
Level 3

Hi Paul,

What you're asking seems to be no problem at all.

Let me get this straight, you would like to mark some traffic (lets call it traffic type A) so that all Other traffic has a higher priority?

Do you already have a QoS policy set up for your network? ie, marking voice with ef, or DSCP 46 or IPP 5, video with 34 or AF41 or IPP4 etc?

I assume the TLS link is entirely yours? ie, no shared bandwidth through a carrier etc?

If you own the link completely, then you can set your own QoS policy however you want it.

To do what you're asking you will need to set ALL traffic to a higher priority than your selected traffic.

ip access-list extended ALL_TRAFFIC

permit ip any any

ip access-list extended SELECTED_TRAFFIC

permit ip X.X.X.X 0.0.0.XX Y.Y.Y.Y 0.0.0.YY

deny ip any any

class-map match-any ALL-TRAFFIC

match ip ALL_TRAFFIC

class-map match-any SELECTED-TRAFFIC

match ip SELECTED_TRAFFIC

policy-map MY-QOS

class ALL_TRAFFIC

bandwidth percent <75%-min bwidth>

set dscp cs2

class SELECTED_TRAFFIC

bandwidth

set dscp cs1

class default

fair-queue

Assign the policy map to your outgoing interface in an the outgoing direction and it should work.

I hope :)

Hope that answers your question!

Brad

Brad's example is representative of how to accomplish what you requested on most Cisco routers, not most L2 or L3 switches, running a recent IOS image.

As an example on such platforms, one weakness is usage of FQ with class-default. On platforms (most) that don't constrain FQ bandwidth usage within class-default, you might not get the minimal you've defined for another class, one of your mentioned requirements. (Brad's example, nicely, minimizes this issue since he places other traffic into a separate named class.)

Another point to note in this example, CBWFQ classes are matched in sequence so you need to insure either ALL_TRAFFIC does not include SELECTED_TRAFFIC (which it does) or move SELECTED_TRAFFIC before ALL_TRAFFIC in the policy-map.

A further point to note in this example, Brad uses CS2 for traffic other than your minimal and CS1 for the minimal bandwidth class. This is fine if you desire to classify using these markings downstream although note that the default-class isn't remarking traffic, so unknown what markings it will have; some will likely be "best effort" which is usually considered less than CS1.

The forgoing, hopefully, shows that it's not always "no problem at all", yet Brad is correct in providing a sense of how easy it might be.

Thanks much for the detailed and helpful replies. Few QoS newbie Qs:

1. Is the 75% to leave room for non-IP traffic that's outside of ALL?

2. if desired min bwidth is 1000 on a link that's 10000, would I use "bandwidth percent 65" ? Just want to understand the (simple!) arithmetic.

3. I'm confused about how the "bandwidth percent" and "bandwidth" interact. To me it seems that the first fixes a ceiling which ALL_TRAFFIC can't exceed. I assume the second works similarly for SELECTED_TRAFFIC. But what I want is this:

- when there is NO selected traffic, give ALL nearly the whole pipe

- when there's ONLY selected traffic, give SELECTED nearly the whole pipe

- when there's lots of both, guarantee a minimum rate for SELECTED

So I'm looking more for a floor than a ceiling, if that makes sense. Possible? Or am I totally confused?

Paul

Hi Paul,

1. By default, 25% is for 'default' traffic, and it is not wise, nor best practise to change that percentile, so when playing with QoS, one plays with 75% of the available bandwidth.

2. You would use whatever percent of the available bandwidth (don't forget that 25% is still used for the 'default' traffic class) that you want. If you wanted to use 1000 on a 10000 link then that would be 'bandwidth percent 10'. In the case of the example i have posted previously, the ALL_TRAFFIC class would be given 65% of the bandwidth (assuming min-bwidth = 10%, therefore 75%-10%=65%).

3. Bandwidth percent assigns a minimum bandwidth to the traffic class of the percent value. eg bandwidth percent 10 assigns 10% of the bandwidth as a minimum. If there is bandwidth available, it will use it, but at all times, it will have the 10%. the Bandwidth statement acutally just gives the minimum bandwidth in kb. so bandwidth 64 says that 64kb is the minimum bandwidth that class can have. If more bandwidth is available, the class can use it, but if there is congestion, the class will always have 64kb.

The bandwidth command defines a minimum bandwidth value. if there is more bandwidth available at any given time, the class can use it, but if there is congestion, it has the minimum bandwidth to use. It doesn't specify a ceiling at all. To specify a ceiling, you can use traffic policing..

Confused? You had to ask. ;)

When you get into percentages, and such, the rules differ based on platform and IOS level.

Although this reference, http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00800fe2c1.shtml#understand, mentions ATM, I believe the rules apply to other interface types.

CBWFQ provides a class-default, even when not named. Whether named or not (usually) all traffic that doesn't match to a named class is placed into it.

Except for LLQ, bandwidths provide a minimum. (So yes, you can accomplish what you want, i.e. utilization of excess bandwidth.)

Bandwidth percentage is a newer option (rather than using an actual bandwidth value). It makes it easy to apply the same policy to different interfaces of different bandwidths.

Actually instead of thinking of minimums in absolutes, think ratios. If I define one class to get 1% or 8K and another to bet 5% or 40k, and together, both want to fill the pipe, the bandwidth allocations will be 1:5. (You can't define a policy that oversubscribes bandwidth, which is how the minimums are supported, but I find tracking ratios is often easier and as effective as working with absolute percentages or absolute bandwidths.)

You might want to read the CBWFQ section of: http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfconmg_ps1835_TSD_Products_Configuration_Guide_Chapter.html

Brad & Joseph,

You guys are awesome - thanks for your expertise and patience!

One more question, if less is more, could I do what I want by defining a class only for SELECTED_TRAFFIC, then something like

policy-map MY-QOS

class SELECTED_TRAFFIC

bandwidth

set dscp cs1

class default

fair-queue

int f1/1

random-detect dscp-based

(not sure i need WRED but it sounds cool)

prompted by Peter Welcher's QoS overview at www.netcraftsmen.net/welcher/seminars/qos-seminar.pdf

Just wondering......

Paul

Yes, in fact you don't even need to declare class-default; it's also present when not explicity defined. However, as my prior post noted, FQ within class-default, on many platforms, will create problems insuring you obtain the minimums for your other classes.

Yes, WRED is cool, but a very tricky beast to obtain its ideal results. (If you defined it, you would add it to the classes within the policy map.

Thanks, Joseph. Sorry I missed the your FQ point earlier. Assuming no other QoS in the net, what would you think of

policy-map MY-QOS

class SELECTED_TRAFFIC

bandwidth

set dscp cs1

random-detect

class default

set dscp cs2

QoS for dummies questions:

- does applying the class-map to the outbound router interface automatically provide the proper queuing? Or need a global command to enable it?

- if FQ is iffy to apply to class-default, what kind of Q applies when c-d is undeclared?

- after bumping into the Cisco IOS Quality of Service Solutions Command Reference (and not reading all 22MB!) is there a simple way to explain how WRED in a class and on an interface (random-detect dscp-based) relate?

"does applying the class-map to the outbound router interface automatically provide the proper queuing? Or need a global command to enable it? "

On most pure routers, all you need to do is apply the policy to the outbound interface. (With ATM, can sometimes be applied to subinterfaces that map to PVCs.) Features vary, especially with L3 switches.

"if FQ is iffy to apply to class-default, what kind of Q applies when c-d is undeclared? "

I, think, FQ.

"after bumping into the Cisco IOS Quality of Service Solutions Command Reference (and not reading all 22MB!) is there a simple way to explain how WRED in a class and on an interface (random-detect dscp-based) relate?"

Both implement the WRED drop policy against the queue. If done against an interface, would apply the interface's queue. If applied against a CBWFQ class, would apply against the class queue.

Normally, believe interface WRED and CBWFQ are exclusive.

There's also a flow based WRED variant that, I recall, only can be used on interfaces.

"Assuming no other QoS in the net, what would you think of "

If there's no downstream devices, no need to mark traffic. (The real purpose of marking traffic is later devices only need to look at the marking, not analyze the traffic.)

If there were downstream devices, you could just mark the "special" traffic and leave everything else best effort.

If class-default defaults to using FQ, you would want to define it explicity with a bandwidth setting so there's only one flow for that class.

"If there's no downstream devices, no need to mark traffic."

Does my one QoS device still know that excess "special" traffic above its min bwidth should be lower priority than best effort?

"you could just mark the "special" traffic and leave everything else best effort."

I'm seeing one source say best effort = dscp 0. If true how do I make "special" traffic lower priority... Is "cs1 scavenger" lower than "best effort?"

Thanks!

In this example, since we're doing the classification and queue management on the outbound interface, the traffic would be treated as you specify.

How you make "special" lower, is up to you. AF11, I believe, is a recent recommendation marking for scavenger. However, Cisco WFQ often will treat, by default, any IP Prec 1 marking better than BE.

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: