group and agent.circuit-id

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

group and agent.circuit-id

Nick Urbanik-2
Dear Folks,

I would like to provide a different
option domain-name-servers ....;
to DHCP clients with particular agent.circuit-id values.

What is the most appropriate way to do that?

I could do something like this:

class "a-particular-agent.circuit-id" {
    match if option agent.circuit-id = "a-particular-agent.circuit-id";
    option domain-name-servers 1.2.3.4, 5.6.7.8;
}
class "another-particular-agent.circuit-id" {
    match if option agent.circuit-id = "another-particular-agent.circuit-id";
    option domain-name-servers 1.2.3.4, 5.6.7.8;
}
...
Would that work?

Or can I use group and specify membership of that group somehow if the
agent.circuit-id has one of a particular set of values?

The context here is the Australian NBN, and the agent.circuit-id is
the AVC identifier used to identify the particular subscriber.
--
Nick Urbanik             http://nicku.org           [hidden email]
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: group and agent.circuit-id

Nick Urbanik-2
On 03/12/16 16:59 +1100, Nick Urbanik wrote:

>I would like to provide a different
>option domain-name-servers ....;
>to DHCP clients with particular agent.circuit-id values.
>
>What is the most appropriate way to do that?
>
>I could do something like this:
>
>class "a-particular-agent.circuit-id" {
>    match if option agent.circuit-id = "a-particular-agent.circuit-id";
>    option domain-name-servers 1.2.3.4, 5.6.7.8;
>}
>class "another-particular-agent.circuit-id" {
>    match if option agent.circuit-id = "another-particular-agent.circuit-id";
>    option domain-name-servers 1.2.3.4, 5.6.7.8;
>}
>...
>Would that work?
>
>Or can I use group and specify membership of that group somehow if the
>agent.circuit-id has one of a particular set of values?
>
>The context here is the Australian NBN, and the agent.circuit-id is
>the AVC identifier used to identify the particular subscriber.

Could this work:

group "different-dns" {
    option domain-name-servers 1.2.3.4, 5.6.7.8;
    host "host1" { host-identifier option agent.remote-id "a-particular-agent.circuit-id"; }
    host "host2" { host-identifier option agent.remote-id "another-particular-agent.circuit-id"; }
    ...
}

???
--
Nick Urbanik             http://nicku.org           [hidden email]
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: group and agent.circuit-id

Niall O'Reilly
On 3 Dec 2016, at 7:56, Nick Urbanik wrote:

> Could this work:
>
> group "different-dns" {
>    option domain-name-servers 1.2.3.4, 5.6.7.8;
>    host "host1" { host-identifier option agent.remote-id
> "a-particular-agent.circuit-id"; }
>    host "host2" { host-identifier option agent.remote-id
> "another-particular-agent.circuit-id"; }
>    ...
> }

   From the man-page:

   "The host-identifier option statement [...] identifies a DHCPv6
client in a host statement."

   So, what you suggest seems valid only if you're running a DHCPv6
server.

   For classic (IPv4) DHCP, the only data items you can use to identify
a host are
   the 'dhcp-client-identifier' option and the network hardware address.

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

Re: group and agent.circuit-id

Niall O'Reilly
In reply to this post by Nick Urbanik-2
On 3 Dec 2016, at 5:59, Nick Urbanik wrote:

> class "a-particular-agent.circuit-id" {
>    match if option agent.circuit-id = "a-particular-agent.circuit-id";
>    option domain-name-servers 1.2.3.4, 5.6.7.8;
> }
> class "another-particular-agent.circuit-id" {
>    match if option agent.circuit-id =
> "another-particular-agent.circuit-id";
>    option domain-name-servers 1.2.3.4, 5.6.7.8;
> }
> ...
> Would that work?

   Yes, but using subclasses (Droms & Lemon: The DHCP Handbook, 1st edn.
p. 273)
   should be more efficient.

   For example:

   class "dns-by-circuit-id" {
     match option agent-circuit-id;
     option domain-name-servers 1.2.3.4, 5.6.7.8;
   }

   subclass "dns-by-circuit-id" "a-particular";
   subclass "dns-by-circuit-id" "a-nother";
   subclass "dns-by-circuit-id" "a-third" {
     # subclass can over-ride master class if necessary
     option domain-name-servers 2.3.4.5, 6.7.8.9;
   }

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

Re: group and agent.circuit-id

Nick Urbanik-2
In reply to this post by Niall O'Reilly
Dear Niall,

On 03/12/16 16:34 +0000, Niall O'Reilly wrote:

>On 3 Dec 2016, at 7:56, Nick Urbanik wrote:
>
>> Could this work:
>>
>> group "different-dns" {
>>    option domain-name-servers 1.2.3.4, 5.6.7.8;
>>    host "host1" { host-identifier option agent.remote-id
>> "a-particular-agent.circuit-id"; }
>>    host "host2" { host-identifier option agent.remote-id
>> "another-particular-agent.circuit-id"; }
>>    ...
>> }
>
>   From the man-page:
>
>   "The host-identifier option statement [...] identifies a DHCPv6
>client in a host statement."
>
>   So, what you suggest seems valid only if you're running a DHCPv6
>server.
>
>   For classic (IPv4) DHCP, the only data items you can use to identify
>a host are
>   the 'dhcp-client-identifier' option and the network hardware address.

Thank you, yes, I saw it used in an example without realising it was
IPv6 only.
--
Nick Urbanik             http://nicku.org           [hidden email]
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: group and agent.circuit-id

Nick Urbanik-2
In reply to this post by Niall O'Reilly
Daer Niall,

On 03/12/16 16:44 +0000, Niall O'Reilly wrote:

>On 3 Dec 2016, at 5:59, Nick Urbanik wrote:
>
>> class "a-particular-agent.circuit-id" {
>>    match if option agent.circuit-id = "a-particular-agent.circuit-id";
>>    option domain-name-servers 1.2.3.4, 5.6.7.8;
>> }
>> class "another-particular-agent.circuit-id" {
>>    match if option agent.circuit-id =
>> "another-particular-agent.circuit-id";
>>    option domain-name-servers 1.2.3.4, 5.6.7.8;
>> }
>> ...
>> Would that work?
>
>   Yes, but using subclasses (Droms & Lemon: The DHCP Handbook, 1st edn.
>p. 273)
>   should be more efficient.
>
>   For example:
>
>   class "dns-by-circuit-id" {
>     match option agent-circuit-id;
>     option domain-name-servers 1.2.3.4, 5.6.7.8;
>   }
>
>   subclass "dns-by-circuit-id" "a-particular";
>   subclass "dns-by-circuit-id" "a-nother";
>   subclass "dns-by-circuit-id" "a-third" {
>     # subclass can over-ride master class if necessary
>     option domain-name-servers 2.3.4.5, 6.7.8.9;
>   }

Thank you again.  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";
}
...
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 have some questions:
1. Would this existing scheme clash with that you proposed?
2. Could things work better if I changed the static allocation scheme
   to use subclasses?  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.

I appreciate the time you have spent in your thoughtful replies, and
hope that this discussion can help others who are implementing systems
like the NBN (national broadband network) system in Australia, where
people are identified by agent.circuit-id.
--
Nick Urbanik             http://nicku.org           [hidden email]
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: group and agent.circuit-id

Niall O'Reilly
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
Reply | Threaded
Open this post in threaded view
|

Re: group and agent.circuit-id

Nick Urbanik
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 [hidden email]
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24  ID: BB9D2C24
I disclaim, therefore I am.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users