Config Lab: Router as DHCP Client

 In 200-301 V2 Ch07: DHCP, 200-301 V2 Part 2: Security Services, 200-301 V2 Parts, Config Lab, Config Lab CCNA Vol 2 Part 2, Hands-on

While most router interfaces use configured IP addresses, in some cases, a design calls for the router to dynamically learn an interface IP address. In those cases, routers can be configured to act as a DHCP client. In many of those same cases, the router needs a default route based on the default gateway IP address learned by DHCP. In this lab, you configure a router to act as a DHCP client, learn a default route, and advertise that default route using OSPF.

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

Lab Requirements

One classic case for a router to lease an address with DHCP occurs with a router connected to an ISP. The link between the ISP router and the Enterprise router often uses public IP addresses as assigned by the ISP. As the customer, the Enterprise can ask to use statically assigned IP addresses on that link. However, in some cases, you can have the router dynamically learn its IP address on the ISP link using DHCP – much like a typical consumer router does at your home.

The Enterprise router also needs to create default routes to support traffic into the Internet. First, using DHCP, the router learns the ISP router’s IP address on the link. The router connected to that link can use that address as the next-hop IP address in a default route. Additionally, other routers may exist in the Enterprise site, like routers B1 and B2 in the figure. So, the Enterprise router connected to the ISP needs to advertise that it has a good default route to the rest of the routers. Then the other routers build their own default routes so that all Enterprise routers can forward packets towards the Internet.

Figure 1: Topology for this Lab


This lab begins with the three Enterprise routers (R1, B1, B2) with IP addresses configured inside the Enterprise and OSPF working on those links. The ISP is ready to use DHCP to assign R1 its IP address on its G0/3/0 interface. So, for this lab, your job:

  1. Configure router R1 to use the DHCP client features:
    1. To lease its G0/3/0 IP address/mask.
    2. To build a default route based on the default gateway learned with DHCP.
  2. Configure the Enterprise routers so that:
    1. All Enterprise routers build a default route that will forward packets towards the Internet (ISP1).


Initial Configurations

Examples 1, 2, and 3 show the initial configuration of IP addresses and OSPF on the three enterprise routers. Example 4 shows the ISP router configuration. Note that the one ISP router has enough DHCP configuration to act as the DHCP server in lab; in a real ISP, another server would be used for DHCP services.

hostname R1
interface GigabitEthernet0/0/0
 ip address
interface GigabitEthernet0/1/0
 ip address
interface GigabitEthernet0/3/0
 no ip address
router ospf 1
 network area 0

Example 1: R1 Initial Config


hostname B1
interface GigabitEthernet0/0
 ip address
 no shutdown
interface GigabitEthernet0/1/0
 ip address
 no shutdown
router ospf 1
 network area 0

Example 2: B1 Initial Config


hostname B2
interface GigabitEthernet0/0
 ip address
 no shutdown
interface GigabitEthernet0/0/0
 ip address
 no shutdown
router ospf 1
 network area 0

Example 3: B2 Initial Config


hostname ISP1
ip dhcp excluded-address
ip dhcp pool oneaddress
interface Loopback1
 ip address
interface GigabitEthernet0/0/0
 ip address
 no shutdown
ip route GigabitEthernet0/0/0

Example 4: ISP1 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 listed in the lab exercise documentation versus those used in the sample CML file.

Device Lab Port  CML Port
R1 G0/0/0 G0/0
R1 G0/1/0 G0/1
R1 G0/3/0 G0/3
B1 G0/1/0 G0/1
B2 G0/0/0 G0/1
ISP1 G0/00 G0/0
ISP1 G0/0/0 G0/0

Lab Answers Below: Spoiler Alert

Lab Answers: Configuration (Click Tab to Reveal)

Lab Configuration

Figure 1: Topology for this Lab


interface GigabitEthernet0/3/0
 ip address dhcp
router ospf 1
 default-information originate

Example 1: R1 Config

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

Lab Commentary

The ip address dhcp interface subcommand tells a router to do two actions:

  • Act as a DHCP client to lease an IP address/mask to use
  • Build a default route based on the default gateway IP address advertised by DHCP

On that second point, note that the router, with default configuration, still acts like a router instead of an IP host. For instance, a router does not use a default gateway concept. However, routers can define a default route: a route that matches all packets not otherwise matched by any other route in the routing table. Using the DHCP client function, the router adds a default route to its routing table, using the default gateway IP address as the next-hop address.

To complete the lab requirements, all three routers must have a default route. To complete that process, add to router R1 the default-information originate command in OSPF mode. That command makes OSPF use this logic:

When I have a default route from any source in my routing table… advertise a default route using OSPF.

R1 has its default route based on the default gateway address learned as a DHCP client. By adding the default-information originate OSPF command, R1 now advertises default routes to B1 and B2.

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. Use the show ip route command on the Enterprise routers (R1, B1, B2) and look for the route to Look for:
    1. R1: A static route to with next-hop address (the address of ISP1)
    2. B1 and B2: An OSPF-learned “E2” route to
  2. From B1 and B2, ping ISP1’s address, the router ISP1 address on the WAN link.

More Labs with Related Content!

Config Lab: DHCP Relay
Config Lab: DHCP Snooping 1
Notify of

Newest Most Voted
Inline Feedbacks
View all comments

Hi Wendell,

I think there’s a typo in the router ospf 1 section of the configuration for R1 in the .pkt file. It lists the wildcard mask as, while B1 and B2 list it as This causes the default route learned from the ISP’s router to not propagate to B1 and B2 unless the R1 wildcard mask is reconfigured to

Strictly speaking, I assumed the wildcard mask on B1 and B2 should be reconfigured to, since the shared subnet has a /24 mask. However, I couldn’t get this work. Your insight on this would be appreciated.

You teach great troubleshooting skills and they came in handy as I tried to figure out just why I could not get this to work!


…and I just realized why won’t work either, because the subnet is Duh. That also explains why does work.

I also just noticed that the configurations for B1 and B2 given on the lab page incorrectly state I guess those would work, but they don’t match the actual .pkt file.


Hey Steve,
Glad you’re seeing all this as a positive opportunity to practice troubleshooting!
I agree, the OSPF subcommand “network…” would not match any interface IP addresses. That was simply incorrect. The intent was to use wildcard
Also, I agree that the lab post’s initial config on B1 and B2 didn’t match what was in the .pkt file.

NET: I updated the .pkt file so it (1) corrects the mistake in the wildcard mask and (b) changes the .pkt file to match the initial config listed for routers B1 and B2.

For anyone who happens along later, just download the .pkt file now and you’ll have the latest/fixed version.
Thanks for the help Steve,


Hello Wendell,

Where do I find your the text for the 2nd requirement – default information originate in the book? Am reading the CCNA guide and I don’t seem to recall reading about it in the dhcp chapter – Chapter 7 of vol 2.

Would love your thoughts, please comment.x