Thank you for agreeing with what I was saying all along (even though
it kind-of contradicts your previous burst statement) ;-)
Now, testing LLQ is tricky and making calls is not exactly the best
way to test it, should you intend to use it for something other than
voice. Any throughput, queueing, performance testing is best left to
the professional tools designed for that purpose. Human ears are not a
good tool :-).
For anyone with (serious) production concerns about the LLQ and a
(serious) testing budget, I can only highly recommend Spirent
SmartBits or TestCenter products. They are *unparalleled* to what
you'll be able to learn about your routers and switches and their
(lack of) performance... :-)
-- Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor - IPexpert On Tue, Dec 18, 2012 at 3:09 PM, Narbik Kocharians <narbikk_at_gmail.com> wrote: > Totally agree with what was stated in that link. > We have to remember that PQ, CBWFQ, are all congestion management tool. but > the best way to test LLQ is to actually make calls and test the quality. > > On Tue, Dec 18, 2012 at 2:40 PM, Joe Sanchez <marco207p_at_gmail.com> wrote: >> >> Here is a great view: >> >> >> http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/pqcbwfq.html#wp5329 >> >> JS >> >> On Tue, Dec 18, 2012 at 3:28 PM, Marko Milivojevic <markom_at_ipexpert.com> >> wrote: >>> >>> For fun, I added another source of the traffic and lowered bandwidth >>> on the interface to 768000 (in an attempt to actually create a >>> congestion). This is by no means an exhaustive test of LLQ and the >>> quality, but it shows a conditional policer in action. >>> >>> ------------------------------8<------------------------------ >>> !!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!! >>> !!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >>> !.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!! >>> !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!! >>> !!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!! >>> !!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!! >>> !!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!! >>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!! >>> !!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!! >>> !!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! >>> !!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >>> !.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!! >>> !!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!! >>> !!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!! >>> !!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!! >>> !!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!! >>> !!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!! >>> !!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!! >>> !!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! >>> ------------------------------8<------------------------------ >>> >>> If you look closely at the pattern of drops above, you will observe >>> the regular intervals at which they appear. This *can* be an indicator >>> of active traffic conditioner. Let's see what our policy says. Keep in >>> mind that the other traffic generator is much more aggressive than the >>> first (timeout 0). >>> >>> ------------------------------8<------------------------------ >>> R2#show policy-map interface Serial0/2/0 output class PRIORITY >>> >>> Serial0/2/0 >>> >>> Service-policy output: LLQ >>> >>> queue stats for all priority classes: >>> >>> queue limit 64 packets >>> (queue depth/total drops/no-buffer drops) 0/0/0 >>> (pkts output/bytes output) 158281/238054624 >>> >>> Class-map: PRIORITY (match-all) >>> 344671 packets, 518385060 bytes >>> 30 second offered rate 10173000 bps, drop rate 9649000 bps >>> Match: protocol icmp >>> Priority: 100 kbps, burst bytes 2500, b/w exceed drops: 186359 >>> ------------------------------8<------------------------------ >>> >>> The problem is that this test is flawed when it comes to reproducing >>> the real congestion, as here we also have to take into account that >>> the traffic is arriving from the same input interface, so we have 1:1 >>> input:output mapping (again, something I mentioned very early in this >>> thread as an important factor). >>> >>> I could spend even more time labbing it up for you, but I suppose I've >>> done enough train-the-trainer for one day :-). >>> >>> -- >>> Marko Milivojevic - CCIE #18427 (SP R&S) >>> Senior CCIE Instructor - IPexpert >>> >>> On Tue, Dec 18, 2012 at 1:16 PM, Marko Milivojevic <markom_at_ipexpert.com> >>> wrote: >>> > On Tue, Dec 18, 2012 at 1:14 PM, Narbik Kocharians <narbikk_at_gmail.com> >>> > wrote: >>> >> How did you prove that LLQ kicks in during congestion? How did you >>> >> measure >>> >> the quality of these packets? >>> > >>> > Well, that's not at all what I was testing, as the test was built >>> > specifically to avoid congestion to show how there's no policing when >>> > congestion does not occur. Apples and Oranges. >>> > >>> > Testing the quality of these packets would be difficult (not >>> > impossible) to measure using IOS-only and Voice SLA probes as traffic >>> > generators, but as I said... this was not the point here. >>> > >>> > -- >>> > Marko Milivojevic - CCIE #18427 (SP R&S) >>> > Senior CCIE Instructor - IPexpert >>> >>> >>> Blogs and organic groups at http://www.ccie.net >>> >>> _______________________________________________________________________ >>> Subscription information may be found at: >>> http://www.groupstudy.com/list/CCIELab.html >>> >>> >>> >>> >>> >>> >>> >> > > > > -- > Narbik Kocharians > CCSI#30832, CCIE# 12410 (R&S, SP, Security) > www.MicronicsTraining.com > Sr. Technical Instructor > YES! We take Cisco Learning Credits! > A Cisco Learning Partner Blogs and organic groups at http://www.ccie.netReceived on Tue Dec 18 2012 - 15:15:30 ART
This archive was generated by hypermail 2.2.0 : Tue Jan 01 2013 - 09:36:53 ART