DHCP Failover and DHCP relay question

Darren perl-list at network1.net
Tue Mar 28 01:02:58 UTC 2006


David (Not David's Dad :) ),
Thank you, this is very informative.  It gets worse, we have no control 
over  the window's DHCP server, it is managed by a third party.  I 
think, the cable modem DHCP will have a source of some 10.0.0.x network, 
and the client DHCP will have some other public source, so them 
answering the wrong requests shouldn't be a problem.

None of these options sound less than 'hokey' :)  Especially considering 
this network will not be the only network on the devices.  We will need 
to check into some other options such as not using a failover and so on...

Something to ponder:  I wonder what might happen if the USR is set to 
relay DHCP requests to some Cisco router that can act as a DHCP Relay 
agent that has both servers configured?  Something that we may be able 
to test...  Anyone have any thoughts on what might happen?

David W. Hankins wrote:

>On Mon, Mar 27, 2006 at 04:24:29PM -0500, Darren wrote:
>  
>
>>Mr. Hankins (or anyone who knows the answer to this question),
>>    
>>
>
>I don't think my dad subscribes to dhcp-users.  I guess I'll answer in
>his proxy.
>
>  
>
>>v.3.0.3 of ISC DHCP
>>
>>Lets say we have DHCP failover partners at 192.168.0.1 and 192.168.0.2 
>>and a cable modem bootp server running on windows at 192.168.0.3 for 
>>example.  The client DHCP of a cable modem network will be going to the 
>>DHCP failover partners.  The cable modem bootp traffic will be going to 
>>the windows bootp server.  It is not possible in this example to place 
>>the bootp on the failover partners (actually, I don't think the ISC DHCP 
>>server supports bootp on failover anyways).
>>    
>>
>
>That's correct, in order to enable failover you must configure 'no dynamic
>bootp' on the failover address pools.  In all presently released versions
>anyway.
>
>But, if the bootp client does match a host statement, or if there is
>another (non-failover) dynamic pool and dynamic-bootp is enabled, it
>might get answered (and you can configure the same host statements on
>both failover servers if you do want to move bootp into your dhcpd
>pair, or simply just configure one pool on one server for bootp).
>
>'ignore bootp;' I think might help avoid irregular responses.
>
>  
>
>>We have an old USR cable access router that will be acting as the DHCP 
>>relay agent for both cable modems and the clients behind them.  While 
>>this router does support failover, it does not support separation of the 
>>client/cable modem traffic.  Therefore, to make this work we would set 
>>the primary DHCP server on the cable access router to 192.168.0.3 so 
>>that the cable modem bootp traffic goes to the windows server.  We will 
>>set the secondary DHCP server to 192.168.0.1 so that the client DHCP 
>>goes to the first failover server.
>>
>>Can anyone tell me if this will work?
>>    
>>
>
>No.  But I can tell you: you're screwed.
>
>  
>
>>Specifically, what will happen if 
>>the hash check on the client MAC Address says that the secondary DHCP 
>>server should answer, but the secondary server never received the DHCP 
>>Discover message from the client?  Will the primary client answer?  If 
>>so, what parameters will determine if it answers (IE, what should these 
>>options be set too:
>>
>>        max-response-delay 5;
>>        max-unacked-updates 5;
>>        mclt 600;
>>        split 128;
>>        load balance max seconds 5;
>>
>>This failover cluster will also be used by other DHCP Relay agents that 
>>do indeed support failover properly, and many of which are not cable 
>>modem networks at all.
>>    
>>
>
>OK.  If LBA hashes to the secondary, the primary will not answer unless
>the client is configured in a fixed-address host {} statement, or the
>lease is ACTIVE, or the 'secs' field of the DHCP packet received exceeds
>your configured value of 5 ("load balance max seconds"), or the peer
>state is not normal (vast oversimplification).
>
>None of those are things you really want to rely on.  And when the
>primary goes down, the secondary will never get the packets from the
>relay to even hope to process them.  So it's of no use.
>
>But I don't really see what you can do if you can only configure two
>dhcp servers on the USR device.
>
>
>Some folks on this list have played with 'anycast DHCP'.  It's a
>functional design, but sadly one we don't support.  Basically with this
>kind of topology, you really want whatever server receives the client's
>packet to answer...because only one ever will.  You configure a 'role'
>address which all servers have configured as lo0 aliases, and use
>router protocols to make sure the nearest alive dhcp server gets the
>client's packets (with some flow-cache magic to keep forwarding
>consistent on source:dest ip:port hashes).
>
>Overall it's the same kind of 'technology' used for the F root name
>server, documented in detail by one Joe Abley:
>
>	http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2004-1.txt
>	http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2003-1.txt
>
>You can use failover to make sure there aren't duplicate assignments
>(but then you have to code-out LBA), or you can just use dhcp servers
>that each have a different dynamic range configured (and then use more
>than failover's limit of 2 servers).
>
>That's a fairly not-well-beaten path for DHCP.  For one, it will take
>source changes in ISC DHCP to support failover in it (which is important
>if you can't throw infinite supplies of DHCP addresses at the problem).
>For another, whereas the current failover implementation is fairly
>laissez-faire with returning IP addresses to clients returning to the
>network, without LBA in this anycast method you're basically accepting
>total randomization (wether you use failover or not).  With failover
>and no anycast, at least you have a hope things might get better in a
>future release ("mac address affinity"), but there's just no way to
>go that route with anycast.
>
>
>See if you can get the USR to accept a protocol address that's a local
>broadcast (eg 192.168.0.255) on the dhcp servers' wire.  It's a hack,
>but it might work.
>
>  
>




More information about the dhcp-users mailing list