Bridging the Gap – IP Helpers

In a recent post, I wrote about a helpful feature on switches named DHCP snooping. Writing that article got me thinking, what else is helpful in regards to DHCP? Ah yes, IP helpers. In that post, I made mention of a concept called a DHCP relay agent, but I did not go into detail on that specific aspect of the DHCP process. In this article, I want to dive into what an IP helper is, why we may need one (or many), and take a look at some sample configuration.

*Note: I use the terms DHCP relay agent, IP helper, and DHCP helper interchangeably.

First off, as we dig into this post, I am going to cheat. Before we get into the definition of IP helpers and the need for them, I want to recap the steps of the individual parts of the DHCP mechanism, also know as the DORA process (which stands for the individual steps known as Discover, Offer, Request, Acknowledgement). I’m cheating because I’m pulling this section directly from my article on DHCP snooping.

• Discover
  • source: client (0.0.0.0 because it does not have an IP yet) – UDP port 68
  • destination: Broadcast – 255.255.255.255 (UDP port 67) – to be received by an available local DHCP server or DHCP relay agent.
  • general message: “Hi! Would you please assign me an IP address so that I can communicate on the network? Watching cat videos on YouTube is important to me!”
• Offer
  • source: DHCP server – UDP port 67
  • destination: Either broadcast – 255.255.255.255 or the unicast address of the DHCP relay agent (router) if the client is on a different subnet from the DHCP server. Either way, the destination port is UDP 68.
  • general message: “Welcome! I do have an available IP for you! How does 192.168.100.50 sound?”
  • note: Although the destination is broadcast, the client’s source MAC is in the actual DHCP message so that when the client processes the DHCP Offer broadcast message, it knows that it is for that specific client.
• Request
  • source: client (0.0.0.0 because it does not have an IP yet) – UDP port 68
  • destination: Broadcast – 255.255.255.255 (UDP port 67) – to be received by an available local DHCP server or DHCP relay agent.
  • general message: “Yes, I would love to have 192.168.100.50. Would you please allocate it to me?”
• Ack (acknowledgement)
  • source: DHCP server
  • destination: Either broadcast – 255.255.255.255 or the unicast address of the DHCP relay agent (router) if the client is on a different subnet from the DHCP server. Either way, the destination port is UDP 68.
  • general message: “Sure thing, buddy! 192.168.100.50 is all yours (for the specified lease time, that is). Enjoy those internet kittens!”

Alright, we are refreshed on the DHCP DORA process. So now what? What is this IP Helper/DHCP relay agent thing and why do we need it? Let’s start with the DHCP Discover message that begins the whole process of a client attempting to dynamically acquire an IP address. This is an interesting conundrum. A chicken or the egg scenario, if you will. A client needs an IP address to communicate on the network. It needs to send a message to signal that it needs an IP address, but it does not already have an IP, so how will the client find a DHCP server and how will the DHCP server talk back to the client? That is where the broadcast mechanism comes into play. As you can see in the above explanation of the DHCP Discover message, the client just uses a source IP of 0.0.0.0. Because the Discover message is leveraging the broadcast mechanism, the destination is 255.255.255.255. This essentially means, “Hey, anyone on this local subnet please process my DHCP Discover message, and hopefully one of you is a DHCP server!”.

This is all well and good if there actually is a DHCP server on the local subnet with the client. In my experience, that is not typically the case. DHCP servers tend to be either centralized to data centers, or distributed to small compute clusters closer to the clients, but not necessarily directly in each of the client subnets. Because DHCP relies on broadcast messages, and routers do not forward broadcasts, how will a client ever receive an IP address if there isn’t a DHCP server local to the VLAN/network segment in which the client resides? It sounds like we need a “helper” (bad attempt at a joke, but thanks for hanging in there!). We need a way for these DHCP messages to be forwarded to/from the client and DHCP server, and that is where IP helpers enter the picture. At a high level, an IP helper is a feature that runs on a router interface to bridge the gap as the article title states, between the client and the DHCP server that lives on another segment in the network. When configured, the local router to the client will process that DHCP Discover message, and forward it to the specified DHCP server(s) as a unicast message, with the local router’s IP address as the source of the message (this is the same for the DHCP Request message from the client). Conversely, when the DHCP server sends the Offer and Ack messages, they are sent to the unicast IP of the router running the IP helper process, to then make it on to the client.

Let’s take a quick glance at what this looks like with some example configuration (with Cisco IOS/IOS-XE code). Similar to DHCP snooping, there is not much that we have to configure. In fact, it is even less. In this example, we will show that the local router for the client is a VLAN interface (SVI) on a multi-layer switch.

interface vlan 10
  ip address 10.1.1.1 255.255.255.0
  ip helper-address 172.16.1.1

In the above configuration example, we used the ip helper-address command to configure the SVI to send DHCP messages from clients in the 10.1.1.0/24 network to a DHCP server with IP address 172.16.1.1.

In Closing
DHCP is a vital part of IPv4 networks, so I think it’s important to understand at least the high level concepts, especially the DORA process. IP helpers are an important part of making sure clients receive IP addresses when a DHCP server is located on another network segment. The reason for this is in the nature of how clients must request IP addresses. Because they have no IP address, they must send a broadcast message to all devices on the VLAN. Broadcast messages are not forwarded by routers, so the IP helper function sends those DHCP messages to the configured destination DHCP server. IP helpers can also be used to send these DHCP messages to Cisco’s Identity Services Engine (ISE) to assist in profiling devices. Thank you for reading this, and definitely let me know if you have any feedback, especially if I got something wrong.