Beiträge von firefox_i

Okay kann sein dass du recht hast.

Ich seh den Screenshot leider nur sehr klein.

Dann muss eben das Standardgateway auch in den Range gebracht werden (kann man aber auch glaub leer lassen oder ?)

S.

Hallo Rainer,

hast du nach dem Abziehen der Leitungen die QNAp neu gestartet ?

Warum meldet deine Fritzbox einen Fehler wenn Du die Adresse fest zuweist?

Die feste Zuweisung passiert in der QNAP.

Kann es sein, dass Du eine Adressreservierung in der Fritzbox machst, die dann per DHCP verteilt wird ?

Das ist gefährlich, denn die Adresse wird abhängig von der MAC-Adresse vergeben...und die ändert sich durchaus bei Portbündelungen.

Also bitte die IP Adressen fix in der QNAP vergeben.

Alles andere ist unsicher und gefährlich.

Desweiteren zum letzten Bild:

Du versuchst das Standardgateway zu ändern.

Die IP Adresse ist in der ersten Zeile.

S.

Hallo Rainer,

Sorry, aber eines Deiner Grundprobleme ist immer noch, dass Du für die ganzen LAN Anschlüsse an der QNAP die an den Switch gehen, denselben IP-Range vergibst.

Hast Du mal versucht, das zu machen was ich beschrieben habe?

Wenn nicht, ist alles Spekulation uns Kafeesatzleserei.

Du brauchst erst mal eine Baseline auf der Du aufbauen kannst.

Und ein Netzwerk mit Loops ist immer was, das sich seltsam verhält und ganz komische Effekte zeigt.

Von Aufgebung der Portbündelung hab ich übrigens nie geredet...das ist alles momentan ein rumdoktern....machs bitte systematisch, ansonsten bringt es nicht viel.

Gruß

S.

Hallo,

Mal vorab zum Themam Portbündelung.

2 Portbündel zwischen 2 Geräten und noch dazu im selben IP-Range ist eine schlechte Idee.

Das funktioniert nur, wenn Du dann die Netze auf einer Seite sauber trennst (VLAN, virtuelle Switche usw....) und das hast Du im vorliegenden Fall nicht.

Zu Deinen Screenshots:

Nächstes mal bisschen größer, da kann man leider nicht alles lesen.

In Deinem Screenshot : was steht da in dem kleinen blauen Kasten neben der Weltkugel bei QLAN_3 ?

Wasmir auffällt : Dein QLAN_3 hat keine Verbindung nach außen (!)

Also der QLAN_3 funktioniert nur vermeintlich.

Dann mal weiter zur Problemeingrenzung:

- Was sagen die Transferstatistiken im D-Link?

Mal schrittweise folgendes machen:

a) Zieh mal QLAN_3 und QLAN_4 ab und starte das QNAP neu.

--> was ändert sich dann in der GUI der QNAP?

b) Gib mal QLAN_3 eine IP Adresse die NICHT im Range des Portbündels liegt (z.B. 192.168.180.1)

Verbinde dann QLAN_3 mit dem Port 11 des Switch.

--> leuchten die LEDs an QLAN_3 und dem Port am Switch ?

--> was ändert sich in der GUI des QNAP ?

Vergib mal einem Rechner eine feste IP in dem Range des "neuen" QLAN_3 (z.B. 192.168.180.2) und versuche die QNAP unter 192.168.180.1 anzupingen.

--> tut das ?

Wenn ja, steck am Switch um auf Port 12 und teste den Ping nochmal.

Wenn das tut ist QLAN_3 und die beiden Ports am Switch i.O.

Stecke dann QLAN_3 wieder auf den Port 11 am D-Link.

c) Ich vermute, dass QLAN_4 wieder in der QNAP sichtbar und somit konfigurierbar ist,

ja ?
Dann gib mal QLAN_4 eine IP Adresse die NICHT im Range der anderen beiden ist (z.B. 192.168.190.1)

Verbinde dann QLAN_4 mit dem Port 12 des Switch.

--> leuchten die LEDs an QLAN_4 und dem Port am Switch ?

--> was ändert sich in der GUI des QNAP ?

Der Rechner mit der IP im Range des QLAN_3 muss die QNAP immer noch anpingen können, korrekt ?

Dann gib dem Rechner eine feste IP in dem Range des "neuen" QLAN_4 (z.B. 192.168.190.2) und versuche die QNAP unter 192.168.190.1 anzupingen.

--> tut das ?

Es würde mich wundern wenn diese Sachen nicht erfolgreich wären.

Für mich sieht das Ganze so aus, dass durch den selben IP Range auf den QNAP_LANs Du dir eine schöne Loop gebaut hast und da auf dem Switch STP und LP aus sind gibts Chaos im Netz und Deine QNAP kommt ins Schleudern.

Übrigens:

Warum sollte das Abziehen einer Leitung oder auch aller Leitungen die Netzwerkkonfig verhunzen?

Das ist ja gerade das Gute bei einem Portbündel:

Die Verbindung bricht nur dann ab, wenn ALLE Leitungen abgezogen sind - logisch.

An der Konfiguration wird sich durch Abziehen und Anstecken nichts ändern.

Gruß

Sven

Hallo,

okay, wusste garnicht dass der 1100-26 auch stp kann aber egal.

STP ist aus, Loop Protection wahrscheinlich auch ?

Was mich nun wundert: leider ist der Screenshot der QNAP GUI unten abgeschnitten, so dass der kritische Port 4 nicht sichtbar ist.

Wo ich aber zusammenzucke :

- im Switch scheinen die Ports 11/12 NICHT für Portbündelung konfiguriert sind - warum ?

- In der QNAP GUI sehe ich, dass der aktive Trunk (QNAP LAN1+2 an Ports 9+10) im selben IP Range liegt wie QNAP LAN3....haben beide 192,168.178.xx

Was willst damit erreichen ?

Warum 2 Portbündelungen zum selben Switch im selben IP-Range?

Wie kommen die QNAP LANs zu ihren IP Adressen ?

Für mich sieht das Fehlerbild so aus:

- Beim Hochfahren der NAS bzw. einstecken der Leitungen entsteht eine Loop

- Da im Switch kein STP und Loopprotection aktiv ist entsteht tatsächlich eine Loop, die im Switch nicht unterbunden wird.

- Die QNAP wirft LAN4 ab, da es im Netzwerkstack den Fehler erkennt.

Ich behaupte:

Schau dir mal die Trafficstatistik im Switch an.

Ich vermute, dass über die Ports die nicht gebündelt sind, also 11/12, entweder keinen oder exorbitant viel traffic zeigen.

So wie es aktuell konfiguriert ist, kann es mMn nicht funktionieren, da die IP Ranges und die Portbündelungen nicht richtig sind.

Gruß

S.

Die für mich wichtige Frage.

Was willst damit erreichen ?

Alle 4 LAN Ports der QNAP an denselben Switch zu stecken macht man doch nur, wenn

- man verschiedene LANs aufsetzt

- Port-Trunking verwenden will

Das ist konfiguratonstechnisch nicht ganz trivial und mehrere Leitungen zwischen 2 Geräten sind immer kitzlig.

Zeig dich mal bitte nen Screenshot der LAN-Konfiguration der QNAP.

Loop-Protection = Loopback Detection ist unter den L2-Features zu finden, ist aber per Default aus.

BTW: der DGS-1100 kann mWn kein Spanning Tree. Wie hast Du denn sichergestellt, dass STP deaktiv ist ?

Hast Du dir mal die Statsistiken im Switch angeschaut?

Zitat von Fanti

Habe mal Qnap-Adapter 3 vom D-Link Port 11 an Adapter 4 an der Qnap angeschlossen. und auch kein Signal (Anzeige weiß) bekommen.

Bei einem Wechsel an dem D-Link Switch hat der Adapter 3 an der Qnap ein Signal, der Adapter 4 an der Qnap nicht.

Also die Netzwerkkabel sind in Ordnung.

Qnap-Adapter 4 an Port 13 des D-Link Switch angeschlossen, an der Qnap auch kein Signal. (weiß)

Ein Neustart der Qnap ändert da leider auch nichts.

Wahrscheinlich ist der Adapter 4 an der Qnap defekt ?

Alles anzeigen

Öhm da blick ich grad nicht ganz durch...kannst da bitte nochmal erklären was du gemacht hast?

Wäre cool wenn Du bitte die Schnittstellen eindeitig beschreibst

Was ich verstanden habe:

a) Status Quo:

- Q_LAN1/2 --> SW_Port 9/10 (Trunk --> wie ist der denn eingestellt?)

- Q_LAN3 --> SW_Port 11

- Q_LAN4 --> SW_Port 12

Ergebnis:

Bis auf die letzte Verbindung funktioniert alles.

Am QNAP leuchten die LEDs am Q_LAN4. In der Anzeige in der QNAP GUI ist diese Schnittstelle weiß.

Wie sieht denn der Status im Switch aus (in der GUI unter System --> Port Settings) ?

Tausche doch mal einfach die Ports 11 und 12 am Switch und schau was passiert.

Gruß

S.

Hmmm ich glaub auch, dass da eher was zugedeckt als gelöst wurde.

Statische IP und Namensauflösung kann kein Grund für die miese Performance sein.

Ich bin noch nie an die MTUs rangegangen, da da sehr schnell was verbastelt werden kann.

Und nur weil Du den Rechner und die QNAP auf 7k gestellt hast, läuft dein Netz noch lange nicht mit 7k

Es müssen ALLE Komponenten dieselbe MTU können sonst bringt es Null.

Ich vermute eher eines:

Wenn Du die MTU manuell eingestellt hast, wurde überall derselbe Zahlenwert eingetragen ?

Hast Du dann mit NETSH mal kontrolliert, welchen Wert Deine Netzwerkschnittstelle wirklich nutzt ?

Wie sind die Switch-Ports konfiguriert?

Das assymetrische Verhalten ist eigentlich nur dadurch zu erklären, dass in einer Richtung massiv Pakete gesplittet werden durch nicht passende Paketgrößen.

Beispiel:

QNAP MTU 1500

Rechner MTU 1508

--> Beim Senden landen 1508 Byte im Netzwerkstack, das muss aber nun auf 2 Ethernet Frames gesplittet werden.....ganz unangenehm

S.

Hallo,

Ich blick da noch nicht ganz durch...also mal langsam:

Es gibt 3 Geräte : Laptop, NAS und MF-Drucker richtig?

Der Laptop ist ein Firmenrechner und in einer Domäne richtig?

Nun wirds spannend:

- Was haben die Geräte für IP-Adressen?

- Ist der Drucker dein "privater" oder hat der irgendwas mit der Firma zu tun?

- Ist das NAS deine private oder hat das irgendwas mit der Firma zu tun?

- Kannst Du vom Laptop aus auf die NAS zugreifen? Wenn ja, welchen Benutzer verwendest Du da?

Wie versuchst Du genau zu Scannen ?

Bei meinen Brother-Geräten sind beim Scannen lediglich der Drucker und das NAS beteiligt, keine Software und auch kein Rechner.

Sorry, dass ich so viel nachfrage, aber da sind derzeit viele Details noch unklar.

S.

Hmm ich vermute, dass man sich hier zu sehr auf die Zwangstrennung eingeschossen hat.

Das Thema mit den SMB Versionen würde mich überraschen, denn warum soll dann nach dem Neustart der NAS es plötzlich tun?

Ich versuchs mal andersrum:

- Hat das vorher funktioniert und das Problem kam dann plötzlich oder hat es unter Windows 10 noch nie funktioniert?

- Konntest Du problemlos über den WIN7 Rechner zugreifen während das Problem existiert?

- Wie hast Du denn das NAS neu gestartet?

- Hast Du mal in die Logs geschaut?

- wie werden die IP Adressen vergeben?

- wie versuchst Du zuzugreifen ? Über den Namen der QNAP oder über die IP? Auf WIN7 und WIN10 beides mal gleich?

- wie ist der Windows 10 und der Windows 7 Rechner angebunden ? Beide Kabel? Beide WLAN?

- wie sind die Energieeinstellungen im NAS?

Meine Vermutung: Entweder eine DNS/Master-Browser-Thematik oder die Energieeinstellung.

Gruß

S.

PS: Warum ich noch nachhake ist einfach: an der SMB Einstellung kann es mMn nicht gelegen haben, sondern es deckt nur die Ursache zu....

Sorry, Aber das kann ich nicht nachvollziehen.

Der oben erwähnte Netgear Switch hat eine Bandbreite von 56Gbps.

Und selbst bei 64 Byte Paketen (also minimale Payload) hat der knapp 41.600 Mfps.

Der wird im normalen Betrieb nie limitieren.

Selbst ein 12 port 10G Switch von Cisco schafft nur 240Gbps auf dem Backplane und knapp 180.000 Mfps bei 64 byte.

Und der hat 12 von den 10G Ports....ich weiß echt nicht welche Switch Performance ein Switch haben muss um deiner Meinung nach zu taugen.

Also wie Du den in die Knie zwingen willst....das bitte zeigen.

Wenn da nicht alle 8 GBit Ports mit 1Gb befeuern kannst während hinten die NAS mit 10Gbit draufgeht....

Bei normalen Datentransfers wie normaler Zugriff aus Shares schafft der das allemal. Alles andere sind eher akademische theoretische Werte zum Vergleich.

S.

Zitat von RedDiabolo

Und der "Traum" von 10x 1Gb teilen sich den 10Gb Port erfüllt sich leider auch nicht. Der Switch kann deine 10x 1Gb Ports nicht parallel zu EINEM 10Gb Port bündeln. Das ginge zwar mit einem "Port Trunking" aber dann auch nur für ein und den selben Client (PC) der z.B. 2 Netzwerkkarten hat. Da würden beide Netzwerkkarten die selbe IP-Adresse bekommen und im Switch wie "ein" 2Gb Port aussehen, eben als " Link-Aggregation". Die kannst du aber nicht auf verschiedenen Geräte aufteilen, sondern nur für jeweils EINE IP-Adresse ...

Kann es sein, dass hier verschiedene Dinge durcheinander fallen?

Versteh ich Dich richtig, dass du sagst, dass bei der 10Gb ort zum NAS keinen Vorteil bei mehreren gleichzeitigen Client Zugriffen bringt?

Ich hoffe ich habe Dich da missverstanden.

Das würde ja unterschiedliche Port-Speeds an einem Switch ad-absurdum führen und würde schnelle Uplink-Ports zwischen Switchen unsinnig ercheinen lassen.

Jeder Port arbeitet mit dem angeschlossenen Gerät mit der maximal möglichen Speed.

Also ein 100Mb Drucker läuft mit 100Mb, ein 1Gb Client mit 1Gb, die 10Gb Schnittstelle des NAS arbeitet am Switch mit 10Gb.

Der Switch empfängt ein Paket, auf einem Port, speichert es zwischen und gibt es an einen anderen weiter - das ist dessen Aufgabe (Store and Forward).

Wenn nun die Geschwindigkeiten nicht zusammenpassen geschieht folgendes:

- ausgehender Port langsamer
Der Switch empfängt ein Paket mit 10Gb vom NAS. An den Client geht es mit 1Gb raus.

Da der Empfänger nach jedem Paket ein ACK zum Sender zurücksendet um den Empfang zu bestätigen dauert das länger da der Client eben nur mit 1Gb kann.

Sobald der Sender das ACK bekommen hat gehts das nächste Paket raus.

Somit effektiv 1Gb.

- ausgehender Port schneller

Der Switch empfängt ein Paket mit 1Gb vom Client. An die NAS geht es mit 10Gb raus.

Das ACK Paket kommt mit 10Gb von der NAS und mit 1Gb an den Client.
Somit effektiv 1Gb.

Aber der Knackpunkt ist:

Die Netzwerkschnittstelle des NAS kann ja mehrere TCP-Verbindungen zu den einzelnen Clients aufbauen.

Somit kann in der Wartezeit auf ein ACK eines "langsamen" gegenübers ein anderer bedient werden.

Ergo:

Du hast 5 Clients die gleichzeitig Daten von der NAS ziehen.

Wenn wir mal davon ausgehen, dass deine NAS schnell genug ist die Daten zu liefern, bekommt jeder Client die Daten mit jeweils maximaler Speed, also 1Gb.

Somit laufen knapp 100MByte an jeden Client und die NAS liefert knapp 500MByte.

Das Ganze hat nichts mit LAG, Trunking oder anderen Portbündelungsmechanismen zu tun.

Gruß

S.

Sobald der Sender das ACK bekommen hat gehts das nächste Paket raus.

Zitat von dolbyman

MAC Filter im WAN ? .. wie geht denn das ? ...

Okay da war ich zu unpräzise:

WOL-Pakete die über das VPN kommen bei denen filtere ich auf die MAC (geht...ist L2).

Wenn ich tatsächlich über "echtes" WAN wecke, dann geht das nicht.

Damit hier ein Security Breach passiert muss ein externer meine öffentliche IP kennen, dann den Port der zum WOL verwendet wird und dann noch die MAC des Rechners den er wecken will....okay....und dann läuft der Rechner. Das Risiko halte ich für vertretbar.

Zitat von Crazyhorse

Da wird halt das hier für benötigt.

https://www.cisco.com/c/m/en_u…p-directed-broadcast.html

Nicht ganz.

Ein directed Broadcast ist ein Broadcast an ein einzelnes Subnetz (also z.B. 192.168.0.255).

Und das was Cisco da macht ist, dieses Paket dann an ein anderes Subnetz (also z.B. an die 192.168.10.255) weiterzuleiten.

Das ist ein super Einfallstor für DoS Attacken.

Was ich mache ist, ich schicke das WOL Paket an einen spezifischen Port meiner öffentlichen Router Adresse.

Und über eine Port Weiterleitung schicke ich das dann an die 255.255.255.255, also den limited Broadcast der nur bei mir lokal ist.

Da braucht man also kein directed Broadcast.

S.

Hallo zusammen,

ich nutze dafür das Wake On Lan Tool 2 (WOL2).

Bei dem kann ich angeben wohin das WOL Paket geschickt wird.

Bei mir sendet WOL2 das Paket an die WAN Adresse meines Routers und an einen speziellen Port.

Dieses Paket wird dann per Firewall-Regel (hier filtere ich u.a. auf die zulässigen MAC Adressen des Versenders) ins interne Netz weitergeleitet.

Somit ist sichergestellt, dass ausschließlich bekannte Geräte ein WOL Paket auslösen können.

Funktioniert aber meist nur mit nem guten Route/Firewall. Fritz ist hier absolut überfordert. Ich hab einen von Lancom.

S.

Hallo zusammen,

ich hatte ähnliche Erfahrungen - allerdings bei einem RSYNC Job - siehe :

Rsync mit HBS3 tierisch langsam

Allerdings musste ich den von Crazyhorse angesprochenen Haken setzen (!) damit nur die Änderungen übertragen wurden.

Meiner Erfahrung nach muss man hier aber trennen zwischen RSYNC und RTRR:

RSYNC ermittelt zunächst, was übertragen werden soll.
Hierzu wird zunächst auf Datum und Größe geschaut- gibt es hier keine Unterschiede wird die Datei nicht kopiert.

Gibt es hier Unterschiede werden nun für einzelne Blöcke der Datei auf beiden Seiten ein Hash errechnet. Unterscheidet er sich, wird der Block übertragen, ansonsten eben nicht.

RSYNC überträgt also beim Vergleich nicht (!) den Dateiinhalt sondern lediglich Hashes.

Bei RTRR scheint hier QNAP ein eigenes Süppchen zu kochen.
RTRR kennt aber mWn den o.g. Modus nicht, dass nur geänderte Dateibrocken übetragen werden sondern wenn sich die Dateien unterscheiden, wird übertragen.

Ich persönliche verwende bei Syncs großer Datenbestände über WAN immer RSYNC.

RTRR verwende ich wenn möglich nur im LAN.

Wenn ich partout eine 2 Wege-Sync via RTRR brauche und das Ganze via WAN sind es meist nur kleine Datenmengen (max. 1GB) und da ist RTRR - auch wenn alles übertragen werden muss - tragbar.

S.

Hallo zusammen,

also um hier die Sache etwas auseinander zu sortieren sollten eventuell einige Zusatzinfos mit angegeben werden:

- QTS Version

- Art des Jobs (RSYNC oder RTRR)

Mir scheint, dass hier zu viel durcheinander geworfen wird und es scheint ja auch so zus ein, dass es zwischen den 4.3.6 und 4.4.1 er Versionen einen Unterschied gibt.

Ich kann für mich nur sagen dass

- QTS 4.3.6

- RSYNC Jobs

- Option "Exclude Duplicates" aktiv

nur die Änderungen überträgt.

S.

Na das gibt doch aber ein Bild:

Bei einigen anderen und mir mit HBS3 und QTS 4.3.6 scheint es zu laufen und die Optionen Wirkung zu haben,

Bei Dir und PureVida mit QTS 4.1.1 werden extremst langsam Daten übertragen.

Klingt für mich eher nach nem QTS Thema.....

BTW:

Es klingt bei QO so, als ob auf nem P-System im Business Einsatz mit der QTS 4.1.1 gearbeitet.
Finde ich ehrlich gesagt sehr sehr mutig.....ich bin bei uns mit FW Versionen auf P-Systemen mindestens 1 Quartal hinterher.

Bei Main releases sogar 2Qs.

S.

Zitat von QNAPOPFER

bei einer 4GB Leitung funktioniert das prima.

Okay, sorry, dass ich davon ausgegangen bin, dass es wie bei 99.99999999999% aller Poster hier um eine normale Leitung ging und keine Glasfaser Standleitung.

Dann bleibt wohl nur der Weg über den Support von QNAP, denn ich bin raus.
Ich kann nur sagen, dass bei mir diese Option was gebracht hat.

Welche QTS Version ist denn drauf ?

Wie es bei 4.4.1 ist wie bei PuraVida kann ich nicht sagen.

S.

Zitat von QNAPOPFER

Wie schon beschrieben lade ich in die Google Cloud 30GB via Browser hoch, benötige ich bei meiner Bandbreite ca. 2-3 Minuten.

30 GByte benötigen bei einer Bandbreite von 1Gbit ca. 4 Minuten.
Du willst das in 2-3 Minuten erledigt haben.....da kann was nicht passen.

Zitat von QNAPOPFER

Das verstehe ich nicht, wenn die Deduplication Option aus ist, genau genommen ist es egal ob an oder aus hab beides getestet, inwiefern sind knapp 10 Stunden für einen Cloud Upload "passend"?

Welche Option ist denn genau aus ? Die "Exclude Duplicate Files" ist NICHT Deduplizierung.

S.

Hallo,

ich kenne nun die Backup Funktionalität von QNAP nur wenig, da ich für Datensicherung eine andere Toolchain einsetze.
Daher ist mein Usecase für HBS reinses Synchronisieren.

Aus dieser Sicht von mir nur die Anmerkung:

Wie beschrieben wird bei einer deaktivierten Option immer alles übertragen und das würde ja auch zu deiner Backup-Dauer passen.

Hinter der Option "Exclude Duplicates" scheint - zumindest bei SYNC Jobs - QNAP also die Funktionität dahinter zu haben, nur Unterschiede zu übertragen,

Ich hab den Eindruck, dass mit diesem einen Haken, eben mehrere Eingriffe in die Parameter der einzelnen dahinter liegenden Prozesse stattfinden.

Was passiert denn, wenn Du den Haken setzt?

Ein Punkt den ich bei QNAP immer nerviger finde:
Es gibt tolle neue Funktionen und Features, aber die Doku ist schlichtweg nicht existent.
Alle Doku die ich finden konnte zur HBS ist noch die 2-er......

S.

Freit ich dass ich helfen konnte.

Kleiner Fun Fact:
In früheren Versione der HBS gab es eine ähnlich benannte Optionen die man damals aber auf gar keinen Fall aktivieren durfte, denn sonst wurde zuerst der komplette Dateiinhalt von der Platte gelesen um festzustellen was sich geändert hat....

Mir scheint dass QNAP unter der neuen Option irgendwie Dinge kombiniert hat...

S.