Optimale DHCP scope

[deHakkelaar]

Ik heb een aantal keren gezien dat DHCP server howtos een relatief kleine scope configureren.
Bv maar 50 of 100 adressen op een /24 subnet.

Is er een nadeel als je deze scope vergroot naar bv 200 adressen op een /24 subnet?
Of mogelijk een andere reden?

Volgens mijn redenering zou ik juist die scope zo groot mogelijk maken ivm met onder wat veel DHCP server implementaties vaak default doen OOTB:

$ man dnsmasq
[..]
       --dhcp-sequential-ip
              Dnsmasq  is designed to choose IP addresses for DHCP clients us-
              ing a hash of the client's MAC address. This normally  allows  a
              client's  address to remain stable long-term, even if the client
              sometimes allows its DHCP lease to expire. In this default  mode
              IP  addresses  are  distributed  pseudo-randomly over the entire
              available address range. There are sometimes circumstances (typ-
              ically server deployment) where it is more convenient to have IP
              addresses  allocated  sequentially,  starting  from  the  lowest
              available address, and setting this flag enables this mode. Note
              that in the sequential mode, clients which allow a lease to  ex-
              pire are much more likely to move IP address; for this reason it
              should not be generally used.

Dan is de kans veel groter dat het uitgedeelde IP uniek blijft.
Natuurlijk afhankelijk van hoeveel clients je hebt verbonden

Snelle DDG voor howto's met veel kleinere scopes dan mogelijk:
https://www.baeldung.com/linux/install-configure-dhcp-server
https://learn.microsoft.c...cp-server?tabs=powershell
https://www.linuxfordevic...ntu/dhcp-server-on-ubuntu

[The Realone]

Een /24 wordt vaak gebruikt vanwege het gemak en een scope maak je zo groot als je nodig denkt te hebben. Als je maar max 50 DHCP clients denkt te moeten voorzien van een adres, dan heeft een pool van 200 natuurlijk weinig zin, maar kwaad kan het ook weer niet zolang het je eventuele logische static assignments niet in de weg zit.

Een voorbeeld is als je naast je DHCP pool voor het gemak bepaalde static ranges wilt gebruiken. Zoals x.x.x.10 - .19 voor servers, x.x.x.20 - .29 voor netwerk spul, etc. Dan kan een grote pool je al gauw in de weg gaan zitten.

Technisch gezien maakt het allemaal niks uit, doen wat je zelf prettig vindt. En als je DHCP adressen consistent wilt houden dien je reservations te gebruiken.

[CyBeR]

deHakkelaar schreef op dinsdag 14 mei 2024 @ 01:40:
Is er een nadeel als je deze scope vergroot naar bv 200 adressen op een /24 subnet?

Nee.

Of mogelijk een andere reden?

Je hebt minder ruimte voor statische addressering, maar verder is er geen reden om zo'n kleine range in te stellen. Je moet het ook instellen zoals je het nodig hebt: als jij 40 statische adressen nodig hebt (die je niet via DHCP uit wilt delen), dan moet je natuurlijk niet 10-250 in je DHCP range zetten want dan kom je er 26 tekort.

[deHakkelaar]

The Realone schreef op dinsdag 14 mei 2024 @ 02:04:
En als je DHCP adressen consistent wilt houden dien je reservations te gebruiken.

Bedankt maar voor mijn netwerk zijn statische DHCP reserveringen overbodig vanwege die deterministische uitgave van IP adressen omschreven in de dnsmasq man page..
De weinige clients op mijn thuis netwerk krijgen elke keer hetzelfde IP toegewezen.
Geen extra werk voor nodig.

[ Voor 4% gewijzigd door deHakkelaar op 14-05-2024 02:14 ]

[Room42]

deHakkelaar schreef op dinsdag 14 mei 2024 @ 02:12:
[...]

Bedankt maar voor mijn netwerk zijn statische DHCP reserveringen overbodig vanwege die deterministische uitgave van IP adressen omschreven in de dnsmasq man page..
De weinige clients op mijn thuis netwerk krijgen elke keer hetzelfde IP toegewezen.
Geen extra werk voor nodig.

Prima, maar dan accepteer je dus mogelijke inconsistentie als er een lease verlopen is waardoor een andere client dat IP-adres weer kan krijgen en de originele client een nieuw, uniek adres zal krijgen.

Het is hacky, maar je zou nog de lease naar erg lang kunnen configureren om bovenstaande risico te verkleinen.

edit:

En zo te lezen is die dnsmasq-optie ook een aanvullende maatregel maar nog steeds geen garantie.

[ Voor 6% gewijzigd door Room42 op 14-05-2024 02:19 ]

[deHakkelaar]

@Room42 , eens.
Maar acht de kans heel heel klein met een 200 scope dat een andere client een al eerder uitgedeeld adres in pikt.
En mij maakt het IP vaak ook niks uit omdat ik alles met hostnamen verbind.

Maar dit is niet relevant voor de vraag die ik stelde

[deHakkelaar]

Room42 schreef op dinsdag 14 mei 2024 @ 02:17:

edit:

En zo te lezen is die dnsmasq-optie ook een aanvullende maatregel maar nog steeds geen garantie.

De dnsmasq default is dit:

Dnsmasq is designed to choose IP addresses for DHCP clients using a hash of the client's MAC address.
In this default mode IP addresses are distributed pseudo-randomly over the entire available address range.

En volgens mij doet de MS DHCP service hetzelfde.

[ Voor 11% gewijzigd door deHakkelaar op 14-05-2024 02:32 ]

[Room42]

deHakkelaar schreef op dinsdag 14 mei 2024 @ 02:22:
@Room42 , eens.
[...]

Maar dit is niet relevant voor de vraag die ik stelde

Is er een nadeel als je deze scope vergroot naar bv 200 adressen op een /24 subnet?

Heel concreet antwoord op deze vraag is dat het (enige) nadeel is dat je minder (max 52) vaste IP-adressen kunt vastleggen. Verder maakt het niks uit, in een thuisnetwerk.

[CyBeR]

deHakkelaar schreef op dinsdag 14 mei 2024 @ 02:22:
@Room42 , eens.
Maar acht de kans heel heel klein met een 200 scope dat een andere client een al eerder uitgedeeld adres in pikt.
En mij maakt het IP vaak ook niks uit omdat ik alles met hostnamen verbind.

Maar dit is niet relevant voor de vraag die ik stelde

Het is natuurlijk mogelijk, met maar ~250 mogelijkheden, dat de MAC-gebaseerde hash-functie op hetzelfde antwoord uitkomt voor twee (of meer) hosts, en die kunnen elkaar's IP dan afpakken.

Als je zéker wilt weten dat een host altijd hetzelfde IP krijgt (of een 'mooi' IP, bv .10 ofzo), even een reservering maken. Als je dat niet zo boeit, lekker laten gaan.

[deHakkelaar]

@CyBeR , die hashing is niet zozeer de vraag.
Meer waarom zo'n kleine poel?

Nog een nadeel als die poel zo klein is waardoor mogelijk client IP's kunnen veranderen, clients onthouden vaak hun eerder toegewezen IP en vragen deze als eerste aan de DHCP service.
Het "Preferred" vlaggetje in output onder:

C:\>ipconfig /all
[..]
   IPv4 Address. . . . . . . . . . . : 10.0.0.23(Preferred)

Als hij deze niet krijgt toegewezen is er extra netwerk verkeer nodig voordat een ander IP kan worden ACKNOWLEDGED.
Tis weinig maar toch

Ow en ik heb mijn clients nog niet zien IP hoppen.

[ Voor 6% gewijzigd door deHakkelaar op 14-05-2024 02:58 . Reden: + wiki ]

[lier]

deHakkelaar schreef op dinsdag 14 mei 2024 @ 01:40:
Dan is de kans veel groter dat het uitgedeelde IP uniek blijft.

Is dat belangrijk/gewenst?

[Frogmen]

Veel is ook historisch zo ontstaan in een tijd dat processoren een stuk minder krachtig waren en je de ARP tabel liever klein hield. Tegenwoordig speelt dit eigenlijk niet meer. Vroeger keek je dus naar het max aantal theoretisch nodig en daar ging je iets boven zitten met een korte TTL als je veel wisselingen had.

[Yariva]

Frogmen schreef op dinsdag 14 mei 2024 @ 09:03:
Veel is ook historisch zo ontstaan in een tijd dat processoren een stuk minder krachtig waren en je de ARP tabel liever klein hield. Tegenwoordig speelt dit eigenlijk niet meer. Vroeger keek je dus naar het max aantal theoretisch nodig en daar ging je iets boven zitten met een korte TTL als je veel wisselingen had.

Eens. Tegenwoordig configureer / kom ik vaak genoeg grotere netwerken tegen met een /22. Zelfs met mobiele apparatuur zijn die broadcasts geen probleem (los van het feit dat degelijke enterprise apparatuur hun eigen implementatie hebben van broadcast / multicast pakketten verwerken. Dan kan je gaan spelen met /16 blokjes voor bijv. een groot stadion van guest wifi voorzien.)

deHakkelaar schreef op dinsdag 14 mei 2024 @ 02:54:
....
Meer waarom zo'n kleine poel?
......

Waarom een veel te grote poel? Je kan je thuisnetwerk ook wel gaan subnetten voor 32K clients maar als ik maar 7 apparaten in huis heb is dat natuurlijk super overkill. Het is nette digitale hygiene om een netwerk te sizen a.d.v. requirements. Dan is een DHCP pool van 1K clients voor bijv. een verwachte max / piek van 60 gebruikers veel te groot.

deHakkelaar schreef op dinsdag 14 mei 2024 @ 02:54:
....
Nog een nadeel als die poel zo klein is waardoor mogelijk client IP's kunnen veranderen, clients onthouden vaak hun eerder toegewezen IP en vragen deze als eerste aan de DHCP service.

Clients onthouden niks tenzij statisch. Clients zullen bij opstarten altijd een DHCP discover sturen. Dat de DHCP server vervolgens nog een oude lease van bijv. 48 uur in de database heeft en het MAC adres op die manier kan voorzien van het zelfde adres klopt. Maar dat is logica welke op de server plaatsvindt, niet op de client. Probeer maar eens een client uit te zetten en daarna de DHCP lease tabel / database te legen op de DHCP server. Grote kans dat de client een ander IP adres krijgt wanneer deze opnieuw opstart (mits het geen DHCP reservering betreft.)

[ Voor 45% gewijzigd door Yariva op 14-05-2024 09:34 ]

[dion_b]

Frogmen schreef op dinsdag 14 mei 2024 @ 09:03:
Veel is ook historisch zo ontstaan in een tijd dat processoren een stuk minder krachtig waren en je de ARP tabel liever klein hield. Tegenwoordig speelt dit eigenlijk niet meer. Vroeger keek je dus naar het max aantal theoretisch nodig en daar ging je iets boven zitten met een korte TTL als je veel wisselingen had.

Wat ook meespeelt is dat mensen best practices van publieke IP adressering overnam op private ranges. Bij publieke IP moet je zo efficient mogelijk omgaan met je schaarse address space en is er dus flinke druk om zo atomair mogelijk te provisionen. Dat dit de administratie een crime maakt en continu risico op lege pools met zich mee brengt is dan maar zo.

Als je dat op private addressering kopieert krijg je dus ook allemaal /25 ranges, terwijl je in de meeste organisaties nooit ook maar in de buurt komt van grenzen van private addressing. _{Heb in m'n hele carriere een keer gezien dat iets gesegmenteerd moest worden omdat een /8 vol liep, maar dat was ook gevolg van schromelijke inefficientie, niet van daadwerkelijk opmaken van 16M adressen}

[Ben(V)]

Een grote dhcp scope heeft geen nadelig gevolg dus kan prima.

Maar het feit dat jij een grote dhcp scope wil duid er volgens mij op dat je ofwel een oplossing zoekt voor een probleem dat niet betstaat ofwel echt een probleem hebt omdat je verwacht dat device altijd hetzelfde ipadres krijgen van een dhcp server en dat niet het geval is.
Er op vertrouwen dat dit laatste het geval is zou ik zeker niet doen.

Een dhcp client vraag gewoon een ipadres aan bij de dhcp server en onthoud helemaal niet zijn oude ipadres.
Dat gebeurd enkel als hij aan blijft staan en hij halverwege de leasetijd een "renew" aanvraagt, dan houd hij dat adres gewoon.
Heel veel dhcp servers delen gewoon het laagste vrije ipadres uit, maar er zijn er ook die een tabel bijhouden en kijken of het oude adres nog vrij is.
Maar als dat inmiddels is uitgegeven dan krijgt hij gewoon een ander.
Er is nergens gedefinieerd hoe het een en ander moet, enkel dat er een vrij ipadres uitgegeven wordt dus dit soort zaken verschillen per dhcp server implementatie.

[deHakkelaar]

lier schreef op dinsdag 14 mei 2024 @ 08:32:
[...]

Is dat belangrijk/gewenst?

Niet perse.

[deHakkelaar]

Yariva schreef op dinsdag 14 mei 2024 @ 09:25:
Clients onthouden niks tenzij statisch. Clients zullen bij opstarten altijd een DHCP discover sturen. Dat de DHCP server vervolgens nog een oude lease van bijv. 48 uur in de database heeft en het MAC adres op die manier kan voorzien van het zelfde adres klopt. Maar dat is logica welke op de server plaatsvindt, niet op de client. Probeer maar eens een client uit te zetten en daarna de DHCP lease tabel / database te legen op de DHCP server. Grote kans dat de client een ander IP adres krijgt wanneer deze opnieuw opstart (mits het geen DHCP reservering betreft.)

Ben(V) schreef op dinsdag 14 mei 2024 @ 09:36:
Een dhcp client vraag gewoon een ipadres aan bij de dhcp server en onthoud helemaal niet zijn oude ipadres.
Dat gebeurd enkel als hij aan blijft staan en hij halverwege de leasetijd een "renew" aanvraagt, dan houd hij dat adres gewoon.
Heel veel dhcp servers delen gewoon het laagste vrije ipadres uit, maar er zijn er ook die een tabel bijhouden en kijken of het oude adres nog vrij is.

Dit is wat er gebeurt als ik op m'n mobieltje de vliegtuig modes toggle:

pi@ph5a:~ $ sudo tcpdump -ntvvvi any udp port 67 or udp port 68
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 336)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 0c:2f:b0:XX:XX:XX, length 308, xid 0xac6549ab, Flags [none] (0x0000)
[..]
            Requested-IP Option 50, length 4: 10.0.0.143

De client vraagt daar met een DISCOVERY broadcast aan de DHCP server om z'n oude (EDIT: Preferred) IP 10.0.0.143.

En nee mijn DHCP service onthoud geen oude verlopen leases, er is geen DB/tabel of iets dergelijks.
Alleen de huidige aktieve leases worden opgeslagen naar disk.
Het is puur en alleen de hashing die er voor zorgt dat de clients elke keer hetzelfde IP krijgen toegewezen.

[Yariva]

deHakkelaar schreef op dinsdag 14 mei 2024 @ 12:24:
[...]


[...]

Dit is wat er gebeurt als ik op m'n mobieltje de vliegtuig modes toggle:

pi@ph5a:~ $ sudo tcpdump -ntvvvi any udp port 67 or udp port 68
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 336)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 0c:2f:b0:XX:XX:XX, length 308, xid 0xac6549ab, Flags [none] (0x0000)
[..]
            Requested-IP Option 50, length 4: 10.0.0.143

De client vraagt daar met een DISCOVERY broadcast aan de DHCP server om z'n oude (EDIT: Preferred) IP 10.0.0.143.

En nee mijn DHCP service onthoud geen oude verlopen leases, er is geen DB/tabel of iets dergelijks.
Alleen de huidige aktieve leases worden opgeslagen naar disk.
Het is puur en alleen de hashing die er voor zorgt dat de clients elke keer hetzelfde IP krijgen toegewezen.

toon volledige bericht

Dit klopt, maar wat jij omschrijft is geen herstart. Dit is tijdelijk een adapter softwarematig uit / inschakelen. Een preferred adres constructie gebeurd voornamelijk wanneer een DHCP lease afloopt. Dan zal de client inderdaad een preferred adres meegeven zodat communicatie niet zomaar verbreekt.

Echter met een volledige herstart start het OS opnieuw zonder enig weten aan welk netwerk deze is gekoppeld. In dit scenario zal DHCP geen preferred adres mee geven.

Hoe je dit ook kan zien is door met je telefoon tijdelijk te verbinden naar een ander netwerk en vervolgens terug te vallen op het eerste netwerk. Ook in deze situatie zal de DHCP server bepalen wat er gebeurd zonder preferred adres. Ik ga er tenminste niet vanuit dat een telefoon een lijst van IP adressen onthoudt van de afgelopen x AP's waarmee deze is verbonden

[deHakkelaar]

@Yariva , heb ik eerder een herstart omschreven dan?

Ik weet niet hoe ik het duidelijker kan maken.
De vliegtuig modes is niks sofwarematig,.
Alle radios worden hardwarematig uitgeschakeld (wifi, bluetooth etc).
Net alsof je het mobieltje loskoppelt van het netwerk en later weer laten
verbinden zoals bv als je buiten de deur bent geweest.

En nee ik heb geen andere wifi waar ik ff mee kan verbinden om daarna weer
terug te hoppen.
Dus ik weet niet ofdat er een IP lijst wordt bijgehouden op de clients voor verschillende netwerken.

Maar onder is de eerste DISCOVER van een Linux VM die ik een koude herstart heb gegeven:

pi@ph5a:~ $ sudo tcpdump -nvvvi eth0 udp port 67 or udp port 68 and ether host 00:16:3e:XX:XX:XX
[..]
13:32:35.367303 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:16:3e:XX:XX:XX, length 300, xid 0x4cacd34, Flags [none] (0x0000)
[..]
            Requested-IP Option 50, length 4: 10.0.0.145

Dus ja zelfs als je een PC uitschakelt onthoud hij z'n laatste IP (10.0.0.145 voor deze client/VM).

EDIT:

$ man dhclient
[..]
FILES
       /sbin/dhclient-script,                         /etc/dhcp/dhclient.conf,
       /var/lib/dhcp/dhclient.leases,                   /var/run/dhclient.pid,
       /var/lib/dhcp/dhclient.leases~.

Het /var/lib/dhcp/dhclient.leases bestandje op die client VM staat bij mij vol met ook oude leases:

$ cat /var/lib/dhcp/dhclient.leases
lease {
  interface "eth0";
  fixed-address 10.0.0.145;
  option subnet-mask 255.255.255.0;
  option routers 10.0.0.1;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option domain-name-servers 10.0.0.2,10.0.0.4;
  option dhcp-server-identifier 10.0.0.2;
  option dhcp-renewal-time 37963;
  option ntp-servers 10.0.0.3;
  option broadcast-address 10.0.0.255;
  option dhcp-rebinding-time 70363;
  option host-name "hak01";
  option domain-name "home.dehakkelaar.nl";
  renew 6 2024/02/03 20:36:04;
  rebind 0 2024/02/04 07:22:46;
  expire 0 2024/02/04 11:50:03;
}
lease {
  interface "eth0";
  fixed-address 10.0.0.145;
  option subnet-mask 255.255.255.0;
  option routers 10.0.0.1;
  option dhcp-lease-time 86400;
[..]

[ Voor 33% gewijzigd door deHakkelaar op 14-05-2024 13:59 ]

[DataGhost]

deHakkelaar schreef op dinsdag 14 mei 2024 @ 01:40:
Volgens mijn redenering zou ik juist die scope zo groot mogelijk maken ivm met onder wat veel DHCP server implementaties vaak default doen OOTB:

$ man dnsmasq
[..]
       --dhcp-sequential-ip
              [..] even if the client
              sometimes allows its DHCP lease to expire. [..] Note
              that in the sequential mode, clients which allow a lease to  ex-
              pire are much more likely to move IP address; for this reason it
              should not be generally used.

De redenering die hierin staat lijkt vooral te zijn voor clients die hun lease laten verlopen, dat is natuurlijk dom en ik weet niet of je zulke clients in je netwerk moet willen hebben. Ook vraag ik me af of dat anno 2024 nog een probleem is, DHCP is niet bepaald een nieuwe, onbekende techniek. Maar goed, je kan kijken of jij en je devices hier last van hebben. Ik gok van niet, dus dan kan je het lekker negeren. Er zijn zat DHCP-implementaties in algemeen gebruik die gewoon sequentieel adressen uitdelen zonder enige issues, bijv. fritz-apparatuur, experiaboxen (laatste keer dat ik keek) en dat soort dingen.

Dan is de kans veel groter dat het uitgedeelde IP uniek blijft.

Statisch bedoel je, ze zijn altijd uniek anders is je DHCP-server kapot. Maar heb je een bepaalde usecase voor statische adressen dan? Of niet echt? Zelfs als je je hosts graag op een bepaalde uniforme manier wilt kunnen bereiken lukt dat hiermee niet, want als je device A offline is (en de lease verlopen) terwijl een ander device B online komt en toevallig naar datzelfde IP hasht, zal je A niet meer kunnen bereiken op dat IP, want dat is nu van B en als A online komt zal het toch een ander IP toegewezen (moeten) krijgen. Dus inderdaad, het is slechts een kans dat het blijft werken.

Maar je moet helemaal niet met IP's aan de slag willen. Wat wel werkt, en ook blijft werken, is DNS. Volgens mij doen de meeste consumentendevices dit al helemaal prima en als je zelf iets in elkaar knutselt is het een klein beetje extra werk, maar met DNS kan je je device gewoon bereiken op de hostname ervan, zonder dat het uitmaakt wat voor IP je device heeft gekregen en hoe vaak dat wisselt. Volgens mij gaat dat met mDNS zelfs autogratisch. En op dat moment maakt het dus ook niet meer uit hoe groot je DHCP-pool is en op wat voor manier de adressen erin uitgedeeld worden. Dan hoef je alleen nog maar te zorgen dat de pool groot genoeg is voor het aantal devices wat je hebt, verder hoef je je nergens druk over te maken.

[DataGhost]

deHakkelaar schreef op dinsdag 14 mei 2024 @ 02:22:
@Room42 , eens.
Maar acht de kans heel heel klein met een 200 scope dat een andere client een al eerder uitgedeeld adres in pikt.
En mij maakt het IP vaak ook niks uit omdat ik alles met hostnamen verbind.

Maar dit is niet relevant voor de vraag die ik stelde

Die kans is ironisch gezien kleiner als je sequentieel adressen uitdeelt, omdat het dan pas gebeurt als er minimaal [groottevanjerange] verschillende devices op je netwerk hebben gezeten. Met de hashing-methode kan je bij 2 devices al een collision krijgen die ervoor kan zorgen dat op een gegeven moment je "IP-plan"
niet meer "klopt". Als een IP per se statisch moet blijven: statisch toewijzen. Maar beter is dus gewoon DNS.

[Ben(V)]

Geen idee welke Dhcp server jij gebruikt maar ze zijn echt niet allemaal met Dnsmasq opgebouwd.
Maar al zou je dhcp server proberen met behulp van het macadres dan kan dat ipadres inmiddels al uitgegeven zijn en krijg je alsnog een nieuw ipadres.

En het is ook helemaal niet nodig dat de dhcp server dat probeert, een dhcp client zal halverwege het verloop van zijn leasetijd een renew aanvragen waardoor de leasetijd opnieuw start.
Als dat niet lukt blijft die client de renew porberen tot de hele leasetijd verlopen is dan zal hij zijn ipadres opgeven.

[deHakkelaar]

DataGhost schreef op dinsdag 14 mei 2024 @ 13:53:
De redenering die hierin staat lijkt vooral te zijn voor clients die hun lease laten verlopen, dat is natuurlijk dom en ik weet niet of je zulke clients in je netwerk moet willen hebben.

Heb jij geen apparaten dan die langer uitstaan als de lease periode (meestal 12 of 24 uur)?
Ik wel namelijk.

DataGhost schreef op dinsdag 14 mei 2024 @ 13:53:
Er zijn zat DHCP-implementaties in algemeen gebruik die gewoon sequentieel adressen uitdelen zonder enige issues, bijv. fritz-apparatuur, experiaboxen (laatste keer dat ik keek) en dat soort dingen.

Over Experiabox heb ik een vermoeden dat deze ook dnsmasq draait als backen met dat default hashen.
Net als heel heel veel ander consumenten spul.

DataGhost schreef op dinsdag 14 mei 2024 @ 13:53:
Statisch bedoel je, ze zijn altijd uniek anders is je DHCP-server kapot.

Ja ik bedoel dat ze uniek blijven voor de desbetreffende client.

DataGhost schreef op dinsdag 14 mei 2024 @ 13:53:
Zelfs als je je hosts graag op een bepaalde uniforme manier wilt kunnen bereiken lukt dat hiermee niet, want als je device A offline is (en de lease verlopen) terwijl een ander device B online komt en toevallig naar datzelfde IP hasht, zal je A niet meer kunnen bereiken op dat IP, want dat is nu van B en als A online komt zal het toch een ander IP toegewezen (moeten) krijgen. Dus inderdaad, het is slechts een kans dat het blijft werken.

Die kans is heel heel klein voor een thuis netwerk en een zo groot mogelijke poel.
Bij mij is het nog niet opgetreden.

DataGhost schreef op dinsdag 14 mei 2024 @ 13:53:
Volgens mij doen de meeste consumentendevices dit al helemaal prima en als je zelf iets in elkaar knutselt is het een klein beetje extra werk, maar met DNS kan je je device gewoon bereiken op de hostname ervan, zonder dat het uitmaakt wat voor IP je device heeft gekregen en hoe vaak dat wisselt. V

Ik heb hier m'n eigen DHCP en DNS service draaien in de vorm van een Pi-hole node.
Twee om precies te zijn.
En ik ben het helemaal eens dat je op DNS hostnamen moet adresseren ipv IP's.
Maar voor m'n gevoel vind ik het netter als de IP's niet veranderen zonder er teveel werk van te maken zoals bv reserveringen.

[deHakkelaar]

Ben(V) schreef op dinsdag 14 mei 2024 @ 14:03:
Geen idee welke Dhcp server jij gebruikt maar ze zijn echt niet allemaal met Dnsmasq opgebouwd.
opgeven.

Wij hebben deze discussie eerder gehad.
Welk gedeelte van onder is onduidelijk?

Consequently, it "is present in a lot of home routers and certain Internet of Things gadgets"[4] and is included in Android.

Wikipedia: dnsmasq

Zie ook m'n vorige bericht.

[deHakkelaar]

MS DHCP:

Each DHCP server on receiving the client request calculates hash of the MAC address in the client request as per hashing algorithm specified in RFC 3074. Each server hashes any MAC address to a value between 1 and 256.

https://community.spicewo...ver-not-leasing-addresses

[deHakkelaar]

ISC DHCP:

The DHCP server generates the list of available IP addresses from a hash table. This
means that the addresses are not sorted in any particular order, and so it is not possible
to predict the order in which the DHCP server will allocate IP addresses. Users of
previous versions of the ISC DHCP server may have become accustomed to the DHCP server
allocating IP addresses in ascending order, but this is no longer possible, and there is
no way to configure this behavior with version 3 of the ISC DHCP server.

https://manpages.ubuntu.c...en/man5/dhcpd.conf.5.html

[ Voor 73% gewijzigd door deHakkelaar op 14-05-2024 14:35 . Reden: verkeerde link ]

[DataGhost]

deHakkelaar schreef op dinsdag 14 mei 2024 @ 14:18:
[...]

Heb jij geen apparaten dan die langer uitstaan als de lease periode (meestal 12 of 24 uur)?
Ik wel namelijk.

Jawel, maar het is een beetje onduidelijk verwoord in de manpage gok ik. Hoe dan ook maakt het voor de werking van een device in principe niet uit welk IP het heeft gekregen.

[...]

Over Experiabox heb ik een vermoeden dat deze ook dnsmasq draait als backen met dat default hashen.
Net als heel heel veel ander consumenten spul.

Ik meen me te herinneren de laatste keer dat ik zo'n Experiabox zag er gewoon sequentieel adressen werden uitgedeeld, maar goed, dat is ondertussen zo'n drie jaar geleden. De fritzbox daarna en ook mijn huidige fritzbox (4060) delen gewoon sequentieel IPtjes uit, of het moet wel erg toevallig zijn dat alle devices op mijn netwerk hashen naar <x.x.x.60 in een DHCP-range die tot van 20 tot 200 gaat, en dan ook nog eens op volgorde van aansluiten.

[...]

Ja ik bedoel dat ze uniek blijven voor de desbetreffende client.

Dat krijgen ze dus niet want als jij twee clients hebt die allebei naar X hashen en ze komen tegelijkertijd online, hasht er eentje naar Y, dus dat is niet uniek. Static is het ook niet want als ze vervolgens beide hun lease laten verlopen en je laat die die Y had als eerste online komen krijgt die X en zijn ze omgewisseld.

[...]

Die kans is heel heel klein voor een thuis netwerk en een zo groot mogelijke poel.
Bij mij is het nog niet opgetreden.

Bij sequentieel uitdelen is de kans nul, zolang jij niet meer unieke devices online hebt gehad dan je pool groot is. Niet dat ik ervan afhankelijk ben maar als mijn devices heel lang offline zijn geweest krijgen ze gewoon hun IP weer terug, ook al bestaat er een device op het netwerk wat anderszins met de hash-methode het IP ingepikt zou hebben.

[...]

Ik heb hier m'n eigen DHCP en DNS service draaien in de vorm van een Pi-hole node.
Twee om precies te zijn.
En ik ben het helemaal eens dat je op DNS hostnamen moet adresseren ipv IP's.
Maar voor m'n gevoel vind ik het netter als de IP's niet veranderen.

Dan is er toch geen probleem? Dat gevoel moet je gewoon snel van af stappen, dat maakt het echt ontzettend veel makkelijker voor je. Dan kan je namelijk ook gewoon IP's veranderen mocht je bijvoorbeeld een keer een ander subnet in willen stellen, zonder dat je op alles wat ervan afhankelijk is de verwijzingen naar de IP's (waarvan jij hoopt dat ze static zijn) moet gaan lopen aanpassen. Als je toch om wat voor reden dan ook vast wilt blijven houden aan je hash-manier zou ik snel je netwerk hernummeren naar 10.0.0.0/8, dan kan je een pool maken van zo'n 16 miljoen IP's zodat de kans op collisions zo klein mogelijk is.

En dus nogmaals, met de hashingmethode is de kans juist groter dat je IP's wel veranderen dan wanneer je ze sequentieel uitdeelt, waarbij ze in principe niet veranderen als je pool groot genoeg is. Moet je DHCP-server wel de historisch uitgedeelde leases onthouden ja, maar dat kan je gewoon instellen. Of je maakt je lease duration gewoon een paar jaar, dan gaat het probleem ook weg (totdat je pool vol zit) (oja doe dit gewoon niet).

dnsmasq
MS DHCP
ISC DHCP

Leuk dat ze het zo doen, maar dat neemt niet weg dat je slechts een kans hebt hetzelfde IP te behouden, geen garantie. Wil je per se hetzelfde IP behouden maak je een static lease, wil je simpelweg altijd hetzelfde device met dezelfde identifier kunnen bereiken gebruik je DNS.

[ Voor 10% gewijzigd door DataGhost op 14-05-2024 14:44 ]

[deHakkelaar]

Nogmaals:

This normally allows a client's address to remain stable long-term, even if the client sometimes allows its DHCP lease to expire.

&

Note
that in the sequential mode, clients which allow a lease to ex-
pire are much more likely to move IP address; for this reason it
should not be generally used.

Ik vertrouw er niet op dat ze onverandert blijven.
Maar het zou wel leuk zijn ipv al je clients een statisch DHCP reservering mee te geven,

[deHakkelaar]

Ik geloof dat m'n vraag wel zo'n beetje beantwoord is.

[deHakkelaar]

Nog een laatste opmerking wbt dat hashing, zelfs als ik de DHCP service omschakel naar m'n tweede backup DHCP server node met exact dezelfde instellingen, dan krijgt die VM client nog steeds hetzelfde IP toegewezen (10.0.0.145):

$ sudo dhclient -r eth0; sudo dhclient -v eth0
Killed old client process
Internet Systems Consortium DHCP Client 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:16:3e:XX:XX:XX
Sending on   LPF/eth0/00:16:3e:XX:XX:XX
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPOFFER of 10.0.0.145 from 10.0.0.4
DHCPREQUEST for 10.0.0.145 on eth0 to 255.255.255.255 port 67
DHCPACK of 10.0.0.145 from 10.0.0.4
bound to 10.0.0.145 -- renewal in 37959 seconds.

[DataGhost]

...alleen heb je nog steeds hetzelfde probleem als device A met hash X online was toen je primaire DHCP down ging en device B met hash X online komt met alleen je secondaire up, die niet weet dat device A een lease heeft (want die heeft je primaire uitgegeven) en dan heb je een IP-conflict als B niet checkt eerst checkt of het IP vrij is. Hoe dan ook kunnen beide devices niet tegelijk hetzelfde IP krijgen. Maar je moet het zelf weten. Nogmaals: hoe groter je DHCP-range, hoe kleiner de kans op collisions.

Het is een birthday problem: met een range van 200 IPs heb je vanaf 17 apparaten al 50% kans dat minimaal twee apparaten naar hetzelfde IP hashen. Met de 47 apparaten die in mijn fritzbox bekend zijn komt het dnsmasq-algoritme slechts op 39 unieke IP's, dus dat zijn al acht(!) collisions:

code:

XX:XX:XX:51:3E:B8: [192.168.0.62]
XX:XX:XX:E3:88:90: [192.168.0.62]

XX:XX:XX:71:A3:10: [192.168.0.81]
XX:XX:XX:10:ED:F3: [192.168.0.81]

XX:XX:XX:3D:2B:22: [192.168.0.123]
XX:XX:XX:3D:2B:24: [192.168.0.123]

XX:XX:XX:AA:5C:5B: [192.168.0.128]
XX:XX:XX:E2:2B:DA: [192.168.0.128]

XX:XX:XX:14:90:C9: [192.168.0.133]
XX:XX:XX:78:E7:BA: [192.168.0.133]

XX:XX:XX:F4:3A:9F: [192.168.0.149]
XX:XX:XX:42:D1:53: [192.168.0.149]

XX:XX:XX:12:3C:87: [192.168.0.189]
XX:XX:XX:A6:A4:18: [192.168.0.189]

XX:XX:XX:50:F8:5D: [192.168.0.211]
XX:XX:XX:47:F8:B1: [192.168.0.211]

[ Voor 52% gewijzigd door DataGhost op 14-05-2024 18:39 ]

[deHakkelaar]

M'n C++ kennis is een beetje roestig maar mooi gevonden!
Zoals ik het zie, tezamen met die client Preferred IP optie (Option 50) is de kans heel klein dat de IP's veranderen.
Maar voor dat hashen is het dus wel wenselijk om een zo groot mogelijke poel te configureren om de kans op "collisions" te verkleinen.
En nogmaals, ik vertrouw er niet op en ik adresseer op naam ipv IP's.

[ Voor 0% gewijzigd door deHakkelaar op 15-05-2024 07:20 . Reden: typo ]