[c-nsp] QoS Design Question

Rodney Dunn rodunn at cisco.com
Thu Oct 18 10:25:08 EDT 2007


On Thu, Oct 18, 2007 at 10:19:27AM -0400, Patrick Greene wrote:
> Rodney,
> Thanks for the input.  This is strictly hub and spoke traffic with little to
> no spoke-to-spoke activity.
> 
> The only references I can find on "per spoke shaping" refers to DMVPN phase
> 3.  What sort of scaling issues?

I can't remember if the 256 or so class-map limitation still applies.

But you would have to do a hierarchical policy on the hub
and each subclass would match on the remote to shape to that PE-CE speed
with it's child class doing the LLQ/CBWFQ policy.

That doesn't scale very well but if you have a hub connection that
has something like a SIP400 where that type/size of policy can be
done in hardware it will work. I've seen it done on small scales
before where the SP didn't do QOS or the customer didn't know how
to work with them to do it.

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.


config is something like:


service-policy out
 class spoke1
  shape average <speed>
    service-policy cbwfqspoke
 class spoike2
  shape average <speed>
    service-policy cbwfqspoke
etc..

and each spoke class definition has to match on an ACL for
the spoke lan subnet.


Rodney

> 
> Thx,
> Patrick
> 
> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com] 
> Sent: Thursday, October 18, 2007 9:51 AM
> To: Patrick Greene
> Cc: 'Oliver Boehmer (oboehmer)'; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] QoS Design Question
> 
> You can't do it without PE QOS on the last hop PE-CE connection.
> 
> If you are *only* getting spoke traffic from a hub (meaning
> it's a hub and spoke simulated over a multipoint MPLS/VPN topology)
> you could do "per spoke shaping" but that has scale issues.
> 
> Rodney
> 
> On Thu, Oct 18, 2007 at 08:24:32AM -0400, Patrick Greene wrote:
> > You are correct..the topology is 
> > 
> > hub -- PE -- (mpls) -- PE -- spoke
> > 
> > If I set a policy on the hub router to guarantee 10Mbps for LOB
> applications
> > outbound towards the MPLS cloud and if I am telling my spoke router to
> > guarantee 512Kbps for LOB application outbound towards the MPLS cloud then
> > outbound I am all set.  However, for inbound LOB traffic on the spoke
> router
> > the hub (set at 10Mbps) can send more than 512Kbps of LOB traffic and
> > consume the T1 inbound.  On my spoke router, should I be setting my
> > bandwidth guarantees inbound from the MPLS instead out towards the MPLS?
> > 
> > Basically I want to gurantee 512Kbps of traffic for LOB apps in and out of
> > each spoke.  I don't have subinterfaces at the hub for each site to apply
> > policies to so I am stuck with an aggregate policy...or so it seems.
> > 
> > Am I making sense here?
> > 
> > 
> > Thanks for your input.
> > 
> > 
> > -----Original Message-----
> > From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com] 
> > Sent: Thursday, October 18, 2007 3:02 AM
> > To: Patrick Greene; cisco-nsp at puck.nether.net
> > Subject: RE: [c-nsp] QoS Design Question
> > 
> > Patrick Greene <> wrote on Wednesday, October 17, 2007 11:45 PM:
> > 
> > > Thanks for any contributions here.
> > > 
> > > 
> > > 
> > > This is hypothetical and not production.  Assume a single company with
> > > hundreds of remote sites.  With today's MPLS environments you have
> > > 100's of sites(T1's) coming back into a single physical
> > > interface(DS3) on the router. I am applying my QoS policies outbound
> > > on my core router interface to manage my 3 classes of traffic:
> > > voice,LOB apps, and default.   The voice gets 5Mbps, LOB applications
> > > get  10Mbps on and default gets the rest.  The remote sites all have
> > > T1's and I allocate 128Kbps to voice, 512MB to Signaling and LOB
> > > applications, and default for all other apps.  This too is applied
> > > outbound on the serial interface.  How do I keep the default
> > > applications from overrunning the INBOUND LOB applications.   Do I
> > > need to apply my QoS policy  inbound on the Serial interface instead
> > > of outbound? Won't that affect VOIP quality if I don't have outbound
> > > policies.  
> > 
> > not sure if I understand the topology and the problem. Assuming you have
> > 
> >   hub -- PE -- (mpls) -- PE -- spoke
> > 
> > you apply outgoing policies on the hub->PE and on the PE->spoke as well
> > as on the spoke->PE and PE->hub direction (and obviously within the MPLS
> > cloud), you will be able to protect voice, won't you? Not sure what you
> > mean by "overrunning the INBOUND LOB"?
> > 
> > 	oli
> > 
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/


More information about the cisco-nsp mailing list