DHCP option Space

[Teja]

Hi ,
How can a DHCP client can get the DHCP option space data from respective
server config
Ex: I have constructed my local server config as below by taking online
example references
default-lease-time 3600;
authoritative;
option space optionSpacedb;
option optionSpacedb.option1d code 1 = ip-address;
subnet 15.0.0.0 netmask 255.255.255.0 {
        pool {
           range 15.0.0.16 15.0.0.17;
        }
         option domain-name "test123.com";
         option optionSpacedb.option1d 5.6.7.8;
         option routers 15.0.0.1;
         option subnet-mask 255.255.255.0;
        }
But I was stuck in testing it by DHCP clients. Do we need to do any setting
on the client side to request the option space, I have checked in other
forums but they only provide the declaration examples but no where we have
practical test example.can any one please help on testing it or any
reference links that can be test on real time environment.Any reference site
for the DHCP option space concept because all i found are the part of its no
complete stuff.Thanks in advance

Thanks



--
Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Peter Rathlev]

I'm a bit late to the game but I guess it might help someone anyway.

On Mon, 2019-07-01 at 07:43 -0500, Teja wrote:
> How can a DHCP client can get the DHCP option space data from
> respective server config

The server selects the relevant option space, typically based on
something the client sends.

The normal way is to use vendor encapsulation. You need to specify that
you want to use your "optionSpacedb" as the vendor space. For you
simple example (using addresses registered to HP!) you could just add:

  option space optionSpacedb;
  option optionSpacedb.option1d code 1 = ip-address;
  subnet 15.0.0.0 netmask 255.255.255.0 {
      pool { range 15.0.0.16 15.0.0.17; }
      option domain-name "test123.com";
      vendor-option-space optionSpacedb;           # <====
      option optionSpacedb.option1d 5.6.7.8;
      option routers 15.0.0.1;
      option subnet-mask 255.255.255.0;
  }

And then have your client request vendor-encapsulated option 43.

It makes the more sense assign the vendor-option-space and the specific
options in a class that only matches relevant clients. Otherwise every
client asking for option 43 will get those encapsulated options.

An example of what we use for Avaya IP phones:

 option space Avaya;
 option Avaya.Magic code 1 = text;
 option Avaya.HTTPSRVR code 2 = text;
 option Avaya.SIG code 14 = text;
 class "Avaya9600" {
     match if option vendor-class-identifier = "ccp.avaya.com";
     vendor-option-space Avaya;
     option Avaya.Magic "6889";
     option Avaya.HTTPSRVR "192.0.2.221";
     option Avaya.SIG "2";
 }

The other option is "site-option-space". I haven't used it but it
sounds like it is used to define regular options, i.e. not vendor
encapsulated. This only makes sense with a specific client selector,
like vendor-class-identifier in the example above. Otherwise you could
just redefine the option globally.

And you must use option codes 224-255 so it doesn't conflict with
regular options. Specifically option code 1 is "subnet mask", which you
probably don't want to change the meaning of.

If you don't care about client selection you can just define options
globally:

option AvayaSSON code 242 = text;
[...]
        # Somewhere in a subnet or pool declaration
        option AvayaSSON "HTTPSRVR=192.0.2.221,SIG=2";

This works okay if you only have one client type asking for that
specific option. Otherwise you need option spaces.

--
Peter



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