IP Addressing on Hosts

Dynamic Host Configuration Protocol (DHCP)

DHCP Concepts

The host acts as a DHCP client. As a DHCP client, the host begins with no IPv4 settings—no IPv4 address, no mask, no default router, and no DNS server IP addresses. But a DHCP client does have knowledge of the DHCP protocol, so the client can use that protocol to (a) discover a DHCP server and (b) request to lease an IPv4 address.

DHCP uses the following four messages between the client and server. (Also, to help remember the messages, note that the first letters spell DORA):

Discover: Sent by the DHCP client to find a willing DHCP server

Offer: Sent by a DHCP server to offer to lease to that client a specific IP address (and inform the client of its other parameters)

Request: Sent by the DHCP client to ask the server to lease the IPv4 address listed in the Offer message

Acknowledgment: Sent by the DHCP server to assign the address and to list the mask, default router, and DNS server IP addresses

0.0.0.0: An address reserved for use as a source IPv4 address for hosts that do not yet have an IP address.

255.255.255.255: The local broadcast IP address. Packets sent to this destination address are broadcast on the local data link, but routers do not forward them.

APIPA IP Addresses (169.254.x.x)

If the DHCP process fails for a DHCP client, hosts have a default means to self-assign an IP address using a feature called Automatic Private IP Addressing (APIPA). When the DHCP process fails, the DHCP client self-assigns an APIPA IP address from within a subset of the 169.254.0.0 Class B network, along with default mask 255.255.0.0.

Using an APIPA address does not help devices work like a normal host. For instance, hosts do not know of a default router or learn a list of DNS servers. The host can send packets only to other APIPA hosts on the same LAN.

The APIPA process works like this:

The client chooses any IP address from network 169.254.0.0 (actual address range: 169.54.1.0 – 169.254.254.255).

The DHCP client discovers if any other host on the same link already uses the APIPA address it chose by using ARP to perform Duplicate Address Detection (DAD). If another host already uses the same address, the client stops using the address and chooses another.

The client can send/receive packets on the local network only.

Supporting DHCP for Remote Subnets with DHCP Relay

With a centralized DHCP server, those DHCP messages that flowed only on the local subnet in Figure 19-1 somehow need to flow over the IP network to the centralized DHCP server and back. To make that work, the routers connected to the remote LAN subnets need an interface subcommand: the ip helper-addressserver-ip command.

The ip helper-address server-ip subcommand tells the router to do the following for the messages coming in an interface, from a DHCP client:

Watch for incoming DHCP messages, with destination IP address 255.255.255.255.

Change that packet’s source IP address to the router’s incoming interface IP address.

Change that packet’s destination IP address to the address of the DHCP server (as configured in the ip helper-address command).

Route the packet to the DHCP server.

This command gets around the “do not route local subnet broadcast packets sent to address 255.255.255.255” rule by changing the destination IP address. Once the destination has been set to match the DHCP server’s IP address, the network can route the packet to the serve

This feature, by which a router relays DHCP messages by changing the IP addresses in the packet header, is called DHCP relay.

he following list shows the types of settings the DHCP server needs to know to support DHCP clients:

Subnet ID and mask: The DHCP server can use this information to know all addresses in the subnet. (The DHCP server knows to not lease the subnet ID or subnet broadcast address.)

Reserved (excluded) addresses: The server needs to know which addresses in the subnet to not lease. This list allows the engineer to reserve addresses to be used as static IP addresses. For example, most router and switch IP addresses, server addresses, and addresses of most anything other than user devices use a statically assigned IP address. Most of the time, engineers use the same convention for all subnets, either reserving the lowest IP addresses in all subnets or reserving the highest IP addresses in all subnets.

Default router(s): This is the IP address of the router on that subnet.

DNS IP address(es): This is a list of DNS server IP addresses.

DHCP uses three allocation modes, based on small differences in the configuration at the DHCP server.

Dynamic allocation refers to the DHCP mechanisms and configuration described throughout this chapter. Another method, automatic allocation, sets the DHCP lease time to infinite. As a result, once the server chooses an address from the pool and assigns the IP address to a client, the IP address remains with that same client indefinitely. A third mode, static allocation, preconfigures the specific IP address for a client based on the client’s MAC address. That specific client is the only client that then uses the IP address. (Note that this chapter shows examples and configuration for dynamic allocation only.)

Additionally, the DHCP server can be configured to supply some other useful configuration settings. For instance, a server can supply the IP address of a Trivial File Transfer Protocol (TFTP) server. TFTP servers provide a basic means of storing files that can then be transferred to a client host. For instance, Cisco IP phones rely on TFTP to retrieve several configuration files when the phone initializes. DHCP plays a key role by supplying the IP address of the TFTP server that the phones should use.

Configuring DHCP Features on Routers and Switches

Configuring DHCP Relay

Configuring DHCP relay requires a simple decision and a single straightforward configuration command. First, you must identify the interfaces that need the feature. The DHCP relay feature must be configured for any router interface that connects to a subnet where

DHCP clients exist in the subnet

DHCP servers do not exist in the subnet

Once such interfaces have been identified, the configuration requires the ip helper-address interface subcommand on each of those interfaces. For instance, in the topology of the previous three figures, R1’s G0/0 interface needs to be configured with the ip helper-address 172.16.2.11 interface subcommand. Once enabled on an interface, the IOS DHCP relay agent makes changes in the incoming DHCP messages’ addresses as described earlier in the chapter. Without the DHCP relay agent, the DHCP request never arrives at the server.

To verify the relay agent, you can use the show running-config command and look for the single configuration command or use the show ip interface g0/0command as shown in Example 19-1. The highlighted line confirms the configured setting. Note that if there were no ip helper-address commands configured on the interface, the highlighted line would instead read “Helper address is not set.”

Configuring a Switch as DHCP Client

To configure a switch to use DHCP to lease an address, configure a switch’s IP address as normal, but with the ip address dhcp interface subcommand. Example 19-2 shows a sample.

To verify that DHCP worked, start with the traditional way to check IP addresses on switch VLAN interfaces: the show interfaces vlan x command as demonstrated in Example 19-3. First, check the interface state, because the switch does not attempt DHCP until the VLAN interface reaches an up/up state. Notably, if you forget to issue the no shutdown command, the VLAN 1 interface will remain in a shutdown state and be listed as “administratively down” in the show command output. Then, if DHCP has not yet worked, you will see the highlighted line shown in the upper part of the example. Once the switch leases an IP address, you will see the different text shown in the bottom half of the example.

Configuring a Router as DHCP Client

The end of the example shows the resulting default route. Oddly, IOS displays this route as a static route (destination 0.0.0.0/0), although the route is learned dynamically based on the DHCP-learned default gateway. To recognize this route as a DHCP-learned default route, look to the administrative distance value of 254. IOS uses a default administrative distance of 1 for static routes configured with the ip route configuration command but a default of 254 for default routes added because of DHCP.

Host Settings for IPv4

To work correctly, an IPv4 host needs to know these values:

DNS server IP addresses

Default gateway (router) IP address

Device’s own IP address

Device’s own subnet mask

To review the basics, the host must know the IP address of one or more DNS servers to send the servers’ name resolution requests. For enterprises, the servers may reside in the enterprise, as shown in Figure 19-6. The host on the left (sometimes called an endpoint) typically knows the addresses of at least two DNS servers for redundancy. If the first DNS fails to respond, the endpoint can then attempt name resolution with the next DNS server.

Each endpoint needs to know the IP address of a router that resides in the same subnet. The endpoint uses that router as its default router or default gateway, as shown in Figure 19-7. From a host logic perspective, the host can then forward packets destined for addresses outside the subnet to the default router, with that router then forwarding the packet based on its routing table.

Host IP Settings on macOS

Although the details vary as compared to Windows, macOS has a graphical interface to see network settings and a variety of network commands. This section shows examples of each, beginning with Figure 19-11. It shows the network settings in macOS for an Ethernet interface, with the address, mask, default router, and DNS server addresses. Also note the setting states that the interface is using DHCP.

Both macOS and Linux support the ifconfig command to list information similar to the Windows ipconfig /all command. However, the ifconfig command lacks an option like /all, listing no information about the default gateway or DNS servers. Example 19-9 gives an example of the ifconfig command from Mac Host B in Figure 19-11, along with another command that lists the default router.

Host IP Settings on Linux

As with the other desktop OSs, Linux shows networking settings from the GUI as well as with commands. However, be aware that the Linux world includes many different Linux distributions. Additionally, the Linux architecture separates the OS from the desktop (the graphical interface). So, other Linux users may use different GUI administration tools and commands to see network settings.

Figure 19-12 shows an example from the Ubuntu Linux distribution using the Mate desktop (www.ubuntu-mate.org). The host, Host C in Figure 19-9, uses DHCP and learns an address in subnet 10.1.1.0/24. Figure 19-12 shows IP details about an Ethernet adapter and includes the IPv4 address, mask, default router, and DNS IP addresses.

inux hosts often support a large set of commands from the command line. However, an older set of commands, referenced together as net-tools, has been deprecated in Linux to the point that some Linux distributions do not include net-tools. (You can easily add net-tools to most Linux distributions.) The net-tools library has popular commands like ifconfig and netstat -rn. To replace those tools, Linux uses the iproute library, which includes a set of replacement commands and functions, many performed with the ip command and some parameters.

Working Windows Host with Static IP Setting (No DHCP)

The ipconfig /all command output in Example 19-13 implies that the host uses static settings by noting that DHCP is disabled (per the first highlighted line). Take a moment to compare that line to the same line back in Example 19-7, in which Host A acts as a DHCP client.

The output here in Example 19-13 also signals that the host uses a static setting rather than DHCP, but it tells us that by the absence of several lines of output usually shown for DHCP clients, omitting the lines for

DHCP Enabled

Lease Obtained

Lease Expires

A Failed Windows DHCP Client Due to IP Connectivity Issues

The following example, again taken from Windows Host A, shows a case in which the host similarly acts as a DHCP client to follow the design from Figure 19-9. However, any problem that prevents the DHCP DORA messages from flowing between the client and DHCP server results in a failure of the DHCP process. The client does not lease an address or learn the other IP details from the DHCP server, but it self-assigns an APIPA address and uses the APIPA default mask of 255.255.0.0. (For a review of APIPA, see the section titled “APIPA IP Addresses (169.254.x.x)” earlier in this chapter.)

Example 19-14 shows the resulting ipconfig /all command. The output confirms the client enables DHCP. However, the following facts identify that the process failed:

It omits the output line that would list the DHCP server’s IP address.

It omits the two output lines that list DHCP lease details.

It shows an APIPA IP address that begins 169.254.

It lists no IPv4 default gateway address.

It lists no IPv4 DNS servers.