BIG-IP LTM version 11.1 introduces the DHCP Relay Virtual Server. Previously, it was possible to forward the requests with a set of extensive iRules that probed deeply into the ways of binary, but with the new virtual server style, it is trivial.

How DHCP Works

DHCP is defined in RFC 2131 and  RFC 2132 for clients and servers, as well as  RFC 1542 for relay agents. The basic (successful) operation of a DHCP transaction between client and server is shown below. A client issues a broadcast in the DHCP Discover, one or more DHCP servers respond with an offer, the client responds with the binding IP address, and the server acknowledges.

dhcprelay_0

A DHCP Relay comes into play when a network grows beyond a handful of subnets and centralized control is desired.  Because a DHCP Discover is a broadcast packet, it would never reach a centralized server as the packet would never cross the broadcast domain into another segment. So the job of a relay is to take that broadcast and package it as a unicast request and send on to the defined dhcp servers. Consider the test lab below:

dhcprelay_1

I have two dhcp servers configured on one side of a BIG-IP LTM VE, and a client configured for dhcp on the other. With no configuration on the LTM, the LTM receives the broadcast, but does nothing with it:

09:37:11.596823 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:99:0c:30, length: 300
09:37:14.689826 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:99:0c:30, length: 300
09:37:20.522498 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:99:0c:30, length: 300
09:37:27.609915 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:99:0c:30, length: 300
09:37:42.846379 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:99:0c:30, length: 300

Creating the Configuration

The configuration is very simple. Create a pool of your dhcp servers, assigning IP and port as appropriate (port 67 for IPv4, port 547 for IPv6). The LB algorithm doesn’t matter, as all servers will receive the request.

dhcprelay_3

The virtual server configuration is equally simple. Name it, select the type as DHCP Relay, and then choose the IPv4 or IPv6 destination. Also, define the vlans this virtual should listen on. In my case, net106 where my dhcp client resides.

dhcprelay_2

Now, a dhcp discover from my client is forwarded as expected to my dhcp servers:

08:57:30.176648 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:99:0c:30, length: 300
08:57:30.176766 IP 192.168.106.5.bootps > 192.168.40.102.bootps: BOOTP/DHCP, Request from 00:0c:29:99:0c:30, length: 300
08:57:30.176771 IP 192.168.106.5.bootps > 192.168.40.103.bootps: BOOTP/DHCP, Request from 00:0c:29:99:0c:30, length: 300

Caveats

In a chained configuration where there are multiple BIG-IP LTM’s between client and server, it will be necessary to preserve the source of the originating relay agent (the self IP of the first BIG-IP LTM receiving the broadcast). This is accomplished with a no-translate snat address:

ltm snat dhcp-no-translate {
    origins {
        192.168.106.5/32 { }
    }
    translation /Common/192.168.106.5
}

as well as a now-unicast dhcp relay on the second BIG-IP LTM as shown in the diagram below

dhcprelay_4

For dhcp lease renewal, which is unicast, a forwarding virtual server should be configured (0.0.0.0:67/0.0.0.0) and a no-translate snat should be in place as well. Note that this is an optional parameter. If it is unsuccessful, the client will revert to broadcast. A request for enhancement that would include the no-translate and dhcp renewal configuration as part of the dhcp relay virtual server type selection has been submitted for consideration for future versions.

Comments on this Article
Comment made 27-Aug-2012 by tarma 2
hello
do we need to add a second VS on to the second bigip? or only configuring the snat onto this second bigip will be sufficient?
1
Comment made 27-Aug-2012 by Jason Rahm
yes, the 2nd bigip should get the 0.0.0.0/0.0.0.0:67 virtual as it will be unicast at that point
0
Comment made 28-Aug-2012 by tarma 2
Ok thanks Jason.
One more question, for the snat, if we have translation address disabled onto the vip 0.0.0.0:67/0.0.0.0 and servers responses are directed by default to the bigip2, we don't need snat?
So i don't need snat for that, because the source ip is not modified by the 2nd bigip (requests forwarded directly to servers) .
0
Comment made 28-Aug-2012 by Jason Rahm
if disabling, then no.
0
Comment made 12-Sep-2012 by Kenny 0
Can we rate limit DHCP requests thru this type of VS?
0
Comment made 24-Sep-2012 by Jason Rahm
I think 11.2 supports rate limiting functionality natively, otherwise you can build it into an iRule.
0
Comment made 07-Mar-2014 by vincent_ing 0
Hi Jason,

Is the DHCP relay feature dependent on the 'auto last hop' setting being enabled?

cheers,Vince
0
Comment made 11-Mar-2014 by vincent_ing 0
Hi Jason,
Thanks for the reply. My forwarding information is correct, the F5 is inline and everything works without auto lasthop. However, when I use DHCP relay, I need to enable the auto lasthop on the VLAN where the DHCP requests are coming from. tcpdumps confirm this: I don't see the request begin send out the F5 as an unicast which ALH. Any thoughts on this?
Cheers,Vince
0
Comment made 12-Aug-2014 by brad 267
We would like to reduce the number of ip-helper addresses that we configure in the routers and replace the list with the F5 virtual server IP address as the helper and have the F5 relay the request to all members of the pool. This doesn't quite seem like this DHCP relay would work. Perhaps a layer4 with a clone pool? Hoping that there is a straightforward way to have the F5 handle this without iRules. Thanks.
0
Comment made 12-Aug-2014 by dbizzle 3
would you need the full LTM license to use this, or is this something that can be done with the basic LTM functionality provided in BigIP when provisioned and licensed for GTM?
0