what is the difference between these 2 qos command sets?

Answered Question
Jun 27th, 2008

command1:

class-map match-all test

match access-group 1

policy-map parent

class test

shape average 3000000

bandwidth 2000

interface FastEthernet0/0

ip address 10.1.1.1 255.255.255.252

duplex auto

speed auto

service-policy output parent

command2:

class-map match-all test

match access-group 1

policy-map child

class test

bandwidth 2000

policy-map parent

class test

shape average 3000000

service-policy child

interface FastEthernet0/0

ip address 10.1.1.1 255.255.255.252

duplex auto

speed auto

service-policy output parent

I have this problem too.
0 votes
Correct Answer by Joseph W. Doherty about 8 years 5 months ago

"If you just take the above example, both the sets will achieve the same result."

Don't believe that's fully correct.

Shapers seem to often actually implement (W)FQ. However, they also seem to minimize or eliminate their own shaper queues when there's a subordinate policy. In command2, the Child's class Test will be a FIFO queue, so, if there's congestion, the output sequencing of the packets could differ between command1 and command2. If command2 had used a child policy with just class-default with FQ defined, then the two implementations sequencing should be more alike.

Another difference between command1 and command2 is the relocation of the bandwidth 2000 statement from the Parent's class Test to the Child's class Test. Bandwidth statements define a weighting factor relevant to all the bandwidth to which the policy is applied to guarantee the defined bandwidth. In command1, the weight would be relative to FastEthernet0/0's actual physical bandwidth, 10 or 100 Mbps. In command2, the weight is relative to the shaper's bandwidth defined in Parent class Test. Further, since command2 doesn't have a bandwidth defined for the Parent's class Test, the example configuration leaves us with the question of how that class will be weighted relative to any other traffic (remember there are still implicit classes for other traffic). Only if your (undefined) access-group 1 matched all traffic would this difference be unimportant.

PS:

(e.g. hierarchal policy most like, but still not exactly the same as, command 1)

command 3:

class-map match-all test

match access-group 1

policy-map child

class class-default

fair-queue

policy-map parent

class test

bandwidth 2000

shape average 3000000

service-policy child

Correct Answer by Pavel Bykov about 8 years 5 months ago

Also some hardware require you to use hierarchical QoS, even though the logic does not require it. This is a requirement for shaping on GSR platform for example.

Or let's say, you have 20 branch locations at 512kbps connected to central site using 100Mbps Fast Ethernet. And you want to shape traffic to every single location, so no traffic leaves central site to any single branch faster than 512 Kbps. Then you would have 1 parent policy map, with 20 parent classes (class will match information unique to branch - for exampel an IP address), each of which will have 1 child policy map that will shape traffic to 512 Kbps (and maybe additionally do some QoS). So effectively you have 20 shapers at 512Kbps each. Like so:

Branch1 IP subnet = 10.0.1.0/24

...

Branch20 IP subnet = 10.0.20.0/24

ip access-list ext BRANCH1

permit ip any 10.0.1.0 0.0.0.255

...

ip access-list ext BRANCH20

permit ip any 10.0.20.0 0.0.0.255

class-map match-any BRANCH1

match access-group name BRANCH1

...

class-map match-any BRANCH20

match access-group name BRANCH20

policy-map CHILD

class class-default

shape average 512000

policy-map PARENT

class BRANCH1

service-policy CHILD

...

class BRANCH20

service-policy CHILD

Then on Central router on WAN interface:

interface fasstethernet 0/1

service-policy output PARENT

This example cannot be done without a hierarchy.

Hope this helps

Correct Answer by n.nandrekar about 8 years 5 months ago

Hi!

The second command set that you have given is an example f hierarchical policy-map.

If you just take the above example, both the sets will achieve the same result. But the real application hierarchical policy-map comes in cases where you have multiple classes in a child policy. Else there is no need.

Application of Hierarchal Policy (second command squense).

Suppose you have to provide Qos for multiple customers going out of the same interface, and also provide different Qos for different types of traffic for the same customer. For this requirement, you will create a parent policy :

Policy Parent

Class cust1 <<<<<< match traffic belonging to cust 1.

shape 2 mbps <<<< suppose this cust has bought 2M bandwidth.

service-policy child_cust1 <<< this will give different qos to different classes within cust 1 traffic.

class cust2 <<<< match traffic for sec cust

shape 1 m

serice-policy child_cust2

.....

and so on..

In child_cust1 you will define qos for that traffic :

policy-map child_cust1

class voip

priority 0.5 mbps

class critical

bandwidth 50%

class data

bandwidth 25%

etc.

So the effect of the policy will be that out of the whole interface bandwidth the traffic for cust 1 will be shaped to 2 mbps according to the parent policy, and cbwfq will be applied to this queued 2mbps traffic for that indivudial cust. the bandwidth % 50 in child policy will reffer to 50% of the shaped 2mbps bandwidth.

Hope this clears your doubts. (pls rate if it does.)

Regards,

Niranjan.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
Correct Answer
n.nandrekar Fri, 06/27/2008 - 01:48

Hi!

The second command set that you have given is an example f hierarchical policy-map.

If you just take the above example, both the sets will achieve the same result. But the real application hierarchical policy-map comes in cases where you have multiple classes in a child policy. Else there is no need.

Application of Hierarchal Policy (second command squense).

Suppose you have to provide Qos for multiple customers going out of the same interface, and also provide different Qos for different types of traffic for the same customer. For this requirement, you will create a parent policy :

Policy Parent

Class cust1 <<<<<< match traffic belonging to cust 1.

shape 2 mbps <<<< suppose this cust has bought 2M bandwidth.

service-policy child_cust1 <<< this will give different qos to different classes within cust 1 traffic.

class cust2 <<<< match traffic for sec cust

shape 1 m

serice-policy child_cust2

.....

and so on..

In child_cust1 you will define qos for that traffic :

policy-map child_cust1

class voip

priority 0.5 mbps

class critical

bandwidth 50%

class data

bandwidth 25%

etc.

So the effect of the policy will be that out of the whole interface bandwidth the traffic for cust 1 will be shaped to 2 mbps according to the parent policy, and cbwfq will be applied to this queued 2mbps traffic for that indivudial cust. the bandwidth % 50 in child policy will reffer to 50% of the shaped 2mbps bandwidth.

Hope this clears your doubts. (pls rate if it does.)

Regards,

Niranjan.

shibindong Fri, 06/27/2008 - 01:56

thanks for your reply!

can i say the nested QoS is just for better programming/structure? is there any other case in which only nested QoS can be used?

n.nandrekar Fri, 06/27/2008 - 02:24

Any requirements where you want to give a specific quality of service to a broad group and want to go more granular to give different Qos to sub-groups within the group, you require Qos.

The example that I told you is the most commonly used scenario. Also any requirements where you want to limit the aggrigate of bandwidth to be used but want to maintain the flexibility to share unused bandwidth within the classes on that aggrigate, you can use H-Qos.

Regards,

Niranjan

Correct Answer
Pavel Bykov Fri, 06/27/2008 - 02:52

Also some hardware require you to use hierarchical QoS, even though the logic does not require it. This is a requirement for shaping on GSR platform for example.

Or let's say, you have 20 branch locations at 512kbps connected to central site using 100Mbps Fast Ethernet. And you want to shape traffic to every single location, so no traffic leaves central site to any single branch faster than 512 Kbps. Then you would have 1 parent policy map, with 20 parent classes (class will match information unique to branch - for exampel an IP address), each of which will have 1 child policy map that will shape traffic to 512 Kbps (and maybe additionally do some QoS). So effectively you have 20 shapers at 512Kbps each. Like so:

Branch1 IP subnet = 10.0.1.0/24

...

Branch20 IP subnet = 10.0.20.0/24

ip access-list ext BRANCH1

permit ip any 10.0.1.0 0.0.0.255

...

ip access-list ext BRANCH20

permit ip any 10.0.20.0 0.0.0.255

class-map match-any BRANCH1

match access-group name BRANCH1

...

class-map match-any BRANCH20

match access-group name BRANCH20

policy-map CHILD

class class-default

shape average 512000

policy-map PARENT

class BRANCH1

service-policy CHILD

...

class BRANCH20

service-policy CHILD

Then on Central router on WAN interface:

interface fasstethernet 0/1

service-policy output PARENT

This example cannot be done without a hierarchy.

Hope this helps

Correct Answer
Joseph W. Doherty Fri, 06/27/2008 - 03:54

"If you just take the above example, both the sets will achieve the same result."

Don't believe that's fully correct.

Shapers seem to often actually implement (W)FQ. However, they also seem to minimize or eliminate their own shaper queues when there's a subordinate policy. In command2, the Child's class Test will be a FIFO queue, so, if there's congestion, the output sequencing of the packets could differ between command1 and command2. If command2 had used a child policy with just class-default with FQ defined, then the two implementations sequencing should be more alike.

Another difference between command1 and command2 is the relocation of the bandwidth 2000 statement from the Parent's class Test to the Child's class Test. Bandwidth statements define a weighting factor relevant to all the bandwidth to which the policy is applied to guarantee the defined bandwidth. In command1, the weight would be relative to FastEthernet0/0's actual physical bandwidth, 10 or 100 Mbps. In command2, the weight is relative to the shaper's bandwidth defined in Parent class Test. Further, since command2 doesn't have a bandwidth defined for the Parent's class Test, the example configuration leaves us with the question of how that class will be weighted relative to any other traffic (remember there are still implicit classes for other traffic). Only if your (undefined) access-group 1 matched all traffic would this difference be unimportant.

PS:

(e.g. hierarchal policy most like, but still not exactly the same as, command 1)

command 3:

class-map match-all test

match access-group 1

policy-map child

class class-default

fair-queue

policy-map parent

class test

bandwidth 2000

shape average 3000000

service-policy child

n.nandrekar Fri, 06/27/2008 - 04:52

Hi Joseph!

Thanks for the input and clarifying on my answer. I was not aware of that intricacy which you stated in the first point. Can you please elaborate on this issue or point to any documentation? My question is, if a shaper does-away with its queues in the presence of subordinate policy, how will it meter the bandwidth?

But I still differ from your second point. How will "weight" come into picture in this scenario when he has defined exact bandwidth using bandwidts syntax? I would have agreed to your reasoning if the bandwidth% or bandwidth remaining % would have been used (which I already have cleared in prev post).

Joseph W. Doherty Fri, 06/27/2008 - 07:35

"My question is, if a shaper does-away with its queues in the presence of subordinate policy, how will it meter the bandwidth?"

It uses the queues of the child policy for metering. If it didn't, there wouldn't be much point in having the child policy since it allows us to define queuing behavior different from what the shaper alone would provide.

"How will "weight" come into picture in this scenario when he has defined exact bandwidth using bandwidts syntax?"

Because even when use absolute values for bandwidth, class flow weights are assigned which would be the based on the absolute value over the maximum available. So, unlike using a %, defined, for instance, 5 Mbps of 10, will result in a different proportion weight vs. 5 Mbps of 100. Both are supposed to guarantee 5 Mbps when all classes are defined for 100% and all classes are congested, but when there's excess available such as one class not demanding its defined share, an absolute 5 Mbps may obtain different ratios of the excess based on the total bandwidth capacity. Remember the special classes on most platforms work with a reserved 25% even when defined classes are using absolute bandwidth values. I.e. one defined class of 1 Mbps vs. another of 5 Mbps will maintain the same ratios, but not to the special traffic classes that use (normal default) reserved 25%.

n.nandrekar Fri, 06/27/2008 - 10:09

Hi!

Thanks a lot for that explanation! It would be very helpful if you can point to any docs which explain the first point in detail.

Regards,

Niranjan

Joseph W. Doherty Fri, 06/27/2008 - 11:14

I don't recall seeing one single document, alone, that covers all the details of the first point.

At the level of detail we're discussing, you often need to look at many documents on the subject area, such as base documentation, tech notes, white papers, etc. (some facts are found looking at a document that's slightly off the subject -- something mentioned in passing). Often you might need to actually watch what a particular platform with specific code actually does (sometimes there's differences between platforms and code versions, not always documented). Sometimes you need to talk with Cisco to obtain additional clarification.

If there's a particular aspect of the first point, where you're hoping there's specific documentation, if you can define it as a specific question, perhaps I might find you a documentation reference that would answer it, or perhaps not, as some points are not documented.

Actions

This Discussion