Regelmäßige ping-Timeouts bei Windows 2003 DC

[hs1]

Hallo Leute,

ich habe folgendes Problem bei dem ich nicht weiterkomme:

Windows 2003 Server der als DC und Terminalserver (für kleine Minianwendung) läuft. Seit einigen Tagen bleibt die Remotedesktopverbindung zu dem Server ständig hängen (d. h. keine Eingaben möglich für ein paar Sekunden).

Nach einiger Recherche und Auswertung der Ereignisprotokolle habe ich mal einen ping -t auf den Server gemacht. Mit dem Ergebnis, dass mindestens einmal in der Minute ein Timeout kommt (hab' das -wait auch mal auf 5000 ms erhöht).

Folgendes habe ich bisher gemacht:

- Reboot des Servers

- An anderen Switch angeschlossen und am gleichen Switch in anderen Port gesteckt

- Netzwerk-Kabel gewechselt (Cat7)

- Auf der Konsole gearbeitet (da tritt während eines Timeouts kein "hängen") auf.

- Server von verschiedenen Servern/Rechnern am gleichen und anderen Switch angepingt

Kann evtl. auch eine defekte Netzwerkkarte die Timeouts verursachen? Wie kann ich das Problem weiter eingrenzen?

Viele Grüße

hs1

[Gast]

Siehst du auf dem Switch auf dem Port um DC was auffälliges, Packet Drops oder CRC Fehler. Hast du die Möglichkeit Port Mirroring zu betreiben, heißt den Port spiegeln und an diesem dann mit Wireshark sniffen bis das Problem wieder auftritt.

Wenn das Ereignisprotokoll von Windows dir keine aussagekräftigen Daten liefert würde ich auch annehmen das die Netzwerkkarte defekt ist.

Das Problem besteht seit wann, sind irgendwelche Änderungen am DC oder Netzwerk in diesem Zeitfenster gewesen?

[SilentDemise]

Ist das ein Server 2003 oder ein 2003 R2? Was für ein Client wird verwendet?

[hs1]

Moin,

danke für Eure Antworten!

Gestern Abend waren zwischenzeitlich alle Netzwerkverbindungen auf allen Rechnern weg. Daraufhin habe ich den Switch neugestartet, bis jetzt scheint das Problem nicht mehr aufgetreten zu sein. Wir beobachten das noch weiter.

Gruß hs1

[Wuwu]

An anderen Switch angeschlossen

Ich weiss nicht was das neustarten des Switches jetzt hilft, der Switch war ja offenbar nicht die Fehlerursache.

[hs1]

Bin mir nicht sicher, weil die beiden Switches miteinander verbunden sind. D. h. theoretisch könnte der Switch schon die Ursache sein. Jedenfalls ist das Problem seit dem Neustart nicht mehr aufgetreten. Wir merken es sofort wenn es wieder auftritt. Nächste Woche aktualisieren wir die Firmware des Switches.

[Gast]

Hallo,

das hört sich aber ganz stark nach einem defekten oder überlasteten Switch an....

Mögliche Ursachen, die mir spontan einfallen:

- sind die Switche leistungsfähig genug?

- Spanning Tree deaktiviert und einen Loop gesteckt?

- Hardwaredefekt

- Fehlerhafte Konfiguration bei einer Link Aggregation

- Fehlerhaft konfigurierter Switch-Stack.

- Duplex-Missmatch bzw. Fehler bei der Autonegotiation. Können die Switche Auto MDI-X bzw. ist ein Crossover-Kabel zwischen diesen beiden verwendet?

P.s.: Was sind das denn für Switche?

mfg Hendrik232

Bearbeitet 17. April 2015 von hendrik232

[Gast]

qhendrik232

Duplex Mismatch und Auto-Negotiation Problem müsste auf dem Switch sichtbar sein, sofern es sich um einen Managed Switch handelt(Kolissionen und Speed/Duplex sichtbar). Auto-MDIX ist völlig egal, denn wenn das falsche Kabel angeschlossen wurde gibt es schon auf elektrischer Ebene keine Verbindung. Damit ist klar das höhere Layer auch nicht funktionieren.

Gleiches gilt bei Link Aggregation wenn du etwa einen Port-Channel meinst, läuft oder läuft nicht. Ich tippe ganz stark darauf das ein Hardwaredefekt vorliegt, entweder auf der Seite des Servers oder auf bei den Switches.

Am besten mal in die Logs vom Switch einen Blick hineinwerfen.

[Gast]

Duplex Mismatch und Auto-Negotiation Problem müsste auf dem Switch sichtbar sein, sofern es sich um einen Managed Switch handelt(Kolissionen und Speed/Duplex sichtbar). Auto-MDIX ist völlig egal, denn wenn das falsche Kabel angeschlossen wurde gibt es schon auf elektrischer Ebene keine Verbindung. Damit ist klar das höhere Layer auch nicht funktionieren.

Ich habe nichts anderes behauptet. Es besteht jedoch durchaus ein Zusammenhang zwischen Auto-MDIX und Autonegotiation. Wenn Auto-MDIX aktiviert ist, dann darf bei einigen Switchherstellern keine feste Geschwindigkeit konfiguriert sein.

Gleiches gilt bei Link Aggregation wenn du etwa einen Port-Channel meinst, läuft oder läuft nicht.

Stimm nicht. Wenn auf einem Switch eine Link Aggregation konfiguriert ist und auf dem gegenüberliegenden Switch nicht, so kann die Verbindung durchaus funktionieren. Es kann jedoch zu massiven Performanceproblemen kommen. Zum Beispiel durch Broadcast-Frames: Switch A hat eine Link Aggregation konfiguriert und leitet einen Broadcast-Frame, der über die Link Aggregation eingeht, an alle anderen Ports weiter, die nicht in der Link Aggrregation eingebunden sind. Switch B ohne eine korrekt konfigurierte Link Aggregation leitet die Frames auf allen Ports, mit Ausnahme des Eingangsports, weiter. So kann es bei einer Link Aggregation mit vier Leitungen dazu kommen, dass Switch A diesen Broadcast-Frame vier mal bekommt.

P.s.: Zu der Begrifflichkeit Link Aggregation: Hier verwendet jeder Hersteller sein eigene Bezeichnung. Bei Cisco wäre dies Etherchannel und der einzelne logische Port heisst dann Port-Channel. Weitere mögliche Namen hierfür: Bonding, Teaming, Port Aggregation, Trunking .....

mfg Hendrik232

Bearbeitet 19. April 2015 von hendrik232

[Gast]

Ich habe nichts anderes behauptet. Es besteht jedoch durchaus ein Zusammenhang zwischen Auto-MDIX und Autonegotiation. Wenn Auto-MDIX aktiviert ist, dann darf bei einigen Switchherstellern keine feste Geschwindigkeit konfiguriert sein.

Das kenne ich aus meiner bisherigen Erfahrung zum Glück nicht, bei welchen Herstellern ist das der Fall?

Und bei Gigabit-Ethernet entfallen die fixen Einstellungen eh komplett laut Standard,sofern sich der/die Hersteller daran hält/halten.

Bezüglich dem Link Aggregation sprechen wir also von ein und demselben nur das die Hersteller halt Marketingtechnisch unterschiedliche Namen haben. Gut, das passt dann soweit. Hoffe doch das das Netzwerk mittels VLANs segmentiert ist um die Auswirkungen von Broadcast zu minimieren.

Bearbeitet 19. April 2015 von laufzeitfehler