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

[Simon Hobson]

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 ?
Unless you are going to not use them at all you have to :
a) have routing in place to route the traffic
b) have management procedures/policies in place to manage devices in that range
Once you deal with those, then it doesn't generally matter whether 
you have 1 client, or 99% of your clients, in the second subnet.

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.

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 !

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.