How to configure the DHCP to make a priority between the subnets inside same shared network
Tim Gavin
livewire98801 at gmail.com
Tue Feb 1 19:54:38 UTC 2011
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.
More information about the dhcp-users
mailing list