Re: LLQ- help

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