Using hostname to assign devices to a class

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Using hostname to assign devices to a class

Adam Raymond

All,

 

                I have been having a long struggle to get the ISC DHCP daemon to differentiate based on DHCP attributes so as to assign devices to different pools and trigger different scripts. I have 4 different models at the moment (and might expand this in the future) and the classes look like this:

 

class "GE112Pro" {

        match if (option vendor-class-identifier) = "ADVA FSP 150-GE112Pro" ;

}

 

class "GE112ProH" {

        match if (option vendor-class-identifier) = "ADVA FSP 150-GE112Pro (H)";

}

 

class "XP116Pro" {

        match if (option vendor-class-identifier) = "ADVA FSP150CC-XG116PRO";

}

 

class "Overture" {

        match if (substring (host-name,0,4)) = “estax”);

}

 

The subnet assignment looks like this:

 

subnet 10.65.16.0 netmask 255.255.248.0 {

        interface eth0;

        option routers 10.65.23.254;

        option subnet-mask 255.255.248.0;

        option broadcast-address 10.65.23.255;

 

        set location = "VIC";

 

        pool {

                allow members of "GE112Pro";

                include "/etc/dhcp/GE112Pro.conf";

                range 10.65.23.236 10.65.23.240;

        }

 

        pool {

                allow members of "GE112ProH";

                include "/etc/dhcp/GE112ProH.conf";

                range 10.65.23.241 10.65.23.243;

        }

        pool {

                allow members of "XP116Pro";

                include "/etc/dhcp/XP116Pro.conf";

                range 10.65.23.244 10.65.23.245;

        }

        pool {

                allow members of "Overture";

                include "/etc/dhcp/on-commit.conf";

                range 10.65.23.246 10.65.23.249;

        }

}

 

The problem I have is that the Overture device is being ignored by the DHCP daemon when it receives a discover packet. This is what a TCPDUMP of the discover packet looks like:

 

01:46:27.024101 IP (tos 0x0, ttl 26, id 36818, offset 0, flags [none], proto UDP (17), length 362)

    10.65.23.253.bootps > man01.syd04.nsw.vocus.net.au.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:0a:c6:51:1a:50 (oui Unknown), length 334, xid 0x5a031d96, Flags [none] (0x0000)

          Gateway-IP 10.65.23.253

          Client-Ethernet-Address 00:0a:c6:51:1a:50 (oui Unknown)

          Vendor-rfc1048 Extensions

            Magic Cookie 0x63825363

            DHCP-Message Option 53, length 1: Discover

            PAD Option 0, length 0

            MSZ Option 57, length 2: 1024

            Parameter-Request Option 55, length 19:

              Server-ID, Lease-Time, RN, RB

              Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name

              BR, NTP, BF, Option 224

              Option 225, Option 227, Option 228, Option 229

              Option 230, Option 231, Option 232

            PAD Option 0, length 0, occurs 3

            Hostname Option 12, length 15: "estax-51-1a-50^@"                         <<<<< What I am trying to filter on

            PAD Option 0, length 0, occurs 3

            Client-ID Option 61, length 15: "estax-51-1a-50"

            PAD Option 0, length 0, occurs 3

            T232 Option 232, length 18: 12346,12848,12595,12593,12848,21553,13621,13104,13658

            END Option 255, length 0

            PAD Option 0, length 0

 

Have I missed something obvious? I have tried a number of different combinations of syntax here, most of which are excepted when I do the restart of the daemon. I even have a work around that works: if you remove the “Overture” class definition altogether and just create a generic pool at the end of the pool definitions, the DHCP daemon responds to the requests, assigning a correct IP address and triggering the “on-commit.conf” configuration.

 

Would welcome any suggestions on what I have missed.


Adam Raymond

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: Using hostname to assign devices to a class

glenn.satchell
I think this might be it:

  match if (substring (host-name,0,4)) = “estax”);

The numbers in the substring() function are the offset and length. So
you're comparing a 4 byte string with a 5 byte string - it'll never match!

regards,
-glenn

On Tue, May 8, 2018 11:20 am, Adam Raymond wrote:

> All,
>
>
>
>                 I have been having a long struggle to get the ISC DHCP
> daemon to differentiate based on DHCP attributes so as to assign devices
> to
> different pools and trigger different scripts. I have 4 different models
> at
> the moment (and might expand this in the future) and the classes look like
> this:
>
>
>
> class "GE112Pro" {
>
>         match if (option vendor-class-identifier) = "ADVA FSP
> 150-GE112Pro"
> ;
>
> }
>
>
>
> class "GE112ProH" {
>
>         match if (option vendor-class-identifier) = "ADVA FSP 150-GE112Pro
> (H)";
>
> }
>
>
>
> class "XP116Pro" {
>
>         match if (option vendor-class-identifier) = "ADVA
> FSP150CC-XG116PRO";
>
> }
>
>
>
> class "Overture" {
>
>         match if (substring (host-name,0,4)) = “estax”);
>
> }
>
>
>
> The subnet assignment looks like this:
>
>
>
> subnet 10.65.16.0 netmask 255.255.248.0 {
>
>         interface eth0;
>
>         option routers 10.65.23.254;
>
>         option subnet-mask 255.255.248.0;
>
>         option broadcast-address 10.65.23.255;
>
>
>
>         set location = "VIC";
>
>
>
>         pool {
>
>                 allow members of "GE112Pro";
>
>                 include "/etc/dhcp/GE112Pro.conf";
>
>                 range 10.65.23.236 10.65.23.240;
>
>         }
>
>
>
>         pool {
>
>                 allow members of "GE112ProH";
>
>                 include "/etc/dhcp/GE112ProH.conf";
>
>                 range 10.65.23.241 10.65.23.243;
>
>         }
>
>         pool {
>
>                 allow members of "XP116Pro";
>
>                 include "/etc/dhcp/XP116Pro.conf";
>
>                 range 10.65.23.244 10.65.23.245;
>
>         }
>
>         pool {
>
>                 allow members of "Overture";
>
>                 include "/etc/dhcp/on-commit.conf";
>
>                 range 10.65.23.246 10.65.23.249;
>
>         }
>
> }
>
>
>
> The problem I have is that the Overture device is being ignored by the
> DHCP
> daemon when it receives a discover packet. This is what a TCPDUMP of the
> discover packet looks like:
>
>
>
> 01:46:27.024101 IP (tos 0x0, ttl 26, id 36818, offset 0, flags [none],
> proto UDP (17), length 362)
>
>     10.65.23.253.bootps > man01.syd04.nsw.vocus.net.au.bootps: [udp sum
> ok]
> BOOTP/DHCP, Request from 00:0a:c6:51:1a:50 (oui Unknown), length 334, xid
> 0x5a031d96, Flags [none] (0x0000)
>
>           Gateway-IP 10.65.23.253
>
>           Client-Ethernet-Address 00:0a:c6:51:1a:50 (oui Unknown)
>
>           Vendor-rfc1048 Extensions
>
>             Magic Cookie 0x63825363
>
>             DHCP-Message Option 53, length 1: Discover
>
>             PAD Option 0, length 0
>
>             MSZ Option 57, length 2: 1024
>
>             Parameter-Request Option 55, length 19:
>
>               Server-ID, Lease-Time, RN, RB
>
>               Subnet-Mask, Default-Gateway, Domain-Name-Server,
> Domain-Name
>
>               BR, NTP, BF, Option 224
>
>               Option 225, Option 227, Option 228, Option 229
>
>               Option 230, Option 231, Option 232
>
>             PAD Option 0, length 0, occurs 3
>
>             Hostname Option 12, length 15: "estax-51-1a-50^@"
> <<<<< What I am trying to filter on
>
>             PAD Option 0, length 0, occurs 3
>
>             Client-ID Option 61, length 15: "estax-51-1a-50"
>
>             PAD Option 0, length 0, occurs 3
>
>             T232 Option 232, length 18:
> 12346,12848,12595,12593,12848,21553,13621,13104,13658
>
>             END Option 255, length 0
>
>             PAD Option 0, length 0
>
>
>
> Have I missed something obvious? I have tried a number of different
> combinations of syntax here, most of which are excepted when I do the
> restart of the daemon. I even have a work around that works: if you remove
> the “Overture” class definition altogether and just create a generic
> pool
> at the end of the pool definitions, the DHCP daemon responds to the
> requests, assigning a correct IP address and triggering the
> “on-commit.conf” configuration.
>
>
>
> Would welcome any suggestions on what I have missed.
>
> Adam Raymond
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Using hostname to assign devices to a class

Adam Raymond
Glenn,

  Thanks - it is usually the obvious things - I thought that those were position values, not string lengths. I will give that try.

Adam

On Tue, May 8, 2018 at 5:24 PM, Glenn Satchell <[hidden email]> wrote:
I think this might be it:

  match if (substring (host-name,0,4)) = “estax”);

The numbers in the substring() function are the offset and length. So
you're comparing a 4 byte string with a 5 byte string - it'll never match!

regards,
-glenn

On Tue, May 8, 2018 11:20 am, Adam Raymond wrote:
> All,
>
>
>
>                 I have been having a long struggle to get the ISC DHCP
> daemon to differentiate based on DHCP attributes so as to assign devices
> to
> different pools and trigger different scripts. I have 4 different models
> at
> the moment (and might expand this in the future) and the classes look like
> this:
>
>
>
> class "GE112Pro" {
>
>         match if (option vendor-class-identifier) = "ADVA FSP
> 150-GE112Pro"
> ;
>
> }
>
>
>
> class "GE112ProH" {
>
>         match if (option vendor-class-identifier) = "ADVA FSP 150-GE112Pro
> (H)";
>
> }
>
>
>
> class "XP116Pro" {
>
>         match if (option vendor-class-identifier) = "ADVA
> FSP150CC-XG116PRO";
>
> }
>
>
>
> class "Overture" {
>
>         match if (substring (host-name,0,4)) = “estax†);
>
> }
>
>
>
> The subnet assignment looks like this:
>
>
>
> subnet 10.65.16.0 netmask 255.255.248.0 {
>
>         interface eth0;
>
>         option routers 10.65.23.254;
>
>         option subnet-mask 255.255.248.0;
>
>         option broadcast-address 10.65.23.255;
>
>
>
>         set location = "VIC";
>
>
>
>         pool {
>
>                 allow members of "GE112Pro";
>
>                 include "/etc/dhcp/GE112Pro.conf";
>
>                 range 10.65.23.236 10.65.23.240;
>
>         }
>
>
>
>         pool {
>
>                 allow members of "GE112ProH";
>
>                 include "/etc/dhcp/GE112ProH.conf";
>
>                 range 10.65.23.241 10.65.23.243;
>
>         }
>
>         pool {
>
>                 allow members of "XP116Pro";
>
>                 include "/etc/dhcp/XP116Pro.conf";
>
>                 range 10.65.23.244 10.65.23.245;
>
>         }
>
>         pool {
>
>                 allow members of "Overture";
>
>                 include "/etc/dhcp/on-commit.conf";
>
>                 range 10.65.23.246 10.65.23.249;
>
>         }
>
> }
>
>
>
> The problem I have is that the Overture device is being ignored by the
> DHCP
> daemon when it receives a discover packet. This is what a TCPDUMP of the
> discover packet looks like:
>
>
>
> 01:46:27.024101 IP (tos 0x0, ttl 26, id 36818, offset 0, flags [none],
> proto UDP (17), length 362)
>
>     10.65.23.253.bootps > man01.syd04.nsw.vocus.net.au.bootps: [udp sum
> ok]
> BOOTP/DHCP, Request from 00:0a:c6:51:1a:50 (oui Unknown), length 334, xid
> 0x5a031d96, Flags [none] (0x0000)
>
>           Gateway-IP 10.65.23.253
>
>           Client-Ethernet-Address 00:0a:c6:51:1a:50 (oui Unknown)
>
>           Vendor-rfc1048 Extensions
>
>             Magic Cookie 0x63825363
>
>             DHCP-Message Option 53, length 1: Discover
>
>             PAD Option 0, length 0
>
>             MSZ Option 57, length 2: 1024
>
>             Parameter-Request Option 55, length 19:
>
>               Server-ID, Lease-Time, RN, RB
>
>               Subnet-Mask, Default-Gateway, Domain-Name-Server,
> Domain-Name
>
>               BR, NTP, BF, Option 224
>
>               Option 225, Option 227, Option 228, Option 229
>
>               Option 230, Option 231, Option 232
>
>             PAD Option 0, length 0, occurs 3
>
>             Hostname Option 12, length 15: "estax-51-1a-50^@"
> <<<<< What I am trying to filter on
>
>             PAD Option 0, length 0, occurs 3
>
>             Client-ID Option 61, length 15: "estax-51-1a-50"
>
>             PAD Option 0, length 0, occurs 3
>
>             T232 Option 232, length 18:
> 12346,12848,12595,12593,12848,21553,13621,13104,13658
>
>             END Option 255, length 0
>
>             PAD Option 0, length 0
>
>
>
> Have I missed something obvious? I have tried a number of different
> combinations of syntax here, most of which are excepted when I do the
> restart of the daemon. I even have a work around that works: if you remove
> the “Overture† class definition altogether and just create a generic
> pool
> at the end of the pool definitions, the DHCP daemon responds to the
> requests, assigning a correct IP address and triggering the
> “on-commit.conf† configuration.
>
>
>
> Would welcome any suggestions on what I have missed.
>
> Adam Raymond
> _______________________________________________
> 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


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