Probleme beim kopieren von großen Dateien / QNAP TS-879 und Windows 10 / Fehler 0x8007003B

    Welches Modell ist es denn bei dir?

    Firmware aktuell?

    HP hat ja einen mega Support, liefern fast ewig Firmware nach.

    Am einfachsten kannst du mit der J Nummer nach der Firmware suchen.

    Ich denke nicht das es am HP Switch liegt. Aus diesem Grund habe ich nachgefragt ob sich das Problem gelöst hat seit dem Layer 3 Switche verwendet wurden, ich bezweifle es.

    Ich habe hier (zu Hause) einen 1950-24G an dem mein TS-870U-RP mit 10G hängt und am Remote Stützpunkt ein 1810-24G V2 an dem mein TS-EC879U-RP mit einem Trunk von 2x1G hängt.

    Wenn ich Daten von einem PC von zu Hause in Richtung Remote Stützpunkt kopieren möchte bricht der Kopiervorgang meist schon nach 4-6MB ab und es kommt dieser Netzwerkfehler-Fehler. Kopiere ich Daten vom NAS auf der Remote Stüztpunkt Seite auf das NAS zu Hause funktioniert es. Starte ich den Kopiervorgang vom Home-NAS von einem PC auf der Remote Stützpunktseite funktioniert es meistens auch. Versuche ich von einem PC auf der Remote Stützpunktseite Daten vom dortigen NAS auf das NAS zu Hause zu kopieren bekomme ich den selben Netzwerkfehler-Fehler von nach ein paar MB.

    Firmware auf den HP Switchen ist der letzte, aktuelle Stand.

    Genauso auf den NAS'sen(bären) (4.3.6.1831)

    Ok, das ist eine sehr fehlerträchtige Konstellation. Könntest Du den Trunk aufgeben? Alternativ die Dateien in kleinere Blöcke zerlegen und dann kopieren.

    Wenn Dir der Installateuer Deines Vertrauens mit einem entsprechenden Meßgerät die CAT6-Tauglichkeit deiner Verkabelung zusichert, kannst Du versuchen dem Problem mit Jumbo-Frames zu Leibe zu rücken. Entweder wird es besser oder viel schlimmer. Bei Letzterem liegt es dann vermutlich daran, dass Dein QNAP mit dem Schreiben nicht hinterherkommt und durch die Lastenverteilung im Trunk die Schreibpuffer überlaufen. Dann wirst Du wohl eine SSD spendieren müssen.

    Wie sind denn auf den NAS Systemen die SMB Einstellungen?

    Mit dem im Titel genanntem Fehlercode wurde hier mal ein Zusammengang gemeldet.

    Wenn nur Win 10 oder neuer eingesetzt wird, reicht SMB 3 als min und auch als MAX.


    Wie ist der Remote Standort angebunden?

    WAN Stecke dazwischen ?

    Stimmt die MSS auf den Endpunkten?


    Und ein activ LACP funktioniert jedenfalls auf HP Switch Seite Problemlos.

    Höchstens das Loadbalancing könnte ein Problem geben, dann gibts Asyncrones Routing.

    Wenn hier keine QuFirewall aktiv ist, spielt das aber keine Rolle.

    Danke für Eure Antworten!

    Ich war ein paar Tage offline. Habe mir jetzt noch ein paar andere Switche bestellt um das Problem einzukreisen bzw. um zu sehen ob es überhaupt an den Switchen liegt.

    Hier die antworten auf Eure Fragen:

    Jumboframes sind auf den Switchen aktuell aktiv, habe ich aber schon so und so probiert, keine Änderung oder Verbesserung bzw. Verschlechterung festellbar.

    Auf beiden QNAP's sind QM2 384er PCIe Steckkarten verbaut mit jeweils 2x1TB Samsung 970 EVO Plus SSD's im Qtier.

    SMB Einstellung auf beiden identisch, min. 2.0 und max. 3.0

    Leider auch noch ältere Systeme im Einsatz für interne Dienste

    Remote Standort hat eine vDSL 100 bei Vodafone (FritzBox 7590)

    Lokaler Standort Kabel Internet 1000 bei Vodafone, ehemals Unitymedia (FritzBox 6591)

    habe keine Möglichkeit gefunden die MSS zu ändern

    QuFirewall ist auf den beiden NAS nicht aktiv.

    Vodafon hat aktuell, hier zumindest, mit dem OFDMA im Upstream massivste Probleme.

    Wenn ich hier eine Sicherung fahre geht es noch, aber wenn meine Eltern hier her sichern, dann geht die Antwortzeit der Internetleitung auf weit über 100ms hoch.

    Da hilft dann nur noch der Limiter das nicht total absaufen zu lassen.


    Kannst du ganz einfach sehen, wenn du einen Ping laufen lässt von der einen LAN Seite über den Tunnel zur anderen durch den Site to Site IPsec Tunnel.

    Aber auch ohne Tunnel wird das Problem auftreten, dann musst du aber Ping auf WAN zulassen, mache ich hier auch aber nur für jeweilige DynDNS Adresse der Gegenstelle.


    Schalte Jumbos mal auf allen Clients und dem NAS aus, am Switch kannst das sogar aktiv lassen das stört nicht, weil er ja nur Pakte weiterleitet und selber keine erzeugt. Zumindest nicht, wenn du Daten von einem Client zum anderen schiebst.


    Wenn deine Switche spinnen, weil du z.B. mal mit OpenVAS nen Scan hast laufen lassen, dann hilft es die mal kurz vom Strom zu nehmen und sauber zu booten. Nen Power Cycle wirkt oft Wunder, wenn sich ein Schaltkreis total verrannt hat.


    Firmware auf den neusten Stand bring bei den Dinger oft was, weil hier nicht selten FPGAs verbaut sind und dann werden die Schaltungen optimiert und arbeiten schneller/zuverlässiger.

    OFDMA?

    Ich verwende für diese Verbindung kein WLAN.

    Das mit den Pingzeiten teste ich mal aus wenn ich Daten zwischen den beiden Standorten austausche.

    Jumbos sind auf den Switchen freigeschaltet und aktiv, auf den Client und auf den NAS'sen aber nicht (1500).


    Wie gesagt, ich vermute nicht das es an den Switchen liegt sondern an den QNAP'sen

    Firmware aller meiner Komponenten sind eigentlich immer auf den neusten Stand und maximal einen Release zurück wenn ich es mal nicht gleich mitbekommen habe. Momentan ist alles netzwerktechnische inkl. der NAS auf den aktuellsten Versionen, leider gibt es ja keine neue Version als die 4.3.6.1831 für meine alten 870/879 Modelle.

    Ich habe mir jetzt einen HP 1920-24G (JG924A) und einen 1820-24G (J9980A) besorgt und sobald die da sind werde ich damit den alten HP 1810-24G ersetzen und damit testen ob sich am Zustand etwas ändert.

    Die 20er HP Reihe ist auch echt brauchbar, habe zwei 2520G mit POE hier im Rack, die laufen einfach.


    OFDMA ist der Docsis 3.1 Upstream, schaue mal ob du den bei dir schon findest, ggf. bist du dann auch eins der Docsis 3.1 Opfer.

    https://www.cabletech.at/wp-co…SIS3.1_Cable_Tech2019.pdf

    So sehe die bei mir aus, wobei die Modulation der QMA Kanäle meist bei 16 liegt und nur noch ganz selten mal kurz bei 64, also echt scheiße!

    pasted-from-clipboard.png

    Bin am Überlegen ob ich auch mal die günstigen 1930 HP-Aruba probieren soll da ich an meinem Remote Standort inhouse gerne mit 10G von Switch zu Switch verbinden möchte. Zu Hause habe ich mittlerweile zwei QNAP QSW-M408-4C zwischen Keller und Büro mit Glasfaser verbunden. Netzwerkschrank, NAS'se, etc. liegt alles im Keller wegen Temperatur und Geräuschpegel.


    tatsächlich, da gibt es doch glatt OFDMA Kanäle in der FritzBox:

    OFDMA_Kanal.jpg

    Die Werte, wenn man der Fritz denn trauen kann, sehen super aus, alles läuft mit der höchsten Modulation.


    Ja die 30er Reihe ist schon wirklich interessant, habe ich mir auch mal angesehen, aber ich tendierte im Moment doch hin zum UI Kram, weil das mit dem Controller und den APs dann schönes SDN ergibt.

    Zitat von Crazyhorse

    Die Werte, wenn man der Fritz denn trauen kann, sehen super aus, alles läuft mit der höchsten Modulation.

    perfekt, ich kann mich mit der Geschwindigkeit und Performance des Kabelanschlusses nicht beklagen.

    Zitat von Crazyhorse

    Ja die 30er Reihe ist schon wirklich interessant, habe ich mir auch mal angesehen, aber ich tendierte im Moment doch hin zum UI Kram, weil das mit dem Controller und den APs dann schönes SDN ergibt.

    Ich hatte leider noch nicht die Zeit mich mit den Ubiquiti Produkten auseinanderzusetzen. Ich habe einen FritzRepeater 3000 und einen 2400 im Haus verteilt und das deckt mir hier alles ab. Am Remote Standort ist noch einige Hardware von Draytek im Einsatz Vigor 2865ac und zwei AP902/903, jahrelang zufrieden gewesen mit Draytek.


    Melde mich zurück sobald ich wieder Erkenntnisse zum eigentlichen Problem habe. Danke für Deine/Eure Unterstützung!

    Hallo zusammen,

    ich wollte mich mal wieder kurz melden.

    Ich habe jetzt den HP-1810-24G Switch am Remote Standort gegen einen HP-1820-24G und dann nochmals gegen einen HP-1920-24G getauscht. Das Resultat hat sich nicht geändert, selbes Problem wie immer, die Datenübertragung vom lokalen Standort an den Remote Standort hört nach ein paar MB (in der Regel 3-7MB)auf, dauer dann ein Weilchen und bricht dann mit der Fehlermeldung "Unerwarteter Netzwerkfehler. (59)" ab.

    Egal ob ich einen Trunk mit 2 oder mehreren Gigabit Ports konfiguriert habe oder auch komplett ohne Trunk mit nur einer 1GB Leitung das 879U-RP anbinde.

    Wie ich vermutet hatte liegt es in meinem Fall nicht an den Switchen.


    Was am Remote Standort noch "anders" ist sind die Router und deren Konstellation. Es ist eine Fritzbox 7590 am DSL 100.000 Anschluss von Vodafone und dahinter ein Draytek 2865ac Router als exposed host. Die FritzBox wird nur für Telefonie verwendet, alles weitere ist dort inkl. WLAN deaktiviert. MTU des Draytekrouters beträgt durch den vorgeschalteten Router 1492.

    Wenn ich vom lokalen Standort das NAS am Remotestandort pinge mit "ping -f -l 1378 192.168.x.x" ist das der größte Wert der noch durch geht. Bei allen größeren Werten kommt

    Code
    "Zeitüberschreitung der Anforderung".


    Könnte es daran liegen?

    Ich kann den Draytekrouter aber nicht so ohne weiteres entfernen da dort sämtliche VPN Verbindungen hinterlegt und gesteuert werden.

    Die MTU sollte jeder halbwegs aktuelle Client automatisch sauber aushandeln können.


    Hier hatte ich für VPN auch mal 1340 eingestellt, damit ich sauber übers Handy mit LTE ohne Fragmentierung Daten schubsen kann.


    Die Einstellungen sind in der neuen Version entfallen, aber alle Verbindungen laufen weiter und HBS3 sichert weiterhin wie gewohnt durch die 2 Tunnel und da sind auch schon mal weit über 100GB Daten per Job rüber gelaufen.

    Kannst du dir ein Monitoring von einem Standort zum Anderen bauen?


    Eine Möglichkeit ist z.B. eine Upstream Störung eines Anschlusses, der läuft aber wenn der dann voll ausgelastet wird gehen die Antwortzeiten so nach oben, das die HBS3 dann in den Timeout läuft und der Job mit einem Fehler aussteigt.


    Bei mir kann ich über die pfSense z.B. die Cloudflare DNS Server per ICMP monitoren. Dann sehe ich wenn auf einer Seite die Verbindung spinnt sehr schön als Peak in der Grafik.

    Zitat von Crazyhorse

    ... HBS3 sichert weiterhin wie gewohnt ...

    HBS nutzt intern rsync, und das ist stabil bei schlechten Netzwerkverbindungen und setzt nach Unterbrechungen automatisch wieder auf, oftmals ohne dass man davon was mitbekommt. (Der mehrere Tage dauernde Abgleich von 850 GByte Daten lief trotz mehrerer Reboots des Routers durch.)


    Im Eingangsbeitrag (und auch bei Onkel_Tom?) geht es aber um eine Kopieraktion über SMB-Mounts und VPN. Das ist nach meinen Erfahrungen wesentlich empfindlicher gegenüber Verbindungsabbrüchen oder langen Ping-Zeiten. Ein Aussetzer bedeutet idR. den Abbruch des Kopiervorganges.


    Wenn sich das Problem mit den Abbrüchen nicht lösen lässt (hier sind ja auch noch mindestens zwei Internetprovider mit beteiligt), dann würde ich den Dateitransfer über (S)FTP machen (z. B. mit Filezilla). FTP ist bei schlechten Verbindungen ebenfalls stabiler als SMB.

    Anthracite hat vollkommen recht, es geht mir hier nicht im HBS sondern um Zugriff über SMB.

    Die HBS3 Version unter QTS 4.3.6 ist die 3.0.210916 is so grottenschlecht das nicht mal eingehende Aufträge vom Remote NAS angezeigt werden. Mein "Update und Installations-Share" ist 5TB groß, wenn ich den zwischen Remote Standort und lokalem Standort mit HBS3 synchronisieren will dauert das Tage obwohl nur paar hundert MB an Daten aktualisiert wurden. Der Vergleich der Daten dauert wohl so lange und bekommt keine Performance auf der Verbindung.


    Wenn ich z.B. die kürzlich aktualisierte Java Version vom lokalen Standort auf den remote Standort kopieren will ziehe ich einfach im Explorer die beiden java Installationsdateien vom lokalen SMB Share auf den Remoteshare und der Kopiervorgang bricht wie oben beschrieben ab. Hat die Datei unter 2-3Mb funktioniert es.


    Verbinde ich von einem PC am Remote Standort auf den dort lokalen Update-Share auf dem 879U-RP und kopiere dann irgendwelche Dateien auf das 870U-RP hier am lokalen Standort funktioniert das. Die Geschwindigkeit bricht zwar nach ein paar MB komplett ein und es dauert dann ewig bis der Kopiervorgang fortgesetzt wird, aber es funktioniert und bricht nicht mit Fehler ab.


    Die MTU-Geschichte von oben ist übrigens von beiden Seiten gleich mit max. 1378.

    Das mit dem HBS3 war ein Beispiel, das selbst so ein robuster Dienst nix mehr überträgt und den Job abbricht, wenn Vodafone mal wieder einen Störer im Sgement hat und der alle Upstreams im Segment killt.


    Daher die Frage, hast du ein Monitoring wie die Antwortzeiten der jeweiligen Standorte Richtung Internet sind und ob hier schon Verluste auftreten.


    Wie verhalten sich die Ping Zeiten von Standort 1 nach 2 wenn du Daten zwischen diesen überträgst?


    Und HBS3 braucht für 9TB und 455k+ Dateien hier ca. 1h 20Min für den Abgleich, wenn nix großes geändert wurde, man darf nur den Parameter, Dateiinhalte prüfen nicht setzen, denn dann werden immer alle Daten übertragen.

    Ggf. ist das ja, richtig parametriert eine Alternative.


    Ansonsten kannst du SMB vom Client aus ja sehr leicht mit Wireshark mitschneiden und schauen was wann passiert, wie die Antwortzeiten der Gegenstelle sind usw. Das sollte relativ schnell Antworten liefern, wenn sich der Fehler so leicht erzeugen lässt.


    Schon mal an den fraglichen Clients einen IP Stack Reset durchgeführt?

    Code
    netsh int ip reset

    Einmal editiert, zuletzt von Crazyhorse ()