[c-nsp] qos plan - advice please

Blake Dunlap ikiris at gmail.com
Fri Aug 30 16:06:28 EDT 2013


So you understand some of the underlying technology: interfaces always work
at line speed, they are either transmitting at 100% or nothing. The percent
full numbers you are talking about are averages of how much of a given time
frame the link was in use, they don't work like water pipes where the water
level only comes up a third of the way while flowing.

Packets either get transmitted immediately across a link at the full speed,
or they wait in line for their turn (and this is called queueing delay).
When you say you are seeing RTT times, are you looking at times of traffic
crossing the devices, or bounced off of them? If bounced, keep in mind that
most all routers have seperate hardware forwarding and cpu control planes,
and all pings et all use the control plane, and they are last priority if
anything is going on. It sounds like you have either congestion issues on
your links, or are measuring it incorrectly coupled with some spiky control
plane issues like maybe some route instability.

If you are talking about actual packets crossing the devices, then yes, you
are seeing congestion, and that is causing packets to sit in queue which is
causing your queueing delay.

Either way, I suggest getting a contractor that knows what he's doing to
help you, or at least show you how this stuff works, because this is a very
deep topic, and a bit above just asking someone on the internet to know
what your problem is without being able to see your network, see what's
going on, and be able to tell you the best qos / network design to fix it.

-Blake


On Fri, Aug 30, 2013 at 2:02 PM, Aaron <aaron1 at gvtc.com> wrote:

> Thanks Blake, sorry about sounding contradictory…. didn’t mean too
> (probably due to me not wording this appropriately)….please bear with me as
> I attempt to learn here…****
>
> ** **
>
> Not sure when/if I said I had “queuing delays” ?****
>
> ** **
>
> However, I am seeing this…. ****
>
> ** **
>
> asr901 (ipsla probe)-------mpls net--------> (ipsla responder) asr9k****
>
> ** **
>
> ….sometimes the asr901 shows 8 ms rtt and sometimes it shows 244 ms.  Big
> difference.  This is during times of no congestion…. And I understand the
> definition of congestion in a best-effort network (a network without any
> qos shaping/policing,etc) is when interfaces are passing traffic at or
> above max capacity of that interface.  So again, my transit interfaces
> between the 901 and 9k are NOT saturated at all… they are barely passing 20
> or 30% of the link capacities along the path.  So my collegues are saying
> “Aaron give me qos so I won’t see 244 ms rtt results in my ipsla
> probes!!”…. but Blake, et al, I’m having trouble with this since I’m under
> the impression that qos is used to solve **congestion** issues, and
> again, if my links aren’t even operating at 20 or 30% load, will qos solve
> that 244 ms rtt ip sla responses ?!****
>
> ** **
>
> Aaron****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Blake Dunlap [mailto:ikiris at gmail.com]
> *Sent:* Friday, August 30, 2013 1:19 PM
> *To:* cisco-nsp at puck.nether.net
> *Cc:* Aaron
>
> *Subject:* Re: [c-nsp] qos plan - advice please****
>
> ** **
>
> You're saying contradictory things: If your links aren't congested, why
> are you seeing queueing delays etc?
>
> Its starting to sound like more request for free consulting here, as
> opposed to any kind of specific questions to fill gaps in knowledge.****
>
> ** **
>
> -Blake****
>
> ** **
>
> On Fri, Aug 30, 2013 at 12:58 PM, Aaron <aaron1 at gvtc.com> wrote:****
>
> Thanks, taking several steps back, here's a question please for the
> group....
>
> Why qos?  Does it do any good IF links aren't congested?  In other words,
> if
> I don't have congestion, is there a reason for it?  ...meaning that if I
> can
> simply add fatter pipes (go from 1 gig to 2 gig etherchannel, or from 10
> gig
> to 20 gig etherchannel) then does fatter pipe solve all my qos problems?
> Latency, delay, jitter, bandwidth needs solved with fatter pipes?
>
> In other words, if I have an sla requirement to provide one-way 5 ms delay
> (nothing more or I'm in violation of sla), AND my interconnections
> throughout my network are NOT congested (utilized at or above line rate)
> AND
> I'm seeing ip sla probes reporting 200 ms latency will qos solve this?
>
> Aaron****
>
>
>
> -----Original Message-----
> From: Mark Tinka [mailto:mark.tinka at seacom.mu]
> Sent: Friday, August 30, 2013 11:20 AM
> To: cisco-nsp at puck.nether.net
> Cc: Aaron; 'Robert Blayzor'
> Subject: Re: [c-nsp] qos plan - advice please****
>
> On Friday, August 30, 2013 05:41:38 PM Aaron wrote:
>
> > Thanks Robert,
> >
> > - (15) asr9k's in core
> > - (40 or 50) asr901's and me3600's
> >
> > That pretty much covers my mpls cloud.... I'm running single area ospf
> > on all those, and mpls on all, and so all of them (9k's, 901's and
> > me's) act as a mix of p's and pe's
>
> I've always supported DiffServ. I've found using RSVP to signal admission
> control to be otherwise heavy (there was a reason it never took off in the
> first place, despite how noble the idea was).
>
> But, your network, your choice :-).
>
> Mark.****
>
> _______________________________________________
> 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