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

Simon Hobson dhcp1 at thehobsons.co.uk
Tue Feb 1 20:38:31 UTC 2011


José Queiroz wrote:

>Each broadcast domain should correspond to a 
>subnet range. If you have several subnets on the 
>same broadcast domain, the DHCP server cannot 
>tell apart which request came from which subnet.
>
>The "right way" to solve your problem is break 
>your network in several broadcast domains (e.g. 
>VLANs), and assign a subnet range to each 
>broadcast domain.

Not necessarily. A shared network is a perfectly 
valid arrangement provided you correctly identify 
it to your DHCP server. The server can quite 
correctly identify the network a client is 
connected to, the only difficulty is forcing 
clients into a specific subnet within that 
network.

Tim Gavin wrote:

>>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 think I start to se the problem - performance 
sucks for those devices on the second subnet. 
There is always the option of not having a large 
pool of addresses in that subnet, that way not 
many devices will get addresses in it.

>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.

Again, I'm still failing to see a big problem here.
You either need the addresses in use - in which 
case I fail to see the big problem whether it's 
100 or 200, or 500. Or you don't, in which case 
just remove/disable the pool.

It's still a very niche requirement. If you 
submit patches then I guess they may be 
considered (other non-RFC-compliant options have 
been accepted).

But it does leave a problem - how are you going 
to define the option and how it works ? Are you 
going to say a client must never be given an 
address in the backup pool if there is even one 
address free in the main pool ? Only if there are 
ten or less ? Only if there are no leases expired 
by at least a day, week, month ? Something else ? 
How many free addresses in the main pool do you 
need before you start migrating devices back ?
I can guarantee that whatever you pick - it will be wrong for the next guy :-/

Roll on IPv6 and then we can all have loads of addresses :-)

-- 
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.



More information about the dhcp-users mailing list