group and agent.circuit-id

Nick Urbanik nick.urbanik at optusnet.com.au
Thu Dec 8 11:09:17 UTC 2016


Dear Niall,

On 04/12/16 16:06 +0000, Niall O'Reilly wrote:
>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.

Certainly, your suggestions are most informative and helpful.  I have
a plan of action now.
-- 
Nick Urbanik http://nicku.org 808-71011 nick.urbanik at optusnet.com.au
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24  ID: BB9D2C24
I disclaim, therefore I am.


More information about the dhcp-users mailing list