Free Play Labs – CCNA Vol 1 Chapter 16
CCNA 200-301 Volume 1 Chapter 16 has several good examples you can recreate in Packet Tracer (PT). This chapter focuses on IPv4 routing, both the concepts and some of the related configuration. It includes concepts and configuration for IPv4 addresses and the resulting connected IPv4 routes, along with static IPv4 routes. This chapter explains some of the most critical content in the book. As with all posts in this series, look for advice and tools to help you recreate this chapter’s examples. Enjoy!
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: Configuring IPv4 Addresses and Static Routes
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!
By default, Cisco routers enable IPv4 routing. However, before a router routes packets, it needs some routes in its routing table, and getting those routes to appear does require some new configuration. In particular, Cisco routers will add IPv4 routes to their respective routing tables based on these three sources:
- Connected routes, as a result of interface IP address configuration.
- Static routes, as a result of the ip route command.
- Routing protocols, as a result of an IP routing protocol running on multiple routers.
This chapter discusses the first two reasons in some detail. PT supports the commands related to both, so jump and look at the results of configuring IP addresses and static routes.
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?|
|16-7||Not Supplied||Not Supplied||N/A|
|16-8||Not Supplied||Not Supplied||N/A|
|16-9||Not Supplied||Not Supplied||N/A|
This book example lists output from the show running-config command. However, in a small departure from our normal process, to make it more meaningful to repeat, we made the PT file with both an initial and ending topology/config. That means you can add the configuration to the initial configuration topology at the top.
Also, note that you may need to add the no shutdown command under each interface to enable the interfaces in PT.
To populate the ARP table, which will then let PT show the same output as in the book example, you should ping from router R1 to PC1 with the ping 172.16.1.9 command.
Also, note the book has a typo in the example: The example is from R1, but the command prompt shows R2. Change “R2” in the example to “R1”.
This example shows a case in which the OSPF-learned route has failed, so router R1 instead uses a floating static route. You can experiment further in lab by:
- Opening the CLI of router R2
- Getting into configuration mode for interface G0/1
- Alternating the no shutdown and shutdown commands
When R2’s G0/1 is enabled, the R1-R2 link should work, OSPF should work over that link, and R1 should use an OSPF-learned route over that link. When disabled, R1 should use the floating static route instead.
Note: It does take some time for OSPF to converge (about 60 seconds in our testing.)
Note that this example is based on Figure 16-12 (not 16-13 as noted in the book).
We do not supply a PKT file for this example because it focuses on the permanent keyword at the end of the ip route command, and PT does not support the permanent keyword.
This example focuses on overlapping routes. We did not supply a PKT file because PTs implementation of the show ip route ospf command omits the prefix-style mask for each route.