Joseph, want to say thank you for your help. I very appreciate that. ... View more

A little bit more pictures that I found ... View more

Found some details at cisco.com: The router executes the child policy and then the parent policy. However, if the child policy contains policing with a specified drop policy, the router polices and drops the appropriate traffic at the child level, but does not execute the parent policy on the dropped packets. The router executes the child policy and then the parent policy. As the packets pass through the router's forwarding engine, the router applies the QoS actions specified in the child policy. After child processing completes, the packets are fed back through the forwarding engine and the router applies the parent policy actions to the aggregate traffic. The router executes the parent policy only on the packets that are fed back. If the router dropped some packets during child processing (the child policy contained a drop policy), the router does not execute the parent policy on those dropped packets. ... View more

Joseph, my last 2 questions: - is it correct that physically CBFWQing performs several times in accoring to levels of hierarchy? If hierarchy consists of two levels, first of all child policy is performed CBWFQing with its shapers if specified. Next step parent policy is used and its also invoke CBFWQing with its shaper if specified. I'm trying to realize physical model all of that. - do you have some detailed articles to clear up last misunderstandings? ... View more

Joseph, thank you very much for such a detailed answer. Now I think I'm starting to realize how it works. At least I'm trying.. Could you please correct me if I'm wrong in following conclusions: 1) The aggregated shaper works after scheduling of the traffic. It seems this scheme was confused me, because it looks like shaping here performed before scheduling: 2) Scheduller consults not load of the tx-ring but load of the shaper. 3) In turn the situation that I've described at my first post cannot be, because weights in CBWFQ works like a ratios (proportional coefficients). For example (simplified): transmit 1Mbits within second from CLASS2 then transmit 8,91Mbits from CLASS1 within second etc. If CLASS2 occupy not all bandwidth, the ratios tuned accordingly (free bandwidth goes to the CLASS1), but total bandwidth at the output from the scheduler can't exceed 100% of specified bandwidth (10Mbps). The procedure of proportional partition/sharing works also like a limiter of total bandwith because we have not only relative values but also absolute value at CLASS2. For example, CLASS1 = 99% of free bandwidth that equal to 99% of 90% = 89,1% of total CLASS2 = 10% of total that also can't exceed 1Mbps. class-default = 0,9% of total Because of CLASS2 is limited to some absolute bandwidth, each other also limited. Because each other have related to CLASS2 bandwidths. Right? interface FastEthernet0/0 service-policy output SHAPE ! policy-map QOS       class CLASS1            bandwidth remaining percent 99       class CLASS2            priority 1000 ! policy-map SHAPE      class class-default           shape average 10000000           service-policy QOS P.s.Very  strange for me that Cisco can't describe all aspects of the algorithm  intelligibly and in details. Especially confusing documentation that was  created prior to HQF. Thanks for your help! ... View more

Joseph, still not clear for me how that aggregated shaper works. I mean shaper in class-default that combine all child's traffic. It's important for me to understand not "how generally shaping works" but how that aggregated shaper performs buffering or drops. I'm trying to understand - does classes that was not exceeded its own bandwidths are also affected due to shaping? When the transmission rate exceeds the interface's bandwidth, or the shaper's bandwidth, packets are queued. You wrote that packets are queued. It's also correct to say that packets then will be dropped when shaper's queues are fully filled. The question is - which traffic will be exposed to drop? Also not clear at which stage that shaper are applied. I guess it should meter all volume of traffic after passing a child policies and then...if speed (token bucket etc.) is too much...buffer and drop (for example), but the same question here - which traffic? Fairly between child's classes? Or tail? May be somehow else? Sorry if I not clarify enough. ... View more

Hello Joseph. Thanks for your reply. However if traffic rate exceed capacity of an interface or shaper,  packets are queued, up until queues overflow, then packets are dropped. As I know scheduler takes packets from the queues and place it into tx-ring when tx-ring has free space (we can configure it with tx-ring-limit command), otherwise queues starts to fill in. Do you mean that shaping in the parent level somehow emulate and suppress packets to shaper rate in tx-ring ? Do you know any details regarding technical realization? I can't find detailed explanation. Only one hint I found here: [...] In other words, it is possible that the primary-level policer could drop packets in one class in favor of the other class. This situation would happen because the primary-level policer had enough tokens when the packets for one class arrived, but there were not enough tokens left for the other class. This pattern could continue indefinitely, based on the arrival pattern of the packets. http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/12-4/qos-plcshp-mod-cli-tlhp.html ... View more