Beiträge von Onkel_Tom

Kurzes Updates zu diesem Problem.

Es lag NICHT an den QNAP'sen, es lag an der Firewall des Draytek Vigor Router am Remote Stützpunkt.

Im Defense Setup waren dort unter der UDP flood Abwehr 2.000 Pakete /Sek. konfiguriert und Draytrek schreibt das bei 100M Bandbreite dort mindestens 8.000 Pakete/Sek. eingetragen werden müssen.

Da ich eine feste IP Adresse an der Basis habe, habe ich diese in der Whitelist der Firewall im Draytek Router eingetragen und jetzt kann ich kopieren von welcher Seite ich will und auch egal welche Größe die Dateien haben. Bricht nix mehr ab, dauert halt so lange wie es dauert und damit bin ich vollkommen zufrieden.

Könnte ja sein das jemand mal ein ähnliches Problem hat.

Ich habe aktuell kein Monitoring. Da müsste ich mich erst mal schlau machen was ich dazu brauche und wie das zu bedienen ist.

Die Option "Dateiinhalte prüfen" ist nicht aktiv bei meinem Zwei-Wege Synchronisationsauftrag.

Ich kann ja nochmals den selben Auftrag auf dem 879U-RP am Remote-Standort anlegen und versuchen von dort aus den Auftrag starten, vielleicht geht es von da aus schneller.

Wireshark probiere ich mal aus.

Das betrifft alle Clients und nicht nur bestimmte. Ein IP Stack Reset würde da defintiv nichts bringen.

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.

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

"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.

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!

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

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.

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.

Zitat von dhc-beaver

Hast Du einen oder 2 Netzwerk-Ports je Gerät und benutzt Du einen oder beide?

ich habe am TS-870U-RP eine 10G Schnittstelle und am TS-EC879U-RP 2x1G Ports als Trunk (lacp, dynamisch) in Verwendung . Falls das die Frage war

Zitat von dhc-beaver

mal die OPLOCKS abgeschaltet?

Ja, auf beiden NAS und für die selbe Freigabe. Leider keine Änderung.

Ich hatte auch ein Problem mit der QuFirewall seit dem letzten Update auf 2.1.0. Zuvor war seit Beginn von QuFirewall die Option "Europa" in der Länderliste für die Zugriffe verfügbar. Das wurde jetzt im letzten Update entfernt und man sich die gewünschten europäischen Länder selbst zusammensuchen und konfigurieren.

Da aber in meiner Konfiguration noch "Europa" stand wurde die QuFirewall nach einem Reboot zwar gestartet, aber blockierte irgendwie keine Zugriffe und und das Log blieb leer. Beim Versuch die Konfiguration zu ändern sagte mit QuFirewall das der Prozess nicht beendet werden kann obwohl ich ihn vorher schon manuell beendet hatte und wieder starten wollte, wohl eher ein Fehler das starten mit stoppen vertauscht wurde. Aber erst nachdem ich "Europa" aus der Länderliste entfernt habe und Deutschland hinzufügte ließ sich die QuFirewall wieder starten und protokolierte dann auch wieder abgewiesenen Zugriffe.

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)

Zitat von ITAZV

Im Moment setze ich überall verwaltete HP Procurve L2 Switche ein, wobei, unabhängig von meinem Problem mit dem NAS, in den nächsten Wochen alle im Einsatz befindlichen Switche gegen Aruba L3 Switche getauscht werden.

Mich würde mal interessieren ob das Problem mit den L3 Switchen behoben wurde. Habe das selbe Problem mit einem TS-EC879U-RP an einem HP Procurve L2 Switch mit 2x1GB Port Trunking. Aber egal ob ich einen Port abziehe oder nur mit einer Schnittstelle konfiguriere, die Abbrüche beim Kopieren bleiben gleich.

Du hast immer noch keinen FQDN angegeben. Gebe dem Pi einfach unter /etc/hostname den Namen "clamavairprint.local" und trage diesen auch in die /etc/hosts Datei ein. Nach einem Reboot sollte der Pi unter http://clamavairprint.local/ erreichbar sein und dann sollte es auch mit dem cvd-update funktionieren.

wenn Du mit einem Browser folgenden Link öffnest

http://clamavairprint/main.cvd

wird die Datei dann zum Download angeboten oder öffnet sich die Datei im Browserfenster?

Zitat von hogen

Ignoring mirror 192.168.171.131 (due to previous errors)
Ignoring mirror 192.168.171.142 (due to previous errors)

hat der Pi jetzt 2 unterschiedliche IP's oder warum versucht der Freshclam hier auf unterschiedliche IP's zu zugreifen?

Funktioniert deine Namensauflösung (DNS) im Netzwerk korrekt?

Eventuell die hosts Datei auf dem NAS anpassen bzw. ergänzen.

Ich denke du solltest einen apache oder lighttp Server auf dem Pi aufsetzen und das dann darüber machen. Dann kannst Du relativ einfach eine Subdomain anlegen und das ganze cvd-update-gedöns darüber abwickeln und kommt somit mit nichts anderem in Konflikt.

Zitat von hogen

Code

Retrieving http://http://clamavairprint:8000/main.cvd
WARNING: Can't get information about http://clamavairprint:8000: Name or service not known
WARNING: Can't download main.cvd from http://clamavairprint:8000

Das "http://" muss aus der freshclam.conf raus => DatabaseMirror clamavairprint

Bist Du dir sicher das es mit dem Port 8000 funktioniert mit cvd serve ?

Ich vermute es liegt am Port.

Hast Du einen apache oder lighttp Server auf drauf auf dem Pi?

was wird den ausgegeben wenn Du auf der NAS per SSH folgenden Befehlt eingibst

freshclam -v -u admin

siehst Du im Browser das directory Listing wenn Du den Share von der Pi aufrufst mit

http://clamavairprint:8000

Ich habe bei mir in der TS-870 Pro den Kingston RAM KVR16S11K2/16 verbaut, das ist ein Kit mit 2x8GB Modulen und läuft seit 7 Jahren problemlos.

steht bei mir auch so, aber in der /etc/resolv.dnsmasq stehen meine beiden Nameserver drin

nameserver 192.168.3.98@eth1
nameserver 192.168.3.254@eth1

aber eigentlich geht es hier im thread um mein Problem und nicht um Deins. Mach doch bitte ein separates Thema für Dein Problem auf.