RENEWING v4 client + IOS unnumbered interface relay + ISC DHCP server + failover = trouble

[David W. Hankins]

On Thu, Apr 26, 2007 at 02:37:36PM -0700, David Sacerdote wrote:
> Unfortunately, this has an interesting side effect: when a DHCPv4 client 
> is in the RENEWING state, if the Cisco IOS DHCP relay is configured with 
> more than one helper-address, DHCPREQUST messages are sent to multiple 
> DHCP servers, something which version 3.0.5 of the ISC DHCP server seems 
> to assume does not ever happen:
>
>  From servers/dhcp.c:
> void dhcprequest (packet, ms_nulltp, ip_lease)
> ...
>          * If it's RENEWING, we are the only server to hear it, so
>          * we have to serve it.

That's true, insofar as RFC2131 tells us:

4.3.2 DHCPREQUEST message
...
   o DHCPREQUEST generated during RENEWING state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message will
      be unicast, so no relay agents will be involved in its
      transmission.  Because 'giaddr' is therefore not filled in, the
      DHCP server will trust the value in 'ciaddr', and use it when
      replying to the client.

      A client MAY choose to renew or extend its lease prior to T1.  The
      server may choose not to extend the lease (as a policy decision by
      the network administrator), but should return a DHCPACK message
      regardless.

You set giaddr, yes?  You just made this a REBIND so far as our
server can know.  That's the tricky part here.  You know the client
is RENEWING, but when that comment says "RENEWING" what it means is
"so far as we know from the packet contents."

Once you set giaddr, we can't tell the difference between RENEW and
REBIND anymore, at least not according to rfc2131.  So what you should
be reading is:

	 * we have to serve it.   If it's REBINDING, it's out of
	 * communication with the other server, so there's no point
	 * in waiting to serve it.    However, if the lease we're

Because a DHCPREQUEST with both ciaddr and giaddr set looks like
REBINDING to us.

"there's no point" is a bit too vague maybe.  The failure mode if
we don't reply to REBINDs is to let the client's lease expire and
send them through INIT again.

Not very nice.


Have you looked at the SRSN work at the DHC WG?  It's authored
by a bunch of folks (different department?) at Cisco.  Very
similar topic here.  They wound up defining a relay agent flags
suboption so that the server can distinguish between RENEW and
REBIND (unicast vs broadcast) when the relay has changed or
hidden that information by setting giaddr.


> DHCPREQUEST messages irrespective of whether they're in a RENEWING or a 
> REBINDING state, and the DHCP broadcast flag is similarly unreliable.

The flag doesn't indicate wether the packet was broadcast, it indicates
wether the client is prepared to receive (unconfigured) unicast or
requires broadcasts.

So, it's reliable, it just doesn't do what you want.

-- 
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