Verständnisfrage Mikrotik RouterOS ab 6.41 Hardware offloading
Hallo zusammen,
ich habe mir einen Mikrotik Router vom Typ RB3011UiAS-RM gekauft.
Warum gerade diese Modell? Schlicht und einfach, weil es mir ausreichend
Gigabit Ports bietet und in mein 19 Zoll Rack passt.
Ich habe mich nun bereits seit Tagen in die Materie eingelesen, mir Tutorials (pascom Brüder)
angesehen und auch die Originaldoku studiert.
Ich denke, das meiste ist mir klar, was ich nicht so ganz verstehe, bzw. mir unklar ist:
Das Gerät hat 2 Switch Chips, jeder Chip ist mit 2x Gbit intern an die CPU angebunden, soweit so gut.
Im hier viel zitierten Tutorial, dem ich zur Einrichtung meines Heimnetzes auch gefolgt bin, wird
alles über eine Bridge realisiert. D.h. Es werden Bridge Ports konfiguriert, Vlans zugewiesen usw.
Wenn ich das richtig verstehe ist das aber alles in Software realisiert, oder? Heißt es belastet die CPU,
aber VLAN filtering ist doch auf Layer2 eben und könnte doch Theoretisch von den Switch Chips durchgeführt werden?
Vielleicht irre ich auch, wunderte mich nur, dass Hardware offloading nicht auswählbar war.
Ich möchte wie im Tutorial beschrieben mein Netz in mehrere Segmente unterteilen, wie sicherlich die meisten.
Das RB ist dabei allerdings über einen 2x 1Gbit Trunk an einen HP 1810-24G Switch angebunden. Von dort aus geht es
teilweise direkt an die Endgeräte (Access Ports) bzw. über einen Uplink an einen kleinen 8 Port TP-Link Switch (der auch VLAN versteht).
WLAN usw kommt alles noch - Step Byte Step, ich möchte erstmal nur den Hintergrund verstehen, warum alles über die Bridge
und nicht über die Switch Interfaces geht.
Danke und Grüße
Richard
ich habe mir einen Mikrotik Router vom Typ RB3011UiAS-RM gekauft.
Warum gerade diese Modell? Schlicht und einfach, weil es mir ausreichend
Gigabit Ports bietet und in mein 19 Zoll Rack passt.
Ich habe mich nun bereits seit Tagen in die Materie eingelesen, mir Tutorials (pascom Brüder)
angesehen und auch die Originaldoku studiert.
Ich denke, das meiste ist mir klar, was ich nicht so ganz verstehe, bzw. mir unklar ist:
Das Gerät hat 2 Switch Chips, jeder Chip ist mit 2x Gbit intern an die CPU angebunden, soweit so gut.
Im hier viel zitierten Tutorial, dem ich zur Einrichtung meines Heimnetzes auch gefolgt bin, wird
alles über eine Bridge realisiert. D.h. Es werden Bridge Ports konfiguriert, Vlans zugewiesen usw.
Wenn ich das richtig verstehe ist das aber alles in Software realisiert, oder? Heißt es belastet die CPU,
aber VLAN filtering ist doch auf Layer2 eben und könnte doch Theoretisch von den Switch Chips durchgeführt werden?
Vielleicht irre ich auch, wunderte mich nur, dass Hardware offloading nicht auswählbar war.
Ich möchte wie im Tutorial beschrieben mein Netz in mehrere Segmente unterteilen, wie sicherlich die meisten.
Das RB ist dabei allerdings über einen 2x 1Gbit Trunk an einen HP 1810-24G Switch angebunden. Von dort aus geht es
teilweise direkt an die Endgeräte (Access Ports) bzw. über einen Uplink an einen kleinen 8 Port TP-Link Switch (der auch VLAN versteht).
WLAN usw kommt alles noch - Step Byte Step, ich möchte erstmal nur den Hintergrund verstehen, warum alles über die Bridge
und nicht über die Switch Interfaces geht.
Danke und Grüße
Richard
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 414822
Url: https://administrator.de/forum/verstaendnisfrage-mikrotik-routeros-ab-6-41-hardware-offloading-414822.html
Ausgedruckt am: 16.02.2025 um 21:02 Uhr
10 Kommentare
Neuester Kommentar
Hey Bali,
Zu allererst möchte ich dir zu der Frage gratulieren, als jemand der viel mit MTs zu tun hat und sich nie wirklich mit dem Punkt "SWITCH" in der Winbox zu tun hat, habe ich erstmal vor deinem Text gesessen und mich gefragt "Ja, warum ist das eigentlich so?"![face-smile face-smile](/images/icons/fa/light/face-smile.svg)
Die (für mich offensichtliche) Antwort hat sich mir dann relativ schnell erschlossen, nämlich dass Routerboards primär dafür konzipiert sind, was in ihrem Namen steht: Routing. Wenn du einen MT nehmen würdest, der primär zum Switching gedacht ist, wie z.B. CRS326, könntest du auf das dafür abgestimmte SwOS wechseln.
Nachdem du heute dieses Topic online gestellt hast gehe ich davon aus, dass du am RB3011 die aktuellste Firmware drauf hast (aktuell: 6.43.11). Wenn du dir die Bridge Ports der Hardware Interfaces ansiehst, wirst du bemerken, dass hier die letzte Checkbox im Reiter "General" die Bezeichnung "Hardware Offload" beträgt.
DISCLAIMER: Ich kanns grad nicht ausprobieren, ob das stimmt, ich glaube Bridge Ports von virtuellen Interfaces, wie VLAN-Interfaces, können nicht mit Hardware Offload ausgestattet werden.
Zum Thema CPU Load sei noch zu sagen, dass du bei Bridges, die wirklich nur zum switching gedacht sind, Fast Path bzw. Fast Forward aktivieren kannst.
Wenn diese Option aktiviert ist ist die Interaktion mit der CPU beim Switching minimalst; die Sache sieht beim Routing zwischen VLANs anders aus, aber das ist ohne Einbindung der CPU auch nicht wirklich machbar.
Abschließend kann ich eigentlich nur noch sagen, dass ich bis dato noch kein SoHo-Setup hatte, in welchem ich mit Switching (auch ohne Fast Path) die CPU auch nur annähernd ausgelastet habe. Das einzige Hardware-Upgrade, welches ich mit Mikrotiks wegen Engpässen hatte, war in meinem eigenen Home Office. Ich hatte hier einen RB2011 stehen und 10x IKEv2 Tunnel, welche nicht mehr online gekommen sind, weil die CPU damit nicht mehr zurecht gekommen ist. Hab dieses dann durch einen RB4011 ersetzt.
lG
Zu allererst möchte ich dir zu der Frage gratulieren, als jemand der viel mit MTs zu tun hat und sich nie wirklich mit dem Punkt "SWITCH" in der Winbox zu tun hat, habe ich erstmal vor deinem Text gesessen und mich gefragt "Ja, warum ist das eigentlich so?"
Die (für mich offensichtliche) Antwort hat sich mir dann relativ schnell erschlossen, nämlich dass Routerboards primär dafür konzipiert sind, was in ihrem Namen steht: Routing. Wenn du einen MT nehmen würdest, der primär zum Switching gedacht ist, wie z.B. CRS326, könntest du auf das dafür abgestimmte SwOS wechseln.
Nachdem du heute dieses Topic online gestellt hast gehe ich davon aus, dass du am RB3011 die aktuellste Firmware drauf hast (aktuell: 6.43.11). Wenn du dir die Bridge Ports der Hardware Interfaces ansiehst, wirst du bemerken, dass hier die letzte Checkbox im Reiter "General" die Bezeichnung "Hardware Offload" beträgt.
DISCLAIMER: Ich kanns grad nicht ausprobieren, ob das stimmt, ich glaube Bridge Ports von virtuellen Interfaces, wie VLAN-Interfaces, können nicht mit Hardware Offload ausgestattet werden.
Zum Thema CPU Load sei noch zu sagen, dass du bei Bridges, die wirklich nur zum switching gedacht sind, Fast Path bzw. Fast Forward aktivieren kannst.
Wenn diese Option aktiviert ist ist die Interaktion mit der CPU beim Switching minimalst; die Sache sieht beim Routing zwischen VLANs anders aus, aber das ist ohne Einbindung der CPU auch nicht wirklich machbar.
Abschließend kann ich eigentlich nur noch sagen, dass ich bis dato noch kein SoHo-Setup hatte, in welchem ich mit Switching (auch ohne Fast Path) die CPU auch nur annähernd ausgelastet habe. Das einzige Hardware-Upgrade, welches ich mit Mikrotiks wegen Engpässen hatte, war in meinem eigenen Home Office. Ich hatte hier einen RB2011 stehen und 10x IKEv2 Tunnel, welche nicht mehr online gekommen sind, weil die CPU damit nicht mehr zurecht gekommen ist. Hab dieses dann durch einen RB4011 ersetzt.
lG
Ad VLAN-Verständnis: Ich verstehe genau was du meinst, ich habe meine ersten VLAN Erfahrungen damals mit einem HP1910 und TP-Link SG3424 gemacht und war da auch etwas überfordert. Wenn es dir beim Verständnis hilft: RouterOS legt mit dem VLAN Interface sowohl das VLAN auf dem entsprechenden Port an als auch das VLAN-Interface, welches das VLAN Routing-fähig macht. Das VLAN-Interface kennst du ja bereits vom HP1810. Das was so wirklich einzigartig ist für Mikrotik (meiner Meinung nach) ist die Tatsache, dass die selbe VLAN-ID an jedem Port definiert sein kann, die entsprechenden Teilnehmer des VLANs nicht miteinander kommunizieren können, solange sie nicht in einer gemeinsamen Bridge sind. Ich hatte tatsächlich schon einmal einen Fall, in dem ich diese Funktionalität gebraucht habe.
RouterOS ist ein sehr direktes Betriebssystem und vergibt keine Fehler... Es wird nicht gefragt, ob du dir sicher bist, dass du diese Interfaces löschen willst; es geht einfach davon aus, dass du weißt was du tust![face-smile face-smile](/images/icons/fa/light/face-smile.svg)
Einziges Sicherheitsnetz ist dabei der Safe-Mode, der sich sowohl als Segen als auch als Fluch präsentiert.
Anyways, zu deiner Konfig, damit die VLANs nicht munter untereinander herum routen würde ich folgendes machen:
1.) Als allererste Regel würde ich ein allgemeines INPUT ALLOW setzen für Anfragen aus allen internen VLANs. Damit kannst du sicher gehen, dass du dich im Zuge deiner Arbeiten auf der Firewall nicht selbst aussperrst
2.) Als zweites würde ich das Forwarding ZWISCHEN den VLANs abdrehen. Nachdem ich davon ausgehe, dass es auch zu asymetrischen Routingberechtigungen kommen kann/soll (VLAN A kann auf B zugreifen aber umgekehrt nicht) habe ich hier auch Connection-States berücksichtigt:
Wenn du die Option Connection-state weglässt ist eine asymetrische Berechtigungsvergabe nicht möglich
3.) Als letztes würde ich für jedes VLAN, dass auf ein bestimmtes anderes zugreifen kann, ALLOW-Regeln basteln. Beispiel: VLAN 20 auf VLAN 30 und vice versa:
Wichtig ist hier grundsätzlich, dass jedes VLAN welches auf ein anderes zugreifen können soll auch eine entsprechende Allow-Regel hat, da wir mit der Regel genannt in 2.) alle Verbindungen zwischen den VLANs, wo keine etablierte Verbindung bestand, droppen.
4.) Sortieren der Regeln! Grundsätzlich gilt, je weiter oben eine Regel in der Liste steht, desto höher ist die Priorität. Für ein Paket bzw. eine Verbindung kann auch immer nur eine Regel treffen. Hast du irgendwo eine ACCEPT Regel hinter einer DROP-Regel angebracht, dann wird die ACCEPT-Regel nie treffen. Ausnahmen bestätigen natürlich die Regel ;)
Also: Die Regel, die dafür sorgt, dass du aus allen VLANs auf deinen Router kommst muss an oberster Stelle sein; danach kommen die VLAN ACCEPT Regeln und am Schluss kommt dann die Regel in der all der übrige Traffic gedroppt wird.
Zum Thema IP Subnetze würde ich noch vorschlagen ein wenig zu streamlinen. Ich weiß nicht ob du das Ganze nur zum Spass an der Freud' machst oder ob das auch für dich eine Möglichkeit sein soll um die Materie kennenzulernen und eventuell auch irgendwann produktiv zu nutzen.
Wenn ersteres der Fall, dann ignoriere meine folgenden Zeilen ganz einfach![face-smile face-smile](/images/icons/fa/light/face-smile.svg)
Im zweiten Fall empfehle ich dir zwei Maßnahmen:
1.) Wenn es sich um eine (größtenteils) statische Installation handelt, in der nicht damit zu rechnen ist, dass viele zusätzliche IP Endgeräte hinzukommen, dann lass zwischen deinen Subnetzen keinen Leerraum. Anstatt in Zehnerschritten zu gehen würde ich kleiner Schritte machen:
Der Grund dafür ist relativ einfach: Wenn du Regeln zusammenfassen möchtest musst du für diese Regeln nicht nur die Bereiche definieren, in denen du tatsächlich IP Adressen nutzt sondern auch all die leeren Adressbereiche, die du nicht nutzt.
Beispiel:
VLAN 20 und 30 sollen auf VLAN 50 zugreifen können, es soll dafür nur eine Regel definiert werden.
In deiner Konfiguration würde das dann so aussehen:
192.168.16.0/20 beinhaltet alle IP Adressen von 192.168.16.0 bis 192.168.31.255
192.168.50.0/24 beinhaltet ausschließlich 192.168.50.0 bis 192.168.50.255
Mit meinen vorgeschlagenen Netzen würde die Regel so aussehen:
192.168.20.0/23 beinhaltet alle Adressen von 192.168.20.0 bis 192.168.21.255
Damit sind keine unbenutzten IP Subnetz-Blöcke in der Allow-Rule enthalten.
Wie oben geschrieben, ist im Home-Bereich eher eine kosmetische Natur, wenn man jedoch mit größeren Netzen zu tun hat sicherlich nicht schlecht, sich so etwas von Anfang an anzueignen![face-smile face-smile](/images/icons/fa/light/face-smile.svg)
Eine weitere Möglichkeit um Regeln zusammenzufassen findest du noch in den Adresslisten. Angenommen du bleibst bei deinen IP Subnetzen und möchtest trotzdem die Anzahl der Einzelregeln so klein und effizient wie möglich halten, dann sind Adresslisten dein Freund.
Wenn wir das Beispiel von vorhin wieder aufgreifen, VLAN20 + 30 sollen auf 50 zugreifen dürfen, dann könnte dies auch so geregelt werden:
Zuerst werden Einträge in die Adresslisten geschrieben:
Dann wird eine Regel erstellt:
Wenn du später mal draufkommst, dass z.B. VLAN40 ebenfalls Zugriff auf VLAN50 haben soll, dann kann der Zugriff über einen zusätzlichen Adresslisten-Eintrag ermöglicht werden.
Abschließender Kommentar zur Firewall:
Ich habe in diesem Post bewusst auf die Firewall Konfiguration für das Internet-Interface verzichtet, nachdem es hier, je nach Zugriffstechnologie, unterschiedliche Konfigurationen zu beachten gibt. Mit der von dir geposteten Konfig und den von mir in diesem Post beschriebenen Möglichkeiten würde ich den Tik auf gar keinen Fall ins Internet hängen. Da müssen unbedingt noch ein paar Regeln vorher gemacht werden bevor der im Internet sicher ist![face-smile face-smile](/images/icons/fa/light/face-smile.svg)
lG
Areanod
RouterOS ist ein sehr direktes Betriebssystem und vergibt keine Fehler... Es wird nicht gefragt, ob du dir sicher bist, dass du diese Interfaces löschen willst; es geht einfach davon aus, dass du weißt was du tust
Einziges Sicherheitsnetz ist dabei der Safe-Mode, der sich sowohl als Segen als auch als Fluch präsentiert.
Anyways, zu deiner Konfig, damit die VLANs nicht munter untereinander herum routen würde ich folgendes machen:
1.) Als allererste Regel würde ich ein allgemeines INPUT ALLOW setzen für Anfragen aus allen internen VLANs. Damit kannst du sicher gehen, dass du dich im Zuge deiner Arbeiten auf der Firewall nicht selbst aussperrst
/ip firewall filter add chain=input action=accept comment="Allow access INPUT from all VLANs" src-address=192.168.0.0/16 place-before=0
2.) Als zweites würde ich das Forwarding ZWISCHEN den VLANs abdrehen. Nachdem ich davon ausgehe, dass es auch zu asymetrischen Routingberechtigungen kommen kann/soll (VLAN A kann auf B zugreifen aber umgekehrt nicht) habe ich hier auch Connection-States berücksichtigt:
/ip firewall filter add chain=forward action=drop comment="Drop all cross-VLAN traffic" src-address=192.168.0.0/16 dst-address=192.168.0.0/16 connection-state=new,invalid,untracked
3.) Als letztes würde ich für jedes VLAN, dass auf ein bestimmtes anderes zugreifen kann, ALLOW-Regeln basteln. Beispiel: VLAN 20 auf VLAN 30 und vice versa:
/ip firewall filter add chain=forward action=accept comment="VLAN20 traffic to VLAN30" src-address=192.168.20.0/24 dst-address=192.168.30.0/24
/ip firewall filter add chain=forward action=accept comment="VLAN30 traffic to VLAN20" src-address=192.168.30.0/24 dst-address=192.168.20.0/24
4.) Sortieren der Regeln! Grundsätzlich gilt, je weiter oben eine Regel in der Liste steht, desto höher ist die Priorität. Für ein Paket bzw. eine Verbindung kann auch immer nur eine Regel treffen. Hast du irgendwo eine ACCEPT Regel hinter einer DROP-Regel angebracht, dann wird die ACCEPT-Regel nie treffen. Ausnahmen bestätigen natürlich die Regel ;)
Also: Die Regel, die dafür sorgt, dass du aus allen VLANs auf deinen Router kommst muss an oberster Stelle sein; danach kommen die VLAN ACCEPT Regeln und am Schluss kommt dann die Regel in der all der übrige Traffic gedroppt wird.
Zum Thema IP Subnetze würde ich noch vorschlagen ein wenig zu streamlinen. Ich weiß nicht ob du das Ganze nur zum Spass an der Freud' machst oder ob das auch für dich eine Möglichkeit sein soll um die Materie kennenzulernen und eventuell auch irgendwann produktiv zu nutzen.
Wenn ersteres der Fall, dann ignoriere meine folgenden Zeilen ganz einfach
Im zweiten Fall empfehle ich dir zwei Maßnahmen:
1.) Wenn es sich um eine (größtenteils) statische Installation handelt, in der nicht damit zu rechnen ist, dass viele zusätzliche IP Endgeräte hinzukommen, dann lass zwischen deinen Subnetzen keinen Leerraum. Anstatt in Zehnerschritten zu gehen würde ich kleiner Schritte machen:
- 192.168.20.x VLAN20
- 192.168.21.x VLAN30
- 192.168.22.x VLAN40
- 192.168.23.x VLAN50
Der Grund dafür ist relativ einfach: Wenn du Regeln zusammenfassen möchtest musst du für diese Regeln nicht nur die Bereiche definieren, in denen du tatsächlich IP Adressen nutzt sondern auch all die leeren Adressbereiche, die du nicht nutzt.
Beispiel:
VLAN 20 und 30 sollen auf VLAN 50 zugreifen können, es soll dafür nur eine Regel definiert werden.
In deiner Konfiguration würde das dann so aussehen:
/ip firewall filter add chain=forward action=accept src-address=192.168.16.0/20 dst-address=192.168.50.0/24
192.168.16.0/20 beinhaltet alle IP Adressen von 192.168.16.0 bis 192.168.31.255
192.168.50.0/24 beinhaltet ausschließlich 192.168.50.0 bis 192.168.50.255
Mit meinen vorgeschlagenen Netzen würde die Regel so aussehen:
/ip firewall filter add chain=forward action=accept src-address=192.168.20.0/23 dst-address=192.168.50.0/24
192.168.20.0/23 beinhaltet alle Adressen von 192.168.20.0 bis 192.168.21.255
Damit sind keine unbenutzten IP Subnetz-Blöcke in der Allow-Rule enthalten.
Wie oben geschrieben, ist im Home-Bereich eher eine kosmetische Natur, wenn man jedoch mit größeren Netzen zu tun hat sicherlich nicht schlecht, sich so etwas von Anfang an anzueignen
Eine weitere Möglichkeit um Regeln zusammenzufassen findest du noch in den Adresslisten. Angenommen du bleibst bei deinen IP Subnetzen und möchtest trotzdem die Anzahl der Einzelregeln so klein und effizient wie möglich halten, dann sind Adresslisten dein Freund.
Wenn wir das Beispiel von vorhin wieder aufgreifen, VLAN20 + 30 sollen auf 50 zugreifen dürfen, dann könnte dies auch so geregelt werden:
Zuerst werden Einträge in die Adresslisten geschrieben:
/ip firewall address-list add list="Zugriff auf VLAN50" address=192.168.20.0/24 comment="VLAN20"
/ip firewall address-list add list="Zugriff auf VLAN50" address=192.168.30.0/24 comment="VLAN30"
Dann wird eine Regel erstellt:
/ip firewall filter add chain=forward src-address-list="Zugriff auf VLAN50" dst-address=192.168.50.0/24 comment="Allow access to VLAN50"
Abschließender Kommentar zur Firewall:
Ich habe in diesem Post bewusst auf die Firewall Konfiguration für das Internet-Interface verzichtet, nachdem es hier, je nach Zugriffstechnologie, unterschiedliche Konfigurationen zu beachten gibt. Mit der von dir geposteten Konfig und den von mir in diesem Post beschriebenen Möglichkeiten würde ich den Tik auf gar keinen Fall ins Internet hängen. Da müssen unbedingt noch ein paar Regeln vorher gemacht werden bevor der im Internet sicher ist
lG
Areanod
Sonos, BÄH ![face-smile face-smile](/images/icons/fa/light/face-smile.svg)
Wenn du Sonos Geräte ohne so eine zentrale Steuereinheit betreibst, also die ganz normalen Stand-Alone Home-Anwendungs-Dinger (<- das ist ein Fachausdruck!) und du möchtest die dann übers WLAN steuern, dann wirst du nicht drum rum kommen die Geräte im selben VLAN zu halten wie dein WLAN sein wird.
Der einfache Grund dabei ist, dass du in der (mir bekannten) Sonos App nicht angeben kannst, mit welcher IP die App sprechen soll sondern alle verfügbaren Geräte im aktuellen Subnetz verfügbar sind, indem via Broadcast nach den Dingern (Fachausdruck #2) gesucht wird.
Mein Wissen diesbezüglich ist schon veraltet (2015), eventuell hat sich hier schon etwas getan im Sinne eines Admin-freundlicheren Verhaltens, ich musste bei einem meiner Kunden jedoch die 20 Sonos-Komponenten in sein WLAN hängen.
EDIT: Hab leider nicht genau genug gelesen, du hast also eh einen Controller, der die einzelnen Sonos Instanzen steuert? Wenn das stimmt und du die Instanzen auch aus anderen Subnetzen steuern kannst, dann is alles gut. IGMP Erfahrungen habe ich in dem Sinne keine.
EDIT #2: Hab gerade gesehen, dass Aqui auch ein super Tutorial gepostet hat, findet sich hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
lG
Areanod
Wenn du Sonos Geräte ohne so eine zentrale Steuereinheit betreibst, also die ganz normalen Stand-Alone Home-Anwendungs-Dinger (<- das ist ein Fachausdruck!) und du möchtest die dann übers WLAN steuern, dann wirst du nicht drum rum kommen die Geräte im selben VLAN zu halten wie dein WLAN sein wird.
Der einfache Grund dabei ist, dass du in der (mir bekannten) Sonos App nicht angeben kannst, mit welcher IP die App sprechen soll sondern alle verfügbaren Geräte im aktuellen Subnetz verfügbar sind, indem via Broadcast nach den Dingern (Fachausdruck #2) gesucht wird.
Mein Wissen diesbezüglich ist schon veraltet (2015), eventuell hat sich hier schon etwas getan im Sinne eines Admin-freundlicheren Verhaltens, ich musste bei einem meiner Kunden jedoch die 20 Sonos-Komponenten in sein WLAN hängen.
EDIT: Hab leider nicht genau genug gelesen, du hast also eh einen Controller, der die einzelnen Sonos Instanzen steuert? Wenn das stimmt und du die Instanzen auch aus anderen Subnetzen steuern kannst, dann is alles gut. IGMP Erfahrungen habe ich in dem Sinne keine.
EDIT #2: Hab gerade gesehen, dass Aqui auch ein super Tutorial gepostet hat, findet sich hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
lG
Areanod
Zitat von @bali2006:
Ich habe einen Sonos Connect, der hängt im LAN. Nicht WLAN. Der spannt für die anderen Sonos Lautsprecher ein eigenes Funknetz auf - hab ich zumindest so verstanden. Was ich bisher gelesen habe, gibt es einen IGMP Proxy der diese Broadcasts in andere Netze leiten kann?!?
Ich habe einen Sonos Connect, der hängt im LAN. Nicht WLAN. Der spannt für die anderen Sonos Lautsprecher ein eigenes Funknetz auf - hab ich zumindest so verstanden. Was ich bisher gelesen habe, gibt es einen IGMP Proxy der diese Broadcasts in andere Netze leiten kann?!?
Mhh, das macht so keinen Sinn ;)
Meinst du jetzt, dass die Sonos Lautsprecher über eine eigene Drahtlosverbindung mit dem Controller sprechen oder dass der Controller irgendwie eine eigene Art VLAN generiert?
Wenn der Controller sowieso für eine eigene Verbindung zu den Lautsprecherboxen sorgt, dann nutzt er deine Infrastruktur sowieso nicht auf der Ebene, wo ein IGMP Proxy genutzt werden muss... Entweder er hat eine eigene Art VLAN (es muss kein VLAN im Sinne von 802.11q sein) oder ein WiFi, über welche er mit den Boxen kommuniziert; so oder so berührt er den IGMP Proxy de facto nicht
Zitat von @bali2006:
Derzeit hängt das Ding mit ether1 hinter einem Speedport W724V Typ A - im Routerbetrieb. Ich habe noch eine zweite VDSL Leitung, die derzeit mein
eigentliches produktives Netz mit Internetzugang versorgt, welches hinter einer Fritzbox 4790 hängt - die ich auch so schnell nicht los werde wegen der VOIP Telefonie.
Derzeit hängt das Ding mit ether1 hinter einem Speedport W724V Typ A - im Routerbetrieb. Ich habe noch eine zweite VDSL Leitung, die derzeit mein
eigentliches produktives Netz mit Internetzugang versorgt, welches hinter einer Fritzbox 4790 hängt - die ich auch so schnell nicht los werde wegen der VOIP Telefonie.
Wenn du Routerbetrieb sagst, heißt dass dann, der Tik hat eine Public IP? Wenn ja, schau dass keine Fremdzugriffe aus dem Internet möglich sind.
In meiner Vision, möchte ich meinen FirmenDSL Anschluss für mein Homeoffice exklusiv über ein getrenntes nicht geroutetes VLAN zugänglich machen. D.h. der Firmenlaptop kann nur über diese Leitung raus. Verbindung zu anderen VLANs darf nicht möglich sein. Dennoch könnte ich mir vorstellen, dass privater Netzverkehr über beide Leitungen geloadbalanced wird, allerdings hinsichtlich der Bandbreite begrenzt
Ich habe keine Ahnung, ob das möglich ist.
Yes, das ist alles möglich, Load-Balancing, Bandbreitenbeschränkung (heißt bei Mikrotik Queues) usw. sind mit diesen Dingern machbar
ABER: Ich würde dir schwerstens empfehlen erst noch etwas sattelfester mit RouterOS, den Quirksen und der Scripting Sprache zu werden.
lG