Skip navigation
Cisco Learning Home > Certifications > Service Provider (CCIP) Retired > Discussions


3603 Views 7 Replies Latest reply: Mar 1, 2012 7:27 AM by chomicz RSS

Currently Being Moderated

Hierarchical Queuing and Class-Based-Shaping

Aug 17, 2011 7:02 AM

Norbert Zehetner 7 posts since
Jun 27, 2008

Hi everybody!


I have the following hierarchical QoS configuration and a question in this regard:


class-map match-any voice

match  dscp ef

match mpls experimental topmost 5

class-map match-any system_intern

match  dscp cs6

match mpls experimental topmost 6

class-map match-any gold

match  dscp af42

match mpls experimental topmost 4

class-map match-any silber

match  dscp af32

match mpls experimental topmost 3


policy-map egress_queue

class voice

  priority percent 24

class gold

  bandwidth percent 40

class silber

  bandwidth percent 16

class system_intern

  bandwidth percent 5

class class-default

  bandwidth percent 10


policy-map egress_queue_parent_2000

class class-default

  shape average 1900000

  service-policy egress_queue


interface GigabitEthernetX/Y.zzz

service-policy output egress_queue_parent_2000


Assuming that there is for instance 300% congestion of the 1,9 MBit/s and every class is overwhelmed.

Will the shaper take care of the DSCP values or rather the priority queue for which packets to drop?


Or is it this way, that the router shapes the traffic to 1,9 MBit/s (and therefore has to drop packets) regardless of what DSCP values this packets are and than makes queuing inside the 1,9 MBit/s for the configured classes and DSCP values? Thus queuing takes place after shaping...?


Thanks for your help!


  • Conwyn 7,914 posts since
    Sep 10, 2008
    Currently Being Moderated
    1. Aug 17, 2011 11:13 AM (in response to Norbert Zehetner)
    Re: Hierarchical Queuing and Class-Based-Shaping

    Hi Norbert


    try show policy-map int. You can see what is happening.


    Regards Conwyn

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,396 posts since
    Oct 7, 2008

    1.  The shaper will shape traffic to 1.9M, but WITHIN that 1.9M, you'll get:


    24% of your traffic to be voice.  Going first.  The policer shouldn't kick in here because it's being shaped before it gets to this policy.


    You have to look at the order.  Your traffic queues all flow into the policy.  The parent policy is a shaper.  It feeds to the sub-queues (sub-policy).  So the traffic coming in to the sub-queues has already been viewed/handled once.


    2.  FIFO to the shaper, then whatever order to the sub-queues.  So the behavior may seem "random".



  • rehanp 30 posts since
    Jun 12, 2008

    Interestingly, I'm trying to lab out pretty similar configuration but working on an overall bigger issue.


    Scott, the following may raise some questions and I'll be glad if we can agree on certain notions here.


    First, if we use percentage command to allocate bandwidth in the child policy, the bandwidth is actually calculated as a percentage factor of the CIR specified in the 'shape' command in the parent policy.


    Second, I can see packet drops in my LLQ once I generate more traffic than the outgoing CIR (specified in the shape command of the parent policy). This means the policer comes into action when congestion hits. And believe you me guys, I'd to work my way to generate more traffic incrementally to spot that it does drop. Its not a weird-one-timer. Also, It doesn't drop when the traffic matching the LLQ exceeds its allocated bandwidth percentage (24% above) and other queues haven't yet hit their threshold, so congestion hasn't really kicked off. I believe the excess EF/EXP 5 traffic gets FIFOed into other queues, as per the LLQ concept.


    I'd a general concept established in my mind that child policies are parsed at the process/thread/memory level by the IOS before the parent policies. Thanks to repetitive use of hierarchical policing. Child poicers are processed before parent-policers. An example from End-to-End Qos Book:


    For example, it might be desirable to limit all TCP traffic to 10 Mbps, while at the same time limiting FTP traffic (which is a subset of TCP traffic) to no more than 1.5 Mbps. To achieve this nested policing requirement, hierarchical policing can be used.


    The policer at the second level in the hierarchy acts on packets transmitted or marked by the policer at the first level. Therefore, the second level does not see any packets that the first level drops. The sum of packets that the lower-level policers see is equal to the sum of packets that the higher-level policer transmits or marks. This feature supports up to three nested levels.


    Nested, Hierarchical Policing Example
     Router# sh run
    policy-map FTP-POLICER
       class FTP
        police cir 1500000
          conform-action transmit
          exceed-action  drop
      policy-map TCP-POLICER
       class TCP
        police cir 10000000
          conform-action transmit
          exceed-action  drop
          service-policy FTP-POLICER

    To me, the lower-level policer in the above example is the child policy. So child policer kicks in before the parent one.

    Now when I hit the config getting discussed in this post, using shape instead of police in the parent policy...

    Question: Is it same when we have shaping in the parent policy?

    I was like shaping happens even before queueing so probably my established concept of parsing of child -> first & parent -> second is wrong! If so, then as you said, I shouldn't be seeing any drops for the traffic matching the class called in the LLQ. Aaargh!!!

    And you know, for any other queues (having the bandwidth command) when I push a load of traffic matching to their classes, I see the router saying its running out of buffers and then ultimately it says it has 0 buffers. Shaping!


    I did see drops for non-LLQ classes but can't remember whether it was when shaping process ran out of buffers or in some other test.


    So is it the operations defined in the child policy are undertaken in some sort of sub-queues and then shaping is performed before the overall traffic hits a big fat output queue?




    I also saw this link:



    It clearly says:


    In the following example, the child policy is responsible for prioritizing traffic and the parent policy is responsible for shaping traffic. In this configuration, the parent policy allows packets to be sent from the interface, and the child policy determines the order in which the packets are sent.


    Router(config)# policy-map child

    Router(config-pmap)# class voice

    Router(config-pmap-c)# priority 50


    Router(config)# policy-map parent

    Router(config-pmap)# class class-default

    Router(config-pmap-c)# shape average 10000000

    Router(config-pmap-c)# service-policy child


    However, does this documentation still mean that shaping will happen before voice traffic getting prioritized in LLQ. Don't you think that the ordering has to happen before the packets are sent? If yes, then child policy kicks in first.


    Any way, this link rules out that packets will be sent out randomly.



    Question stands... Will shaping in the parent policy happen before any child policy operations?

  • Mohamed Sobair 340 posts since
    Oct 21, 2008
    Currently Being Moderated
    5. Aug 24, 2011 5:44 AM (in response to rehanp)
    Re: Hierarchical Queuing and Class-Based-Shaping



    In Hierarchical Policy, always the Parent Policy applied with the Shaper command takes precedence over the child policy.


    The LLQ which applied for the child policy should kick in once the traffic has reached the max limit assigned by he shaper, at this point of congestion, LLQ reserves 50% of the shaper bandwidth to Class Voice, So its with no doubt from practical point of view, understanding and as per the NAME implies, In a Nested Policy, the Parent Policy takes precedene over the Child Policy.





  • rehanp 30 posts since
    Jun 12, 2008
    Currently Being Moderated
    6. Aug 24, 2011 8:13 AM (in response to Mohamed Sobair)
    Re: Hierarchical Queuing and Class-Based-Shaping



    I wish you were true man!


    At a general level, saying that in Nested QoS implementations, a parent policy takes precedence over a child policy is incorrect. Please see my hierarchical policiing example above. The 10Mbps TCP Policer kicks in after the 1.5Mbps FTP policer has done its job and TCP policer looks after of not just the FTP traffic but also other TCP traffic types. Source is a Cisco Press book so there is a very less chance that it'll be wrong. Other CCO documentation supports this. Going by the name parent/child is contextual too.


    I truly take the point that shaping is a different beast and hence when we're doing shaping in the parent policy, things may vary. That's the exact reason, I've posted my thoughts.


    And as you said... If the LLQ in child policy kicks in after the shaper in the parent policy has done its job then I won't see any drops in the LLQ. Whatever is sent to the LLQ will already be conforming to the CIR (something which the shaper would've ensured) and hence there won't be any congestion which the LLQ and other queues defined in the child policy (with the bandwidth command) will have to deal with.


    Whatever mixture of packets it may be, there won't be any congestion.


    Lets suppose the shaper does its job first and throws a packet mixture over to the child policy. Since shaping is happening on overall traffic in the parent policy, the child policy may see a random mixture, which contains higher number of voice packets, more than what the LLQ percentage bandwidth can handle. Ok, then so what, they'll get FIFOed into any other queue which has some room. They won't get the priority (not a good thing though) but you won't be seeing any drops on the LLQ.


    If you ask me, how will the other queues will have some room... Well, because of this extra bunch of voice packets, some other traffic classes' packets wont be in that mixture and hence their respective queues will have some room.




    The whole point is that I do see drops on the LLQ... So the above couple of paragraphs are contradicting to what's happening.

  • chomicz 2 posts since
    Apr 1, 2010
    Currently Being Moderated
    7. Mar 1, 2012 7:27 AM (in response to rehanp)
    Re: Hierarchical Queuing and Class-Based-Shaping

    Hi rehanp,


    I think I see where you're coming from. In my opinion you may be looking at it from the wrong perspective (and assuming I'm right about how the queuing works).


    The shaper has is always shaping traffic (to the 1.9Mbps in this example). When we get excess traffic/congestiong the packets get enqueued to their class space with the 'bandwidth' command giving each queue it's weight. The scheduler then dequeues the packets in their weighted order (WRED drops packets within their queues) and the packets are put in the tx_ring. In the end it's still the shaper that sends the traffic within the configured rate... as you mentioned in your post referring that shaping determines the 'amount' and the child policies determine which goes first.


    Using your other example with 2 nested policed policies. If we think of it this way: parent policy drops any excess traffic past 1.9Mbps how will child policy see this excess traffic?


More Like This

  • Retrieving data ...

Bookmarked By (1)