How to configure the DHCP to make a priority between the subnets inside same shared network

[Tim Gavin]

On 02/01/2011 11:21 AM, Simon Hobson wrote:
> Tim Gavin wrote:
>> What's wrong with that, and why would it break?  I would also have a 
>> lot of use out of a 'priority' block, with a 'backup' block.  In the 
>> past, I had a block that was too small, with a NAT block to increase 
>> the useful size until I could get new allocations from ARIN.  Now 
>> that I'm done with that situation, I would still find a 'backup' 
>> block useful, though not as much as before.
>
> OK, simple question then. If you have a requirement for the number of 
> addresses that makes a second subnet required AND your network will 
> work fine with machines using those addresses, then what purpose does 
> it serve to specifically avoid using them ?

Assuming my original example of a NAT block, the network doesn't work 
'fine', there is a significant performance problem.  My situation is 
past, I have LOTS of addresses now, but someone else might have another 
compelling reason for this.

>
> I can see your point about using an overflow block while you are 
> waiting for your new allocation to arrive. But in that case, I'd be 
> leaving alone until I had the new allocation, then just add it and 
> migrate (a one off forced change) any clients in the temporary block.
>
>> I never posted a thread about it because I found on in the archives 
>> saying why it wasn't implemented, but I think it's a valid feature 
>> request.  As long as addresses are assigned according to RFC in the 
>> 'primary' block, what would it hurt to implement this?  Maybe set a 
>> longer lease time on the 'primary' block, and a short one on the 
>> 'backup' block.  If a device renews the allocated address before 
>> expiry, it's renewed, but if that client reconnects after the lease 
>> with a DISCOVER, it gets allocated an address from the 'primary' 
>> block if there is one available.  If there isn't a primary address 
>> available, it gets reallocated the same backup address it had 
>> previously.
>
> Well apart from being expressly against the RFC ?
>
> You have a device that gets an address in the 'backup' block. It's 
> lease expires and when it comes back to the network it gets a 
> different address when it's previous one is still free. Against RFC. 
> You've made it change address for no reason.
>
> A device appears on the network, you have 'never used' addresses in 
> your backup block, yet you reallocate an address previously used by a 
> different client in preference - client comes back, gets different 
> address because it's previous one has been reallocated. Against RFC. 
> You've made it change address for no reason.

Not no reason. . . if there was no reason, there would be no 'backup' 
block.  And as long as the 'client churn' is ONLY for new DHCPDISCOVERs, 
not for renewals, the client won't notice.

>
> In any case, you are promoting client churn - which I personally (you 
> may disagree) consider to be less favourable than being able to keep 
> an address block as backup. Not that I'm that bothered, I've always 
> tried to setup my networks with proper DNS etc - which is why I'd not 
> be bothered which subnet the client was in.
> Now if one block is publicly routeable, and the other is NATted then I 
> might think differently - I don't think anyone who's heard me express 
> an opinion would accuse me of thinking NAT is the best thing since 
> sliced bread !

I agree, NAT is a bad option, except when it's your only option.  I had 
to deal with it for six months on an ISP network until I got all the 
ARIN data fixed.


I don't want to start a flame war here, all I'm saying is that there 
might be a reason that this would be handy.  Maybe put in a warning 
about breaking RFCs, but allow the option for those that need it.  It 
sure would have saved me a lot of frustration for a while.