QoS - Policy map Classes order

[jerome.gomez]

Hi all,

i'm wonderring about one point without finding any answer to my question.

Is class order important in policy map definition ?

I know it's important regarding match criteria, but is order important for a kind of priority.

I explain

I have a 1gig interface connected to a 30Mb/s WAN link and following policy on it:

policy-map OUT-interface

class Voice

priority 1024

class Video

bandwidth 2048

class PLM-CYC-HER

bandwidth 6000

class PLM-CYC-DOM

bandwidth 10000

class PLM-CYC-STH

bandwidth 6000

class Data3-1

bandwidth 2048

class Data3-2

bandwidth 5120

class class-default

fair-queue

random-detect dscp-based

where each Classes are not ovelapping (a packet cannot match multiple classes)

class-map match-all Data3-2
match access-group name Data-Class3-2
class-map match-all Data3-1
match access-group name Data-Class3-1
class-map match-all PLM-CYC-STH
match access-group name PLM-CYC-STH
class-map match-all PLM-CYC-DOM
match access-group name PLM-CYC-DOM
class-map match-all Video
match access-group name Video-Class2
class-map match-all Voice
match access-group name Voice-Class1
class-map match-all PLM-CYC-HER
match access-group name PLM-CYC-HER

Last week, during a huge file transfert matching PLM-CYC-DOM, allconnections matching Data-Class3-1 were blocked. By changing order of classes, passing Data3-1 and 3-2 before PLM everything worked fine but i'm not sure this order is important on network behaviour or if i had chance.

Does anybody have an answer/link that address my concern ?

best regards

thanks

[lgijssel]

Hi Jerome,

You have only configured bandwidth statements per class. This defines the MINIMUM bandwidth allocated to that class.

It does nothing to restrict total traffic volume to 30Mb. In order for that, you need to use a shaper for 30Mb:

policy-map Shape-30Mbps

class class-default

  shape average 30000000

  service-policy OUT-interface

Then you need to apply the policy-map Shape-30Mbps to the interface.

Note that this may not be possible on most switches, there only egress policing is supported.

(Apart from the high-end models)

regards,

Leo

[jerome.gomez]

Hi Leo,

thanks for quick answer.

I can deploy such a config (i'm on ISR not Switch)

I thought that in any cases my data classes had respectively at least 2M and 5M. Maybe my mistake

So you are advising a global service policy that police my real traffic and inside a nested one with my existing policy. I'll try this and let you know.

Since one week, no more issue but let's see it

[lgijssel]

I thought that in any cases my data classes had respectively at least 2M and 5M. Maybe my mistake

This your policy does but it does not ensure that overall traffic stays within the WAN limit of 30Mb.

When overall traffic bursts beyond this level, the provider will start dropping packets, generally by policing i.e. indiscriminately. This causes the behavior you observed.

regards,

Leo

[jerome.gomez]

Hi,

it makes sense, i'll try it and let you know.

Regards

[Peter Paluch]

Hi Jerome and Leo,

Just to answer Jerome's original query:

Is class order important in policy map definition ? 

Yes, it is: The IOS QoS Configuration Guide at

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_mqc_ps10591_TSD_Products_Configuration_Guide_Chapter.html#wp1044230

mandates:

A packet can match only one traffic class within a traffic policy. If a packet matches more than one traffic class in the traffic policy, the first traffic class defined in the policy will be used.

Best regards,

Peter

[lgijssel]

Hi peter,

As usual you are fully right. I was merely attempting to resolve the issue behind the reported problem.

The total alloted bw does not increase 30Mb but it was not realized that this is a minimum. Probably in this case with a shaper applied -and no traffic matched by more than one class-map- it would have worked anyway.

One more remark about the order: When considering the order of the classes in a policy map, put the smaller ones and the most important flows at the beginning and always have class-default as the last entry.

regards,

Leo

[jerome.gomez]

Hi Peter,

thanks for your help / time.

The link you sent is exactly what i meant by writing :

"I know it's important regarding match criteria"

regards

[Joseph W. Doherty]

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

Yes, Peter is correct.  Like Leo, I too suspect issue seen was due to overall rate not being controlled, and since OP mentioned "where each Classes are not ovelapping (a packet cannot match multiple classes)", sequence shouldn't be an issue, but still, again, Peter is correct to note this.

On sequencing, Leo also adds a good point (still assuming matches don't overlap), that "most important flows at the beginning" if this means expected match occurrence frequency, I agree as I believe this is a bit more efficient.  (Don't quite understand "smaller ones", though.)

BTW, Leo mentions class-default must be the last entry, but believe I've noticed it can be entered in any sequence but it will still appear last.  (NB: there's also a class-default even if not explicitly defined.)  Likewise, believe I've noticed LLQ classes can be entered in any sequence, but they will appear first (NB: entry sequence of multiple LLQ classes is maintained and can be important).

PS:

Also BTW, although Cisco's and RFC's current QoS recommendation do define, it seems, classes for everything, unless there's a special need, I've found you can often combine classes.  Looking at the original post, I wonder whether all the PLM- and Data- classes really need to be separate, especially if the IOS being used supports per class FQ.

[Joseph W. Doherty]

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

Since I see you've a voice class, some points you might be want to be aware of:

Depending on the IOS version, you might need to tune down the Tc.  I believe, older IOSs default to 25 ms and newer IOSs default to 4 ms.

You may need to tune down tx-ring-limit.

You many need to account for L2 overhead if the shaper is only counting L3 packet sizes.

PS:

Older IOSs, before HQF, on ISRs allow class-default FQ to distort other non-LLQ bandwidths.

I normally recommend against using WRED unless you really understand it.