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
priority percent 24
bandwidth percent 40
bandwidth percent 16
bandwidth percent 5
bandwidth percent 10
shape average 1900000
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!
in the described scenario (300% congestion, every class overwhelmed) there will be drops in every queue (class) and this will also be the output of the show policy-map command.
Maybe I have to ask the other way round:
1) The priority queue will police (drop) everything in the voice class above the 24 percent. Also EF traffic within the 24 percent will never be dropped, regardless of the whole congestion because the packets are always prioritized. Correct?
2) What is the dropping behaviour if there is a congestion like 50% gold queue, 50% silber queue and 50% default queue? Or e.g. 100% (2 MBit/s) in both the gold and silber queue? In which manner will the router drop the outgoing packets? Randomly obove the total 1,9 MBit/s shaping rate?
I hope you can figure out what i mean ;-)
It´s quite difficult to explain QoS Problems....
Thanks in advance,
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".
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.
Router# sh run
police cir 1500000
police cir 10000000
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?
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.
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.
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?