Common settings

[Mike Richardson-2]

Hiya,

If I have multiple large sets of subnets and want to apply different common
options to them, is there a nice way of doing it?

e.g.

subnet 1.1.1.0 netmark 255.255.255.0 {}
subnet 1.1.2.0 netmark 255.255.255.0 {}
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Niall O'Reilly]

On 29 Nov 2016, at 10:05, Mike Richardson wrote:

> Hiya,
>
> If I have multiple large sets of subnets and want to apply different common
> options to them, is there a nice way of doing it?
>
> e.g.
>
> subnet 1.1.1.0 netmark 255.255.255.0 {}
> subnet 1.1.2.0 netmark 255.255.255.0 {}

  [ s/netmark/netmask/ ? ]

  In the general case, there's no nice way to make one group of subnets
  have the values for certain options in common, while another group has
  a different set of common values for the same or another set of options.
  Specifying the options repeatedly inside each '{' ... '}' block is all
  that can be done.

  That said, if you can match a common set of options to a particular
  set of network devices by topology (shared-network) or by device
  characteristics (class), you can specify the common options in the
  corresponding shared-network or class definition.

  Best regards,
  Niall O'Reilly
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Mike Richardson-2]

On Tue, Nov 29, 2016 at 05:11:28PM +0000, Niall O'Reilly wrote:
>   In the general case, there's no nice way to make one group of subnets
>   have the values for certain options in common, while another group has
>   a different set of common values for the same or another set of options.
>   Specifying the options repeatedly inside each '{' ... '}' block is all
>   that can be done.

Ok, thanks. My best bet then it probably a script which generates a suitable
file to be included in the main config.

>   That said, if you can match a common set of options to a particular
>   set of network devices by topology (shared-network) or by device
>   characteristics (class), you can specify the common options in the
>   corresponding shared-network or class definition.

I'd looked at using the class but, because of the precendence rules, that
meant I couldn't have one of the subnet definitions with a setting that
overrode the class one. I can see the logic of having the precedence the way
it us, it just doesn't happen to suit what I'd like to do.

An enhancement along the lines of 'force option blah' would be nice, which
takes precedent over other ones when its section matches a client.

Thanks,

Mike

--
Mike Richardson
Networks ([hidden email])
IT Services, University of Manchester
*Plain text only please - attachments stripped on arrival*
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Mike Richardson <[hidden email]> wrote:

> An enhancement along the lines of 'force option blah' would be nice, which
> takes precedent over other ones when its section matches a client.

It's not clear what you are looking to do here.

You mention "matches a client", but earlier you talk about options for each subnet.

Your first message had me thinking that you are wanting to reduce the amount of this in the config :
subnet blah... {
  option dns_servers ...;
  option ...
  option ...
  ...
}

As stated, there isn't really a great scope for reducing that.
You can see the most common options globally, so for example if 80% of your subnets use the same DNS servers, you could set that option globally and only set it per-subnet where it's different.
Or, as you hint at, if you have a small number of common sets of options, you can set them in include files :
subnet blah... {
  $INCLUDE user_subnet_options ;
  ...
}

The only other construct I can think of (and I don't know if this would work) is the group { ... } structure. Eg :
#User subnets
group {
  option blah...;
  option blah...;
  subnet blah...{
    ...
  }
  subnet blah...{
    ...
  }
  ...
}
According to The DHCP Handbook, "You can use the group declaration to provide a common scope for whatever is declared within it. For example, if several host declarations require the same set of parameters ..."
There doesn't seem to be any suggestion it can't be used for subnets.

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

[Mike Richardson-2]

On Wed, Nov 30, 2016 at 09:46:59AM +0000, Simon Hobson wrote:
> Mike Richardson <[hidden email]> wrote:
>
> > An enhancement along the lines of 'force option blah' would be nice, which
> > takes precedent over other ones when its section matches a client.
>
> It's not clear what you are looking to do here.
>
> You mention "matches a client", but earlier you talk about options for each subnet.

In the way that a client will match a subnet that's suitable for it. I
wasn't quite sure of what terminology to use. When a client asks for an
address it will 'match' a subnet and maybe a class and maybe a group and
maybe a host. Precendence determines which of these matches will be the one
to return the option value.

If a client matches a subnet and a class and a host and the same option is
set for all three (say, default-lease) then the one defined in the host will
be the one used. However, if 'force default-lease' were set in the subnet
then that would be the one used.

> Your first message had me thinking that you are wanting to reduce the amount of this in the config :
> subnet blah... {
>   option dns_servers ...;
>   option ...
>   option ...
>   ...
> }

Yep, that's the idea.

> As stated, there isn't really a great scope for reducing that.
> You can see the most common options globally, so for example if 80% of your subnets use the same DNS servers, you could set that option globally and only set it per-subnet where it's different.
> Or, as you hint at, if you have a small number of common sets of options, you can set them in include files :
> subnet blah... {
>   $INCLUDE user_subnet_options ;
>   ...
> }

In practice the split would be roughly equal across several groups of
subnets, each group consisting of 256 declarations (splitting /16s into
/24s).

> The only other construct I can think of (and I don't know if this would work) is the group { ... } structure. Eg :
> #User subnets
> group {
>   option blah...;
>   option blah...;
>   subnet blah...{
>     ...
>   }
>   subnet blah...{
>     ...
>   }
>   ...
> }
> According to The DHCP Handbook, "You can use the group declaration to provide a common scope for whatever is declared within it. For example, if several host declarations require the same set of parameters ..."
> There doesn't seem to be any suggestion it can't be used for subnets.

Ok, I'd looked at the group option but had only seen it used in the context
of hosts. I'll give it a go.

Thanks,

Mike

--
Mike Richardson
Networks ([hidden email])
IT Services, University of Manchester
*Plain text only please - attachments stripped on arrival*
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users