CCNP TSHOOT 6.0 - The Cisco Learning Network
CCNP TSHOOT 6.0 - The Cisco Learning Network
CCNP TSHOOT 6.0 - The Cisco Learning Network
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>CCNP</strong>v6 <strong>TSHOOT</strong><br />
Referring to the above results, the TTCP utility transmitted over 67 million bytes in approximately 106<br />
seconds or about 613 Kilobytes per second (kB/s). As a comparison, the baseline configuration without the<br />
errors in this trouble ticket took approximately 70 seconds to transmit the same amount of data but at a rate of<br />
about 898 kB/s. Different devices and network links produce different results.<br />
Note: You cannot issue any commands on the console of either device until the transfer finishes. <strong>The</strong><br />
transmission can be interrupted at any point in time from the transmitting side using the key combination Ctrl-<br />
Shift-6.<br />
Caution: This utility can overload a router with test traffic. It is not recommended to use it on production<br />
devices. Read the TTCP documentation before using the TTCP utility.<br />
Step 6: Test R3 with load applied.<br />
Note: For this lab, TTCP utility creates a load that lasts 60–120 seconds. <strong>The</strong> actual length of time<br />
depends on the capabilities of the devices and links being used.<br />
On R3, use <strong>Cisco</strong> IOS commands and pings to record the router performance figures simulating a<br />
condition where large file transfers are being transmitted. <strong>The</strong>se results can be compared to the baseline<br />
output (selected baseline information is shown) and the output obtained when using the TTCP utility.<br />
Try to issue the following <strong>Cisco</strong> IOS commands on R3 while TTCP is generating traffic between ALS1 and<br />
DSL2. If it stops, restart the transmit-receive process between switches ALS1 and DLS2. You can also<br />
increase the length of time traffic runs by increasing the send buflen parameter, which defaults to<br />
32768 (for example, you can increase it 65536 or higher).<br />
a. While TTCP is running, ping from PC-B to SRV1 and record the minimum, maximum, and average<br />
round-trip results.<br />
____________________________________________________________________________________<br />
____________________________________________________________________________________<br />
<strong>The</strong> times should be 10 times or more higher than without the TTCP load on R3.<br />
C:\>ping 10.1.50.1<br />
Pinging 10.1.50.1 with 32 bytes of data:<br />
Reply from 10.1.50.1: bytes=32 time=39ms TTL=64<br />
Reply from 10.1.50.1: bytes=32 time=38ms TTL=64<br />
Reply from 10.1.50.1: bytes=32 time=38ms TTL=64<br />
Reply from 10.1.50.1: bytes=32 time=38ms TTL=64<br />
Ping statistics for 10.1.50.1:<br />
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),<br />
Approximate round trip times in milli-seconds:<br />
Minimum = 38ms, Maximum = 39ms, Average = 38ms<br />
b. On Fa0/0, change the period over which the loads are computed to 30 seconds.<br />
interface fa0/0<br />
load-interval 30<br />
c. Issue the show interfaces fa0/0 command and note the values for txload and rxload.<br />
___________________________________________________________________________<br />
R3#show interfaces fa0/0<br />
FastEthernet0/0 is up, line protocol is up<br />
Hardware is Gt96k FE, address is 001b.530d.6028 (bia 001b.530d.6028)<br />
Internet address is 10.1.80.1/24<br />
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,<br />
All contents are Copyright © 1992–2010 <strong>Cisco</strong> Systems, Inc. All rights reserved. This document is <strong>Cisco</strong> Public Information. Page 9 of 32