Technical Articles
F5 SMEs share good practice.
cancel
Showing results for 
Search instead for 
Did you mean: 
JRahm
Community Manager
Community Manager

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.

0151T000003d4DaQAI.png

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:

0151T000003d4DbQAI.png

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.

0151T000003d4DcQAI.png

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.

0151T000003d4DdQAI.png

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

0151T000003d4DeQAI.png

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
tarma_58716
Nimbostratus
Nimbostratus
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?

 

JRahm
Community Manager
Community Manager
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
tarma_58716
Nimbostratus
Nimbostratus
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) .
JRahm
Community Manager
Community Manager
if disabling, then no.
Kenny_48664
Historic F5 Account
Can we rate limit DHCP requests thru this type of VS?
JRahm
Community Manager
Community Manager
I think 11.2 supports rate limiting functionality natively, otherwise you can build it into an iRule.
vincent_ing_129
Nimbostratus
Nimbostratus
Hi Jason,

 

 

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

 

 

cheers,Vince

 

vincent_ing_129
Nimbostratus
Nimbostratus
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
brad_11480
Nimbostratus
Nimbostratus
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.
dbizzle_20930
Nimbostratus
Nimbostratus
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?
JackF
F5 Employee
F5 Employee

@JRahm ,

We are testing this out and running into a new issue.  We see where the DHCP server will ignore the source IP and send the DHCP offer based on the gateway address.  This can be called: DHCP relay on wireshark, gateway address on tcpdump, and giaddr.  

So is there a way, or a suggested way, to change the Gateway-IP?  

Note: These are /27's subnets in the screenshot:

JackF_0-1677189060021.png

JackF_1-1677189084933.png

 

JRahm
Community Manager
Community Manager

Hi @JackF ... i don't have a BIG-IP up and accessible currently (tomorrow sometime?) but are there any db keys you can toggle/set for DHCP? I don't think the stock solution supports that and I'd say iRules but I'm not sure what events would be triggered if any by DCHP relays. Will have to set that up to dig in.

Version history
Last update:
‎14-Aug-2012 08:46
Updated by:
Contributors