DHCP for Wireless LAN Clients

DHCP for Wireless LAN Clients

By CWNP On 12/29/2011 - 94 Comments

For us wireless folks that aren’t stellar routing and switching guys, one of the most daunting network tasks is integrating our WLAN infrastructure with the existing wired infrastructure and its services. Understanding wired design topics is pretty fundamental to installing or managing any network, so it really should be on our priority list to spruce up those skills. To give you a nudge on your journey, let’s talk about Dynamic Host Configuration Protocol (DHCP) for wireless clients.

Dynamic Host Configuration Protocol (DHCP) is one of those oft-overlooked topics that you must understand for initial wireless configuration and connectivity troubleshooting. In this article, I want to focus on understanding a few ways in which your wireless infrastructure participates in the client’s process of obtaining a DHCP address.

In a typical client connection to a wired Ethernet port, the client will be a member of a VLAN based on the switch port configuration. When the client connects, it does the usual DHCP exchange by sending a broadcast DHCP discovery frame to find a DHCP server. If there’s a DHCP server on the local Layer 2 domain, it will reply and everyone will be happy. However, if the DHCP server is not on the local subnet, a router must be configured to forward the DHCP discovery. Typically, this is accomplished by configuring an IP Helper Address on the router, which is just a way of telling the router to relay certain broadcast UDP frames (like DHCP) to a specific IP destination. In the case of DHCP, the router will forward the DHCP discovery and request as unicast frames to one or more pre-configured DHCP servers.

However, the router does something interesting. Remember that the original client doesn’t yet have an IP address, so there is no source IP address in the DHCP discovery. When a router forwards the frame across the IP network, the router must include a relay IP address so that the DHCP server can send the DHCP offer back to the proper relay device. For this, the router uses the interface (or subinterface) IP address that matches the client’s VLAN.

For wireless clients, when you understand the above process, DHCP is not terribly complex. There are a few more potential gotchas on the wireless segment, though. A few reasons why Wi-Fi DHCP is a little different follow:

1. An AP’s radio interface performs different functions than an access (non-trunked) port on a switch
1. A single radio interface is expected to allow multiple clients at the same time
2. The radio interface may support multiple service sets with different parameters and functions
3. Clients associated to an interface may be in different VLANs
2. The AP may be connected to its uplink switch via a trunk (with multiple VLANs) or an access port (with only a single VLAN) and may forward data directly to its source or tunnel the data to a WLAN controller for forwarding
3. Clients move

So the first goal for the infrastructure is to determine which VLAN a wireless client belongs in. There are two primary ways this is done today. The most common method is to statically map an SSID with a VLAN. Once the client associates to the SSID, it is automatically placed in that SSID’s VLAN. The other method—more flexible, but less common— is to implement 802.1X user-based policies in which the client is assigned to a VLAN dynamically based on RADIUS attributes sent during 802.1X authentication. Regardless of the method, after the authentication is complete, the infrastructure (WLAN controller and/or AP) can map the client with a VLAN and IP subnet. Of course, the client doesn’t know which subnet it belongs in.

When the client initiates a DHCP exchange, the WLAN infrastructure can handle it in a few ways.

DHCP Bridging
DHCP bridging is somewhat self-explanatory in that the WLAN infrastructure simply “bridges” the DHCP frames to the wired network without modifying them. Neither the WLAN controller nor AP changes the DHCP frames in any way. In this configuration, the upstream wired network remains responsible for handling DHCP exchanges, as described previously for wired clients. This is the expected behavior for a WLAN infrastructure that does not support the proxy or relay DHCP features described later.

Below is an overly simplified network diagram in which the DHCP server is in a different IP subnet than the client.

With DHCP bridging, the client’s DHCP discovery and request frames would be passed to the upstream network, in this case, the first router (connected via a red link for illustration). The router would then act as a DHCP relay agent, forwarding/routing the DHCP discovery and request to the DHCP server. A frame decode of this is shown below, captured from the red link prior to the router’s modification.

[/caption]

DHCP Relay
At the beginning of this article, we described the DHCP exchange for a wired client. When a DHCP discovery or request hits an IP subnet boundary, a router must be configured with an IP Helper address pointing to a DHCP server. Wi-Fi segments can accomplish the same basic task by turning the AP or WLAN controller into the relay agent.

Vendors usually call this DHCP Relay. Either the AP or the WLAN controller (depending on the data forwarding plane) receives the DHCP discovery/request and forwards the frame to the DHCP server(s), adding its own IP address as the relay.

The key configuration requirement for DHCP Relay is that the WLAN controller or AP must have an interface with a corresponding IP address in each of its clients VLANs—and potential clients’ VLANs. The WLAN infrastructure uses the corresponding interface and IP address as the relay agent IP address for the DHCP discovery and request frames. By using the client’s VLAN/subnet as the relay agent IP, the DHCP server knows to provide an IP address in the correct client subnet.

A frame decode of DHCP Relay is shown below. This frame was also captured from the red link between the wireless infrastructure and the router. The WLC/AP has changed the destination from broadcast to unicast (the DHCP server’s IP address) and has placed its own client-side IP address as the relay agent IP address.
 

DHCP Proxy
DHCP Proxy is similar to DHCP Relay in its basic function, but it goes a step further. Instead of merely forwarding the frames back and forth, the DHCP Proxy takes a more active role by inserting itself as a DHCP server to the client device. When the client sends the DHCP discovery and request frames, the WLAN infrastructure alters (or rebuilds) the frames and unicasts them to the DHCP server. After receiving the offer from the DHCP server, the WLAN infrastructure sends a DHCP offer to the client, presenting itself as the DHCP server. The WLAN infrastructure maintains a table of client MAC to IP mappings, drawing on this information to add security and performance functionality to the WLAN (I’ll explain in a minute).

If we were to look at a frame trace of DHCP proxy on the wired side as we did in the previous DHCP bridging and DHCP relay traces, DHCP proxy would look the same as DHCP relay. Below is a frame trace of DHCP proxy on the Wi-Fi interface. This frame is the DHCP offer sent to the Wi-Fi client. The WLAN infrastructure offers the IP address to the client, using its own IP address as the DHCP server. For this, the WLAN infrastructure is configured with a virtual IP address (it was common practice to use 1.1.1.1 in Cisco WLANs, but now recommended that an unused private address be used instead), which is the “DHCP server” IP address shown to the client. You’ll see here that the client is offered 10.10.50.4/24 from 1.1.1.1.

There are three primary benefits to DHCP Proxy:

1. By converting a broadcast frame to unicast at the frame’s entry point on the wired network (other than in a tunnel to the WLAN controller, which is also unicast), the DHCP relay and proxy features both eliminate wireless broadcast DHCP traffic on the LAN.
2. We mentioned earlier that the WLAN infrastructure maintains a client MAC/IP table, and this table enables the infrastructure to apply security policies between the wired and wireless segments. Specifically, participation in the DHCP process prevents unauthorized DHCP traffic between wireless and wired segments, it allows the WLAN to prevent IP and ARP spoofing as well as rogue DHCP servers, and it protects against other DoS attacks.
3. DHCP proxy also improves roaming performance. When a client roams between Layer 3 boundaries, it recognizes the need to request a new IP address. By sharing the virtual IP address (e.g. 1.1.1.1) across a mobility domain (i.e. in Cisco speak), the WLAN infrastructure can easily and efficiently renew the client’s IP address without the back-and-forth with the real DHCP server. The added efficiency and IP renewal may prevent a disruption to applications that require a continuous session.

Impact of the Data Plane
When it comes to WLAN architectures with DHCP features, the device that relays or proxies the DHCP frames will either be the AP or the WLAN controller. Regardless of the forwarding model, the device(s) that is responsible for DHCP relay or proxy features must be configured with interfaces on each client VLAN/subnet. If data is forwarded through the WLAN controller (i.e. centralized), it makes sense that the WLAN controller would be handling DHCP features. In distributed forwarding models, network design plans should account for more IP address consumption because each AP will need an IP address for each supported client subnet. When large numbers of APs serve each client VLAN, IP address consumption becomes excessive and the DHCP Bridging model is a better design choice than DHCP proxy/relay. To date, only one vendor supports DHCP relay in a distributed fashion.

Final Comments and Suggestions (FCS)
DHCP is not always  first on the list of hot topics for wireless design priorities. No less, poor DHCP planning for your network could have a significant impact on WLAN service availability. For that reason, and for troubleshooting problems that will inevitably arise, any WLAN engineer should know the three primary ways to manage DHCP in a WLAN: bridging, relay, and proxy. We spend a lot of time and energy improving our RF environments; it would be a real shame to let DHCP ruin client connectivity.
 
I am much obliged to Andrew VonNagy (@revolutionwifi) for offering improvements and keeping me on point with technical review of the article.
And a big thanks to George Stefanick (@wirelesssguru) for providing insight on the topic and “labbing” the concepts to provide the frame traces. He is also responsible for saying: “this would make a good blog post.”
 
For further reading on similar topics, see these articles from the RevolutionWiFi blog by Andrew VonNagy:
Explaining DHCP Server 1.1.1.1 - http://revolutionwifi.blogspot.com/2011/03/explaining-dhcp-server-1111.html
Wireless Network Segmentation Options - http://revolutionwifi.blogspot.com/2011/01/wireless-network-segmentation-options.html
Dynamic VLAN Assignment - http://revolutionwifi.blogspot.com/2011/01/dynamic-vlan-assignment_31.html

Editor's Note: This post was originally published in December 2011 and has been updated for accuracy and comprehensiveness.

Tagged with: roaming, Mobility, DHCP proxy, DHCP relay, IP Helper, subnet, 1.1.1.1

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.