[Dnsmasq-discuss] Config file length / performance question

Simon Kelley simon at thekelleys.org.uk
Sat Dec 6 20:52:06 GMT 2008

Johann MacDonagh wrote:
> Hi all,
> Sorry for the long e-mail. The question is towards the end, the
> beginning is just background.
> I am setting up an isolated computer lab using VMware ESX server /
> VirtualCenter. This "enterprise level" VMware product did away with
> NAT based networking like the consumer counterparts, and instead
> expects you to statically give virtual machines IP addresses, or have
> a DHCP server hand them out. Given the highly dynamic nature of the
> lifetime of these virtual machines as well as the wide range of
> operating systems we plan on installing, statically setting IP
> addresses is out of the question. That's where dnsmasq comes in.
> I'm building a custom Gentoo box that will act as the DHCP server.
> Each "experiment" will need to be isolated from other experiments, and
> I plan on accomplishing this via VLANs. Each experiment will be on the
> same switch (actually, a VMware Virtual Switch), and given a unique
> VLAN ID for all machines in that experiment. The Gentoo box will be
> sitting on a special VLAN port that accepts traffic from all VLANs. I
> just need to make sure VLAN support is build into the kernel.
> I've chosen dnsmasq for the DHCP server, because it looks like it can
> listen on multiple interfaces very easily. This is required because
> when want a Linux machine to accept traffic from multiple VLANs, you
> get separate adapters (e.g. if eth0 receives all VLAN traffic, and you
> want to listen to VLAN 2, you run vconfig and get an interface
> eth0.2). In the end, I plan on having about 100 VLANs to work with,
> 1-100.
> That part is easy, the difficult part is making sure the DHCP server
> gives nice IP addresses. For example, I was thinking of this format:
> So, if I start an experiment that gets assigned VLAN 4 with these VMs,
> you get the the following IP addresses:
> Windows XP
> BackTrack
> BackTrack
> Ubuntu
> I also want to make sure that the first VM they select on our little
> web interface is assigned x.x.x.1, the second x.x.x.2, and so on.
> Since all the VMs get powered on at roughly the same time, the
> allocations end up going to whoever requests first.
> Now, the (partial) solution. I have control over the MAC address of
> these machines just before they are powered on. VMware also has a OUI
> for manual MAC addresses. I was thinking of using that to generate MAC
> addresses in the following format:
> 00:50:56:00:VLANID:SUFFIX
> So, the MAC address that I would want the DHCP server to allocate
> to would be 00:50:56:00:04:08.
> My question is (*finally*), which is the best way to go about making
> sure dnsmasq takes this into consideration? I see two solutions:
> 1. Modify source, edit address_allocate in dhcp.c to generate an
> address based on the MAC address.
> 2. Leave source alone, have 2560 lines in the config file, one for
> each possible suffix for each VLAN (100*256).
> So far, the second option seems cleaner, because I can upgrade to
> newer versions of dnsmasq and not worry about editing the source
> again. But, can dnsmasq handle that many configuration lines? Are the
> static allocations stored in some sort of a hash table?

There are no hard limits on the number of configuration lines. The 
dhcp-host configuration options are searched linearly, not hashed. I 
can't see this being a significant performance bottleneck, even with 
2560 options, on any sane modern machine. (It'a only O(n)). If it turns 
out that I'm wrong, I'll happily look at improving performance.

PS. There's one algorithm which is O(n^2) on the number of dhcp-host 
options, but that's a check which runs at start-up. If the daemon starts 
in a reasonable time, there shouldn't be any problems.

You should probably use the --no-ping and --dhcp-authoritative options 
in this application.

> I'm building the gentoo box as we speak, but I thought I would ask the
> community for some input as I try to decide which route to go.



More information about the Dnsmasq-discuss mailing list