shared subnet declaration behavior between 2 pools

project722 project722 at gmail.com
Mon Oct 9 20:52:14 UTC 2017


Thanks Simon, that was very helpful!!

On Mon, Oct 9, 2017 at 3:49 PM, project722 <project722 at gmail.com> wrote:

> Thanks all. I'm just trying to figure out if the "shared network" option
> will automatically use our second pool when the first one gets full. But, I
> think Bob has answered that question. If what he is saying is correct, then
> my question is answered.
>
> On Mon, Oct 9, 2017 at 3:36 PM, Patrick Trapp <ptrapp at nex-tech.com> wrote:
>
>> All things being equal, I don’t know how it handles this. In our network,
>> each pool in the shared network is assigned based on class matching (or not
>> matching). In our case, each class matches a different type of device which
>> gets a different configuration in addition to receiving an address from a
>> different pool.
>>
>>
>>
>> I’m not sure, looking at your configuration here, why you need a shared
>> network. What are you trying to accomplish?
>>
>>
>>
>> In our case, we have multiple networks that are all reaching the DHCP
>> server via a particular network. In order for ISC DHCP to accept a request
>> from network Z when the request came through network X, we define shared
>> networks so that the server accepts the request as valid. Otherwise, it
>> rejects the request. You don’t seem to have that type of scenario in your
>> example.
>>
>>
>>
>> What problem are you trying to fix with a shared network?
>>
>>
>>
>> *From:* dhcp-users [mailto:dhcp-users-bounces at lists.isc.org] *On Behalf
>> Of *project722
>> *Sent:* Monday, October 9, 2017 3:10 PM
>> *To:* Users of ISC DHCP <dhcp-users at lists.isc.org>
>> *Subject:* shared subnet declaration behavior between 2 pools
>>
>>
>>
>> Hello. im curious as to how dhcpd determines what pool to pull a lease
>> from in a shared subnet declaration. for ex on our server we have:
>>
>>
>>
>> shared-network "Market 1" {
>>
>>         option domain-name "example.com";
>>
>>                 subnet 192.168.1.0 netmask 255.255.255.0 {
>>
>>                 option broadcast-address 192.168.1.255;
>>
>>                 option routers 192.168.1.1;
>>
>>                 pool {
>>
>>
>>
>>
>>
>>                        failover peer "dhcp-failover";
>>
>>                        range 192.168.1.10 192.168.1.254;
>>
>>
>>
>>         }
>>
>>         subnet 192.168.2.0 netmask 255.255.255.0 {
>>
>>                 option broadcast-address 192.168.2.255;
>>
>>                 option routers 192.168.2.1;
>>
>>                 pool {
>>
>>
>>
>>                         failover peer "dhcp-failover";
>>
>>                         range 192.168.2.10 192.168.2.254;
>>
>>
>>
>>
>>
>>                }
>>
>> }
>>
>>
>>
>> I would suspect that the broadcasts that come through these
>> routers/gateways determine the pool that dhcp assigns a lease from. So, if
>> a client requests is seen by the sever comes from 192.168.1.1 it will get a
>> lease out of that pool, and if it sees that the client requests cvomes from
>> 192.168.2.1 it will get a lease from that pool. Is my understanding correct
>> on this? If that is correct, then what happens when the 192.168.1.0 network
>> gets full? Does dhcpd have some type of algo that allows it to assign a
>> lease from the 192.168.2.0 pool in order to prevent an out of leases
>> condition?
>>
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20171009/98e34cc9/attachment-0001.html>


More information about the dhcp-users mailing list