DHCP (dynamic host configuration protocol) is used for dynamically assigning network addresses to hosts. DHCP operates on a client-server model, where a DHCP server sends configuration information to DHCP clients. The CCNA (Cisco Certified Network Associate) exams require you to understand DHCP and be able to configure and verify it on Cisco routers. In this article we will provide an introduction to DHCP, going into details relevant to CCNA. We will also develop a topology in GNS3 to practice the concepts hands on. The current article belongs to the GNS3 Labs for CCNA series and assumes you already have a GNS3 installation in working order. If that’s not you and you need help setting up GNS3 from scratch. you should read the article GNS3 Labs for CCNA: Getting Started first and then come back here.

Introduction to DHCP

DHCP is based on BOOTP (bootstrap protocol), which provides the framework for passing configuration information to hosts on a TCP/IP network. The main advantage of DHCP over BOOTP is that you don’t need to configure MAC addresses of all clients on the DHCP server.

The graphic below shows the message exchange between a DHCP server and client:

The steps shown in the graphic are explained below:

The operating system on the host is configured to obtain network configuration via DHCP, so the host, acting as DHCP client, sends a DHCPDISCOVER broadcast message to locate a DHCP server. A DHCP server on the local subnet offers configuration parameters, including an IP address, to the client in a DHCPOFFER unicast message. The DHCP client returns a formal request for the offered IP address to the server in a DHCPREQUEST broadcast message. The DHCP server confirms that the IP address has actually been allocated for use by the client by returning the final DHCPACK unicast message.

The interaction of a DHCP server and client looks just like what we presented when the client and server are both on the same broadcast domain/subnet. If that’s not the case, a DHCP relay agent is needed, in addition to client and server. A DHCP relay agent is any host that forwards DHCP packets between DHCP clients and DHCP servers. In practice, DHCP servers are often centrally located and you almost always need a DHCP relay agent to forward messages back and forth between the client and server. A DHCP relay agent does more than simply forwarding DHCP packets like a router forwarding IP packets. The relay agent receives DHCP messages and then generates a new DHCP message to send on another interface. The Cisco IOS (Internetwork Operating System) running on Cisco routers includes both DHCP server and relay agent software and we are going to cover the configuration of both features in this article.

DHCP Server Configuration and Verification

In the first article of the series (GNS3 Labs for CCNA: Getting Started), we set up GNS3 and created a simple topology with two routers, but we did not add any hosts. In this article, it will probably be useful to add a couple of hosts to see our DHCP server in action, actually assigning addresses. So let’s learn how to add hosts to GNS3 before moving on to DHCP configuration.

The GNS3 0.8.6 all-in-one package that we are using comes bundled with version 0.11.0 of the Qemu emulator. You will use Qemu to emulate a lightweight distribution of Linux called Micro Core. You should download the Qemu appliance for Linux Micro Core from http://sourceforge.net/projects/gns-3/files/Qemu%20Appliances/linux-microcore-3.8.2.img and save it to the directory C:\Images on your Windows system. You need also to configure GNS3 by going to Edit > Preferences > Qemu and then, on the tab labeled Qemu Guest, do as shown in the graphic below. Finally, you have to press the Save and OK buttons in succession.

In this article, we will use the topology shown below. We are making the GNS3 topology and initial configuration files available freely as a RAR archive. You should download the archive and decompress it using a utility like WinRAR to a folder on your computer. The topology provided comes pre-configured with IP addresses and static routing. The idea is to come straight to the point we are covering in this article.

You have to double click the downloaded topology.net file and GNS3 should launch automatically. You have to start all devices once the topology is loaded in GNS3. The devices will all come alive with initial configurations. First, you should go to R1 and add the following configuration to make it act as a DHCP server for directly connected hosts as well as for hosts connected to R2 on the remote LAN.

ip dhcp excluded-address 192.168.1.1 192.168.1.50 ! ip dhcp pool Pool_R1 network 192.168.1.0 255.255.255.0 default-router 192.168.1.1 dns-server 192.168.1.1 lease 0 23 59 domain-name intenseschool.com

We have defined a DHCP pool named Pool_R1 that includes all addresses in the subnet 192.168.1.0/24. The default router/gateway is 192.168.1.1 that happens to be the IP address on FastEthernet0/0 of R1. We have plans of possibly making R1 our DNS server in future (not in this article), so the DNS server too is 192.168.1.1. The command lease days hours minutes has been used to configure a DHCP lease duration of 23 hours and 59 minutes or almost a full day, after which clients must renew their addresses. The command ip dhcp excluded-address has been used to prevent the server from assigning the first 50 IP addresses in the pool. We plan to configure these reserved addresses statically on servers that need to have permanent IP addresses. Finally, we used the command domain-name to set the domain name arbitrarily to intenseschool.com.

You may now go to the host labeled MicroCore on the left and verify if it has obtained an IP address from R1 over DHCP. Please note that the default login for Qemu Micro Core Linux appliance is tc with no password.

Micro Core Linux box login: tc (°- //\ Micro Core is distributed with ABSOLUTELY NO WARRANTY. v_/_ www.tinycorelinux.com tc@box:~$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:AB:B6:8E:DC:00 inet addr:192.168.1.51 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::2ab:b6ff:fe8e:dc00/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:48 errors:0 dropped:0 overruns:0 frame:0 TX packets:35 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:13352 (13.0 KiB) TX bytes:7263 (7.0 KiB)

The router R1 is supposed to act as DHCP server for local hosts as well as for remote hosts connected to R2. You have to add the following configuration to R1 to make it act as a DHCP address for hosts connected to FastEthernet0/0 of R2.

ip dhcp excluded-address 192.168.2.1 192.168.2.50 ! ip dhcp pool Pool_R2 network 192.168.2.0 255.255.255.0 default-router 192.168.2.1 dns-server 192.168.2.1 lease 0 23 59 domain-name intenseschool.com

We created another DHCP address pool named Pool_R2 with configuration quite similar to the configuration of Pool_R1. The configuration done so far on R1 is not enough to allow hosts on the LAN connected to R2 obtain network addresses. The reason is that hosts connected to R2 and R1 are not in the same broadcast domain. The DHCPDISCOVER messages sent by those remote hosts simply cannot reach R1. You need to add the following configuration to R2 to make it act as DHCP relay agent.

interface FastEthernet0/0 ip helper-address 172.16.12.1

The DHCP relay agent feature requires just the ip helper-address command configured under FastEthernet0/0 of R2. You may now go to the host on right labeled MicroCore_2 and verify that it has received its IP address from R1.

Micro Core Linux box login: tc (°- //\ Micro Core is distributed with ABSOLUTELY NO WARRANTY. v_/_ www.tinycorelinux.com tc@box:~$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:AB:E3:52:02:00 inet addr:192.168.2.51 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::2ab:e3ff:fe52:200/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:26 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2218 (2.1 KiB) TX bytes:7020 (6.8 KiB)

You can see that MicorCore_2 has obtained 192.168.2.51 as its IP address from the DHCP server running on R1.

We successfully configured the DHCP server and relay agent on R1 and R2, respectively. The verification came directly from examining IP addresses assigned to hosts. Now let’s have a closer look at the state of DHCP server on R1, using show commands.

The command show ip dhcp binding reports IP addresses assigned and client MAC addresses associated with those addresses.

R1#show ip dhcp binding Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name 192.168.1.51 0100.abb6.8edc.00 Mar 02 2002 12:02 AM Automatic 192.168.2.51 0100.abe3.5202.00 Mar 02 2002 12:30 AM Automatic

The command show ip dhcp pool reports the number of addresses leased so far, along with some other details on current utilization of addresses in the DHCP pool.

R1#show ip dhcp pool Pool Pool_R1 : Utilization mark (high/low) : 100 / 0 Subnet size (first/next) : 0 / 0 Total addresses : 254 Leased addresses : 1 Pending event : none 1 subnet is currently in the pool : Current index IP address range Leased addresses 192.168.1.52 192.168.1.1 - 192.168.1.254 1 Pool Pool_R2 : Utilization mark (high/low) : 100 / 0 Subnet size (first/next) : 0 / 0 Total addresses : 254 Leased addresses : 1 Pending event : none 1 subnet is currently in the pool : Current index IP address range Leased addresses 192.168.2.52 192.168.2.1 - 192.168.2.254 1

The command show ip dhcp server statistics reports the number of DHCP messages of each type received, as well as some other statistics.

R1#show ip dhcp server statistics Memory usage 25885 Address pools 2 Database agents 0 Automatic bindings 2 Manual bindings 0 Expired bindings 0 Malformed messages 0 Secure arp entries 0 Message Received BOOTREQUEST 0 DHCPDISCOVER 2 DHCPREQUEST 2 DHCPDECLINE 0 DHCPRELEASE 0 DHCPINFORM 0 Message Sent BOOTREPLY 0 DHCPOFFER 2 DHCPACK 2 DHCPNAK 0

The DHCP server implementation in Cisco IOS also tries to detect conflicts between assigned and statically configured addresses. You have seen the ip dhcp excluded-address command, which tries to prevent address conflicts. But there is nothing in the world that can prevent someone from statically configuring an IP address from within the range of addresses used by the DHCP server. DHCP servers detect such conflicts by pinging the new IP address before assigning it to a client. The show ip dhcp conflict command lists all address conflicts known to the DHCP server. The DHCP server avoids assigning the addresses from the list to any clients until the list is manually cleared using the clear ip dhcp conflict command.

We have come to the conclusion of the article, but you still have to do two things in order to make sure your configurations are available the next time you load the topology in GNS3. First, do write memory or copy running-config startup-config on all routers in the topology. Second, save the project from File > Save project as… We hope to see you again with another article in the GNS3 Labs for CCNA series covering another topic from the new CCNA version 2.