Re: LLQ

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 cant compare the forwarding rate on a switch vs a router.
>
> Second,
>
> Timeout 0 will dropped all packets on a routers 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
Received on Tue Dec 08 2009 - 16:38:16 ART