IP-Adresskonflikt

Computer: Hardware Netzwerk
#1

Hallo,

ich habe das Problem, dass in meinem Netzwerk (ca. 60 PCs) bei einigen Rechnern ein IP-Adressenkonflikt auftritt.

Da es sich um einen großen Gebäudekomplex handelt ist es schwer, jeden einzelnen Rechner zu überprüfen.

Theoretisch sind alle PCs auf DHCP-IP-Bezug eingestellt. Lediglich die Rechner im Informatik-Raum (ca. 30 PCs) haben eine feste IP-Adresse des Bereichs 192.168.114.(201-232) zugewiesen bekommen. IPv6 ist überall deaktiv und wird nicht genutzt.

Nach dem Anmelden tritt jedoch bei rund 6 PCs ein IP-Konflikt auf und sie bekommen Adressen aus dem Raum 169.254.*.* zugewiesen.
Der DHCP-Server läuft auf unserem File-Server (Windows Server Standard 2007). Die entsprechende IP-Range des Informatik-Raums ist dort ausgeschlossen.
Auch die Lease-Tabelle sagt aus, dass diese IPs nicht vergeben wurden.

Leider konnte ich beim überprüfen der PCs im gesamten Gebäude keinen Rechner mit statischer IP finden.

Nun bin ich ratlos, da es ja dann eigentlich nicht zu einem Konflikt kommen dürfte.

Hat jemand eine Idee, woran es liegen könnte?
Sonst wäre ein Rat hilfreich, wie man beide am IP-Konflikt beteiligten Rechner über das Netzwerk ermitteln kann (der Computername wäre hier als Antwort hilfreich!).

Alle PCs laufen mit Windows 7 Prof Sp1 (64-bit).

Vielen Dank schonmal im Vorraus.
LG Jonas

#2

Hallo,

hast Du Notebooks dabei, die sich auch gelegentlich in anderen Netzen aufhalten?
Beobachte das Phänomen in meinem SOHO-Netzwerk (klein, übersichtlich, DHCP mit Range sauber konfiguriert) auch gelegentlich bei meinem dienstlichen Notebook (ursprünglich auch Win7 Enterprise, 64Bit), wenn ich damit mal wieder zwischendurch in der Firma online war. Allerdings läuft bei mir trotz der Meldung dann alles ganz normal, und ich habe auch noch keinen echten Konflikt entdecken können.

Da ich seit einer Woche Win 8.1 auf dem Gerät habe, und in der Zeit noch keine diesbezügliche Meldung hatte (obwohl ich zweimal in der Firma war), könnte es sein, das sich das Thema jetzt erledigt hat. Mal abwarten.

Gruß vom Wiz

#3

Theoretisch sind alle PCs auf DHCP-IP-Bezug eingestellt.
Lediglich die Rechner im Informatik-Raum (ca. 30 PCs) haben
eine feste IP-Adresse des Bereichs 192.168.114.(201-232)
zugewiesen bekommen. IPv6 ist überall deaktiv und wird nicht
genutzt.

Nach dem Anmelden tritt jedoch bei rund 6 PCs ein IP-Konflikt
auf und sie bekommen Adressen aus dem Raum 169.254.*.*
zugewiesen.

Wie jetzt? Das kann nicht sein. Entweder die haben eine statische IP, dann kracht es ggf. wenn diese mehrfach vergeben ist, oder sie kriegen die IP über DHCP.

Der DHCP-Server läuft auf unserem File-Server (Windows Server
Standard 2007).

Einen Windows Server Standard 2007 gibt es nicht.

Auch die Lease-Tabelle sagt aus, dass diese IPs nicht vergeben
wurden.

Das würde ich im Zweifelsfall mittels Ping prüfen. Was sagen die Log-Files und die Ereignisanzeige des Servers?

Leider konnte ich beim überprüfen der PCs im gesamten Gebäude
keinen Rechner mit statischer IP finden.

Nun bin ich ratlos, da es ja dann eigentlich nicht zu einem
Konflikt kommen dürfte.

kann auch nicht. Zumindest nicht, wenn alles so ist, wie beschrieben.

Hat jemand eine Idee, woran es liegen könnte?

Ggf. geistert ein weiterer DHCP Server im Netz herum?

Sonst wäre ein Rat hilfreich, wie man beide am IP-Konflikt
beteiligten Rechner über das Netzwerk ermitteln kann (der
Computername wäre hier als Antwort hilfreich!).

Auf welchen PC kommt denn überhaupt die Meldung? Ich würde auf dem PC, auf dem die Meldung kommt, dass die IP bereits benutzt wird, zunächst einmal prüfen, welche IP dieser hat. Dann vom Netz trennen und einen Ping auf die vermeintlich bereits vergebene IP absetzen. Mit dem ARP Befehl kann man dann die entsprechende MAC Adresse ermitteln, Anhand derer sich zumindest der Hersteller der NIC und daraus der Typ des Gerätes (Drucker/Switch/PC etc.) ergibt. Dann auf die Suche gehen. Oft hilft es auch einfach mal im Explorer ein \IPAdresse einzugeben um zu sehen, welche Freigaben und Drucker sich dahinter verbergen. Auch der testweise Aufbau einer RDP Verbindung zeigt meist, um welchen PC es sich handelt oder zumindest welcher User angemeldet ist.

Es gibt eine Vielzahl weiterer Tests und Diagnosemöglichkeiten. Z.B. temporär den DHCP Server Dienst deaktivieren, die angeblich doppelt vergebenen Adressen reservieren etc.

Als allererstes sollte aber geklärt werden, warum PC, die die Adresse statisch verwenden sollen, nach einem DHCP Server suchen und dann eine 169.254.*.* bekommen.

Und noch was: Ggf. hat irgendein HONK benutzerdefinierte MAC Adressen für die NICs vergeben. Das ist bei einem PC nicht schlimm. Wenn man das aber auf mehr als einem macht und zwei Mal die selbe MAC Adresse vergibt, knallt es mächtig.

Hilfreich ist es natürlich immer, wenn man alle Hosts mit MAC Adresse und IP inventarisiert hat.

#4

Hallo

169-er IPs sind sogenannte ‚APIPA-Adressen‘, die Windows selbständig vergibt, wenn via DHCP keine Konfiguration erhalten werden konnte.

Kommt wirklich die Meldung eines Adresskonflikts? Die fraglichen Rechner sind korrekt verkabelt? Also Kaben angeschlossen und nicht defekt? Lokal keine statische IP konfiguriert?

CU
Peter

#5

Steckt irgendwo an einem PC bzw. Laptop eine
Funkkarte eines Providers ??
Bzw. eine WLAN-Karte,die Verbindung mit einem anderen Netz aufnimmt ??

Denn die 169.xxx ist doch Zugangspunkt eines privaten Telekommunikationsbetreibers.

#6

nee, ist es eigentlich nicht.

169.254 da gibt sich windows selbst die adresse, wenn er keine hat oder keinen dhcp server erreicht.

#7

schon mal das eventlog der maschinen angesehen? da solltest du alles finden, was du suchst

#8

Hallo,

Denn die 169.xxx ist doch Zugangspunkt eines privaten
Telekommunikationsbetreibers.

nein, ist es natürlich nicht. 169.254.0.0/16 ist in RFC3330 gelistet.
Verwendungszweck: IP-Adressen selbst zuteilen, wenn DHCP aktiviert ist, aber kein DHCP-Server gefunden wird.

Gruß,
Steve

#9

Hallo Zusammen!

Vielen Dank für die vielen Ideen bzw. Rückmeldungen.

ich beantworte die einzelnen Punkte mal gemeinsam für alle Antworten:

Es gibt zwar einzelne Laptops bzw. Android-Geräte, die sich über W-LAN anmelden. Diese sind jedoch alle über DHCP mit Adressen versorgt. Laut Protokoll des DHCP-Servers auch alle im IP-Bereich 100-200 und somit außerhalb des „kritischen“ Bereichs 201-235.

Was mich halt total wundert ist, dass die PCs mit der Störung definitiv so konfiguriert sind, dass sie eine statische IPv4 z.B. 192.168.114.222 konfiguriert haben. Auch Subnetz und Gateway sowie DNS sind eingerichtet. Genau so, wie auch auf den PCs, die ohne Probleme funktionieren.
Nach dem Booten kommen die Problem-PCs jedoch nicht ins Internet. Wenn man dann über die Netzwerkverbindungen den Status der Netzwerkverbindung aufruft steht dort die IP aus dem 169er Bereich.

Die IP .222 ist jedoch definitiv nur einmal vergeben.
Es kommt dann teilweise der Hinweis, dass ein Adresskonflikt vorliegt. Dann ist auch definitiv immer eine 169er-IP eingestellt!
Wenn man die Netzwerkkarte dann deaktiviert und aktiviert, funktioniert alles ohne Probleme.

Mich wundert allerdings, dass wenn ich einen „arp -a“ am Server ausführe, dort 5-10 Rechner mit 169er-IPs aufgelistet werden, die ich aber auch nicht anpingen kann.

Eine Überlegung war jetzt noch, ob evtl. ein Bauteil defekt sein kann, wie z.B. ein Switch. Alle Leitungen kommen im Server-Raum zusammen (via Glasfaser) und werden dort über mehrere Switches verteilt. Wäre es denkbar, dass evtl. ein Switch defekt ist und zu solchen Störungen führt, an dem zufällig alle PCs mit den Problemen angeschlossen sind?

Zudem die Frage:
Führt ein IP-Konflikt dazu, dass eine 169er-IP an beiden beteiligten Rechnern konfiguriert wird?

LG Jonas

#10

Hallo Jonas,

Eine Überlegung war jetzt noch, ob evtl. ein Bauteil defekt
sein kann, wie z.B. ein Switch. Alle Leitungen kommen im
Server-Raum zusammen (via Glasfaser) und werden dort über
mehrere Switches verteilt. Wäre es denkbar, dass evtl. ein
Switch defekt ist und zu solchen Störungen führt, an dem
zufällig alle PCs mit den Problemen angeschlossen sind?

Wenn alles richtig konfiguriert ist, stellt der PC beim hochfahren eine DHCP-Anfrage.
Wenn nicht innerhalb von 2 Minuten eine Antwort kommt, wird angenommen, dass kein DHCP vorhanden ist und Windows vergibt eine 169er IP.

http://de.wikipedia.org/wiki/Dynamic_Host_Configurat…

Wenn der Switch die DHCP-Anfrage nicht weiterleitet, kommt natürlich keine Antwort oder die Antwort geht irgendwo verloren.

Es kann also sein, dass ein Switch einen Hau weg hat oder falsch konfiguriert ist, falls es ein konfigurierbarer Switch ist.
Allerdings müssten sich dann Gemeinsamkeiten bei den betroffenen PCs zeigen, die müssten alle hinter einem bestimmten Switch sitzen.

MfG Peter(TOO)

#11

Die betroffenen PCs sind jedoch alle mit statischen IPs konfiguriert! Keiner von denen ist auf DHCP-Bezug eingestellt, weswegen es mich ja so wundert, dass denen eine 169er-IP zugewiesen wird.

Ob die alle an einem Switch hängen weiß ich noch nicht. Bin leider nicht beim Aufbau des Netzwerkes dabei gewesen und muss erstmal gucken, dass ich entsprechende Dokumentationen auftreiben kann, die Aufschluss über die Verkabelung geben.
Konfigurierbar sind die Switches jedoch nicht!

Der DHCP-Server wurde zudem auch noch einmal komplett neu aufgesetzt, da ich die Vermutung hatte, dass dieser trotz statischer IP über die MAC-Adresse trotzdem einfach dem Rechner eine IP aufzudrängen versucht … hat aber auch leider nicht geholfen.

#12

Die betroffenen PCs sind jedoch alle mit statischen IPs
konfiguriert!

Die betroffenen PC stehen demnach alle im Informatikraum und sind mit einer statischen Adresse 192.168.114.(201-232) konfiguriert?

Wenn einer der betroffenen PC auf die Fehlermeldung läuft, kannst du dann von einem der nicht betroffenen PC dessen statische IP-Adresse anpingen? Kannst du sie anpingen, wenn dieser betroffene PC wieder ausgeschaltet ist?

Gruß

#13

Ja, alle betroffenen PCs stehen im Informatik-Raum und sind im Bereich 192.168.11.(201-232) konfiguriert.

Wenn ich versuche einen der „gestörten“ PCs über die fest konfigurierte IP anzupingen, erhalte ich keine Antwort.

Das mit dem Ausschalten habe ich noch nicht probiert. Kann ich morgen aber gerne mal machen.

#14

Das mit dem Ausschalten habe ich noch nicht probiert. Kann ich
morgen aber gerne mal machen.

Einen korrekten Versuchsaufbau vorausgesetzt (nicht betroffener PC kann konfigurierte IP-Adresse eines betroffenen PC unmittelbar nach Aufscheinen der Fehlermeldung nicht pingen) ist der Versuch bei ausgeschaltetem betroffenen PC müßig. Bei einem tatsächlichen Adressenkonflikt bleibt der ursprüngliche Inhaber der Adresse nämlich immer pingbar.

Wenn die doppelt vergebene Adresse aber von einem dritten Rechner aus nicht pingbar ist, dann befindet sich dieser dritte Rechner in einem anderen Netz, oder der Adresskonflikt ist lokalen Ursprungs, oder die Fehlermeldung verweist nicht auf das tatsächliche Problem. Oder es liegt, wie schon von Wiz vermutet, ein Windows-Bug vor… Oder ich übersehe ein Szenario!

Ich kann mir folgende im Netzwerkdesign angelegte Ursachen für die Fehlermeldungen vorstellen:

  • die betroffenen PC sind in einem anderen Netz, als die nicht betroffenen PC. Wenn eure Switches nicht konfigurierbar sind, würde das bedeuten, dass diese PC an einem anderen Switch hängen
  • auf den betroffenen PC ist nicht die tatsächlich genutzte, sondern eine andere Netzwrkschnittstelle konfiguriert. Haben die PC genau eine physische ethernet-Schnittstelle und ist auch tatsächlich die konfiguriert (und nicht etwa irgendeine Firewire- oder tap- oder sonstwas-Schnittstelle)? Was sagt der Gerätemanager?
  • die betroffenen PC haben DNS-Namen, die bereits anderen PC zugewiesen sind

Gruß

#15

Hallo Fragewurm,

Wenn die doppelt vergebene Adresse aber von einem dritten
Rechner aus nicht pingbar ist, dann befindet sich dieser
dritte Rechner in einem anderen Netz, oder der Adresskonflikt
ist lokalen Ursprungs, oder die Fehlermeldung verweist nicht
auf das tatsächliche Problem. Oder es liegt, wie schon von Wiz
vermutet, ein Windows-Bug vor… Oder ich übersehe ein
Szenario!

Mir kommt noch eine doppelte MAC-Adresse in den Sinn.

MfG Peter(TOO)

#16

Noch eine Idee
Hallo,

ich nochmal!

Haben die betroffenen Rechner alle genau eine Netzwerkschnittstelle, oder sind da weitere Schnittstellen in den Netzwerkeinstellungen vorhanden (WLAN, Bluetooth, virtuelle Schnittstellen für irgendeine Virtualisierung, weitere Karten, die eine Schnittstelle zur Verfügung stellen - das können sogar ISDN- und TV-Karten, … sein)?

Man kann in den Netzwerkeinstellungen ziemlich versteckt die Reihenfolge der Verbindungen definieren. Und zwar in der Systemsteuerung unter Netzwerk und Internet\Netzwerkverbindungen\Erweitert\Erweiterte Einstellungen.

Schau doch mal nach, ob bei den betroffenen Rechnern da tatsächlich nur das richtige Netzwerk vorhanden ist/zumindest an erster Stelle steht.

Gruß vom Wiz

#17

ich würde sie einfach mal auf dhcp stellen, ich vermute hier eher fehler bei den fest vergebenen adressen.
was spricht gegen einen dhcp test?

#18

Hi …

nur um meine 2 Ideen noch loszuwerden … wenn wir uns einig sind, dass ein „echter“ Ip Konflikt vermutlich nicht vorliegt , es könnte durchaus sein, dass Dich ein fehlkonfiguriertes Netzwerkkistchen narrt.

Ich kann mich leider nur noch dunkel und nicht im genauen Detail erinnern, aber ich hatte sowas einmal … ein Kästchen, das auf fast jeder IP Adresse einen IP Konflikt verursacht hat. Ursache war ein verunglückter Versuch, das Kästchen als Netzwerk-Bridge zu betreiben. Es hat versucht, per Proxy-ARP Funktion den IP Traffic aller Stationen auf sich umzuleiten, wenn es dachte, dass sich der Empfänger auf der entfernten Seite der Bridge befindet. Daher hat es die ARP Requests von Clients, die das Vorhandensein ihrer eigenen IP ADresse prüfen wollten, mit seiner eigenen MAC Adresse beantwortet, was die PCs wiederum als IP Konflikt gedeutet haben.

Mit einem Netzwerk-Sniffer (Wireshark) an einem Netzwerk-Port eines betroffenen PCs eigeschleift (per Hub - ich hab extra dafür noch einen in der Schublade) oder per Port-Mirror (am Switch einzustellende Spiegelung eines Ports zum Zweck des Netzwerk-Sniffens) findest Du schnell heraus, welche Maschine (MAC Adresse) den Konflikt meldet. Bereits die MAC Adresse, aus der Du den Hersteller des Netzwerk-Chips rauslesen kannst (Tabellen gibts im internet) reicht manchmal als Hinweis, um das Gerät zu identifizieren. Wenn die Switches intelligent sind kannst Du die Management-Software nach dem Port suchen lassen, an dem sich die MAC Adresse befindet.

Man findet dann irgendwelche Kisten, z.B. ausgemusterte Router, von Laien per Tiral and Error eingerichtet und ans Netzwerk angeschlossen, um z.B. das eigene Büro mit WLAN zu versorgen, so ein Kästchen wäre möglicherweise gut für so eine Fehlfunktion.

Eine Variante wäre - ich habs allerdings nicht ganz zu Ende durchgedacht, für heute Nacht bin ich ziemlich fertig mit der Welt - wenn jemand so einen ausgemusterten Router als WLAN AP aufbauen würde und vergessen würde, seine DHCP Funktion abzuschalten, und wenn diese vom IP Range her mit eurem „richtigen“ DHCP überlappen würde. Unter Umständen würden die beiden konkurrierenden DHCP Server die gleiche IP Adresse an zwei verschiedene PCs vergeben.

Gruss Armin.

#19

Hi …

Mir kommt noch eine doppelte MAC-Adresse in den Sinn.

Jo. Hatte ich auch mal, ein ganzer Karton Intel Netzwerkkarten mit der gleichen MAC Adresse. War wohl ein kleiner Fehler bei der Produktion …

Und mir kommt zusätzlich noch ein anderer Dinosaurier aus längst vergangenen Tagen in den Sinn: DecNet. Manchmal parallel zu TCP/IP installiert um mit alten DEC/VMS/VAX Computern Daten auszutauschen. Die Achillesferse des Protokolls: an Hand einer manuell zu vergebenen DECNet Adresse wird dem Computer allen Ernstes eine eigene MAC Adresse aufgezwungen. Doppelte DecNet Adresse verursacht doppelte MAC Adresse. Das Verhalten tritt besonders dann auf, wenn man Computer mit installiertem DecNet voneinander clont, alle Clones haben dann die gleiche MAC Adresse, sobald das DecNet Protokoll hochläuft.

DecNet sollte eigentlich längst ausgestorben sein, aber Tote leben bekanntlich länger …

Gruss Armin.

#20

Hallo,

prüfungsbedingt bin ich leider erst heute wieder einsatzfähig.

Jetzt aber mit neuen Infos und verschiedenen Testergebnissen.

Hier ist ein Screenshot der Detailinformationen eines gestörten Rechners:
http://pl.vc/2sbm4

Finde ich schonmal komisch, da dort die statische IP definitiv gesetzt ist!

Testabläufe:

statisch: ist immer die fest konfigurierte IP des gestörten PCs
dynamisch: ist immer die frei zugewiesene IP des gestörten PCs
richtige MAC = MAC des gestörten PCs

  1. nbtstat -A dynamisch: Erfolgreich (Name: PC-Raum18, eindeutig, richtige MAC)

  2. nbtstat -A statisch: Host nicht gefunden

  3. ping: dynamisch und statisch nicht erreichbar

  4. arp -a (vom Server, ist auch DNS-Server ausgeführt):
    statische: fehlt als Eintrag
    dynamische: gelistet mit richtiger MAC

  5. Kabel am gestörten PC entfernt

  6. ping: dynamisch und statisch nicht erreichbar

  7. nbtstat: dynamisch und statisch „Host nicht gefunden“

  8. Kabel am gestörten PC eingesteckt

  9. ping statische: Erfolgreich (Der PC kommt auch wieder ins Internet)

  10. ping dynamisch: Host nicht gefunden.

Soweit von mir. Wenn ich noch etwas durchführen soll … einfach sagen :wink:

LG Jonas

PS: Es gibt lediglich einen W-LAN-AP, dieser besitzt keine DHCP-Funktion. Ansonsten sind nur PCs über Kabel angeschlossen, die WinXP oder Win7 haben. Die IPs sind überall dynamisch, außer im PC-Raum (hier: 192.168.114.200-230). Die IP-Lease-Tabelle des DHCP ist soweit sauber, dass keine IPs aus der PC-Raum-Range gesetzt wurden.