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