link aggregation DEAKTIVIEREN funktioniert nicht

  • Liebe Community,


    für Euch sicherlich ein sehr einfaches Problem aber ich verzweifle echt gerade:


    Setup bisher, welches fehlerfrei lief:

    TS-451 DEU mit link aggregation aktiv angeschlossen an einem D-Link DGS-1210 bei dem link aggregation für die beiden Ports ebenfalls an ist.


    Nun wollte ich das wieder rückgängig machen und das NAS nur über einen Port ansprechen (Weil ich eine VM installieren möchte und diese über einen eigenen Port erreichbar machen mag) und dafür im allerersten Schritt auf dem NAS die Aggregation ausgeschaltet und dann auf dem Switch.


    Nun erreiche ich das NAS nicht mehr richtig. Im QFinder wird es immer mal wieder angezeigt, ein Aufruf über SSH oder die entsprechenden IPs funktioniert aber nicht. Nach einem hard-reboot komme ich dann immer kurz drauf aber nur für einen Aufruf, nicht dauerhaft. Ich kann dort dann den Adapter wieder auf Trunking setzen und alles ist gut aber das will ich ja gerade nicht.

    Ich bin sicher, ich mache als Netzwerk-DAU nur einen Denkfehler aber wo?


    DANKE!

  • Der Dreisekundenreset sollte dein Problem erst einmal lösen, da dabei auch die Port-Aggregation gelöscht wird.


    Der Reset hat noch ein paar weitere Auswirkungen, siehez. B. hier.

  • Nun wollte ich das wieder rückgängig machen und das NAS nur über einen Port ansprechen (Weil ich eine VM installieren möchte und diese über einen eigenen Port erreichbar machen mag) und dafür im allerersten Schritt auf dem NAS die Aggregation ausgeschaltet und dann auf dem Switch.

    Welchen Vorteil hat es für Dich eine VM über einen eigenen physischen Port erreichbar zu machen?!

    Innerhalb eines Aggregats hast Du eine zusätzliche Ausfallsicherheit, wenn mal aus versehen ein Kabel rausgezogen wird oder aus welchem Grund auch immer ein Link versagt.

  • Welchen Vorteil hat es für Dich eine VM über einen eigenen physischen Port erreichbar zu machen?!

    Innerhalb eines Aggregats hast Du eine zusätzliche Ausfallsicherheit,

    Da ich dieselbe Idee hatte wie der TE und zwei Ports mit zwei unterschiedlichen IPs belegt habe, eine für NAS-Dienste, eine für die VM, also keine Aggregation, kann ich mal meine Erfahrungen schreiben.


    Die Ideen dahinter waren

    1. Keine Beeinträchtigung der NAS-Zugriffsgeschwindigkeit, wenn gleichzeitig die VM sich mit anderen Geräten oder dem Internet "unterhält".

    => Theoretisch Ziel erreicht, praktisch keine Auswirkungen, da dieser Fall zu selten auftritt, um sich bemerkbar zu machen.


    2. Höhere Sicherheit, wenn Ports der VM per Portfreigabe vom Internet aus erreichbar sind, da ein Angreifer nicht mehr über das NAS muss, sondern nur auf die VM und damit nur diese angreifen kann.

    => Da Qnap auch bei eigenem Port für die VM den Datenverkehr über einen virtuellen Switch laufen lässt, besteht keine erhöhte Sicherheit. Ziel verfehlt (ist aber auch nicht schlechter geworden).


    3. NAS über zweite IP erreichbar, wenn erste IP nicht mehr will (meistens wegen Konfiguration kaputtgespielt).

    => Funktioniert und erfüllt seinen Zweck.


    Zu deinem Argument mit der zusätzlichen Ausfallsicherheit einer Aggregation:

    Diese Ausfallsicherheit besteht theoretisch, aber ich sehe sie in der Praxis nicht, weil die Portaggregation von qts vergleichsweise fehleranfällig ist, während der spontane Ausfall eines normalen Ports sehr selten vorkommt (meistens fällt der Port aus, wenn man ihn fehlerhaft konfiguriert hat, aber dann hilft nicht die Link-Aggregation, sondern eine zweite "Notfall-IP").


    Eine höhere Geschwindigkeit kann ich durch eine Link-Aggregation nicht erzielen, erstens weil das dafür nötige Zugriffsszenario hier praktisch nicht vorkommt, und zweitens weil es woanders im Netz einen Flaschenhals gibt, der die Geschwindigkeit auf die Leistung eines NAS-Ports begrenzt.


    Die Fehleranfälligkeit der Portaggregation war übrigens der Grund, warum ich die Versuche damit schnell wieder aufgegeben habe.

  • Danke an alle!


    Der 3-sekunden Reset führt dazu, dass ich kurz und einmalig auf das NAS komme, dann aber nicht mehr. Das ist leider genau der Fehler, den ich mir nicht erklären kann. Ich habe nach dem Reset und reboot ca. 15 Sekunden Zeit, mich einzuloggen und die Adapter wieder auf Trunking zu stellen. Tue ich das nicht, verliert das NAS die Verbindung zum Netz und ist weder im DHCP Server noch per QFinder aufzufinden


    Barungar tatsächlich wollte ich es eigentlich nur einmal ausprobieren. Final sollte das Setup in der Tat wie von Dir beschrieben sein


    EDIT: Korrektur: im DHCP sehe ich beide Adapter mit eigenen IPs. Über diese reagiert das NAS aber nicht bzw. liefert nicht den Login Sceen zurück und nimmt keine SSH Anmeldung an

  • Versuch es mal mit

    https://IP-DES-NAS:443 bzw. statt 443 den Port den Du eingestellt hast, falls Du es geändert hast oder gleich mit http://IP-DES-NAS:8080

  • mich einzuloggen und die Adapter wieder auf Trunking zu stellen. Tue ich das nicht, verliert das NAS die Verbindung zum Netz

    Kann es sein, dass im Switch noch eine falsche Einstellung vorhanden ist?


    Nimm im Switch mal einen anderen Port, der nie für Portaggregation benutzt worden ist.

  • btw: wie zitiere ich in dieser Forensoftware?

    Text mit Maus markieren. Sobald du die Maustaste loslässt, erscheint da "Zitat speichern" und "Zitat einfügen", wo du auf das Gewünschte drauf klickst.

  • Nur so als kleine Frage. waren immer beide Netzwerkkabel am NAS und am Switch verbunden?


    Wenn ja bitte mal nur mit einem Kabel verbinden und die Link Aggregation im Switch entfernen, falls noch nicht geschehen.

  • Mod: Unnötiges Volltext-/Direktzitat entfernt! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    Ja, es waren (bis auf zum Testen der Funktionalität nach der Einrichtung vor einigen Wochen) immer beide Kabel verbunden. Für den hier auftretenden Fehler ändert das Ziehen eines Kabels leider nichts.


    Getestet folgende Kombinationen:

    - Kabel A+B drin, Kabel A raus, Kabel B raus (jeweils sowohl am Switch als auch am NAS)

    - lb am Switch an / aus

    - lb am NAS an / aus


    mit Ausnahme der ersten paar Sekunden nach dem 3-Sekunden Reset bekomme ich Zugriff auf das NAS nur in der Kombi lb an Switch und NAS an. Ob Kabel A, B, A+B ist dann aber egal

  • Hast du das NAS mal direkt am Router oder einem anderen Switch getested, ohne Link Aggregation und nur mit einem LAN-Kabel? Eventuell liegt das Problem beim DGS-1210.


    Das NAS auch mal an einem anderen Port beim Switch angeschlossen?


    Manchmal hilft es auch die gesamte Netzwerk-Infrastruktur auszuschalten und nach einer kurzen Pause erneut hochzufahren.

    Im QFinder wird es immer mal wieder angezeigt, ein Aufruf über SSH oder die entsprechenden IPs funktioniert aber nicht

    Funktioniert nur der Zugriff auf die GUI nicht mehr oder ist das NAS auch im Datei-Explorer nicht mehr zu sehen?


    Für den Webzugriff kannst du im LAN auch diese Adresse verwenden https://IP-NAS/cgi-bin/, die Seite wird im Browser als nicht vertrauenswürdig gemeldet, was aber übergangen werden kann. Eventuell auch mal einen anderen Browser verwenden.


    Noch eine kleine Anmerkung am Rande:

    Mein NAS hat 4 Ports, zwei davon sind in einem LACP zusammengeschlossen und mit einem Switch verbunden. Die zwei weiteren Ports sind im gleichen Netzwerk jedoch direkt am Router angeschlossen. Ich weiss nicht mehr warum genau ich die zwei einzelnen Ports direkt am Router angeschlossen habe. Ich weiss nur noch das es zu Verbindungsproblemen kam als alle 4 Ports mit dem Switch verbunden waren. Entgegen deiner Aussage traten die bei mir auch auf als alle 4 Ports in einem LACP waren.

    Einmal editiert, zuletzt von Xydoc ()

  • Die Ideen dahinter waren

    1. Keine Beeinträchtigung der NAS-Zugriffsgeschwindigkeit, wenn gleichzeitig die VM sich mit anderen Geräten oder dem Internet "unterhält".

    => Theoretisch Ziel erreicht, praktisch keine Auswirkungen, da dieser Fall zu selten auftritt, um sich bemerkbar zu machen.

    Diese Beeinträchtigung ist aber auch eher hypothetisch, außer natürlich man hat synchrone 1 Gbit/s Anbindungen ans Internet, was ja jeder hat. ;)

    Und in einem Aggregat ist es noch unwahrscheinlicher, zusätzlich könnte man auch noch DCSP oder ähnliches einsetzen. Wenn da eine reale Gefahr bestünde.



    2. Höhere Sicherheit, wenn Ports der VM per Portfreigabe vom Internet aus erreichbar sind, da ein Angreifer nicht mehr über das NAS muss, sondern nur auf die VM und damit nur diese angreifen kann.

    => Da Qnap auch bei eigenem Port für die VM den Datenverkehr über einen virtuellen Switch laufen lässt, besteht keine erhöhte Sicherheit. Ziel verfehlt (ist aber auch nicht schlechter geworden).

    Eine jedwede "vermeintliche" höhere Sicherheit kann man beim QNAP-Konstukur in den Skat drücken, da so oder so jedes Interface ein INterface des Host-Systems ist. Ob nun direktes Interface, software-defined switch oder whatever. Das "komplette" durchreichen der NIC-Hardware sieht die Virtualization Station gar nicht vor.


    Du stehst Dich also mit Link Aggregat und virtuellen Switch kein Stück schlechter.



    3. NAS über zweite IP erreichbar, wenn erste IP nicht mehr will (meistens wegen Konfiguration kaputtgespielt).

    => Funktioniert und erfüllt seinen Zweck.


    Zu deinem Argument mit der zusätzlichen Ausfallsicherheit einer Aggregation:

    Diese Ausfallsicherheit besteht theoretisch, aber ich sehe sie in der Praxis nicht, weil die Portaggregation von qts vergleichsweise fehleranfällig ist, während der spontane Ausfall eines normalen Ports sehr selten vorkommt (meistens fällt der Port aus, wenn man ihn fehlerhaft konfiguriert hat, aber dann hilft nicht die Link-Aggregation, sondern eine zweite "Notfall-IP").

    Ahja, das ist dann aber schon eine Kunst. Und mehrere IPs kann ich auf einem Link Aggregat haben, ich kann da sogar noch mehrere "virtuelle Links" (VLAN) drüber führen.


    Und in meiner Erfahrung sind die physischen Störungen deutlich höher als die Fehlkonfigurationen. Mal eben was gemacht und das Patchkabel "beschädigt" oder aus dem Port gezogen. Oder der Absturz mit Reboot eines Switch-Modul, alles das sind eher Ding, die bei mir und in meiner Erfahrung ein passieren... bei all denen hilft ein Link Aggregat.


    Und was auch nicht selten vorkommt, wenn man eben mal was "umstecken" muss. Beim Link Aggregat gar kein Problem, man muss halt nur darauf achten, dass ein Link noch besteht, dann kann man die anderen seriell umstecken.



    Eine höhere Geschwindigkeit kann ich durch eine Link-Aggregation nicht erzielen, erstens weil das dafür nötige Zugriffsszenario hier praktisch nicht vorkommt, und zweitens weil es woanders im Netz einen Flaschenhals gibt, der die Geschwindigkeit auf die Leistung eines NAS-Ports begrenzt.


    Die Fehleranfälligkeit der Portaggregation war übrigens der Grund, warum ich die Versuche damit schnell wieder aufgegeben habe.

    Eine höhere Geschwindigkeit zu erreichen war ja gar nicht mein Ansatz. Ich persönlich habe nur kein Verständnis, dafür das man für sowas zwei getrennte physische Ports nutzt, wo ich einfach den Mehrwert nicht erkennen kann. Dafür aber die Nachteile, die sich in meiner Wahrnehmung ergeben.


    Ich kann die vermeintliche Fehleranfälligkeit nicht nachvollziehen, ich betreibe QNAPs mit Link Aggregation schon viele, viele Jahre und ich hatte noch NIE mit der Link Aggregation ein Problem.

  • Habe alle Vorschläge (inklusive Xydoc , danke dafür!) einmal durchgespielt und kann den Fehler wie folgt eingrenzen:


    Das NAS lädt irgend eine Konfiguration im Booten nach, die es zerschießt. Unabhängig vom zugreifenden System, Browser, Switch/Router, Browser etc.

    Ich kann in den ersten 15-20 Sekunden das NAS normal bedienen über ein Lan Kabel. Wenn ich dann nicht auf trunking schalte und damit neu boote, verliere ich den Connect und es hilft nur der 3-Sekunden reset, dann geht es von vorne los.


    Es scheint sich hier beim Laden auch tatsächlich aufzuhängen weil es danach dann auch im QFinder nicht mehr auffindbar ist. Im Switchmenü die IP aber noch zugewiesen erscheint.


    Sagt das jemandem was? Was könnte das NAS hier im Starten laden, was mit trunked ports unproblematisch, über einen Adapter aber problematisch ist?

  • Sagt das jemandem was? Was könnte das NAS hier im Starten laden, was mit trunked ports unproblematisch, über einen Adapter aber problematisch ist?

    Mir ist nichts derartiges bekannt. Wenn etwas ohne Portaggregation nicht funktioniert, ist nicht anzunehmen, dass es mit Portaggregation funktioniert (außer Kabelbruch, defekter Port u. Ä.).


    Aber Xydoc s Anmerkung am Rande hat mich auf ein paar Ideen gebracht, was noch falsch sein könnte:

    - Zwei DHCP-Server

    - Zyklus (Kreis) im Netzwerk

    - IP doppelt vergeben.


    Versuch mal, NAS und PC direkt zu verbinden, d. h. kein Switch dazwischen, an beiden Geräten kein weiteres LAN-Kabel eingesteckt, kein WLAN (also der PC kann nur mit dem NAS reden und sonst nichts, sowie umgekehrt).

    Funktioniert es jetzt? Wenn ja, kannst du entweder in aller Ruhe die Konfiguration auf dem NAS durchgehen oder nach und nach das restliche Netzwerk wieder hinzunehmen, bis der Fehler wieder auftritt.


    P. S.: Hast du mal einen Reboot der Fritzbox gemacht? Was auch helfen kann: Auf der Fritzbox NAS (und eventuell PC ) aus der Geräteliste löschen. Manchmal verhakt sich auch die.


    Barungar

    Abgesehen von meinen Negativerfahrungen mit der Portaggregation sind wir nicht weit voneinander entfernt. meine Erfahrungen zu Punkt 1) und 2) bestätigen deine Aussagen dazu.

  • Da ist ne gute Idee, danke, das gehe ich die Tage mal durch (bin in Quarantäne und kann derzeit nicht auf die Ersatzswitche und Kabel im Keller zugreifen. Insbesondere der Punkt mit 2 DHCP im Netz ist eine Untersuchung wert weil ich in der Tat keine Fritzbox, sondern einen Draytek Router mit loadbalancing und 2 WAN


    Ich vermute allerdings immer noch, dass es irgendwie mit der virtual Switch Funktion des QNAP zusammenhängt. Habe die Links nun wieder aggregiert und alles läuft rund so wie es soll. Sobald ich einen v-switch anlege komme ich aber nicht mehr aufs NAS und das scheint auch irgendwie noch so zu bleiben, nachdem der Switch wieder gelöscht wurde