dhcpd problem on virtual machines

[David W. Hankins]

Sorry I didn't notice this earlier (I tend to watch dhcp-workers
closer than dhcp-hackers), but hopefully the information is still
useful.

On Thu, Apr 15, 2010 at 02:04:40PM +0100, Alex Zeffertt wrote:
> There are several possible solutions to this, and I'm keen to find out 
> which of these - if any - seems the best to you:
>
>  i)   Always use AF_PACKET in dhclient

This is not really an option as it requires the full implementation of
the IP stack, including IP routing.  Currently we only have enough of
the IP stack implemented ourselves for basic function.

>  ii)  Use AF_INET in dhcpd for receiving packets instead of AF_PACKET (*)

Note this is an option we are investigating in a future version of the
software.  If you check the dhcp-hackers mailing list archive, there is
actually a discussion with some ideas on how to implement a DHCP server
on modern unixes without the use of a raw socket.

Otherwise, it can be selected for use as a compile-time option, but
coming with this is the limitation that it will not work with directly
connected clients that rely on strict RFC 2131 compliance with regard
to the destination IPv4 address of some DHCPv4 packets.

>  iii) Don't verify the checksum in dhcpd if the hardware supports checksum offload

iv) Use extended packet information available on the AF_PACKET socket
    on 'dhcpd' to determine not to validate checksums.

We actually have a patch queued from one of the Linux distributions
that performs this.  Of course, it's platform specific.

v) Locate the DHCP server external to the virtual machine so that the
   hardware has calculated the checksum.

> (*) Actually dhcpd has two sockets open, one AF_INET and one AF_PACKET. 
> However, the packets received over the AF_INET socket are silently dropped, 
> whilst the copies received over the AF_PACKET socket get used.

The AF_INET socket is only used for transmission in this scenario.
Anything it receives is ostensibly a duplicate.

I've been wanting to try in our lab setting the receive socket buffer
size to zero to see if this eliminates the extra reads and select
wakeups.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-hackers/attachments/20100611/27c4c896/attachment.bin>