Per Site QOS policy with Cisco IOS-XE
Lee
ler762 at gmail.com
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*
>
More information about the NANOG
mailing list