on 14-Aug-2012 08:46
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.
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.
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:
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
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.
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.
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
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
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.
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?
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) .
Is the DHCP relay feature dependent on the 'auto last hop' setting being enabled?
cheers,Vince
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
@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:
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.