Static IP Routing: Cert Guide PT Labs ICND1 Chapter 18
Labs really do help, and labbing what you saw in book examples can even help. Do the labs, and then try and explore beyond the book. Today’s post launches from Chapter 18 of the ICND1 Official Cert Guide. Enjoy!
Advice before You Begin
The big idea is pretty simple: Repeat the Examples in the Official Cert Guide as part of your lab practice for CCNA.
To get your head around what kind of content is here in the blog for these labs, read both of these posts or at least the second post:
After reading those posts, you have the context, so onward to the details!
What’s in This Post
Intro to the Book Chapter: A brief description of the topics in that chapter of the book.
Chapter Examples and .PKT File Reference: A section that lists the examples in the chapter, the .pkt files supplied, and reminders/notes about cases in which we don’t supply all three files for any one example.
Tips and Exceptions: 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!
Intro to the Book Chapter
While Chapter 17 of the ICND1 100-105 Official Cert Guide had only a few examples, Chapter 18, “Configuring IPv4 Addresses and Static Routes” has many. This chapter is the first chapter in the book that gets into detail about configuring IPv4 addresses and the resulting connected and local routes. The chapter also goes into some detail about IPv4 static routes, with many examples on those features.
Chapter Examples and .PKT File Reference
Download this ZIP file to get all the .pkt files for this chapter:
This table tells you what files to expect in the ZIP, and which examples happen to use interface IDs that can be exactly replicated in PT:
| Example | Topology File | Initial Config | Ending Config | Exact Match of Interface ID? |
| 18-1 | None | None | None | N/A |
| 18-2 | None | None | None | N/A |
| 18-3 | Yes | Yes | Yes | Yes |
| 18-4 | Yes | Yes | Yes | Yes |
| 18-5 | None | None | None | N/A |
| 18-6 | Yes | Yes | Yes | Yes |
| 18-7 | None | None | Use 18-6 | Yes |
| 18-8 | Yes | Yes | Yes | Yes |
| 18-9 | None | None | Use 18-8 | Yes |
| 18-10 | None | None | None | N/A |
| 18-11 | Yes | Yes | Yes | Yes |
| 18-12 | Yes | Yes | Yes | Yes |
Reminders: Purpose of Each Type of .PKT File
Topology File: The file contains all devices and cables in the associated figure along with any implied extra devices. The purpose: you never had to add a device or cable. It also contains a few configuration commands that do not affect the example, but help you navigate, for instance, it sets hostnames, passwords (always “cisco”), and interface descriptions.
Initial Config: The file contains everything in the Topology file, plus all configuration listed or implied by the words and figures leading up to the example. That is, it attempts to match the state of the network just before the first line of the example.
Ending Config: The file adds the configuration listed in the example to the Initial Config file – nothing more, nothing less.
Table Lists “None” or Other Strange Terms?
Some examples have all three types of PKT files, however, some Examples have no PT files, and some have a mix of fewer than three files. Here’s a reminder of why. You can check this earlier post for more background if you care to know more.
Initial Config as “None”: If the table says “yes” for the Topology and Ending config, but not the Initial config, then the Topology file has all configuration needed at the beginning of the example.
Ending Config as “None”: The Ending config will be shown as “None” when the example as printed in the book does not have any configuration commands.
All Three Files as “None”: We do not supply .pkt files for that example.
Use x-y: Use Example x-y’s ending config file because the example continues earlier example x-y.
Tips and Exceptions
This section lists our comments about using PT to do the examples. When we built the files, when we saw any behavior that we thought might make it more difficult to perform the example, we noted that fact so we could list it here, in case it might help you with the examples.
Examples 18-3, 18-4
Both examples focus on the router configurations. However, note that the initial PKT files pre-configure the switch port with the switchport mode trunk command, so that both the router and switch use trunking on that link.
Example 18-6
In our testing, the PT 2960 switch did not support layer 3 switching, so we used a PT 3560 switch. Note that the PT 3560 switch does not require a command like sdm prefer lanbase-routing to enable IP routing.
Example 18-7
You can still perform this example in PT, but note that you will see some minor differences. Note that the output on the PT 3560 switch does not include the Local routes shown in Example 18-7, but it does include the connected routes, due to the PT 3560 being a (simulated) older switch with older software. More recent layer 3 switches would include the Local routes.
Example 18-8
Be aware that we have seen some incorrect error messages when performing this example in PT. That is, the router in PT gives an error message that a real router would not. For example:
|
1 2 3 4 |
R1(config)#ip route 172.16.3.0 255.255.255.0 s0/0/1 %Default route without gateway, if not a point-to-point interface, may impact performance R1(config)# |
Example 18-10
The example requires the use of the permanent keyword on the command ip route 172.16.2.0 255.255.255.0 172.16.4.2 permanent, and PT does not support it today.
Example 18-12
This example uses the topology in book figure 18-15; note that some printings list the figure reference as 18-16. FYI.
Dear Wendell,
I’ve configured the L-3 switch and the hosts in the different VLAN’s are now able to ping each other. My question is: I’m able to ping B1 from S1. However I cannot ping the router B1 from any of the hosts from vlans 10 and 20.
I think we need to configure static route on Router B1 for both Vlan 20 & 10 or packets will be discarded if route not found in routing table.
please correct me if I’m wrong.
Mohammed,
Are you talking about example 18-13? If so, and if B1 does not have a route to the subnets on VLANs 10 and 20, that’s a problem. Thanks for the notice. I’ll add it to our Trello board for labs to check – thanks for the heads up!
Wendell
Hello sorry but the directly connected routes are not treated directly using the cef entries? That is, they are not managed by the router circuitry? Otherwise what are local routes for? They are used to avoid that you go to process the request through routing then through the ios system so in my opinion the ping should have worked.
Pietro,
I may be misunderstanding what you are asking. Connected routes and local routes are in the IP routing table. They then result in CEF tables entries, which the router uses for the actual software forwarding process (not hardware.) That said, I’m not understanding what you’re asking. Taking a guess:
No, directly connected routes are not “treated” using CEF entries. Routers create CEF table entries based on routes.
No, IP routing table entries like connected routes are not managed by router circuitry.
Instead, connected routes are added to the IP routing table when (a) the interface has been configured with an address and (b) the interface is in an up/up state. Then (and not discussed in the post, by the way), the router builds a CEF table entry.
Moving on to local routes, honestly I’ve never found a completely satisfying answer to what they are for. You can search around cisco.com and find some references. The most convincing arguments are that it helps clarify the internal process, across Cisco router OS’s (IOS, XE, XR) from IP routing table entries to any/all forwarding optimizations like CEF (a software optimization) or even in hardware forwarding as in some models of routers. For example, have an IP routing table entry for a router’s interface IP address then leads to a CEF entry that lets the CEF forwarding process match that entry, vs an entry for the connected subnet, possibly for a more efficient processing path. (Honestly, IOS already did that in the CEF table before Cisco added local routes… one reason why I think the CEF reasoning to be a little suspect.)
Long story short: proprietary OS, internals, it may not be fully knowable as to why the local routes exist.
Figure 18-8 I did the lab I configured the two routes but when I ping from pc A to pc B the connection isn’t there. What’s the problem?
Hi!
I’ve downloaded the zip file opened a .pkt file and now what? I see no tasks. What am I missing? 🙂
Hi Rocket.
Couple of things that might help. First, all the Cert Guide Packet Tracer Labs are associated with a chapter in a book. This page is from the book for the now-retired ICND1 100-105 book. If you’re working on the CCNA 200-301 exam, you might want to look at this page, for the equivalent chapter in the CCNA 200-301 Official Cert Guide Vol 1: https://blog.certskills.com/cgptl-301-v1-ch16/
That said, if you are using the older books, look at the “Advice before You Begin” at the top of this post, open those two links, and read. That will give the context. Short version: Recreate the examples from the book. This series does not provide lab exercises with steps. Instead, it’s a good start on re-creating the same environment as most of the books’ examples so you can experiment with the config and show commands you find there.
Note that for the current CCNA 200-301 books, the “Cert Guide Packet Tracer Labs” post series is found at https://blog.certskills.com/category/hands-on/pt-labs-200-301/
Hope this helps…
PS You might be interested in the Config Labs as well – those have a more traditional lab document approach with a lab post with configuration requirements and with a matching answers post. Up to you to create the environment in Packet Tracer.