Schreiben auf QNAP-NAS mit Windows verursacht defekte Daten.

    Dann hast du die NAS mit Paketen überrannt und vermutlich auch deinen Switch.


    10Gbit macht ohne Jumbo Frames nicht viel Sinn.


    Windows übernimmt das so, jedenfalls meine Intel und Realtek Chips. Beim Switch kann das anders aussehen.


    Ist aber auch kein Wunder denn bei 1500er MTU sind 10G 800-900k pps, da fliegt die alles aus der Mütze.

    Bei 9k MTU sieht es da mit 150k pps schon wieder anders aus und das lässt wich noch handhaben.


    Was kann denn dein Switch laut Datenblatt an pps?

    Meine mit 48Gbit und 4SFP+ ist mit 176Gbit Switching und 131 Mil pps angegeben.

    Zitat von no1dea

    Aber wie finde ich heraus was die richtige MTU für ein 10GBE-NAS-Netzwerk ist?

    Falsche Frage. Die richtige MTU bezieht sich immer auf eine Netzkwerkkarte bzw. deren Kombination mit einem zugehörigen Treiber. Was richtig ist je Netzwerkkarte bzw. deren Kombination mit Treiber, kann auch nicht so ohne weiteres beantwortet werden. Wenn man Glück hat, findet man in der Doku bzw. Spezifikation der Netzwerkkarte die Angabe der maximal unterstützten Paketgröße (MTU). Vielleicht verwendet die Spec den Begriff Jumbopaket an dieser Stelle. Vielleicht finden sich zur jeweiligen Karte auch Berichte vom Hersteller oder von Testern, die diese Angaben liefern. Wenn man die jeweils maximal unterstützte MTU je Netzwerkkarte konfiguriert, kann es zu Segmentierung von Paketen bei Verbindungen kommen, insbesondere, wenn die MTU nicht zwischen den Kommunikationspartnern ausgehandelt wird. Bei TCP sollte diese ausgehandelt werden. Bei UDP bin ich mir nicht sicher, und bei ICMP gehe ich nicht davon aus. Ping nutzt ICMP.

    Zitat von no1dea

    wenn ich 1500 Byte versuche, das NAS anzupingen, kommt bereits eine Zeitüberschreitung und bei 9000 ein gesetzter DF-Flag. ( nur 1490 Byte geht noch).

    Die Größenangaben beziehen sich auf die eingestellten MTU oder auf die angegebene Ping-Paketgröße?


    Bei IPv4 hatte ich in Erinnerung, dass standardmäßig die Paketlänge für ping 56 Byte im Versand und 60 Byte im Empfang seien, also weit weg von der MTU. Bei Wahl entsprechender Optionen können die Paketlängen auch größer werden. Und falls Du die Ping-Paketgröße angegeben hast, dann musst Du ausreichend unterhalb der MTU liegen, weil diese Paketangaben auf unterschiedlichen Protokollschichten liegen, und entsprechend unterschiedliche Paketgrenzen gelten.


    Wenn man die Übersicht über alle Netzwerkkarten und -schnittstellen im lokalen Netzwerk hat, kann man auch die kleinste MTU aller Netzwerkkarten komfigurieren, wenn man Paketsegmentierung im lokalen Netzwerk begrenzen will. Als ich vor Jahrzehnten mit MTU herum experimentiert hatte, habe ich auch schon eine MTU um die 1024 konfiguriert, damals noch ohne NAS.


    Und ping ist auf keiner Kommunikationsseite weder in der Firewall noch in den Netzwerkeinstellungen blockiert? Traceroute bzw. tracert wäre noch eine Alternative zu ping. Wenn der Switch aber ein L2-Switch ist, dürfte dies auch nicht weiterhelfen.


    Jedenfalls gehe ich davon aus, dass die Prüfsummenfehler nichts mit den Timeouts bei ping zu tun haben.

    Zitat von chef1

    Und wenn MTU auf Switchport auf 9198 steht, aber bei Endgeräte auf 9000, dann dürfte für die Verbindung auch nur 9000 verwendet werden.

    Stimmt leider so nicht!

    In der Praxis schon oft genug erlebt, das bei manchen Geräte/Betriebssystemen eben nicht 9000=9000 sind.

    Wie mussten da auch schon empirisch ermitteln, das bei einem Switch die Jumbo Frames mit 9000 angegeben waren, bei Windows musste aber 8768 (oder ein ähnlich krummer Wert) eingegeben werden.

    Anscheinend rechnen die Einen mit einer 2 Basis, die anderen mit einer 10er Basis, obwohl das dann eigentlich 9000 und 9216 sein müssten.

    Hat uns mehrere Stunden debugging mit Wireshark gekostet.

    Problem war, das im Switch nur 9000 als Jumbo Frame möglich war, abweichende Werte gab es nicht.


    Gruss

    Einmal editiert, zuletzt von FSC830 ()

    Anmerkung!


    Die gesamte Kette muss Jumbo sauber unterstützen, also Client, Switch, Server/NAS.


    Ist das im Client und im Server eingestellt, aber der Switch kann nur 1500er MTU, gibts Packetsalat.


    Daher muss man wenn alle Datenblätter auf den Kopf stellen und dann den gemeinsamen Nenner finden.

    Wenn ein Switch jedoch 16k kann, ist das kein Problem, das erlaubte max Frame darf nur nicht kleiner sein als die max MTU am Client.


    Bei meinem sieht das so aus:

    Code
    Jumbos Global Values


Configured :  Max Frame Size :  9216      IP-MTU :  9198
In Use     :  Max Frame Size :  9216      IP-MTU :  9198

    Sorry für die späte Rückmeldung. Ich bin nicht wirklich vom Fach und hatte keine Zeit mich einzulesen.
    Ich komm nicht drauf, wie ich jetzt den richtigen MTU einstelle (Momentan: NAS 9000, Switch 9198, PC 9000). Wenn ich mit MTU 9000 Pinge gehen die Pakete immer noch verloren.(DF-Flag ist gesetzt)
    Es kommen zwar ja jetzt nun seltener Prüfsummenfehler, aber irgend etwas stimmt da immer noch nicht. Manchmal kommt es auch noch vor, dass das große Datenschreiben nicht funktioniert. Ala kopierfenster lädt und lädt und lädt ohne Fortschritt und nach 1-2 Minuten Zugriffsfehler. Dann muss ich das Netzwerkkabel am PC raus und wieder reinstecken und dann geht es wieder.
    Ich frage mich generell, warum ich anscheinend der einzige mit solchen Problemen bin? Verwenden so wenig Leute 10GBE? Oder suche ich falsch? Ich habe ja nun auch schon jede Komponente einmal durchgetauscht.
    Überhaupt: warum ist so etwas offensichtlich essentielles wie MTU umstellen in Windows so umständlich? Commandline öffnen, Ethernet Adapter identifizieren, irgend einen hoffentlich richtigen Wert zwischen 1000 und 9000 eingeben, checken ob es den übernommen hat... Und da steht da dann auch der Wert, aber erst nach einem Neustart funktioniert es erst. Echt horror

    Vielleicht ist es ja auch ein Treiberproblem...soweit ich das mit den MTU Problemen im Kopf habe geht das dann entweder gar nicht, aber jedenfalls führt das auf der gleichen Route normalerweise nicht zu teilweise kaputten Paketen. Und die müsste eigentlich schon der Netzwerkstack wegen fehlerhafter Prüfsummen aussortieren. Wenn die Dateien erst auf dem Datenträger kaputt sind liegt es womöglich an etwas ganz anderem. Ich würde mal die Windows Ereignisanzeige nach Fehlern und Warnungen filtern. Womöglich hast Du ein ganz anderes Problem.


    Wenn es der Treiber ist macht der irgendwas im Speicher nach einer Anzahl von Zugriffen kaputt und das landet dann auf der Platte. Da hat das NAS oder der Router vielleicht nix mit zu tun. Denn kaputte Ethernetframes müssten eben anhand der Prüfsumme bemerkt werden.

    Einmal editiert, zuletzt von nasferatu ()

    Zitat von no1dea

    Ich komm nicht drauf, wie ich jetzt den richtigen MTU einstelle (Momentan: NAS 9000, Switch 9198, PC 9000). Wenn ich mit MTU 9000 Pinge gehen die Pakete immer noch verloren.(DF-Flag ist gesetzt)

    MTU ist auf Ethernet-Ebene. Im Fall von ping stehen Dir somit maximal 8972 Bytes Nutzlast zur Verfügung. Ein ping mit 9000 Bytes Länge müsste daher in zwei Ethernetpakete gesplittet werden. Versuche daher mal Deine pings mit Nutzgrößen zwischen 8950 und 8972 Bytes, damit es ohne Segmentierung übertragen werden kann.

    Zitat von no1dea

    Ich frage mich generell, warum ich anscheinend der einzige mit solchen Problemen bin? Verwenden so wenig Leute 10GBE?

    Einerseits bist Du nicht der Einzige. Andererseits sind 10 GbE Infrastrukturen auch noch nicht Standard. Kommen am ehesten bei Servern vor. Und die Implementierung von MTU-Aushandlung funktioniert nicht immer ordentlich bei allen beteiligten Komponenten.

    Zitat von no1dea

    Überhaupt: warum ist so etwas offensichtlich essentielles wie MTU umstellen in Windows so umständlich? Commandline öffnen, Ethernet Adapter identifizieren, irgend einen hoffentlich richtigen Wert zwischen 1000 und 9000 eingeben, checken ob es den übernommen hat... Und da steht da dann auch der Wert, aber erst nach einem Neustart funktioniert es erst. Echt horror

    Das müsste auch über die GUI funktionieren. Ich hätte die Erwartung, dass es auch ohne Neustart funktionieren solle. Wenn der veränderte Wert nicht sofort übernommen wird, sollte auch ein deaktivieren und reaktivieren des Gerätes helfen. Dann würde ich aber sicherheitshalber erneut nachsehen, ob nach Reaktivierung der veränderte Wert weiterhin eingetragen ist.

    Zitat von no1dea

    Überhaupt: warum ist so etwas offensichtlich essentielles wie MTU umstellen in Windows so umständlich?

    Das geht auch über die GUI, im NIC Treiber, dabei wird ein Link Reset erzeugt und der Adapter neu inizialisiert, also nix Neustart.


    Aber wie immer, damit am PC alles sauber funktioniert benötigt man einen gescheiten Treiber.

    Oh, tatsächlich. In den Treiber-Einstellungen steht 9014 Bytes bei Jumbo Packet, danke!

    Sorry, ich muss das Thema nochmal aufgreifen. In letzter Zeit sind wieder vermehrt fehlerhafte Dateien nach Kopiervorgängen aufgefallen. Sowohl bei IMac's mit interner 10-Gigabit- Karte, als auch bei Thunderbolt Adaptern oder PCs mit Qnap PCI-Karten. Die Daten sind wichtig. Jedes zerstörte Video kostet viel Arbeitszeit.

    Die Qnap ist nach wie vor das QNAP TVS-872xt und das Switch das Netgear prosafe xs712tv2. Ich habe beide Geräte ohne Besserung getauscht und

    "Packet forwarding rate (64 byte packet size): 178,5 mpps" müsste doch bedeuten, dass die MTU nicht das Problem sein können. Nach dem Hochstellen, sind es vermutlich einfach weniger Pakete die beschädigt ankommen.

    Ich kenne mich mit Netzwerken leider nicht so gut aus, aber es muss doch einen Workflow geben, um herauszufinden woran das liegt. Einen Stresstest mit überwachter Leitung oder so. Wo erfahre ich wie das möglichst unkompliziert geht? (Dieses riesige Daten kopieren und auf Prüfsummen checken, kostet leider zu viel Zeit)

    Mir fällt übrigens auch auf, dass das Qnap Protokoll immer noch voll von gedropten Paketen ist. Ist das normal?


    Code
    Link encap:Ethernet  HWaddr 24:5E:BE:4D:AE:BD  
          inet addr:192.168.178.134  Bcast:192.168.178.255  Mask:255.255.255.0
          inet6 addr: fe80::265e:beff:fe4d:aebd/64 Scope:Link
          inet6 addr: 2a02:810d:8cbf:e044:265e:beff:fe4d:aebd/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
          RX packets:266287019 errors:0 dropped:282476 overruns:0 frame:0
          TX packets:302811986 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:180393816026 (168.0 GiB)  TX bytes:419893116432 (391.0 GiB)

    2 Mal editiert, zuletzt von no1dea ()

    Hast du einen weiteren Client den du am Kabel wo sonst das NAS steckt testen kannst?


    Dann würde ich das machen, damit schließt du dann die Strecke und den Switch als Fehlerquelle aus, wenn du hier Dateien ohne CRC Fehler hin und her schieben kannst.


    Dann bleibt nur noch das NAS als Fehlerquelle über.

    In dem Fall kann es eine defekte LAN Karte im NAS sein, defekte Hauptplatine, CPU oder RAM.


    Ich habe es ja schon an verschiedene Switches(selbe Modell) und Steckplätze angesteckt, ohne Erfolg. Und direkt zwischen Computer kopieren ging bis jetzt auch immer ohne Probleme.
    Und das komplette NAS habe ich ja auch schon von QNAP auswechseln lassen. Es ist doch unwahrscheinlich, dass die LAN Karte bei beiden NAS defekt ist. Das würde nicht gerade für die Qualität von QNAP sprechen.

    Wie ist das generell? Sind gedroppte Pakete normal?
    Als ich die eigentlich baugleiche PCI-Karte verbaut habe ist es (vorerst?) nicht zu Fehlern gekommen. Da wurden von 601.682.910 Paketen nur 1.980 gedroppt. Bei der Internen bei 266.287.019 aber 282.476. Auch wenn es blöd ist, dass ich das 10GBE NAS mit einer 10GBE-Karte aufrüsten muss, damit es funktioniert, würde ich einfach die PCI-Karte reinstecken, wenn ich dann endlich sicher sein kann, dass wirklich keine Prüfsummenfehler mehr kommen.


    Gibt es denn kein Programm, dass automatisch immer wieder verschiedene Dateien schreibt und checkt, ob die Prüfsummen gleich sind, das ich einfach eine Nacht durchlaufen lassen kann, um sicher zu gehen?

    Ich würde das Teil als defekt abstempeln und entsorgen, bzw. nach 3 Versuchen wandeln.


    Bei TCP/IP kann es defekte Pakete bei der Übertragung geben, dann wird erneut gesendet, dafür ist ein verbindungsorientiertes TCP gebaut worden.


    Defekte Dateien im Storage ist aber eine andere Sache und wenn das Storage die Funktion sauber und Fehlerfrei Daten zu speichern nicht erfüllt ist es Schrott.



    Ist da eine Intel 10G Karten drin?

    Die hat in der ersten Revision einen Hardware Bug.

    Habe auch eine TVS-872XT und in zwei PCs und einer TVS-673 ebenfalls QNAP QXG-10G1T verbaut. Funktioniert alles einwandfrei. Das sind keine Intel Chips, sondern Marvell.

    Achso, ich benutze keine Jumbo Frames.

    Ich weiß jetzt nicht welchen Speicher du im PC verbaut hast, aber 400 MB/s kommt mir bei voller Bestückung der NAS schon recht langsam vor. Das geht mindestens 1,5 mal so schnell.


    PS: Hier gibts ein Tool um die Firmware der QXG-10G1T zu updaten.

    Die Firmware vom Switch hatten wir schon angesprochen?

    Welche ist hier aktiv, aktuell ist Version 7.0.0.20, passe beim Update auf, PW länger als 15 Zeichen fliegt dir um die Ohren.

    Zitat von Helljumper

    Habe auch eine TVS-872XT

    Und hast du schon mal beim Helpdesk ein Protokoll heruntergeladen? Sind bei dir denn 0 "Dropped" Pakete bei RX aufgelistet?
    Und verwendest du ein Switch dazwischen?
    Danke für den Link. Die Firmware vom Onboard-QXG-10G1T im NAS werde ich damit aber nicht Updaten können, oder?

    Zitat von Crazyhorse

    Ich würde das Teil als defekt abstempeln und entsorgen, bzw. nach 3 Versuchen wandeln.

    Ich weiß, das nervt ungemein. Ich will aber nur ungern ein 2000€ NAS entsorgen oder das Teil 3 Mal auf meine Kosten nach Holland schicken.

    Die Firmware vom Switch ist die aktuelle 7.0.0.20

    2 Mal editiert, zuletzt von no1dea ()

    Wie ich in deiner PM gelesen habe benutzt du SSDs als read write/ cache? Stell den mal bitte auf read only!Hatte damit auch mal Probleme das der im write Modus die Verbindung verlangsamt hat! Eventuell hören damit deine Probleme schon auf.

    Zitat von Helljumper

    ich benutze keine Jumbo Frames.


    Ich habe Jumbo Frames auch überall abgestellt da immer wieder Ärger aufgetreten ist.


    Würde aber auch zuerst den SSD Cache testweise komplett abschalten und dann ausprobieren ob der Fehler noch auftritt. Wenn er weg ist, nur den Lese Cache aktivieren und nochmal ausprobieren. Im amerikanischen Qnap Forum schreibt auch einer mit dem 872XT über lost data und dem Cache.

    Er benutzt: Cache is 2x M2 NVME Samsung 970 1TB Pro configured Raid 1 in read/write mode - giving 1TB of cache.

    Seltsam. Am Anfang des Threads meinte jeder ich soll Jumbo Frames einstellen und jetzt soll ich sie ausstellen. Na gut. Dann sind es immerhin mehr Pakete, wodurch es häufiger passiert, falls es passiert.
    Da es anscheinend sowieso keinen Performance-Vorteil bringt, werde ich den Cache einfach mal auf Read stellen. Habe ihn aber auch erst seit ein paar Wochen installiert und vorher gab es die gleichen Probleme, wenn man das Onboard LAN verwendet hat.

    Nicht falsch verstehen Jumbo Frames sind keine schlechte Sache machen aber öfters Probleme. Da bei dir Probleme auftauchen ....... wenn alles einwandfrei wieder läuft kannst du jumbo frames testen ob es dir was bringt.


    Heißt also du hattest die Fehler schon bevor überhaupt ein SSD Cache installiert war ? Oder nur den write Cache ?

    Zum testen würde ich diesen trotzdem abschalten umso wenig Fehlerquellen wie möglich zu haben.


    Falls ja teste bitte mal einen Rechner direkt am NAS mit einem CAT 7 Kabel und berichte. Schlechte Kabel verursachen auch Dropped Pakete. Normalerweise werden defekte Pakete abgefangen so das die Dateien keine Fehler aufweisen sollten. Deine Log zeigt aber keinen Error an.

    Bitte nimm ein fertiges Kabel und keines das du selbst herstellst zum testen. Wenn der Fehler dann auftritt liegt es definitiv am NAS und alles andere kann ausgeschlossen werden.


    Wenn ich das Teil testen müsste beim Kunden würde ich den ganzen PCIe Kram komplett ausbauen und beim Grundgerät anfangen zu testen ob der Fehler auftritt. Falls Arbeitsspeicher geändert wurde, würde ich sogar diesen wieder auf original ändern zum testen. Falls der Fehler dann weg ist nach und nach die Komponenten einbauen bis der Fehler wieder auftritt. Tritt der Fehler immer noch auf, würde ich sogar mit einem einzigen neuen Laufwerk und mit fast Grundeinstellungen die 10GBe testen, danach an Qnap wenden, denn dann würde meiner Meinung nach ein Hardware Fehler vorliegen.