Re: LLQ

I forgot to answer your last question.

I always believe the IOS, it never lies. But the question is which IOS? as
you know we can NOT just go in there and change the IOS because we are
comfortable with it (Normally a career move, out of the door) so i test as
much as i can in a test environment using their IOSes and so forth before
implementing it. hahahahaha i see where you are going with that.....

On Tue, Dec 8, 2009 at 4:21 PM, Ahmed Elhoussiny <aelhoussiny_at_gmail.com>wrote:

> 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 <http://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
>

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