[Dnsmasq-discuss] dnsmasq: no address range available for DHCP request via tap0

[TJ]

I'm trying to configure DHCP on a KVM/QEMU virtual machine network using
tap interfaces and kernel routing. Using static IP addresses in the VM
guests this approach works fine, but trying to use DHCP has so far
failed.

For the purposes of this example assume the 10.254.254.0/24 subnet is
assigned and routed from upstream (the Internet). The aim is to have one
of these IP addresses assigned to each of the VM guests using DHCP.

The host uses an alias interface on the Internet-connected port:

 sudo /sbin/ifconfig eth0:0 10.254.254.1 netmask 255.255.255.0 broadcast 10.254.254.255

This is to support a multi-homed eth0 interface where the upstream
router routes a block of IPs to the interface.

Forwarding and proxy_arp are enabled on the eth0 interface:

 sudo sh -c "echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding"
 sudo sh -c "echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp"

ARP is proxied since the upstream router imposes constraints on MAC
addresses it is prepared to talk to.

For each VM guest the host creates a tap interface 

 sudo /usr/sbin/tunctl -t tap${IF} -u `id -un` -g `id -gn`

enables proxy_arp:

 sudo sh -c "echo $PROXY_ARP > /proc/sys/net/ipv4/conf/tap${IF}/proxy_arp"

starts the interface:

 sudo /sbin/ip link set tap${IF} up

and adds a route:

 sudo /sbin/ip route add unicast $IP dev tap${IF}

Each guest has a static assignment of the form:

10.254.254.2/24 broadcast 10.254.254.255 with gateway 10.254.254.1

Now I want to replace the static assignments with DHCP. I configured
dnsmasq to bind to the tap interface(s) but it fails to respond on the
interface to the DHCP discovery:

 sudo /usr/sbin/dnsmasq -d --keep-in-foreground --interface=tap0  \
  --except-interface=lo --bind-interfaces --user=nobody \
  --dhcp-range=kvm,10.254.254.2,10.254.254.254,255.255.255.0,10.254.254.255,8h \
  --pid-file=/var/run/vmnet_dnsmasq.pid --conf-file --log-dhcp

dnsmasq: started, version 2.41 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt no-ISC-leasefile DBus
I18N TFTP
dnsmasq: DHCP, IP range 10.254.254.2 -- 10.254.254.254, lease time 8h
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 10.254.251.1#53
dnsmasq: read /etc/hosts - 10 addresses
dnsmasq: no address range available for DHCP request via tap0
dnsmasq: no address range available for DHCP request via tap0
dnsmasq: no address range available for DHCP request via tap0
dnsmasq: no address range available for DHCP request via tap0
dnsmasq: no address range available for DHCP request via tap0


I've tried adding "--listen-address=10.254.254.1" but as I read the
man-pages and mail-list posts about alias interfaces it seems that the
dhcp-range will bind to eth0 since it hosts an alias in the same subnet.

I also tried "--dhcp-host=56:44:45:30:31:32,10.254.254.2", thinking that
a specific MAC might help force the assignment.

However, I've also tried the scenario without an alias interface (no
eth0:0) with no better results.

The key problem I think is that the DHCP server wants there to be an IP
assigned to the tapX interface, in which case:

dnsmasq: DHCP packet: transaction-id is 1976227649
dnsmasq: Available DHCP range: 10.254.254.2 -- 10.254.254.254
dnsmasq: DHCPDISCOVER(tap0) 56:44:45:30:31:32 
dnsmasq: DHCPOFFER(tap0) 10.254.254.5 56:44:45:30:31:32 

However this would complicate matters in the scenario where the
upstream=assigned subnet addresses need to be allocated to the VM
guests.

Is there a 'neat' way for dnsmasq to work with this
tap-interface-with-no-IP-address scenario.

I'm wondering about setting up a tap interface just for dnsmasq to bind
to and then bridging that with the guest interfaces. However as I
understand that would result in all guests seeing all traffic -
something I'd like to avoid.

Obviously, whatever solution is found needs to scale to handling one tap
interface per VM guest - and there could be a lot of those.

Thanks for reviewing this issue - if my commentary seems confused in
places it is because new ideas occurred to me as I was writing this and
I modified it based on additional discoveries.

TJ.