[162920] in North American Network Operators' Group
Re: Per Site QOS policy with Cisco IOS-XE
daemon@ATHENA.MIT.EDU (Wes Tribble)
Wed May 8 10:55:17 2013
In-Reply-To: <CAJEFqDdJkFVWHueCzryYrH6Cj2fmhc7k=-TvP0Kj4DJcD6o9Dg@mail.gmail.com>
Date: Wed, 8 May 2013 09:54:48 -0500
From: Wes Tribble <westribble@gmail.com>
To: Tyler Haske <tyler.haske@gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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@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 spo=
ke
> 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@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 offic=
e
>> locations(single T-1 to 4.5mb/s multilinks). This packet loss only seem=
s
>> 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 dro=
p
>> in every queue, so I can=92t even choose a policy that has WRED implemen=
ted.
>>
>
