Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

quick qos question

policy-map QOS

class SIP

    priority percent 25

class class-default

    fair-queue

policy-map 3M_Shaping

class class-default

    shape average 3000000

  service-policy QOS

interface FastEthernet0/0

description *** INTERNET ***

bandwidth 20000

....

so this is a 20mb internet line.

I just want to make sure I understand the QOS part.

25% of the 20000 is reserved for SIP?

which means what that if there is no sip that 25% is still reserved and can not be used?

what is the shape average 3000000 doing exactly?

thanks.

12 REPLIES
New Member

Re: quick qos question

The shape average command is shaping all unclassified traffic to 2.8 meg. The priority command may or may not be a strict queue. I do believe that it reserves and limits throughout for class SIP for 25% of the interface bandwidth. What is your IOS version and what platform is this on?

Sent from Cisco Technical Support iPhone App

New Member

Re: quick qos question

router:  2811

ios: 124-24.T8

so from what I understand,

it reserves 25% for SIP, remaining goes to anything else up to 2.8meg due to the shaping of 3000000.

now this 25% is this always reserved and can not be used by anything else even if SIP is not using the 25% at a given time?

thanks.

     

btw I have applied to to my wan interface as outgoing. I have a 20MB download and +-5MB uplaod so I'm trying to control the upload.

      

I know it works because on speedtest I hit 3MB with the qos on and without I hit 5MB.

thanks.

Re: quick qos question

Hello

If the policy map 3M_Shaping is applied to FastEthernet 0/0 then you will be shaping all outbound traffic to 3mb and SIP traffic will be guaranteed 25% of this bw at times of congestion.

Res
Paul

Sent from Cisco Technical Support iPad App

Please don't forget to rate any posts that have been helpful. Thanks.
New Member

Re: quick qos question

Yes, it only applies at interface
congestion. It's also important to know that there is not only a 25% minimum but also a 25% maximum.

Sent from Cisco Technical Support iPhone App

Super Bronze

Re: quick qos question

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

joshuacmoore wrote:

Yes, it only applies at interface
congestion. It's also important to know that there is not only a 25% minimum but also a 25% maximum.

Sent from Cisco Technical Support iPhone App

BTW, such QoS is not restricted to just an interface.

The implicit policer only triggers when there's congestion.  I.e. it's possible for LLQ to exceed its assigned bandwidth.

Super Bronze

Re: quick qos question

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

25% of the 20000 is reserved for SIP?

No.

which means what that if there is no sip that 25% is still reserved and can not be used?

No.

what is the shape average 3000000 doing exactly?

It tries to insure any traffic passing through it doesn't not exceed a 3 Mbps transmission rate, on average, over some time period.  If it does, it queues the traffic.  (NB: queues can overflow, and packets will drop.)

The time period is set (indirectly) by defining a burst size.  Your posting doesn't show an explicit setting for Bc, so it will take a default value (which varies based platform and/or IOS version - common defaults use either a Tc of 25ms or 4ms).

PS:

Although in the above, I've answered your questions, I suspect your looking for a much better understanding.  If QoS is "new" to you, it's difficult to explain how the above might work if you don't (yet) have a conceptional understanding.  Additionally, QoS, with the same configuration may behave differently on different platforms and/or IOS versions.  For example, HQF can work differently than pre-HQF QoS with the same configuration, shapers and FQ operations being a couple of the differences between the two "flavors"; both in your posting.

You also didn't post what, if any, service-policy statements are on F0/0.  I would expect something like "service-policy output 3M_Shaping", but you didn't note that.  If such is there, then one wonders why there's a bandwidth statement for 20 Mbps but shaping for 3 Mbps.  One also wonders, whether the FE is running at 10 or 100.

[edit]

BTW, from you later posting, for that platform and IOS version, you're running HQF QoS.

New Member

Re: quick qos question

Can you please elaborate? It is my understanding that at the parent rate congestion (shape average 300000) the priority policer will kick in to reserve a minimum and maximum of 25% of the interface bandwidth.

Is this not the case?

Sent from Cisco Technical Support iPhone App

Super Bronze

Re: quick qos question

Are you asking that question of me? I think you might be, but you attached response to OP item(?).

New Member

Re: quick qos question

Yes, sorry.

Sent from Cisco Technical Support iPhone App

Super Bronze

Re: quick qos question

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

As the class is defined as priority with 25%, when the parent (in this case another policy's [3 Mbps] shaper) queues packets, any packets in the LLQ will be dequeued first.  Any packets being queued in the LLQ class will be policed at 25% of the controlling bandwidth, if under a 3 Mbps shaper, this would be at 750 Kbps.  (NB: Bc, Tc and Be values, unknown.)

When it comes to "reserved", LLQ doesn't actually reserve bandwidth such that other classes are unable to use its unused bandwidth.  Again, what's guaranteed is LLQ being dequeued first.

As the LLQ's implicit policer only triggers against packets to be queued in the LLQ, it's possible LLQ traffic could actually utilize, in this example, up to 3 Mbps.  I.e. as long as the LLQ class packets aren't being queued, the implicit policer doesn't police the LLQ class traffic.

(NB: note the above applies to most ISRs, unknown if true with every platform and IOS version.)

New Member

Re: quick qos question

A few things:
1. Are you suggesting that the 25% is derived from the parent shaping rate? If so why/how? I was under the impression this was always from the interface bandwidth (either default bandwidth or by the bandwidth command)

2. You keep saying "as long as it isn't being queued". Queuing would not occur unless there is contention. How is this different than the logic that the policer does not go into affect until there is contention?

Sent from Cisco Technical Support iPhone App

Super Bronze

Re: quick qos question

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

1. Are you suggesting that the 25% is derived from the parent shaping rate? If so why/how? I was under the impression this was always from the interface bandwidth (either default bandwidth or by the bandwidth command)

Yes (at least with HQF QoS).  As to how/why, those are questions only Cisco could answer.

2. You keep saying "as long as it isn't being queued". Queuing would not occur unless there is contention. How is this different than the logic that the policer does not go into affect until there is contention?

The reason I emphasis until queued, is because the policy-map queues are not always the only queues.  For example, if the policy was applied to an interface, congestion will first queue to the hardware's tx-ring, and the policy map's LLQ implicit policer wouldn't "see" this as congestion.

As to shapers, it's my belief, on some platforms and IOS versions, the parent shaper seems to have some of its own queue that "overflow" into the child policy's queues.

So, the implicit LLQ policer only appears to apply to packets actually being queued into the LLQ.  Whereas an explicit policer would apply to all packets that match the class-map.

277
Views
0
Helpful
12
Replies
CreatePlease to create content