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