Meerdere DHCP servers...hoe hun respons prioriteren ?

[PtrO]

Ik heb meerdere DHCP servers in mijn netwerk en wil graag de afhandelingsverzoeken prioriteren, hoe te doen ?

Mijn (hier versimpelde) opzet is een Microsoft DHCP (win2k3), Fritz:box7390 OS/06,20 DHCP en een QNAP: ISC/ DHCP Server "4.3.4".

Hierbij heb/wil ik graag dat in het geval de Microsoft versie het niet doet (sever plat bv),hetIP adres door de QNAP en als die twee (uit of niets doen), het IP adres uiteindelijk wordt verzorgd door de Fritz. Oftewel trappetje aflopen. In het geval ze het alle drie niet doen, gebruikt de "client" een lokaal geconfigureerde (local-ip) fall-back.

Voor de goede orde, de DHCP lease-reeksen gebruiken IP ranges en overeenkomstige instellingen.
En, de verschillende DHCP smaken hebben geen onderlinge connectie en dus "weet"/"kennis" van elkaar.

Waar ik naar op zoek ben is een DHCP (linux) instelling die zorgt dat de DHCP respons van mijn QNAP (linux) langzamer is dan die van de Microsoft. De respons van de Fritz is bij voorkeur weer wat langzamer dan de QNAP. Dat ik de Fritz kan aanpassen is wat minder belangrijk.

Probleem is dat ik feitelijk alleen de instelling van mijn QNAP/ISCServer "4.3.4" (dhcpd.conf) fatsoenlijk kan configureren omdat die van de Microsoft en Fritz, "closed-config" zijn.
Ik ben dus primair op zoek naar een DHCPD parameter waarmee het verzoek tot afgeven van een IP (OFFER) adres, kan worden vertraagd... dat het adres ongebruikt wordt opgenomen als "LEASE" in de server boeit mij verder niet. Als de leasetermijn verlopen is, komt die vanzelf wel weer beschikbaar.

Ik heb al flink rondgekeken maar buiten balance oplossingen, kan ik niets vinden waarmee ik wat kan. Ook andere tips, binnen bovenstaande of eventuele doenbare mogelijkheden, zijn welkom.

Wanneer het bovenstaande werkt kan ik precies nagaan of en vanuit welk DHCP-server in mijn netwerk een IP is afgegeven en daarbij concluderen welke (hoofd)server het dus niet deed. Die deterctie is nie het doel, het doel is dat cliënt-apparaten altijd werken met een (routeerbare) ingestelde "configuratie" voor een domotica (IoT) oplossing.

NB: Ik ben bekend met dat het niet raadzaam is en dat het niet hoort en dat er andere fabrieksoplossingen zijn die hier FF niet beschikbaar zijn. Ik moet het doen met wat ik heb.

Vast dank.

[lier]

Uitgebreid verhaal waarbij het voor mij nog steeds niet helder is welk probleem dit moet oplossen.

Daarnaast, W2K3??? En wat bedoel je precies met "closed-config"? En waarom gaat je server plat? En waarom moet deze W2K3 server per sé je primaire DHCP server zijn?

[Room42]

Je weet dat we gaan vallen over Windows 2003, hè?

edit:
Daar heb je het al!

Maar goed, als je niet de controle over de DHCP-servers hebt, kun je ook zorgen dat ze naast elkaar werken, door elk hun eigen pool toe te wijzen binnen hetzelfde subnet. En als ~80 hosts (240 verdeeld over 3 DHCP-servers) te weinig is, kun je ook je subnet uitbreiden. In plaats van een /24 subnet neem je dan /23, bijvoorbeeld. Dan zul je wellicht wel meer van je infra moeten herzien.

Ik neem overigens aan dat dit niet om een bedrijfsnetwerk gaat! Anders...

[ Voor 10% gewijzigd door Room42 op 03-08-2019 19:27 ]

[HKLM_]

Dit is wel voor thuis toch? En waarom niet alles netjes onder bij 1 fatsoenlijke DHCP server?

Ik zou die server 2003 bak snel migreren naar een Windows hyper-v server en twee server 2016 core machines installeren. Daar de DHCP op zetten in een hot/stand-by configuratie. Faalt Host A neemt Host B het over. Aangezien je de trail versies 180 dagen kan gebruiken en 5x kan verlengen is het een mooie thuis oplossing. (Na die tijd is het weer migratie tijd)

[ Voor 12% gewijzigd door HKLM_ op 03-08-2019 19:36 ]

[Tokkes]

1. Win2k3, serieus? Komaan...
2. Hoe vaak denk je dat zo'n DHCP server over de kop gaat ? Dat is mij letterlijk nog nooit gebeurt, en ik heb er 3 in persoonlijk beheer, al een aantal jaar, geen enkele redundant. Hoeft ook zo niet - moest het fout lopen is dat snel opgelost.
3. zoals al aangegeven is opsplitsen in scopes de (enige) best practice om een fail-over/redundant DHCP set-up te hebben. Om te monitoren welke DHCP-server het al dan niet doet zet je best andere methodes in, zoals service monitoring of een udp connection-test naar serveradres:67 of iets dergelijks. Het "probleem" bij DHCP hier is dat er (AFAIK) geen feature is geimplementeerd in het protocol om 'het trapje af te lopen'. Het is simpel DORA, oftewel Discover, Offer, Request, Acknowledge, en de eerste DHCP server die reageert geeft de lease uit.

Als het je gaat om automatische DNS toewijzing voor clients zodat je geen IPs moet vanbuiten weten, dat kan je met een linux omgeving ook (en PiHole doet dat ook gewoon voor je Zet je er een RPi voor in de plaats en kan dat win2k3 bakje wat anders doen. Zoals een upgrade krijgen )

[MewBie]

Draai op je Windows server een linux container/VM met ISC DHCP en je Qnap NAS zul je ook handmatig via de CLI in moeten stellen volgens:
https://kb.isc.org/docs/aa-00502

Veel beter gaat het waarschijnlijk niet worden met de hardware die in de openingspost staat.

[CH4OS]

Lijkt mij inderdaad een betere optie om een opzet te maken waarbij een IP-adres van machine kan wisselen, zodat als A uitvalt, B het over kan nemen, of C, net hoe spannend je dat wilt maken. Maar met een constructie over verschillende apparaten wordt je denk ik nooit blij van, zeker met Windows 2003 als primaire DHCP niet.

[bommel]

Dit wordt vaak opgelost door de gehele range op alle dhcp servers beschikbaar te maken maar exclusions te zetten zodat iedere server eigen "blokken" heeft binnen de reeks. Valt een dhcp server uit dan zal een andere het overnemen en nooit een conflicterend adres uitgeven maar wel een bestaande lease van een andere dhcp server verlengen. Evt nog te combineren met een ping check voordat een adres wordt uitgegeven

[ik222]

Met bijvoorbeeld ISC DHCP server kan je prima een cluster maken. Daarbij worden leases dan ook netjes gesynchroniseerd en weten de servers van elkaar wat ze doen. Dat heb ik op het werk ook draaien alleen hebben we het dan wel over een setup die tienduizenden clients van een IP adres moet voorzien.

Windows ken ik verder niet maar ook daar kan je neem ik aan wel een redundante opstelling maken als je 2 of meer Windows DHCP servers hebt.

Bij een setup met 1 oude Windows server, 1 QNAP NAS en en 1 Fritzbox zou ik lekker een van de drie kiezen. Neemt niet weg dat het met aparte ranges best zou kunnen werken maar dan moet je denk ik nog eens heel goed nadenken waarom je dit zo doet en hoe redundant de rest van het netwerk is.

[HollowGamer]

bommel schreef op zaterdag 3 augustus 2019 @ 20:15:
Dit wordt vaak opgelost door de gehele range op alle dhcp servers beschikbaar te maken maar exclusions te zetten zodat iedere server eigen "blokken" heeft binnen de reeks. Valt een dhcp server uit dan zal een andere het overnemen en nooit een conflicterend adres uitgeven maar wel een bestaande lease van een andere dhcp server verlengen. Evt nog te combineren met een ping check voordat een adres wordt uitgegeven

Waarom zou je eigenlijk meerdere DHCP-servers willen hebben? Leuk dat je een fail-safe hebt, maar als je meer stuff hebt, dan wordt het alweer een stuk moeilijker met syncen bv.

Waarom ook niet gewoon alles van routing in een VM? Dan heb je ook snapshots, makkelijker met backups, etc.

Ik kan mij verder niet zo een-twee-drie een situatie voorstellen dat je een andere DHCP het wilt laten overnemen, dat gaat er toch al iets fout in je routering? Correct me if I'm wrong.

[ Voor 10% gewijzigd door HollowGamer op 03-08-2019 22:51 ]

[PtrO]

Leuk, thx2all.

Nog wel opgemerkt dat mijn vraag niet was of wat ik wil zo (on)zinnig is, niet van deze tijd is en laat staan niet snugger is. De vraag is kernachtig: hoe meerdere DHCP-Offers te prioriteren gevraagd en vertstuurd (binnen)in een lokaal netwerk.

lier schreef op zaterdag 3 augustus 2019 @ 19:25:
Uitgebreid verhaal waarbij het voor mij nog steeds niet helder is welk probleem dit moet oplossen.

Daarnaast, W2K3??? En wat bedoel je precies met "closed-config"? En waarom gaat je server plat? En waarom moet deze W2K3 server per sé je primaire DHCP server zijn?

Omdat dit nu eenmaal het geval is, wat verder niet mijn vraag was. Ik heb een oude Corsa met 3 slechte banden en wil naar Spanje... hoe te doen.

lier schreef op zaterdag 3 augustus 2019 @ 19:25:
Uitgebreid verhaal waarbij het voor mij nog steeds niet helder is welk probleem dit moet oplossen.

Daarnaast, W2K3??? En wat bedoel je precies met "closed-config"? En waarom gaat je server plat? En waarom moet deze W2K3 server per sé je primaire DHCP server zijn?

closed config, ik kan niet meer aanpassen dan de userinterface biedt. Het nadeel van windows en Frizboxen. Onder linux ben je wat vrijjer

Het probleem dat ik wil oplossen dat eerst DFCP offer van Win2K3 wordt vertuurd, na een sconde pas die van mijn .QNAP en daarna pas die van de Fritz.

HKLM_ schreef op zaterdag 3 augustus 2019 @ 19:30:
Dit is wel voor thuis toch? En waarom niet alles netjes onder bij 1 fatsoenlijke DHCP server?

Ik zou die server 2003 bak snel migreren naar een Windows hyper-v server en twee server 2016 core machines installeren. Daar de DHCP op zetten in een hot/stand-by configuratie. Faalt Host A neemt Host B het over. Aangezien je de trail versies 180 dagen kan gebruiken en 5x kan verlengen is het een mooie thuis oplossing. (Na die tijd is het weer migratie tijd)

Ja thuis wat de vraagstelling niet anders maakt. Je oplossing zou ik ook wel allemaal willen (laten doen) maar gaat ver van het hobbydoel. Ik zoek een oplossing om mijn DHCP servers een seconde of meer na elkaar te laten antwoorden op REQUESTS.

Ik heb nu alles op één DHCP server en als die uitvalt (vmware met win2k3 gaat plat) wil ik terugvallen op DHCP van de Router of de Qnap. De router is daarbij kut omdat je alles via een webinterface statisch moet regelen. Die DHCP van mijn Qnap box kan ik met CLI doen.

HKLM_ schreef op zaterdag 3 augustus 2019 @ 19:30:
Dit is wel voor thuis toch? En waarom niet alles netjes onder bij 1 fatsoenlijke DHCP server?

Ik zou die server 2003 bak snel migreren naar een Windows hyper-v server en twee server 2016 core machines installeren. Daar de DHCP op zetten in een hot/stand-by configuratie. Faalt Host A neemt Host B het over. Aangezien je de trail versies 180 dagen kan gebruiken en 5x kan verlengen is het een mooie thuis oplossing. (Na die tijd is het weer migratie tijd)

Ik heb een fatsoenlijke DHCP server en waarom zou ik migreren.... dan kan ik net zo goed alles opnieuw oppakken door een superfarm plaatsem ?.... en dan daarbij mijn probleme vergroten door er 3 windows bakken bij te plaatsen... waarvoor ik resources moet vrijmaken.....

Het probleem zit 'm niet in de WindowsSmaak (win2k3) maar dat ik de dhcp-server van mijn Frizbox en Qnap niet kan vertragen.

Tokkes schreef op zaterdag 3 augustus 2019 @ 19:43:
1. Win2k3, serieus? Komaan...
2. Hoe vaak denk je dat zo'n DHCP server over de kop gaat ? Dat is mij letterlijk nog nooit gebeurt, en ik heb er 3 in persoonlijk beheer, al een aantal jaar, geen enkele redundant. Hoeft ook zo niet - moest het fout lopen is dat snel opgelost.
3. zoals al aangegeven is opsplitsen in scopes de (enige) best practice om een fail-over/redundant DHCP set-up te hebben. Om te monitoren welke DHCP-server het al dan niet doet zet je best andere methodes in, zoals service monitoring of een udp connection-test naar serveradres:67 of iets dergelijks. Het "probleem" bij DHCP hier is dat er (AFAIK) geen feature is geimplementeerd in het protocol om 'het trapje af te lopen'. Het is simpel DORA, oftewel Discover, Offer, Request, Acknowledge, en de eerste DHCP server die reageert geeft de lease uit.

Als het je gaat om automatische DNS toewijzing voor clients zodat je geen IPs moet vanbuiten weten, dat kan je met een linux omgeving ook (en PiHole doet dat ook gewoon voor je Zet je er een RPi voor in de plaats en kan dat win2k3 bakje wat anders doen. Zoals een upgrade krijgen )

Laat je niet afleiden van de windowssmaak......heeft er verder bitter weinig mee te maken of en hoe je een getrapt DHCP afhandelt.
En wat ik dus wil dat de eerste binnen een seconde, de tweede pas na 2 seconden en de 3e na 6 seconden de DORA doet.

MewBie schreef op zaterdag 3 augustus 2019 @ 19:58:
Draai op je Windows server een linux container/VM met ISC DHCP en je Qnap NAS zul je ook handmatig via de CLI in moeten stellen volgens:
https://kb.isc.org/docs/aa-00502

Veel beter gaat het waarschijnlijk niet worden met de hardware die in de openingspost staat.

Nope... die Win2K2/DHCP draai ik onder VMware (single host) en als die uitvalt wil ik juist de DHCP van de QNAP hanteren.

Het probleem is niet DHCP-server failover maar dat een DHCP Request door alle dhcp-servers worden afgehandeld en de snelste OFFER wint. Soms is dat de router/Fritz, soms de QNAP/doos en meestal de Win2k3@VM.

Je brengt mij wel op een superidee om een DHCP-sourcecode aan te passen en dat te compileren met ingebouwde vertraging en die op mijn QNAP neerplempen. Wat ik als alternatief in de pocket hou. Het liefst zie ik een operationele/configuratie oplossing.

bommel schreef op zaterdag 3 augustus 2019 @ 20:15:
Dit wordt vaak opgelost door de gehele range op alle dhcp servers beschikbaar te maken maar exclusions te zetten zodat iedere server eigen "blokken" heeft binnen de reeks. Valt een dhcp server uit dan zal een andere het overnemen en nooit een conflicterend adres uitgeven maar wel een bestaande lease van een andere dhcp server verlengen. Evt nog te combineren met een ping check voordat een adres wordt uitgegeven

Ik zie niet goed hoe ik hiermee de prioriteit van DHCP offers kan reguleren.....en dat het anders kan met allerlei goedbedoelde zwaartekracht tot en met (re)activeren van server, snap ik ook.

[CyBeR]

PtrO schreef op zaterdag 3 augustus 2019 @ 22:57:
De vraag is kernachtig: hoe meerdere DHCP-Offers te prioriteren gevraagd en vertstuurd (binnen)in een lokaal netwerk.

Heel simpel: niet.

DHCP ondersteunt dit niet.

[HKLM_]

PtrO schreef op zaterdag 3 augustus 2019 @ 22:57:
Leuk, thx2all.

Nog wel opgemerkt dat mijn vraag niet was of wat ik wil zo (on)zinnig is, niet van deze tijd is en laat staan niet snugger is. De vraag is kernachtig: hoe meerdere DHCP-Offers te prioriteren gevraagd en vertstuurd (binnen)in een lokaal netwerk.


[...]

Omdat dit nu eenmaal het geval is, wat verder niet mijn vraag was. Ik heb een oude Corsa met 3 slechte banden en wil naar Spanje... hoe te doen.


[...]
closed config, ik kan niet meer aanpassen dan de userinterface biedt. Het nadeel van windows en Frizboxen. Onder linux ben je wat vrijjer

Het probleem dat ik wil oplossen dat eerst DFCP offer van Win2K3 wordt vertuurd, na een sconde pas die van mijn .QNAP en daarna pas die van de Fritz.


[...]

Ja thuis wat de vraagstelling niet anders maakt. Je oplossing zou ik ook wel allemaal willen (laten doen) maar gaat ver van het hobbydoel. Ik zoek een oplossing om mijn DHCP servers een seconde of meer na elkaar te laten antwoorden op REQUESTS.

Ik heb nu alles op één DHCP server en als die uitvalt (vmware met win2k3 gaat plat) wil ik terugvallen op DHCP van de Router of de Qnap. De router is daarbij kut omdat je alles via een webinterface statisch moet regelen. Die DHCP van mijn Qnap box kan ik met CLI doen.

[...]

Ik heb een fatsoenlijke DHCP server en waarom zou ik migreren.... dan kan ik net zo goed alles opnieuw oppakken door een superfarm plaatsem ?.... en dan daarbij mijn probleme vergroten door er 3 windows bakken bij te plaatsen... waarvoor ik resources moet vrijmaken.....

Het probleem zit 'm niet in de WindowsSmaak (win2k3) maar dat ik de dhcp-server van mijn Frizbox en Qnap niet kan vertragen.

[...]

Laat je niet afleiden van de windowssmaak......heeft er verder bitter weinig mee te maken of en hoe je een getrapt DHCP afhandelt.
En wat ik dus wil dat de eerste binnen een seconde, de tweede pas na 2 seconden en de 3e na 6 seconden de DORA doet.


[...]

Nope... die Win2K2/DHCP draai ik onder VMware (single host) en als die uitvalt wil ik juist de DHCP van de QNAP hanteren.

Het probleem is niet DHCP-server failover maar dat een DHCP Request door alle dhcp-servers worden afgehandeld en de snelste OFFER wint. Soms is dat de router/Fritz, soms de QNAP/doos en meestal de Win2k3@VM.

Je brengt mij wel op een superidee om een DHCP-sourcecode aan te passen en dat te compileren met ingebouwde vertraging en die op mijn QNAP neerplempen. Wat ik als alternatief in de pocket hou. Het liefst zie ik een operationele/configuratie oplossing.


[...]

Ik zie niet goed hoe ik hiermee de prioriteit van DHCP offers kan reguleren.....en dat het anders kan met allerlei goedbedoelde zwaartekracht tot en met (re)activeren van server, snap ik ook.

Daarom zeg ik een tweede Windows bak met DHCP erop en failover configureren mijn aangedragen oplossing is qua resource haalbaar met een systeem met 4gb ram. Waar je beide DHCP servers op laat draaien. Failover instellen is nog geen 10 minuten werk als je beide host hebt geïnstalleerd.

Voorbeeldje:

https://cloud23.nl/2019/05/16/server-core-dhcp-failover-2/
https://cloud23.nl/2019/05/15/server-core-dhcp-failover/

Als je failover wilt zal je naar een andere oplossing moeten zoeken je je nu hebt wat dat is niet mogelijk omdat het niet in DHCP zit.

Off-topic: je gebruik Windows server 2003 of het nu nog werkt of niet je moet het gewoon echt maar dan ook echt niet meer willen

[ Voor 6% gewijzigd door HKLM_ op 03-08-2019 23:13 ]

[PtrO]

Room42 schreef op zaterdag 3 augustus 2019 @ 19:25:
Je weet dat we gaan vallen over Windows 2003, hè?

Altijd leuk wanneer "slimme" mensen vallen op of over een versie en allee nog dat kunnen benadrukken.
Dat het probleem totaal niet anders is/wordt met Win2K19 wordt dan gemist.

[Tokkes]

PtrO schreef op zaterdag 3 augustus 2019 @ 23:08:
[...]

Dat het probleem totaal niet anders is/wordt met Win2K19 wordt dan gemist.

Hier gaat volgens mij ook geen enkele post over het feit dat het 'met een upgrade' wel zou kunnen Het gaat ons denk ik allemaal veel meer om het feit dat er nog ergens een zeef waarschijnlijk aan het internet hangt.

[PtrO]

HKLM_ schreef op zaterdag 3 augustus 2019 @ 23:05:
[...]


Daarom zeg ik een tweede Windows bak met DHCP erop en failover configureren mijn aangedragen oplossing is qua resource haalbaar met een systeem met 4gb ram. Waar je beide DHCP servers op laat draaien. Failover instellen is nog geen 10 minuten werk als je blijde host hebt geïnstalleerd.

Off-topic: je gebruik Windows server 2003 of het nu nog werkt of niet je moet het gewoon echt maar dan ook echt niet meer willen

Moet ik toch uitleggen hoe ik nu al die windowsshit all inclusive draai..... op een hele dikke hobbybob VMware doos. Wanneer die VM-bak uitvalt (of onbereikbara is, kan gebeuren) is daar niks meer van over en heb ik alleen nog de "beschikking" over een Router en een QNAP/storagedoos. Op mijn QNAP draai ik ter info al mijn IoT/Coud/Web zaken.

Om nu permanent, ons ben zuunig, een tweede fysieke VM/Win server aan te laten staan is niet bepaald vriendelijk voor het stroom verbruik.

[HKLM_]

PtrO schreef op zaterdag 3 augustus 2019 @ 23:12:
[...]

Moet ik toch uitleggen hoe ik nu al die windowsshit all inclusive draai..... op een hele dikke hobbybob VMware doos. Wanneer die VM-bak uitvalt (of onbereikbara is, kan gebeuren) is daar niks meer van over en heb ik alleen nog de "beschikking" over een Router en een QNAP/storagedoos. Op mijn QNAP draai ik ter info al mijn IoT/Coud/Web zaken.

Om nu permanent, ons ben zuunig, een tweede fysieke VM/Win server aan te laten staan is niet bepaald vriendelijk voor het stroom verbruik.

Onzin dit is prima op een zuinig systeem te draaien. Mijn HPE microserver gebruikt 16 watt maximaal gooi ik daar nog een microserver bij zit ik op 32 watt voor twee systemen. Snelle berekening komt uit op 70 euro per jaar.

Nu heb je ook een hele rambam maar het kan echt wel zuiniger hoor als je maar wilt. En anders toch eens na denken of je het echt nodig hebt als de hobby je te duur is

[PtrO]

HKLM_ schreef op zaterdag 3 augustus 2019 @ 23:05:
Off-topic: je gebruik Windows server 2003 of het nu nog werkt of niet je moet het gewoon echt maar dan ook echt niet meer willen

Waarom niet, en dat bedoel ik serieus...... basaal werk dat ding prima en met nieuwe serverzooi moet ik door allerlei leercurves en (licentieshit) die mij niets toevoegen. Gata mijn probleem wel opgelost worden als ik Win2K19 ga draaien als DHCP ?

Mijn Win2K3 is doorgaans supersnel en is alleen heel soms niet de snelste omdat bijvoorbeeld de tussenliggende switch (netgear/JGS524E) of VMware FF zit te stumperen (broadcast stormpje of dDos tegenhouden) of aan het repliceren is.

[HKLM_]

PtrO schreef op zaterdag 3 augustus 2019 @ 23:19:
[...]

Waarom niet, en dat bedoel ik serieus...... basaal werk dat ding prima en met nieuwe serverzooi moet ik door allerlei leercurves en (licentieshit) die mij niets toevoegen. Gata mijn probleem wel opgelost worden als ik Win2K19 ga draaien als DHCP ?

Mijn Win2K3 is doorgaans supersnel en is alleen heel soms niet de snelste omdat bijvoorbeeld de tussenliggende switch (netgear/JGS524E) of VMware FF zit te stumperen (broadcast stormpje of dDos tegenhouden) of aan het repliceren is.

Hoe update jij je win2K3 machine?

[Grvy]

PtrO schreef op zaterdag 3 augustus 2019 @ 22:57:
Leuk, thx2all.


[...]

Omdat dit nu eenmaal het geval is, wat verder niet mijn vraag was. Ik heb een oude Corsa met 3 slechte banden en wil naar Spanje... hoe te doen.

Simpel, je denkt na en doet dat niet en huurt/koopt een fatsoenlijke auto. Zoals elk redelijk denkend mens zou zeggen en doen. Maar nee, dit is IT dus alles moet maar kunnen.

[Freezerator]

Sowieso, het is voor thuis, dus hoe kritiek is het? Waarom niet fixed ip's en 1 dhpc host voor eventueel wat dynamisch een adres nodig heeft. Andere oplossing van de scope per dhcp host te configureren was geen optie?

En server2k3, tja....

[Brahiewahiewa]

PtrO schreef op zaterdag 3 augustus 2019 @ 23:08:
[...]

Altijd leuk wanneer "slimme" mensen vallen op of over een versie en allee nog dat kunnen benadrukken.
Dat het probleem totaal niet anders is/wordt met Win2K19 wordt dan gemist.

Nou, het is vooral niet slim om hedentendage nog windows 2k3 te gebruiken; zowel slimme als minder slimme mensen gaan dan denken dat je dom bent ;o)

Anyway: je probeert nu twee problemen tegelijk op te lossen, nl 1) dhcp redundancy en 2) dhcp passive monitoring. En dat gaat je op deze manier niet lukken met closed source software.

Op zich kun je prima meerdere DHCP servers in een netwerk segment draaien, zelfs met overlappende scopes. Je keuze voor passive monitoring is niet zo handig en ook niet zo betrouwbaar. Als er nu één dhcp offer verzuipt in je netwerk ga jij meteen denken dat je win2k3 bak gecrasht is. Ik denk dat er betere manieren zijn om de beschikbaarheid van dhcp-servers te monitoren

[MewBie]

PtrO schreef op zaterdag 3 augustus 2019 @ 22:57:
[...]
Nope... die Win2K2/DHCP draai ik onder VMware (single host) en als die uitvalt wil ik juist de DHCP van de QNAP hanteren.

Het probleem is niet DHCP-server failover maar dat een DHCP Request door alle dhcp-servers worden afgehandeld en de snelste OFFER wint. Soms is dat de router/Fritz, soms de QNAP/doos en meestal de Win2k3@VM.

Je brengt mij wel op een superidee om een DHCP-sourcecode aan te passen en dat te compileren met ingebouwde vertraging en die op mijn QNAP neerplempen. Wat ik als alternatief in de pocket hou. Het liefst zie ik een operationele/configuratie oplossing.

Nu maak je het alleen maar moeilijk voor jezelf.

DHCP in je router uitschakelen, op je VMware bak maak je een nieuwe linux VM aan die ook ISC DHCP draait, die stel je in als primary, je Qnap configureer je als secondary en je bent klaar met een configuratie die door de ontwikkelaars gewoon ondersteunt wordt en werkt zoals het hoort.

DHCP is niet ontwikkelt om een race te zijn wie als eerste antwoord, dat wel proberen te doen gaat je situatie echt niet beter van worden.

[PtrO]

HKLM_ schreef op zaterdag 3 augustus 2019 @ 23:18:
[...]


Onzin dit is prima op een zuinig systeem te draaien. Mijn HPE microserver gebruikt 16 watt maximaal gooi ik daar nog een microserver bij zit ik op 32 watt voor twee systemen. Snelle berekening komt uit op 70 euro per jaar.

Nu heb je ook een hele rambam maar het kan echt wel zuiniger hoor als je maar wilt. En anders toch eens na denken of je het echt nodig hebt als de hobby je te duur is

Goed moraliserend bedoeld maar je zegt (nofi) niets technisch....... en ik heb nergens iets gezegd (of gevraagd) over vermogensrendement maar wil er sws geen apparaten BIJ gaan zetten.

En stel je een huis volgeladen met een tiental servers voor verschillende doeleinden, 5-switches, 3-routers en een zooi Domotica shit met in totaal 200 devices plus qay ik allemaal zo FF vergeet. Een waar tweakers huis dus waar de Zolder offlimits is.

Dat het anders kan als ik opnieuw zou beginnen, snap ik ook. Wrs, alles geweten, had dan helemaal niets gedaan en een studie Economie gedaan ipv IT.
Idem met hoe makkelijk mensen zeggen om bv een QNAP te migreren en niet begrijpen dat het meer is dan storage. Windows upgraden doe je in een uurtje maar functionaliteit migreren kan goed weken tot maanden aan inspanning kosten.

Maar als gezegd, dat is allemaal niet het probleem ... ik zoek een oplossing hoe ik DHCP-Offers kan vertragen (of mijn op Windows kan versnellen) zonder daarbij ander netwerkverkeer te vertragen.

[HKLM_]

PtrO schreef op zaterdag 3 augustus 2019 @ 23:30:
[...]

Goed moraliserend bedoeld maar je zegt (nofi) niets technisch....... en ik heb nergens iets gezegd (of gevraagd) over vermogensrendement maar wil er sws geen apparaten BIJ gaan zetten.

En stel je een huis volgeladen met een tiental servers voor verschillende doeleinden, 5-switches, 3-routers en een zooi Domotica shit met in totaal 200 devices plus qay ik allemaal zo FF vergeet. Een waar tweakers huis dus waar de Zolder offlimits is.

Dat het anders kan als ik opnieuw zou beginnen, snap ik ook. Wrs, alles geweten, had dan helemaal niets gedaan en een studie Economie gedaan ipv IT.
Idem met hoe makkelijk mensen zeggen om bv een QNAP te migreren en niet begrijpen dat het meer is dan storage. Windows upgraden doe je in een uurtje maar functionaliteit migreren kan goed weken tot maanden aan inspanning kosten.

Maar als gezegd, dat is allemaal niet het probleem ... ik zoek een oplossing hoe ik DHCP-Offers kan vertragen (of mijn op Windows kan versnellen) zonder daarbij ander netwerkverkeer te vertragen.

Ik geef alleen aan dat er andere opties zijn. Jij begint over een dikke VMware bak en dan over zuinigheid.

Maar als gezegd, dat is allemaal niet het probleem ... ik zoek een oplossing hoe ik DHCP-Offers kan vertragen (of mijn op Windows kan versnellen) zonder daarbij ander netwerkverkeer te vertragen.

Zoals al door meerder mensen hierboven aangegeven kan dat niet en zal je naar 1 van de aangedragen oplossingen moeten als je het zo graag wilt.

[Verwijderd]

Dit kan DHCP gewoon niet. Je zult het moeten laten werken op de manier zoals het bedacht is: je systemen zullen een juist adres moeten krijgen ongeacht welke DHCP server toevallig als eerste reageert. Dus als een systeem altijd hetzelfde IP moet krijgen, dan zal in alle 3 de DHCP servers dezelfde reservering aanwezig moeten zijn. Systemen die dynamisch mogen, zullen een adres moeten krijgen uit de op de betreffende DHCP server aanwezige pool. Enige alternatief is of je DHCP service clusteren (wat niet kan met de nu aanwezige servers) of overstappen op een wat recentere Microsoft oplossing (failover).

[PtrO]

MewBie schreef op zaterdag 3 augustus 2019 @ 23:28:
[...]

Nu maak je het alleen maar moeilijk voor jezelf.

DHCP in je router uitschakelen, op je VMware bak maak je een nieuwe linux VM aan die ook ISC DHCP draait, die stel je in als primary, je Qnap configureer je als secondary en je bent klaar met een configuratie die door de ontwikkelaars gewoon ondersteunt wordt en werkt zoals het hoort.

DHCP is niet ontwikkelt om een race te zijn wie als eerste antwoord, dat wel proberen te doen gaat je situatie echt niet beter van worden.

Probleem is dat juist mijn VMbak met daarin de (virtuele) servers trager is dan de dhcp op router/qnap...... in in de VM/Win bak dan daarin dan iets extra's virtueel draaien gaat mij niet helpen.

Dat DHCP daarvoor niet is ontwikkeld.... hoe konden ze dat ook in 1993 bedenken... snap ik ook en daarom de vraag of er niet ergens in de tussentijd een "onverwachte" parameter is (gekomen) waarmee het kan worden bewerkstelligd. Dat het gen het "protocol" is, interesseert mij weer niet zo veel.

Als niets overblijft, haal ik de DHCP source van de QNAP wel naar binnen en verbouw dat door de OFFER timing bij te stellen. Wanneer ik daar toch ben kan ik gelijk code invoegen die controleert of de VM/Winbak er echt niet is. Maar goed, ik wilde dat relatief moeizame sourcecode aanpassen voorkomen wat je dan altijd weer meesleept in een toekomst wanneer je iets gaat restoren of initialiseren.

[Grvy]

@PtrO belachelijk. Echt waar belachelijk. Je hebt een auto met slechte banden en gaat er vervolgens maar vierkante banden en een houten chassis opzetten omdat het _moet_ met kracht en willens tegen elke best practice in zoals jij dat voor ogen hebt.

[HKLM_]

PtrO schreef op zaterdag 3 augustus 2019 @ 23:38:
[...]

Probleem is dat juist mijn VMbak met daarin de (virtuele) servers trager is dan de dhcp op router/qnap...... in in de VM/Win bak dan daarin dan iets extra's virtueel draaien gaat mij niet helpen.

Dat DHCP daarvoor niet is ontwikkeld.... hoe konden ze dat ook in 1993 bedenken... snap ik ook en daarom de vraag of er niet ergens in de tussentijd een "onverwachte" parameter is (gekomen) waarmee het kan worden bewerkstelligd. Dat het gen het "protocol" is, interesseert mij weer niet zo veel.

Als niets overblijft, haal ik de DHCP source van de QNAP wel naar binnen en verbouw dat door de OFFER timing bij te stellen. Wanneer ik daar toch ben kan ik gelijk code invoegen die controleert of de VM/Winbak er echt niet is. Maar goed, ik wilde dat relatief moeizame sourcecode aanpassen voorkomen wat je dan altijd weer meesleept in een toekomst wanneer je iets gaat restoren of initialiseren.

Maar hoe update je die server 2003 bak nu dan? Aangezien die zo heilig voor je lijkt te zijn? Anders wilde je wel migreren of had je dat al gedaan 14 juli 2015 is namelijk al even voorbij Hack je daar ook je eigen updates in

[ Voor 3% gewijzigd door HKLM_ op 03-08-2019 23:51 ]

[PtrO]

Verwijderd schreef op zaterdag 3 augustus 2019 @ 23:38:
Dit kan DHCP gewoon niet. Je zult het moeten laten werken op de manier zoals het bedacht is: je systemen zullen een juist adres moeten krijgen ongeacht welke DHCP server toevallig als eerste reageert. Dus als een systeem altijd hetzelfde IP moet krijgen, dan zal in alle 3 de DHCP servers dezelfde reservering aanwezig moeten zijn. Systemen die dynamisch mogen, zullen een adres moeten krijgen uit de op de betreffende DHCP server aanwezige pool. Enige alternatief is of je DHCP service clusteren (wat niet kan met de nu aanwezige servers) of overstappen op een wat recentere Microsoft oplossing (failover).

Als het niet in DHCP staat ik het er dus zelf inzetten. Was er al wat bang voor en vindt hier wat bevestiging.

Daar mijn oude virtuele windows server reeds "primair" qua snelheid is, zie ik nog niet hoe een nieuwere versie (ook virtueel gedraaid) sneller wel kan prioriteren. Ik durf bijna te wedden dat DHCP@win2k3 sneller is dan dhcp@win2k19.

SourceCode aanpassen is overigens minder ingrijpend werk dan mijn infrastructuur te migreren, desnoods kan ik ipv de QNAP; een Raspberry PI hanteren wat ik juist niet wil omdat ik het aantal nodes wil verminderen. Elk doosje vraag tzt weer ongepaste aandacht etc.etc.

Los van alles zou je/ik (willen) denken dat een protocol daar wel parameter voor zou hebben waarmee netwerk verzoeken met micro/milli/seconden kan worden vertraagd of mijn part met een soort QoS/Cos prioriteert. Maar goed, jouw respons is vooralsnog to the point het helderste.

[CyBeR]

PtrO schreef op zaterdag 3 augustus 2019 @ 23:50:
[...]

Als het niet in DHCP staat ik het er dus zelf inzetten. Was er al wat bang voor en vind hier wat bevestiging.

Je vindt als je een stukje omhoog scrollt ook al wat bevestiging. Wat je wilt kan niet.

(Los van dat 3 dhcp servers voor thuis compleet bullshit is. Kies 1 van je opties die het minst stuk is en gebruik die gewoon.)

[ Voor 16% gewijzigd door CyBeR op 03-08-2019 23:52 ]

[|sWORDs|]

DHCP trager vanuit een VM? Zeer onwaarschijnlijk.

Ik heb twee dikke (24 core, 256GB, GPUs, 10GBit, etc.) VMware bakken en een klein (i3-7100U, 32GB, 6x Gbit) VMware doosje. Op de kleine draait de router (pfSense direct aan glasvezel NTU) en een Server 2016 domain controller (met DHCP en DNS), plus vCenter en VSAN witness. Op één van de grote draait een tweede domain controller (met DHCP en DNS) en XPenology als NAS met een SATA controller in passthrough.

De grote kunnen uit en dan heb ik alleen even geen NAS, de kleine kan uit als een grote aan staat. Geen extra NAS, geen extra router.

[ Voor 104% gewijzigd door |sWORDs| op 04-08-2019 00:06 ]

[HKLM_]

PtrO schreef op zaterdag 3 augustus 2019 @ 23:50:
[...]

Als het niet in DHCP staat ik het er dus zelf inzetten. Was er al wat bang voor en vindt hier wat bevestiging.

Daar mijn oude virtuele windows server reeds "primair" qua snelheid is, zie ik nog niet hoe een nieuwere versie (ook virtueel gedraaid) sneller wel kan prioriteren. Ik durf bijna te wedden dat DHCP@win2k3 sneller is dan dhcp@win2k19.

SourceCode aanpassen is overigens minder ingrijpend werk dan mijn infrastructuur te migreren, desnoods kan ik ipv de QNAP; een Raspberry PI hanteren wat ik juist niet wil omdat ik het aantal nodes wil verminderen. Elk doosje vraag tzt weer ongepaste aandacht etc.etc.

Los van alles zou je/ik (willen) denken dat een protocol daar wel parameter voor zou hebben waarmee netwerk verzoeken met micro/milli/seconden kan worden vertraagd of mijn part met een soort QoS/Cos prioriteert. Maar goed, jouw respons is vooralsnog to the point het helderste.

Hoe selectief kan je lezen zeg

Daar mijn oude virtuele windows server reeds "primair" qua snelheid is, zie ik nog niet hoe een nieuwere versie (ook virtueel gedraaid) sneller wel kan prioriteren

Het kan niet wat jij wilt

[MewBie]

PtrO schreef op zaterdag 3 augustus 2019 @ 23:50:
[...]
Los van alles zou je/ik (willen) denken dat een protocol daar wel parameter voor zou hebben waarmee netwerk verzoeken met micro/milli/seconden kan worden vertraagd of mijn part met een soort QoS/Cos prioriteert. Maar goed, jouw respons is vooralsnog to the point het helderste.

Nee, waarom zou DHCP de mogelijkheid hebben om een response te vertragen? Je wilt die zooi zo snel mogelijk afhandelen. Om te zorgen voor high availability (wat jij in feite probeert te bereiken) ondersteunen DHCP servers dus failover, load balancing en andere features.

En nee, dat gaat waarschijnlijk niet werken als je probeert 3 verschillende DHCP software paketten te combineren. Dus moet je er 2 dumpen en van die 3de een extra instantie draaien en dan beide DHCP servers juist configureren.

[ Voor 14% gewijzigd door MewBie op 03-08-2019 23:58 ]

[PtrO]

HKLM_ schreef op zaterdag 3 augustus 2019 @ 23:48:
[...]


Maar hoe update je die server 2003 bak nu dan? Aangezien die zo heilig voor je lijkt te zijn? Anders wilde je wel migreren of had je dat al gedaan 14 juli 2015 is namelijk al even voorbij. Hack je daar ook je eigen updates in

Niet updaten .... ik zou niet weten waarom dat nodig is.. (natuurlijk ken ik de virus/update maffia).

Essentiële zaken incl filesharing draai ik sws op Linux met m'n Qnap als o.a.. iScsi provider.
Alles draait en doet prima wat ik nodig heb... t/m midi-control van de (muziek)studio.
Het is een echte shitcom researchbak. Het is hobby en verder niks zakelijks.
Dat het niet mag van Mr Windows - stoute ik - zoeken ze maar uit wanneer ik ben overleden.
Die winbak is over de vele jaren al een keer of 12 (virtueel) verplaatst en meeverhuisd

Die oude winbak doet kan van alles zoals domotica,, consolelogging, mail, websites, sensor reading etc.etc en is over de jaren volgeladen met alle gadgets wat ik nu niet meer zou doen. Ben wel bezig om functies weg te bouwen naar de QNAP of rPI zoals eerder Exchange en recentelijk m'n Asterisk/Voip centrale.

Maar goed ik ga uitgedaagd, wel enthousiast offtopic (wat verder totaal niet mijn bedoeling was met mijn vraag). Wel leuk bevraagd te worden. Thx.

[HKLM_]

PtrO schreef op zondag 4 augustus 2019 @ 00:06:
[...]

Niet updaten .... ik zou niet weten waarom dat nodig is.. (natuurlijk ken ik de virus/update maffia).

Die oude winbak doet kan van alles zoals domotica,, consolelogging, mail, websites, sensor reading etc.etc en is over de jaren volgeladen met alle gadgets wat ik nu niet meer zou doen. Ben wel bezig om functies weg te bouwen naar de QNAP of rPI zoals eerder Exchange en recentelijk m'n Asterisk/Voip centrale.

Lees je tekst nog eens als je dan nog niet snapt waarom je wel zou moeten updaten dan weet ik niet of it / hobbie it iets voor je is

Veel succes i.i.g met je project verder hopelijk steek je er wat van op en denk je aan je security.

[PtrO]

MewBie schreef op zaterdag 3 augustus 2019 @ 23:54:
[...]

Nee, waarom zou DHCP de mogelijkheid hebben om een response te vertragen? Je wilt die zooi zo snel mogelijk afhandelen. Om te zorgen voor high availability (wat jij in feite probeert te bereiken) ondersteunen DHCP servers dus failover, load balancing en andere features.

En nee, dat gaat waarschijnlijk niet werken als je probeert 3 verschillende DHCP software paketten te combineren. Dus moet je er 2 dumpen en van die 3de een extra instantie draaien en dan beide DHCP servers juist configureren.

Dit heet in de box denken (nofi), ik ga/wil er juist (weet ik) buiten omheen.

[brainstorming modus]

Dat iets snel bedoeld lijkt te zijn wil niet zeggen dat er geen reden voor is om het te willen vertragen.
Los van DHCP kan ik genoeg opnoemen waar vertraging van netwerkprotocollen juist gewenst is, al was het maar om dan "verkeer" te kunnen doseren. Verkeer van stel http poort 8080 is dan langzamer/sneller dan die van poort 9090. Met de port/firewall regel je dan wie over/met welke poort babbelt.

Een andere oplossing is mogelijk een centrale switch (of routertje) tussen te zetten die selectief de DHCP pakketjes inspecteert en dan daaruit de OFFERS prioriteert. Hiervoor moet je dan de firmware aanpassen wat ik sws niet wil. Handiger is dan de HDCP software op m'n QNAP.

Nu ik daar nog verder over nadek kan ik de verschillende servers ook proberen aan en uit te zetten. Zolang DHCP op de Window het doet, schakel ik dhcp op de QNAP en ROUTER. Wanneer de Windows onbereikbaar is, schakel ik die van de QNAP resp. FRITZ/router in. Dit kan relatief eenvoudig met een los Raspberry PI (of nog simpeler met een esp8266 microcontroller die CLI telnet/commandoś stuurt of zo). Je brengt mij wel op een uitvoerbaar idee. Thanks.

[/brainstorming modus]

[PtrO]

HKLM_ schreef op zondag 4 augustus 2019 @ 00:13:
[...]


Lees je tekst nog eens als je dan nog niet snapt waarom je wel zou moeten updaten dan weet ik niet of it / hobbie it iets voor je is

Veel succes i.i.g met je project verder hopelijk steek je er wat van op en denk je aan je security.

Thx, gaat goedkomen. Twee ideetjes zo tokkelend opgedaan: alsnog DHCP software aanpassen of (beter) een watchdog monitor die de gewenste DHCP server aan/uitzet.

Offtopic: Heb wat sporen verdiend en het goud wat niet blinkt, ligt op de plank.

Ik snap uitstekend waarom je dingen moet of zou willen doen wat niet wil zeggen dat dit altijd toepasselijk is. Dat is wat ik anderen graag meegeef. Ga niet als een dolle bewegen zonder te weten waartoe en waarheen.

Vraag je zelf altijd af waarom je (niet of juist wel) gaat updaten en met virtualisatie kan je oude zaken een glansrijke toekomst geven. Mogelijk niet meer in de boze buitenwereld maar prima voor in het huis. Dat er nu laserLED lampen zijn wil niet zeggen dat je dan dus ook je werkende gloeilamp in de kelder moet vervangen.

[PtrO]

CyBeR schreef op zaterdag 3 augustus 2019 @ 23:51:
[...]


Je vindt als je een stukje omhoog scrollt ook al wat bevestiging. Wat je wilt kan niet.

(Los van dat 3 dhcp servers voor thuis compleet bullshit is. Kies 1 van je opties die het minst stuk is en gebruik die gewoon.)

Ik reageer toch even om de algehele gedachtenzetting wat positief te beïnvloeden.

Ik heb weinig boodschap aan "kan niet"; prima als dat nu ECHT zo is (waar he top lijkt) wat voorts DAN reden kan zijn het WEL te maken.
Mijn hobby/werk is vooral datgene wat niet kan, wel te doen. Zolang ik daar huis en haard niet mee beschadig, zie ik geen belemmering.

Dat 3 servers bullshit zijn is meer kwalitatieve gedachtbeperking. Ik kan zo redenen hebben om er 10 te plaatsen, voor elke vLAN, of zelfs 300 die elk hun eigen IP range afhandelt of zelfs per tijdslot.
Net als dat ik ook Het met één afkan waarbij je dan geen failback hebt etc.etc..
Dit is niet om het belachelijk te maken maar om, te schetsen dat er redenen zijn die je je misschien niet kunt voorstellen. het is dan wat positiever om je afkeuring voor je te houden.

Wel oprecht bedankt voor alle input, meendenkerij wat mij iig de bevestiging geeft dat het er op lijkt dat het NIET kan in de huidige opzet. Het wordt dus programmeren (dhcp source) of orchestreren (monitoring aan/uitzetten serverfunctie).

Thx.

[CyBeR]

PtrO schreef op zondag 4 augustus 2019 @ 00:45:
[...]
Ik heb weinig boodschap aan "kan niet"; prima als dat nu ECHT zo is (waar he top lijkt) wat voorts DAN reden kan zijn het WEL te maken.
Mijn hobby/werk is vooral datgene wat niet kan, wel te doen. Zolang ik daar huis en haard niet mee beschadig, zie ik geen belemmering.

Het kan niet. Het DHCP protocol ondersteunt dit niet. Daar wordt gewoonlijk omheen gewerkt door twee (of meer) DHCP servers verschillende ranges te laten uitgeven binnen hetzelfde subnet.

Dit is niet om het belachelijk te maken maar om, te schetsen dat er redenen zijn die je je misschien niet kunt voorstellen. het is dan wat positiever om je afkeuring voor je te houden.

Ik keurde niks af totdat je me negeerde.

Wel oprecht bedankt voor alle input, meendenkerij wat mij iig de bevestiging geeft dat het er op lijkt dat het NIET kan in de huidige opzet. Het wordt dus programmeren (dhcp source) of orchestreren (monitoring aan/uitzetten serverfunctie).

In Linux zou je de uitgaande DHCP respons kunnen vertragen. Maar success daarmee met windows en je fritzbox.

[Room42]

@PtrO Er zijn wel mogelijkheden maar je schrijft zooo veel waar ik niks mee kan dat het werkelijk TL;DR geworden is en dat ik niet weet waar ik moet beginnen. Maar wat is er mis met de oplossing in mijn eerste post?
Verder hoop ik je op professioneel gebied leert dat je nu echt fout/onbeheersbaar bezig bent.

[chaoscontrol]

Grappig hoe iedereen over 2k3 valt maar bijna alle consumenten meuk routers met dhcp op een oude ongepatche linux kernel draaien.

[Room42]

chaoscontrol schreef op zondag 4 augustus 2019 @ 00:49:
Grappig hoe iedereen over 2k3 valt maar bijna alle consumenten meuk routers met dhcp op een oude ongepatche linux kernel draaien.

Dat is absoluut ook een probleem, maar die hebben wel een stuk kleinere "attack surface".

[ Voor 4% gewijzigd door Room42 op 04-08-2019 00:51 ]

[PtrO]

Grvy schreef op zaterdag 3 augustus 2019 @ 23:46:
@PtrO belachelijk. Echt waar belachelijk. Je hebt een auto met slechte banden en gaat er vervolgens maar vierkante banden en een houten chassis opzetten omdat het _moet_ met kracht en willens tegen elke best practice in zoals jij dat voor ogen hebt.

We zijn er in de IT om veilige grenzen op te leggen aan anderen en die van onszelf te verleggen.
Zoals je je misschien al hebt gemerkt. zit ik vooral in die laatste categorie.

Space the final frontier en boldly go where no man has gone before

[MewBie]

PtrO schreef op zondag 4 augustus 2019 @ 00:20:
[...]

Dit heet in de box denken (nofi), ik ga/wil er juist (weet ik) buiten omheen.

Nee, dat is zorgen dat dingen doen die ze moeten doen.
De taak van een DHCP server is een IP adres reserveren en deze uitgeven, een respons vertragen heeft een negatieve impact op het verlenen van deze service en kan resulteren in een time out vanuit de client omdat deze geen antwoord krijgt binnen de verwachtte tijd.

Even een hypotetische situatie:
- Je hebt 3 DHCP servers, de 1e reageert onmiddelijk, de 2e heeft 1sec vertraging ingebouwd, de 3e heeft 2sec vertraging ingebouwt.
- Een DHCP client verwacht binnen 1,5sec een antwoord of geeft anders een time out en bedenkt zelf een IP adres.
- Server 1 en 2 gaan om wat voor reden dan ook plat.
- Server 3 is nutteloos omdat je client een time out heeft voordat server 3 gereageert heeft.

Als server 1,2 en 3 in een fail over of load balancing setup geconfigureerd waren krijgt de client onmiddellijk een antwoord van 1 van de servers en er kunnen er 2 plat gaan zonder onderbreking van de service.

[brainstorming modus]

Dat iets snel bedoeld lijkt te zijn wil niet zeggen dat er geen reden voor is om het te willen vertragen.
Los van DHCP kan ik genoeg opnoemen waar vertraging van netwerkprotocollen juist gewenst is, al was het maar om dan "verkeer" te kunnen doseren. Verkeer van stel http poort 8080 is dan langzamer/sneller dan die van poort 9090. Met de port/firewall regel je dan wie over/met welke poort babbelt.

Een andere oplossing is mogelijk een centrale switch (of routertje) tussen te zetten die selectief de DHCP pakketjes inspecteert en dan daaruit de OFFERS prioriteert. Hiervoor moet je dan de firmware aanpassen wat ik sws niet wil. Handiger is dan de HDCP software op m'n QNAP.

Dat is QoS, load balancing en misschien nog wat andere dingen gecombineerd en is geen onderdeel van DHCP, net als dat het geen onderdeel is van UDP, TCP/IP, HTTP, FTP, DNS. Al kun je op al die zaken bovengenoemde technieken toepassen.

[PtrO]

Room42 schreef op zondag 4 augustus 2019 @ 00:49:
@PtrO Er zijn wel mogelijkheden maar je schrijft zooo veel waar ik niks mee kan dat het werkelijk TL;DR geworden is en dat ik niet weet waar ik moet beginnen. Maar wat is er mis met de oplossing in mijn eerste post?
Verder hoop ik je op professioneel gebied leert dat je nu echt fout/onbeheersbaar bezig bent.

Ik had hier d8 op gereageerd..... inclusief je voorspelling dat ik met "win2k3" op staande voet overhoop zou worden geschoten.

Room42 schreef op zaterdag 3 augustus 2019 @ 19:25:
Maar goed, als je niet de controle over de DHCP-servers hebt, kun je ook zorgen dat ze naast elkaar werken, door elk hun eigen pool toe te wijzen binnen hetzelfde subnet. En als ~80 hosts (240 verdeeld over 3 DHCP-servers) te weinig is, kun je ook je subnet uitbreiden. In plaats van een /24 subnet neem je dan /23, bijvoorbeeld. Dan zul je wellicht wel meer van je infra moeten herzien.

Ik neem overigens aan dat dit niet om een bedrijfsnetwerk gaat! Anders...

Ik ga er even iet meer technisch op in. Het gaat idd niet om een bedrijfsnetwerk, hoewel het daar - in size en complexity - zonder meer mee kan concurreren. Dikdoenerij is verder niet relevant.

Ik heb nu 3 dhcp servers die elk hun eigen geisoleerde IP ranges versturen, dus ik heb geen ruzie qua duplicaten of overlap.

Je prima suggestie voor subnet indeling is daarmee dan ook niet nodig. Mijn een DHCP server doet zeg Host range 10-63 de tweede 64-127 en de derde 128-195. Ieder met dezelfde secundaire DNS ( m'n externe DNS bij Amazon) en primair het als DNS die van de DHCP die reageerd op het REQUEST en het OFFER aanbiedt.
Afhankelijk van welke DHCP server het IP adres afgeeft, gebruikt die dan ook de DNS/IP adres van die specifieke DHCP server. Dit "geintje" haal ik ook uit voor andere DHCP parameters (tijd, bootp etc.)

Het probleem wat ik nu heb is dat er dus 3 DHCP actieve servers zijn waarbij de snelste prima werkt maar heel soms door een slowdown, een hostrequest tussendoor schiet wat dan weer een dag duurt (leasetime 24h) voordat die weer bij is gekomen in het lease domain van de normale DHCP (mijn winbox)

Mijn IoT clients zijn zo ingericht dat wanneer zij geen van de twee DNS-servers kunnen adresseren, zij gaan herstarten en daarmee dan een nieuw IP adres krijgen van een DAN wel bereikbare DHCP server en dus daarmee OOK een primaire werkende DNS.

Ik heb ook zitten denken om mijn probleem via DNS op te lossen waarvoor ik de in het Ip protocol ingebakken DNS-resolver moet zin te bewerken wat een redelijk complexe zaak kan zijn. In mijn IBM tijd (toen alles nog kon ) heb ik dat wel gedaan en had er schoon genoeg van. DHCP omdat het een zelfstandige service is, is veel makkelijker; hoewel ik de source daarvoor nog moet/ga bekijken.

Ik hoop dat dit wat verduidelijkt.

Ik heb iig met al jullie input voldoende antwoord dat ik het buitenom ga oplossen. De kans dat er een gedocumenteerde parameter is, is zo goed als uitgesloten. Het werkend krijgen met balancing zou kunnen maar betekent (nog) meer, laat staan nieuwe "moeilijke" servers dan ik mijzelf wil toestaan.

Thx2all.

Grtz. Peter

[PtrO]

Mijn reactie gaat way offtopic doe ik omdat mijn reageerders daartoe wat uitnodigen.
TLDR; wanneer het in IT niet KAN, ga je het maken en als het niet MAG laat je het WERKEN.

MewBie schreef op zondag 4 augustus 2019 @ 00:57:
[...]

Nee, dat is zorgen dat dingen doen die ze moeten doen.
De taak van een DHCP server is een IP adres reserveren en deze uitgeven, een respons vertragen heeft een negatieve impact op het verlenen van deze service en kan resulteren in een time out vanuit de client omdat deze geen antwoord krijgt binnen de verwachtte tijd.

Even een hypotetische situatie:
- Je hebt 3 DHCP servers, de 1e reageert onmiddelijk, de 2e heeft 1sec vertraging ingebouwd, de 3e heeft 2sec vertraging ingebouwt.
- Een DHCP client verwacht binnen 1,5sec een antwoord of geeft anders een time out en bedenkt zelf een IP adres.
- Server 1 en 2 gaan om wat voor reden dan ook plat.
- Server 3 is nutteloos omdat je client een time out heeft voordat server 3 gereageert heeft.

Als server 1,2 en 3 in een fail over of load balancing setup geconfigureerd waren krijgt de client onmiddellijk een antwoord van 1 van de servers en er kunnen er 2 plat gaan zonder onderbreking van de service.


[...]

Dat is QoS, load balancing en misschien nog wat andere dingen gecombineerd en is geen onderdeel van DHCP, net als dat het geen onderdeel is van UDP, TCP/IP, HTTP, FTP, DNS. Al kun je op al die zaken bovengenoemde technieken toepassen.

Je hebt helemaal gelijk..... maar IT is geen heilig huis en kan toch ook anders gebruikt worden ?...... zo evolueren zaken nu eenmaal.
Dat mensen dit RFC in de hand het misbruik noemen en dat je het daarom beter niet aanbiedt is wat anders. Dan herschrijf je de RFC maar of voeg je er één toe. Voor je het weet wordt je anders voor gek versleten.
Ik ben zelf totaal niet van de wetgeving, weet uitstekend hoe het (niet) moet en in m'n hobby/research negeer ik alles. Daar maak ik zelf wel uit wat moet/mag/kan/is.

Wat is er op tegen om DHCP zo in richtten en aan te passen aan wensen; en als de reactietijden te lang zijn, verkort je ze naar iets wat wel acceptabel is voor een standaard client ? etc.etc.

Dat QoS geen gerichte taakstelling heeft voor zeg DHCP wil niet zeggen dat je dat niet kan laten worden. Kwestie van het "denken" even anders gaan "bedenken".
Alles wat er nu is, is ook maar bedacht door illustere voorgangers.
En wij, jij ?, gaat dingen doen die onze kleinkinderen dan weer als wetmatig gaan aannemen.

Ik kan mij zelfs voorstellen, ga ik niet doen = te veel zinloos werk, dat ik mijn eigen DHCP serversoftware ga schrijven. die gelijk 2FA authenticatie, logging en billing doet, inclusief een meegebouwde failover/monitoring voorziening.
Die software crosscompile je vervolgens voor windows/XXbit, linux/armv7 en Fritz/mips32. Allemaal nog meer werk, vooral bijeenzoeken van software libraries, Onzinnig voor een "flesje Sourcy"(mineraalwater) wat leuk is wanneer je niets beter te doen hebt. Om daarna in de shithole-loop te komen dat bij elke update/upgrade/aanpassing mee te moeten nemen.

My 2cts

[PtrO]

Thx.

Brahiewahiewa schreef op zaterdag 3 augustus 2019 @ 23:27:
....Nou, het is vooral niet slim om hedentendage nog windows 2k3 te gebruiken; zowel slimme als minder slimme mensen gaan dan denken dat je dom bent ;o)
....

Zelfs het in je mond nemen is al vergif.
Tja dat had ik mij vooraf moeten realiseren, net of je een rode lap ophangt en vervolgen als sitting-duck door de stieren afgeschoten te worden. Valt mij wel tegen dat reaguurders zich zo laten (be)sturen door ingepeperde marketing. Het werkt wel.. zelfs zo goed dat er zelfs in niets meer overblijft van de boodschap.

Ik krijg nu al een angstbeeld ....... oh dat is die gast met.... brrrr... het kost je 10 jaar om er te komen en je bent het in 10 seconden allemaal kwijt .

Slaap op droom lekker allemaal.

[plizz]

Als je switch DHCP snooping ondersteunt, bereik je wat je wil. De Win 2k3 en Qnap zet je in untrtust "default" en de poort naar fritzbox zet je op trust. Zo ontvangt de clients in je niet nooit de DHCP offer van die twee machine.

[Koffie]

Alles is wel al gezegd in dit topic. TS wil eigenwijs een oud OS draaien Daar kun je iets over roepen en wat feiten bij vertellen maar het blijft zijn keus en verantwoordelijkheid. Einde discussie.
Dan het DHCP verhaal, ook genoeg verteld hier, kan niet. Einde discussie.

Toch wat technische kanttekeningen van mijn kant: stop met het krampachtig vasthouden aan 3(!) DHCP servers in een thuisnetwerkje. Zelfs zakelijk ga je pas nadenken over meerdere DHCP servers wanneer je meerdere vestigingen bediend. Als jou DHCP server thuis vaak uitvalt is er iets anders aan de hand dan dat je je zorgen over een chain DHCP servers moet maken (wellicht zit er een bug in je Windows 2003 DHCP server? )
Leuk dat jet het wil kunnen, maar er is eigenlijk geen enkele legitieme reden voor anders dan 'gewoon omdat ik het leuk vind',
Sowieso mag je DHCP prima om donderen in zo'm omgeving. Zet een leasetijd van 24 uur en je clients hobbelen vrolijk verder wanneer je DHCP server omgevallen is. Het word pas een uitdaging wanner clients online komen die langer dan 24 uur uit zijn geweest of clients die al langer dan 24 uur online zijn.
Verleng je lease naar 7 dagen en je hebt dagen om de boel te fiksen zonder dat er een client vervelend doet.

Ben je nou echt paranoia om je windows DHCP server, maak dan een scrippie op je Qnap of een pi of een docker die elke 10 minuten een DHCP broadcast doet. Zodra er geen response meer is van je hoofd DHCP server start je je fallback DHCP server.