Mikrotik/VLAN - Verständnisfrage

[Simon Moon]

Hi



Nun ist mein MikroTik hEX s angekommen und nach etwas konfigurieren läuft er auch. Bei der Konfiguration fand ich vom Provider nur relativ knappe Infos u.a. Um VLAN10 (802.1q-Verkapselung) zu nutzen, musst du deinen Router konfigurieren (https://www.wingo.ch/de/hilfe/haeufig-gestellte-fragen?open=faq-100067#faq-100067).


Ich bin nun also im WebFig auf Interfaces, hab dort ein VLAN-10 mit der ID 10 erstellt und dieses auf den SFP Port gelegt. Danach unter IP / DHCP Client als Interface VLAN-10 ausgewählt.



Aber was wäre nun der Unterschied wenn ich über Bridge -> VLANS eine VLAN mit der ID 10 erstelle und dann bei tagged Interface den SFP Port angebe? Danach entsprechend als DHCP Client die Bridge nehmen, mach ich da jetzt einen Denkfehler?

[Gast]

In der Regel willst du den WAN-Port nicht als Mitglied in einer Bridge haben, sondern als separates Interface ansprechen. Das verhindert zuverlässig, dass Pakete ohne routing zwischen beiden Netzen leaken können.
In deinem Fall kommt noch hinzu, dass der Switch Chip des hEX S kein VLAN-Filtering kann. D.h. sobald du auf der Bridge VLAN Filtering aktivierst, verlierst du das Hardware Switching und sämtlicher lokale Ethernet Traffic zwischen den LAN-Ports geht durch die CPU -- mit entsprechenden Geschwindigkeitseinbußen.

[Simon Moon]

In der Regel willst du den WAN-Port nicht als Mitglied in einer Bridge haben, sondern als separates Interface ansprechen. Das verhindert zuverlässig, dass Pakete ohne routing zwischen beiden Netzen leaken können.


Die Trennung zwischen WAN / LAN war dann auch der Grund wieso ich das vorerst mal nur auf den SFP gelegt hab. Aber ich dachte, vll. hätte es Vorteile über die Bridge die mir entgingen, aber scheint wohl eher ein Feature für Switchs zu sein wenn ich das richtig verstehe.



In deinem Fall kommt noch hinzu, dass der Switch Chip des hEX S kein VLAN-Filtering kann. D.h. sobald du auf der Bridge VLAN Filtering aktivierst, verlierst du das Hardware Switching und sämtlicher lokale Ethernet Traffic zwischen den LAN-Ports geht durch die CPU -- mit entsprechenden Geschwindigkeitseinbußen.


Ok, bei einem Router kann ich jetzt noch auf VLAN Filtering verzichten, den externen Traffic kann ich via sourcedst auf ein eigenes Interface legen.

[myMind]

Es ist noch etwas anders beim hexS. Da ist der SFP-Port gar nicht am Switch-Chip angeschlossen. Ist auch für den angedachten Zweck normalerweise nicht notwendig.

https://i.mt.lv/cdn/rb_files/RB760iGS-esw3-190628133359.png


Es hört sich für mich jetzt so an, als ob du vorhast das Netzwerk deines Providers einfach so in dein lokales Netz zu bridgen. Das wäre nicht gut. Vielleicht schreibst Du nochmal, was genau der Plan ist.

Ich würde so beginnen den Router in die Standard-Routingkonfiguration zu versetzen. Also mit NAT und Firewall.
Statt ether1 dann den SFP Port als WAN konfigurieren.
Und letzlich muss Du noch anstelle des "SFP" das "VLAN10 aus SFP" auf das WAN-Interface bekommen. Wobei ich genau Null Ahnung habe wie das geht. Ohne dass ich da wirklich tieferes Wissen habe, wäre das der Plan nach dem ich vorgehen würde.

Falls sich hier niemand mit mehr Wissen findet, im Luxx und bei Administrator.de sind auf jedenfall Leute die sich mit MikroTik gut auskennen. Die springen in der Regel immer darauf an, wenn man seine Konfig mit "hide-sensitive" exportiert und postet.

[Simon Moon]

Es hört sich für mich jetzt so an, als ob du vorhast das Netzwerk deines Providers einfach so in dein lokales Netz zu bridgen. Das wäre nicht gut. Vielleicht schreibst Du nochmal, was genau der Plan ist.




Nein nein, ich bridge schon nichts auf meine public IP. Es wird da lediglich min. zwei getrennte Netze geben - einmal das normale LAN für die Clients und daneben noch eine DMZ für den Server, auf dem einige Services in Linux-Containern laufen.





Ich würde so beginnen den Router in die Standard-Routingkonfiguration zu versetzen. Also mit NAT und Firewall.
Statt ether1 dann den SFP Port als WAN konfigurieren.
Und letzlich muss Du noch anstelle des "SFP" das "VLAN10 aus SFP" auf das WAN-Interface bekommen. Wobei ich genau Null Ahnung habe wie das geht. Ohne dass ich da wirklich tieferes Wissen habe, wäre das der Plan nach dem ich vorgehen würde.





VLAN ist eigentlich ziemlich primitiv, da werden einfach ein paar Byte mit den Werten 0 - 4092 in den Header geklatscht und die kann man dann auf IP Ebene wieder rausfiltern / Sachen mit anstellen. Am längsten hab ich gebraucht, bis ich kapiert hab, DAS ich den Upstream verkapseln muss - Irgendwie dachte ich nämlich, dass das VLAN10 als nur Steuerinterface für Fernseher gebraucht würde.



Etwas mühsam war dann noch, dass mein Provider die DHCP Lease Dauer auf min. 40 Min. setzt und erst nach Ablauf des Lease ein anderes Modem eine IP zugewiesen bekommt - Darum spiel ich am WAN auch grad nicht s ogerne rum ^^

[Gast]

Aber ich dachte, vll. hätte es Vorteile über die Bridge die mir entgingen, aber scheint wohl eher ein Feature für Switchs zu sein wenn ich das richtig verstehe.
Eine Bridge ist nichts anderes als das zusammenswitchen aller angeschlossenen Ports. Das ist also in Switch! Das ist nur dann sinnvoll, wenn du mehrere Ports auf Layer 2 verbinden willst. Die Bridge selber und deren IP Config ist dann der Anschluss der CPU an diesen Switch.
Je nach Konfiguration und Gerät wird das Switching der Pakete von einem Switch Chip erledigt (das geht dann mit wire speed), oder geht komplett über die CPU. Siehe
https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_Hardware_Offloading
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features

Wenn du Ports aus der Bridge heraus nimmst, kannst du diese als separates Interface benutzen. Für sinnvolle Konfigurationen lohnt sich hier immer ein Blick ins Block-Diagramm: in deinem Fall kannst du wie schon erwähnt z.B. SFP1 oder einen der eth Ports ohne Bridge als WAN benutzen und die restlichen eth Ports fürs LAN in der Bridge belassen. Dann hat die CPU jeweils 1 Gbps in Richtung WAN und LAN und LAN-interner Traffic geht über den Switch Chip.

[Simon Moon]

Eine Bridge ist nichts anderes als das zusammenswitchen aller angeschlossenen Ports. Das ist also in Switch! Das ist nur dann sinnvoll, wenn du mehrere Ports auf Layer 2 verbinden willst. Die Bridge selber und deren IP Config ist dann der Anschluss der CPU an diesen Switch.
Je nach Konfiguration und Gerät wird das Switching der Pakete von einem Switch Chip erledigt (das geht dann mit wire speed), oder geht komplett über die CPU. Siehe
https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_Hardware_Offloading
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features

Wenn du Ports aus der Bridge heraus nimmst, kannst du diese als separates Interface benutzen. Für sinnvolle Konfigurationen lohnt sich hier immer ein Blick ins Block-Diagramm: in deinem Fall kannst du wie schon erwähnt z.B. SFP1 oder einen der eth Ports ohne Bridge als WAN benutzen und die restlichen eth Ports fürs LAN in der Bridge belassen. Dann hat die CPU jeweils 1 Gbps in Richtung WAN und LAN und LAN-interner Traffic geht über den Switch Chip.


Das ist soweit eigentlich eingestellt bzw. ich nem an wenn HW Offloading aktiv ist, wird er automatisch auswählen ob er nun eth - switch oder eth - bridge nimmt, je nachdem wohin es geht. Wobei die Anforderungen im LAN sowieso nicht so riesig sind. Momentan hängt der Desktop/Server und der Laptop dran.



Komplexer wird es allenfalls virtuell auf dem Server - dort laufen dann so ein dutzend LXC Container für alle möglichen Dienste, die je nach Service nicht, teilweise oder explizit extern erreichbar sein sollen. Dabei gibts dann erst mal ein separates Subnet für die Container und je nach Bedarf eine feinere Unterteilung per VLAN-Tags. Zumindest taggen sollte auf dem SFP/WAN-Port ja kaum Geschwindigkeit kosten und Filtern kann ich dann ja auf der virtuellen Bridge im Server.



Bei meinem letzten Gebastel mit VMs hatte ich so viele Workarrounds und obskure Konstrukte gewählt, bis mir die Lust verging wegen Kleinigkeiten einen ganzen Rattenschwanz umzukonfigurieren und natürlich nach kurzer Zeit bei der Hälfte der configs nicht mehr wusste was nun wohin überall Einfluss hatte. War ein interessantes Projekt das mir gezeigt hat was so theoretisch alles konfigurierbar ist und das längst nicht alles sinnvoll ist. Das wollte ich diesmal aber vermeiden, einerseits etwa durch die Container mit ihrer eigenen, unabhängigen Konfiguration, andererseits durch vermeiden von weiteren NAT Stufen und solchen Verrenkungen - Ein flexibler Router ist zwar nicht zwingend, macht aber vieles bequemer und einfacher