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