RE: LLQ

Have you tried to configure LLQ on a serial interface on a low to mid level
router?

class-map match-all EF
 match ip dscp ef
!
!
policy-map test
 class EF
  priority 1000

r1# sh run int s0/0
Building configuration...

Current configuration : 200 bytes
!
interface Serial0/0
 ip address 155.1.0.1 255.255.255.0
service-policy output test

r1#sh policy-map int s0/0

 Serial0/0

  Service-policy output: test

    Class-map: EF (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp ef (46)
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 1000 (kbps) Burst 25000 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)
      1 packets, 14 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

See that "Strict Priority" in there? This is on 12.4(19b).

tv

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Edison Ortiz
Sent: Tuesday, December 08, 2009 2:33 PM
Cc: 'Cisco certification'
Subject: RE: LLQ

When using 'Strict Priority' the condition changes.

Example, doing Priority on a SIP/SPA module.

http://www.cisco.com/en/US/docs/interfaces_modules/shared_port_adapters/conf
iguration/6500series/76cfgsip.html#wp1177665

Edison Ortiz

Routing and Switching, CCIE # 17943

  _____

From: Ahmed Elhoussiny [mailto:aelhoussiny_at_gmail.com]
Sent: Tuesday, December 08, 2009 3:19 PM
To: Edison Ortiz
Cc: Cisco certification
Subject: Re: LLQ

Edison,
            Nice quick test, yes from your test the LLQ works as a
conguestion aware, may be some IOS versions got this.

But from some testing on other IOS, it didnt work, Also on IOS XR 3.6.1 it
wasn't congestion aware.

so we can say that :

1- its based on the IOS ver or IOS XR , it may be congestion aware or
not...Its better for the engineering department to test it before
implementaion.

2- If the LLQ is conguestion aware in your OS, you must be very carefull, as
if at any time other classess requtes its garenteed BW your VOIP traffic
will get dropp randommly affecting most of VOIP calls.

TO better control this use CAC to conftol VOIP traffic from the source.

Guys to you got any more ideas

On Tue, Dec 8, 2009 at 9:59 PM, Edison Ortiz <edisonmortiz_at_gmail.com> wrote:

I don't have the original testing at the moment but I quickly pull up a
scenario.

R2 <----> R0 <----> R3

R0 will LLQ traffic from R2 towards R3 - for this example, I lowered the
priority to a minimum value to observe any drops with a simple ping (size
1500 bytes).

R0 config:

class-map match-all EF

 match ip dscp ef

!

!

policy-map WAN_QOS

 class EF

 priority 9

!

R0#sh policy-map interface

 FastEthernet0/1

 Service-policy output: WAN_QOS

   Class-map: EF (match-all)

     0 packets, 0 bytes

     5 minute offered rate 0 bps, drop rate 0 bps

     Match: ip dscp ef (46)

     Queueing

       Strict Priority

       Output Queue: Conversation 264

       Bandwidth 9 (kbps) Burst 225 (Bytes)

       (pkts matched/bytes matched) 0/0

       (total drops/bytes drops) 0/0

   Class-map: class-default (match-any)

     1 packets, 74 bytes

     5 minute offered rate 0 bps, drop rate 0 bps

     Match: any

Generate some traffic from R2

R2#ping

Protocol [ip]:

Target IP address: 10.1.1.2

Repeat count [5]: 10000

Datagram size [100]: 1500

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]: 0xB8

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 10000, 1500-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

On R0:

R0#sh policy-map interface

 FastEthernet0/1

 Service-policy output: WAN_QOS

   Class-map: EF (match-all)

     697 packets, 1055258 bytes

     5 minute offered rate 27000 bps, drop rate 1000 bps

     Match: ip dscp ef (46)

     Queueing

       Strict Priority

       Output Queue: Conversation 264

       Bandwidth 9 (kbps) Burst 225 (Bytes)

       (pkts matched/bytes matched) 2/3028

       (total drops/bytes drops) 2/3028

You will notice some drop rate on the output and some drop was noticed on R2

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!

 but the flow was not completely dropped like a policer.

Let's test with a policer..

On R0:

class-map match-all EF

 match ip dscp ef

!

!

policy-map WAN_QOS

 class EF

   police 9000

On R2:

...

..........................

Feel free to perform your own test as well.

Edison Ortiz

Routing and Switching, CCIE # 17943

-----Original Message-----

From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Tony
Varriale
Sent: Tuesday, December 08, 2009 2:23 PM
To: 'Cisco certification'
Subject: RE: LLQ

I'm aware of what the docs say. I thought this was discussed here and found

that anything over the priority statement was dropped. I could be

remembering incorrectly.

Do you have any of your testing that you care to share publically?

Tony Varriale

Flamboyan, Inc.

C: 630.546.7610

F: 815.717.9436

tvarriale_at_flamboyaninc.com

-----Original Message-----

From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of

Edison Ortiz

Sent: Tuesday, December 08, 2009 12:32 PM

Cc: 'Cisco certification'

Subject: RE: LLQ

The documentation and my testing say otherwise:

"When the device is not congested, the priority class traffic is allowed to

exceed its allocated bandwidth. When the device is congested, the priority

class traffic above the allocated bandwidth is discarded."

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_n1.html#wp1048

842

Edison Ortiz

Routing and Switching, CCIE # 17943

-----Original Message-----

From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of

Ahmed Elhoussiny

Sent: Tuesday, December 08, 2009 1:19 PM

To: Tony Varriale

Cc: Cisco certification

Subject: Re: LLQ

Dear all,

             if LLQ is used for VOIP, it will get dropped/policed in case

the traffic exceeds the LLQ size.

And this in case there is congestion and same if there is no congestion.`

LLQ got nothin to do with congestion, this is based on IOS & IOS XR

features & also my testing while designing QOS for my Mobile operator.

In some references you may find LLQ congestion aware....but this didn't

successfully being implemented till now...

WHY ?

simply imagine u have an LLQ class with 1 M , and no interface BW

congestion.

VOIP traffic increased to reach 2 M, and no drops cuz of no congestion due

to not used BW on other classes...

SO what if the traffic in other queues increased, and reached its 100 %, now

the LLQ will decrease to reach 1 M, and all VOIP calls will get some packets

dropped which will affect most of VOIP calls...

Hope this might help

Thanks & B.regards

Ahmed Elhoussiny,2x CCIE# 21988 (R&S-SP)

Network Consultant & Cisco Academy Instructor

On Tue, Dec 8, 2009 at 6:54 PM, Tony Varriale

<tvarriale_at_flamboyaninc.com>wrote:

> I thought the priority queue won't use the general bucket when it's over

> its

> defined number? Hence, all packets will get dropped.

>

> tv

>

>

> -----Original Message-----

> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of

> Narbik Kocharians

> Sent: Tuesday, December 08, 2009 10:20 AM

> To: Wouter Prins

> Cc: jack daniels; Cisco certification

> Subject: Re: LLQ

>

> If you like the voice traffic to get 1M and 1M ONLY, then, provide LLQ and

> Police that traffic at the same time. Very common.

>

> On Tue, Dec 8, 2009 at 8:10 AM, Wouter Prins <wp_at_null0.nl> wrote:

>

> > Hello Jack,

> >

> > What do you think would happen to the other traffic if the voice traffic

> > was

> > allowed to burst to 2M in a LLQ?

> >

> > Depending on whether the interface is congested or not, the traffic

would

> > be

> > dropped if it exceeds the bw you specify in the priority command. It's

> sort

> > of a conditional policer. The traffic will not end up in the default

> class.

> >

> > 2009/12/8 jack daniels <jckdaniels12_at_gmail.com>

> >

> > > Hi guys,

> > >

> > > Please help me with the understanding of LLQ -

> > >

> > > If I have a link of 2 MB

> > >

> > > and I reserve 1 MB for VOICE ( LLQ) the if voice exceeds 1 MB will it

> be

> > > droppped or be sent in default class.

> > >

> > >

> > >

> >

> > --

> > Wouter Prins

> > wp_at_null0.nl

> > CCIE #25628

> >

> >

> > 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!

> Training And Remote Racks available

>

>

> Blogs and organic groups at http://www.ccie.net

>

> _______________________________________________________________________

> Subscription information may be found at:

> http://www.groupstudy.com/list/CCIELab.html

>

>

> Blogs and organic groups at http://www.ccie.net

>

> _______________________________________________________________________

> Subscription information may be found at:

> http://www.groupstudy.com/list/CCIELab.html

>

>

>

>

>

>

>

>

--
Blogs and organic groups at http://www.ccie.net