dhcpd problem on virtual machines

Alex Zeffertt alex.zeffertt at eu.citrix.com
Tue Apr 20 15:27:40 UTC 2010


Ted Lemon wrote:
> On Apr 20, 2010, at 2:34 AM, Alex Zeffertt wrote:
>> However, fixing this in dhcpd/dhclient is much more straight forward.  We simply 
>> need to acknowledge that if the sender uses AF_INET then so should the receiver. 
>>  Or alternatively, if the receiver uses AF_PACKET then so should the sender.
> 
> I don't disagree with your basic conclusion here, but in what sense is this
> "easy"? How would the DHCP client or DHCP server know? I mean, you could add a
> command-line flag that says "don't checksum," but this is problematic if one
> server is virtual and another isn't, and also the user has to know to use the
> flag, the reason for which most end-users would find peculiar and unexpected.
> 
> Has anybody actually measured the benefit of this hack? Is there a use case
> for it? It sounds a lot like a case of premature optimization. It seems to me
> that it would be better to have a kernel flag, off by default, that enables this
> feature. That way the people for whom this optimization is valuable would turn
> it on, and you could inform them in the documentation that they might need to
> also hack the DHCP server or client.
> 

Hi Ted,

Thanks for your email.  I guess I characterised the requirement wrongly.  What I 
should have said is that if the sender uses AF_INET then the receiver must also 
use AF_INET.  However, if the sender uses AF_PACKET and builds the header in 
userspace then the receiver can use either socket type.

The patch I sent modifies both dhcpd and dhclient so that they always send with 
AF_PACKET.  This is a slight performance hit to these processes, but not much.

I don't know whether the Linux community have measured the benefit of adding 
support for reception of frames with only the pseudo headers checksummed. 
However, I imagine that for some TCP connections it could be quite a bit.  For 
example, if I rsync'd a 10GB home directory from one virtual machine to another 
on the same host, then this flag would save the sender 5 billion 16 bit 
additions and the same for the receiver.

Regards,

Alex




More information about the dhcp-hackers mailing list