---

Jeg styrer et netværk, hvor der i spidsbelastningerne er ca. 400
computere tilsluttet på lokalnettet. Vi bruger ISC DHCPD både til IPv4
og IPv6 (IPv6 statefull opsætning med radvd + isc-dhcpd6), og begge
steder fungerer det hele faktisk ganske udmærket.

Men jeg har ét problem: dhcpd6.leases filen bliver voldsomt stor... Og
efter et par dages kørsel af isc-dhcpd6 bliver files så stor, at vores
IPv6 DHCPD kører meget trægt. Rent praktisk har jeg igennem de senere
måneder hver nat kørt et cron-script, der stopper isc-dhcpd6, sletter
denne dhcpd6.leases fil og derefter starter isc-dhcpd6 igen. Og dagen
efter modtager klienterne nye leases, filen genopbygges igen og det hele
fungerer.

Det er kun vores stationære maskiner, serverne og enkelte bærbare
maskiner, der har faste IPv6 adresser. Resten af maskinerne tildeles
bare tilfældige adresser i en del af vores IPv6-adresseområde.

Og nu kommer spørgsmålet:
Er der nogle af jer, der har erfaringer med at bruge LDAP (fx OpenLDAP)
som backend for disse leases i ISC DHCPD?

Jeg gætter på, at problemet med størrelsen af dhcpd6.leases filen hænger
sammen med, at dataene gemmes i relativt simpel tekststruktur, hvor der
gemmes ret mange data for hver af klienterne. Og dette kunne gøres mere
effektivt i en LDAP-struktur... Og yderligere ville søgningen efter
klientdataene køre væsentligt mere effektivt.

Mvh. Jacob Tranholm

---

Jacob Tranholm <jt@drlund-gym.dk> writes:

> Men jeg har ét problem: dhcpd6.leases filen bliver voldsomt stor... Og
> efter et par dages kørsel af isc-dhcpd6 bliver files så stor, at vores
> IPv6 DHCPD kører meget trægt. Rent praktisk har jeg igennem de senere
> måneder hver nat kørt et cron-script, der stopper isc-dhcpd6, sletter
> denne dhcpd6.leases fil og derefter starter isc-dhcpd6 igen. Og dagen
> efter modtager klienterne nye leases, filen genopbygges igen og det

Lyder mere som en fejl me ICS DHCPS end noget du skal hakke dig udenom
med LDAP.

Det er open source software. Er der fejlrapporter om problemet? Det
kan være en banal ting du mangler at sætte eller gøre...
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

On Mon, 31 Oct 2011 09:19:40 +0100
Jacob Tranholm <jt@drlund-gym.dk> wrote:

> Er der nogle af jer, der har erfaringer med at bruge LDAP (fx OpenLDAP) som backend for disse leases i ISC DHCPD?
>
> Jeg gætter på, at problemet med størrelsen af dhcpd6.leases filen hænger sammen med, at dataene gemmes i relativt simpel tekststruktur, hvor der gemmes ret mange data for hver af klienterne. Og dette kunne gøres mere effektivt i en LDAP-struktur... Og yderligere ville søgningen efter klientdataene køre væsentligt mere effektivt.
>
I sagens natur vil en leasesfil, afhængig af antal klienter og Expire
time, være en særdeles skrivetung opgave. LDAP er i sin natur beregnet
på få skrivninger og mange læsninger/søgninger, hvorfor LDAP vil være et
overordentlig dårlig valg til opgaven.

Et væsentligt bedre valg kunne være, at lade dhcpd skrive til en
RAM-disk. Se
http://www.howtoforge.com/storing-files-directories-in-memory-with-tmpfs

[mir@sleipner]$ sudo mount -t tmpfs -o size=250m tmpfs /opt/data
[mir@sleipner]$ time dd if=/dev/zero of=/opt/data/test count=400000
bs=512
400000+0 records in
400000+0 records out
204800000 bytes (205 MB) copied, 0,431175 s, 475 MB/s

real   0m0.434s
user   0m0.044s
sys   0m0.388s
[mir@sleipner]$ time dd if=/dev/zero of=/tmp/test count=400000 bs=512
400000+0 records in
400000+0 records out
204800000 bytes (205 MB) copied, 0,886364 s, 231 MB/s

real   0m0.889s
user   0m0.056s
sys   0m0.796s

--
Hilsen/Regards
Michael Rasmussen
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

Den 31-10-2011 18:28, Michael Rasmussen skrev:
> On Mon, 31 Oct 2011 09:19:40 +0100
> Jacob Tranholm<jt@drlund-gym.dk> wrote:
>
>> Er der nogle af jer, der har erfaringer med at bruge LDAP (fx OpenLDAP) som backend for disse leases i ISC DHCPD?
>>
>> Jeg gætter på, at problemet med størrelsen af dhcpd6.leases filen hænger sammen med, at dataene gemmes i relativt simpel tekststruktur, hvor der gemmes ret mange data for hver af klienterne. Og dette kunne gøres mere effektivt i en LDAP-struktur... Og yderligere ville søgningen efter klientdataene køre væsentligt mere effektivt.
>>
> I sagens natur vil en leasesfil, afhængig af antal klienter og Expire
> time, være en særdeles skrivetung opgave. LDAP er i sin natur beregnet
> på få skrivninger og mange læsninger/søgninger, hvorfor LDAP vil være et
> overordentlig dårlig valg til opgaven.
>
> Et væsentligt bedre valg kunne være, at lade dhcpd skrive til en
> RAM-disk. Se
> http://www.howtoforge.com/storing-files-directories-in-memory-with-tmpfs
>
> [mir@sleipner]$ sudo mount -t tmpfs -o size=250m tmpfs /opt/data
> [mir@sleipner]$ time dd if=/dev/zero of=/opt/data/test count=400000
> bs=512
> 400000+0 records in
> 400000+0 records out
> 204800000 bytes (205 MB) copied, 0,431175 s, 475 MB/s
>
> real   0m0.434s
> user   0m0.044s
> sys   0m0.388s
> [mir@sleipner]$ time dd if=/dev/zero of=/tmp/test count=400000 bs=512
> 400000+0 records in
> 400000+0 records out
> 204800000 bytes (205 MB) copied, 0,886364 s, 231 MB/s
>
> real   0m0.889s
> user   0m0.056s
> sys   0m0.796s
>

Mange tak for rådet... Jeg tror, at du har helt ret i, at problemet er
skrivehastigheden til harddisken. Og jeg vil derfor følge dit råd og
prøve med en RAM-disk i stedet.

Mvh. Jacob Tranholm

---

Jacob Tranholm <jt@drlund-gym.dk> writes:

> Men jeg har ét problem: dhcpd6.leases filen bliver voldsomt stor... Og
> efter et par dages kørsel af isc-dhcpd6 bliver files så stor, at vores
> IPv6 DHCPD kører meget trægt.

Traditionelt er problemet med DHCP at protokollen forlanger at leases er
skrevet til disk før de bliver givet til klienter. Med en traditionel
7200RPM-disk er man nede på 120 IOPS, og det kan man nemt ramme.
Specielt ext3-filsystemer har det rigtigt skidt med fsync.

Der er flere mulige løsninger.

https://lists.isc.org/pipermail/dhcp-users/2010-July/011592.html siger
at isc-dhcpd 4.1 implementerer flere leases pr sync. Det er den rigtige
løsning men jeg ved ikke om det findes i isc-dhcpd6.

RAM-disk som blev foreslået af Michael Rasmussen virker fint, men man
overholder ikke protokollen -- med mindre man kan garantere at
skrivningerne altid når en rigtig disk i tilfælde af nedbrud. (Det kan
man i øvrigt aldrig i praksis på moderne maskiner, RAM-disk eller ej.)

SSD'er er en let løsning, men vær opmærksom på at hver skrivning slider
på disken.

Et filsystem der har det bedre med fsync(). XFS måske, eller endnu bedre
BTRFS hvis du tør.


/Benny

---

Den 31-10-2011 19:36, Benny Amorsen skrev:
> Jacob Tranholm<jt@drlund-gym.dk> writes:
>
>> Men jeg har ét problem: dhcpd6.leases filen bliver voldsomt stor... Og
>> efter et par dages kørsel af isc-dhcpd6 bliver files så stor, at vores
>> IPv6 DHCPD kører meget trægt.
>
> Traditionelt er problemet med DHCP at protokollen forlanger at leases er
> skrevet til disk før de bliver givet til klienter. Med en traditionel
> 7200RPM-disk er man nede på 120 IOPS, og det kan man nemt ramme.
> Specielt ext3-filsystemer har det rigtigt skidt med fsync.
>
> Der er flere mulige løsninger.
>
> https://lists.isc.org/pipermail/dhcp-users/2010-July/011592.html siger
> at isc-dhcpd 4.1 implementerer flere leases pr sync. Det er den rigtige
> løsning men jeg ved ikke om det findes i isc-dhcpd6.
>
> RAM-disk som blev foreslået af Michael Rasmussen virker fint, men man
> overholder ikke protokollen -- med mindre man kan garantere at
> skrivningerne altid når en rigtig disk i tilfælde af nedbrud. (Det kan
> man i øvrigt aldrig i praksis på moderne maskiner, RAM-disk eller ej.)
>
> SSD'er er en let løsning, men vær opmærksom på at hver skrivning slider
> på disken.
>
> Et filsystem der har det bedre med fsync(). XFS måske, eller endnu bedre
> BTRFS hvis du tør.
>
>
> /Benny

Du og Michael har uden tvivl ret i, at problemet er skrivehastigheden
til harddisken. Der bruges EXT4 som filsystem på denne partition. Udfra
benchmarks burde EXT4 være lige så hurtigt som XFS, men ydelsesmæssigt
kan det vist ikke matche BTRFS. Jeg har faktisk aldrig prøvet BTRFS...
Jeg er nok lidt konservativ angående filsystemerne, hvor jeg på de ældre
servere hovedsageligt anvender XFS, og på de nyere anvender jeg
hovedsageligt EXT4 (på alle anvendes EXT2 til boot partitionerne). For
år tilbage havde jeg en forkærlighed for reiserfs (godt til mange små
filer), men her standsede hele udviklingen beklageligvis da Hans Reiser
tog sin længere ferie bag tremmer.

Jeg er lidt tilbøjelig til at følge Michael Rasmussens råd om at bruge
en RAM-disk. Dette kan meget vel være en bøjning af reglerne, men det er
min nuværende løsning med at slette leases-filerne i et natligt cronjob
jo også, og RAM-disken vil trods alt være mindre drastisk. Og denne
server genstartes typisk kun en enkelt eller 2 gange om året.

Jeg kunne muligvis også have løst problemet ved at have lavet en lille
partition med RAID-0, men så ville serveren jo gå ned, hvis én af
harddiskene strejkede, og det vil jeg ikke risikere.

Så jeg ender nok med at bøje reglerne og bruge en RAM-disk til disse
leases...

Mvh. Jacob Tranholm

---

On 31-10-2011 22:50, Jacob Tranholm wrote:

<KLIP>


> Så jeg ender nok med at bøje reglerne og bruge en RAM-disk til disse
> leases...
>
> Mvh. Jacob Tranholm

Skal det være helt corny, kunne du jo lægge LVM på RAM-disken og så
snapshot'e til fastpladelager med jævne mellemrum


--
Steen Suder

---

On Mon, 31 Oct 2011 22:57:09 +0100
Jacob Tranholm <jt@drlund-gym.dk> wrote:

>
> Mange tak for rådet... Jeg tror, at du har helt ret i, at problemet er skrivehastigheden til harddisken. Og jeg vil derfor følge dit råd og prøve med en RAM-disk i stedet.
>
Bemærk at ovenstående er sekventiel skrivning, for tilfældige
skrivninger vil forskellen være endnu større, da RAM-disken ikke er
underlagt mekaniske love

--
Hilsen/Regards
Michael Rasmussen
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

Den 31-10-2011 23:09, Michael Rasmussen skrev:
> On Mon, 31 Oct 2011 22:57:09 +0100
> Jacob Tranholm<jt@drlund-gym.dk> wrote:
>
>>
>> Mange tak for rådet... Jeg tror, at du har helt ret i, at problemet er skrivehastigheden til harddisken. Og jeg vil derfor følge dit råd og prøve med en RAM-disk i stedet.
>>
> Bemærk at ovenstående er sekventiel skrivning, for tilfældige
> skrivninger vil forskellen være endnu større, da RAM-disken ikke er
> underlagt mekaniske love
>

Indtil nu fungerer det hele i hvert fald med RAM-disken. Og jeg bilder
mig faktisk også ind, at klient-maskinerne modtager deres IP-adresser
hurtigere. Tidligere har jeg i sjældne tilfælde set, at klientmaskinerne
har skullet vente i et par sekunder på disse IP-adresser, og nu kommer
de næsten øjeblikkeligt (i mine få tests). Jeg har dog ikke lavet
systematiske tests, og dette er udelukkende baseret på den meget
uvidenskabeligt metode, der er min fornemmelse af tingene.

Mvh. Jacob Tranholm

---

On Tue, 01 Nov 2011 07:50:24 +0100
Steen Suder <steen@suder.dk> wrote:

>
> Skal det være helt corny, kunne du jo lægge LVM på RAM-disken og så snapshot'e til fastpladelager med jævne mellemrum
>
>
Så ryger hele performance gevindsten, LVM bør ikke vælges såfremt, man
går efter højeste skrivehastighed.

--
Hilsen/Regards
Michael Rasmussen
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

Michael Rasmussen <mir@miras.org> writes:

> On Tue, 01 Nov 2011 07:50:24 +0100
> Steen Suder <steen@suder.dk> wrote:
>
>>
>> Skal det være helt corny, kunne du jo lægge LVM på RAM-disken og så snapshot'e til fastpladelager med jævne mellemrum
>>
>>
> Så ryger hele performance gevindsten, LVM bør ikke vælges såfremt, man
> går efter højeste skrivehastighed.

Er det mig der har misforstået noget eller SKAL en DHCP server med op
til 400 klienter have så meget disktraffik at en almindelig harddisk
ikke kan følge med?
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Den 01-11-2011 08:51, Thorbjørn Ravn Andersen, 20111101 skrev:
> Er det mig der har misforstået noget eller SKAL en DHCP server med op
> til 400 klienter have så meget disktraffik at en almindelig harddisk
> ikke kan følge med?

Jeg forstår det heller ikke helt... Men her skal du tænke på, at for
IPv4 DHCP fungerede det hele som ønsket med den stationære harddisk.
Problemerne ligger kun i IPv6-delen... Og fra loggen kan jeg også se, at
klientmaskinerne forespørger DHCP-serveren ret ofte.

Yderligere skal du også tænke på, at alle nyere browsere ligeledes
sender forespørgsler til DHCP for at modtage proxy-data for netværket.
Dette giver selvfølgelig ingen skrivning til leases-filerne, men det
giver en væsentligt større DHCP-aktivitet og det kunne jo tænkes (jeg
ved det ikke), at dette kræver en læsning af dataene i leases-filerne.

SÃ¥ jeg kan bare konkludere, at der tilsyneladende er mere trafik i
DHCP-delen, og heraf også mere læsning/skrivning til leases-filerne.
Indtil nu fungerer det hele som det skal. Men det er nok for tidligt at
lave konklusioner, da vores DHCP-leases kun har kørt fra RAM-disk siden
i aftes.

Det kan meget vel tænkes, at vores system ville have gavn af en
finetuning. Men det tog mig 2-3 måneder med utallige forskellige
opsætningsforsøg at få vores IPv6 DHCP til at fungere tilbage i den sene
vinter 2010/2011, og jeg vil meget nødigt pille alt for meget ved et
system, der fungerer. Vores DHCP er lidt kompliceret, da vi har flere
forskellige VLANs, der får adresserne (både IPv4 og IPv6) i forskellige
områder. Og alt dette skal jo også samkøres med vores switch-struktur.
Så derfor vil jeg bare være glad, hvis dette med RAM-diskene løser
problemerne. Så kan jeg bare lade systemet fortsætte...

Jeg har dog en mistanke om, hvad der kan give den relativt store
DHCP-trafik. I opsætningsfilerne for vores ISC DHCP er der umiddelbart
ingen indstillinger, der burde give denne større DHCP-trafik. Men jeg
overvejer lidt om problemet kan ligge i vores radvd-opsætning. Her er
der en række indstillinger af fx. MinRtrAdvInterval, MaxRtrAdvInterval,
AdvRouteLifetime,... hvor vi tidsmæssigt er nede i sekunder-området. Og
hvis klient-maskinerne laver en fuld DHCP-forespørgsel i stedet for bare
et tilpasse routingen, ville dette forklare den relativt store
DHCP-trafik. - Men dette er kun en mistanke...

Mvh. Jacob Tranholm

---

On 11/01/2011 10:32 AM, Jacob Tranholm wrote:
> Jeg har dog en mistanke om, hvad der kan give den relativt store
> DHCP-trafik.

Kan du ikke pakkesnuse dig til hvor meget DHCP trafik der er?

Mogens

--
Mogens Kjaer, mk@lemo.dk
http://www.lemo.dk

---

Den 01-11-2011 10:56, Mogens Kjaer skrev:
> Kan du ikke pakkesnuse dig til hvor meget DHCP trafik der er?

Det kunne jeg nok... Men når systemet fungerer, betyder det ikke så
meget for mig. Og vi snakker ikke om store datamængder, men snarere
kvantitativt mange forespørgsler. Og fra logfilen kan jeg jo se alle
forespørgsler.

Yderligere er DHCP jo en besværlig protokol at arbejde med. Jeg har
tidligere forsøgt at opstille firewall regler for at route DHCP fra ét
netværk til et andet. Dette er nogle år siden, og så vidt jeg husker
opgav jeg og fandt i stedet et færdigt program, der lavede arbejdet for
mig. Og helt ærligt gider jeg ikke dette besvær igen... På den anden
side er der vist noget med, at IPv6-delen af DHCP muligvis er nemmere at
arbejde med end IPv4-delen. For IPv6-delen er DHCP så vidt jeg husker
blevet bundet til UDP 546 og UDP 547, og så kunne jeg jo bare overvåge
portene.

Det korte af det lange er, at jeg ikke har tid til at undersøge alt
dette lige nu. Jeg har tidligere haft problemer med at overvåge IPv4
DHCP og kan derfra huske, at der var nogle problemer relateret til
dette. Men dette er så længe siden, at jeg ikke længere kan huske, hvad
problemerne var.

Mvh. Jacob Tranholm

---

nospam0002+20111101@gmail.com (Thorbjørn Ravn Andersen, 20111101)
writes:

> Er det mig der har misforstået noget eller SKAL en DHCP server med op
> til 400 klienter have så meget disktraffik at en almindelig harddisk
> ikke kan følge med?

Det SKAL den ikke, men en naiv implementering af protokollen + et
filsystem som ikke kan lide fsync() kan nemt få det til at ske.

Hardware-RAID5 kan også slå fsync()-performance ihjel, men det er så
ikke problemet i dette tilfælde.


/Benny

---

Den 01-11-2011 11:37, Benny Amorsen skrev:
> Det SKAL den ikke, men en naiv implementering af protokollen + et
> filsystem som ikke kan lide fsync() kan nemt få det til at ske.
>
> Hardware-RAID5 kan også slå fsync()-performance ihjel, men det er så
> ikke problemet i dette tilfælde.
>
> /Benny

Det kan nemt have været problemet også her... Filsystemet kører ikke på
RAID-5, men det kører med et software RAID-10. Og software RAID-10 er et
godt system når vi snakker læsehastigheden af dataene, men for
skrivehastigheden vil software RAID-10 typisk være en lille smule
langsommere end harddiskenes egen hastighed. SÃ¥ RAID-systemet kan meget
vel være en del af problemet...

Mvh. Jacob Tranholm

---

Den 01-11-2011 11:37, Benny Amorsen skrev:
> Det SKAL den ikke, men en naiv implementering af protokollen + et
> filsystem som ikke kan lide fsync() kan nemt få det til at ske.

Angående den naive implementering af protokollen kører dette fra den ISC
DHCP 4.1.1 version, der ikke er blevet forandret i Debian Stable igennem
ret lang tid. Det kunne jo meget nemt tænkes, at der var nogle
ydelsesmæssige forbedringer i 4.2 linjen (ligger i Debian Unstable), men
jeg har ikke turdet tage chancen endnu. Så jeg håber, at ISC DHCP 4.2
linjen snart modnes til Stable-linjen under Debian.

Den naive del kunne selvfølgelig også komme fra min opsætning... Men
dette vælger jeg at ignorere. Men da jeg konfigurerede vores IPv6-system
fandtes der ikke ret mange guides. Der er sidenhen kommet nogle stykker,
og hver gang jeg falder over en guide til opsætningen af ISC DHCP IPv6
nærlæser jeg alle oplysninger i håb om at lære noget nyt. Men når der
kommer mere fuldstændige manualer, vil jeg uden tvivl også opdage, at
vores opsætning mangler et eller andet. Men indtil da stiller jeg mig
tilfreds med, at det fungerer...

Mvh. Jacob Tranholm

---

Den 01-11-2011 12:10, Jacob Tranholm skrev:
> Angående den naive implementering af protokollen kører dette fra den ISC
> DHCP 4.1.1 version, der ikke er blevet forandret i Debian Stable igennem
> ret lang tid. Det kunne jo meget nemt tænkes, at der var nogle
> ydelsesmæssige forbedringer i 4.2 linjen (ligger i Debian Unstable), men
> jeg har ikke turdet tage chancen endnu. Så jeg håber, at ISC DHCP 4.2
> linjen snart modnes til Stable-linjen under Debian.

Dette skal måske forklares lidt yderligere...

Serveren kører faktisk med en Gentoo Linux. Og i min første installation
af ISC DHCPD på denne server installerede jeg net-misc/dhcp fra Gentoo's
"~amd64" udviklingslinje. Og på daværende tidspunkt var dette version
4.2.1. Men denne version kørte højest ustabilt, og det lykkedes ikke for
mig at få den til at køre ordentligt. Og derfor installerede jeg i
stedet en chroot'ed udgave af Debian på serveren, hvor det eneste aktive
program i denne udgave er ISC DHCPD...

Og da version 4 af net-misc/dhcp stadig ligger i "~amd64"
udviklingslinjen under Gentoo, bruger jeg i stedet denne chroot'ede
Debian-udgave. Og det fungerer ganske udmærket.

Så helt generelt glæder jeg mig til enten at version 4 af net-misc/dhcp
bliver regnet som stabil under Gentoo eller at Debian får finpudset
deres udgave af 4.2 linjen.

Mvh. Jacob Tranholm

---

Jacob Tranholm <jt@drlund-gym.dk> writes:

> Den 01-11-2011 08:51, Thorbjørn Ravn Andersen, 20111101 skrev:
>> Er det mig der har misforstået noget eller SKAL en DHCP server med op
>> til 400 klienter have så meget disktraffik at en almindelig harddisk
>> ikke kan følge med?
>
> Jeg forstår det heller ikke helt... Men her skal du tænke på, at for
> IPv4 DHCP fungerede det hele som ønsket med den stationære
> harddisk. Problemerne ligger kun i IPv6-delen... Og fra loggen kan jeg
> også se, at klientmaskinerne forespørger DHCP-serveren ret ofte.

Ret ofte? En moderne harddisk kan sagtens skrive 40 MB/s. Hvis du har
400 klienter i luften, skal HVER af disse klienter foranledige at der
udløses 100 KB der skal skrives _per sekund_.

Der er altså noget galt.

> finetuning. Men det tog mig 2-3 måneder med utallige forskellige
> opsætningsforsøg at få vores IPv6 DHCP til at fungere tilbage i den
> sene vinter 2010/2011, og jeg vil meget nødigt pille alt for meget ved
> et system, der fungerer. Vores DHCP er lidt kompliceret, da vi har

Det du fortæller mig i ovenstående er at du faktisk ikke er 100% klar
over hvordan jeres nuværende opsætning er skruet sammen fordi du har
forsøgt dig frem.

Jeg holder stadig på at der let kan være noget der er sat forkert op,
som kan forklare opførslen.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Benny Amorsen <benny+usenet@amorsen.dk> writes:

> nospam0002+20111101@gmail.com (Thorbjørn Ravn Andersen, 20111101)
> writes:
>
>> Er det mig der har misforstået noget eller SKAL en DHCP server med op
>> til 400 klienter have så meget disktraffik at en almindelig harddisk
>> ikke kan følge med?
>
> Det SKAL den ikke, men en naiv implementering af protokollen + et
> filsystem som ikke kan lide fsync() kan nemt få det til at ske.

Det fatter jeg simpelthen ikke. Er pointen med DHCP ikke at klienterne
kun snakker med serveren for at forny deres lease, og hvis deres
netværkskonfiguration ændrer sig?

Jeg tror forslaget om at lave noget pakkesnifning for at se hvad der er
galt vil være en rigtig god ide.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Jacob Tranholm <jt@drlund-gym.dk> writes:

> Den naive del kunne selvfølgelig også komme fra min opsætning...

Nej. Det er implementationen der sætter begrænsningen. Med mindre du
selv retter i sourcekoden kan du ikke gøre noget ved det.


/Benny

---

Den 02-11-2011 11:58, Benny Amorsen skrev:
> Nej. Det er implementationen der sætter begrænsningen. Med mindre du
> selv retter i sourcekoden kan du ikke gøre noget ved det.
>
> /Benny

Og jeg retter kun sjældent i kildekoden til programmerne... Og i
relation til ISC DHCPD kan jeg med 100% sikkerhed sige, at med mit
nuværende knowhow angående DHCP, vil jeg overlade udviklingen til
eksperterne. SÃ¥ jeg har ikke selv pillet ved denne del...

I relation til Gentoo's specifikke implementering af net-misc/dhcp
pakken har jeg dog mange gange overvejet, at den nuværende
pakke-administrator godt kunne bruge lidt hjælp. Og jeg håber, at der
snart kommer et mere produktivt pakke-administreringsteam i relation til
denne pakke. SÃ¥ hvis der er nogle af jer, der sidder med en god knowhow
om både Gentoo og DHCP, ville dette være et godt sted et bruge et par
timer et par eftermiddage. - Det er forbavsende, at 4.1 pakken har hørt
til i stable-udgaverne ved Debian i månedsvis (så vidt jeg husker siden
en gang i efteråret 2010), men i Gentoo er den stabile pakke version 3.1.3.

Mvh. Jacob Tranholm