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

[Simon Kelley]

TJ wrote:
> 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.
> 

This stuff always boggles me. I have a similar sort of system using
bridging, with an IP address assigned to the bridge interface.

It occurs to me (without looking too carefully at your setup, as I say,
it's boggling) that the solution may already exist but be disabled.
There is an option called --bridge-interface which says "(eg) treat
packets arriving on tap0 as if they arrived in eth0" and might just work

bridge-interface=eth0,tap0

or

bridge-interface-eth0:0,tap0

You will have to recompile the code to get it, using

make COPTS=-DHAVE_BSD_BRIDGE

This was added for BSD virtual networking, it wasn't clear that it had a
function on Linux, so it's not included on Linux builds. If it turns out
to be useful, I'll include it everywhere.

Simon.