Welcome back! I hope you’ve enjoyed your last couple of weeks off — I know I have (if, by enjoy, you mean lots of meetings and late-night lab rebuilds).
This particular class is about the procedures beyond the day-in and day-out of server administration (like last class). In this class we will be learning the intricacies of the mechanisms that allow our networks to work. Be prepared to discuss things such as DNS, security (including IPSec), WSUS, etc.
In today’s class, we discussed DHCP. If you reach way back to the Network+ class, you’ll remember that DHCP stands for Dynamic Host Configuation Protocol. What that means is that this particular protocol will automatically configure our computers with IP addresses, subnet masks, gateways, DNS servers and more. This becomes nicer and nicer the larger our networks become — imagine having to manually configure 500 different computers — the time alone to complete this task would be phenomenal and that’s assuming that we wouldn’t make ANY mistakes on any of those 500 computers. Ha!
Just for review, recall that the configurations that clients receive are called leases, and are temporary in nature. In Windows networks, they last for eight days, and the clients try renewing the leases starting at day four. Typically, the client is allowed to keep getting the same IP address, although it’s not guaranteed.
We discussed some of the requirements of the DHCP server. For Windows networks, this means NT4+, a server with a static IP address (irony? no, not really) and a valid range of addresses at your disposal. For a computer to use DHCP as a client, basically any modern or semi-modern operating system will do. For example, Windows 3.11 will receive a dynamically assigned IP address.
Now, back in Net+, I promised we would get into DHCP much deeper, and I plan on keeping that promise.
We’ve discussed how DHCP works in general terms. The DHCP client comes alive, broadcasts out on the network looking for a server. If one’s available, it responds back and configures the client, if one’s not, the DHCP client self configures with an APIPA address. But, let’s really look at how the DCHP process works.
There are up to eight different types of packets that get thrown around on the network during typical DHCP conversations. The four most common:
- DHCPDISCOVER – This packet is sent out by the client machine. It’s by definition a broadcast packet, and its sole purpose is to dig up a DHCP server somewhere.
- DHCPOFFER – This packet is sent out by the server to a client machine in response to a DHCPDISCOVER packet. No configuration is happening yet, the server is just introducing itself and offering IP address configuration. We do this in case there are more than one DHCP server in the subnet, the client can then turn away “late” DHCPOFFER packets (more on this in a moment).
- DHCPREQUEST – This is a client packet, and it’s sent out to the first DHCP server to send out a DHCPOFFER packet. It’s the formal request for configuration, and basically tells the server, “Hey, thanks for the configuration, I’ll take it.”
- DHCPACK – This packet, sent out by the server, acknowledges (hence the ACK) that the client has accepted its configuration and logs its presence in the server. That particular IP address will not be given to another client unless the client gives it up later.
There are, of course, other types of DHCP packets:
- DHCPDECLINE – This packet is sent by the client to the server declining its offer. This packet would be sent to DHCP servers who respond the clients after the inital DHCP server responds (remember our example above?)
- DHCPNACK – Sometimes, when a client tries to renew it’s lease, the server says no. Usually the reason is that the client machine is now in a different subnet, but sometimes we just want to deny network access to a client, and this is one way of doing it.
- DHCPRELEASE – This type of packet releases the client’s IP address. To accomplish this in a Windows system, we issue the
ipconfig /release command.
- DHCPINFORM – This packet is used by clients in order to obtain additional IP addresses.
Clear? Good. Now, here’s a wrench: the DHCPDISCOVER packet is a broadcast packet right? What happens when the DHCP client is on one subnet and the DHCP server is on another subnet on the other side of a router? If the router is like most, the client won’t be able to find the DHCP server — routers block broadcast packets. This can present some problems. It’s not exactly cheap buy lots of servers simply for running DHCP servers.
We have two possible solutions to this problem. First, we could purchase a RFC1542-compliant router, which is a fancy way of saying “Buy a router that DOES let broadcast packets through!”. This would certainly work, but may defeat the benefit of the router by combining broadcast domains. Another solution we could do is set one server up as a DHCP Relay Agent. I like this solution — with it, we name some random server as an informant of sorts. This particular server listens for DHCPDISCOVER packets, and then wraps them up as non-broadcast packets and smuggles them across the router, destined for the DHCP Server on the other side. The DHCP server then takes over and configuration happens as normal.
So what happens when a client can’t find a server with whom to connect? After a period of trying to locate a server, the client will self-configure with an older dynamic configuration protocol called Automatic Private IP Addressing (APIPA). An APIPA address starts out with the octets 169.254 and has random entries in the last two octets. Once the client receives an APIPA address, it continues to try to contact a DHCP server every five minutes. The reason is because an APIPA address cannot be routed, which means you will NOT be able to access the Internet, or any other network on the other side of a router.
Ok, theory aside, we jumped into the actual DHCP server configuration and looked around at some things. One thing to point out, if your DHCP server is running inside Active Directory, it must be authorized by an administrator. This is to prevent rouge servers from popping up on the network and handing out phony addresses.
We discussed the concepts of Reservations and Exclusions. Oftentimes, students will confuse the two, and it’s important that you recognize the differences between the two. To configure a Reservation, you will need the MAC address of a client, and the server will reserve a specific IP address for that MAC address. No other host will receive it, but the host will still receive its configuration dynamically. When you configure an exclusion, on the other hand, it is in effect telling the DHCP server not to even hand out a particular address or range of addresses. This is useful if you have servers or specialized clients that need static IP addresses right in the middle of your IP address range. For example, I might have a configured scope of 192.168.1.0 – 192.168.1.255, but have some servers that live on 192.168.1.50-55. Those servers would be statically configured with their IP addresses, and then I would configure exclusions in the DHCP server to not hand out those IP addresses to clients.
Homework:
