Netzwerkgeschwindigkeit bricht ein - server oder switch problem?

Die Fehlerquellen, sofern es nur das Netz sein sollte, können vielfältig sein. Erstmal solltest du testen ob du wirklich ein Performance Problem mit deinem Server bzw. Client hat. Dafür eignet sich das Tool netio sehr gut:

www.wintotal.de/softw/index.php?rb=28&id=671

Das rennt im DOS Fenster und zeigt dir deine Netzwerkperformance bzw. die deiner Karten bei unterschiedlichen Packetgrößen. Ein Aufruf ohne Parameter zeigt die Bedienung, die recht einfach ist. Damit kannst du dann erstmal generell sagen wie performant deine Apapter bzw. der Switch ist. Adapterperformance allein kannst du natürlich nur mit einer Back to Back Verbindung ohne Switch verifizieren.

Da der Fehler sporadisch auftritt könnten das durchaus Broadcast Stürme sein, dazu musst du aber rausbekommen wer der Verursacher ist. Ein gutes Tool dafür ist Ethereal:

www.ethereal.com

Ein Sniffertool, der dir sowas anzeigt. Allerdings benutzt du Switches und da ist das Messen nicht ganz einfach denn normal siehst du nur Broad- und Multicast Packete an so einem Port, was aber ggf. schon ausreicht um Verdächtige zu identifizieren. Ansonsten musst du einen Mirror Port definieren und daran messen. Wie das geht steht im Manual deines Switchherstellers. Hast du allerdings einen nicht mangebaren Switch hast du Pech, denn diese bieten solch eine Möglichkeit eben aus Preisgründen nicht.
Solcherlei Low Budget Switches haben meist eine sehr schwache CPU. Diese muss bei entsprechender Broadcastlast alle Broadcast Packete n mal auf alle Ports kopieren. Das überfordert bei einer entsprechenden Grundlast meist solche Systeme, so das die dann Packets droppen und es zu Verlangsamung kommt, da die Endgeräte retransmitten müssen oder schlimmstenfalls die Sessions abbbrechen.

Weitere Möglichkeit ist ein NIC Negotiation Problem deines Servers oder deiner Server. D.h. die Karte hat z.B. Full Duplex negotiated und dein Switch aber nur Half Duplex. Solange du moderaten Netzwerktraffic hast fällt das nicht weiter auf, da man meistens ein Half Duplex Verhalten in der Kommunikation der Rechner hat über die Zeit gesehen. Steigt allerdings die Anzahl der Benutzer und Transaktionen mit dem Server kann es durch den ungleichen Modus zu Kollisionen auf dem Link kommen und alles rennt im 3. Gang. Intelligente Switches blocken außerdem kurzzeitig solche Ports wenn die Collision Rate einen bestimmten Wert übersteigt, was das Verhalten verschlimmert.
Solche Diskrepanzen erkennst du wenn du dir den Switchport über die Managementconsole ansiehst und dazu deine NIC im Server. Im Fehlerfalle hilft hier das Setzen BEIDER Seiten auf feste Werte sowohl für Speed als auch für den Duplex Modus. Hast du einen nicht managebaren Switch hast du leider Pech und must mit so einem Fehler leben, denn auf die Link LEDs kann man sich keineswegs verlassen.

Hast du das Netzwerk ausgeschlossen kommen noch die Server und Komponenten dran und das ist eine weitere Geschichte... (siehe Kommentar oben)

Oha, dasklingt nicht gut. SMB ist Server Message Block, darunter kommuniziert Windows. PDU heisst Protocol Data Unit. Was aber sehr bedenklich ist das die Packet Checksum Fehler haben. Da muss man jetztmal schauen von wem genau diese Packete kommen. Das kann jetzt vielfältige Ursachen haben. Kaputte Netzwerkkkarte, kaputter Switch etc. Ggf. Back to Back Tests um Switches und andere aktive Komponenten auszuschliessen.
Ist auf alle Fälle eine höchst bedenkliche Fehlermeldung ! Solche Checksum Fehler treten sehr sehr selten in der Kommunikation auf. Wenn das gehäuft bei dir der Fall ist, ist da irgendwas fehlerhaft. Alle diese Packete werden verworfen, da sie eben fehlerhaft sind und die Endgeräte müssen retransmitten. Kein Wunder das dein Netz lahm ist...

Kein Problem.... Mit Back to Back meinte ich einen Client mit Crosskabel einmal direkt an den Server zu hängen ohne Switch um zu sehen ob diese Fehler noch auftreten. Ziel wäre damit rauszubekommen ob ggf. der Switch die Fehler verursacht.
Ein sliding Window bei einer TCP Session ist nicht unbedingt ein Problem. So passen sich die Entgeräte an wenn einer zu schnell sendet und der andere nicht schnell genug empfangen kann.
Deinen Einwand mit "doppeltem QoS" verstehe ich jetzt nicht genau. Normalerweise könnte ein Endgerät 802.1q QoS Bits setzen aber das machen dann meistens die Applikationen, da das ja sinnvollerweise applikationsabhängig sein sollte und nicht generell alles per Schrotschuss priorisiert werden sollte. Der 2. Punt bei QoS ist die Frage ob dein Switch das überhaupt versteht. Gemeine Consumer Switches ala Netgear 8 Port u.ä. können sowas nicht und ignorieren das schlicht. Andere Switches wiederum haben ein default QoS Profile indem sie das Queueing steuern je nach gesetzem TOS Bit. Bei den meisten muss man das aber über das Konsolmanagement einstellen bzw. konfigurieren, sonst ignorieren sie schlicht QoS. "Doppeltes" QoS kann es so eigentlich nicht geben. Endweder sind die Bits gesetzt oder nicht.... Da bei Mittelklasse Switches sowas meist in Hardware passiert sollten die eigentlich nicht überfordert sein und auch sollten daraus niemals Checksum Errors resultieren. Es sei den.... Dein Switch versteht das überhaupt nicht. 802.1q ist ein zusätzlicher Tag der an den Ethernet Frame angehängt wird. Ist dein Switch nicht 802.1q fähig erkennt er möglicherweise diesen Frame nicht als gültigen Ethernet Frame und quittiert ihn als Collision oder Giant, was dann wieder andere Problem hinter sich herziehen kann. Du solltest auf alle Fälle sämtliches QoS ausschalten wenn du einfache nicht QoS fähige Switches einsetzt.