Client krijgt wel IP en DHCP opties geen internet en server

[Anoniem: 240093]

Hallo,

ik heb een onregelmatig terugkerend probleem met (waarschijnlijk) DHCP op mijn servers, verspreid over 6 locaties met elk hun eigen domein en geen onderlinge verbinding.
De situatie:

• w2003 ent server NL SP1 met recente updates, ca. 60 clients waaronder (wifi) laptops

• server is domeincontroller, dhcp server, dns server en fileserver, naam SERVER, ip 10.0.0.1

• internettoegang via speedtouch xs4all modem (10.0.0.138) in hetzelfde subnet (10.0.0.0 /24)

• dhcp scope 10.0.0.10-250, opties: gateway 10.0.0.138, dns 10.0.0.1

• op de dns server zijn fwd en reverse zone aangemaakt met doorstuurservers xs4all prim en sec dns ip

Alles werkt al een aantal jaar zo en draait prima. De clients kunnen op de server en op internet etc.
Het probleem is dat er af en toe een client niet op internet of de server kan. Dit zijn meestal laptops die nog niet eerder op het netwerk zijn geweest, maar ook soms clients die er al een tijdje aan hangen. Bij controle lijken op het eerste gezicht alle essentiele opties goed met DHCP te zijn meegekomen:

• IP adres is correct en staat ook in DHCP lease op server aan juiste pc-naam gekoppeld

• gateway en dns adressen zijn correct

Een ping op naam naar "server" vanaf de betreffende client werkt niet, maar ook niet naar het ip van de server (10.0.0.1). Fysiek is de verbinding in orde, want DHCP werkt wel. Daarnaast is het wel mogelijk het gateway adres (modem) te bereiken met ping, maar ook op de webinterface...alle 7 laagjes van het OSI-model werken dus .

Mijn oplossing voor dit probleem is een tijdelijke:

• ik verwijder de lease van de client op de dhcp server

• ik gooi het betreffende ip in het uitsluitingsbereik van de scope

• ik schakel de netwerkverbinding uit en weer in op de client

De client krijgt nu een ander IP adres toegewezen en dan werkt het wel. Als ik vervolgens het "rotte" IP adres weer aan de scope toevoeg en een andere client krijgt dit op een later tijdstip, is er ook geen probleem. Helaas is dit geen structurele oplossing en kan er weer een andere client opduiken met hetzelfde probleem. Bijkomend nadeel is dat ik slechts 1x per week op een locatie aanwezig ben, dus op zoek ben naar een structurele oplossing.

Ik heb al wat research op het net hierop gedaan en het probleem aan verschillende mensen voorgelegd, maar tot nu toe geen resultaat. Dingen die ik geprobeerd heb naast de bovenstaande oplossing (en me nog kan herinneren ) : ARP cache leeggehaald op de client, DHCP scope verwijderd en opnieuw gemaakt.

Ik vermoed dat het iets met DHCP en dan specifieker met de DNS optie te maken heeft. Dit denk ik omdat de gateway wel bereikbaar is, maar "het internet" niet. Ik vind het ook vreemd dat de server niet benaderbaar is per ping op ip-adres. Dit verklaart natuurlijk wel waarom er geen webpagina's kunnen worden weergegeven, aangezien de DNS op de server draait en dat hele zaakje niet bereikbaar is (ping 10.0.0.1, Doelhost niet gevonden).

Heeft er iemand suggesties? Alvast bedankt en excuus voor het lange verhaal

[Anoniem: 240093]

Niemand?

[kevlar]

heeeel vaag probleem..

Het lijkt mij een probleem op layer 2 of mischien op layer 3. aan de hand van jou verhaal trek ik niet de conclusie dat dhcp of dns het probleem is. de client krijgt tenslotte gewoon een ip adres met alle opties. en hij kan de dns server zelfs niet pingen, dit geeft dus geen aanleiding om te denken dat dns het probleem is.

mijn gevoel zegt dat je switch wel eens het probleem zou kunnen zijn. afgaande op jou omschrijving kan het probleem alleen aan de kant van de client zitten of aan de kant van je switch. maar goed, ik begrijp dat je het probleem op alle 6 locaties hebt. de kans dat je hier overal de zelfde switches hebt staan schat ik laag in.

Als je het nog eens hebt, reboot je switch dan eens om te zien of het is opgelost.

verder vraag ik mij af of je bepaalde firewall software gebruikt op je clients. dit zou het probleem ook nog wel eens kunnen veroorzaken.

succes ermee.

[bazkar]

Dit is een laag 2 probleem als het een netwerk probleem is. Waarom? Nou, je server staat in het subnet van de clients en dus hoeft er niet gerouteerd te worden door je modem/router als je die probeert te pingen.

Routeproblemen (laag 3) kunnen we voorlopig dus even uitsluiten.
Hoe ziet de ARP tabel van de machine eruit als er geen connectivity meer is? En van de server en de router?
Staat je server dan wel in de arp tabel van de machine? (arp -a vanaf command line) en vice versa?
Installeer eens een sniffer (wireshark) op die machine als het mis is. Zie je dan wel broadcast paketten weg gaan? (Who is 10.0.0.1? achtige paketten).
Is er iets te zien in de DHCP log van de server? Hebben de machines 'meteen' dit probleem als ze de netwerkkabel erin prikken of na verloop van tijd (dus als ze een tijdje wel connectivity gehad hebben).

Als het een probleem met de switch is, zou je ook je gateway niet meer kunnen pingen.
Het rare is dus dat je wel je gateway kan pingen, en dat ANDERE machines nog wel je server kunnen pingen.
Erg raar...

[Anoniem: 240093]

Allereerst bedankt voor de reacties!

kevlar schreef op vrijdag 16 november 2007 @ 16:48:
mijn gevoel zegt dat je switch wel eens het probleem zou kunnen zijn. afgaande op jou omschrijving kan het probleem alleen aan de kant van de client zitten of aan de kant van je switch. maar goed, ik begrijp dat je het probleem op alle 6 locaties hebt. de kans dat je hier overal de zelfde switches hebt staan schat ik laag in.

Als je het nog eens hebt, reboot je switch dan eens om te zien of het is opgelost.

Switches zijn op alle locaties vrijwel hetzelfde: 3com baseline switches (niet het duurste model, maar toch). Even een switch resetten zullen de meeste gebruikers niet waarderen , maar ben in voor elke oplossing...blijft vreemd dat als ik de pc een ander ip adres "dwing" te gaan gebruiken (zoals eerder beschreven) dat het dan wel werkt.

kevlar schreef op vrijdag 16 november 2007 @ 16:48:
verder vraag ik mij af of je bepaalde firewall software gebruikt op je clients. dit zou het probleem ook nog wel eens kunnen veroorzaken.

Nope...(Windows) firewall staat uitgeschakeld middels grouppolicy en verder draait er alleen een corporate virusscanner (Symantec 10.x of AVG) zonder firewall opties. Laptops hebben vaak AVG free erop staan, maar kan ook andere scanner zijn..denk ook niet dat het hier aan ligt.

bazkar schreef op vrijdag 16 november 2007 @ 21:25:
Hoe ziet de ARP tabel van de machine eruit als er geen connectivity meer is? En van de server en de router?
Staat je server dan wel in de arp tabel van de machine? (arp -a vanaf command line) en vice versa?

Als ik het me goed kan herinneren staat de server er wel in op de client, maar zal het iig checken op de server de volgende keer. Als de client er dan niet instaat verklaart dat waarom de pings niet terugkomen.

bazkar schreef op vrijdag 16 november 2007 @ 21:25:
Als het een probleem met de switch is, zou je ook je gateway niet meer kunnen pingen.
Het rare is dus dat je wel je gateway kan pingen, en dat ANDERE machines nog wel je server kunnen pingen.

De switch zal het dan waarschijnlijk niet zijn, die houdt alleen maar een MAC tabel bij gekoppeld aan de poorten; als hierin de server verkeerd zou staan, zou inderdaad niemand de server kunnen benaderen. Als de client er verkeerd in zou staan zou het wel kunnen verklaren waarom er geen verkeer van server naar client mogelijk is, maar denk niet dat dat het is, want dan zou mijn DHCP truukje ook niet werken: het MAC adres van de client verandert tenslotte niet als deze een ander IP krijgt toegewezen.
Daarom denk ik stiekem toch dat het een hogere laag is die het probleem veroorzaakt. Fysiek t/m IP (1 t/m 3) werkt, anders kon ik bijv. niet op de router IP komen.

Gevoelsmatig lijkt het erop dat er "geen toegang" tot de server kan worden verkregen (authenticatie?) en dus de dns (server) niet benaderd kan worden. Deze toegang is er op een lager niveau wel, want de DHCP procedure wordt vrolijk doorlopen....grrrrrr

Ik moet helaas/gelukkig wel even wachten tot het probleem zich voordoet, voordat ik Wireshark etc. kan uitproberen, want zoals ik al zei is het probleem redelijk onvoorspelbaar: het kan zo weer enkele maanden goed gaan... maar dan op hout....

[Anoniem: 240093]

Als er nog iemand andere suggesties/oplossingen heeft, hoor ik het graag...

[kevlar]

bazkar schreef op vrijdag 16 november 2007 @ 21:25:
Dit is een laag 2 probleem als het een netwerk probleem is. Waarom? Nou, je server staat in het subnet van de clients en dus hoeft er niet gerouteerd te worden door je modem/router als je die probeert te pingen.

Routeproblemen (laag 3) kunnen we voorlopig dus even uitsluiten.

Ik vind het bijna flauw om dit te zeggen, maar ik wil toch even mijn gelijk halen

Het kan wel een layer 3 probleem zijn, de symptonen kunnen ook ontstaan als er een brakke firewall in het spel is. een firewall is een een layer 3 (of hoger) device.

Het is inderdaad zo dat er niet gerouteerd wordt, maar een firewall kan ook laag 3 verkeer scannen in een laag 2 mode (transparant firewall heet dat), je software firewall op je systeem doet precies dit.

[bazkar]

Om niet helemaal off-topic te gaan, je hebt gelijk in zoverre dat de firewall er tussen kan zitten, maar dan kan het probleem zich inderdaad tot en met laag 7 voordoen (application firewalling).

Verder heb je niet helemaal gelijk. Het IP van de router bereiken gaat niet via laag 3 omdat de router in het subnet van de machines zit. Dit blijft steken op laag 2 (Je client machine bouwt nl voor machines in zijn eigen subnet ZELF de arp tabel op, dit hoeft de router niet te doen).

Verder 'hoeft' de verbinding fysiek in zoverre niet meer in orde te zijn, dat een DHCP lease een eenmalige actie is. Op het moment dat ik een ipconfig /release en renew doe, worden volgens mij de ARP tabellen ook leeg gegooid en dus kan het een ARP probleem zijn op de client.

[Anoniem: 240093]

Jongens, niet vechten, ik heb liever een oplossing!
Overigens heb je het volgens mij altijd over laag 3 (OSI dan hè, bij TCP/IP model is het laag 2) wanneer je over IP praat. ARP zit in ieder geval op laag 3, zeker als je het over de tabel hebt waarmee IP adressen aan MAC adressen worden gekoppeld. Op het moment dat ik succesvol naar de webinterface op de router/modem ga, gebruik ik alle lagen t/m 7 (HTTP zit daar), dus werkt naar het modem toe iig alles.
Ik denk niet dat het probleem in de ARP tabel van de client zit (daar heb ik een keer naar gekeken en stond de server 10.0.0.1 volgens mij gewoon in), maar toch lijkt het me een stap in de goede richting. Als de ARP tabel op de server "corrupt" raakt en die ene client met een verkeerd IP aan zijn MAC gekoppeld staat, zou dat kunnen verklaren waarom het niet werkt. De client weet wel de server te vinden, maar het pakket komt niet terug want de server heeft het verkeerde retouradres. Na de "DHCP-truuk" wordt de ARP tabel op de server gedwongen bijgewerkt en vindt ie de client weer wel...
Een corrupte ARP tabel zou dus de reden kunnen zijn waarom het contact tussen de server en een client niet goed verloopt, maar nu dan nog de oorzaak: waarom raakt dat ding corrupt?

[bazkar]

Tja, dat kan door duplicate IP's komen bijvoorbeeld. Iemand die een laptop met een DHCP-lease krijgt (leastijd bv. 1 week). Vervolgens gaat diegene 2 weken op vakantie. De lease is verlopen en wordt opnieuw uitgegeven. Dan komt de persoon terug, sluit zijn machine aan (met de verlopen lease) en heeft dan nog wel (eventjes) netwerk, totdat zijn lease vernieuwd is. Dat is vaak net lang genoeg om de ARP tabellen aan gort te helpen.

[Anoniem: 240093]

bazkar schreef op dinsdag 20 november 2007 @ 16:09:
Tja, dat kan door duplicate IP's komen bijvoorbeeld. .... Dat is vaak net lang genoeg om de ARP tabellen aan gort te helpen.

Dan zou het daarin inderdaad kunnen zitten: vaak gaat het om laptops die van een andere locatie afkomen. Op die locatie hebben ze een ip adres in dezelfde range (10.0.0.x), dus die proberen ze natuurlijk eerst bij de DHCP server te claimen...die geeft ze vervolgens aan dat het al in gebruik is (of niet), maar misschien dat dat de ARP tabel op de server verpest....klinkt wel vaag, maar goed, dat is het probleem ook.
Bedankt voor het meedenken in ieder geval!

[bazkar]

Anoniem: 240093 schreef op dinsdag 20 november 2007 @ 21:58:
[...]
Bedankt voor het meedenken in ieder geval!

U is welkom. Daar gaat het toch ook om bij GoT.
Mensen die zelf ook proberen mee te denken en niet hun probleem op het forum smijten met de melding: "Los dit ff voor me op" scoren bij mij tegenwoordig al bonuspunten.

[Anoniem: 240093]

...de forumverslaafdheid is bij mij ook toegeslagen helaas: probeer meer posts te plaatsen dan alt-92

[Anoniem: 240093]

Goed, ik had het probleem net weer op een client. Het betrof een standaard desktop machine, die altijd goed gewerkt heeft.
Arp tabel op de client gecheckt: verwijzing naar server (10.0.0.1) stond erin, samen met het correcte MAC adres.
Arp tabel op server gecheckt: het ip adres van de client (10.0.0.90) stond erin, MAAR met een incorrect MAC adres!!!
In DHCP mmc (leases) stond de client (ws069) gewoon vermeld met het correcte IP adres.

arp -d 10.0.0.90 op de server gedaan: client IE laten openen (hij benadert de server voor DNS) en werkt meteen.

Dus de theorie van de corrupte arp tabel op de server klopt... blijft de vraag: waarom raakt deze corrupt? Iemand suggesties waar ik moet gaan zoeken?
Ik zie overigens nog wel in de arp tabel de vermelding statisch of dynamisch achter de verschillende entries staan. De corrupte entry had de vermelding statisch; zou ik het hierin moeten zoeken?

[Anoniem: 240093]

Goed ik denk dat ik er uit ben...
Een beetje research heeft uitgewezen dat de oorzaak van een corrupte arp tabel vaak gezocht moet worden in duplicate ip adressen op het netwerk.
Ik gebruik op elke locatie hetzelfde subnet (10.0.0.0 /24), dus een laptop die van een andere locatie komt heeft in principe al een correct ip adres en opties (gateway, dns, etc.) en kan verbinding maken met de server. Ik vermoed dat dit in sommige gevallen gebeurt voordat de DHCP handshake wordt afgewikkeld, zodat de arp tabel van de server wordt bijgewerkt met de mac en ip van de laptop. Vervolgens blijkt bij dhcp dat het ip adres al bezet is (door bijv. een desktop pc) en krijgt de laptop een ander ip adres, maar ondertussen is de arp tabel verpest.
Door arp -d wordt de incorrecte entry verwijderd en bij nieuw contact met de server goed ingevoerd.

Ik was toch al van plan om op elke locatie een ander subnet te gaan gebruiken, dus ben benieuwd of na invoering hiervan de problemen ook verdwijnen.

Iedereen in ieder geval bedankt voor het meedenken!

[Anoniem: 496361]

Ik had het zelfde probleem als beschreven. Bij mij zat het in de ARP lijst van mijn Zywall firewall.

Door Putty te downloaden en SSH verbinding te maken met mijn Zywall kon ik onderstaande commands uitvoeren. (op firewall kijken via webpagina van dat apparaat of SSH aanstaat + welke poort)

show arp-table (laat lijst zien)

enable (enter)
configure terminal (enter)

arp-table flush (om ARP lijst op nieuw te laten opbouwen)

[johnkeates]

Welkom in 2019. Hoe was het in 2007?

[Anoniem: 496361]

zelfs na 12 jaar heeft het mijn probleem opgelost @johnkeates

[Equator]

Maar dan hoeven we niet alsnog oude koeien uit de sloot te halen