This chapter covers the following exam topics:
1.0 Network Fundamentals
1.10 Identify IP parameters for Client OS (Windows, Mac OS, Linux)
4.0 IP Services
4.3 Explain the role of DHCP and DNS within the network
4.6 Configure and verify DHCP client and relay
In the world of TCP/IP, the word host refers to any device with an IP address: your phone, your tablet, a PC, a server, a router, a switch—any device that uses IP to provide a service or just needs an IP address to be managed. The term host includes some less-obvious devices as well: the electronic advertising video screen at the mall, your electrical power meter that uses the same technology as mobile phones to submit your electrical usage information for billing, your new car.
No matter the type of host, any host that uses IPv4 needs four IPv4 settings to work properly:
DNS server IP addresses
This chapter discusses these basic IP settings on hosts. The chapter begins by discussing how a host can dynamically learn these four settings using the Dynamic Host Configuration Protocol (DHCP). The second half of this chapter then shows how to find the settings on hosts and the key facts to look for when displaying the settings.
Just a note about the overall flow of the chapters: This chapter does not discuss security topics, although it sits inside Part II, “Security Services.” I located this DHCP-focused chapter here because Chapter 8, “DHCP Snooping and ARP Inspection,” relies heavily on knowledge of DHCP.
Take the quiz (either here or use the PTP software) if you want to use the score to help you decide how much time to spend on this chapter. The letter answers are listed at the bottom of the page following the quiz. Appendix C, found both at the end of the book as well as on the companion website, includes both the answers and explanations. You can also find both answers and explanations in the PTP testing software.
Foundation Topics Section
Dynamic Host Configuration Protocol
Identifying Host IPv4 Settings
1. A PC connects to a LAN and uses DHCP to lease an IP address for the first time. Of the usual four DHCP messages that flow between the PC and the DHCP server, which ones do the client send? (Choose two answers.)
2. Which of the following kinds of information are part of a DHCP server configuration? (Choose two answers.)
Ranges of IP addresses in subnets that the server should lease
Ranges of IP addresses to not lease per subnet
DNS server hostnames
The default router IP and MAC address in each subnet
3. Which answers list a criterion for choosing which router interfaces need to be configured as a DHCP relay agent? (Choose two answers.)
If the subnet off the interface does not include a DHCP server
If the subnet off the interface does include a DHCP server
If the subnet off the interface contains DHCP clients
If the router interface already has an ip address dhcp command
4. A router connects to an Internet Service Provider (ISP) using its G0/0/0 interface, with the ip address dhcp command configured. What does the router do with the DHCP-learned default gateway information?
The router ignores the default gateway value learned from the DHCP server.
The router uses the default gateway just like a host, ignoring its routing table.
The router forwards received packets based on its routing table but uses its default gateway setting to forward packets it generates itself.
The router adds a default route based on the default gateway to its IP routing table.
5. In the following excerpt from a command on a Mac, which of the following parts of the output represent information learned from a DHCP server? (Choose two answers.)
Macprompt$ ifconfig en0 En1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV> ether 00:6d:e7:b1:9a:11 inet 172.16.4.2 netmask 0xffffff00 broadcast 172.16.4.255
6. Which of the following commands on a Windows OS should list both the IP address and DNS servers as learned with DHCP?
Answers to the “Do I Know This Already?” quiz:
1 B, D
2 A, B
3 A, C
5 B, C
Dynamic Host Configuration Protocol (DHCP) provides one of the most commonly used services in a TCP/IP network. The vast majority of hosts in a TCP/IP network are user devices, and the vast majority of user devices learn their IPv4 settings using DHCP.
Using DHCP has several advantages over the other option of manually configuring IPv4 settings. The configuration of host IP settings sits in a DHCP server, with each client learning these settings using DHCP messages. As a result, the host IP configuration is controlled by the IT staff, rather than on local configuration on each host, resulting in fewer user errors. DHCP allows both the permanent assignment of host addresses, but more commonly, DHCP assigns a temporary lease of IP addresses. With these leases, the DHCP server can reclaim IP addresses when a device is removed from the network, making better use of the available addresses.
DHCP also enables mobility. For example, every time a user moves to a new location with a tablet computer—to a coffee shop, a client location, or back at the office—the user’s device can connect to another wireless LAN, use DHCP to lease a new IP address in that LAN, and begin working on the new network. Without DHCP, the user would have to ask for information about the local network and configure settings manually, with more than a few users making mistakes.
Although DHCP works automatically for user hosts, it does require some preparation from the network, with some configuration on routers. In some enterprise networks, that router configuration can be a single command on many of the router’s LAN interfaces (ip helper-address server-ip), which identifies the DHCP server by its IP address. In other cases, the router acts as the DHCP server. Regardless, the routers have some role to play.
This first major section of the chapter takes a tour of DHCP, including concepts and the router configuration to enable the routers to work well with a separate DHCP server.
Sit back for a moment and think about the role of DHCP for a host computer. 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, as a way 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
DHCP clients, however, have a somewhat unique problem: they do not have an IP address yet, but they need to send these DHCP messages inside IP packets. To make that work, DHCP messages make use of two special IPv4 addresses that allow a host that has no IP address to still be able to send and receive messages on the local subnet:
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.
To see how these addresses work, Figure 7-1 shows an example of the IP addresses used between a host (A) and a DHCP server on the same LAN. Host A, a client, sends a Discover message, with source IP address of 0.0.0.0 because host A does not have an IP address to use yet. Host A sends the packet to destination 255.255.255.255, which is sent in a LAN broadcast frame, reaching all hosts in the subnet. The client hopes that there is a DHCP server on the local subnet. Why? Packets sent to 255.255.255.255 only go to hosts in the local subnet; router R1 will not forward this packet.
Now look at the Offer message sent back by the DHCP server. The server sets the destination IP address to 255.255.255.255 again. Why? Host A still does not have an IP address, so the server cannot send a packet directly to host A. So, the server sends the packet to “all local hosts in the subnet” address (255.255.255.255). (The packet is also encapsulated in an Ethernet broadcast frame.)
Note that all hosts in the subnet receive the Offer message. However, the original Discover message lists a number called the client ID, which includes the host’s MAC address, that identifies the original host (host A in this case). As a result, host A knows that the Offer message is meant for host A. The rest of the hosts will receive the Offer message, but notice that the message lists another device’s DHCP client ID, so the rest of the hosts ignore the Offer message.
Network engineers have a major design choice to make with DHCP: Do they put a DHCP server in every LAN subnet or locate a DHCP server in a central site? The question is legitimate. Cisco routers can act as the DHCP server, so a distributed design could use the router at each site as the DHCP server. With a DHCP server in every subnet, as shown in Figure 7-1, the protocol flows stay local to each LAN.
However, a centralized DHCP server approach has advantages as well. In fact, some Cisco design documents suggest a centralized design as a best practice, in part because it allows for centralized control and configuration of all the IPv4 addresses assigned throughout the enterprise.
With a centralized DHCP server, those DHCP messages that flowed only on the local subnet in Figure 7-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-address server-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 packets sent to 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 server.
Figure 7-2 shows an example of the process. Host A sits on the left, as a DHCP client. The DHCP server (172.16.2.11) sits on the right. R1 has an ip helper-address 172.16.2.11 command configured, under its G0/0 interface. At step 1, router R1 notices the incoming DHCP packet destined for 255.255.255.255. Step 2 shows the results of changing both the source and destination IP address, with R1 routing the packet.
The router uses a similar process for the return DHCP messages from the server. First, for the return packet from the DHCP server, the server simply reverses the source and destination IP address of the packet received from the router (relay agent). For example, in Figure 7-2, the Discover message lists source IP address 172.16.1.1, so the server sends the Offer message back to destination IP address 172.16.1.1.
When a router receives a DHCP message, addressed to one of the router’s own IP addresses, the router realizes the packet might be part of the DHCP relay feature. When that happens, the DHCP relay agent (router R1) needs to change the destination IP address, so that the real DHCP client (host A), which does not have an IP address yet, can receive and process the packet.
Figure 7-3 shows one example of how these addresses work, when R1 receives the DHCP Offer message sent to R1’s own 172.16.1.1 address. R1 changes the packet’s destination to 255.255.255.255 and forwards it out G0/0, because the packet was destined to G0/0’s 172.16.1.1 IP address. As a result, all hosts in that LAN (including the DHCP client A) will receive the message.
Many enterprise networks use a centralized DHCP server, so the normal router configuration includes an ip helper-address command on every LAN interface/subinterface. With that standard configuration, user hosts off any router LAN interface can always reach the DHCP server and lease an IP address.
A DHCP server might sound like some large piece of hardware, sitting in a big locked room with lots of air conditioning to keep the hardware cool. However, like most servers, the server is actually software, running on some server OS. The DHCP server could be a piece of software downloaded for free and installed on an old PC. However, because the server needs to be available all the time, to support new DHCP clients, most companies install the software on a very stable and highly available data center, with high availability features. The DHCP service is still created by software, however.
To be ready to answer DHCP clients and to supply them with an IPv4 address and other information, the DHCP server (software) needs configuration. DHCP servers typically organize these IPv4 settings per subnet, because the information the server tells the client is usually the same for all hosts in the same subnet, but slightly different for hosts in different subnets. For example, IP addressing rules tell us that all hosts on the same subnet should use the same mask but hosts in different subnets would have a different default gateway setting.
The 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.
Figure 7-4 shows the concept behind the preconfiguration on a DHCP server for two LAN-based subnets, 172.16.1.0/24 and 172.16.2.0/24. The DHCP server sits on the right. For each subnet, the server defines all the items in the list. In this case, the configuration reserves the lowest IP addresses in the subnet to be used as static addresses.
The configuration can list other parameters as well. For example, it can set the time limit for leasing an IP address. The server leases an address for a time (usually a number of days), and then the client can ask to renew the lease. If the client does not renew, the server can reclaim the IP address and put it back in the pool of available IP addresses. The server configuration sets the maximum time for the lease.
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. As it turns out, 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.
Cisco routers and switches support a variety of features. Routers can be configured to act as a DHCP server with just a few straightforward commands—a feature useful in the lab and in some limited cases. More commonly, the enterprise uses a centralized DHCP server (that does not run on a router) but with the router DHCP relay feature on most every router interface. Finally, Cisco routers and switches can also act as DHCP clients, learning their IP addresses from a DHCP server.
This section discusses the DHCP configuration topics mentioned for the current exam topics. Those include the router DHCP relay feature and the configuration to enable DHCP client services on both switches and routers.
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, with earlier Figure 7-3, 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/0 command as shown in Example 7-1. The highlighted line confirms the configured setting. Note that if there were no ip helper-address commands configured on the interface, the text would instead read “Helper address is not set.”
R1# show ip interface g0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 172.16.1.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is 172.16.2.11
! Lines omitted for brevity (about 20 lineSc
A switch can act as a DHCP client to lease its IP address. In most cases, you will want to instead use a static IP address so that the staff can more easily identify the switch’s address for remote management. However, as an example of how a DHCP client can work, this next topic shows how to configure and verify DHCP client operations on a switch.
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 7-2 shows a sample.
Emma# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Emma(config)# interface vlan 1 Emma(config-if)# ip address dhcp Emma(config-if)# no shutdown Emma(config-if)# ^Z Emma# 00:38:20: %LINK-3-UPDOWN: Interface Vlan1, changed state to up 00:38:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
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 7-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 listed as “administratively down” in the show command output.
Emma# show interfaces vlan 1 Vlan1 is up, line protocol is up Hardware is EtherSVI, address is 0019.e86a.6fc0 (bia 0019.e86a.6fc0) Internet address is 192.168.1.101/24 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 ! lines omitted for brevity
The second half of Example 7-3 shows the show interfaces vlan x command output, which lists the interface’s IP address on the third line. If you statically configure the IP address, the IP address will always be listed; however, when using DHCP, this line only exists if DHCP succeeded. Also, note that when present, the output does not state whether the address was statically configured or learned with DHCP. The output lists 192.168.1.101 as the address, but with no information to identify whether the IP address is a static or DHCP-learned IP address.
To see more details specific to DHCP, instead use the show dhcp lease command to see the (temporarily) leased IP address and other parameters. (Note that the switch does not store the DHCP-learned IP configuration in the running-config file.) Example 7-4 shows sample output. Note also that the switch learns its default-gateway setting using DHCP as well.
Emma# show dhcp lease Temp IP addr: 192.168.1.101 for peer on Interface: Vlan1 Temp sub net mask: 255.255.255.0 DHCP Lease server: 192.168.1.1, state: 3 Bound DHCP transaction id: 1966 Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs Temp default-gateway addr: 192.168.1.1 Next timer fires after: 11:59:45 Retry count: 0 Client-ID: cisco-0019.e86a.6fc0-Vl1 Hostname: Emma Emma# show ip default-gateway 192.168.1.1
Just as with switches, you can configure router interfaces to lease an IP address using DHCP rather than using a static IP address, although those cases will be rare. In most every case it makes more sense to statically configure router interface IP addresses with the address listed in the ip address address mask interface subcommand. However, configuring a router to lease an address using DHCP makes sense in some cases with a router connected to the Internet; in fact, most every home-based router does just that.
A router with a link to the Internet can learn its IP address and mask with DHCP and also learn the neighboring ISP router’s address as the default gateway. Figure 7-5 shows an example, with three routers on the left at one enterprise site. Router R1 uses DHCP to learn its IP address (192.0.2.2) from the ISP router over a connection to the Internet.
The DHCP process supplies a default gateway IP address to router R1, but routers do not normally use a default gateway setting; only hosts use a default gateway setting. However, the router takes advantage of that information by turning that default gateway IP address into the basis for a default route. For instance, in Figure 7-5, router R1 dynamically adds a default route to its routing table with the default gateway IP address from the DHCP message—which is the ISP router’s IP address—as the next-hop address. At that point, R1 has a good route to use to forward packets into the Internet.
Additionally, router R1 can distribute that default route to the rest of the routers using an interior routing protocol like OSPF. See the section titled “OSPF Default Routes” in Chapter 20 of the CCNA 200-301 Official Cert Guide, Volume 1, for more information.
Example 7-5 shows the configuration on router R1 to match Figure 7-5. Note that it begins with R1 configuring its G0/1 interface to use DHCP to learn the IP address to use on the interface, using the ip address dhcp command.
R1# configure terminal R1(config)# interface gigabitethernet0/1 R1(config-if)# ip address dhcp R1(config-if)# end R1# R1# show ip route static ! Legend omitted Gateway of last resort is 192.0.2.1 to network 0.0.0.0 S* 0.0.0.0/0 [254/0] via 192.0.2.1
The end of the example shows the default route added to R1’s routing table as a result of learning a default gateway address of 192.0.2.1 from DHCP. 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.
Whether learned using DHCP or not, every host that uses IP version 4 needs to have some settings to work correctly. This second major division of the chapter examines those settings and shows examples of those settings on Windows, Linux, and macOS.
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 7-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 7-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.
Of course, each device needs its own IP address and subnet mask. Equally as important, note that the host and the default router need to agree as to the addresses inside the subnet. The host will use the address and mask to do the math to determine which addresses are in the same subnet and which are in other subnets. For routing to work correctly, the default router’s interface address and mask should result in the same definition of the subnet with the same addresses, as shown in Figure 7-8.
The rest of this section shows examples of the display of these settings in the graphical user interface (GUI) and command-line interface (CLI) of three different host operating systems.
Most every OS in the world—certainly the more common OSs people work with every day—have a fairly easy-to-reach settings window that lists most if not all the IPv4 settings in one place. For example, Figure 7-9 shows the Network configuration screen from a Windows 10 host from the network area of the Windows Control Panel. This particular example shows the big four settings: address, mask, router, and DNS.
However, beyond the GUI, most OSs have a variety of networking commands available from a command line. With all Windows versions, the ipconfig and ipconfig /all commands supply the most direct help, as shown in Example 7-6. As you can see, both list the address, mask, and default gateway, with the ipconfig /all command also listing the DNS server settings.
C:DOCUME1OWNER> ipconfig Windows IP Configuration Ethernet adapter Ethernet3: Connection-specific DNS Suffix . : IPv4 Address. . . . . . . . . . . : 192.168.1.172 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 C:DOCUME1OWNER> ipconfig /all ! Lines omitted for brevity Ethernet adapter Ethernet 3: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : ASIX AX88179 USB 3.0 to Gigabit Ethernet Adapter Physical Address. . . . . . . . . : 00-05-1B-A3-5D-D0 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 192.168.1.172(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Friday, August 2, 2019 12:55:50 PM Lease Expires . . . . . . . . . . : Saturday, August 3, 2019 1:01:45 AM Default Gateway . . . . . . . . . : 192.168.1.1 DHCP Server . . . . . . . . . . . : 192.168.1.1 DNS Servers . . . . . . . . . . . : 22.214.171.124 126.96.36.199 NetBIOS over Tcpip. . . . . . . . : Enabled
Another common command on most user host OSs is the netstat -rn command. This command lists the host’s IP routing table. Of interest, the top of the table lists a route based on the default gateway, with the destination subnet and mask listed as 0.0.0.0 and 0.0.0.0. The top of the output also lists several other routes related to having a working interface, like a route to the subnet connected to the interface. Example 7-7 lists an excerpt from the netstat -rn command from the same Windows host, with the default route and the route to the local subnet (192.168.1.0) listed. Note that a gateway of “on-link” means that the PC thinks the destination is on the local subnet (link).
C:DOCUME1OWNER> netstat -rn IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.172 25 127.0.0.0 255.0.0.0 On-link 127.0.0.1 331 127.0.0.1 255.255.255.255 On-link 127.0.0.1 331 127.255.255.255 255.255.255.255 On-link 127.0.0.1 331 169.254.0.0 255.255.0.0 On-link 169.254.244.178 291 169.254.244.178 255.255.255.255 On-link 169.254.244.178 291 169.254.255.255 255.255.255.255 On-link 169.254.244.178 291 192.168.1.0 255.255.255.0 On-link 192.168.1.172 281 192.168.1.172 255.255.255.255 On-link 192.168.1.172 281 192.168.1.255 255.255.255.255 On-link 192.168.1.172 281 ! Lines omitted for brevity
Although the particulars vary, like Windows, macOS has both a graphical interface to see network settings and a variety of network commands. This section shows examples of each, beginning with Figure 7-10. 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.
macOS and Linux both support the ifconfig command to list information similar to the Windows ipconfig /all command. (Note that ifconfig does not have an /all option.) Of note, the ifconfig command does not list the default gateway or DNS servers, so Example 7-8 includes two other macOS commands that supply those details.
Wendell-Odoms-iMac:~ wendellodom$ ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV> ether 0c:4d:e9:a9:9c:41 inet 192.168.1.102 netmask 0xffffff00 broadcast 192.168.1.255 ! IPv6 details omitted for brevity media: autoselect (1000baseT <full-duplex,flow-control,energy-efficient- ethernet>) status: active Wendell-Odoms-iMac:~ wendellodom$ networksetup -getinfo Ethernet DHCP Configuration IP address: 192.168.1.102 Subnet mask: 255.255.255.0 Router: 192.168.1.1 Client ID: IPv6: Automatic IPv6 IP address: none IPv6 Router: none Ethernet Address: 0c:4d:e9:a9:9c:41 Wendell-Odoms-iMac:~ wendellodom$ networksetup -getdnsservers Ethernet 188.8.131.52 184.108.40.206
Like Windows, macOS adds a default route to its host routing table based on the default gateway, as well as a route to the local subnet calculated based on the IP address and mask learned with DHCP. And like Windows, macOS uses the netstat -rn command to list those routes—but with several differences in the output. Of note in the macOS sample shown in Example 7-9, the output represents the default route using the word default rather than the paired numbers 0.0.0.0 and 0.0.0.0 for the destination subnet and mask.
C:DOCUME1OWNER> netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGSc 92 0 en0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 4 1950 lo0 169.254 link#5 UCS 2 0 en0 ! 169.254.210.104 0:5:1b:a3:5d:d0 UHLSW 0 0 en0 ! 192.168.1 link#5 UCS 9 0 en0 ! 192.168.1.1/32 link#5 UCS 1 0 en0 ! 192.168.1.1 60:e3:27:fb:70:97 UHLWIir 12 2502 en0 1140 192.168.1.102/32 link#5 UCS 0 0 en0 ! ! lines omitted for brevity
On Linux, the graphical windows to display network settings differ for many reasons. First, the Linux world includes a large number of different Linux versions or distributions. Additionally, Linux separates the OS from the desktop (the graphical interface) so that a user of one Linux distribution can choose between different desktop interfaces. As a result, you will see different GUI screens to display the Linux network settings.
For perspective, this section shows a few examples from the MATE desktop included in the Ubuntu MATE Linux distribution (www.ubuntu-mate.org). First, the image in Figure 7-11 shows details for a wireless LAN adapter and includes the IPv4 address, mask, default router, and primary DNS IP address.
From the command line, Linux hosts will often support a large set of commands. 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 includes 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.
Example 7-10 shows a sample of the ifconfig command for the same interface detailed in Figure 7-11. Note that it lists the Ethernet MAC and IPv4 addresses, along with the subnet mask, similar to the macOS version of the command. However, on Linux, it also shows some interface counters.
chris@LL ~ $ ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 30:3a:64:0d:73:43 inet addr:192.168.1.223 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::e5b8:f355:636a:b2a4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2041153 errors:0 dropped:0 overruns:0 frame:0 TX packets:712814 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2677874115 (2.6 GB) TX bytes:134076542 (134.0 MB) chris@LL ~ $ ip address 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 30:3a:64:0d:73:43 brd ff:ff:ff:ff:ff:ff inet 192.168.1.223/24 brd 192.168.1.255 scope global wlan0 valid_lft forever preferred_lft forever inet6 fe80::e5b8:f355:636a:b2a4/64 scope link valid_lft forever preferred_lft forever
The bottom of the example shows the command from the iproute package that replaces ifconfig, namely the ip address. Note that it shows the same basic addressing information, just with the subnet mask shown in prefix notation rather than in dotted decimal.
Linux has long supported the netstat -rn command as well, as part of the net-tools package, with a sample shown in Example 7-11. The output lists a default route, but with a style that shows the destination as 0.0.0.0. As usual, the default route points to the default gateway as learned with DHCP: 192.168.1.1. It also lists a route to the local subnet (192.168.1.0 as highlighted toward the bottom of the output).
chris@LL ~ $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 chris@LL ~ $ ip route default via 192.168.1.1 dev wlan0 proto static metric 600 169.254.0.0/16 dev wlan0 scope link metric 1000 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.223 metric 600 chris@LL ~ $
The bottom of the example shows the command meant to replace netstat -rn: ip route. Note that it also shows a default route that references the default router, along with a route for the local subnet.
One key to doing well on the exams is to perform repetitive spaced review sessions. Review this chapter’s material using either the tools in the book or interactive tools for the same material found on the book’s companion website. Refer to the “Your Study Plan” element for more details. Table 7-2 outlines the key review elements and where you can find them. To better track your study progress, record when you completed these activities in the second column.
Review key topics
Review key terms
Repeat DIKTA questions
Review command tables
Key Topic Element
Definitions of special IPv4 addresses 0.0.0.0 and 255.255.255.255
Four logic steps created by the ip helper-address command
What the ip helper-address command changes in a DHCP Discover message
The two facts that must be true about a subnet for a router to need to be a DHCP relay agent for that subnet
Switch commands that confirm the details of DHCP client operations based on the ip address dhcp interface subcommand
The IPv4 settings expected on an end-user host
Output from a Windows ipconfig /all command
Output from a macOS ifconfig command plus two networksetup commands
Tables 7-4, 7-5, and 7-6 list configuration and verification commands used in this chapter. As an easy review exercise, cover the left column in a table, read the right column, and try to recall the command without looking. Then repeat the exercise, covering the right column, and try to recall what the command does.
ip helper-address IP-address
An interface subcommand that tells the router to notice local subnet broadcasts (to 255.255.255.255) that use UDP, and change the source and destination IP address, enabling DHCP servers to sit on a remote subnet
ip address dhcp
An interface subcommand that tells the router or switch to use DHCP to attempt to lease a DHCP address from a DHCP server
show arp, show ip arp
Command that lists the router’s IPv4 ARP table
show dhcp lease
Switch command that lists information about addresses leased because of the configuration of the ip address dhcp command
show ip default-gateway
Switch command that lists the switch’s default gateway setting, no matter whether learned by DHCP or statically configured
(Windows) Lists IP address, mask, gateway, and DNS servers
(Mac, Linux) Lists IP address and mask for an interface
networksetup -getinfo interface
(Mac) Lists IP settings including default router
networksetup -getdnsservers interface
(Mac) Lists DNS servers used
(Windows, Mac, Linux) Lists the host’s routing table, including a default route that uses the DHCP-learned default gateway
(Windows, Mac, Linux) Lists the host’s ARP table
(Linux) Lists IP address and mask information for interfaces; the Linux replacement for ifconfig
(Linux) Lists routes, including the default route and a route to the local subnet; the Linux replacement for netstat -rn