dhcpd problem on virtual machines

[Ted Lemon]

On Apr 21, 2010, at 2:27 AM, Alex Zeffertt wrote:
> I'm not sure I understand why the DHCP server would not be on the same LAN as 
> the client during lease renewal when it has to be on the same LAN for the 
> discover.

There is in fact always a DHCP server or relay agent connected to any network served by DHCP.   If the DHCP server is not on the local wire, the DHCP relay agent acts as an intermediary until the client gets an IP address.   After the client has an IP address, though, the DHCP relay agent is no longer needed, and at that point renewals are processed using unicast communication to the DHCP server, which is routed if the DHCP server is off-network.

> However, whatever the explanation, if you need routing for the 
> renewal packets then, you're right, using AF_PACKET won't work.  I guess that 
> means we need a different solution :-(.

Yes.

> Actually, the TCP and UDP packets may never have to be checksummed by the CPU. 
> There are two cases.  In case 1 the packet is going to another VM on the same 
> host, only the pseudo header is checksummed, and the PARTIAL flag is set on 
> receive indicating there's no need to verify.  In case 2 the packet is going out 
> on the wire.  In this case the CPU only has to complete the checksum if the NIC 
> doesn't support tx checksum offloading.  If it does support tx checksum 
> offloading then the driver indicates to the NIC the start and end of the UDP or 
> TCP packet and the location of the partial checksum, and the NIC completes the 
> checksum.
> 
> I think it would be difficult to convince the Linux developers to remove support 
> for reception of partially checksummed packets.  My gut instinct is that they 
> will not be prepared to sacrifice performance to benefit applications doing 
> TCP/IP in userspace.  However, it might be worth bringing this up to see if 
> there is an overlooked solution that doesn't sacrifice performance, or require 
> applications like dhcp-isc to be virtualisation-aware.

I'm not proposing that they remove support for this performance hack.   I'm proposing that since the behavior of the kernel is inconsistent when the hack is enabled, it should not be enabled by default.   As long as there's a sysctl to enable it, anyone who benefits from this performance hack can easily enable it on system startup, but since it will require a positive action to enable, it will no longer violate the principle of least surprise.

The trick to debating with Linux kernel people is to push gently, and never be offended when they call you an idiot.   If you can pull that off, and be persistent, in the long run chances are the right thing will happen.   (I learned this the hard way, of course... :')