We had a similar problem years ago with a frame-relay <---> IMA setup. The hub end was a multiplexed ATM circuit with PVC's to each site's frame-relay circuit. The IMA speed was equal to the aggregate speed of each site's CIR. It worked great until all the sites were bursting above CIR. VoIP call quality would go really bad when that happened (early mornings mainly.) QoS policies could not be maintained between the frame and ATM sides. Sprint (support contract on the CPE) and MCI (circuits) engineers finally decided to run PPP over the native protocols on each end and then apply QoS to the PPP sessions. That fixed the problem. I am not sure if something like that is possible in your case or not though as I am not familiar with MPLS. I tried to find the config, but I no longer have it. I remember it used virtual templates, but don't remember the specifics. Jason On Thu, May 9, 2013 at 10:40 AM, Wes Tribble <westribble@gmail.com> wrote:
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.haske@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 <westribble@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?
-- Jason Lester Administrator for Instructional Technology Washington County Public Schools Tel: 276-739-3060 Fax: 276-628-1893 http://www.wcs.k12.va.us