Config Lab: IPv4 Addresses 4

Wendell Odom
By Wendell Odom September 10, 2021 15:05

Practice makes memory. So, time for some practice with IPv4 address configuration on routers. This post is a traditional Config Lab exercise: you start with a network diagram and some planned IPv4 subnets. Your job: do some subletting math and configure the router interfaces with the correct IPv4 addresses and masks.

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

This lab asks you to configure all the router IP addresses for the design shown in Figure 1, given a set of requirements. At this point, do not configure static routes or a routing protocol; just configure the IP addresses per the following specific instructions:

  1. Use the subnets as listed in Figure 1.
  2. Routers must use the lowest IP address(es) in each subnet.
  3. If more than one router exists in a subnet, the router with the lower number in the hostname gets the lower IPv4 address. EG, R1 would have a lower IPv4 address than R2.
  4. Hosts should use the lowest IPv4 address in the subnet, with the same tiebreaker concept as stated in #3.

Figure 1: Router Triangle with IPv4 Subnets

Table 1 shows a way to organize the addresses for reference.

Location Address/Mask
R1 G0/0
R1 G0/1
R1 G0/2
R2 G0/0
R2 G0/1
R2 G0/2
R3 G0/0
R3 G0/1
R3 G0/2

Table 1: IPv4 Addresses

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:

The interfaces used in the lab match the interfaces used in CML file.

Lab Answers Below: Spoiler Alert

Lab Answers: Configuration (Click Tab to Reveal)

Answers

Your first task was to calculate the IP addresses to use, based on requirements. For reference, Table 1 lists the results. Note that all subnets sit in class A network 10.0.0.0, but several use different masks, so this design happens to use Variable Length Subnet Masking (VLSM).

Location IP/mask
R1 G0/0 10.1.12.1 /29
R1 G0/1 10.1.12.17 /28
R1 G0/2 10.1.0.1 23
R2 G0/0 10.1.12.2 /29
R2 G0/1 10.1.12.33 /28
R2 G0/2 10.1.6.1 /23
R3 G0/0 10.1.12.18 /28
R3 G0/1 10.1.12.34 /28
R3 G0/2 10.1.2.1 /23

Table 1: IPv4 Addresses

 

To create the configuration, all you have to do is add the ip address command to each interface in configuration mode. Easy once you’d done it a few times; here are the answers to be complete.

Example 1: R1 IPv4 Address Configuration

 

Example 2: R2 IPv4 Address Configuration

Example 3: R3 IPv4 Address Configuration

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

Cisco routers and switches allow a simple security method for both the console and for Telnet access. Basically, all you have to do is tell the device to use that method by supplying a prompt for the password (the login subcommand), and then define the password’s value (the password subcommand).

Note that the answer shows the configuration of the VTY password (to support Telnet) with VTYs 0 through 4 as separate from the configuration of VTYs 5 through 15. This quirk of Cisco output has to do with the fact that older IOS versions support only VTYs 0 through 4. You could have used the commands literally shown in the answer example, or you could have used the command line vty 0 15, followed by those same password and login commands.

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 None No known issues related to this lab.

 

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. After opening the supplied .pkt file, but before configuring any commands, test to see which PCs lease an IP address with DHCP:
    1. Use the ipconfig /all command from the PC command prompt to discover if the PCs have an IP address assigned from the DHCP server.
    2. As needed, use the ipconfig /release and ipconfig /renew commands to release the old address and attempt to renew a lease on an IP address.
  2. After configuring the lab:
    1. Repeat the above tests to confirm that all the PCs lease an address.
    2. From each PC, ping the other PC IP addresses. Because the lab begins with routing working, once DHCP works on each PC, the pings should all work as well.

More Labs with Related Content!

Config Lab: IPv4 Addresses 3
Config Lab: IPv4 Addresses 5
Wendell Odom
By Wendell Odom September 10, 2021 15:05
Write a comment

5 Comments

  1. Frank Wijmans November 30, 11:01

    Hi Wendell,

    I’ve just tried to import the yaml file for this lab (204) but just like with the file from the previous lab (203) it returns an error.

    When I compare these files with files from other labs it looks like the devices aren’t in these 2 files.

    For the time being I just went for the old fashion paper way of doing the exercise, but obviously it’s more fun to do it in CML.

    Hope you can help me out.

    Reply to this comment
    • certskills November 30, 13:27

      Hi Frank,
      I’ll answer both your related posts here. It’s a long answer, hopefully helpful in the end.
      I have bumped into this error before. At issue is the “version: 0.0.x” line in the .yaml file. It appears that CML, at various versions, store a different value for that variable. And it appears (at least in my experience with it) that a .yaml file exported at a version that lists one value for that variable, when you try to import it into CML that uses another version, the import fails. That’s probably what’s happening here.
      For instance, when we set about to update all these labs, we had a similar error. The old .virl files for VIRL version 1 (YAML format, but filetype .virl), listed version: 0.0.3. We tested/built on CML 2.2, which used version: 0.0.4.
      The good news is that there may be a simple workaround. About 90% of the time, the simple workaround worked. But I’ll need you to try a few things, because (a) I still have CML 2.2 (which works with the files) and (b) I can’t take the time to upgrade/test CML right now. So here’s the process:

      Use CML to create a simple topology with say 1 router and 1 switch.
      Export the CML .yaml file.
      Open the exported .yaml file and find the “version: 0.0.x” line. I’d be curious: what CML version are you running, and what shows up as the version number in the file? (I’m guessing 0.0.5).
      Download the .yaml file for this lab.
      Edit the .yaml file for this lab, and change the value of the version variable to the value you saw in the .yaml file you created. And save the lab file.
      Now try to import that file.

      As I mentioned, the above worked 90% of the time for us.

      Happy to engage more about it, just not enough time to test for myself right now. Honestly, I almost ignored CML for the 2021 updates to these labs, as most people use Packet Tracer for CCNA labbing, but I like CML. Just have a deadline working right now.

      Let me know how it goes. Cheers.
      Wendell

      Reply to this comment
      • Frank Wijmans December 2, 15:07

        Hi Wendell,

        Thanks for taking the time and explaining what the issue was and how to fix it.
        For me it was actually the other way around from a version perspective, I was still running CML 2.0 (version 0.0.3). But when I applied that little trick you mentioned and changed the version in your .yaml files to 0.0.3, it worked like a charm!

        This talk about versions got me to perform an upgrade for CML from 2.0 to 2.2.3, but this actually broke the thing and presented me with other issues. So instead of restoring a backup and going back to 2.0, I opted for the option to deploy a whole new controller running 2.2.3. And your yaml files work just fine now.

        Thanks again for your time to reach out and helping me getting back on track!

        Cheers,

        Frank

        Reply to this comment
        • Wendell Odom (@Wendellodom) December 2, 16:59

          Frank,
          Wonderful! Glad it worked out. Yeah, I was avoiding the 2.2.3 upgrade myself – I follow the CLN CML community, and there are posts daily about issues after a CML upgrade. Good to hear of the workaround.
          Cheers!
          Wendell

          Reply to this comment
  2. Emil February 4, 21:32

    Great lab, but I think the Lab Commentary section belongs to a different lab. It says:

    “Cisco routers and switches allow a simple security method for both the console and for Telnet access. Basically, all you have to do is tell the device to use that method by supplying a prompt for the password (the login subcommand), and then define the password’s value (the password subcommand).

    Note that the answer shows the configuration of the VTY password (to support Telnet) with VTYs 0 through 4 as separate from the configuration of VTYs 5 through 15. This quirk of Cisco output has to do with the fact that older IOS versions support only VTYs 0 through 4. You could have used the commands literally shown in the answer example, or you could have used the command line vty 0 15, followed by those same password and login commands.”

    Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email

Subscribe

Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Thank you for subscribing.

Something went wrong.

Search

Categories