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:iki...@gmail.com] Sent: Friday, August 30, 2013 1:19 PM To: cisco-nsp@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 <aar...@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.ti...@seacom.mu] Sent: Friday, August 30, 2013 11:20 AM To: cisco-nsp@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/