Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: IPv4 Private Address Space (Bob Harold)
2. Re: dhcrelay prints these logs and doesn't live normally.
[Can't initialize context: not enough free resources.]
(glenn.satch...@uniq.com.au)
3. dhcrelay 4.1.1 IPv6 and multiple prefixes (Marc Haber)
----------------------------------------------------------------------
Message: 1
Date: Thu, 13 May 2021 09:43:56 -0400
From: Bob Harold <rharo...@umich.edu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: IPv4 Private Address Space
Message-ID:
<CA+nkc8A8iPsw_t6u4SCqCoa1ohTB42n=zcma7xvdsgx9wzv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
At the University of Michigan, the smaller DHCP servers use about 100mb of
ram for the dhcpd process. The largest servers use about 350mb ram to
serve 270,000 dynamic DHCP addresses.
So a difference of 250mb ram looks like about 1kb ram per IP address in the
DHCP ranges, would be my guess. (Did I get that right?)
--
Bob Harold
DNS and DHCP Hostmaster - UMNet
Information and Technology Services (ITS)
rharo...@umich.edu 734-512-7038
On Wed, May 12, 2021 at 3:06 PM Philippe Maechler <plcmaech...@gmail.com>
wrote:
> sorry to hijack this thread. i often read about the memory usage when one
> uses larger subnets/ranges.
>
> what are larger subnets?
>
> at $dayjob we use lots of /24, several hundreds /30 and about two dozens
> /20. the memory usage on a recent server is ignorable and the startup times
> are also way below one minute...
>
> how is it with dhcpv6? there we have even larger pools with ia-na, -pd and
> -ta. is the memory "setup" different?
>
> tia
> philippe
>
> Simon Hobson <dh...@thehobsons.co.uk> schrieb am Mi., 12. Mai 2021, 14:22:
>
>> Louis Garcia <louisg...@gmail.com> wrote:
>>
>> >> According to standards set forth in Internet Engineering Task Force
>> >> (IETF) document RFC-1918, the following IPv4 address ranges are
>> reserved by the IANA for private internets,
>> >>
>> >> 10.0.0.0/8 IP addresses: 10.0.0.0 ? 10.255.255.255
>> >> 172.16.0.0/12 IP addresses: 172.16.0.0 ? 172.31.255.255
>> >> 192.168.0.0/16 IP addresses: 192.168.0.0 ? 192.168.255.255
>>
>> Correct.
>> But just because 172.16.0.0/12 is reserved doesn't mean you have to use
>> all 1,048,576 addresses in that block, and you don't have to use /12 as
>> your mask. The /12 here simply tells you that everything from 172.16.0.0 to
>> 172.31.255.255 is in that reserved space.
>> The DHCP server will not allocate anything you haven't told it to, and
>> your border routers (and certainly your ISP) should be filtering any of
>> these RFC1918 address out - "nothing out, nothing in" should be the policy
>> for them.
>> Also, because of the way the server works, it's a really bad idea to
>> create large blocks (though I think relates to ranges, rather than subnets)
>> as it makes in-memory tables huge.
>>
>>
>> >> dhcpd does not seem to like subnet/mask combination.
>> >>
>> >> authoritative;
>> >> default-lease-time 600;
>> >> max-lease-time 7200;
>> >> subnet 172.16.4.0 netmask 255.240.0.0 {
>> >> option domain-name-servers 172.16.4.1;
>> >> option broadcast-address 172.31.255.255;
>> >> option routers 172.16.4.1;
>> >> option ntp-servers 172.16.4.1;
>> >> range 172.16.4.50 172.16.4.254;
>> >> }
>>
>> Yes, as already mentioned, that's not a valid address & mask.
>>
>>
>> > Currently I have three networks 172.16.2.0/24 172.16.3.0/24
>> > 172.16.4.0/24. I read that not all of 172.16.0.0 is private, only
>> > 172.16.0.0/12. I am trying to not have public routable IPs on my
>> > network. Please let me know if this setup is fine.
>> >
>> > # DHCP Server Configuration file.
>> >
>> > authoritative;
>> > default-lease-time 600;
>> > max-lease-time 7200;
>> >
>> > # Client system architecture type: RFC4578
>> > option arch code 93 = unsigned integer 16;
>> >
>> > subnet 172.16.2.0 netmask 255.255.255.0 {
>> > option domain-name-servers 172.16.2.1;
>> > option broadcast-address 172.16.2.255;
>> > option routers 172.16.2.1;
>> > option ntp-servers 172.16.2.1;
>> > range 172.16.2.50 172.16.2.254;
>> > if option arch = 00:07 {
>> > filename "/grub/shim.efi";
>> > }
>> > next-server 172.16.2.5;
>> > }
>> >
>> > subnet 172.16.3.0 netmask 255.255.255.0 {
>> > option domain-name-servers 172.16.3.1;
>> > option broadcast-address 172.16.3.255;
>> > option routers 172.16.3.1;
>> > option ntp-servers 172.16.3.1;
>> > range 172.16.3.50 172.16.3.254;
>> > }
>> >
>> > subnet 172.16.4.0 netmask 255.255.255.0 {
>> > option domain-name-servers 172.16.4.1;
>> > option broadcast-address 172.16.4.255;
>> > option routers 172.16.4.1;
>> > option ntp-servers 172.16.4.1;
>> > range 172.16.4.50 172.16.4.254;
>> > }
>>
>> Yes, that's just fine.
>>
>>
>>
>> Simon
>>
>> _______________________________________________
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>>
>> dhcp-users mailing list
>> dhcp-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users@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/20210513/4a24724c/attachment-0001.htm>
------------------------------
Message: 2
Date: Fri, 14 May 2021 17:07:17 +1000
From: glenn.satch...@uniq.com.au
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: dhcrelay prints these logs and doesn't live normally.
[Can't initialize context: not enough free resources.]
Message-ID: <8fab903481e1855864acb808ad737...@uniq.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Sounds like you don't have enough free memory for it to run. Try running
"free -h" to see if you have enough memory available. You may need to
shut down some other services first.
Secondly be sure you are running as root, it may be getting a permission
denied message from some underlying system call.
regards,
Glenn
On 2021-05-13 17:28, ??? wrote:
> Hi, all.
>
> It's my first time using this email list, so please understand that
> I'm not familiar with it.
>
> dhcp version is 4.2.6.
>
> The dhcrelay daemon does not live normally, printing the message
> below.
>
> Why this problem happend? Which part should I check?
>
> Does anyone know what problems can cause this kind of message?
>
> => daemon.err>dhcrelay: Can't initialize context: not enough free
> resources
>
> Thanks.
>
> pkd.
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 3
Date: Fri, 14 May 2021 09:53:41 +0200
From: Marc Haber <mh+dhcp-us...@zugschlus.de>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: dhcrelay 4.1.1 IPv6 and multiple prefixes
Message-ID: <yj4shwxrsganq...@torres.zugschlus.de>
Content-Type: text/plain; charset=utf-8
Hi,
I have a Linux-based IP router that has caters for multiple IPv6
prefixes. If it matters, one of the prefixes comes in via prefix
delegation using systemd-networkd and changes ever 24 hours. The other
prefix comes in via OpenVPN and is statically configured. For the static
prefix, DHCPv6 is in use; the DHCP server does not run on the router
itself. Instead, dhcrelay is used.
The server is on Interface int181; a test client is on Interface int182.
int182 has an IP address from both prefixes while int181 just has one IP
address from the static prefix.
Before the dynamic prefix was added, this was working fine with the
dhcrelay command line
/usr/sbin/dhcrelay -d -6 -u int181 -l int181 -l int182
This stopped working when the dynamic prefix was added, the relay
doesn't forward the requests to the server on int181.
The man page says:
| -l [address%]ifname[#index]
| Specifies the ``lower'' network interface for DHCPv6 relay
| mode: the interface on which queries will be received from
| clients or from other relay agents. At least one -l option
| must be included in the command line when running in DHCPv6
| mode. The interface name ifname is a mandatory parameter.
| The link address can be specified by address%; if it isn't,
| dhcrelay will use the first non-link-local address configured
| on the interface. The optional #index parameter specifies the
| interface index.
Since the first non-link-local address on int182 is the address from the
DHCP-less dynamic prefix, I suspect this might be the issue here.
And, indeed,
/usr/sbin/dhcrelay -d -6 -u int181 -l int181 -l
2001:db8:42bc:a182::70:100%int182
that is, giving the address for the lower interface explicitly, seems to
make DHCPv6 work again.
However, i have two issues that I am not sure whether things are ok here
or not:
(1) The parameters don't show up properly in the process list:
[5/4996]mh@prom:~ $ pgrep --list-full dhcrelay
363071 /usr/sbin/dhcrelay -d -6 -u int181 -l int181 -l
2001:db8:42bc:a182::70:100 int182 -l int183 -l int188 -l int196 -l unt381 -l
unt383
[6/4997]mh@prom:~ $
note the missing "%" between the explicitly given IP address and the
interface name. I have checked that the % is present in the execve call
that actually invokes dhcrelay, so that gets lost somewhere inside the
ISC code.
And,
(2) adding the IP address to the upper interface breaks DHCPv6
/usr/sbin/dhcrelay -d -6 -u 2001:db8:42bc:a181::70:100%int181 -l
2001:db8:42bc:a181::70:100%int181 -l 2001:db8:42bc:a182::70:100%int182
with this command line, dhcrelay doesn't relay requests any more. In the
current setup, lucky me doesn't need the IP address explicitly set for
the upper interface, but in the near future, an address from the dynamic
prefix will be added to int181 as well, and this will make it necessary
to add the IP address for the upper interface as well.
Are those two things genuine issues in dhcrelay, or am I doing things
wrong?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 151, Issue 6
******************************************
