dhcplb is Facebook's implementation of:
Both modes currently only support handling messages sent by a relayer which is unicast traffic. It doesn't support broadcast (v4) and multicast (v6) requests. Facebook currently uses it in production, and it's deployed at global scale across all of our data centers. It is based on @insomniacslk dhcp library.
Facebook uses DHCP to provide network configuration to bare-metal machines at provisioning phase and to assign IPs to out-of-band interfaces.
dhcplb was created because the previous infrastructure surrounding DHCP led
to very unbalanced load across the DHCP servers in a region when simply using
Anycast+ECMP alone (for example 1 server out of 10 would receive >65% of
Facebook's DHCP infrastructure was presented at SRECon15 Ireland.
Later, support for making it responsible for serving dhcp requests (server mode) was added. This was done because having a single threaded application (ISC KEA) queuing up packets while doing backend calls to another services wasn't scaling well for us.
We needed a server implementation which allow us to have both:
dhcplb at Facebook?
This picture shows how we have deployed
dhcplb in our production
TORs (Top of Rack switch) at Facebook run DHCP relayers, these relayers are responsible for relaying broadcast DHCP traffic (DISCOVERY and SOLICIT messages) originating within their racks to anycast VIPs, one DHCPv4 and one for DHCPv6.
In a Cisco switch the configuration would look like this:
ip helper-address 10.127.255.67
ipv6 dhcp relay destination 2401:db00:eef0:a67::
We have a bunch of
dhcplb Tupperware instances in every region listening on
They are responsible for received traffic relayed by TORs agents and load
balancing them amongst the actual
dhcplb servers distributed across clusters
in that same region.
Having 2 layers allows us to A/B test changes of the server implementation.
The configuration for
dhcplb consists of 3 files:
dhcplb will try to balance on
dhcplb does not support relaying/responding broadcasted DHCPv4 DISCOVERY
packets or DHCPv6 SOLICIT packets sent to
ff02::1:2 multicast address. We
don't need this in our production environment but adding that support should be
TODOs and improvements are tracked here
PRs are welcome!
When operating in v4
dhcplb will relay relayed messages coming from other
relayers (in our production network those are rack switches), the response from
the server will be relayed back to the rack switches:
dhcp client <---> rsw relayer ---> dhcplb (relay) ---> dhcplb (server)
In DHCPv6 responses by the dhcp server will traverse the load balancer.
$GOPATH/bin/dhcplb, simply run:
$ go install github.com/facebookincubator/dhcplb@latest
If you wish to clone the repo you can do the following:
$ mkdir -p $GOPATH/src/github.com/facebookincubator
$ cd $_
$ git clone https://github.com/facebookincubator/dhcplb
$ go install github.com/facebookincubator/dhcplb
You can run tests with:
$ cd $GOPATH/src/github.com/facebookincubator/dhcplb/lib
$ go test
dhcplb can be run out of the box after compilation.
To start immediately, you can run
sudo dhcplb -config config.json -version 6.
That will start the relay in v6 mode using the default configuration.
Should you need to integrate
dhcplb with your infrastructure please
see Extending DHCPLB.
You can bring up a virtual lab using vagrant. This will replicate our production environment, you can spawn VMs containing various components like:
dhcrelay, simulating a top of rack switch.
All of that is managed by
You can use this lab to test your
For more information have a look at the vagrant directory.
dhcplb started in April 2016 during a 3 days hackathon in the Facebook
Dublin office, the hackathon project proved the feasibility of the tool.
In June we were joined by Vinnie Magro (@vmagro) for a 3 months internship in
which he worked with two production engineers on turning the hack into a
production ready system.
Original Hackathon project members:
Internship project members:
BSD License. See the LICENSE file.