DHCP forwarding and multiple subnets on a single interface.

[Simon Hobson]

Frances Albemuth wrote:

>  First post to the list, so apologies in advance if my etiquette
>isn't appropriate.  I'm using the ISC DHCP server in a rather vanilla
>configuration right now and I'm moving towards the addition of new
>interfaces over which DHCP will be served via forwarding.  I would
>like to be able to map multiple address blocks to a single interface
>and have the DHCP server make offers based on utilization of pools,
>but I see no way to do this.  It seems to me that the server sees the
>source address of the interface from which the request was forwarded
>in therefore makes an offer from that pool (subnet a.b.c.d).

>It's not
>obvious looking at the man file (and frankly seems counter-intuitive)
>that you can specify a range or pool inside of a subnet declaration
>that lives outside of said subnet.  Has anybody got a way of
>accomplishing this?

I believe what you are describing is a Shared Network - more than one 
IP subnet on the same physical network.

The syntax is basically :

shared-network "officenet" {
   subnet ...
   }
   subnet ...
   }
}

You can have multiple shared network declarations if you have 
multiple shared networks.

This tells DHCP server that when it receives a request tagged with an 
IP in ANY of the subnets in the shared network, then it can give out 
ANY IP in any of the subnets that it is configured to give out. What 
it won't do is any form of 'load balancing' or client affinity 
without some help.

What you will find is that if you just start up a fresh config with 
(say) two large pools, the server will allocate from one pool until 
all it's addresses have been used once, and only them start 
allocating from the second pool. You have two main ways of changing 
this behaviour :

1) use classes (or host statements & fixed addresses) to associate 
classes to a particular pool. For example, if you had IP phones then 
you might assign all IP phones to one pool (using perhaps the first 
three byte of the mac address to identify them) and everything else 
to another pool.

2) Artificially restrict one pool to force allocation from the other. 
By restricting the size of the pool used first, the server will be 
forced to allocated from the other pool - once a client has an 
allocation, then in general it will continue to use that in future. 
By expanding the pools as the number of clients increases you can get 
to a situation where the distribution appears to have some randomness.

There is a third way that comes to mind, create dummy expired leases 
for all addresses (either by adding them to the leases file or using 
omshell). If you do this alternatively from each pool (ie when sorted 
chronologically they go A B A B A B A B ... where A and B are the two 
pools) then the server will reuse addresses and it's least recently 
used algorithm will make it use address alternately from each pool.

Of course, once all addresses have been used at least once by real 
clients, then future assignments will appear to be random because of 
the least recently used criteria for selecting an address to 
reallocate.

Simon