QOS

[Mlex1]

Hello everyone

Are these settings different or the same and how act in real wokr?

policy-map TEST
class FOR_TEST
priority lavel 1 percent 30
!
policy-map TEST
class FOR_TEST
priority percent 30

[Giuseppe Larosa]

Hello @Mlex1 ,

when you have a policy map with multiple class maps / traffic classes and you want to have two LLQ queues the priority level command provides a way to deal with competition between the LLQ queues.

In your case with a single class map defined under the policy map the two sets of commands provide the same result a single LLQ with a built in policer of 30% of interface bandwidth.

If you had multiple class maps and two of them with LLQ ( priority command) the priority level provides two levels for managing the competition between the two LLQ queues.

To make an example if you have VOIP packets and a video stream class both with LLQ you want to provide a preferred treatment to VOIP packets you associate their class-map with the best priority level (likely 1) and the video class with priority level less preferred (likely 2)

Hope to help

Giuseppe

[Mlex1]

Hello 

To make an example if you have VOIP packets and a video stream class both with LLQ you want to provide a preferred treatment to VOIP packets you associate their class-map with the best priority level (likely 1) and the video class with priority level less preferred (likely 2)

what you type i readed on internet my question a liitle another, i mean both of priority lavel 1 percent 30 and priority percent 30  when i configure result will be the same ?

[Giuseppe Larosa]

Hello @Mlex1 ,

if you have only one LLQ traffic class the result is the same 

Hope to help

Giuseppe

[Mlex1]

ok for example purpose i choose this option, how this one action in real work?

policy-map TEST
class FOR_TEST
priority percent 30

priority traffic will always be policed to 30% of the interface bandwidth, 

priority traffic can never use more than 30% of the interface bandwidth.
am i right ?

[Joseph W. Doherty]

priority traffic will always be policed to 30% of the interface bandwidth, 

"Always", no.  (For always, you need to add an explicit policer.)

priority traffic can never use more than 30% of the interface bandwidth.

"Never", no; can use up to 100%.  (At least, surprisingly, that's how it used to work.)

[Mlex1]

if you have link can you share please or any documentation 

[Joseph W. Doherty]

Beyond what @balaji.bandi already provided?

As your original questions has been answered, is there another question, or the answers are unclear, or you're looking for documentation confirmation?  As QoS is a wide topic, try to be as specific as possible with any follow up questions.

[Joseph W. Doherty · Accepted solution]

Oh, I might mention, support for two physical LLQ queues (levels 1 and 2) was a feature later added to CBWFQ.

The "surprising" way a LLQ class's implicit policer works, wasn't, I recall, well documented when CBWFQ was initially released.  However, @balaji.bandi 's reference does explicitly describe it, for example:

Only traffic that conforms to the token bucket is guaranteed low latency. Any excess traffic is sent if the link is not congested or is dropped if the link is congested.

Or

As noted previously, the offered load of a priority class is metered by a traffic policer. During congestion conditions, a priority class cannot use any excess bandwidth.

Or

Note: An exception to these guidelines for LLQ is Frame Relay on the Cisco 7200 router and other non-Route/Switch Processor (RSP) platforms. The original implementation of LLQ over Frame Relay on these platforms did not allow the priority classes to exceed the configured rate during periods of non-congestion. Cisco IOS Software Release 12.2 removes this exception and ensures that non-conforming packets are only dropped if there is congestion.

BTW, Cisco QoS documentation has markly improved over the years.  Also in that reference we find:

Use the tx-ring-limit command to tune the size of the transmit ring to a non-default value. Cisco recommends that you tune the transmit ring when you transmit voice traffic.

Not knowing that drove me crazy, decades ago, working out effective QoS.  I finally found mention of the need for it, in a Tech Note, when using ATM, which we weren't.  It's useful for more than voice, although shouldn't be as important on a LAN or any high bandwidth interface, and supposedly (at least at one time) Cisco noted some devices automatically decrease its setting when the device detects an interface with QoS applied.

@Mlex1 , lastly, I'm possibly the QoS expert on these forums.

If you have other QoS questions, feel free to ask.

Be warned, though, I consider much QoS material, for its usage, poor.

When it comes to QoS, I'm a legend, in my own mind.  ; )

Seriously, though, I spent about half my time, over a decade, working on creating truly effective QoS, in a production environment.  I believe I succeeded.  BTW, I started with the "book" recommendations, so I'm fairly well acquainted with them (and their often less than ideal, effectiveness).

[Mlex1]

During congestion conditions, a priority class cannot use any excess bandwidth.

am i right you mean if not congestion on interface, priotiyr can use more then 30 or 40% and so on ?

[Joseph W. Doherty]

am i right you mean if not congestion on interface, priotiyr can use more then 30 or 40% and so on ?

Correct.

BTW, that's not just me saying that, that's also what's being said by Cisco in their documentation referenced by @balaji.bandi , which I provided snippets of in a prior reply.

I believe the reason for this behavior, the implicit policer guarantees non LLQ traffic a percentage of bandwidth, but just like for other classes, if there's available bandwidth, LLQ class traffic can use it.

If you wish to always cap a LLQ class's bandwidth, you can configure an explicit policer.

[Joseph W. Doherty]

BTW, the ATM Tech Note, I alluded to: https://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/ip-to-atm-class-of-service/6142-txringlimit-6142.html

As I wrote earlier, tx-ring-limit setting can be critical to a CBWFQ policy working well, and not just for ATM interfaces or supporting voice.

Basically it controls the depth setting of an interface's hardware transmission FIFO queue.  To paraphrase Dune's "Fear is the mind-killer", FIFO is the QoS killer.

Further, CBWFQ queuing "stuff" only comes into play dealing with the overflow of the tx-ring queue.

I mention this, because anyone needing to use LLQ, is very, very likely trying to provide effective QoS.

[balaji.bandi]

In adding @Giuseppe Larosa suggestion and explanation.

What device model and IOS code is running on the device?

check below some reference guide below:

https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet-marking/10100-priorityvsbw.html

[Mlex1]

Hi 

I guess you also understand wrong, on the link esepecially about  bandwidth remaining percent

[Joseph W. Doherty]

Are these settings different or the same and how act in real wokr?

policy-map TEST

class FOR_TEST

priority lavel 1 percent 30

!

policy-map TEST

class FOR_TEST

priority percent 30

As shown, they are the same (and as already described by others).  Also, as would be:

policy-map TEST

class FOR_TEST

priority level 2 percent 30

As to how they would work, all would provide one physical LLQ and traffic, in just the FOR_TEST class, would be policed at 30% but only if there is congestion (unlike an explicit policer).