<div dir="ltr"><div>Hi Marcin, thank you for your response. I'll try to respond to your questions.</div><div><br></div><div>> How does the server determine which subnet it should use to make this assignment?</div><div><br></div><div>The DHCP server selects a subnet according to lease availability (free leases). </div><div><br></div><div>> Couldn't you just define a single subnet and multiple address pools within the same subnet?</div><div><br></div><div>In this configuration scenario, subnets have different prefixes so I understand that it's not useful to have a subnet with different pools. I guess that the whole thing has to do with exhaustion of the IPv4 address space and optimization of address usage. Cable operators most of the times have: 1 subnet for CM (private addresses), 1 subnet for MTA (private addresses) and several subnets for CPE (public addresses). And it's common for cable operators to move subnets between CMTSs to optimize usage; or adding new subnets to be able to provision new customers on a CMTS.</div><div><br></div><div>> if the client has obtained an address from a given network/subnet, is it possible for this client to move onto another network/subnet under some conditions?</div><div><br></div><div>Yes. Obviously that will happen if the CPE moves to another CMTS (e.g. a cellphone, or notebook). But also, if the lease expires the CPE could obtain a lease from another subnet.</div><div><br></div><div>> Would configuration of these subnets include the same option sets?</div><div><br></div><div>As far as I know, the only option that changes is the routers option.</div><div><br></div><div><br></div><div>Regards,</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">
<div><font face="'courier new', monospace"><font color="#333399"><font size="2">Guido Marelli</font><br><font size="2">Intraway Corp.</font><br><font size="2">Project Leader</font><br></font></font><span style="font-size:13px;color:rgb(51,51,153);font-family:'courier new',monospace">AR Office: </span><font face="'courier new', monospace" style="font-size:13px"><font color="#333399"><a value="+541160404000" style="color:rgb(17,85,204)">+54 (11) 6040 4000 x4033</a></font></font></div><div style="font-size:13px"><span style="color:rgb(51,51,153);font-family:'courier new',monospace">US Office: </span><font face="'courier new', monospace"><font color="#333399"><a value="+15166203890" style="color:rgb(17,85,204)">+1 (516) 620 3890 X4033</a> </font></font><span style="color:rgb(51,51,153);font-family:'courier new',monospace"> </span></div><p><span style="font-size:10pt;font-family:"Courier New";color:rgb(31,73,125)" lang="EN-US"></span></p><div style="font-size:13px"><span style="color:rgb(51,51,153);font-family:'courier new',monospace">Mobile: </span><font face="'courier new', monospace"><font color="#333399"><a value="+5491151111111" style="color:rgb(17,85,204)">+54 (911) 5424 9574</a> <br>Email:</font> <a href="mailto:guido.marelli@intraway.com" style="color:rgb(17,85,204)" target="_blank">guido.marelli@intraway.com</a></font><div><br><div><br></div><div><span style="border-collapse:collapse"><font color="#333399"><span lang="EN-US" style="font-size:10pt;font-family:'Courier New'">Visit our website at </span><a href="http://www.intraway.com/" style="color:rgb(17,85,204)" target="_blank"><span lang="EN-US" style="font-size:10pt;font-family:'Courier New'">http://www.intraway.com</span></a><span lang="EN-US" style="font-size:10pt;font-family:'Courier New'"><br>Proud to be an ISO 9001:2008 certified company</span></font></span></div></div></div><p></p></div></div></div>
<br><div class="gmail_quote">On Wed, Nov 18, 2015 at 11:55 AM, Marcin Siodelski <span dir="ltr"><<a href="mailto:marcin@isc.org" target="_blank">marcin@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Guido,<br>
<br>
Kea treats "subnet" as a client's point of attachment and hence it<br>
assumed that the particular client (on the particular link) belongs to<br>
one subnet.<br>
<br>
Together with fully fledged "client classification" (planned for Kea 1.1<br>
release) Kea will get some more flexibility. In particular, it will be<br>
possible to use expressions defining additional conditions for subnet<br>
selection. In other words, it will be possible to select different<br>
subnet, depending on what options the client has sent. This is to better<br>
facilitate the case that I described in my first email to you, and also<br>
other use cases like PXE boot etc.<br>
<br>
Whether "client classification" will be suitable for the multi-network<br>
scenario you're describing, it is up for consideration. I'd like to<br>
understand this use case a bit more.<br>
<br>
Suppose there is a single DHCPv4 server, single CMTS (relay) and a<br>
single CPE. It probably doesn't matter from the server perspective<br>
whether we're talking about the CM or router part of CPE trying to<br>
obtain its DHCP configuration. The CPE initiates a DHCP exchange via<br>
CMTS. The server receives message from the CPE. The server has three<br>
networks (subnets and pools) configured, from which it could assign an<br>
address and options to this CPE. The question is, how does the server<br>
determine which subnet it should use to make this assignment? Relay<br>
agent address doesn't appear to be sufficient because all networks are<br>
associated with the same CMTS. I guess the server would need to look<br>
into some specific options or fixed fields of the DHCPv4 message to make<br>
this determination? Which fields and options?<br>
<br>
I also wonder why multiple networks are needed for a single CPE? You say<br>
that these networks are "the same". I am not sure I understand what it<br>
means. They should at least have different (non-overlapping) address<br>
pools? If this is the case, couldn't you just define a single subnet and<br>
multiple address pools within the same subnet? Of course, that wouldn't<br>
be feasible if they use a different address prefix. But, that I don't<br>
know from your description.<br>
<br>
Also, if the client has obtained an address from a given network/subnet,<br>
is it possible for this client to move onto another network/subnet under<br>
some conditions?<br>
<br>
Another question about the matter of many networks. Would configuration<br>
of these subnets include the same option sets? In other words, if the<br>
client A obtains configuration from subnet/network X and the client B<br>
obtains configuration from subnet/network Y, would they get the same<br>
options, e.g. the same dns servers list etc?<br>
<br>
<br>
I believe that client classification will support many, if not all, use<br>
cases. However, there is always a possibility to write a custom hook<br>
library which will customize server's behavior with respect to many<br>
things, including subnet selection. If you decide to go down that path,<br>
we can serve with advice.<br>
<br>
Marcin<br>
<span class=""><br>
On 13.11.2015 15:58, Guido Marelli wrote:<br>
> Hi Marcin, thank you for clarifying.<br>
><br>
> On the other hand, a scenario that I have observed in many deployments<br>
> with DHCPv4, is the existence of multiple networks configured in the<br>
> same relay/CMTS that are eligible for leasing to the same type of<br>
> device. This is: there is no difference between networks A, B and C but<br>
> any of these networks can be use to assign addresses, for example, to<br>
> CPEs.<br>
><br>
> From your comments, I understand that this is now not possible with Kea:<br>
> Do you plan to include this type of functionality?<br>
><br>
><br>
> Guido Marelli<br>
> Intraway Corp.<br>
> Project Leader<br>
> AR Office: +54 (11) 6040 4000 x4033<br>
> US Office: +1 (516) 620 3890 X4033<br>
><br>
> Mobile: +54 (911) 5424 9574<br>
</span><span class="">> Email: <a href="mailto:guido.marelli@intraway.com">guido.marelli@intraway.com</a> <mailto:<a href="mailto:guido.marelli@intraway.com">guido.marelli@intraway.com</a>><br>
><br>
><br>
> Visit our website at <a href="http://www.intraway.com" rel="noreferrer" target="_blank">http://www.intraway.com</a> <<a href="http://www.intraway.com/" rel="noreferrer" target="_blank">http://www.intraway.com/</a>><br>
> Proud to be an ISO 9001:2008 certified company<br>
><br>
><br>
</span><span class="">> On Thu, Nov 12, 2015 at 6:25 AM, Marcin Siodelski <<a href="mailto:marcin@isc.org">marcin@isc.org</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:marcin@isc.org">marcin@isc.org</a>>> wrote:<br>
><br>
><br>
> On 10.11.2015 17:00, Guido Marelli wrote:<br>
> > Hi,<br>
> ><br>
> > I'm analyzing the feasibility of using Kea in DOCSIS networks.<br>
> However,<br>
> > I didn't managed to configure Kea to use more than one IPv4<br>
> subnet with<br>
> > the same relay/giaddr.<br>
> ><br>
> > What I observed is that Kea depletes leases from the first<br>
> subnet and<br>
> > that the other subnets, which were configured with the same<br>
> relay, are<br>
> > ignored. I think this behavior is due to the method "CfgSubnets4 ::<br>
> > selectSubnet" which iterates subnets until it finds the first subnet<br>
> > that matches the giaddr, but it doesn't check lease availability.<br>
> ><br>
> > Any thoughts on this?<br>
> ><br>
> ><br>
> > Regards,<br>
> > Guido<br>
> ><br>
> ><br>
> > Guido Marelli<br>
> > Intraway Corp.<br>
> > Project Leader<br>
> > AR Office: +54 (11) 6040 4000 x4033<br>
> > US Office: +1 (516) 620 3890 X4033<br>
> ><br>
> > Mobile: +54 (911) 5424 9574<br>
> > Email: <a href="mailto:guido.marelli@intraway.com">guido.marelli@intraway.com</a><br>
> <mailto:<a href="mailto:guido.marelli@intraway.com">guido.marelli@intraway.com</a>><br>
</div></div>> <mailto:<a href="mailto:guido.marelli@intraway.com">guido.marelli@intraway.com</a><br>
<span class="">> <mailto:<a href="mailto:guido.marelli@intraway.com">guido.marelli@intraway.com</a>>><br>
> ><br>
> ><br>
> > Visit our website at <a href="http://www.intraway.com" rel="noreferrer" target="_blank">http://www.intraway.com</a><br>
> <<a href="http://www.intraway.com/" rel="noreferrer" target="_blank">http://www.intraway.com/</a>><br>
> > Proud to be an ISO 9001:2008 certified company<br>
> ><br>
> ><br>
> ><br>
><br>
> Hi Guido,<br>
><br>
> Thanks for your email and your interest in Kea.<br>
><br>
> We have implemented "limited" support for DOCSIS in 2013 and<br>
> successfully tested it with one cable network. This limited support<br>
> facilitates the case when devices connected to the same link obtain<br>
> addresses from different subnets. The devices are differentiated<br>
> by the<br>
> contents of the Vendor Class Identifier. It is assumed that that a<br>
> device is a CM if the identifier is "docsis3.0". It is assumed<br>
> that the<br>
> device is a router if the identifier is "eRouter1.0".<br>
><br>
> As per the Kea User's Guide:<br>
> <a href="http://kea.isc.org/docs/kea-guide.html#dhcp4-client-classifier" rel="noreferrer" target="_blank">http://kea.isc.org/docs/kea-guide.html#dhcp4-client-classifier</a><br>
><br>
> you can create a subnet with address pools dedicated exclusively<br>
> for CMs<br>
> with a configuration similar to this:<br>
><br>
> "Dhcp4": {<br>
> "subnet4": [<br>
> {<br>
</span>> "subnet": "<a href="http://192.0.2.0/24" rel="noreferrer" target="_blank">192.0.2.0/24</a> <<a href="http://192.0.2.0/24" rel="noreferrer" target="_blank">http://192.0.2.0/24</a>>",<br>
<div class="HOEnZb"><div class="h5">> "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],<br>
> "relay": {<br>
> "ip-address": "10.0.0.1"<br>
> },<br>
> "client-class": "VENDOR_CLASS_docsis3.0"<br>
> }<br>
> ],<br>
> ...<br>
> }<br>
><br>
> Note that the "docsis3.0" is an identifier sent in the Vendor Class<br>
> Identifier option by CM. If your CMs send different identifier, the<br>
> class name is "VENDOR_CLASS_<your-cm-identifier>".<br>
><br>
> One final note. The "proper" implementation of DOCSIS requires full<br>
> support for client classification, i.e. the server must be able to<br>
> extract arbitrary expressions from various DHCP options and use<br>
> them to<br>
> assign a client to a particular class or set of classes. Then, classes<br>
> are used to assign subnets, options etc according to the<br>
> configuration.<br>
> The first part of this generic client classification will be available<br>
> with the Kea1.0 release (December 2015). The next release (Kea1.1) is<br>
> fully devoted to finish up client classification. So, if the current<br>
> "limited" support for DOCSIS is not sufficient for your<br>
> deployment, you<br>
> may wish to monitor the progress on client classification for 1.0 and<br>
> 1.1 releases to make sure it would address your needs.<br>
><br>
> I should also note that Kea has a built-in mechanism of "hooks" which<br>
> allows for customizing packet processing at various stages. The server<br>
> calls out to custom/user-defined C++ library to perform common tasks<br>
> like subnet selection, options assignment etc. It is possible for<br>
> you to<br>
> create a simple C++ library which replaces standard subnet selection<br>
> mechanism with customized one, required in your deployment.<br>
><br>
> More about writing your own hooks can be found in Kea Developer's<br>
> Guide:<br>
><br>
> <a href="http://git.kea.isc.org/~tester/kea/doxygen/df/d46/hooksdgDevelopersGuide.html" rel="noreferrer" target="_blank">http://git.kea.isc.org/~tester/kea/doxygen/df/d46/hooksdgDevelopersGuide.html</a><br>
><br>
> Marcin Siodelski<br>
> DHCP Software Engineer<br>
> ISC<br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>