Wake on LAN bei 10 Gbit - Alternativen

  • Hi zusammen,

    ja ich wusste vorher, dass die 10GBit Karten kein WoL können.

    Warum kann ich zwar nicht ganz nachvollziehen, denn ain Wake via PCIe durchaus geht, aber ist halt so.



    Nun ist die Frage:

    Was ist die Alternative?


    Einfach eine der 1GBit Leitungen nehmen?
    Ich hab irgendwie nen Knoten im Hirn, denn das selbe Gerät über 2 LAN Verbindungen ins selbe Subnetz ist doch nicht soooo der Brüller, oder kann ich der QNAP irgendwie beibringen, die Netzwerkkarte einfach nicht zu verwenden, so dass ich die nur für WOL nutzen kann?

    Ich hätte noch ein anderes Subnetz über das die ganzen Management Sachen laufen, aber das wird - um eben Zugriff auf die Infrastruktur zu haben - geroutet und spätestens dann ist die QNAP wieder auf 2 "Wegen" erreichbar.

    Wie gesagt: Knoten im Hirn.

    S.

  • Nimm doch einen (1GbE)WOL-LAN Port vom NAS (sofern noch frei) und verbinde diesen Port zusätzlich mit dem 10GbE Switch. Da WOL eine Multicast Message ist, sollte ein WOL zum Switch seinen Weg auch über den (1GbE)WOL-Port zum NAS finden. Dann von einem PC im (10GbE)LAN die MAC vom (1GbE)WOL-Port des NAS senden. In der Theorie sollte das funktionieren - ausprobiert hab ich das nicht. ;)

  • GBit Port ins Management VLAN und alles andere über 10G rein und raus.

    Fertig.


    Wenn du aber Netzfremd ans Management ran willst, dann könnte es nach Verhalten von QTS mit dem 10G Antworten, da könnte eine NAT IP aus dem Management Netz helfen, die deine Source IP umschreibt und dann muss das NAS mit der GBit Karte im Management VLAN antworten.

  • Was meinst du mit

    "Wenn du aber Netzfremd ans Management ran willst, dann könnte es nach Verhalten von QTS mit dem 10G Antworten,"

    Da hab ich nen Knoten im Hirn.

    Also das mit den 2IPs sollte tun.

    Wichtig nur:
    NETBIOS aus denn sonst gibts da Proböleme....wber wer nutzt das schon. Ich hab nen DNS und darüber kann ich die sauber trennen.

    S.

  • Wenn QTS mit 2 verschiedenen Netzen aktiv ist und eine Anfrage auf GBit rein kommt, der anfragenden Client aber aus einem anderen Netz das QTS anspricht, dann könnte QTS über die Default Route antworten.


    Ist dann eine Firewall dazwischen wird das wegen asymmetrischem Routing mit deny enden.


    GBit 192.168.1.11

    1G: 192.168.2.11


    Client VPN: 192.168.4.1


    Dann würde das wie folgt aussehen:

    192.168.4.1

    192.168.1.1

    192.168.1.11

    192.168.2.11

    192.168.2.1 -> GW ist jetzt Firewall dann deny weil kein state


    Würde QTS aber mit dem strong host Modell auf dem GBit antworten sieht es wie folgt aus.

    192.168.4.1

    192.168.1.1

    192.168.1.11

    192.168.1.1

    192.168.4.1 -> Client bekommt die Antwort

  • Okay jetzt versteh ich was Du meinst ;)
    Stand da etwas auf dem Schlauch sorry.

    Hmm das wäre aber ein sehr seltsames Verhalten, denn dann würde ja eine multihomed NAS nicht funktionieren wenn eine Anfrage aus dem 192.168.4.x, das auf nem Netz 192.168.1.x reinkommt auf dem Netz 192.168.2.x beantortet wird, nur weil dieses Netz das Default Gateway beinhaltet.

    Da würde ja wie gesagt keine multihomed Applikation funktionieren oder hab ich da nen Denkfehler?
    Kann ja durchaus sein, dass zwischen diesen beiden Netzen kein Routing stattfindet und so jegliche Kommunikation unmöglich ist - mal ganz unabhängig von der FW und dem asymmetrischen Routing.


    S.

  • Hält sich QTS an das Strong Host Model, dann gehen alle Anfragen aus dem Interface raus, auf dem sie rein gekommen sind.


    Macht QTS das nicht, sondern geht nach Routing Tabelle für das Ziel, dann geht alles was auf dem GBit rein kommt und dessen Quell IP ungleich dem Netz vom GBit Port ist über den 10G Link raus.


    Daher testet man so etwas immer, wenn man das aufbaut, denn Theorie ist gut, aber in der Praxis läuft das eine oder andere System dann anders als zuvor vom Marketing versprochen.

  • OKay dann werde ich das mal testen.


    Aber nochmal ne blöde Frage:

    Würde dann ein multihomed NAS überhaupt funktionieren, wenn QTS nach Weak Host Model operiert?

  • Im gleichen Netz und über einen Router ja, über Netzgrenzen und eine Firewall die statefull arbeitet nicht.


    Aber das haben wenige und daher ist eine klare Aussage nicht zu treffen, da es auch immer nur für das Modell mit der Firmware zutreffen würde.

  • Da bin ich mal gespannt wenn ich das am WE teste.
    An dem Standort an dem die NAS steht habe ich dann 2 Netze.
    Einmal 10.72.30.0/24 fürs Netz an sich --> Da ist der 10 GBit Port drin

    Dann 10.72.40.0/24 als Management LAN (1GBit)


    Von einem anderen Standort greife ich aus dem Netz 10.72.10.0/24 per VPN auf die beiden Netze zu.

    Der VPN Router macht das Routing.

    Bin gespannt ob das tut.

    S.

  • Das kann funktionieren, je nach Netzwerktopologie und Routing-Konfiguration. Die Chancen sind eigentlich relativ gut.

    • Verbindungen, die auf dem gemäß Routingtabelle "richtigen" Interface ankommen (das heißt: auf dem, über das die Antwortpakete an die Quell-IP-Adresse laut Routingtabelle geschickt werden sollen) funktionieren auf jeden Fall.
    • Damit funktionieren insbesondere alle Verbindungen von Clients, die überhaupt nur eines der Interfaces des NAS erreichen. In vielen Topologien trifft das für alle oder mindestens für die meisten Clients zu.
    • Verbindungen, die auf dem "falschen" Interface ankommen, funktionieren ebenfalls, solange nicht auf dem Rückweg eine "stateful" Firewall dazwischensteht, die Antwortpakete von Verbindungen, deren three way handshake sie nicht gesehen hat, blockt. Asymmetrisches Routing ist ja nicht verboten, sondern im Internet sogar gang und gäbe.
    • Solltest du eine "stateful" Firewall im Netz haben, müsstest du bei Clients, die mehrere Interfaces des NAS erreichen können, sicherstellen, dass sie das "richtige" Interface ansprechen, indem du als Zieladresse die Adresse des Interfaces benutzt, auf das die Routingtabelle des NAS für die Quelladresse dieses Clients zeigt.
    • Im häufigsten Fall, dass du nur eine Default-Route hast, heißt das schlicht, dass Clients in Netzen, in denen das NAS ein Interface hat, immer dieses Interface ansprechen sollten, und alle anderen immer das Interface, über das die Default-Route läuft.

    Edit: Das bezog sich auf die Frage von 20:32 Uhr. Während ich an der Antwort feilte, kamen schon wieder zwei Beiträge dazwischen.

  • Ja aber das kann man mit einem Source NAT vom VPN Netz bei Zugriff auf die NAS IP im Management Netz austricksen.

    Da würde dann die Source IP durch die.9 im gleiche Netz ersetzt und das NAS kann dann nicht anders als mit dem Management Adapter zu antworten.

  • Hey,

    • Solltest du eine "stateful" Firewall im Netz haben, müsstest du bei Clients, die mehrere Interfaces des NAS erreichen können, sicherstellen, dass sie das "richtige" Interface ansprechen, indem du als Zieladresse die Adresse des Interfaces benutzt, auf das die Routingtabelle des NAS für die Quelladresse dieses Clients zeigt.

    Ich müsste mich schwer täuschen, aber der Traffic der über das VPN im Management LAN läuft wird ja in der FW des Routers (LANCOM) entsprechend behandelt und wird in den korrekten Tunnel geschoben. mWn steuert die FW den VPN traffic da anders um.

    Dennoch find ich den Satz irgendwie seltsam....ich kenn die Routingtabelle die in der NAS ist ja garnicht oder meinst Du, dass ich dort statische Routen definieren muss?
    Und vor allem:
    Ich möchte von dem Rechner aus (nennen wir ihn mal Admin-PC) sowohl das Management LAN erreichen, als auch im "normalen" Netz Teilnehmer sein.

    Bei den WIN2019 VirtualisierungsHosts habe ich das ja genau so: Das Blech hat mehrere IPs und je nachdem welche ich anspreche, läuft der Traffic über das entsprechende Interface,
    Aber das ist ja wieder die Sache mit strong host, die bei Linox ja scheinbar anders ist ;)

    Im häufigsten Fall, dass du nur eine Default-Route hast, heißt das schlicht, dass Clients in Netzen, in denen das NAS ein Interface hat, immer dieses Interface ansprechen sollten, und alle anderen immer das Interface, über das die Default-Route läuft.

    Okay. Ist noch früh...aber das versteh ich offen gesagt nicht.
    Ja ich habe nur eine Default Route...und was sollen nun die Clients machen ?

    a) User Rechner
    Es gibt Clients die normalerweise nur das "User-Netz" brauchen --> Trivial...nur die Adresse der NAS in dem User-Netz ansprechen.a
    b) lokale Management Rechner
    Wenn ich vor Ort bin, hänge ich ja erstmal im Usernetz.
    Damit ich nun auf das Management Netz zugreifen kann, habe ich für Rechner, die als Management Rechner erlaubt sind, Routen ins Management Netz (oder wahlweise eine zwete IP der NIC zugewiesen).
    Und je nachdem, welches Netzwerk ich anspreche kommt - zumindest bei WIN Rechnern - der Verkehr über das richtige Interface.

    c) entfernte Management Rechner

    Bei Remotezugriff übers VPN gibt es von meinem Rechner aus Routen in die o.g. Netze.

    Und auch hier spreche ich momentan schlichtweg die verschiedenen Subetze an.


    Ist es das was Du meinst?




    Sorry wegen der vielen - für euch bestimmt dummen - Fragen, aber bisher waren meine Anwendungsszenarien so, dass ich Windows Systeme hatte und bei denen hat es immer so funktioniert, wie man es erwartet.

    S.

  • Ich müsste mich schwer täuschen, aber der Traffic der über das VPN im Management LAN läuft wird ja in der FW des Routers (LANCOM) entsprechend behandelt und wird in den korrekten Tunnel geschoben. mWn steuert die FW den VPN traffic da anders um.

    Ja. Dieses Steuern des Traffic nennt man Routing. Deswegen heißt das Ding Router. Die Eingangsgröße dafür ist die Zieladresse des Datenpakets, das transportiert werden soll. Wenn du die IP-Adresse des NAS im Netz 10.72.30.0/24 als Ziel angibst, schickt der Router es in das 10-GBit-LAN. Wenn du die IP-Adresse des NAS im Netz 10.72.40.0/24 als Ziel angibst, schickt der Router es in das Management-LAN.

    Dennoch find ich den Satz irgendwie seltsam....ich kenn die Routingtabelle die in der NAS ist ja garnicht oder meinst Du, dass ich dort statische Routen definieren muss?

    Nein, umgekehrt. Wenn du statische Routen definiert hättest, müsstest du die an dieser Stelle berücksichtigen. Wenn du die Routingtabelle nicht kennst, hast du ziemlich sicher nur eine Defaultroute. Das macht es einfacher. Lass es so.

    Und vor allem:
    Ich möchte von dem Rechner aus (nennen wir ihn mal Admin-PC) sowohl das Management LAN erreichen, als auch im "normalen" Netz Teilnehmer sein.

    Was genau willst du da erreichen? Sprichst du bestimmte Dienste des NAS vom Admin-PC aus immer auf dem 10Gig-Interface an und andere immer auf dem Admin-interface? Oder gibt es Gründe, warum du denselben Dienst einmal auf dem 10Gig-Interface und einmal auf dem Admin-Interface ansprechen willst?



    Bei den WIN2019 VirtualisierungsHosts habe ich das ja genau so: Das Blech hat mehrere IPs und je nachdem welche ich anspreche, läuft der Traffic über das entsprechende Interface,
    Aber das ist ja wieder die Sache mit strong host, die bei Linox ja scheinbar anders ist ;)

    Das ist auch bei Linux so. Die Strong-Host-Sache betrifft nur die Antwortpakete, die das NAS an den Admin-PC zurückschickt. Da kann Linux optimieren. Wenn das NAS anhand der Routingtabelle zu dem Schluss kommt, dass die Antwortpakete über das andere Interface schneller ans Ziel kommen, schickt es sie dort raus. Die Strong-Host-Option verbietet ihm das und zwingt es dazu, die Antwort über dieselbe Schnittstelle rauszuschicken, über die die Anfrage reinkam.



    Mod: Unnötiges Direktzitat gekürzt! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    Okay. Ist noch früh...aber das versteh ich offen gesagt nicht.

    Es geht nicht darum, welches Netz die Clients brauchen, sondern in welchem sie selber stehen.

    Zu a) Wenn diese Clients im selben Adressbreich 10.72.30.0/24 stehen wie das 10Gig-Interface des NAS, dann sollten sie die Adresse des 10Gig-Interfaces ansprechen.

    Zu b) Wenn so ein lokaler Management-Rechner im 10Gig-Netz steht, also eine Adresse im Bereich 10.72.30.0/24 steht, sollte er die Adresse des 10Gig-Interfaces ansprechen. Steht er im Management-Netz, hat also eine Adresse im Bereich 10.72.40.0/24, dann sollte er die Adresse des 1Gig-Interfaces ansprechen.

    Zu c) Das ist der zweite Fall meines letzten Aufzählungspunktes. Ein Client, der kein Interface im selben Netz mit einem der Interfaces des NAS hat. Die Info, die mir an dieser Stelle fehlt, ist auf welches Interface die Default-Route des NAS zeigt. Geht die ins 10Gig-Netz oder ins Admin-Netz?


    Aber nochmal: das alles spielt nur eine Rolle, wenn dein Router eine stateful firewall eingebaut hat, die mit asymmetrischem Routing nicht zurechtkommt. Ist das nicht der Fall, dann wird es "einfach so" funktionieren und all das Ausklamüsern von Routen, Netzen und Interfaces ist nicht nötig.

  • hi.. soory, hab hier nicht alles gelesen..

    warum nicht zwei lan Kabel Anschlüsse. eine davon 1 Gb (mit IP Adresse) da kannst du dann NAS wecken!

  • Hi,

    also zum einen : NAS hat die Default Route ins 10er Netz


    Nun zu den Fragen "warum will der sowas" ;)

    a) Fehlerfall:
    Normalerweise spreche ich das NAS über das 10Gbit Netz an.
    Wenn aber das ausfällt , dann möchte ich immer noch drauf kommen. Deshalb die zweite LAN Leitung, die nur in dem Fall zum Einsatz kommt.


    b) WOL

    10GBit unterstützt kein WOL, von daher brauch ich einen der 1G Ports zum aufwecken


    S,

  • ja ich wusste vorher, dass die 10GBit Karten kein WoL können.

    So ganz allgemein stimmt das nicht.

    In TS-653D kann eine QXG-10G1T WOL. Eine Mellanox ConnectX-3 hingegen nicht.

  • Ich habe die "originale" QXG-10G2TB in einer TVS 871 und da findich es schon etwas "schade" wenn man da kein WOL implementiert...

    Egal ist so,.,..

    S.

  • NAS hat die Default Route ins 10er Netz

    Wunderbar. Dann einfach das NAS immer über seine 10G-Adresse ansprechen, sollte funktionieren.

    Normalerweise spreche ich das NAS über das 10Gbit Netz an.
    Wenn aber das ausfällt , dann möchte ich immer noch drauf kommen. Deshalb die zweite LAN Leitung, die nur in dem Fall zum Einsatz kommt.

    Das wird dann aber nur von einem direkt im 1G-Netz angeschlossenen Admin-PC aus funktionieren, nicht über das VPN. Für das VPN würde dem NAS bei Ausfall des 10G-Netzes die Rückroute fehlen. Da gibt es zwei Abhilfemöglichkeiten:

    1) Profi-Lösung: Routingprotokoll aufsetzen. Dann wird die 10G-Adresse des NAS bei Ausfall des 10G-Netzes automatisch über das 1G-Netz geroutet. Ok, ist für deinen Fall vielleicht Overkill, aber erwähnt wollte ich es doch haben. ;)

    2) Redundanz für Arme: Auf dem NAS eine zweite Default-Route mit größerer Metrik ins 1G-Netz setzen. Die greift dann nur, wenn das 10G-Netz weg ist. Dann musst du halt wenn das 10G-Netz ausfällt explizit die 1G-Adresse des NAS ansprechen.


    10GBit unterstützt kein WOL, von daher brauch ich einen der 1G Ports zum aufwecken

    Das ist unproblematisch. WOL braucht keine Rückroute. Sprich einfach explizit die IP-Adresse des 1G-Ports an.

  • Hey zusammen,

    läuft jetzt ganz gut.
    Danke für die Unterstützung.


    S.