cannot change ip address in pool (fixed question)
Glenn Satchell
glenn.satchell at uniq.com.au
Fri Sep 14 14:18:25 UTC 2012
This means that over a 10 minute period you will have about 1000 renewals.
About 3 every 2 seconds, so a very low powered server would handle this
easily.
regards,
-glenn
On Fri, September 14, 2012 7:05 pm, Jan nowak wrote:
> I think I fixed the problem. I changed two variables:
> default-lease-time 600; ( before 1200)
> max-lease-time 3600; ( before 12000)
>
> Is it good to have these values when i have more than 1k users ?
>
>
> 2012/9/13 Sten Carlsen <stenc at s-carlsen.dk>
>
>>
>> On 13/09/12 14:31, Glenn Satchell wrote:
>>
>> Actually defining pools at the shared-network level is ok, if somewhat
>> unusual. The server will match the pool up with an appropriate subnet.
>> So
>> no need to re-write the config file.
>>
>> Right, but then defining hosts at that level might get you in some
>> "interesting" situations with inheritance of options from unexpected
>> scopes.
>>
>> I think there might still be a good reason to go over the structure of
>> the
>> file and check it vs. best practices.
>>
>> Now, as to what is going on, perhaps using grep to find entries in the
>> log
>> file for that mac address and ip address. With thousands of entries, the
>> log file is going to be cluttered with other things.
>>
>> regards,
>> -glenn
>>
>> On Thu, September 13, 2012 6:22 pm, Jan nowak wrote:
>>
>> thanks for fast reply. You scared the hell out of me. I have 1k users
>> in
>> this config and every record have same pattern, all of this lines are in
>> shared netowrk
>>
>> #######################################################################################
>> host m69 { hardware ethernet 00:0a:73:f9:e6:3a; fixed-address
>> 172.16.10.69;
>> filename "file.cm";}
>> class "M069" { match if binary-to-ascii(16, 8, ":", option
>> agent.remote-id)
>> = "0:a:73:f9:e6:3a"; spawn with option agent.remote-id; lease limit 1;}
>> pool { allow members of "M069"; range 172.16.20.69; }
>>
>> host m70 { hardware ethernet 00:0a:73:f9:e6:31; fixed-address
>> 172.16.10.70;
>> filename "file.cm";}
>> class "M070" { match if binary-to-ascii(16, 8, ":", option
>> agent.remote-id)
>> = "0:a:73:f9:e6:31"; spawn with option agent.remote-id; lease limit 1;}
>> pool { allow members of "M070"; range 172.16.20.70; }
>>
>> host m71 { hardware ethernet 00:0a:73:f9:e6:32; fixed-address
>> 172.16.10.71;
>> filename "file.cm";}
>> class "M071" { match if binary-to-ascii(16, 8, ":", option
>> agent.remote-id)
>> = "0:a:73:f9:e6:32"; spawn with option agent.remote-id; lease limit 1;}
>> pool { allow members of "M071"; range 172.16.20.71; }
>>
>> host m72... etc
>> ##########################################################################################
>> and it would be very difficult to rewrite it. In this pattern every
>> modem
>> should have only one CPE device connected, so pool provides only one ip
>> address. As you can see the class and poll fields aren't between host
>> braces, they're independent of each other.
>> So what should i do now, should i rewrite entire config file ?
>>
>> kind regards,
>> Jan
>>
>> 2012/9/13 Simon Hobson <dhcp1 at thehobsons.co.uk> <dhcp1 at thehobsons.co.uk>
>>
>> Jan nowak top-posted:
>>
>>
>> Sep 13 07:32:35 debian dhcpd: ICMP Echo reply while lease 172.16.20.203
>>
>> valid.
>> Sep 13 07:32:35 debian dhcpd: ICMP Echo reply while lease 172.16.20.203
>> valid.
>> Sep 13 07:32:35 debian dhcpd: ICMP Echo reply while lease 172.16.20.203
>> valid.
>> Sep 13 07:32:35 debian dhcpd: ICMP Echo reply while lease 172.16.20.203
>> valid.
>> Sep 13 07:32:37 debian dhcpd: Reclaiming abandoned lease 172.16.20.203.
>> Sep 13 07:32:37 debian dhcpd: Reclaiming abandoned lease 172.16.20.203.
>> Sep 13 07:32:37 debian dhcpd: Reclaiming abandoned lease 172.16.20.203.
>> Sep 13 07:32:37 debian dhcpd: Reclaiming abandoned lease 172.16.20.203.
>>
>>
>> Not seen that first message before, but basically it means the server
>> has
>> pinged the address and got a reply - when it shouldn't have. So it's
>> marked
>> the lease as abandoned - abandoned leases are only used as last resort
>> if
>> nothing else is available.
>>
>> But this is a different address to the one of interest ...
>>
>>
>> Sep 13 07:32:41 debian dhcpd: data: "leased-address" configuration
>>
>> directive: there is no lease associated with this client.
>>
>>
>> That would be correct - the lease has been abandoned and there's
>> nothing
>> leased to the client.
>>
>>
>> Sep 13 07:32:58 debian dhcpd: DHCPDISCOVER from 00:14:5e:7f:35:3c via
>>
>> eth0: network xxx: no free leases
>>
>>
>> Sep 13 07:32:58 debian dhcpd: DHCPDISCOVER from 00:14:5e:7f:35:3c via
>>
>> eth0: network xxx: no free leases
>>
>>
>> This is what you expect to see when using restricted lease ranges and
>> old
>> leases are still active. There isn't anything for the server to assign
>> to
>> the client. Again, this isn't the client (MAC) in the config snippet.
>>
>> It's not that helpful to see this unrelated log extract. If it's a
>> network
>> with too much DHCP traffic to extract only the relevant entries, then
>> you
>> probably need to either temporarily disable DHCP service for all but one
>> client, or setup a test environment with only the one client.
>>
>>
>> shared-network xxx{
>>
>> subnet 172.16.0.0 netmask 255.255.0.0 {
>> next-server 192.168.0.1;
>> option domain-name-servers 217.30.129.149, 217.30.137.200;
>> option routers 172.16.0.1;
>> option subnet-mask 255.255.0.0;
>> option broadcast-address 172.16.255.255;
>> }
>>
>>
>> Could I suggest better formatting would be a good idea ? Something like
>> this would make the nesting more readily viewable :
>>
>>
>> shared-network xxx{
>>
>> subnet 172.16.0.0 netmask 255.255.0.0 {
>> next-server 192.168.0.1;
>> option domain-name-servers 217.30.129.149, 217.30.137.200;
>> option routers 172.16.0.1;
>> option subnet-mask 255.255.0.0;
>> option broadcast-address 172.16.255.255;
>> }
>>
>> subnet ...
>>
>> This is especially true when we get to your host statements.
>>
>>
>> ##############################**###########
>>
>> host m69 { hardware ethernet 00:0a:73:f9:e6:3a; fixed-address
>> 172.16.10.69; filename "<http://plik.cm> <http://plik.cm>plik.cm";}
>>
>> class "M069" { match if binary-to-ascii(16, 8, ":", option
>> agent.remote-id) = "0:a:73:f9:e6:3a"; spawn with option
>> agent.remote-id;
>> lease limit 1;}
>> pool { allow members of "M069"; range 172.16.20.69; }
>> ##############################**################
>> }
>>
>>
>> Not only is this hard to read, it's mixing scopes as well.
>>
>>
>> host m69 {
>> hardware ethernet 00:0a:73:f9:e6:3a;
>> fixed-address 172.16.10.69;
>> filename "plik.cm";}
>> class "M069" {
>> match if binary-to-ascii(16, 8, ":", option agent.remote-id) =
>> "0:a:73:f9:e6:3a";
>> spawn with option agent.remote-id; lease limit 1;
>> }
>> pool {
>> allow members of "M069";
>> range 172.16.20.69;
>> }
>> }
>>
>> So what *exactly* are you trying to achieve with this ?
>> You've correctly put the host statement in the global scope, but then
>> you've defined a class and pool within it.
>> I'm not sure about the class (do these need to be in the global scope
>> ?),
>> but the pool really belongs within the subnet.
>>
>> And there should be no need to have both the class/pool AND a fixed
>> address - either one or the other. So either :
>>
>>
>> host m69 {
>> hardware ethernet 00:0a:73:f9:e6:3a;
>> fixed-address 172.16.10.69;
>> filename "plik.cm";}
>> }
>>
>> or :
>>
>> class "M069" {
>>
>> match if option agent.remote-id) = 0:a:73:f9:e6:3a;
>> spawn with option agent.remote-id; lease limit 1;
>> }
>> and
>>
>> subnet 172.16.0.0 netmask 255.255.0.0 {
>> next-server 192.168.0.1;
>> option domain-name-servers 217.30.129.149, 217.30.137.200;
>> option routers 172.16.0.1;
>> option subnet-mask 255.255.0.0;
>> option broadcast-address 172.16.255.255;
>> pool {
>> allow members of "M069";
>> range 172.16.20.69;
>> }
>> }
>>
>> Ahh, now I've split that up, it becomes clearer. 172.16.10.69 is for the
>> device with MAC address 00:0a:73:f9:e6:3a and 172.16.20.69 is for the
>> downstream device.
>> As you've defined it, I don't think the class would be matched because
>> the
>> definition (and pool statement) are within a host statement that will
>> not
>> apply to the downstream client.
>> By definition, the downstream client will not be the host with MAC
>> address
>> 0:a:73:f9:e6:3a, so the host statement will not be matches, and nothing
>> inside it will be acted upon.
>>
>> --
>> Simon Hobson
>>
>> Visithttp://www.**magpiesnestpublishing.co.uk/<http://www.magpiesnestpublishing.co.uk/>
>> <http://www.magpiesnestpublishing.co.uk/>for
>> books by acclaimed
>> author Gladys Hobson. Novels - poetry - short stories - ideal as
>> Christmas stocking fillers. Some available as e-books.
>>
>> ______________________________**_________________
>> dhcp-users mailing
>> listdhcp-users at lists.isc.orghttps://lists.isc.org/mailman/**listinfo/dhcp-users<https://lists.isc.org/mailman/listinfo/dhcp-users>
>> <https://lists.isc.org/mailman/listinfo/dhcp-users>
>>
>> _______________________________________________
>> dhcp-users mailing
>> listdhcp-users at lists.isc.orghttps://lists.isc.org/mailman/listinfo/dhcp-users
>>
>> _______________________________________________
>> dhcp-users mailing
>> listdhcp-users at lists.isc.orghttps://lists.isc.org/mailman/listinfo/dhcp-users
>>
>>
>> --
>> Best regards
>>
>> Sten Carlsen
>>
>> No improvements come from shouting:
>> "MALE BOVINE MANURE!!!"
>>
>>
>> _______________________________________________
>> 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
More information about the dhcp-users
mailing list