☰

Konsistentes Verhalten von Problemkunden:

tag-icon • tag-icon dhcp
Konsistentes Verhalten von Problemkunden:

Ich würde mich sehr über Gedanken und Meinungen zu diesem seltsamen Problem freuen, das ich kürzlich hatte.

Konsistentes Verhalten von Problemkunden:

  • Bis zu einer bestimmten Uhrzeit am Morgen forderten Benutzer-PCs die Verwendung von 169.254.x APIPA-Adressen an
  • Nichtakzeptieren der vom DHCP-Server angebotenen legitimen Adressen innerhalb dieses Zeitrahmens
  • Nach einem zweiten DHCPDISCOVER nach Ablauf der Zeitspanne akzeptieren die Clients dann die von DHCP angebotene IP-Adresse

Zusammenfassung

  • Das Netzwerk eines einzelnen Gebäudes war nach einem Wochenende betroffen
  • Bei Benutzern, die ihre Rechner übers Wochenende eingeschaltet gelassen haben, gab es keine Probleme – DHCP-Erneuerungen usw. funktionieren normal
  • Benutzer, die ihre PCs sorgfältig ausgeschaltet hatten, hatten jedoch nach dem Einschalten DHCP-Probleme
  • Das Gebäude war zwei Stunden lang davon betroffen, es wurde kein Fehler gefunden und das Problem löste sich von selbst.
  • Das Netzwerk wird überwacht und es wurden umfassende Untersuchungen durchgeführt – im Zeitraum keine Netzwerkprobleme
  • Die DHCP-Server vergeben standortübergreifend Adressen. Dies war nur auf ein Gebäude beschränkt.
  • Client-Rechner, überwiegend Windows 7, verschiedene Hardware- und NIC-Anbieter betroffen – kein Muster gefunden.
  • Mischung aus statischen Desktops und Laptops
  • Kabelgebundene Konnektivität
  • Ein VLAN ist betroffen, allerdings sind nicht alle Clients innerhalb des VLAN betroffen.

Abfolge der im DHCP-Serverprotokoll erfassten Ereignisse

  1. DHCPDISCOVER - Client-PC - Erste Erkennungsaktion durch den Client
  2. DHCPOFFER DHCP-Server – Legitime IP-Adresse, angeboten vom DHCP-Server
  3. DHCPREQUEST - Client-PC - Anforderung von 169.254x vom Client: Meldung „Falsches Netzwerk“
  4. DHCPNAK - DHCP-Server - Server bestätigt negativ per NAK. Client muss Prozess neu starten
  5. DHCPDISCOVER -Client-PC - Zweite Erkennungsaktion durch den Client
  6. DHCPOFFER - DHCP-Server - Legitime IP-Adresse angeboten
  7. DHCPREQUEST - Client-PC - Der Client fordert die Verwendung der legitimen IP-Adresse an
  8. DHCPACK - DHCP-Server - Server bestätigt positiv

Pseudozusammenfassung der Punkte von RFC3927:

Ein „kurzer“ Blick in RFC 3927 – Dynamische Konfiguration von IPv4-Link-Local-Adressen – wirft mehr Fragen auf als es beantwortet!

Bei Verwendung von Link-Local-Adressen 169.254.x

  • 169.254./16 Link-Local-Adressierung wird verwendet, wenn Adressen oder Adresskonfiguration nicht verfügbar sind
  • Wird normalerweise beim Start ausgeführt

Wenn der Host die Adresse 169.254.x verwendet und die Adresse jetzt verfügbar ist, muss der Host

  • Routingfähige Adresse verwenden
  • Beenden Sie die Werbung für 169.254.x

Routingfähige Methodenadressen sind möglicherweise nicht mehr verfügbar

  • Ablauf der DHCP-Lease
  • Entfernung der Adresse über manuelle Konfiguration
  • Roaming-Host zu neuem Netzwerk, dessen Adresse nicht mehr funktioniert

169.254.x Adressauswahl

  • Windows- und MAC-Hosts implementieren die lokale Link-Autokonfiguration
  • Windows-Hinweis:
    • Sobald eine Netzwerkverbindung erkannt wurde, wird DHCPREQUEST oder DHCPDISCOVER an die Schnittstelle gesendet
    • Systeme wechseln sofort aus der Autokonfiguration, sobald Konnektivität verfügbar ist
  • Generierung von Pseudozufallszahlen basierend auf dem Host, d. h. der MAC-Adresse
  • Tritt beim Booten auf

Beanspruchung der Adresse 169.254.x

  • Der Host muss prüfen, ob die lokale Linkadresse 169.254.x im Netzwerk nicht verwendet wird.
  • Abgeschlossen über eine gesendete ARP-Anfrage (einschließlich Ziel-IP-Adresse – wird geprüft)

Ankündigung der Adresse 169.254.x

  • Zweiter ARP-Broadcast, diesmal jedoch mit Absender- und Ziel-IP-Adressen, nun die ausgewählten 169.254.x IPs

Abschließende Zusammenfassung

  • Der Client führt DHCPDISCOVER durch und der DHCP-Server antwortet mit einem DHCPOFFER
  • Der Client sollte dieses Angebot einer routbaren Adresse annehmen und die Verwendung der Link-Local-Adresse 169.254.x einstellen. Aus irgendeinem Grund tut er das nicht.
  • Die nachfolgende DHCPREQUEST vom Client scheint ein ARP-Test oder eine ARP-Ankündigungssendung zu sein? Dass der Client 169.254.xx verwendet und möglicherweise nicht mit den Antworten des DHCP-Servers korreliert?
  • Zweites DHCPDISCOVER – es ist nicht klar, was dies auslöst, da die PCs anfangs eingeschaltet waren.

Vielen Dank für Ihre Geduld, wenn Sie es bis hierher geschafft haben!

Wäre wirklich dankbar für jede Hilfe zum Verständnis.

Danke,

Antwort1

Sind die Adressen im Lease-Pool aufgebraucht? Vielleicht kann er deshalb keine weiteren IP-Adressen mehr vergeben.

Können Sie den DHCP-Server von den betroffenen Rechnern aus anpingen, sobald Sie in Windows sind? Können Sie die Netzwerkkarte auf eine unbenutzte IP aus dem DHCP-Bereich fest codieren und erhalten Sie so zum Testen Zugriff auf das Netzwerk? Testen Sie bei Bedarf auch einen der funktionierenden PCs am selben Netzwerkport wie einen nicht funktionierenden Rechner.

verwandte Informationen