Netzwerkprobleme mit Managed Switch 2.5G mit SFP+

[Datanette]

...

 

[Eye-Q]

So wie Du das erklärst ist leider noch einiges unklar, weil Du nur die beiden Switches beschrieben hast. Kannst Du mal bitte versuchen, alle physischen Netzwerkverbindungen aufzuzeichnen? Was für andere Switches und Geräte sind im Netzwerk vorhanden? Wie hast Du das ohne LWL getestest, wenn die beiden Switches in unterschiedlichen Gebäuden sind?

 

[radicale]

Vor 4 Wochen hatte ich auch solche Switches im Einsatz, 8x 2,5 Gbit und 2x SFP+. Findet man auch bei dem großen Fluss im Angebot teilweise sogar noch billiger.

Zum Anfang hin haben die Teile (2 Stück mittels SFP+ 10Gbit) problemlos in Betrieb gehabt. Probleme gab es dann, als so langsam Last auf die Verbindungen gegeben wurde. Sobald ich 2 Port's 2,5 GBit mit 50 % Dauerlast ausgelastet habe, haben die Probleme angefangen. Anfänglich mit Drops bis hin zu Verbindungsabbrüchen. Stellenweise wurden die Verbindungen heruntergehandelt auf 1 Gbit. Sobald die Teile wieder weniger Last hatte, war das Problem auch wieder beseitigt. Entweder die Chips sind der letzte Dreck oder die Kühlung der Kisten ist ein Alptraum.

Qualität kostet doch eben etwas mehr.

 

[74181]

"Receive drops" sind etwas anderes als "recieve errors". Erstere können beispielsweise entstehen, wenn die TTL der eingehenden Pakete 1 oder 0 ist. Oder wenn das Protokoll nicht unterstützt wird. Letztere würde ich bei Übertragungsproblemen erwarten.

Bei den Screenshots Deines Switches sehe ich keine receive drops oder errors? Bei dem Interface eth0 schon. Von welchem Gerät ist das? Dein PC? Du könntest dort mal Wireshark starten. Es würde mich nicht wundern, wenn es Netzwerk-Management-Pakete sind - zumal Du ja als Häufigkeit auch ungefähr 1/s erwähnst.

Du könntest testweise möglichst viele Management-Funktionen Deiner Switches abschalten (insbesondere IGMP) und schauen, ob es besser wird.

 

[74181]

Na ja, Wireshark zeigt alle Pakete an, die an einem Interface gesendet oder empfangen werden. In der Spalte "Protocol" steht TCP, UDP, ICMP, HTTP, TLS, QUIC, Wireguard, usw. für Datenverkehr und IGMP, CDP, STP, RSTP, EIGRP, BGP usw. für Netz-Management Verkehr.

Das Problem ist häufig, dass sehr viele Pakete ein- und ausgehen. Dadurch sieht man den Wald vor lauter Bäumen... ähh Paketen nicht mehr. Man kann entweder Filter in Wireshark setzen. Oder man sorgt dafür, dass man eine freie Leitung hat und nur die gewünschten Pakete über die Leitung gehen. Manchmal muss man ein bisschen experimentieren, bis man das Ergebnis hat.

In Deinem Fall könntest Du gleichzeitig den Receive Drop Zähler und die eingehenden Netzpakete betrachten - und schauen, ob Du eine Übereinstimmung findest. Vorher könntest Du alle PCs und Server aus dem LAN entfernen, damit diese nicht störenden Datenverkehr auf das Interface schicken, das Du gerade belauschst.

PS: Falls Du Wireshark nicht auf dem NAS laufen lassen kannst, gibt es als leichtgewichtige Form das Programm "tcpdump". Dieses kann Pakete auf einer Konsole anzeigen. Oder es kann den Datenverkehr in eine Dump-Datei schreiben. Diese kann man auf einem anderen Rechner kopieren, in Wireshark öffnen und dort analysieren. Siehe: Capturing with “tcpdump” for viewing with Wireshark

PPS: Manche Switche und Router können ein- und ausgehende Daten auch direkt in eine Dump-Datei schreiben. Auch diese kann man auf einem anderen Rechner kopieren, in Wireshark öffnen und dort analysieren.

 

[74181]

Somit wäre das erste Rätsel soweit gelöst. Super, danke vielmals an die Helfer!
Es fragt sich, ist das dann ganz normal, wenn loop-detection eingeschaltet ist?

Erst mal toll, dass Du den Netzwerkverkehr ausgewertet hast und den Grund für die "receive drops" gefunden hast!

Wenn man mehrere Switches hat, kann es recht schnell passieren, dass man eine Loop schaltet. Man bekommt das auch mit einem einzigen Switch hin: Kabel zu sich selbst. Wenn man solche Loops hat, können Broadcast-Stürme entstehen: ein Rechner schickt ein Broadcast-Paket (ein Paket an alle anderen Netzteilnehmer). Das fließt dann im Kreis und wird immer und immer wieder an alle Teilnehmer verschickt. So lange, bis die TTL bei 0 ist. Bei großen Netzen und wenn viele Teilnehmer Broadcast-Pakete schicken, kann man damit mühelos das ganze Netz lahmlegen.

Deshalb gibt es Loop Detection Protokolle wie STP oder auch RLDP. Sie versuchen, solche Loops zu entdecken. Wenn sie eine Loop feststellen, werden die entsprechenden Ports gesperrt.

Das ist keine Boshaftigkeit, sondern ein wichtiges Feature. Ohne das könnte man keine größeren LANs aufbauen.

Wenn man ein kleines LAN hat, kann man Loop Detection ausschalten. Wenn man doch eine Loop haben sollte, muss man mit dem Ärger leben.

Ein weiterer Nachteil der Loop Detection und anderer Selbstschutz-Protokolle ist, dass man häufig nicht sofort eine Verbindung bekommt, wenn man einen Rechner neu an einen Switch anschließt, sondern dass es ein paar Sekunden bis zu einer halben Minute dauern kann. Profi-Switches reagieren manchmal auch sehr unwirsch, wenn man den Port wechselt. Das sollte man im Hinterkopf behalten, wenn man mit solchen Switches arbeitet.

Auch das zweite Problem ist damit schon behoben. Traffic speed ist wieder so schnell wie gewohnt.
Es fragt sich nur noch, was diese sporadischen Totalstillstände mit Drosselung auf 1MB/s auslöst oder ausgelöst hat. Ich bin gespannt, ob die nun auch weg sind.

Das ist merkwürdig. Loop Detection sollte nicht zu diesem Verhalten führen...

 

[74181]

@Datanette: wie schon gesagt: ich glaube nicht, dass Loop Detection zu den von Dir beschriebenen Leistungseinbrüchen führt. Es könnte sich natürlich um einen Bug auf dem Switch handeln - aber das halte ich für unwahrscheinlich.

Wahrscheinlicher ist, dass es doch ein Problem auf Deinem Link oder in Deinem Netz gibt. Vielleicht tritt es nur manchmal oder nur selten auf? Wenn Du nur ab und zu Daten übers Netz schickst, klappt es vielleicht und Du siehst den vollen Durchsatz? Wenn regelmäßig kleine Pakete übers Netz geschickt werden (Loop Detection), ist vielleicht eines davon betroffen? Der Switch merkt es und schaltet (temporär) in einen anderen Übertragungsmodus? Oder es gibt Probleme mit den Mac Adressen - und die Switches haben zeitweise falsche Weiterleitungs-Tabellen?

Ich würde das weiter untersuchen. Beispielsweise könnte man Loop Detection ausgeschaltet lassen, aber zwei Rechner Pings durch das Netz hin- und herschicken lassen. Das wären dann auch 2 Pakete pro Sekunde. Treten die Leistungseinbrüche dann auch auf?

Es gibt auch Tools, die Latenzen und/oder Durchsatz jede Minuten messen und das schön als Diagramm über ein oder zwei Tage darstellen. Wenn man solche Diagramme mit Loop Detection, ohne Loop Detection und mit Pings zwischen zwei Rechnern erstellt, kann man i.d.R. eine Menge erkennen. Insbesondere sieht man, wann und wie häufig die Probleme auftreten.

Gibt es Log-Einträge auf den Switches? Oder zeigen die dortigen TX oder RX error counter etwas an?

Ich kann Dir von hier aus nicht wirklich helfen. Aber ich kann versuchen, Dich in die richtige Richtung zu schubsen: testen und monitoren, bis Du den tatsächlichen Grund gefunden hast. Scheinlösungen "ich schalte Loop Detection aus und dann geht es" fallen einem früher oder später auf die Füße. Und zwar insbesondere dann, wenn man es überhaupt nicht gebrauchen kann.

 

[74181]

Mach mal Folgendes: erstelle eine 10 GB große Datei unter Windows und miss die Zeit, die es dauert, um sie mit Windows Shell und "copy" auf Dein NAS zu kopieren. Miss auch die Zeit in der anderen Richtung.

Dann mache das gleiche unter Linux ("cp"). Bei der Zeitmessung solltest Du sicherstellen, dass die gesamte Zeit gemessen wird - und nicht nur die Zeit, bis die Daten in einen Cache kopiert sind. Es sollte also auch ein "sync" dabei sein.

FreeFileSync ist vermutlich kein guter Test, weil möglicherweise auch andere Dinge wie Latenzen oder Caches eine Rolle spielen.

Hast Du auch NFS aktiv? Dann miss auch unter NFS. Falls Du weißt, wie man mit scp ohne langsame Verschlüsselung kopiert, versuche auch das. Falls FTP aktiv ist, probiere auch das.

 

[74181]

Hier ein paar Testergebnisse von mir.

Mein Setup: ein kleiner, unmanaged 2.5 GBit/s Ethernet Switch mit 5 Ports (Trendnet TEG-S350). An dem Switch hängen u.a. ein Dateiserver (192.168.2.2) und ein PC (192.168.2.3) über Cat. 7 Ethernet-Kabel.

Auf dem PC (192.168.2.3):

1) Testdatei erstellen (Zufallszahlen, damit nicht komprimiert werden kann)

$ cd /tmp
$ dd if=/dev/random of=testdatei bs=1M count=10000

10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9,8 GiB) copied, 20,7418 s, 506 MB/s

$ ls -la
...
-rw-rw-r--  1  root  root  10485760000  Feb 12 19:59  testdatei
...

2) Test mit NFS Server

# mount -t nfs4 -o rw,nosuid 192.168.2.2:/export/scratch /mnt

$ sync; time ( cp testdatei /mnt; sync )

real    0m37,128s
user    0m0,005s
sys     0m3,722s
 
umount /mnt

Das sind 269 MB/s. Ganz ordentlich für eine 2.5 GBit/s Verbindung

3) Test mit Samba Server

# mount -t cifs -o user=XXXXX -o rw //192.168.2.2/scratch /mnt

$ sync; time ( cp testdatei /mnt; sync )

real    0m36.866s
user    0m0.001s
sys     0m3.537s

umount /mnt

Das sind 271 MB/s - also genauso schnell wie NFS.

 

[sch4kal]

Deshalb gibt es Loop Detection Protokolle wie STP oder auch RLDP. Sie versuchen, solche Loops zu entdecken. Wenn sie eine Loop feststellen, werden die entsprechenden Ports gesperrt.

Vorsicht, Loop Detection hat in diesem Fall nichts mit Spanningtree zu tun. Das ist eine proprietäre Implementierung des Herstellers und rein lokal auf den Switch begrenzt.

 

[74181]

Wenn ich es richtig verstehe, geht es hier darum herauszufinden, ob es Netzprobleme gibt - und warum Du unter Linux einen geringeren Durchsatz misst.

Bei Geschwindigkeitstests ist es wichtig, alle Störfaktoren auszuschalten. Sonst misst man nicht das, was man messen will.

Deswegen empfehle ich Basis-Kopier-Befehle wie copy und cp, die einfach nur kopieren. Andere Programme machen möglicherweise viel mehr - sie komprimieren, cachen, verbrauchen CPU-Zeit für Animationen, telefonieren noch mal nach Hause, um herauszufinden, ob sie überhaupt kopieren dürfen, diskutieren mit dem Virenscanner...

Virenscanner können eine Rolle spielen. Vorher ausschalten.

Festplattenverschlüsselung kann eine Rolle spielen. Man kann es daran erkennen, dass die CPU Last recht hoch ist. Deshalb auf dem Start- und Zielrechner immer top oder den Systemmonitor mitlaufen lassen. Den Test zum Messen des Netzwerk-Durchsatzes sollte man, wenn der Durchsatz zu niedrig ist, mit unverschlüsselten Volumes wiederholen. Bei meinem obigen Test habe ich /tmp verwendet. /tmp ist eine Ramdisk. Es gibt keine Verschlüsselung und keine Disk I/O Latenzen, die stören könnten.

Wichtig ist, dass man für den Durchsatz-Test zunächst eine (!) sehr große (!) Datei wählt, deren Übertragung mindestens 20 Sekunden dauert. Das minimiert den Einfluss vieler Störungen. Iin meinem Test war das eine Datei mit 10GB.

 

[74181]

Na, dann probier doch erst einmal zu lesen. Packe eine sehr große Datei 'testdatei' auf Dein NAS. Und dann:

sync; time ( cp /mnt/testdatei /dev/null; sync )

Durch Angabe von /dev/null kopierst Du direkt in den Mülleimer. Damit vermeidest Du Verzögerungen durch Festplatten-Verschlüsselung auf dem Arbeitsrechner.

 

[74181]

10 GB in 41 Sekunden... Das sind 10.000 MB / 41 Sekunden = 243 MB/s. Das ist doch ein ordentlicher Wert für ein 2.5 GBit/s Netzwerk! Viel mehr, als was Du oben geschrieben hast!

Man kann das vielleicht noch weiter optimieren... Aber bitte miss erst einmal, welche Datenrate Du mit dem cp-Befehl beim Schreiben vom Arbeitsrechner auf Dein NAS erhältst.

 

[74181]

Vielleicht kannst Du auf Deinem NAS ein Share erstellen und freigeben, das nicht verschlüsselt ist? Damit solltest Du die volle Geschwindigkeit hinbekommen. Im Vergleich zwischen unverschlüsseltem und verschlüsseltem Share kannst Du messen, wie viel Performance die Verschlüsselung kostet.

Auf meinem Fileserver gibt es ein paar verschlüsselte Volumes für meine Daten. Es gibt aber auch das Scratch-Volume, das nicht verschlüsselt ist. Ich verwende es für Datenaustausch - oder um mal schnell einen Film oder ein großes VM Image dorthin kopieren zu können. Dafür brauche ich keine Verschlüsselung. Ich will maximale Geschwindigkeit. Ich kann das Scratch-Volume natürlich auch gut für Durchsatz-Tests nehmen, wie in den Beispielen oben.

Wenn ich dies nun richtig interpretiere, gibts prinzipiell keine Probleme mit dem Netzwerk.

Das würde ich auch so interpretieren.

Fragt sich was denn die Kopiervorgänge so langsam macht mit FreeFileSync unter Linux und auch das Kopieren in Nemo einiges langsamer ist als das Kopieren per Win-Dateiexplorer.

Es gibt zwei unterschiedliche Arten von Kommunikation über das Netz.

1. Bei der ersten sendet die eine Seite Daten mit voller Geschwinfdigkeit an die andere Seite. Damit erreicht man relativ einfach den vollen Durchsatz.
   
   
2. Bei der zweiten unterhalten sich die beiden Rechner. Der erste Rechner sendet eine Anfrage an den anderen - und wartet auf die Antwort. Danach sendet er wieder eine Anfrage und wartet wieder auf die Antwort. Usw. Bei dieser Art der Kommunikation ist die Bandbreite nicht so wichtig. Es kommt auf die Reaktionsgeschwindigkeit des Kommunikationspartners an.

Wenn man mit "cp" eine große Datei überträgt, wird hauptsächlich die erste Variante verwendet. Wenn man mit einem Tool (FreeFileSync, Nemo) viele kleine Dateien zusammensuchen lässt und diese überträgt, wird hauptsächlich die zweite Variante verwendet. Dann braucht man sich nicht zu wundern, wenn der Datendurchsatz viel geringer ist als die Bandbreite. Weil das Tool einen großen Teil der Zeit keine Daten überträgt, sondern auf Antworten der anderen Seite wartet.

 

[74181]

Meiner Erfahrung nach ist Linux eher etwas schneller als Windows. Wenn Deine Tests unter Linux langsamer sind, ist entweder etwas noch nicht richtig konfiguriert bei Dir - oder die Tools, die Du verwendest, arbeiten für Deinen Testcase suboptimial. Ich persönlich würde weiter testen, bis ich herausgefunden hätte, was es ist.

Wie die Volumes gemountet sind, kannst Durch Eingabe des Befehl "mount" sehen. Schau, wie die Ausgabe ist, wenn Du von Hand mountest und wenn Du mit gigolo mountest.

Was passiert, wenn Du mit gigolo mountest und die 10GB Datei von Hand mit den obigen Befehlen überträgst? Ist es langsamer? Oder gleich schnell?

 

[74181]

Bitte poste die Ausgabe vom

mount | grep "192.168.1.22"

Der richtige copy-Befehl ist vermutlich:

sync; time ( sudo cp testdatei /run/user/1000/gvfs/smb-share; sync )

oder vielleicht auch:

sync; time ( sudo cp testdatei /run/user/1000/gvfs/smb-share/datashare; sync )

Gehe mit Deinem Filemanager (oder auf der Shell) nach "/run/user/1000/gvfs/smb-share/" und hangle Dich von dort weiter, bis du das Verzeichnis auf dem NFS-Share siehst, in das Du kopieren willst. Welches Verzeichnis ist das? Dann gehst Du auf der Shell wieder in das /tmp-Verzeichnis und führst den cp-Befehl aus - mit dem Verzeichenis als Zielverzeichnis, das du herausgefunden hast.

Anmerkung: unter Windows werden Netzwerklaufwerke häufig mit eigenem Laufwerks-Buchstaben eingehängt. Unter Linux werden sie an einen beliebigen Otr im bestehenden Verzeichnisbaum eingehängt. Also z.B. nach /mnt oder auch nach /run/user/1000/gvfs/smb-share. Wenn man auf das Netzwerklaufwerk kopieren will, kopiert man einfach an die entsprechende Stelle im Verzeichnisbaum. Es gibt keine Laufwerksbuchstaben.

 

[74181]

Ich schreibe alle Volumes, die ich gemounted haben möchte, in die Datei /etc/fstab. Dann werden sie automatisch beim Systemstart gemountet.

Ein kleines Problem sind Passwörter. Meine NFS Shares haben keine Passwörter und können deshalb automatisch gemountet werden.

Bei Samba Shares werden i.a. Usernamen und Passwörter benötigt. Diese kann man entweder in die fstab schreiben (sehr unschön) oder in eine credentials-Datei.

Außerdem muss man überlegen, was passieren soll, wenn der Dateiserver beim Systemstart nicht erreichbar sein sollte. Soll der Server dann warten? Oder soll er weiterbooten und die Shares zu einem späteren Zeitpunkt mounten? Und was soll passieren, wenn das Netzwerk oder der Dateiserver im laufenden Betrieb ausfallen sollte? Je nachdem, was man will, gibt es unterschiedliche mount-Optionen (auto, noauto, usw.).

Du kannst bei Google suchen nach "Linux cifs fstab mount" oder hier schauen: https://wiki.ubuntuusers.de/mount.cifs

 

[74181]

Ich kannte Gigolo noch nicht, habe es mir aber gerade angeschaut. Soweit ich sehe, ist es ein System für Anwender, die ab und zu mal Daten mit Dateiservern austauschen wollen. Also z.B. ein Student an einer Uni, der gelegentlich Dateien auf verschiedene Uni-Server übertragen oder von dort herunterladen möchte. Für diesen Anwendungsfall ist es vermutlich gut geeignet. Auf volle Geschwindigkeit kommt es nicht an.

Das ist etwas anderes, als wenn man Netzwerk-Volumes in einem LAN dauerhaft und stabil auf seinen Rechner mounten möchte. So als wäre es eigene lokale Festplatte, nur eben über das Netz.

Also, man muss man schauen, welchen Anwendungsfall man hat. Ein paar Kröten muss man immer schlucken. Bei Gigolo braucht man keine root-Rechte und man ist sehr flexibel. Dafür bekommt man aber offenbar nicht die volle Geschwindigkeit und es wird möglicherweise eine ältere Version von SMB/CIFS verwendet. Bei den klassischen UNIX Netzwerk-Mounts über NFS oder CIFS und /etc/fstab bekommt man ein schnelles Netzlaufwerk, das sich verhält wie eine lokale Festplatte. Es kann aber Probleme geben, wenn das Netzlaufwerk mal nicht verfügbar sein sollte (Netzprobleme, NAS ist kaputt). Dann kann man seinen Arbeitsrechner vielleicht gar nicht mehr starten. Je nachdem, welche Mount-Parameter man gewählt hat. Es kostet Zeit, bis man alles so eingerichtet hat, wie man es braucht.

Du kannst auch experimentieren und einen etwaigen Wechsel schrittweise machen. Erstelle auf Deinem NAS ein neues Share "scratch", das nicht verschlüsselt ist - und mounte das über /etc/fstab, am besten mit Option "noauto". Dann kannst Du schauen, ob es etwas für Dich ist. Du kannst auch Gigolo und klassiche UNIX-Mounts parallel verwenden.