Re: LLQ

From: Narbik Kocharians <narbikk_at_gmail.com>
Date: Tue, 8 Dec 2009 16:37:21 -0800

Scott,

I never said you did, the confussion is in the IOS, and trust me i have seen
some seriously strange behaviors on different IOSes and as an instructor
some times you don't know what you are suppose to say. So what you do is
avoid the "T" versions when conducting a test all together, "T" stands for
Try again on another IOS.

Some times before i open my mouth in the class i try a gievn feature on 8 -
10 different IOSes and then, read the DOC before i talk about it. Oh NO,
listen i totally agree with the fact that it can get very confusing.

On Tue, Dec 8, 2009 at 4:27 PM, Scott M Vermillion <
scott_ccie_list_at_it-ag.com> wrote:

> I never said the documentation wasn't consistent. ;-)
>
> On Dec 8, 2009, at 5:07 , Narbik Kocharians 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
>
> 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 <http://www.micronicstraining.com/>
> Sr. Technical Instructor
> YES! We take Cisco Learning Credits!
> Training And Remote Racks available
>
>
>

--
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
Received on Tue Dec 08 2009 - 16:37:21 ART

This archive was generated by hypermail 2.2.0 : Sat Jan 02 2010 - 11:11:08 ART