Problems using class match by user-option

[Sven Schumacher]

Hello,

I have the following problem: two many clients within a limited range of
IP-addresses.
I would like to sort the clients which get dynamically their IP in two
pools. One of them is for PXE-Clients or Clients with "official"
ip-adresses, the other one for "nat"-able Clients. But only
"known-clients" shall be assigned an address (later on there might be
the option to assign unknown-clients a third range within a third pool
with no internet-access and in an isolated ip-range, which gets blocked
by firewall on all other devices). So I tried the following in dhcpd.conf:


option tfd-scope-identifier code 230 = text;

class "gaeste" {
  match if (config-option tfd-scope-identifier = "gaeste");
}

shared-network tfd {

    subnet 10.69.0.0 netmask 255.255.0.0 {
      deny unknown-clients;
      ...
    }
    subnet 130.75.69.0 netmask 255.255.255.0 {
      deny unknown-clients;
      ...
    }

     host test1 {
         hardware ethernet aa:bb:cc:dd:ee:ff;
         option tfd-scope-identifier "gaeste";
     }
     host test2 {
         hardware ethernet bb:cc:dd:ee:ff:aa;
     }
      pool { # host test2 should get IP of this pool
          range 130.75.69.50 130.75.69.60;
          deny members of "gaeste";
          ....
      }
      pool { # host test1 should get IP of this pool, but didn't
          range 10.69.253.1 10.69.253.254;
          option routers 10.69.0.251;
          allow members of "gaeste";
      }
}



But when I did this, test2 still got an IP of the address range
130.75.69.50 to 130.75.69.60. So the class-match for the config-option
seems to be wrong.
Looking at my syslog only DHCPDISOVER, DHCPREQEST and DHCPACK Messages
are logged.
Is there any way to "debug" the class-match like more verbose output?

Thanks in advance

Sven
     

--
Sven Schumacher - Systemadministrator Tel: [phone]
Leibniz Universitaet Hannover
Institut für Turbomaschinen und Fluid-Dynamik       - TFD
Appelstraße 9 - 30167 Hannover
Institut für Kraftwerkstechnik und Wärmeübertragung - IKW
Callinstraße 36 - 30167 Hannover



_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bill Shirley-2]

Class/subclass would better fit your needs:
#      -------------
class "gaeste" {   
  match hardware;
  option routers 10.69.0.251;    # can set the routers here or in "gaste" pool
}
# MAC address is preceded by '1:' indicating ethernet
subclass "gaeste"    1:aa:bb:cc:dd:ee:ff;    # test1
#      -------------

#      -------------
class "subnet2" {
  match hardware;
}
subclass "subnet2"    1:bb:cc:dd:ee:ff:aa;    # test2
subclass "subnet2"    1:cc:dd:ee:ff:aa:bb    { # test3 - can have additional settings
    ddns-hostname = "test3-PC";
    ddns-domainname "different.domain.com";
}
#      -------------

shared-network tfd {
    subnet 10.69.0.0 netmask 255.255.0.0 {
      ...
      pool { # host test1 should get IP of this pool
          allow members of "gaeste";
#          option routers 10.69.0.251;
          range 10.69.253.1 10.69.253.254;
      }
    }

    subnet 130.75.69.0 netmask 255.255.255.0 {
      ...
       pool { # host test2 should get IP of this pool
          allow members of "subnet2";
          range 130.75.69.50 130.75.69.60;
          ....
      }
       pool { # NO INTERNET
          deny members of "gaeste";
          deny members of "subnet2";
          range 130.75.69.61 130.75.69.70;
          ....
      }
   }
}
#host test1 {
# hardware ethernet aa:bb:cc:dd:ee:ff;
# option tfd-scope-identifier "gaeste";
#}
#host test2 {
# hardware ethernet bb:cc:dd:ee:ff:aa;
#}

Host declarations are global and should not be inside any
other structure except 'group'.  Pools should be inside subnet
declarations.

There are other ways to do class matches:
class "10.mobile_device" {
    match if (
        option host-name ~~ "dhcpcd"
        or option host-name ~~ "android"
        or option vendor-class-identifier ~~ "android"
        or option host-name ~~ "samsung-sm"
        or option host-name ~~ "iphone"
        or option host-name ~~ "ipod"
        or option host-name ~~ "ipad"
        or option host-name ~~ "watch"
    );

    if (lcase(option host-name) = "iphone") { ddns-hostname = concat("iPhone-", binary-to-ascii(16, 8, "", substring(hardware, 4, 3))); }
    if (lcase(option host-name) = "iphone-2") { ddns-hostname = concat("iPhone2-", binary-to-ascii(16, 8, "", substring(hardware, 4, 3))); }
    if (lcase(option host-name) = "ipod") { ddns-hostname = concat("iPod-", binary-to-ascii(16, 8, "", substring(hardware, 4, 3))); }
    if (lcase(option host-name) = "ipad") { ddns-hostname = concat("iPad-", binary-to-ascii(16, 8, "", substring(hardware, 4, 3))); }
    if (substring(lcase(option host-name), 0, 10) = "samsung-sm") {
        ddns-hostname = concat("samsung-", binary-to-ascii(16, 8, "", substring(hardware, 4, 3)));
    }
}
The 'if' statements above creates a unique name for those people
that leave their iPhone name with the out-of-the-box default name.
~~ is a regex comparison.

Kyocera printer:
class "Kyocera" {
#    match if substring(hardware, 1,3) = 00:c0:ee;
    match if (
        substring(hardware, 1,3) = 00:c0:ee
        or substring(hardware, 1,3) = 00:17:c8
    );
}

Bill

On 12/7/2017 3:49 AM, Sven Schumacher wrote:

class "gaeste" {
  match if (config-option tfd-scope-identifier = "gaeste");
}

shared-network tfd {

    subnet 10.69.0.0 netmask 255.255.0.0 {
      deny unknown-clients;
      ...
    }
    subnet 130.75.69.0 netmask 255.255.255.0 {
      deny unknown-clients;
      ...
    }

     host test1 {
         hardware ethernet aa:bb:cc:dd:ee:ff;
         option tfd-scope-identifier "gaeste";
     }
     host test2 {
         hardware ethernet bb:cc:dd:ee:ff:aa;
     }
      pool { # host test2 should get IP of this pool
          range 130.75.69.50 130.75.69.60;
          deny members of "gaeste";
          ....
      }
      pool { # host test1 should get IP of this pool, but didn't
          range 10.69.253.1 10.69.253.254;
          option routers 10.69.0.251;
          allow members of "gaeste";
      }
}

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Sven Schumacher]

Am 07.12.2017 um 13:48 schrieb Bill Shirley:

Class/subclass would better fit your needs:

Yes of course... but I didn't want to specify the mac-address twice.
More comfortable would be to add a option to  the already existing groups of hosts:

group { # guests
    option tfd-scope-identifier "gaeste";
    host test1 {
       hardware ethernet aa:bb:cc:dd:ee:ff;
    }
    host test2 {
       hardware ethernet bb:cc:dd:ee:ff:aa;
    }
}

#      -------------
class "gaeste" {   
  match hardware;
  option routers 10.69.0.251;    # can set the routers here or in "gaste" pool
}
# MAC address is preceded by '1:' indicating ethernet
subclass "gaeste"    1:aa:bb:cc:dd:ee:ff;    # test1
#      -------------

#      -------------
class "subnet2" {
  match hardware;
}
subclass "subnet2"    1:bb:cc:dd:ee:ff:aa;    # test2
subclass "subnet2"    1:cc:dd:ee:ff:aa:bb    { # test3 - can have additional settings

this way I would have to add the MAC-address twice (one time for the subclass and one time for the host)

#host test1 {
# hardware ethernet aa:bb:cc:dd:ee:ff;
# option tfd-scope-identifier "gaeste";
#}
#host test2 {
# hardware ethernet bb:cc:dd:ee:ff:aa;
#}

Host declarations are global and should not be inside any
other structure except 'group'.  Pools should be inside subnet
declarations.

The pool-declarations are in a shared-network, but even changing this, so that the pool-declaration are in the corresponding subnet-declarations, doesn't help.

There are other ways to do class matches:
class "10.mobile_device" {
    match if (
        option host-name ~~ "dhcpcd"
        or option host-name ~~ "android"
        or option vendor-class-identifier ~~ "android"
        or option host-name ~~ "samsung-sm"
        or option host-name ~~ "iphone"
        or option host-name ~~ "ipod"
        or option host-name ~~ "ipad"
        or option host-name ~~ "watch"
    );

It seems to me, that class matches doesn't work with config-options, only with options :(
I tried once to use "option host-name " instead of my "config-option tfd-scope-identifier" and then the class was assigned.

Thanks so far

Sven

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bill Shirley-2]

You don't need to define the hosts unless there is more to your config
than you've shared.  Code it once as a subclass declaration.

Did you not notice that I commented our the host statements?

Bill

On 12/7/2017 7:58 AM, Sven Schumacher wrote:

Am 07.12.2017 um 13:48 schrieb Bill Shirley:

Class/subclass would better fit your needs:

Yes of course... but I didn't want to specify the mac-address twice.
More comfortable would be to add a option to  the already existing groups of hosts:

group { # guests
    option tfd-scope-identifier "gaeste";
    host test1 {
       hardware ethernet aa:bb:cc:dd:ee:ff;
    }
    host test2 {
       hardware ethernet bb:cc:dd:ee:ff:aa;
    }
}

#      -------------
class "gaeste" {   
  match hardware;
  option routers 10.69.0.251;    # can set the routers here or in "gaste" pool
}
# MAC address is preceded by '1:' indicating ethernet
subclass "gaeste"    1:aa:bb:cc:dd:ee:ff;    # test1
#      -------------

#      -------------
class "subnet2" {
  match hardware;
}
subclass "subnet2"    1:bb:cc:dd:ee:ff:aa;    # test2
subclass "subnet2"    1:cc:dd:ee:ff:aa:bb    { # test3 - can have additional settings

this way I would have to add the MAC-address twice (one time for the subclass and one time for the host)

#host test1 {
# hardware ethernet aa:bb:cc:dd:ee:ff;
# option tfd-scope-identifier "gaeste";
#}
#host test2 {
# hardware ethernet bb:cc:dd:ee:ff:aa;
#}

Host declarations are global and should not be inside any
other structure except 'group'.  Pools should be inside subnet
declarations.

The pool-declarations are in a shared-network, but even changing this, so that the pool-declaration are in the corresponding subnet-declarations, doesn't help.

There are other ways to do class matches:
class "10.mobile_device" {
    match if (
        option host-name ~~ "dhcpcd"
        or option host-name ~~ "android"
        or option vendor-class-identifier ~~ "android"
        or option host-name ~~ "samsung-sm"
        or option host-name ~~ "iphone"
        or option host-name ~~ "ipod"
        or option host-name ~~ "ipad"
        or option host-name ~~ "watch"
    );

It seems to me, that class matches doesn't work with config-options, only with options :(
I tried once to use "option host-name " instead of my "config-option tfd-scope-identifier" and then the class was assigned.

Thanks so far

Sven

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Sten Carlsen]

I have been using this setup for a long time, even using 5 different classes with different routers , one with no internet access and one for unknown hosts for isolation.

The only place to use the hardware address is in the subclass statement where you can add e.g. dns-name if needed. I put this into an include file.

I have a few host statements for things that need a fixed address, referring to the DNS lookup of the name.

It was the easiest solution I could find. Recommended.

On 07/12/2017 13:58, Sven Schumacher wrote:

Am 07.12.2017 um 13:48 schrieb Bill Shirley:

Class/subclass would better fit your needs:

Yes of course... but I didn't want to specify the mac-address twice.
More comfortable would be to add a option to  the already existing groups of hosts:

group { # guests
    option tfd-scope-identifier "gaeste";
    host test1 {
       hardware ethernet aa:bb:cc:dd:ee:ff;
    }
    host test2 {
       hardware ethernet bb:cc:dd:ee:ff:aa;
    }
}

#      -------------
class "gaeste" {   
  match hardware;
  option routers 10.69.0.251;    # can set the routers here or in "gaste" pool
}
# MAC address is preceded by '1:' indicating ethernet
subclass "gaeste"    1:aa:bb:cc:dd:ee:ff;    # test1
#      -------------

#      -------------
class "subnet2" {
  match hardware;
}
subclass "subnet2"    1:bb:cc:dd:ee:ff:aa;    # test2
subclass "subnet2"    1:cc:dd:ee:ff:aa:bb    { # test3 - can have additional settings

this way I would have to add the MAC-address twice (one time for the subclass and one time for the host)

#host test1 {
# hardware ethernet aa:bb:cc:dd:ee:ff;
# option tfd-scope-identifier "gaeste";
#}
#host test2 {
# hardware ethernet bb:cc:dd:ee:ff:aa;
#}

Host declarations are global and should not be inside any
other structure except 'group'.  Pools should be inside subnet
declarations.

The pool-declarations are in a shared-network, but even changing this, so that the pool-declaration are in the corresponding subnet-declarations, doesn't help.

There are other ways to do class matches:
class "10.mobile_device" {
    match if (
        option host-name ~~ "dhcpcd"
        or option host-name ~~ "android"
        or option vendor-class-identifier ~~ "android"
        or option host-name ~~ "samsung-sm"
        or option host-name ~~ "iphone"
        or option host-name ~~ "ipod"
        or option host-name ~~ "ipad"
        or option host-name ~~ "watch"
    );

It seems to me, that class matches doesn't work with config-options, only with options :(
I tried once to use "option host-name " instead of my "config-option tfd-scope-identifier" and then the class was assigned.

Thanks so far

Sven

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Sven Schumacher <[hidden email]> wrote:

> I have the following problem: two many clients within a limited range of
> IP-addresses.
> I would like to sort the clients which get dynamically their IP in two
> pools. One of them is for PXE-Clients or Clients with "official"
> ip-adresses, the other one for "nat"-able Clients. But only
> "known-clients" shall be assigned an address (later on there might be
> the option to assign unknown-clients a third range within a third pool
> with no internet-access and in an isolated ip-range, which gets blocked
> by firewall on all other devices). So I tried the following in dhcpd.conf:
>
>
> option tfd-scope-identifier code 230 = text;
>
> class "gaeste" {
>  match if (config-option tfd-scope-identifier = "gaeste");
> }
>
> shared-network tfd {
>
>    subnet 10.69.0.0 netmask 255.255.0.0 {
>      deny unknown-clients;
>      ...
>    }
>    subnet 130.75.69.0 netmask 255.255.255.0 {
>      deny unknown-clients;
>      ...
>    }
>
>     host test1 {
>         hardware ethernet aa:bb:cc:dd:ee:ff;
>         option tfd-scope-identifier "gaeste";
>     }
>     host test2 {
>         hardware ethernet bb:cc:dd:ee:ff:aa;
>     }
>      pool { # host test2 should get IP of this pool
>          range 130.75.69.50 130.75.69.60;
>          deny members of "gaeste";
>          ....
>      }
>      pool { # host test1 should get IP of this pool, but didn't
>          range 10.69.253.1 10.69.253.254;
>          option routers 10.69.0.251;
>          allow members of "gaeste";
>      }
> }
>
>
>
> But when I did this, test2 still got an IP of the address range
> 130.75.69.50 to 130.75.69.60. So the class-match for the config-option
> seems to be wrong.

There are several things wrong with your config. The first thing is that you need to move your host statements to the global scope - defining them in the shared-network scope doesn't work as you might expect (you can get some very strange inheritance issues).
Similarly, the pools should be defined inside the subnets to which they belong.

Next, don't mix allow and deny statements in a pool - remember that a pool inherits settings/options from a parent subnet/enclosing shared network/global scope. Ted's described how allow and deny work together, but TBH I could never remember it - and it's by far the safest option to simply don't mix them !

I would suggest something along the lines of :

class "pxeclients" {
  match on ?
}
# Check the archives, I'm sure there'll be an example of how to match PXE clients.

class "authhosts"
  match on hardware
}

subclass authhosts 1:aa:bb:cc:dd:ee:ff
subclass authhosts 1:bb:cc:dd:ee:ff:aa
# Check man dhcpd.conf and see the section on classes and subclasses as I've probably got the syntax wrong.


shared-network ...
  subnet a.b.c.d ...
    pool ....
      allow members of "authhosts"
    }
  }

  subnet w.x.y.z ...
    pool ...
      allow members of "pxeclients"
    }
  }

  subnet m.n.o.p ...
    pool ...
      deny members of "authhosts"
      deny members of "pxeclients"
    }
  }
# Optional subnet/pool for "everything else"

}


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users