Re: LLQ

Ahmed,

Some firms are doing the same thing that i recommended, But the reason they
do that is because they don't want Voice traffic to EVER exceed the
configured value in the Priority command.

Thanks M8.
I agree about different behaviors in IOS, totally.

On Tue, Dec 8, 2009 at 4:37 PM, Narbik Kocharians <narbikk_at_gmail.com> wrote:

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