Free Play Labs – CCNA Vol 1 Chapter 18
You’ve probably been using ping, traceroute, Telnet, and SSH all through your lab efforts. But maybe not. This next chapter (CCNA Vol 1, Chapter 18) looks at those tools precisely, rather than treating them a brief aside to do some testing. And interestingly, the Cisco IOS ping and traceroute commands have some interesting features, so it’s useful to slow down long enough to try some of those options in lab.
Confused? New to “Free Play” Labs?
The idea is simple: Many students would like to further explore the Examples in the Official Cert Guide. We remove the barriers so you can do just that with the free Cisco Packet Tracer simulator.
The details require some reading. To get your head around what kind of content is here in the blog for these labs, read:
Book: CCNA 200-301 OCG, Volume 1
Title: Troubleshooting IPv4 Routing
What’s in This Post
Chapter Intro: A brief description of the topics in that chapter of the book.
Download Link: Links to a ZIP; the ZIP holds all the .PKT files for this chapter.
Table of PKT files, by Example: A table that lists each example in the chapter, with the files supplied for each. Also lists a note about whether the PKT topology matches the book example exactly or not.
Tips: When we build the files, we come across items that we think might confuse you when trying the examples with PT. We write those notes in this section!
The Cisco IOS ping command sends a message to a host, with the intent that the other host sends a message back. Ditto for the traceroute command. But how do they differ? When might you use one or the other?
Chapter 18 of the CCNA 200-301 Volume 1 book examines those two commands in some detail, along with some additional information about Telnet and SSH. While the chapter discusses minimal configuration, it does explain how to use these tools as EXEC commands to test and verify network operations, so it’s worth taking a few minutes to dig in to understand the tools.
Download the Packet Tracer ZIP File
One .PKT File – But Maybe Two (Duplicate) Toplogies
When building the content for this post, we review the examples in the book and decide whether it makes sense to supply a Packet Tracer (.pkt) file to match the example. If we choose to support an example by supplying a matching .pkt file, the .pkt file includes a topology that matches the example as much as possible. It also includes the device configurations as they should exist at the beginning of the example.
In some cases, the .pkt file shows two instances of the lab topology – one above and one below. We include two such topologies when the book example includes configuration commands, for these purposes:
- Top/Initial: The topology at the top has the configuration state at the beginning of the example.
- Bottom/Ending: The topology at the bottom adds the configuration per the example, so that it mimics the configuration at the end of the example.
Table of .PKT Files, by Example
|Example||.PKT Includes Initial State of Example?
||.PKT Also Includes Ending State of Example?
||Exact Match of Interface IDs?|
To re-create this example, you will need to ping PC B from PC A. To do so, click on the icon for PC A, navigate to a command prompt, and then issue the same ping 172.16.2.101 command (PC B’s IP address).
First, note a typo in the book: The example shows a command prompt for router R2, but the example actually shows output from router R1.
Next, note that the example compares results based on timing and the contents of the ARP table. An empty ARP table on R1 results in output that shows the first ping with only a 4 of 5 success rate, while the second ping shows 5 of 5 because of a full ARP cache. To re-create those conditions in PT: After starting the simulation, using the reload command on both R1 and R2 to reload both the routers, and then issue the two successive ping 172.16.2.101 commands from R1.
The book example shows the traceroute command on MacOS. To test in PT, instead use the Windows tracert command.
Both example 18-7 and 18-8 require a username/password, so use: wendell/odom
Also, note that not all the pings between devices will work. The example does not show any static routes or dynamic routing protocol, so we did not supply either in the configurations. However, you could add static routes or OSPF as an exercise if you like. FYI.