On 4 Dec 2016, at 5:01, Nick Urbanik wrote:
> Currently, we have more than 2000 classes of the
> form:
> class "a-circuit-id" {
> match if option agent.circuit-id = "a-circuit-id";
> set logged-class = "static";
> }
From what I've read in the Handbook and man-pages, this configuration
will give you a mean of more than 1000 trips around the loop that
compares the value provided by the client with each in turn of your
configured values.
> ...
> that are then used to allocate static IPs like this, inside subnet
> declarations:
> pool { failover peer "partner"; allow members of "a-circuit-id"; range
> 11.12.13.14; }
> ...
I'm not sure that failover gains you anything for a singleton range,
as there isn't any arbitrary state to be communicated to the partner.
Without failover, you can gain resilience by having identical
configurations
on more than two servers; failover limits you to two (per pool).
> I have some questions:
> 1. Would this existing scheme clash with that you proposed?
I can't say for sure, as I've never used or even tested such a
combination
of schemes. I don't know why they would cause each other problems
unless
you (mis-) configured the same value in a 'match if ...' statement as
in
a 'subclass' declaration.
> 2. Could things work better if I changed the static allocation scheme
> to use subclasses?
The matching would be faster, as subclasses are implemented using a
hash
table rather than a comparison loop.
> I'm not really sure how, since currently, each
> static assignment corresponds to a separate class, whereas
> subclasses provide a way to add multiple members to one class.
It's subtler than that: each subclass is a class of its own as well,
although without a distinct name to be referenced by.
This doesn't necessarily mean that the 'subclass' approach can meet
your
needs. It's not clear from either the Handbook or the man-page
whether
a 'fixed-address' declaration is allowed or forbidden in a 'subclass'
declaration. If it's allowed, then I think there's a solution which
gives
the performance advantage of subclass hashing and avoids the
complexity
of failover, like this:
class "dns-by-circuit-id" {
match option agent.circuit-id;
option domain-name-servers 1.2.3.4, 5.6.7.8;
}
# per-circuit-id subclasses, each with its own IP address
subclass "dns-by-circuit-id" "whatever" { fixed-address
11.12.13.14; }
If 'fixed-address' isn't allowed here, then I think you have to
continue with multiple classes. I expect you can drop failover
except
for customers (if any) for whom you assign a non-singleton pool.
I hope this helps.
Best regards,
Niall O'Reilly
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users