QoS related issues

[Wilfort]

Hello everyone!
Due to an emergency demand, I took over the position of a CCNP professional who dealt with direct questions from the Service Provider, and I need help with questions related to QoS.

Could you help me with that?

I have the following requirements requested by the client:

The circuit must follow the following QoS premise:
Queue 1 - 20% - Real Time
Queue 2 - 30% - Critical apps
Queue 3 - 40% - Non-critical apps
Queue 4 - 10% - Best Effort

1 - Queues 2, 3 and 4 can use resources from other queues (including queue 1), if they are without traffic. However, queue 1 cannot use resources from other queues.

2 - The available network must make the necessary appointments to adapt the network's QoS policies in both directions.

3 - The bandwidth reserved for each queue should flexibly meet the following criteria:

Queue 1 - EF; AF1
Queue 2 - AF21; AF22; AF23; AF31; FA32; FA33
Queue 3 - DSCP 00; (all remaining markings)
Queue 4 - AF11

Below is what was understood by me in relation to what was requested by the client:

class-map match-any Real_Time
description Data for Voice and Video Conference
match ip dscp ef
match ip dscp af41

class-map match-any Critical_Apps
description Critical Applications
match ip dscp af21
match ip dscp af22
match ip dscp af23
match ip dscp af31
match ip dscp af32
match ip dscp af33

class-map match-any Non_Critical_Apps
description Non-critical applications and standard DSCP
match ip dscp default
match ip dscp af12
match ip dscp af13
match ip dscp af42
match ip dscp af43

class-map match-any Best_Effort
description Best Effort
match ip dscp 11

policy-map QoS_Structure
class Real_Time
priority percent 20

class Critical_Apps
bandwidth percent 30
random-detect dscp-based

class Non_Critical_Apps
bandwidth percent 40
random-detect dscp-based
fair-queue

class Best_Effort
bandwidth percent 9
random-detect dscp-based
fair-queue

I would like to know if this configuration meets the client's requirements or if I am just mistaking it all.

Any help is always welcome!

Thank you!

[Vishnu Vardhan S]

Configuration looks good. Do you have any lab devices to work on this with a traffic generator.

[Joseph W. Doherty]

"However, queue 1 cannot use resources from other queues."

For that, you'll also need to add an explicit police statement to your Real_Time class.

Suggest for:

class-map match-any Non_Critical_Apps
description Non-critical applications and standard DSCP
match ip dscp default
match ip dscp af12
match ip dscp af13
match ip dscp af42
match ip dscp af43

class Non_Critical_Apps
bandwidth percent 40
random-detect dscp-based
fair-queue

Use, instead:

class class-default
bandwidth percent 40
fair-queue

Also (strongly) suggest, as seen in above class, not to use random-detect dscp-based (especially with FQ) in any class.

Also suggest possibly using FQ in Critical_Apps class.

BTW, generally DSCP BE (zero) is best effort class, not AF11.

Also BTW, your Best_Effort class only has 9% allocated. This, I believe, because implicit class-default requires at least 1%. If you do as suggested, above, you should be able to allocate the requested 10%.

Further, also BTW, believe you can match up to 4 DSCP markings per match statement. So, if you want to "condense" your configuration, you might write a class-map like:

class-map match-any Critical_Apps
description Critical Applications
match ip dscp af21 af22 af23
match ip dscp af31 af32 af33

Lastly, what about IPPrec 6 and 7, 5 (excluding EF), CS1..4, AF12 and AF13, AF42 and AF43; client wants all these treated BE?

[Wilfort]

Hi Joseph!

Thank you for your help, and for sharing your knowledge with me!

I modified the structure of the settings according to its orientation, from what I could understand, I think it should be as below, right?

class-map match-any Real_Time
description Voice and Video Conference
match ip dscp af41 ef

class-map match-any Critical_Apps
description Critical Applications
match ip dscp af21 af22 af23
match ip dscp af31 af32 af33

class-map match-any Class_Default
description Non-critical Applications
match ip dscp default af12 af13
match ip dscp af42 af43

class-map match-any Bulk_Data
description Background Noninteractive Traffic Flows
match ip dscp af11

policy-map QoS_Structure

class Real_Time
priority percent 20

class Critical_Apps
bandwidth percent 30
fair-queue

class Class_Default
bandwidth percent 40
fair-queue

class Bulk_Data
bandwidth percent 10
fair-queue

Lastly, what about IPPrec 6 and 7, 5 (excluding EF), CS1..4, AF12 and AF13, AF42 and AF43; client wants all these treated BE?
Everyone's tags (0)

I am still studying IP Precedence and I confess that I still don't have enough knowledge to apply it correctly in these configurations.

For the information provided by the customer, it is necessary that Queue 2 (Critical_Apps), Queue 3 (Class_Default), and Queue 4 (Bulk_Data) can use resources from other queues, including Queue 1 (Real_Time), if these queues are without traffic . However, Queue 1 (Real_Time) will not be able to use the resources belonging to the other queues, even if they are without traffic.

Again, thank you for all your help!

[Joseph W. Doherty · Accepted solution]

Again, for your Real_Time LLQ, the way LLQ normally works, if there's no actual queuing in that class, the class can use more than the specified bandwidth, up to the full link's worth. (The implicit policer only usually engages when traffic is queued in this class.) Basically, it will only, in such cases, use otherwise unused bandwidth. So, again, if you truly want to limit it to some amount of bandwidth, all the time, you need to police it.

E.g.
class Real_Time
priority percent 20
police average # !later IOS versions might also support a percentage allocation

The "class-default" doesn't get its own class-map because it's always there in the policy-map, whether explicitly defined or not. This built-in class is basically a none-of-the-above class. I.e. anything not matched in other classes goes through this class. As the sequence of class definitions in a policy-map can be important, as they are processed top to bottom (like an ACL), the class-default will always appear last. (Likewise, LLQ classes appear before other classes, but since you can define more than one of these, although there is only one physical LLQ [excluding later IOSs that support two - which you may want to consider for prioritization of VoIP over Video], the sequence of defining them is maintained, as configured, relative to each other.)

So:

class-map match-any Class_Default
description Non-critical Applications
match ip dscp default af12 af13
match ip dscp af42 af43

IPPrec is the earlier RFC for use of first 3 ToS byte bits. DSCP supercedes IPPrec but is somewhat backward compatible with IPPrec. For example, BE overlaps IPPrec zero, and IPPrec 6 and 7 are "left alone" by DSCP (so they can be treated as they were - for network management purposes). Traffic allocated to AF classes and EF, is generally done such that "more important" traffic aligns with, more-or-less, IPPrec 1..5. Knowing this, if you want to match, for example, CS# and the AF#x markings, IPPrec # will match them all. (IPPrec will also match the other "private" ToS values immediately one above the corresponding CS# and AF#x marking. E.g. IPPrec 1 matches DSCP values CS1, AF11, AF12, AF13 and 9, 11, 13, 15).

[Wilfort]

I am having trouble understanding you accurately, I believe it is due to my level of English.

Sorry about that.

Latest changes:

class-map match-any Real_Time
description Voice and Video Conference
match ip dscp af41 ef

class-map match-any Critical_Apps
description Critical Applications
match ip dscp af21 af22 af23
match ip dscp af31 af32 af33

class-map match-any Class_Default
description Non-critical Applications
match ip dscp default

class-map match-any Bulk_Data
description Background Noninteractive Traffic Flows
match ip dscp af11



policy-map QoS_Structure

class Real_Time
priority percent 20
police rate percent 20

class Critical_Apps
bandwidth percent 30
fair-queue

class Class_Default
bandwidth percent 40
fair-queue

class Bulk_Data
bandwidth percent 10  (I still can't reach 10% of the band, something must still be wrong)
fair-queue



About the class below:
Class_Default
description Non-critical Applications
match ip dscp default
Can I leave it this way, or do I need to remove it?



I am taking a lot of your time, if it is no longer feasible for you to answer I will understand perfectly.

Thanks!

[Joseph W. Doherty]

"I am having trouble understanding you accurately, I believe it is due to my level of English.

Sorry about that."

No need to apologize. I'm sure your understanding of English is better than mine of your native language. ;)

Okay, one issue, you've defined a class-map and policy-map class for "Class_Default". Don't define that class-map and replace its policy-map class with one defined "class-default". The latter is a built-in class. It's always present, although it won't appear in the config unless you define it. If you define it explicitly, you can define parameters for it. (I believe this "built-in" class is what's using the missing 1%.)

[_|brt.drml|_]

"Also (strongly) suggest, as seen in above class, not to use random-detect dscp-based (especially with FQ) in any class."

Why? 

[Joseph W. Doherty]

First, because it's surprisingly difficult to "get it right".

Second, with FQ active, you don't need RED trying to avoid a single global tail drop issue, and, with FQ, drops will "dynamically", and generally, first apply to flows causing congestion whereas RED targets all flows equally (WRED can target differently tagged packets but flows with the same tag are treated alike).  (BTW, Cisco's FRED is a RED variant that applies per flow, better than global WRED, but, I believe, FQ is still a better choice.)

In a few of my posts, over the years, I've detailed potential issues with RED (to "get it right"), but in another recent post, relating some of RED's potential issues, I noted a new one, i.e. the latest TCP stacks now can use detailed analysis of RTT to adjust their transmission rate.  In other words, these TCP implementations don't really need to detect dropped packets for flow rate management.

[Wilfort]

Hello Vishnu Vardhan

Yes, I have EVE-NG and PNETlab simulators. I have been following these traffic with Sniffer and checking the matches directly in the Appliances.

Thank you for your help!