Per Site QOS policy with Cisco IOS-XE
Wes Tribble
westribble at gmail.com
Wed May 8 14:54:48 UTC 2013
Tyler,
I would love to implement a policy similar to that one. Unfortunately, I
don't believe you can have two tiers of shaping like that in a policy.
Most of the two-tiered shaping solutions I have seen involve using a VRF to
shape to the aggregate rate and then use a second VRF to shape to the site
rate. This is to get around the three-tier policy limitations.
With that said, if you have something like that configured and working, I
would love to see the config and the "show policy-map interface" output.
That is exactly the kind of policy I was originally looking to implement,
but then I ran into those limitations.
Thanks for the reply. Great idea in concept. If only we could implement.
On Wed, May 8, 2013 at 9:02 AM, Tyler Haske <tyler.haske at gmail.com> wrote:
> If you want to prevent a PE router from deciding which ingress packets to
> drop, the only plan is to send packets to spoke sites at or below the spoke
> line-rate. The only good way to do that is shaping on the hub router.
>
> 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
> ... whatever you typically use here....
>
> Tyler Haske
>
>
>
> On Wed, May 1, 2013 at 5:03 PM, Wes Tribble <westribble at gmail.com> wrote:
>
>> I have a question for the QOS gurus out there.
>>
>> We are having some problems with packet loss for our
>> smaller MPLS locations. This packet loss is due to the large speed
>> differential on our Hub site(150mb/s) in comparison the the branch office
>> locations(single T-1 to 4.5mb/s multilinks). This packet loss only seems
>> to impact really bursty applications like our Web Proxy. I have been
>> around and around with WindStream to give me some extra buffer or enable
>> random early detection on the smaller interfaces in my MPLS network. So
>> far they are unwilling to do a custom policy and none of their standard
>> policies have enough buffer to handle the bursts. They do FIFO tail drop
>> in every queue, so I can’t even choose a policy that has WRED implemented.
>>
>
More information about the NANOG
mailing list