Re: LLQ

Thanks Narbik, but trust me , it doesn't always work as cisco doc says.

it may be the case for 12.2 & some 12.4 T......

So its better to use a policer + priority cmds to enable both LLQ & in the
same time not affecting VOIP in case of other classes needs its min.
guaranteed BW.

What do u think, if you have 12.2 and need to enable LLQ, will u just enable
LLQ via priority command, or also use policing cmds to garentee VOIP when
there is a conguestion variation, and saving your self from the headec of
conguestion aware/not aware issue ?

On Wed, Dec 9, 2009 at 2:07 AM, Narbik Kocharians <narbikk_at_gmail.com> wrote:

> Guys/Ladies,
>
> Read this doc, its pretty good:
>
>
> http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfconmg_ps1
> 835_TSD_Products_Configuration_Guide_Chapter.html#wp1003189<http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfconmg_ps1%0A835_TSD_Products_Configuration_Guide_Chapter.html#wp1003189>
>
> Read the section starting with:
>
> *Priority traffic metering has the following qualities:*
>
> It is much like the rate-limiting feature of CAR, *except that priority
> traffic metering is only performed under congestion conditions*. *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.*
>
> It is performed on a per-packet basis, and tokens are replenished as
> packets are sent. If not enough tokens are available to send the packet, it
> is dropped.
>
> It restrains priority traffic to its allocated bandwidth to ensure that
> nonpriority traffic, such as routing packets and other data, is not
> starved.
>
>
>
> On Tue, Dec 8, 2009 at 3:38 PM, Scott M Vermillion <
> scott_ccie_list_at_it-ag.com> wrote:
>
> > Glad I could help a small bit if I did Ed.
> >
> > Over the years, based on all of the threads here and the test results
> > that have been posted here, I have been persuaded that there are
> > likely many variations of QoS behavior throughout the many versions
> > and releases of IOS. I like the earlier post that suggested we would
> > probably do well to thoroughly lab test any anticipated outcome or
> > behavior prior to real-world deployment. I used to be of the belief
> > that overall physical interface congestion was absolutely required
> > before the implicit LLQ policer would kick in (and I believe I may
> > have even posted test results to that effect at one point in the
> > past). But I'm no longer convinced that's necessarily a uniform
> > behavior spanning all IOS.
> >
> > What I am convinced of is that Dynamips is to be treated with a great
> > deal of skepticism when it comes to QoS test results. ;-)
> >
> > Cheers sir,
> >
> > Scott
> >
> >
> > On Dec 8, 2009, at 2:57 , Edison Ortiz wrote:
> >
> > > Hi Scott,
> > >
> > > Thanks for your contribution. I stand corrected on the amount a
> > > router can send.
> > > I failed to notice the input and output stats on the directly
> > > connected switch even if the packets were shown as dropped on the
> > > source router.
> > >
> > > Per your observation and guidance and I checked the switch.
> > >
> > > SW-1#sh int f0/5 | i rate
> > > Queueing strategy: fifo
> > > 30 second input rate 5870000 bits/sec, 485 packets/sec
> > > 30 second output rate 5864000 bits/sec, 484 packets/sec
> > >
> > > With that said, I still want to see the policy-map interface
> > > output from Ron and see if the packets were dropped because of the
> > > police command or just dynamips.
> > >
> > > Regards,
> > >
> > >
> > > Edison Ortiz
> > > Routing and Switching, CCIE # 17943
> > > From: Scott M Vermillion [mailto:scott_at_it-ag.com]
> > > Sent: Tuesday, December 08, 2009 4:51 PM
> > > To: Edison Ortiz
> > > Cc: Cisco certification
> > > Subject: Re: LLQ
> > >
> > >
> > >
> > > Hi Ed,
> > >
> > > I've done this many times on both routers and switches - the 6500
> > > story was just a little anecdote to keep things interesting and to
> > > tie what I was saying back to some real-world circumstance. Also,
> > > this isn't so much about >forwarding< as it is about >sourcing<. So
> > > the bigger/more powerful the CPU, the more Mbps of IMCP Echo
> > > Requests you are likely to be able to generate. But even with the
> > > little guys, you can do fairly well (especially if, as I mentioned
> > > beforehand, you specify a large ICMP Echo Request size along with
> > > timeout zero).
> > >
> > > Yes, you see periods in your below output because you aren't
> > > awaiting any reply (and thus no "!" will be possible). This does
> > > not indicate that the sourcing router dropped its own ICMP traffic
> > > outbound. Rather, it just means it didn't get an Echo Reply in a
> > > span of zero milliseconds. If you repeat that test and watch your
> > > interface counters every couple of seconds, you'll see what I mean.
> > >
> > > And my Dynamips comment was directed more towards what Ron was
> > > attempting (he mentioned using Dynamips for his QoS testing, which I
> > > was just cautioning against).
> > >
> > > Cheers,
> > >
> > > Scott
> > >
> > >
> > > On Dec 8, 2009, at 2:35 , Edison Ortiz wrote:
> > >
> > >
> > > Hi Scott,
> > >
> > > First
> > > You can t compare the forwarding rate on a switch vs a router.
> > >
> > > Second,
> > >
> > > Timeout 0 will dropped all packets on a router s ping:
> > >
> > > R0#ping 150.1.15.1 size 1500 repeat 100000 time 0
> > >
> > > Type escape sequence to abort.
> > > Sending 100000, 1500-byte ICMP Echos to 150.1.15.1, timeout is 0
> > > seconds:
> > > ......................................................................
> > > ......................................................................
> > > ......................................................................
> > > ...................................................................
> > >
> > > Third,
> > >
> > > I used real hardware on my test (masking my serial number just in
> > > case..)
> > >
> > > R0#sh diag
> > > Slot 0:
> > > C2651XM 2FE Mainboard Port adapter, 4 ports
> > > Port adapter is analyzed
> > > Port adapter insertion time 4w5d ago
> > > EEPROM contents at hardware discovery:
> > > Hardware Revision : 4.1
> > > PCB Serial Number : xxxxxxxxxxxx
> > > Version Identifier :
> > > Product (FRU) Number :
> > > Chassis Serial Number : xxxxxxxxxxx
> > > Part Number : 73-7756-06
> > > RMA History : 00
> > > RMA Number : 0-0-0-0
> > > Board Revision : B0
> > > Deviation Number : 0-0
> > > EEPROM format version 4
> > > EEPROM contents (hex):
> > > 0x00: 04 FF 40 03 6F 41 04 01 C1 0B 46 4F 43 30 39 30
> > > 0x10: 38 34 4B 4C 43 89 FF FF FF FF CB 12 FF FF FF FF
> > > 0x20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF C2 0B
> > > 0x30: 46 54 58 30 39 32 30 41 31 39 42 82 49 1E 4C 06
> > > 0x40: 04 00 81 00 00 00 00 42 42 30 80 00 00 00 00 FF
> > > 0x50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> > > 0x60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> > > 0x70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> > >
> > > WIC Slot 0:
> > > Serial 1T WAN daughter card
> > > Hardware revision 1.0 Board revision J0
> > > Serial number xxxxxxxxx Part number 800-01514-01
> > > FRU Part Number WIC-1T=
> > > Test history 0x0 RMA number 00-00-00
> > > Connector type Wan Module
> > > EEPROM format version 1
> > > EEPROM contents (hex):
> > > 0x20: 01 02 01 00 01 5E 68 18 50 05 EA 01 00 00 00 00
> > > 0x30: 98 00 00 00 00 09 11 01 FF FF FF FF FF FF FF FF
> > >
> > > WIC Slot 1:
> > > Serial 1T WAN daughter card
> > > Hardware revision 1.0 Board revision J0
> > > Serial number xxxxxxxx Part number 800-01514-01
> > > FRU Part Number WIC-1T=
> > > Test history 0x0 RMA number 00-00-00
> > > Connector type Wan Module
> > > EEPROM format version 1
> > > EEPROM contents (hex):
> > > 0x20: 01 02 01 00 01 5D FB 79 50 05 EA 01 00 00 00 00
> > > 0x30: 98 00 00 00 00 09 10 01 FF FF FF FF FF FF FF FF
> > >
> > >
> > > Edison Ortiz
> > > Routing and Switching, CCIE # 17943
> > >
> > > -----Original Message-----
> > > From: Scott M Vermillion [mailto:scott_ccie_list_at_it-ag.com]
> > > Sent: Tuesday, December 08, 2009 4:19 PM
> > > To: Edison Ortiz
> > > Cc: 'ron wilkerson'; 'Cisco certification'
> > > Subject: Re: LLQ
> > >
> > > Hey Ed,
> > >
> > > Depending on the platform, you can generate several Mbps of traffic
> > > with ICMP Echo. You simply need to specify the timeout as zero so
> > > that there is no wait for a reply. It helps to specify a large echo
> > > request size as well. The only time I ever saw a 6500 CPU spike to
> > > and remain near 100% was when I used this technique to remotely
> > > troubleshoot a throughput problem (the 6500 being the only "host" on
> > > the network over which I had any control from afar).
> > >
> > > Having said that, this is one area where Dynamips falls flat on its
> > > face; I wouldn't trust any results involving Dynamips and any QoS
> > > function, as there is no physical interface into which and out of
> > > which to clock traffic. Dynamips is OK for practicing the
> > > configuration of QoS, but not for capturing any meaningful results of
> > > said configuration.
> > >
> > > Regards,
> > >
> > > Scott
> >
> >
> > 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
>
>
>
>
>
>
>
>

-- 
Thanks & B.regards
Ahmed Elhoussiny,2x CCIE# 21988 (R&S-SP)
Network Consultant & Cisco Academy Instructor
Blogs and organic groups at http://www.ccie.net