strange behavior of shared network

[Sten Carlsen]

-- 
Best regards 
Sten Carlsen


"No trees were killed in the making of this e-mail... however,
a large number of electrons were terribly inconvenienced."

> On 4 Oct 2019, at 13.04, Milan Kovac <kovac65 at gmail.com> wrote:
> 
> I think I found the problem.
> 
> There can not be defined range in subnet which is for static clients.
Well, no.

My shared network has:
192.168.16.0/24 - one single network segment
192.168.16.1 - 192.168.16.30 - static and fixed allocations
192.168.16.31 - 192.168.16.49 - static allocations
192.168.16.50 - 192.168.16.150 - class based allocation - NO router given, no internet access
192.168.16.160 - 192.168.16.195 - class based allocation - router given
192.168.16.200 - 192.168.16.254 - static and fixed allocations

192.168.161.0/24 - for unknown clients until they get a fixed address or are put into a class
192.168.161.100 - 192.168.161.150 - only unknown clients

This works fine.

Looking at the data you give, I see no conflict. Can you be more specific about the problem?

> 
> I will test it more deeply and will give results.
> 
> In any case, thanks a lot for ideas.
> 
> Milan
> 
> Dňa 2. 10. 2019 o 21:50 Simon Hobson napísal(a):
>> Milan Kovac <kovac65 at gmail.com> wrote:
>> 
>>> I have a few routed networks each with 2 subnets ( public and private )
>> ...
>> 
>> 
>>> Here is dhcpd.conf
>> ...
>>> shared-network 001 {
>>> default-lease-time 43200;
>>> max-lease-time 43200;
>>> # divina-private
>>> subnet 10.64.0.0 netmask 255.255.240.0 {
>>>         option broadcast-address 10.64.15.255;
>>>         option subnet-mask 255.255.240.0;
>>>         option routers 10.64.0.1;
>>>         range 10.64.0.2 10.64.15.254;
>>>         }
>>> 
>>> # divina-public
>>> subnet 157.157.56.128 netmask 255.255.255.240 {
>>>         option broadcast-address 157.157.56.143;
>>>         option subnet-mask 255.255.255.240;
>>>         option routers 157.157.56.129;
>>>         deny unknown-clients;
>>>         range 157.157.56.130 157.157.56.142;
>>>     host Divinka-Uhliarik {
>>>                         hardware ethernet cc:2d:e0:3f:fa:42;
>>>                         fixed-address 157.157.56.130;
>>>                         }
>>>     host Divinka-Obecny-Urad {
>>>                         hardware ethernet 00:4f:74:31:b4:03;
>>>                         fixed-address 157.157.56.131;
>>>                         }
>>>                 }
>>> }
>> You need to fix this to start with.
>> Host statements must always be defined in the global scope - they cannot be defined in a lower scope as you have done here. Wherever you define them, they are always global in scope - but they can inherit options from where there are defined. This is almost certainly not what you want.
>> 
>> So I suggest you fix this first and if the problem persists, then we can try and diagnose it.
>> 
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
> _______________________________________________
> 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/20191004/99361815/attachment.html>