Re: LLQ

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
> 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 - 17:27:08 ART