bali2006
Goto Top

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

Content-Key: 414822

Url: https://administrator.de/contentid/414822

Printed on: April 25, 2024 at 08:04 o'clock

Member: bali2006
bali2006 Feb 07, 2019 at 13:22:15 (UTC)
Goto Top
Anbei noch meine config, die zum einen noch nicht richtig funktioniert, und auch noch nicht vollständig ist, Stichwort Firewall.

# feb/07/2019 14:19:42 by RouterOS 6.43.11
# software id = XXX 
#
# model = RouterBOARD 3011UiAS
# serial number = xxx
/interface bridge add comment="TEST TEST TEST" name=bridge1 vlan-filtering=yes  
/interface ethernet set [ find default-name=ether5 ] mac-address=64:D1:54:17:65:51
/interface vlan add interface=bridge1 name=vlan_20_Entertainment vlan-id=20
/interface vlan add interface=bridge1 name=vlan_30_WLAN vlan-id=30
/interface vlan add interface=bridge1 name=vlan_40_LAN vlan-id=40
/interface vlan add interface=bridge1 name=vlan_50_DEVTEST vlan-id=50
/interface vlan add interface=bridge1 name=vlan_99_ADMIN vlan-id=99
/interface vlan add interface=bridge1 name=vlan_100_EXT vlan-id=100
/interface bonding add mode=802.3ad name=bond_coreswitch slaves=ether4,ether5 transmit-hash-policy=layer-3-and-4
/interface wireless security-profiles set [ find default=yes ] supplicant-identity=MikroTik
/ip pool add name=pool20 ranges=192.168.20.100-192.168.20.200
/ip pool add name=pool30 ranges=192.168.30.100-192.168.30.200
/ip pool add name=pool40 ranges=192.168.40.100-192.168.40.200
/ip pool add name=pool50 ranges=192.168.50.100-192.168.50.200
/ip pool add name=pool1 ranges=192.168.1.100-192.168.1.200
/ip pool add name=pool100 ranges=192.168.100.100-192.168.100.200
/ip pool add name=pool99 ranges=192.168.99.50-192.168.99.60
/ip dhcp-server add address-pool=pool20 disabled=no interface=vlan_20_Entertainment lease-time=2w name=server20
/ip dhcp-server add address-pool=pool30 disabled=no interface=vlan_30_WLAN lease-time=3d name=server30
/ip dhcp-server add address-pool=pool40 disabled=no interface=vlan_40_LAN lease-time=2w name=server40
/ip dhcp-server add address-pool=pool50 disabled=no interface=vlan_50_DEVTEST lease-time=1d name=server50
/ip dhcp-server add address-pool=pool99 disabled=no interface=vlan_99_ADMIN lease-time=15m name=server99
/interface bridge port add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=vlan_20_Entertainment
/interface bridge port add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=vlan_30_WLAN
/interface bridge port add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=vlan_40_LAN
/interface bridge port add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=vlan_50_DEVTEST
/interface bridge port add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=vlan_100_EXT
/interface bridge port add bridge=bridge1 interface=bond_coreswitch
/interface bridge port add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether2 pvid=99
/interface bridge port add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=vlan_99_ADMIN
/interface bridge vlan add bridge=bridge1 tagged=vlan_20_Entertainment,bridge1,bond_coreswitch vlan-ids=20
/interface bridge vlan add bridge=bridge1 tagged=bridge1,vlan_30_WLAN,bond_coreswitch vlan-ids=30
/interface bridge vlan add bridge=bridge1 tagged=bridge1,vlan_40_LAN,bond_coreswitch vlan-ids=40
/interface bridge vlan add bridge=bridge1 tagged=bridge1,vlan_50_DEVTEST,bond_coreswitch vlan-ids=50
/interface bridge vlan add bridge=bridge1 tagged=bridge1,vlan_100_EXT,bond_coreswitch vlan-ids=100
/interface bridge vlan add bridge=bridge1 tagged=bridge1,vlan_99_ADMIN,bond_coreswitch untagged=ether2 vlan-ids=99
/ip address add address=192.168.100.1/24 interface=vlan_100_EXT network=192.168.100.0
/ip address add address=192.168.20.1/24 interface=vlan_20_Entertainment network=192.168.20.0
/ip address add address=192.168.30.1/24 interface=vlan_30_WLAN network=192.168.30.0
/ip address add address=192.168.40.1/24 interface=vlan_40_LAN network=192.168.40.0
/ip address add address=192.168.50.1/24 interface=vlan_50_DEVTEST network=192.168.50.0
/ip address add address=192.168.99.1/24 comment="Admin Port ether2 // VLAN99" interface=vlan_99_ADMIN network=192.168.99.0  
/ip dhcp-client add dhcp-options=hostname,clientid disabled=no interface=ether1
/ip dhcp-server network add address=192.168.20.0/24 dns-server=192.168.20.1 domain=opgenoorth.home gateway=192.168.20.1 netmask=24
/ip dns set allow-remote-requests=yes
/system clock set time-zone-name=Europe/Berlin
Member: areanod
areanod Feb 07, 2019 updated at 15:05:42 (UTC)
Goto Top
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

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
Member: bali2006
bali2006 Feb 07, 2019 at 15:59:58 (UTC)
Goto Top
Vielen Dank für Deine Ausführliche Antwort. Deine Vermutung lässt sich logisch nachvollziehen. Ich habe diesen Thread auch nur eröffnet um sicherzustellen dass ich da nicht vollkommen auf dem Holzweg unterwegs bin.

Ich muss schon sagen, das Gerät gefällt mir eigentlich ganz gut, nur die Logik mit der Bridge will einfach nicht in mein Hirn. Ich habe mich früher schon mal intensiver mit iptables beschäftigt, aber da habe ich keine Bridge in diesem Sinne benötigt. Auch die VLAN Konfiguration ist nicht in allen Punkten selbsterklärend, bzw gewöhnungsbedürftig - wenn auch gefühlt maximal flexibel .. und damit fehleranfällig 😊

Kannst Du vielleicht noch einen kurzen Blick auf meine Konfig werfen?
Wie kann ich verhindern, dass sämtliche VLANs bedingungslos untereinander geroutet werden?

Grüße
Richard
Member: areanod
areanod Feb 07, 2019 at 17:19:47 (UTC)
Goto Top
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

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  
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:
/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   
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
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 face-smile

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

lG
Areanod
Member: bali2006
bali2006 Feb 07, 2019 at 17:30:14 (UTC)
Goto Top
Hi Areanod,

vielen Dank für Deine Ausführliche Antwort.
Ich werde jetzt erstmal ein bisschen Sporteln und mir danach Deine Antwort im Detail ansehen.
Ich vermute, es macht Sinn noch einen kleinen MT Router zu kaufen (das kleinste was es gibt) zum spielen. Denn
wenn ich später im laufenden Betrieb was ander Konfig ändere und das Weibchen kein Sonos oder TV mehr gucken
kann, hängt der Haussegen schief.

Apropo SONOS... ich habe schon gelesen, dass ich dafür das IGMP Proxy paket benötige, damit die Multi-/Broadcasts vom Controller
an die Devices gelangen... hast Du damit zufällig auch Erfahrung. Einfach mal auf das Risiko hin, dass ich diesen Thread
dafür missbrauche face-smile

Grüße
Richard
Member: areanod
areanod Feb 07, 2019 updated at 17:40:53 (UTC)
Goto Top
Sonos, BÄH face-smile

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
Member: bali2006
bali2006 Feb 07, 2019 at 17:50:53 (UTC)
Goto Top
Da habe ich doch fast noch was vergessen..

Zitat von @areanod:

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


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.

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 face-smile Ich habe keine Ahnung, ob das möglich ist.

Grüße
Richard
Member: bali2006
bali2006 Feb 07, 2019 at 20:26:56 (UTC)
Goto Top
Zitat von @areanod:


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.


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?!?
Member: areanod
areanod Feb 08, 2019 at 11:44:36 (UTC)
Goto Top
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?!?

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 face-smile
Member: areanod
areanod Feb 08, 2019 at 11:54:51 (UTC)
Goto Top
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.

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 face-smile 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