Re: LLQ- help

How did you prove that LLQ kicks in during congestion? How did you measure
the quality of these packets?

On Tue, Dec 18, 2012 at 1:11 PM, Marko Milivojevic
<markom_at_ipexpert.com>wrote:

> Have you tried without RSVP configuration? I remember some correlation
> between RSVP and LLQ/CBWFQ (I'm struggling to remember what exactly).
>
> I used the main interface and relied on Inverse-ARP to tell me the
> DLCI (I was lazy to set-up subinterface). Here's that configuration:
>
> R5:
> ------------------------------8<------------------------------
> interface Serial0/2/0
> ip address 192.168.25.5 255.255.255.0
> encapsulation frame-relay
> frame-relay interface-dlci 502
> frame-relay intf-type dce
> !
> ------------------------------8<------------------------------
>
> In the meantime I modified the LLQ to be less aggressive (I thought
> for a second that being too aggressive may turn off the policer
> entirely), but the result is absolutely the same:
>
> ------------------------------8<------------------------------
> policy-map LLQ
> class PRIORITY
> priority 100
> !
>
> 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) 95487/143612448
>
> Class-map: PRIORITY (match-all)
> 95521 packets, 143663460 bytes
> 30 second offered rate 815000 bps, drop rate 0 bps
> Match: protocol icmp
> Priority: 100 kbps, burst bytes 2500, b/w exceed drops: 3
> ------------------------------8<------------------------------
>
> I think the proof is here, without a shed of a doubt.
>
> Paul - your ball.
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Tue, Dec 18, 2012 at 1:06 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
> wrote:
> > Well, I guess it's not just putting encapsulation frame that does the
> trick,
> > but using some internal DLCI to carry the traffic.
> >
> > The actual config at the router tested is:
> >
> > interface Serial0/1/0
> > description to PSTN
> > no ip address
> > encapsulation frame-relay
> > no keepalive
> > ip rsvp bandwidth
> > !
> > interface Serial0/1/0.121 point-to-point
> > description to BR-1
> > ip address 10.1.6.101 255.255.255.0
> > frame-relay interface-dlci 121
> > ip rsvp bandwidth 48
> >
> > This is an HQ router from a cvoice class I'm teaching right now, so I
> don't
> > know what part of it makes that the LLQ priority does policing,
> > when attached to the main interface.
> >
> > I hope we all learn from this :)
> >
> > -Carlos
> >
> > Marko Milivojevic @ 18/12/2012 17:53 -0300 dixit:
> >
> >> Well, I didn't really want to let the good learning experience go to
> >> waste, so I made my own test bed. Carlos - my findings are different
> >> than yours. I'd really wish to compre the configs.
> >>
> >> So here's a very simple test involving couple of routers:
> >>
> >>
> >> R1--R2--R5
> >>
> >> R2 is running various IOSs (I tried with 12.4(15)T, 12.4(24)T and with
> >> 15.1(3)T4). Since CBWFQ->HQF change was at 12.4(20)T, and I had no
> >> observable difference in behavior, I will assume that indeed my
> >> earlier observation that HQF did not affect LLQ in any way.
> >>
> >> This is the configuration on R2's interface facing R5:
> >>
> >> ------------------------------8<------------------------------
> >> interface Serial0/2/0
> >> bandwidth 2000
> >> ip address 192.168.25.2 255.255.255.0
> >> load-interval 30
> >> clock rate 2000000
> >> service-policy output LLQ
> >> !
> >> ------------------------------8<------------------------------
> >>
> >> As you can see, interface is configured with both physical and logical
> >> bandwidth of 2 Mb/s.
> >>
> >> This is the policy:
> >>
> >> ------------------------------8<------------------------------
> >> class-map match-all PRIORITY
> >> match protocol icmp
> >> !
> >> policy-map LLQ
> >> class PRIORITY
> >> priority 8 32
> >> !
> >> ------------------------------8<------------------------------
> >>
> >> It is configured for the minimum possible values for both the
> >> conditional policer and now infamous burst rate.
> >>
> >> There is no other traffic, excluding occasional CDP and keepalive.
> >> There is no dynamic routing in place.
> >>
> >> Here's the "traffic generator" from R1:
> >>
> >> ping 192.168.25.5 df size 1500 repeat 100000 timeout 1
> >>
> >> Here's the status on R2's input interface, after the ping has been
> >> running for some time (approximately the time it took me to type out
> >> the above text):
> >>
> >> ------------------------------8<------------------------------
> >> R2#sh int gi0/0 | i 30 sec
> >> 30 second input rate 582000 bits/sec, 45 packets/sec
> >> 30 second output rate 581000 bits/sec, 45 packets/sec
> >> ------------------------------8<------------------------------
> >>
> >> Here's the policy:
> >>
> >> ------------------------------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) 26487/39822448
> >>
> >> Class-map: PRIORITY (match-all)
> >> 26499 packets, 39832496 bytes
> >> 30 second offered rate 840000 bps, drop rate 0 bps
> >> Match: protocol icmp
> >> Priority: 8 kbps, burst bytes 32, b/w exceed drops: 12
> >> ------------------------------8<------------------------------
> >>
> >> Let's see if Frame Relay changes anything. R5 is set as FR DCE, R2 is
> >> set as DTE. No other configuration changed.
> >>
> >> ------------------------------8<------------------------------
> >> R2#show interface s0/2/0 | i Encaps
> >> Encapsulation FRAME-RELAY, loopback not set
> >>
> >> 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) 2011/3024544
> >>
> >> Class-map: PRIORITY (match-all)
> >> 2042 packets, 3071044 bytes
> >> 30 second offered rate 536000 bps, drop rate 0 bps
> >> Match: protocol icmp
> >> Priority: 8 kbps, burst bytes 32, b/w exceed drops: 0
> >> ------------------------------8<------------------------------
> >>
> >> I'm really not sure what else I need to do to show the conditional
> >> nature of this policer...
> >>
> >> --
> >> Marko Milivojevic - CCIE #18427 (SP R&S)
> >> Senior CCIE Instructor - IPexpert
> >>
> >> On Tue, Dec 18, 2012 at 12:10 PM, Marko Milivojevic <
> markom_at_ipexpert.com>
> >> wrote:
> >>>
> >>> Didn't you see his previous message, when he tested non-FR interface?
> >>> Go back and check it out...
> >>>
> >>> --
> >>> Marko Milivojevic - CCIE #18427 (SP R&S)
> >>> Senior CCIE Instructor - IPexpert
> >>>
> >>> On Tue, Dec 18, 2012 at 12:05 PM, Paul Negron <negron.paul_at_gmail.com>
> >>> wrote:
> >>>>
> >>>> Actually, I'm not aware that he disproved it. In fact, He proved it
> with
> >>>> Frame Relay by showing you that he was NOT congested and still
> >>>> experienced
> >>>> drops. How did that support my wrong case?
> >>>>
> >>>> For nowlets agree to disagree.
> >>>>
> >>>> When I show you that the burst rate WILL INDEED affect the traffic
> even
> >>>> when
> >>>> the link is NOT congested, You may change your mind or I will if it is
> >>>> proven otherwise.
> >>>>
> >>>> Agreed?
> >>>>
> >>>> Paul
> >>>>
> >>>> Paul Negron
> >>>> CCIE# 14856
> >>>> negron.paul_at_gmail.com
> >>>>
> >>>>
> >>>>
> >>>> On Dec 18, 2012, at 2:53 PM, Marko Milivojevic <markom_at_ipexpert.com>
> >>>> wrote:
> >>>>
> >>>> You are aware that Carlos disproved what you were saying all along,
> >>>> except for Frame Relay? Given how Frame Relay has its own QoS
> >>>> mechanisms (granted, probably not at play here), I don't see how this
> >>>> is supporting your (wrong) case :-)
> >>>>
> >>>> Anyway... Feel free to misunderstand how LLQ works. I'll keep
> >>>> understanding it well and we're all happy...
> >>>>
> >>>> --
> >>>> Marko Milivojevic - CCIE #18427 (SP R&S)
> >>>> Senior CCIE Instructor - IPexpert
> >>>>
> >>>> On Tue, Dec 18, 2012 at 11:40 AM, Paul Negron <negron.paul_at_gmail.com>
> >>>> wrote:
> >>>>
> >>>> Very well done Carlos!!!
> >>>>
> >>>> That burst is pesky and a pain !!!!! This is similar to what I saw in
> my
> >>>> "INVALID TEST"
> >>>>
> >>>> This is the reason why they removed it in IOS-XR as a default.
> >>>>
> >>>> Now, I would think that this output should help others in putting this
> >>>> to
> >>>> bed. Any complaints against it would be pure pride and speculation.
> >>>>
> >>>>
> >>>> Paul Negron
> >>>> CCIE# 14856
> >>>> negron.paul_at_gmail.com
> >>>>
> >>>>
> >>>>
> >>>> On Dec 18, 2012, at 11:44 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
> >>>> wrote:
> >>>>
> >>>> Yes, there are policy drops:
> >>>>
> >>>> HQ-1#sh policy-map interface
> >>>> Serial0/1/0
> >>>>
> >>>> Service-policy output: prioUDP
> >>>>
> >>>> queue stats for all priority classes:
> >>>>
> >>>> queue limit 64 packets
> >>>> (queue depth/total drops/no-buffer drops) 0/0/0
> >>>> (pkts output/bytes output) 297/292842
> >>>>
> >>>> Class-map: udp (match-all)
> >>>> 460 packets, 453560 bytes
> >>>> 5 minute offered rate 10000 bps, drop rate 6000 bps
> >>>> Match: access-group name udp
> >>>> Priority: 100 kbps, burst bytes 2500, b/w exceed drops: 163
> >>>>
> >>>> Without the service policy, all traffic flies...
> >>>>
> >>>> -Carlos
> >>>>
> >>>> Marko Milivojevic @ 18/12/2012 13:33 -0300 dixit:
> >>>>
> >>>> Can you post the output of "show frame pvc" when you tested the FR? I
> >>>> would be very careful jumping to any conclusions (which you did not),
> >>>> as something other than the policer could be dropping those packets.
> >>>> Did you see the hit counter increase on the drops in the class?
> >>>>
> >>>> --
> >>>> Marko Milivojevic - CCIE #18427 (SP R&S)
> >>>> Senior CCIE Instructor - IPexpert
> >>>>
> >>>> On Tue, Dec 18, 2012 at 7:26 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar
> >
> >>>> wrote:
> >>>>
> >>>> Just tested this under 15.1.1T @ 2811.
> >>>>
> >>>> Incoming interface fastEthernet, outgoing serial.
> >>>> Monitoring TX on serial via snmp, generating with a script udp traffic
> >>>> at a constant rate.
> >>>>
> >>>> Baseline: 100K and 200K both are seen at TX on serial.
> >>>> Check1:
> >>>> class-map match-all udp
> >>>> match access-group name udp
> >>>> policy-map prioUDP
> >>>> class udp
> >>>> priority 100
> >>>> interface Serial0/1/1
> >>>> service-policy output prioUDP
> >>>> ip access-list extended udp
> >>>> permit udp any any
> >>>>
> >>>> Both 100K and 200K seen on TX on serial.
> >>>>
> >>>> That was my understanding. (no congestion, no policing).
> >>>>
> >>>> But... same code, same config on an interface that has frame relay,
> does
> >>>> drop packets even when not congested.
> >>>>
> >>>>
> >>>> To play with this, all you need is one router (real one, no dynamips
> to
> >>>> test
> >>>> QoS please :), and some time.
> >>>> I can provide a perl script that generates udp traffic. Also copy of a
> >>>> small
> >>>> SNMP interface traffic graphing tool which is handy.
> >>>> (Interface Traffic Indicator, InfTraf.exe
> >>>> Version 1.1.0; April 2004
> >>>> Software by Carsten Schmidt)
> >>>>
> >>>>
> >>>> -Carlos
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Carlos G Mendioroz @ 18/12/2012 06:56 -0300 dixit:
> >>>>
> >>>> May I ? :)
> >>>>
> >>>> It might be that the whole issue is that:
> >>>> -the behaviour changed in some point in time
> >>>> -the behaviour is different in some architecture
> >>>> -some test was done with some issue that drove a false idea on someone
> >>>>
> >>>> I have not tested this latelly, but it used to be the case that the
> >>>> policer would not be there when not congested. Fact, tested by many.
> >>>>
> >>>> I will retest this ASAP to (again ?) be ascertive about it. I respect
> >>>> Paul and it may be that with some code (an some arch) this has
> changed.
> >>>> After all, it would make sense for cisco to impose a policer on a
> >>>> priority queue always, because that's how most people believe it would
> >>>> behave.
> >>>>
> >>>> The burst size may just be a measurement parameter. After all, instant
> >>>> rate is always input interface speed, right ? You for any throughput
> >>>> metering, you need some time slots, which might not be aligned, and
> some
> >>>> bursting slack.
> >>>>
> >>>> As to whether there is or not a queue, it would be very hard to be
> >>>> conclusive, because the TX ring will always behave as one. But what
> >>>> difference would it make, or if it would be needed at all given that
> >>>> it is priority and should be below the output if rate, I don't know
> nor
> >>>> care :)
> >>>>
> >>>> I would like this NOT to be taken offline. We all can learn. I would
> >>>> also like to everyone to agree to a self imposed rate limit, may be
> >>>> exponential, to filter any impulse driven answer. It's an important
> >>>> subject, IMHO.
> >>>>
> >>>> -Carlos
> >>>>
> >>>>
> >>>>
> >>>> Marko Milivojevic @ 18/12/2012 02:14 -0300 dixit:
> >>>>
> >>>>
> >>>> Oh, I understand it very well... This has *nothing* to do with burst,
> >>>> as I said hours ago... :-) It has something to do when a strict
> >>>> scheduler is in effect. It's in effect when software queueing is in
> >>>> effect and is in effect when lower layer (for the lack of better term
> >>>> - TX, parent shaper) signal they are congested (TX) or they exist
> >>>> (shaper).
> >>>>
> >>>> Now, your message I'm responding to clearly shows you really
> >>>> misunderstand how CBWFQ works. There is no policer there. Conditional
> >>>> policer exists only in the LLQ. Unfortunately, I'm off to watch The
> >>>> Hobbit now, so I'll have to explain better in couple of hours.
> >>>>
> >>>> PRIORITY keyword does not create a "PRIORITY QUEUE". It creates LLQ,
> >>>> which I downright * refuse* call by the term used in IOS for something
> >>>> else.
> >>>>
> >>>> If you're curious. Create LLQ with 2 Mb/s priority. Send 10 Mb/s of
> >>>> the traffic that matches, but *no* other traffic. Ensure that you're
> >>>> not oversubscribing the outgoing interface. What will happen?
> >>>>
> >>>> --
> >>>> Marko Milivojevic - CCIE #18427 (SP R&S)
> >>>> Senior CCIE Instructor - IPexpert
> >>>>
> >>>>
> >>>> On Mon, Dec 17, 2012 at 9:03 PM, Paul Negron <negron.paul_at_gmail.com>
> >>>> wrote:
> >>>>
> >>>>
> >>>> Marko,
> >>>>
> >>>> There are 2 distinct things in play for LLQ.
> >>>>
> >>>> 1) CBWFQ scheduler- This operates exactly the way you have been
> >>>> stating the entire time. Congestion must be in effect for this
> >>>> scheduler to be operating effectively.
> >>>>
> >>>> 2) The priority Class- I think you are very mistaken about this part
> >>>> of LLQ. The fact that you did not understand the "Burst" proves this.
> >>>> Not that this is a bad thing. SO what if you did not know. Does not
> >>>> mean I think less of you.;-)
> >>>>
> >>>> You keep speaking about LLQ from only one of the above perspectives.
> >>>>
> >>>> I understand the multiple input interfaces deal. I was not testing
> >>>> the Queuing, that is very straight forward.
> >>>>
> >>>> I was testing the Policer in the Priority Class. Ya know the part
> >>>> that makes LLQ different from CBWFQ. You are speaking as if they
> >>>> behave the same when they don't.
> >>>>
> >>>> I think I see where we MAY be speaking past each other but let me
> >>>> clarify. I was making a point so EVERYONE would understand how the
> >>>> Priority Q works which is very different then what MOST people think.
> >>>> The statement from the point I was referencing was about the
> >>>> "PRIORITY" keyword, which means it is participating as a Priority
> Queue.
> >>>>
> >>>> Paul
> >>>>
> >>>> Paul Negron
> >>>> CCIE# 14856
> >>>> negron.paul_at_gmail.com
> >>>> 303-725-8162
> >>>>
> >>>>
> >>>>
> >>>> On Dec 17, 2012, at 11:33 PM, Marko Milivojevic <markom_at_ipexpert.com>
> >>>> wrote:
> >>>>
> >>>> And mind you :-). I was not the one who talked about flows. I talked
> >>>> about different interfaces or classes in the same policies. Two flows
> >>>> in the same queue coming from the same input interface be it 1 or 19
> >>>> phones is still 1 input 1 output. To see the queueing, you need
> >>>> multiple input interfaces. Think of a Y.
> >>>>
> >>>> --
> >>>> Marko Milivojevic - CCIE #18427 (SP R&S)
> >>>> Senior CCIE Instructor - IPexpert
> >>>>
> >>>> On Mon, Dec 17, 2012 at 8:31 PM, Marko Milivojevic
> >>>> <markom_at_ipexpert.com> wrote:
> >>>>
> >>>>
> >>>> Paul,
> >>>>
> >>>> If there was no congestion on the TX ring, there was no LLQ. TX ring
> >>>> congestion is what signals to IOS that software queueing needs to be
> >>>> engaged. Your test was flawed, sorry to say.
> >>>>
> >>>> --
> >>>> Marko Milivojevic - CCIE #18427 (SP R&S)
> >>>> Senior CCIE Instructor - IPexpert
> >>>>
> >>>> On Mon, Dec 17, 2012 at 8:25 PM, Paul Negron
> >>>> <negron.paul_at_gmail.com> wrote:
> >>>>
> >>>>
> >>>> I have tested it precisely!
> >>>>
> >>>> I put Voice traffic into the Priority Class and left the burst to
> >>>> default.
> >>>>
> >>>> I placed enough voice calls to equal the amount of traffic I used
> >>>> with the
> >>>> "priority" command (4 calls at 32K each/NO VAD enabled). ALL
> >>>> traffic passed
> >>>> and was not rejected. I placed a 5th call and it also went through
> >>>> with no
> >>>> problem because it did not exceed the burst rate parameter (Voice
> >>>> is not
> >>>> bursty). The second I placed another call, ALL of the Voice flows
> >>>> were
> >>>> negatively impacted. The priority class began dropping traffic! It
> >>>> reacted
> >>>> as if it was receiving burst traffic that exceeded what it would
> >>>> allow.
> >>>>
> >>>> When I extended the Burst parameter, ALL of the Voice call issues
> >>>> cleared
> >>>> up.
> >>>>
> >>>> There was NO congestion on the transmit ring at ANY time during
> >>>> this test.
> >>>>
> >>>>
> >>>> I also performed the same test with Live Video but the results were
> >>>> devastating due to the extreme Bursty nature of the traffic I was
> >>>> using. I
> >>>> needed to extend the "BURST" parameter extensively due to it's
> >>>> extreme
> >>>> restrictive default.
> >>>>
> >>>> This is why some people misspeak and say that the Priority class is a
> >>>> maximum value. It's true in that it binds the high end bandwidth
> >>>> but it does
> >>>> ALLOW you to burst and squeeze a little bit more by default. It's
> >>>> just
> >>>> REALLY restrictive. It does not enforce the 1 to 2 second
> >>>> recommendation.
> >>>>
> >>>> I still disagree with your example of where you " MAY SEE"
> >>>> queueing of
> >>>> packets since I have NOT been able to prove it to this point. I
> >>>> did not ask
> >>>> you to show me the packets to be confrontational or argumentative. I
> >>>> actually thought I was going to learn something in this
> >>>> conversation about
> >>>> how the Priority Queue actually buffers packets. I don't know what
> >>>> command
> >>>> you used to verify this.
> >>>>
> >>>> This is why I am NOT confused about how LLQ works. I understood
> >>>> what the
> >>>> BURST parameter actually does. I am NOT guessing.
> >>>>
> >>>> Policing will impose its constraint weather you are congested on
> >>>> the TX ring
> >>>> or NOT. Same goes for Shaping!
> >>>>
> >>>> Paul
> >>>>
> >>>> Paul Negron
> >>>> CCIE# 14856
> >>>> negron.paul_at_gmail.com
> >>>>
> >>>>
> >>>>
> >>>> On Dec 17, 2012, at 10:19 PM, Marko Milivojevic
> >>>> <markom_at_ipexpert.com> wrote:
> >>>>
> >>>> On Mon, Dec 17, 2012 at 7:11 PM, Marko Milivojevic
> >>>> <markom_at_ipexpert.com>
> >>>> wrote:
> >>>>
> >>>>
> >>>> Yeah, I've seen that in the command reference as well. It's not
> >>>> exactly well documented what it does.
> >>>>
> >>>>
> >>>> What I suspect though (and this is purely speculation) is that it
> >>>> allows the traffic to burst for the specified time when the LLQ is
> >>>> engaged, which means when TX ring (or other choke point, i.e. shaper
> >>>> in the parent class) trigger a congestion. Since there's no LLQ when
> >>>> there's no congestion, I don't see how this parameter is at all
> >>>> relevant when LLQ is not active. That's the thing with your statement
> >>>> about 30 seconds that I mostly disagree with.
> >>>>
> >>>> --
> >>>> Marko Milivojevic - CCIE #18427 (SP R&S)
> >>>> Senior CCIE Instructor - IPexpert
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
> >>>>
> >>>>
> >>>> --
> >>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
> >>>>
> >>>>
> >>>>
> >
> > --
> > Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>

--
*Narbik Kocharians
*CCSI#30832, CCIE# 12410 (R&S, SP, Security)
*www.MicronicsTraining.com* <http://www.micronicstraining.com/>
Sr. Technical Instructor
YES! We take Cisco Learning Credits!
A Cisco Learning Partner
Blogs and organic groups at http://www.ccie.net