Tyler, Tyler,
I already had a case open with TAC on this issue. This is what the CCIE assigned to the case is saying about that type of policy: Hi Wesley, Yes, I’m afraid that configuration is not possible. We can only mark or police traffic on this child policy. You will see the following message when trying to attach the service-policy to the interface: --- ASR10004(config-if)#service-policy output parent_shaper Cannot attach queuing-based child policy to a non-queuing based class *This is what I sent to her:* So this configuration is not possible? policy-map parent_shaper class class-default shape average 100000000 < --- 100Mbps parent shaper. service-policy site_shaper policy-map site_shaper class t1_site shape average 1536000 service-policy qos_global class multilink_site shape average 3072000 service-policy qos_global class class-default service-policy qos_global policy-map qos_global class VOICE priority percent 25 set dscp ef class AF41 bandwidth percent 40 set dscp af41 queue-limit 1024 packets class class-default fair-queue set dscp af21 queue-limit 1024 packets On Thu, May 9, 2013 at 8:33 AM, Tyler Haske <tyler.ha...@gmail.com> wrote: > Wes, > > The earlier policy doesn't use bandwidth commands, hence, it doesn't > *subscribe* anything. The only thing it does is ensures that individual > sites do not exceed their shaped rate. You could add bandwidth statements > if you wanted to ensure a certain site always is guaranteed a certain > amount of bandwidth from the parent shaper. You can't oversubscribe with > the bandwidth command. > > > policy-map parent_shaper > class class-default > shape average 100000000 > service-policy site_shaper > > policy-map site_shaper > class t1_site > shape average 1536000 > bandwidth percent 1 > > service-policy qos_global > class multilink_site > shape average 3072000 > bandwidth percent 2 > service-policy qos_global > class class-default > bandwidth percent 97 > service-policy qos_global > > policy-map qos_global > ! ... whatever you want here. > > This would make sure that large sites don't stare out small spoke sites > for bandwidth. > > On Thu, May 9, 2013 at 8:58 AM, Wes Tribble <westrib...@gmail.com> wrote: > >> Thanks for the information Tyler, I will have to play around with that >> kind of policy in my lab. What would you suggest if you are >> oversubscribing the interface? With the child policy inheriting the >> bandwith of the parent shaper, wouldn't I run out of bandwidth allocation >> before I built all the shapers for all of my 29 sites? >> >
