DHCP RENEW on Multi homed client

David W. Hankins dhankins at isc.org
Wed Dec 2 18:43:57 UTC 2009


On Tue, Nov 24, 2009 at 04:15:01PM -0600, Jolynn Schmidt wrote:
> Eth0 and Eth1 have no problem getting their initial dhcp request, but we are having problems when dhclient for eth1 renews it's lease.   The default gateway points out eth0 so the renew for eth1 is being sent out eth0, I see the request and ack transaction occur between the server and the client on eth0 but dhclient for eth1 never sees it, and just keeps send out a request over and over again.
> 
> Is this just not going to work, do I need to static address my eth1 interface or should this be working?

You've got an RFC incompliant DHCP server, it should direct the reply
to the address configured on eth1 ("ciaddr"), and not to the IP source
address, as it appears to be doing.

If the server is directing the reply to the ciaddr properly, then
you've got a route from the DHCP server to the client via the wrong
interface?  If you can sort out that route so it reaches the client
via the interface in question, it will start working.

Note that if RENEWING eth1 fails, all that really happens is the
client will ultimately reach REBINDING and broadcast its packet on
eth1.  In this case, the server will reply on the same network or
via a relay agent.  It isn't optimal, but it will work.


The problem you're seeing is that the DHCP software (client, relay,
and server) have to both send and receive "funny" packets - from the
all-zeroes IPv4 address, or packets sent to the all-ones IPv4
("limited broadcast") address.

Most straight UDP sockets don't let us do that, and some that might
let us do that won't let us send the packet on a specific interface...

So the current setup is that we open a straight UDP socket, and we
send unicasts on it, so it sends packets by way of normal routing when
we're unicasting regular packets, but for broadcasts or preconfigured
broadcasts we use a raw socket to send.

Because we have to receive "funny packets" on the raw socket, we are
going to get some duplicates on the UDP socket...the solution being to
receive all the packets we actually process on the raw socket, and to
drop all the packets we receive on the straight UDP socket (we
basically just empty it).  This way we receive all packets exactly
once.

This isn't exactly an optimal state of affairs.  I've long considered
that the DHCP client in particular should lose its raw socket when it
is BOUND, RENEWING, and possibly REBINDING, and use the UDP socket for
all its work while it has a valid address.  The relay really shouldn't
use a raw socket on its "server-facing" interface (which causes us to
be unable to do dhcrelay extensions over PPP lines for example because
we don't support PPP raw framing).  There are many platforms where we
might be able to trick a DHCP server into working without raw sockets
and still maintain RFC 2131 compliance in terms of "funny packets".

I'd love to change it.

But this is kind of a critical piece of the software's operation which
is more or less working very well right now, so it would really take a
major effort to make even minor changes to make sure we don't
introduce any negative impacts.


Your DHCP server should be replying to the ciaddr, not to the IPv4
source address.  This should reach the raw socket on that interface
if it is received on that interface (rather than routed to the other
one).

   If the 'giaddr' field in a DHCP message from a client is non-zero,
   the server sends any return messages to the 'DHCP server' port on the
   BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
   field is zero and the 'ciaddr' field is nonzero, then the server
   unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
   If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
   set, then the server broadcasts DHCPOFFER and DHCPACK messages to
   0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
   'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
   messages to the client's hardware address and 'yiaddr' address.  In
   all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
   messages to 0xffffffff.

[Experted from RFC 2131 Section 4.1, "Constructing and sending DHCP
 messages"]

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20091202/08749f45/attachment.bin>


More information about the dhcp-users mailing list