Per Site QOS policy with Cisco IOS-XE

Thu May 2 01:36:36 UTC 2013

On 5/1/13, Wes Tribble <westribble at gmail.com> wrote:
> I have a question for the QOS gurus out there.

cisco-nsp might be a better place to post your question.  But in any
case, this option looks right:
> Another Idea I had was to create a bunch of shaper classes all feeding the
> same child policy for priority queuing and bandwidth reservations based on
> DSCP markings.  I’m just not exactly sure that this is allowed or
> supported.

see http://puck.nether.net/pipermail/cisco-nsp/2007-October/044508.html
  So they just shaped at the hub towards the spoke to prevent overrunning the
  PE-CE link at the spoke. Another advantage was they didnt' waste
  hub-PE bandwidth for traffic that would be dropped at the spoke PE-CE link
  anyway.

which has nothing to do with IOS-XE but does sound like what you're
wanting to do.

Regards,
Lee

>
>                 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.
>
>
>
>                 I am looking for a way to solve the problem on my side.  I
> can create a shaper for the proxy and match off an access-list to the
> smaller sites, but I am either forced to do bandwidth reservations for each
> site, or have multiple sites share the same shaper.  Here is an example of
> what I was playing around with:
>
>
>
> ip access-list extended ProxyT1Sites
>
>  permit tcp any host 10.x.x.x 10.x.x.x 0.0.0.255
>
>  permit tcp any host 10.x.x.x 10.x.x.x 0.0.0.255
>
>
>
> class-map match-any ProxyShaperT1
>
> match access-group name ProxyT1Sites
>
>
>
> policy-map WindStream
>
> class VOICE
>
>   priority percent 25
>
>   set dscp ef
>
> class AF41
>
>   bandwidth percent 40
>
>   set dscp af41
>
>   queue-limit 1024 packets
>
> class ProxyShaperT1
>
>   shape average 1536
>
>   bandwidth percent 1
>
>   set dscp af21
>
>   queue-limit 1024 packets
>
> class class-default
>
>   fair-queue
>
>   set dscp af21
>
>   queue-limit 1024 packets
>
>
>
>
>
> Another Idea I had was to create a bunch of shaper classes all feeding the
> same child policy for priority queuing and bandwidth reservations based on
> DSCP markings.  I’m just not exactly sure that this is allowed or
> supported.  I also would run out of bandwidth allocation on the policy if I
> use the true bandwidth number of 150mb/s. It is on a Gig port so I could
> just take the bandwidth statement off of the interface to give myself
> enough room for all of the shaper allocations.
>
>
>
> Something like this(I am omitting the access-list that matches the branch
> subnet and class map for brevity):
>
>
>
> policy-map PerSiteShaper
>
> class FtSmith
>
>   shape average 1536
>
>   bandwidth 1536
>  service policy Scheduler
> class Dallas
>
>   shape average 4500
>
>   bandwidth 4500
>   service policy Scheduler
> class NYC
>
>   shape average 100000
>
>   bandwidth 100000
>   service policy Scheduler
> class-default
>   service-policy Scheduler
>
> policy-map Scheduler
> 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
>
>
>
>
>
>
> Just looking for some ideas that do not involve building tunnels to our
> remote offices.  Thanks in advance,
>
>
>
> *Wes Tribble*
>