[c-nsp] qos plan - advice please

Fri Aug 30 17:34:17 EDT 2013

Hi Aaron,

Please be aware that asr901 has a relatively slow CPU, which means
that all ip sla probe packets will be competing with every other
router function (except forwarding) for the resource. If you want to
reliably measure the quality of service you provide you should go past
your devices and run the probes on something that doesn't do anything
else.
ASR901 has limited capabilities when it comes to QoS, and it takes
some experimentation to achieve right scheduling.

kind regards
Pshem

On 31 August 2013 08:06, Blake Dunlap <ikiris at gmail.com> wrote:
> 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/****
>>
>> ** **
>>
> _______________________________________________
> 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/