Sub-pool or pool hierarchy

Prunk Dump prunkdump at gmail.com
Mon Oct 14 18:12:55 UTC 2013


2013/10/14 Simon Hobson <dhcp1 at thehobsons.co.uk>:
> Prunk Dump wrote:
>> 1) My network use two domain controllers PEDA and ORPEO that live in the same subnet 172.16.0.0/16 :
>> -> The ip addresses of the stations managed by the PEDA domain controller are in the range 172.16.0.2 to 172.16.0.254
>> -> The ip addresses of the stations managed by the ORPEO domain controller are in the range 172.16.200.2 to 172.16.200.254
>
>> 2) For each domain I have organized the station's ip address by classroom :
>> -> ex : the C301 classroom, managed by the PEDA domain controler, contain stations in the range 172.16.0..100 to 172.16.0.150.
>> -> the C302 classroom is in the range 172.16.0.150 to 172.16.0.200
>> ....
>
>> I use the hostname to identify the "isc dhcp class" of the clients. This is because the stations in the C301 classroom
>> are named C301-01, C301-02... But how can I create the corresponding pools inside the PEDA and ORPEO pools ?
>
>
>> In general it is possible to make a hierarchy in the pools ? (with a hierarchy in the parameters) I would avoid giving each time all the PEDA or ORPEO parameters to each pool !
>
> You'll need to create a means of classifying the clients, otherwise any client can get an address in any pool from any server. So you'll probably need to use a construct like :
> class c301 {
>  match if substring(hostname,1,4) = "C301" ;
> }
> ..
> pool ... {
>  allow members of "c301" ;
>  ...
> }
>
> As you'll almost certainly have clients on the network without the right form of hostname, it's probably best to give them a class too :
> pool {
>  # For badly named clients
>  deny members of "c301" ;
>  deny members of "c302" ;
>  ...
> }
> depending on your setup, you might redirect any web connections to a captive portal, or just give them a dummy router, or something else.
> But the key thing is that they'll get an address and be logged - so you can detect that they're there and deal with them - rather than just see a lot of "no free leases" messages. You have to deny members of ... for all the classes defined - there is no option to allow clients that don't match any class. You will have to include all the classes handled by the other server - otherwise clients could get an address in this pool when they should in fact get one from the other server.
>
> As to not repeating all the config statements for each pool, you could try a group and see if it works. I think it should :
> pool {
>  option ...
>  option ...
>  pool ...
>  pool ...
>  pool ...
> }
> this shoudl allow you to define a number of options that will be applied to each pool in the group - that is the function of the group statement.
>
>
> PS - using the hostname isn't really a reliable mechanism. Anyone should be able to figure out what's going on and just set their own device accordingly - thus getting themselves on the network.
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users


Thank you very much !

Unfortunately a group of pools or a pool containing multiple pools is
not accepted by the isc dhcp server. And a "subnet" cannot be defined
as an IP range.

Reorganizing my PEDA and ORPEO domain ip range to become two real
subnets is it the only way to separate my classes in two groups ?

Thanks again !


More information about the dhcp-users mailing list