5
DHCP-IPs werden zu langsam zugeteilt
Hallo!
Ich schreibe diesen Beitrag in den Bereich "Server", da mein Problem nicht von einem Betriebssystem abhängt, mein Problem ist, dass ich ein Noob bin. Zum Problem:
Ich habe zwei Server. Der eine ist für das interne Netzwerk(ein Fileserver mit einer Domäne), der andere ist ein Router für das Internet und die User müssen jedes mal das Kabel in eine andere Buchse umstecken, wenn sie auf den Anderen Server wollen(bitte nicht lachen, das System hat mein Vorgänger ausgedacht, so empfand er das als am sichersten;) Die beiden Server wurden ebenfalls von meinem Vorgänger eingerichtet und die Prozedur des umsteckens hat auch nicht so lang gedauert, da die Clients relativ schnell ihre neue IP bekamen. Aber nun habe ich den Router schon mehrmals mit unterschiedlichen Betriebssystemen neu installiert und habe immer das gleiche Problem. Wenn man das Kabel eines Clients auf meinen Router umstöpselt, so merkt er im ersten Moment gar nicht, dass er in einem anderen Netz ist, paar Sekunden später kommt bei einem Win-Client die meldung unten "eingeschränkte Konnektivität(das gelbe Warndreieck)" und erst dann bekommt er seine neue IP zugeteilt. Früher(vor meinem Eingriff) war das aber nicht so, kein Warndreieck und der Client hat sofort gewusst, dass er im anderen Netz ist und sofort nach einer neuen IP gefragt.
Woran könnte es liegen? Habe ich bei der Konfiguration etwas vergessen?
Ich bin für jeden Tipp sehr dankbar!
Ich schreibe diesen Beitrag in den Bereich "Server", da mein Problem nicht von einem Betriebssystem abhängt, mein Problem ist, dass ich ein Noob bin. Zum Problem:
Ich habe zwei Server. Der eine ist für das interne Netzwerk(ein Fileserver mit einer Domäne), der andere ist ein Router für das Internet und die User müssen jedes mal das Kabel in eine andere Buchse umstecken, wenn sie auf den Anderen Server wollen(bitte nicht lachen, das System hat mein Vorgänger ausgedacht, so empfand er das als am sichersten;) Die beiden Server wurden ebenfalls von meinem Vorgänger eingerichtet und die Prozedur des umsteckens hat auch nicht so lang gedauert, da die Clients relativ schnell ihre neue IP bekamen. Aber nun habe ich den Router schon mehrmals mit unterschiedlichen Betriebssystemen neu installiert und habe immer das gleiche Problem. Wenn man das Kabel eines Clients auf meinen Router umstöpselt, so merkt er im ersten Moment gar nicht, dass er in einem anderen Netz ist, paar Sekunden später kommt bei einem Win-Client die meldung unten "eingeschränkte Konnektivität(das gelbe Warndreieck)" und erst dann bekommt er seine neue IP zugeteilt. Früher(vor meinem Eingriff) war das aber nicht so, kein Warndreieck und der Client hat sofort gewusst, dass er im anderen Netz ist und sofort nach einer neuen IP gefragt.
Woran könnte es liegen? Habe ich bei der Konfiguration etwas vergessen?
Ich bin für jeden Tipp sehr dankbar!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 64847
Url: https://administrator.de/contentid/64847
Ausgedruckt am: 19.11.2024 um 03:11 Uhr
5 Kommentare
Neuester Kommentar
Eigentlich kann das nicht sein !!!
Warndreieck und eingeschränkte Konnektivität bedeutet das der PC/Laptop keinen DHCP Server im Netz gefunden hat nach seinem DHCP Server Broadcast !! Er vergibt sich dann automatisch eine APIPA IP Adresse aus dem reservierten Bereich von 169.254.x.x und bleibt damit auch bestehen und versucht dann nur in sehr langen Intervallen mit einem DHCP Broadcast eine neue IP Adresse zu bekommen !
Ein Link Interrupt bewirkt aber in jedem Falle einen DHCP Broadcast und die Anfrage nach einer Adresse. Man kann dann nur schlussfolgern, das der DHCP Server im Router nicht korrekt arbeitet oder.... die DHCP Implementation auf dem Client.
Das kannst du sehr einfach überprüfen indem du mal auf einem Clienten parallel einen Sniffer wie wie dem www.wireshark.org oder dem Mircrosoft Net-Monitor sehen wie die DHCP Vergabereihenfolge aussieht.
Wenn der Server nicht rechtzeitig antwortet ists der Router, wenn der Client nicht reagiert auf einen DHCP Offer des Routers ists der Client !!
Warndreieck und eingeschränkte Konnektivität bedeutet das der PC/Laptop keinen DHCP Server im Netz gefunden hat nach seinem DHCP Server Broadcast !! Er vergibt sich dann automatisch eine APIPA IP Adresse aus dem reservierten Bereich von 169.254.x.x und bleibt damit auch bestehen und versucht dann nur in sehr langen Intervallen mit einem DHCP Broadcast eine neue IP Adresse zu bekommen !
Ein Link Interrupt bewirkt aber in jedem Falle einen DHCP Broadcast und die Anfrage nach einer Adresse. Man kann dann nur schlussfolgern, das der DHCP Server im Router nicht korrekt arbeitet oder.... die DHCP Implementation auf dem Client.
Das kannst du sehr einfach überprüfen indem du mal auf einem Clienten parallel einen Sniffer wie wie dem www.wireshark.org oder dem Mircrosoft Net-Monitor sehen wie die DHCP Vergabereihenfolge aussieht.
Wenn der Server nicht rechtzeitig antwortet ists der Router, wenn der Client nicht reagiert auf einen DHCP Offer des Routers ists der Client !!
Hallo!
Vielen Dank für deine schnelle Anwort!
Ich bin mir ziemlich sicher, dass nicht die Clients für das Problem verantwortlich sind, es hat ja früher, vor meinem Eingriff, funktioniert. Irgendwas mache ich bei der Konfiguration des Servers falsch.
Es ist tatsächlich wahr, die Clients merken zuerst nicht, dass sie in einem anderen Netz sind, dann kommt der Warndreieck und sie bekommen für eine halbe Sekunde eine APIPA IP, danach kommt sofort die richtige IP. Ich habe beide Programme getestet, die du vorgeschlagen hast, allerdings bin ich nicht so schlau zu verstehen, was in den Protokollen steht, vielleicht könntest du oder jemand anders mehr hier erkennen und mir einen Ratschlag geben. 172.16.70.141 ist hier die IP des externen Servers, der nicht richtig läuft und 192.168.70.1 die IP des internen, der richtig funktioniert. Ich schalte also zuerst vom falsch konfigurierten auf den richtig konfigurierten und nach paar Sekunden wieder zurück. Mit dem Internen tauscht er übrigens die ganze Zeit irgendwelche Daten aus. Kann man sagen, was er da macht?
(ich habe leider keine Möglichkeit gefunden, die Datei ins Forum hochzuladen oder alle Packete als Text zu kopieren und einzufügen, deswegen hier ein Protokoll von Wireshark)
http://www.cshare.de/file/a3b4059767c34d4d0529a13dccccd068/Sniff.pcap.h ...
Vielen Dank für deine schnelle Anwort!
Ich bin mir ziemlich sicher, dass nicht die Clients für das Problem verantwortlich sind, es hat ja früher, vor meinem Eingriff, funktioniert. Irgendwas mache ich bei der Konfiguration des Servers falsch.
Es ist tatsächlich wahr, die Clients merken zuerst nicht, dass sie in einem anderen Netz sind, dann kommt der Warndreieck und sie bekommen für eine halbe Sekunde eine APIPA IP, danach kommt sofort die richtige IP. Ich habe beide Programme getestet, die du vorgeschlagen hast, allerdings bin ich nicht so schlau zu verstehen, was in den Protokollen steht, vielleicht könntest du oder jemand anders mehr hier erkennen und mir einen Ratschlag geben. 172.16.70.141 ist hier die IP des externen Servers, der nicht richtig läuft und 192.168.70.1 die IP des internen, der richtig funktioniert. Ich schalte also zuerst vom falsch konfigurierten auf den richtig konfigurierten und nach paar Sekunden wieder zurück. Mit dem Internen tauscht er übrigens die ganze Zeit irgendwelche Daten aus. Kann man sagen, was er da macht?
(ich habe leider keine Möglichkeit gefunden, die Datei ins Forum hochzuladen oder alle Packete als Text zu kopieren und einzufügen, deswegen hier ein Protokoll von Wireshark)
http://www.cshare.de/file/a3b4059767c34d4d0529a13dccccd068/Sniff.pcap.h ...
Wenn einer der Server eine Windows Machine ist, dan hat Windows die Option auf doppelte IP Adressen zu prüfen. Der Windows DHCP Server versucht die von ihm zu vergebende IP zu pingen. Ist die Antwort negativ schickt er sie erst dann als DHCP Offer heraus. Das kostet natürlich Zeit auf einem schwachbrüstigen Server oder einem unter Last und kann schon einmal die Wartezeit vergrößern. Diese Option solltest du also einmal in jedem Falle abschalten sofern sie aktiviert sein sollte !!!
Als weiteren Quercheck kannst du diesen Client einmal an einen Banal DHCP Server hängen der Betreibssystem unabhängig ist wie z.B. den eines DSL Routers. Geschieht hier dei IP Adressvergabe verzögerungsfrei, dann liegt das Problem sicher an deinem DHCP Server.
Den Sniffer Trace kannst du doch sehr einfach lesen.....sieh dir doch nur einmal die Packetreihenfolge für den DHCP Aufbau an...irgendeiner hört auf zu senden...entweder der Server oder der Client und das ist dann meist auch der Schuldige.
Auch das der Client permanent Daten mit dem Internet tauscht sollte dich in höchste Alarmbereitschaft versetzen. Sowas ist eigentlich nicht normal das die Rechner nach Hause telefonieren !!! Anhand der öffentlichen IP Adresse im Packet (Ziel IP) kannst du über einen Whois Server wie z.B. diesen hier:
http://www.heise.de/netze/tools/whois-abfrage
sofort rausbekommen wo das hingeht und die Applikation entlarven !!! Es kann sein das du nicht konsequnet genug die nach Hause telefonier Option von Windows abgeschaltet hast und auch diese sinnlosen Update und Meldefunktionen von Applikationen die meist nur Userverhalten usw. ausspionieren wollen !!! Schlimmstenfalls hast du Viren oder Trojaner oder der Rechner ist Teil eines BOT Netzwerkes.
An deine Pcap Daten kommt man nicht ran. Mach ein JPEG Screencapture und poste das hier über den Editor und die Bild Importfunktion !
Als weiteren Quercheck kannst du diesen Client einmal an einen Banal DHCP Server hängen der Betreibssystem unabhängig ist wie z.B. den eines DSL Routers. Geschieht hier dei IP Adressvergabe verzögerungsfrei, dann liegt das Problem sicher an deinem DHCP Server.
Den Sniffer Trace kannst du doch sehr einfach lesen.....sieh dir doch nur einmal die Packetreihenfolge für den DHCP Aufbau an...irgendeiner hört auf zu senden...entweder der Server oder der Client und das ist dann meist auch der Schuldige.
Auch das der Client permanent Daten mit dem Internet tauscht sollte dich in höchste Alarmbereitschaft versetzen. Sowas ist eigentlich nicht normal das die Rechner nach Hause telefonieren !!! Anhand der öffentlichen IP Adresse im Packet (Ziel IP) kannst du über einen Whois Server wie z.B. diesen hier:
http://www.heise.de/netze/tools/whois-abfrage
sofort rausbekommen wo das hingeht und die Applikation entlarven !!! Es kann sein das du nicht konsequnet genug die nach Hause telefonier Option von Windows abgeschaltet hast und auch diese sinnlosen Update und Meldefunktionen von Applikationen die meist nur Userverhalten usw. ausspionieren wollen !!! Schlimmstenfalls hast du Viren oder Trojaner oder der Rechner ist Teil eines BOT Netzwerkes.
An deine Pcap Daten kommt man nicht ran. Mach ein JPEG Screencapture und poste das hier über den Editor und die Bild Importfunktion !
So schlimm ist es nicht, die Clients tauschen die Informationen nur mit dem internen Server. Sobald ich zum externen wechsle sind sie ruhig. Dass es an meinem Server liegt, da bin ich ziemlich sicher, was ich falsch mache, das kann ich nur nicht begreifen. Einer der Server ist tatsächlich mit Windows, aber mit ihm ist alles OK, nur wenn ich auf meinen Server wechsle, dann habe ich diese Verzögerung, und zwar egal, ob ich ihn mit Windows oder Linux bespiele. Die Option, wo man die Überprüfung abschalten kann habe ich leider noch nicht gefunden. Könntest du bitte sagen, wie sie genau heisst? Die Protokoll-Datei konnte ich problemlos herunterladen, bitte klicke noch mal drauf und dann auf downloaden(es ist mir sehr wichtig, da die Leute vom Institut mir langsam sauer werden, dass es so lange dauert beim umschalten. Ich wäre dir also sehr verbunden.) Wie ich schon gesagt habe, die Clients verhalten sich merkwürdig, wenn ich auf den externen Server wechsle. Sie behalten im ersten moment die alte IP, dann kommt das Warndreieck und die APIPA-IP und dann erst die richtige aus dem richtigen Bereich. Ich danke dir nochmals sehr, dass du versuchst mir zu helfen, da ich schon am Verzweifeln bin.
Ich habe bei Wikipedia vor kurzem folgendes gelesen:
Zitat:
Eine negative Bestätigung DHCPNAK kann als Ursache haben, dass der Client versucht, seine ehemalige IP-Adresse zu leasen, die jedoch inzwischen nicht mehr verfügbar ist (Lease abgelaufen und anderweitig vergeben), oder wenn der Client-Computer in ein anderes Subnetz verschoben wurde.
Um die Ausfallwahrscheinlichkeit zu verringern, ist es auch möglich, mehrere DHCP-Server in einem Netz zu platzieren. Dabei sollte allerdings beachtet werden, dass sich die Adressbereiche der einzelnen Server nicht überlappen, da es sonst zu Doppelvergaben von IP-Adressen kommen kann. Dazu gibt es die „authoritative“ (engl. für „maßgebliche“) Einstellung, mit der man einstellen kann, ob ein DHCPNAK auch verschickt werden soll, wenn der DHCP-Server für die vom Client vorgeschlagene Adresse nicht zuständig ist.
Wenn der Client eine negative Bestätigung erhält, wird der DHCP-Lease-Vorgang erneut gestartet.
Ein Client sendet DHCPRELEASE, wenn er eine IP-Adresse vor Ablauf der Lease-Zeit zurückgeben will.
Sollte der Client feststellen, dass die zugewiesene Adresse bereits benutzt wird, so teilt er dies dem Server durch DHCPDECLINE mit, welcher seinerseits den Administrator von dieser potentiellen Fehlkonfiguration unterrichten sollte.
Es scheint genau das Problem zu beschreiben, nur wie konfiguriert man diese authoritative-Option...?
Zitat:
Eine negative Bestätigung DHCPNAK kann als Ursache haben, dass der Client versucht, seine ehemalige IP-Adresse zu leasen, die jedoch inzwischen nicht mehr verfügbar ist (Lease abgelaufen und anderweitig vergeben), oder wenn der Client-Computer in ein anderes Subnetz verschoben wurde.
Um die Ausfallwahrscheinlichkeit zu verringern, ist es auch möglich, mehrere DHCP-Server in einem Netz zu platzieren. Dabei sollte allerdings beachtet werden, dass sich die Adressbereiche der einzelnen Server nicht überlappen, da es sonst zu Doppelvergaben von IP-Adressen kommen kann. Dazu gibt es die „authoritative“ (engl. für „maßgebliche“) Einstellung, mit der man einstellen kann, ob ein DHCPNAK auch verschickt werden soll, wenn der DHCP-Server für die vom Client vorgeschlagene Adresse nicht zuständig ist.
Wenn der Client eine negative Bestätigung erhält, wird der DHCP-Lease-Vorgang erneut gestartet.
Ein Client sendet DHCPRELEASE, wenn er eine IP-Adresse vor Ablauf der Lease-Zeit zurückgeben will.
Sollte der Client feststellen, dass die zugewiesene Adresse bereits benutzt wird, so teilt er dies dem Server durch DHCPDECLINE mit, welcher seinerseits den Administrator von dieser potentiellen Fehlkonfiguration unterrichten sollte.
Es scheint genau das Problem zu beschreiben, nur wie konfiguriert man diese authoritative-Option...?
