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: DHCPD Leases, no way to clean the file? (Simon)
2. Re: simple DHCPv6 config with /56-Prefix (Simon)
3. Re: simple DHCPv6 config with /56-Prefix (Adam Nielsen)
----------------------------------------------------------------------
Message: 1
Date: Sun, 21 Aug 2022 21:01:57 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCPD Leases, no way to clean the file?
Message-ID: <cd1f4720-0efb-4e1d-b91b-71f1c3b74...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Jorge Bastos <mysql.jo...@decimal.pt> wrote:
> I've started using DHCPD, and noticed that the lease file is not "cleaned",
> What I mean is, if some cliente request IP, and get .....11, and after two
> days/another time request again after the lease time ends, and the ......11
> is already in someone else, it will get a new IP, so far so good.
I assume here you mean the client gets an address xx.xx.xx.11 rather than it
gets 11 addresses ?
> But the lease file stays with the information about the old lease, aswell the
> new one.
It will have multiple entries for the same address for a short while - compile
time option, default is one hour between cleanups.
Each hour (default), the server will write out a fresh copy of the leases file
from it?s internal tables. This fresh copy will contain only the most recent
lease for each IP - it will not contain any older versions. Where your leases
file is stored, you?ll see both dhcpd.leases and dhcpd.leases~. The latter is
the previous leases file.
The process used is to write out the new file (to a different temporary file
name); iff that succeeds, then it will rename dhcpd.leases to dhcpd.leases~
(deleting the previous file named dhcpd.lease~), and rename the temporary new
file to dhcpd.leases. It is done this way so that no matter what happens (e.g.
disk full, server crash, power cut, whatever), you will not be left without a
valid leases file.
It may be that for some reason this process is failing (in which case your
leases file will continue to grow until the disk is full), it may be worth
looking into that.
But in normal operation, you should see older lease file entries disappear
after no more than one hour.
Simon
------------------------------
Message: 2
Date: Sun, 21 Aug 2022 21:14:06 +0100
From: Simon <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: simple DHCPv6 config with /56-Prefix
Message-ID: <d1b03aa7-668e-418a-a636-a5d246310...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Adam Nielsen <a.niel...@shikadi.net> wrote:
> Note that if you put all your DHCP clients in one /64 and your servers
> in another /64, all traffic between the two subnets will transit via
> your router. Assuming all machines are connected to the same switch
> this is quite inefficient, as all network traffic will be pushed
> through a single host (your router) even when the machines could
> have communicated with each other directly via the switch.
This is not true in the IPv6 world. All it needs is for a router to advertise
that both prefixes are on-link and the hosts can communicate directly. This is
one area where IPv6 is fundamentally different (better) than IPv4.
For completeness, a router can advertise that a prefix is not on-link - meaning
that communications between hosts in the same prefix must communicate via the
gateway. This can be the case in some non-broadcast networks, or networks where
device-device direct communications is blocked (e.g. for privacy/security in
public WiFi).
However ...
While you can use any prefix length you like, in practice there are many things
that won?t work properly in anything but a /64. If using DHCP* then you
possibly aren?t using SLAAC*, so this is somewhat more fluid, but I would work
on the assumption that sooner or later you?ll come across something that
assumes prefixes are never anything but /64 and breaks if even anything else.
* This will prevent Android devices using the network as Google (for
idealogical reasons) refuses to support DHCP, and not only doesn?t provide a
client, but actively blocks others from providing one.
Simon
------------------------------
Message: 3
Date: Mon, 22 Aug 2022 11:49:29 +1000
From: Adam Nielsen <a.niel...@shikadi.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: simple DHCPv6 config with /56-Prefix
Message-ID: <20220822114929.0932d...@vorticon.teln.shikadi.net>
Content-Type: text/plain; charset=US-ASCII
> This is not true in the IPv6 world. All it needs is for a router to
> advertise that both prefixes are on-link and the hosts can
> communicate directly. This is one area where IPv6 is fundamentally
> different (better) than IPv4. For completeness, a router can
> advertise that a prefix is not on-link - meaning that communications
> between hosts in the same prefix must communicate via the gateway.
> This can be the case in some non-broadcast networks, or networks
> where device-device direct communications is blocked (e.g. for
> privacy/security in public WiFi).
Very interesting, I didn't know that, thanks for the explanation!
BTW @Walter if you're reading this (presumably through the list
archives), your e-mail address is bouncing:
walte...@mathemainzel.info
all relevant MX records point to non-existent hosts
Cheers,
Adam.
------------------------------
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 166, Issue 7
******************************************
