Wie defekten PC im Netzwerk identifizieren?
Hallo Administrator-Community,
ich habe ein Problem mit unserem Netzwerk. Ich habe für einen Schulungsraum 14 gebrauchte PCs gesponsort bekommen, da die alten Geräte nun wirklich zum Alten Eisen gehörten (Pentium 4).
Wir haben ein novellbasiertes Netzwerk mit Zenworks im Einsatz und bisher hat auch alles reibungslos funktioniert (Imaging, Management der Geräte, Paketierung von Software), allerdings bereitet mir dieser Raum so langsam Kopfschmerzen.
Ich habe die alten Geräte alle entsorgt und die neuen Gebrauchten normal mit dem Netzwerk verbunden. Will ich nun mit den PCs arbeiten, so legt eines der Geräte das komplette Netz lahm (Unterverteilung für diesen Raum und den Knotenpunkt für drei verschiedene Gebäude zum Server). Dies erkenne ich daran, dass die PCs dann im PXE Preboot vom DHCP keine IP mehr zugewiesen bekommen. Starte ich den Switch der Unterverteilung und im Knotenpunkt neu, so funktioniert wieder alles bis ich die PCs erneut einschalte.
Zur Info: die Switche haben keine besondere Konfiguration und beziehen ihre IP-Adressen vom DHCP (es handelt sich um einen Nortel Switch in der Unterverteilung und einen Level1 Switch im Knotenpunkt).
Meine Frage lautet nun: gibt es eine besondere Möglichkeit das schwarze Schaf ausfindig zu machen oder muss ich mühsam jedes Gerät einzeln anstecken und testen, wer der Verantwortliche ist?
ich habe ein Problem mit unserem Netzwerk. Ich habe für einen Schulungsraum 14 gebrauchte PCs gesponsort bekommen, da die alten Geräte nun wirklich zum Alten Eisen gehörten (Pentium 4).
Wir haben ein novellbasiertes Netzwerk mit Zenworks im Einsatz und bisher hat auch alles reibungslos funktioniert (Imaging, Management der Geräte, Paketierung von Software), allerdings bereitet mir dieser Raum so langsam Kopfschmerzen.
Ich habe die alten Geräte alle entsorgt und die neuen Gebrauchten normal mit dem Netzwerk verbunden. Will ich nun mit den PCs arbeiten, so legt eines der Geräte das komplette Netz lahm (Unterverteilung für diesen Raum und den Knotenpunkt für drei verschiedene Gebäude zum Server). Dies erkenne ich daran, dass die PCs dann im PXE Preboot vom DHCP keine IP mehr zugewiesen bekommen. Starte ich den Switch der Unterverteilung und im Knotenpunkt neu, so funktioniert wieder alles bis ich die PCs erneut einschalte.
Zur Info: die Switche haben keine besondere Konfiguration und beziehen ihre IP-Adressen vom DHCP (es handelt sich um einen Nortel Switch in der Unterverteilung und einen Level1 Switch im Knotenpunkt).
Meine Frage lautet nun: gibt es eine besondere Möglichkeit das schwarze Schaf ausfindig zu machen oder muss ich mühsam jedes Gerät einzeln anstecken und testen, wer der Verantwortliche ist?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 228643
Url: https://administrator.de/contentid/228643
Ausgedruckt am: 25.11.2024 um 10:11 Uhr
13 Kommentare
Neuester Kommentar
Hi Verwesend,
Aber dass Switche sind die Konfiguration via DHCP ziehen ist eher unnormal.
Das könnte auch schon auf dein Problem hinweisen.
Wenn ein Client schneller ist als der Switch, kann der evtl. Probleme bekommen.
Die Infrastruktur wird sinnvollerweise mit einer stabilen, festen Konfiguration betrieben.
Außerdem kannst du mal einen Wireshark am Switch laufen lassen. Damit kannst du ohne Konfiguration die Broadcast- und Learning-Pakete aufzeichnen. Dort steht vermutlich etwas, was als Hinweis dienen kann.
Gruß
Netman
Aber dass Switche sind die Konfiguration via DHCP ziehen ist eher unnormal.
Das könnte auch schon auf dein Problem hinweisen.
Wenn ein Client schneller ist als der Switch, kann der evtl. Probleme bekommen.
Die Infrastruktur wird sinnvollerweise mit einer stabilen, festen Konfiguration betrieben.
Außerdem kannst du mal einen Wireshark am Switch laufen lassen. Damit kannst du ohne Konfiguration die Broadcast- und Learning-Pakete aufzeichnen. Dort steht vermutlich etwas, was als Hinweis dienen kann.
Gruß
Netman
Moin.
Zur Effektivität von Fehlersuche gibt es eine gute Idee: Schalte die Hälfte ein (hier: 8) ist der verursachende PC nicht dabei, schalte von den restlichen 7 wiederum die Hälfte (also 4) ein, und so weiter. Dann hast Du den Verursacher spätestens nach 4 Durchgängen gefunden und nicht nach 15 (bzw. genaugenommen 14).
Zur Effektivität von Fehlersuche gibt es eine gute Idee: Schalte die Hälfte ein (hier: 8) ist der verursachende PC nicht dabei, schalte von den restlichen 7 wiederum die Hälfte (also 4) ein, und so weiter. Dann hast Du den Verursacher spätestens nach 4 Durchgängen gefunden und nicht nach 15 (bzw. genaugenommen 14).
Salute,
Kann es sein, dass eventuell dein DHCP-Pool voll ist, sprich keine IP-Adressen mehr frei hat, die er vergeben darf?
Wie viele Adresse kann dein DHCP denn vergeben?
Für wie viele Rechner im Scope ist denn platz?
Grüße, freshnfunkyy ♪ ♫
Dies erkenne ich daran, dass die PCs dann im PXE Preboot vom DHCP keine IP mehr zugewiesen bekommen. Starte ich den Switch der Unterverteilung und im Knotenpunkt neu, so funktioniert wieder alles bis ich die PCs erneut einschalte.
Kann es sein, dass eventuell dein DHCP-Pool voll ist, sprich keine IP-Adressen mehr frei hat, die er vergeben darf?
Wie viele Adresse kann dein DHCP denn vergeben?
Für wie viele Rechner im Scope ist denn platz?
Grüße, freshnfunkyy ♪ ♫
Hallo,
mal nach einem Kabelbruch gesucht oder einem LAN Port mit
ein wenig Staub drinnen? Eventuell ist auch nur ein Port bei einem
Switch hinüber und man sollte sich einmal überlegen ob man nicht
umsteckt um zu sehen ob es dann funktioniert.
denn heute zu Tage kann man ja so etwas schon dort verstellen und wenn Du nun zwei
PCs hast die die gleiche MAC Adresse haben dann wird es eben auch zu solchen komische
Reaktionen kommen können.
Gruß
Dobby
mal nach einem Kabelbruch gesucht oder einem LAN Port mit
ein wenig Staub drinnen? Eventuell ist auch nur ein Port bei einem
Switch hinüber und man sollte sich einmal überlegen ob man nicht
umsteckt um zu sehen ob es dann funktioniert.
Meine Frage lautet nun: gibt es eine besondere Möglichkeit das schwarze Schaf ausfindig zu machen
oder muss ich mühsam jedes Gerät einzeln anstecken und testen, wer der Verantwortliche ist?
Eventuell mal schnell die MAC Adressen in den BIOS LAN Einstellungen kontrollierenoder muss ich mühsam jedes Gerät einzeln anstecken und testen, wer der Verantwortliche ist?
denn heute zu Tage kann man ja so etwas schon dort verstellen und wenn Du nun zwei
PCs hast die die gleiche MAC Adresse haben dann wird es eben auch zu solchen komische
Reaktionen kommen können.
Gruß
Dobby
Hi,
also ich geb auch mal meinen Senf dazu. Wenn ich dich richtig verstanden habe, geht es dir darum das du nicht zu jedem PC rennen musst ihn anschalten und nachsehen ob es funktioniert, um dir deine Wertvolle Zeit für andere Dinge zu sparen. Verständlich! Weniger verständlich, die Hälfte der Kommentare die dich locker mal das doppelte an Zeit kosten würden.
Meine Einschätzung:
Ich geh einfach mal davon aus das ihr ab dem "Knotenpunkt" Routet, oder ein VLAN verwendet. Demnach tippe ich darauf das eine Netzwerkkarte im PC einen Hau weg hat und einen Broadcaststurm in deiner Kollisionsdomäne auslöst. Deine ARP Table auf den Switches füllen sich und je nach Firmware haben die anschließend nicht mehr große Lust zu arbeiten (Burnout :-P). Durch den Strom ziehen und wieder rein stecken baut der Switch diese Tabelle neu auf und funktioniert wieder. Den Hinweis das eine NIC vll die gleich MAC hat würde ich ignorieren, das ist sehr unwahrscheinlich, wenn auch nicht unmöglich, aber selbst wenn es so sein sollte hast du lediglich die die Situation die bei einem klassischen ARP Spoofing gegeben ist und keinen Ausfall deiner Switsches.
Mein Vorschlag:
Wenn du am Schulungsraum einen Managbaren Switch hast dann log dich auf die Managmentconsole ein, mach die rechner an und schau die an wo dein Broadcastaufkommen am hösten ist, bzw. wo du die meisten Bad Packets bekommst. Das geht meistens bei so einem Defekt mit einher. Ansonsten bleibt dir nur die möglichkeit von DerWoWusste.
Gruß
PJM
also ich geb auch mal meinen Senf dazu. Wenn ich dich richtig verstanden habe, geht es dir darum das du nicht zu jedem PC rennen musst ihn anschalten und nachsehen ob es funktioniert, um dir deine Wertvolle Zeit für andere Dinge zu sparen. Verständlich! Weniger verständlich, die Hälfte der Kommentare die dich locker mal das doppelte an Zeit kosten würden.
Meine Einschätzung:
Ich geh einfach mal davon aus das ihr ab dem "Knotenpunkt" Routet, oder ein VLAN verwendet. Demnach tippe ich darauf das eine Netzwerkkarte im PC einen Hau weg hat und einen Broadcaststurm in deiner Kollisionsdomäne auslöst. Deine ARP Table auf den Switches füllen sich und je nach Firmware haben die anschließend nicht mehr große Lust zu arbeiten (Burnout :-P). Durch den Strom ziehen und wieder rein stecken baut der Switch diese Tabelle neu auf und funktioniert wieder. Den Hinweis das eine NIC vll die gleich MAC hat würde ich ignorieren, das ist sehr unwahrscheinlich, wenn auch nicht unmöglich, aber selbst wenn es so sein sollte hast du lediglich die die Situation die bei einem klassischen ARP Spoofing gegeben ist und keinen Ausfall deiner Switsches.
Mein Vorschlag:
Wenn du am Schulungsraum einen Managbaren Switch hast dann log dich auf die Managmentconsole ein, mach die rechner an und schau die an wo dein Broadcastaufkommen am hösten ist, bzw. wo du die meisten Bad Packets bekommst. Das geht meistens bei so einem Defekt mit einher. Ansonsten bleibt dir nur die möglichkeit von DerWoWusste.
Gruß
PJM
Zitat von @Fowesed:
Die Switche sind zwar managebar, allerdings setzen wir keine VLANs ein. Ich vermute wirklich dass es sich um einen bestimmten PC
handelt, bei dem die Netzwerkkarte defekt ist. Ich tausche diese morgen mal gegen eine neue aus und berichte dann
Die Switche sind zwar managebar, allerdings setzen wir keine VLANs ein. Ich vermute wirklich dass es sich um einen bestimmten PC
handelt, bei dem die Netzwerkkarte defekt ist. Ich tausche diese morgen mal gegen eine neue aus und berichte dann
Das eine hat ja mit dem anderen nix zu tun Schauen ob du Bad Packets hast kannste auch ohne Vlan. Vlan hab ich nur erwähnt wegen dem Punkt mit der Broadcastdomäne. (Kollisiondomäne war falsch)