The fourth article in my series covering BIND 10 has nothing to do (directly) with DNS. This one describes how to configure the DHCP4 component of BIND 10 to provided DHCP service for IPv4 clients in my lab network. I used bind10-1.0.0-rc.

There is quite an important caveat to note from the RC release notes:

As you can see, DHCPv4 clients must be connected to the DHCP server via a relay. As I have no Cisco devices on my home network running ip-helper or similar, I used dhcrelay to provide DHCP relay services. I configured my network as per the following diagram, utilising three CentOS 6.3 x86_64 VMs:

gooby will provide DHCP service to the 192.168.172.0/24 network via its eth1 interface. spooderman‘s dhclient will come online and make a multicast discovery request. dhcrelay on gooby will relay that message out of eth0 to dolan and b10-dhcp4. b10-dhcp4 will assign an IP address based upon configuration and current leases, and hand the offer back to gooby. dhcrelay will receive this offer, and relay it back out over eth1 via broadcast. spooderman will pick up this offer, and acknowledge it. Once b10-dhcp4 receives the acknowledgment, it commits the lease to the MySQL database. dhclient configures spooderman‘s eth0 interface, and the exercise is complete.

As 172.16.18.0/24 is my NATted network out of my test workstation, VMware provides its own DHCP service on the host OS - ensure this is shut down prior to commencing work. If your networks do not already run a DHCP service, you don’t need to worry about that - if they do, shut them down before proceeding (as long as this isn’t production :/) …

With the network planned and any existing DHCP services disabled, we can continue.

Building BIND 10

Prior to (re)building BIND 10 on dolan, you will need to have MySQL server installed (not strictly on the same server, but I did for simplicity’s sake), the MySQL libraries and the MySQL development files (headers and such).

Get the latest MySQL release via whichever package management system you use. I use CentOS, so yum it is:

Ensure that mysql_config is in PATH:

Once the packages are correctly installed and mysql_config is located, BIND 10 can be built. If you’ve already built a BIND 10 install like me, back it up first after ensuring BIND 10 is shut down:

Change to your extracted source directory (I’ve compiled before) …

and clear up the previous run:

Now, we can configure. The important option to note is --with-dhcp-mysql, which will look for mysql_config in the default PATH. If you have installed MySQL to a non-standard location, you will need to specify the absolute path to mysql_config, e.g.: --with-dhcp-mysql=/path/to/mysql_config.

If you don’t have all those supporting applications already installed, you can read my first article to learn how to build and install them.

Once configure has completed successfully, you can compile and install the software:

As you can see, using a symlink pointed at your current version makes installation and rollback easy, and any existing scripts you’ve written will not need to be updated.

Configuring MySQL

In the previous section, MySQL was installed but left in an unconfigured state. Before we can move on to configuring DHCP under BIND 10, MySQL must be initialised and configured, and the appropriate schema loaded. It would help to have some MySQL skills so you know what’s going on if anything doesn’t work as expected.

Initialise the MySQL system tables first, using mysql_install_db. If you’ve not changed the MySQL datadir, then this will be /var/lib/mysql on a RHEL-derived system:

MySQL can now be started. Whilst I added the mysqld service via chkconfig, I disabled the option to have it start at boot. If I started all my services automatically on the lab systems, they’d be a little busy …

As soon as MySQL is up, define a root password - it’s blank to begin with:

You might want to use something better than newpassword for the new password. Connect to the MySQL monitor as root using the newly defined password:

Next, create the database:

I created a database called b10dhcp, connected to it, and sourced in dhcpdb_create.mysql, distributed with the BIND 10 release. Once the schema was created, I granted all privileges on the b10dhcp database to b10user, who may only connect from localhost using the password b10pass.

Attempt a connection as the newly created user to ensure there are no issues:

MySQL configuration is now complete, and we’re ready to configure BIND 10.

BIND 10 Configuration for DHCPv4

Before configuring BIND 10, we’d better start it. I found that running BIND 10 as a non-privileged user (starts as root, binds to appropriate ports and then drops its privileges) as I do for BIND 10 when serving DNS (-u bind10) wouldn’t work when b10-dhcp4 tried to bind to port 67. The only way the port bind succeeded was by running the entire service as root - which wouldn’t be desirable if you were also hosting DNS from this instance:

Next, as this is a fresh installation, I created a new user via b10-cmdctl-usermgr to administer the instance,

and connected via bindctl:

The b10-dhcp4 component is enabled and started next. This assumes the default message queue address of Dhcp4 as we define nothing else:

We define kind dispensable so that b10-init can restart it if required. If you review the BIND 10 logs (in my case, nohup.out as I’ve not defined logging yet - the default is STDOUT) you will see messages along the following lines (if the startup is successful):

Let’s review the standard Dhcp4 configuration:

All of these configuration items are described in the BIND 10 Guide so I will only describe what we change - you will need to review the various timing parameters specifically for your environment.

The first step is to define the backend MySQL datasource within the Dhcp4 configuration. Do this as follows:

We define Dhcp4/lease-database/host as an empty string - shorthand for localhost. It’s worth noting here that Dhcp4/lease-database/password is stored within the BIND 10 configuration (b10-config.db) in clear text. If no errors are noted during the commit, you should see a successful connection in the logs:

Any issues at this point should be traced. Check your MySQL GRANT statements and your BIND 10 Dhcp4 data source configuration.

The next thing to add is a subnet and an address pool to our BIND 10 configuration:

This is equivalent to the ISC dhcpd.conf configuration syntax:

A number of additional options are also required for DHCP to give the client enough information to be able to be networked correctly - such as routers, domain-name-servers, etc. I’ll define just two here - the aforementioned routers and domain-name-servers - but you should review the list of standard options in the BIND 10 Guide and ensure that all appropriate options are set for your environment (comparing with options set in your current dhcpd.conf if applicable):

With all appropriate Dhcp4 parameters defined, we can move on to dhcrelay configuration.

dhcrelay Configuration

On gooby, I’m running dhcrelay to pass requests between eth1 and eth0 and back again. This is very simple to achieve. Install the current ISC DHCP implementation; on RHEL-like systems this will install dhcpd, dhclient and dhcrelay:

Modify /etc/sysconfig/dhcrelay as follows:

Now, start dhcrelay:

The DHCP implementation is now ready to be put to work.

Boot the Client

spooderman is booted, but its network interface configuration has (deliberately) not been configured. Modify /etc/sysconfig/network-scripts/ifcfg-eth0 so it contains (at a minimum):

Again, this presumes a RHEL-based system. Configure your network interface for DHCP via whichever mechanism is supported by your OS.

Restart your network service (or simply ifup eth0) and the DHCP transaction should occur.

You can perform the following steps on your dhcrelay server to watch the relaying occur:

This will cause dhcrelay to operate in debug mode, and also run in the foreground. Here, we can see that the BOOTREQUEST is received and relayed to dolan. b10-dhcp4 then responds with the address and dhcrelay forwards the BOOTREPLY back to the host requesting the IP (and here we see the assigned IP - 192.168.172.10).

We can also use tcpdump to monitor the traffic - a simple trace of all appropriate interfaces on dolan and gooby were used to troubleshoot DHCP traffic:

Once you’ve verified that your client has an IP address

you can check the MySQL database:

We have a DHCPv4 lease! Digging further:

This is exact output - the deformation caused by the unprintable characters in the hwaddr field. Checking a DESCRIBE on the table:

I guess this will stop us manually fiddling around with the database One thing I did note - b10-dhcp4 does not seem to honour a DHCPREQUEST when a client attempts to request an existing IP that has been leased to it. After three ifup/ifdown cycles on spooderman, b10-dhcp4 had reissued a new IP each time:

Conclusion

This article has illustrated how to configure DHCPv4 under BIND 10, utilising a DHCP relay to pass client messages on to BIND 10 for address assignment.

This is the first publicly available release of BIND 10 to be able to offer leases to clients, hence there are some limitations around functionality (DHCPv6 appears to be a little further developed at present). There still seem to be a few kinks to iron out, but the functionality is definitely coming along.

Important Note for VMware Users

If you’re running your lab environment under desktop versions of VMware (Workstation, Fusion) you’ll need to place eth0 on your dhcrelay server into promiscuous mode (run tcpdump in the background, for example).