RENEWING v4 client + IOS unnumbered interface relay + ISC DHCP server + failover = trouble
Ted Lemon
Ted.Lemon at nominum.com
Fri Apr 27 02:45:31 UTC 2007
On Apr 26, 2007, at 2:37 PM, David Sacerdote wrote:
> So does anybody have suggestions about how one would go about
> modifying
> the ISC DHCP server to check whether its failover peer is up, and
> to not
> respond to DHCPREQUEST messages intended for its peer if that peer is
> indeed functional? Is there some major pitfall that I should be
> aware of?
David, I think you're jumping the gun here. It sounds like you've
actually made some changes in your processing of the DHCP protocol
that don't follow the spec - it's completely valid for two DHCP
servers to reply to the same DHCPREQUEST message, for example. And
it's really *not* permissible to trap unicast UDP messages and
"relay" them to DHCP servers. That's completely out of spec.
And you further propose to modify the failover protocol to prevent
servers from responding when the failover peer ought to, which is
going to be a very subtle modification, easy to get wrong. And your
route setup code is designed so that if two different servers ACK the
same DHCPREQUEST, it will fail in some way you haven't explained,
even though in the case of a client that's rebinding, the dual ACK
would be completely normal.
Oh, and some Cisco DHCP clients broadcast when in the RENEWING state,
and you propose that this is another reason to modify the failover
implementation.
So I think you're really asking the wrong question. The right
question is, "how do we fix this mess," not "how do we change the ISC
DHCP server to fix this mess." It probably seems like it would be
easier to fix the DHCP server to do what your non-conforming
implementations need, rather than fixing your non-conforming
implementations, and from an engineering standpoint that's probably
true. But what you're left with after you do this is one additional
non-conforming thing, not fewer non-conforming things.
I'm not the maintainer of the ISC DHCP server anymore, and haven't
been for years, so I'm speaking here with my IETF protocol wonk hat
on here: I'd really encourage you to figure out a way to fix the
things here that are actually not conforming to the protocol, even
though more coding and thinking will be needed to accomplish that goal.
More information about the dhcp-hackers
mailing list