Windows 7-Client-Flooding-Netzwerk mit DHCP-Anforderungen. IP nicht einstellen

7

Ich habe ein kleines Netzwerk mit 15 Workstations, SAMBA AD und einer Reihe von virtualisierten Linux-Servern. Alle Workstations und Server befinden sich im selben Subnetz.

Auf allen Arbeitsstationen wird Windows 7 Pro ausgeführt

Sowohl mein Samba 4 DC als auch mein ISC-DHCP-SERVER werden auf demselben virtualisierten Host ausgeführt.

Für die meisten, wenn nicht alle Workstations sind DHCP-Reservierungen konfiguriert.

Eine meiner Workstations erhält keine DHCP-Adresse. Wenn ich den Adapter aktiviere, meldet das Syslog meines DHCP-Servers Folgendes: (Ich habe versucht, die dydns-Skripte zu entfernen, aber es hat keinen Unterschied gemacht. Ignorieren Sie diese Meldungen.)

Jan  6 03:47:21 frfdc dhcpd[984]: DHCPREQUEST for 192.168.1.249         (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPACK on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPDISCOVER from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPOFFER on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: Commit: IP: 192.168.1.249 DHCID: 1:0:23:24:a1:cd:80 Name: FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[0] = /etc/dhcp/bin/dhcp-dyndns.sh
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[1] = add
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[2] = 192.168.1.249
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[3] = 1:0:23:24:a1:cd:80
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[4] = FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : Getting new ticket, old one has expired
Jan  6 03:47:21 frfdc sh[984]: kinit: Permission denied while getting initial credentials
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : dhcpd kinit for dynamic DNS failed
Jan  6 03:47:21 frfdc dhcpd[984]: execute: /etc/dhcp/bin/dhcp-dyndns.sh exit status 256
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPREQUEST for 192.168.1.249 (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPACK on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPDISCOVER from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPOFFER on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: Commit: IP: 192.168.1.249 DHCID: 1:0:23:24:a1:cd:80 Name: FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[0] = /etc/dhcp/bin/dhcp-dyndns.sh
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[1] = add
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[2] = 192.168.1.249
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[3] = 1:0:23:24:a1:cd:80
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[4] = FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : Getting new ticket, old one has expired
Jan  6 03:47:21 frfdc sh[984]: kinit: Permission denied while getting initial credentials
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : dhcpd kinit for dynamic DNS failed
Jan  6 03:47:21 frfdc dhcpd[984]: execute: /etc/dhcp/bin/dhcp-dyndns.sh exit status 256

Ich werde anscheinend mit 10 Anfragen pro Sekunde für diese Workstation überflutet. Schließlich tritt bei Windows eine Zeitüberschreitung auf, weist sich eine 169.xxx-Adresse zu und wird beendet.

Alle Einsichten / Vorschläge wären sehr willkommen.

Auf der Workstation habe ich versucht: Treiber aktualisieren. Bare OS installieren. Deaktivieren der drahtlosen Netzwerkkarte. Anwenden einer Registrierungseinstellung "DhcpConnEnableBcastFlagToggle auf 1" in HKLM-System-Current Control Set-Services-TCPIP-Parameter-Schnittstellen-GUID.

Auf dem Server habe ich versucht, den DHCP-Server zu aktualisieren. Ich bin jetzt bei 3.3-5ubuntu12.7. Ich habe verschiedene Verzögerungseinstellungen untersucht, aber sie scheinen nicht zu helfen.

dhcpd.conf unten: (Andere Reservierungen entfernt) 

default-lease-time 600;
max-lease-time 7200;

authoritative;

subnet 192.168.1.0 netmask 255.255.255.0 {
  option subnet-mask 255.255.255.0;
  option broadcast-address 192.168.1.255;
  option time-offset 0;
  option routers 192.168.1.1;
  option domain-name "CHANGED.local";
  option domain-name-servers 192.168.1.19;
  option netbios-name-servers 192.168.1.19;
  option ntp-servers 192.168.1.19, 192.168.1.250;


host FRF-M014-PC.FRFCanada.local{
  hardware ethernet 00:23:24:a1:cd:80; 
  fixed-address 192.168.1.249; 
}

pool {
  max-lease-time 1800; # 30 minutes
  range 192.168.1.150 192.168.1.199;
  }
}

Update: 7. Januar 2018, 12:40 Uhr Ich sehe nichts, was das Ereignis auf dem Client protokolliert, was relevant aussieht. Ich habe versucht, die Reservierungs-IP in 192.168.1.6 zu ändern. - Der Client überflutet den DHCP-Server noch etwa 30 Sekunden lang, akzeptiert jedoch möglicherweise die IP. Ich suche nach einem möglichen Duplikat von 192.168.1.249 - konnte aber noch keines finden. Es ist Sonntag und niemand anderes ist im Büro, das könnte ein Grund dafür sein. Ich habe auch den vorgeschlagenen Registrierungsschlüssel hinzugefügt.

Update: 7. Januar 2018 12:40 Ich habe zu früh gefeiert. Ich habe den Client neu gestartet und er akzeptiert die IP nicht mehr

Update 7. Januar 2018 13:45 Nach 15 Minuten der Anforderung einer IP akzeptierte der Client schließlich die IP. Protokoll unten erfasst:

Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPREQUEST for 192.168.1.6 (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPACK on 192.168.1.6 to 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPDISCOVER from 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPOFFER on 192.168.1.6 to 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: Commit: IP: 192.168.1.6 DHCID: 1:0:23:24:a1:cd:80 Name: FRF-M014-PC
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[0] = /etc/dhcp/bin/dhcp-dyndns.sh
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[1] = add
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[2] = 192.168.1.6
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[3] = 1:0:23:24:a1:cd:80
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[4] = FRF-M014-PC
Jan  7 13:42:05 frfdc dhcpd: 07-01-18 13:42:05 [dyndns] : Getting new ticket, old one has expired
Jan  7 13:42:05 frfdc sh[1693]: kinit: Permission denied while getting initial credentials
Jan  7 13:42:05 frfdc dhcpd: 07-01-18 13:42:05 [dyndns] : dhcpd kinit for dynamic DNS failed
Jan  7 13:42:05 frfdc dhcpd[1693]: execute: /etc/dhcp/bin/dhcp-dyndns.sh exit status 256
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPREQUEST for 192.168.1.6 (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPACK on 192.168.1.6 to 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:08 frfdc dhcpd[1693]: DHCPINFORM from 192.168.1.6 via eth0
Jan  7 13:42:08 frfdc dhcpd[1693]: DHCPACK to 192.168.1.6 (00:23:24:a1:cd:80) via eth0

Update 7. Januar 2018 14:45

Geänderte Netzwerkkarte, Reservierung mit MAC der neuen Netzwerkkarte aktualisiert. Gleiches Ergebnis.

Update 8. Januar 2018 9:45

Wireshark-Screenshot vom DHCP-Server, der den gesamten Datenverkehr von der Client-Ether-Adresse erfasst.

Update 9. Januar 2018

Ich habe ein Ausfallfenster für den 13./14. Januar erworben. Keine Updates mehr bis zum 15 ..

Update 14. Januar 2018 Ich habe versucht, den Switch und den physischen Server neu zu starten. Immer noch keine Veränderung. Ich habe dem Server dann seinen eigenen physischen NIC / Switch-Port zugewiesen. Immer noch keine Veränderung. Ich habe dann die Switch-Konfiguration überprüft und die Porteinstellungen erneut auf den verwendeten Port angewendet, und die Flut scheint gestoppt zu sein. Ich bin noch nicht überzeugt und werde für ein paar Tage überwachen.

windows-7  dhcp  tcpip  samba4  isc-dhcp 
— Skye Bowen
quelle
1
Ihre Wireshark-Erfassung sieht seltsam aus. Es gibt 6 verschiedene DHCP-Konversationen (basierend auf der Transaktions-ID) und das DHCP-Angebot wird an eine bestimmte IP-Adresse (192.168.1.6) gesendet, wenn es an 255.255.255.255 gehen soll, da der Client noch keine IP haben sollte Adresse. Dieses Verhalten sollte nur während der T1-Phase (Erneuerung) beobachtet werden. Haben Sie eine alternative IP-Adresse auf der Netzwerkkarte des Clients konfiguriert?
— Joeqwerty
Es sind keine alternativen Adressen konfiguriert. Das ist nur ein kleiner Ausschnitt. Es gibt 600 Anfragen pro Minute von diesem bestimmten Client. Es ist möglich, dass der Client gerade versucht, eine Verlängerung durchzuführen, da ich nur die Netzwerkkarte auf dem Client deaktiviere. Starten Sie die Erfassung und aktivieren Sie die Netzwerkkarte erneut. Nach einer langen Zeit (manchmal 10 Minuten) bekommt es schließlich eine IP
— Skye Bowen
Während der Erneuerungsphase (T1) wird Unicast direkt zwischen der IP-Adresse des Servers und der vorhandenen DHCP-geleasten IP-Adresse des Clients gesendet. Während der Rebinding-Phase (T2) kehrt der Client in die INIT-Phase zurück und verwendet Broadcast, um einen beliebigen DHCP-Server zu kontaktieren. Ihre Spur scheint beide Verhaltensweisen gleichzeitig zu zeigen, was sehr seltsam ist. Ich kann dieses Verhalten in einer Laborumgebung nicht replizieren.
— Joeqwerty

Antworten:

3

Mir scheint eine schlechte Netzwerkkarte in der Workstation.

Versuchen Sie ein Firmware-Update und ändern Sie die Netzwerkkarte, falls dies immer noch nicht funktioniert.

— yagmoth555
quelle
Danke, bitte sehen Sie neue Details gepostet. Ich habe die Netzwerkkarte geändert und die Reservierung aktualisiert. Gleiches Verhalten.
— Skye Bowen
@SkyeBowen Bitte machen Sie einen Wireshark von der Client-Seite, wenn Sie die Diagnose fortsetzen können, und zeigen Sie es uns.
— yagmoth555
@ SkyeBowen Danke für den Wireshark. Der Computer erhält niemals die letzte Bestätigung vom DHCP-Server. Wireshark Inbound wird vor der Firewall angezeigt, daher ist es keine Computer-Firewall, die das Paket blockiert. (Outbound in Wireshark ist nach der Firewall). Versuchen Sie es mit einem anderen Switch-Port. Möglicherweise liegt ein ARP-Problem mit dem Switch vor (oder nur ein Port-Problem)
— yagmoth555
Danke, ich habe versucht, Ports zu tauschen. Sowohl der Server als auch der Client sind an denselben Switch angeschlossen. An keinem Port sind spezielle VLAN-Konfigurationen vorhanden. Ich verwende einen Ubiquiti US-48-750w-Switch. (wenn das einen Unterschied macht)
— Skye Bowen
@SkyeBowen Haben Sie ein Wartungsfenster, um es wie einen anderen Switch verwenden zu können und den Server und den Computer daran anzuschließen, um den Switch auszuschließen?
— yagmoth555
2

Basierend auf dem Angebot -> Festschreiben scheint es, als ob der DHCP-Server funktioniert. Aus irgendeinem Grund akzeptiert der Client die ausgegebene IP nicht.

Gibt es noch etwas, das diese IP verwendet? Windows verwendet ARP, um widersprüchliche Mac / IP-Bindungen für eine IP-Adresse zu identifizieren, bevor diese an die eigene Schnittstelle gebunden werden.

Am einfachsten ist es, eine andere IP zu testen. Alternativ können Sie die Erkennung doppelter Adressen über die Registrierung beenden:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

DWORD  ArpRetryCount = 0
— CGretski
quelle
0

Haben Sie versucht, ein anderes Ethernet-Kabel / eine andere Ethernet-Verbindung zum nic zu verwenden? Haben Sie versucht, IPv6 auf dem Nic zu deaktivieren? Haben Sie die Firewall auf dem Computer ausgeschaltet und erneut überprüft?

— qore5
quelle
Haben Sie versucht, ein anderes Ethernet-Kabel / eine andere Ethernet-Verbindung zum nic zu verwenden? - Ja Haben Sie versucht, ipv6 auf dem Netzwerk zu deaktivieren? - Ja Haben Sie die Firewall auf dem Computer ausgeschaltet und erneut überprüft? -Ja
— Skye Bowen
Ich habe auch bekannt, dass Netzteile solche Probleme verursachen. Sie könnten versuchen, ein Netzteil von einer guten Maschine gegen diese auszutauschen. Ein bisschen Arbeit, könnte aber funktionieren und das Problem diagnostizieren.
— Qore5
Das Deaktivieren von IPv6 widerspricht den bewährten Methoden und Anleitungen von Microsoft und ist niemals eine Lösung für ein Problem, insbesondere nicht für dieses.
— Joeqwerty
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.