Config Lab: IPv4 Static Routes 3

 In 200-301 V1 Ch16: Router Addresses and Routes, 200-301 V1 Part 5: IPv4 Routing, 200-301 V1 Parts, Config Lab, Config Lab CCNA Vol 1 Part 5, Hands-on

This blog post begins with a router triangle, IP addresses, and working interfaces. All routers can ping their own IP addresses, but the routers only know their own connected routes. You job: Add static routes for the LAN subnets.  Answer coming in a few days; Details below the fold!

All about Config Labs

The blog has a series of lab exercises called “Config Labs.” Each lab presents a topology with the relevant initial configuration for each device. The lab also lists new requirements, after which you should create the additional configuration to meet those requirements. You can do the lab on paper, in a text editor, or use software tools like Cisco Packet Tracer or Cisco Modeling Labs.

Once you have created your answer, you can click various tabs at the bottom of this post to see the lab answers, comments about the lab, and other helpful information.

The Lab Exercise

Requirements

The following figure shows three routers and their IP addresses. The routers all use an initial configuration that matches the three examples listed here as well. Your job is to add static routes to the LAN subnets, per the following specific instructions:

  1. Routers R1 and R2 should use static routes whose configuration refers to an IP address in the command.
  2. Router R3 should use static routes that refer to the outgoing interface in the command.
  3. If your configuration was implemented, all three routers should have a connected route to their own LAN subnet, and a static route to each of the other two LAN subnets.
  4. Do not add static routes for the WAN subnets.

Figure 2: Router Triangle with IP Addresses

interface GigabitEthernet0/0
 no shutdown
 ip address 10.1.87.1 255.255.255.128
!
interface GigabitEthernet0/2/0
 no shutdown
 ip address 10.1.1.129 255.255.255.128
!
interface GigabitEthernet0/3/0
 no shutdown
 ip address 10.1.88.129 255.255.255.128
!

Example 1: R1 Initial Config

 

interface GigabitEthernet0/0
 no shutdown
 ip address 172.16.2.1 255.255.254.0
!
interface GigabitEthernet0/1/0
 no shutdown
 ip address 10.1.1.130 255.255.255.128
!
interface GigabitEthernet0/3/0
 no shutdown
 ip address 172.16.0.1 255.255.254.0
!

Example 2: R2 Initial Config

 

interface GigabitEthernet0/0
 no shutdown
 ip address 10.1.89.1 255.255.255.128
!
interface GigabitEthernet0/1/0
 no shutdown
 ip address 10.1.88.130 255.255.255.128
!
interface GigabitEthernet0/2/0
 no shutdown
 ip address 172.16.0.2 255.255.254.0

Example 3: R3 Initial Config

Answer Options - Click Tabs to Reveal

You can learn a lot and strengthen real learning of the topics by creating the configuration – even without a router or switch CLI. In fact, these labs were originally built to be used solely as a paper exercise!

To answer, just think about the lab. Refer to your primary learning material for CCNA, your notes, and create the configuration on paper or in a text editor. Then check your answer versus the answer post, which is linked at the bottom of the lab, just above the comments section.

You can also implement the lab using the Cisco Packet Tracer network simulator. With this option, you use Cisco’s free Packet Tracer simulator. You open a file that begins with the initial configuration already loaded. Then you implement your configuration and test to determine if it met the requirements of the lab.

(Use this link for more information about Cisco Packet Tracer.)

Use this workflow to do the labs in Cisco Packet Tracer:

  1. Download the .pkt file linked below.
  2. Open the .pkt file, creating a working lab with the same topology and interfaces as the lab exercise.
  3. Add your planned configuration to the lab.
  4. Test the configuration using some of the suggestions below.

Download this lab’s Packet Tracer File

You can also implement the lab using Cisco Modeling Labs – Personal (CML-P). CML-P (or simply CML) replaced Cisco Virtual Internet Routing Lab (VIRL) software in 2020, in effect serving as VIRL Version 2.

If you prefer to use CML, use a similar workflow as you would use if using Cisco Packet Tracer, as follows:

  1. Download the CML file (filetype .yaml) linked below.
  2. Import the lab’s CML file into CML and then start the lab.
  3. Compare the lab topology and interface IDs to this lab, as they may differ (more detail below).
  4. Add your planned configuration to the lab.
  5. Test the configuration using some of the suggestions below.

Download this lab’s CML file!

 

Network Device Info:

This table lists the interfaces used in the lab exercise documentation that differ from those used in the sample CML file.

Device Lab Port  CML Port
R1 G0/2/0 G0/2
R1 G0/3/0 G0/3
R2 G0/1/0 G0/1
R2 G0/3/0 G0/3
R3 G0/1/0 G0/1
R3 G0/2/0 G0/2

Lab Answers Below: Spoiler Alert

Lab Answers: Configuration (Click Tab to Reveal)

Static Routes for LAN Subnets

Check the original post for the requirements. Here sit the answers! Ask questions if you have them.

Figure 2: Router Triangle with IP Addresses

ip route 172.16.2.0 255.255.254.0   10.1.1.130
ip route 10.1.89.0  255.255.255.128 10.1.88.130

Example 1: R1 Static Routes

ip route 10.1.87.0  255.255.255.128 10.1.1.129
ip route 10.1.89.0  255.255.255.128 172.16.0.2

Example 2: R2 Static Routes

ip route 172.16.2.0 255.255.254.0 GigabitEthernet0/2/0 172.16.0.1
ip route 10.1.87.0  255.255.255.128 GigabitEthernet0/1/0 10.1.88.129

Example 3: R3 Static Routes

Commentary, Issues, and Verification Tips (Click Tabs to Reveal)

You need to do a little work before thinking about command syntax. Each router needs two routes: one each for the subnets on the two remote LANs. The lab also tells you that for the forwarding instructions, R1 and R2 should use a next-hop IP address, and R3 should use an outgoing interface. Note that because the topology uses Ethernet WAN links, using the outgoing interface in the ip route commands also benefits from using the next-hop IP address as well.

To that end, R1’s configuration shows ip route commands for the two remote subnets: 172.16.2.0 255.255.254.0 and 10.1.89.0 255.255.255.128. Both use the neighboring router’s IP address as the next-hop address, respectively.

Similarly, R2’s configuration shows ip route commands for the two remote subnets: 10.1.87.0 255.255.255.128 and 10.1.89.0 255.255.255.128. Both use the neighboring router’s IP address as the next-hop address, respectively.

Finally, the ip route commands on R3 refer to the two remote subnets, as expected. They also list both the outgoing interface and the next-hop address. For example, for the route to the subnet connected to router R1, R3’s route lists R3’s G0/1/0 interface, but R1’s 10.1.88.129 address as the next-hop address.

Known Issues in this Lab

This section of each Config Lab Answers post hopes to help with those issues by listing any known issues with Packet Tracer related to this lab. In this case, the issues are:

# Summary Detail
1 PT does not support both the next-hop address and outgoing interface in the same ip route command. The configuration on R3, per the lab requirements, uses both the outgoing interface and next-hop IP address. PT will reject an ip route command with both configured. To test in PT,  just use the next-hop address on these commands.

 

Why Would Cisco Packet Tracer Have Issues?

(Note: The below text is the same in every Config Lab.)

Cisco Packet Tracer (CPT) simulates Cisco routers and switches. However, CPT does not run the same software that runs in real Cisco routers and switches. Instead, developers wrote CPT to predict the output a real router or switch would display given the same topology and configuration – but without performing all the same tasks, an actual device has to do. On a positive note, CPT requires far less CPU and RAM than a lab full of devices so that you can run CPT on your computer as an app. In addition, simulators like CPT help you learn about the Cisco router/switch user interface – the Command Line Interface (CLI) – without having to own real devices.

CPT can have issues compared to real devices because CPT does not run the same software as Cisco devices. CPT does not support all commands or parameters of a command. CPT may supply output from a command that differs in some ways from what an actual device would give. Those differences can be a problem for anyone learning networking technology because you may not have experience with that technology on real gear – so you may not notice the differences. So this section lists differences and issues that we have seen when using CPT to do this lab.

Beyond comparing your answers to this lab’s Answers post, you can test in Cisco Packet Tracer (CPT) or Cisco Modeling Labs (CML). In fact, you can and should explore the lab once configured. For this lab, once you have completed the configuration, try these verification steps. 

  1. Confirm all the configured static routes appear in the respective routing tables (show ip route).
  2. Test the routes using both the ping and traceroute commands. You can:
    1. Test from the router CLI using the LAN IP addresses of the other routers. Try the extended versions of the commands to use a router’s LAN interface as the source interface.
    2. Add PCs to the Packet Tracer topology and configure them to match IP addresses in the lab. Then test by using the ping and tracert commands on the PCs.

More Labs with Related Content!

Config Lab: IPv4 Static Routes 2
Config Lab: ROAS Basics 1
Subscribe
Notify of
guest

9 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Jan van der Linden

Dear mr. Odom,
I might be mistaken of course, but the lab commentary seems to be from another lab? It handles about telnet/console login, not the subject at hand.

Furthermore, about the solution regarding example3, router 3. It says the interfaces to be used by the static routes are supposed to be serialports, but the drawing just mentions Gigabit-ports.

Thank you very much,
Jan van der Linden

certskills

Hi Jan,
You are correct. We updated about 75 of the Config Labs to a new format in 2021, this one included. Lots of moving parts in that migration, and we missed some steps with this lab/page. I just updated the various components. Hopefully I caught all the issues. If you see any others, please let me know. Thanks for the help.
Regards,
Wendell Odom

jp

Is the IP address important after the interface listed as next-hop?
ip route 172.16.2.0 255.255.254.0 GigabitEthernet0/2/0 172.16.0.1

I was under the impression that it was:
ip route 172.16.2.0 255.255.254.0 GigabitEthernet0/2/0

Juan Nicolas

Hi Jp.
If you look on the section “Known Issues in this Lab”, It says “PT does not support both the next-hop address and outgoing interface in the same ip route command”. It is related to PT issues vs real software, for best practice in real-life use both interface and next-hop IP address for better results.

certskills

JP,
In case Juan’s comment wasn’t what you were asking…
You can configure an IPv4 static route with an outgoing interface only. Originally, I wrote this lab to require both the outgoing interface and next-hop address. Looking back, I must’ve edited that bit out last time I updated the lab. Anyway…
I talk about this more in the books, but when the outgoing interface is any multi-access network interface like an Ethernet interface, it’s best to also include the next-hop address. Without it, the router (R3 in this case) would ARP for packet destinations that match that route, and both R1 and R2 would have to use a feature called proxy ARP to reply. Many sites disable proxy ARP these days.
Honestly, this lab is trying to give you exercise of many options, but in real life, I’d use the next hop address alone as the better option.
Hope this helps…
Wendell

jp

Okay :), I will have to read about Proxy ARP.

ccnaboudje

hello everyone
please Mr Odom, can you explain me, for example how the R1 knows about the subnet 172.10.16.0/23, the same question about the 2 Routers regarding the subnets they aren’t connected directly
thank you

certskills

Hello again,
For this lab, as worded, R1 would not have a route to the 172.16.0.0/23 subnet (I assume that’s the one you meant). But you could configure one with the same syntax you used for the other labs. Of note, in real networks, for forwarding packets to/from the endpoint devices, the routers do not need routes to remote WAN subnets. So when I made this lab, I asked all to not add those routes just to encourage some thinking about these kinds of subnets.
That said, in real networks, you would almost certainly use a routing protocol instead, and the routing protocol would cause the routers to learn all the routes, including the WAN subnets.

ccnaboudje

thank you so much Mr Odom

9
0
Would love your thoughts, please comment.x
()
x