> 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 - 14:50:35 ART
This archive was generated by hypermail 2.2.0 : Sat Jan 02 2010 - 11:11:08 ART