May 11, 2020, updated at 19:09:56 (UTC)

3185

Mikrotik: zwei vlans auf einem Port

Hallo zusammen,

ich habe auf meinem RB3011 nach aquis Anleitung (Mikrotik vlan tutorial) mehrere vlans eingerichtet. Jedes vlan hat einen eigenen DHCP-Server. Das funktioniert auch wunderbar.

Nun habe ich einen Linux-Server (ubuntu) und habe auf dessen Netzwerkkarte 2 vlans eingerichtet (vlan50 & 60). Der Server ist am Port ether5 des RB3011 angeschlossen. Ich habe deshalb sowohl beim vlan50 als auch bei vlan60 den ether5 als tagged port angegeben (jeweils neben der bridge und dem vlan selbst). Beide virtuellen Netzwerkkarten erhalten nun eine IP aus dem richtigen vlan (172.20.50.200 & 172.20.60.200) und antworten auch auf pings.

Was ich aber nicht verstehe: welche PVID muss ich beim Bridge-Port ether5 unter dem Reiter vlan eingeben? Und ist als Frame Types "admit only VLAN tagged" richtig? In der Mikrotik-Anleitung (wiki.mikrotik.com/wiki/Manual:Bridge_VLAN_Table) ist ja davon die Rede, dass die PVID für acces-ports genutzt werden. Ein access-port i.S.e. unttagged ports ist es ja aber gerade nicht.

Herzlichen Dank!

Please also mark the comments that contributed to the solution of the article

Content-Key: 571053

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

Printed on: April 27, 2024 at 01:04 o'clock

9 Comments

Latest comment

Linux-Server (ubuntu) und habe auf dessen Netzwerkkarte 2 vlans eingerichtet (vlan50 & 60).

Das hast du auch richtig gemacht wie z.B. hier beschrieben ?!:
Netzwerk Management Server mit Raspberry Pi
Wenn ja gehen wir mal davon aus das die Ubuntu/Debian Seite damit richtig konfiguriert ist.
Um ganz sicher zu gehen kannst du an den Serverport mal einen Wireshark klemmen und checken ob der Server entsprechend getaggte Pakete am Port raussendet:

(Hier mal ein Sniffer Beispiel mit der VLAN ID 14)
Aber deine Aussage das du pingen kannst und alle IP Adressen stimmen belegt ja das du generell alles richtig gemacht hast und es auch sauber funktioniert !!

Was ich aber nicht verstehe: welche PVID muss ich beim Bridge-Port ether5 unter dem Reiter vlan eingeben?

Die PVID bestimmt IMMER in welches VLAN UNgetaggte Pakete an diesem Port geforwardet werden. Sprich also Pakete ohne eine VLAN Information. Das muss das Endgerät egal ob Switch oder Server ja wissen um diese Pakete richtig zuordenen zu können, denn denen fehlt ja jegliche VLAN Information.
Siehe dazu auch HIER was das Thema PVID genau beschreibt.
Bei Debian basierten Linuxen wie Ubuntu und Co. sendet immer das physische Interface selber was die VLANs bedient alle Pakete untagged aus. Wenn also der Linux Port eth1 ist sendet dieses Pakete untagged aus die darauf aufliegenden VLAN Interfaces eth1.10, eth1.20 usw. aber tagged.
Siehe dazu auch das hiesige VLAN Server Tutorial:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Das Ziel VLAN dieser nativen Interface Pakete bestimmst du also auf dem Mikrotik mit der PVID. Am Beispiel oben also wo die Pakete auf Mikrotik Seite hinkommen die das native eth1 Interface des Ubuntu Servers aussendet.

Ein VLAN Switch Trunk, sprich ein Tagged Uplink hat immer ein sog. "Native VLAN" oder oft auch als Default VLAN bezeichnet was bestimmt WO diese UNtagged Pakete hinkommen. Dieses native VLAN ist frei programmierbar über das Setup und steht im Default immer auf dem Default VLAN 1. So auch bei deinem Mikrotik !

Eigentlich eine ganz einfache Logik !

Zitat von @aqui:
Das hast du auch richtig gemacht wie z.B. hier beschrieben ?!:
Netzwerk Management Server mit Raspberry Pi

Nein, mein ubuntu (19.10) läuft in der standard-config mit netplan. Ich habe deshalb das Paket vlan installiert und das Modul mit modprobe in den Kernel geladen. Danach habe ich die Netplan configuration wie folgt angepasst:

# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager
  ethernets:
    eno1:
      dhcp4: true
    enp2s0:
      dhcp4: no
  vlans:
    vlan50:
      id: 50
      link: enp2s0
      dhcp4: true
    vlan60:
      id: 60
      link: enp2s0
      dhcp4: true

Damit haben die virtuellen Interfaces vlan50 und vlan60 die jeweils passenden IP-Adressen erhalten, z.B.:

4: vlan50@enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 68:05:ca:94:84:cf brd ff:ff:ff:ff:ff:ff
    inet 172.20.50.200/24 brd 172.20.50.255 scope global dynamic noprefixroute vlan50
       valid_lft 529sec preferred_lft 529sec

Danke für den Tipp mit Wireshark. Danach versenden die Interfaces keine getaggte Pakete

Der komplette Block "802.1Q Vurtual LAN" fehlt. Warum das so ist, muss ich noch herausfinden.

Bei Debian basierten Linuxen wie Ubuntu und Co. sendet immer das physische Interface selber was die VLANs bedient alle Pakete untagged aus. Wenn also der Linux Port eth1 ist sendet dieses Pakete untagged aus die darauf aufliegenden VLAN Interfaces eth1.10, eth1.20 usw. aber tagged.
Siehe dazu auch das hiesige VLAN Server Tutorial:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Das Ziel VLAN dieser nativen Interface Pakete bestimmst du also auf dem Mikrotik mit der PVID. Am Beispiel oben also wo die Pakete auf Mikrotik Seite hinkommen die das native eth1 Interface des Ubuntu Servers aussendet.

Okay, verstehe. Also kann ich damit bestimmen, mit welchem tag das physische Interface selbst die Pakete versendet. Die virtuellen vlan-Interfaces versenden (wenn denn alles richtig konfiguriert ist...) die Pakte mit dem in ubuntu konfigurierten Tag. Die PVID ändert daran nichts.

Eigentlich eine ganz einfache Logik !

Wenn man sie irgendwann verstanden hat

Damit haben die virtuellen Interfaces vlan50 und vlan60 die jeweils passenden IP-Adressen erhalten, z.B.:

Gut, das zeigt ja aber das der Server Part saube rist auch wenn man Servern natürlich keine dynmaischen IP Adressen vergibt abewr ggf. machst du das ja per Mac Reservierung was dann wieder OK ist.

Danke für den Tipp mit Wireshark. Danach versenden die Interfaces keine getaggte Pakete

Das kommt ganz sicher weil du vermutlich NICHT den Promiscous Mode aktiviert hast in deiner netzwerkkarte des Wireshark !
Ein typischer Fehler und dann werden 802.1q VLAN Tags nicht angezeigt.
Achte also darauf das das entsprechend gesetzt ist wenn du mit einem Winblows Rechner arbeitest:
Z.B. Intel: https://www.intel.com/content/www/us/en/support/articles/000005498/netwo ...
Oder allgemein: https://wiki.wireshark.org/CaptureSetup/VLAN#Special_flag_settings
Linux hat diese Problematik nicht !
Also Workaround kannst du aber auch auf dem Ubuntu tcpdump benutzen sofern du es mit apt install tcpdump installiert hast. Ein tcpdump -i enp2s0 -nn -e vlan sollte dir das auch anzeigen. Oder mit tcpdump -i enp2s0 -nn -e vlan -w /tmp/vlan.pcap kannst du es auch in eine .pcap Datei schreiben die du dir dann mit dem Wireshark ansehen kannst.

Also kann ich damit bestimmen, mit welchem tag das physische Interface selbst die Pakete versendet.

Nein !
Denn das physische Interface versendet alle Pakete generell immer ohne VLAN Tags ! Das ist in allen Betriebssystemen so.
Du kannst das unterbinden indem du dem physischen Interface selber keine IP Adresse gibst. Keine IP = keine Pakete...

So kommen rein nur Tagged Pakete aus dem Server Port.

Die virtuellen vlan-Interfaces versenden die Pakete mit dem in Ubuntu konfigurierten Tag. Die PVID ändert daran nichts.

Das ist richtig !
Die PVID auf Serverseite ist quasi das physische Interface wenn du es so sehen willst.

Zitat von @aqui:

Gut, das zeigt ja aber das der Server Part saube rist auch wenn man Servern natürlich keine dynmaischen IP Adressen vergibt abewr ggf. machst du das ja per Mac Reservierung was dann wieder OK ist.

Aktuell nutze ich DHCP auch als Hinweis darauf, ob die Konfiguration grundsätzlich okay ist. Die Adressen setzte ich - wenn es dann funktioniert - im Router auf statisch. Da es sich hier nicht um eine produktive Umgebung handelt, ist das für mich bis auf Weiteres in Ordnung so

Danke für den Tipp mit Wireshark. Danach versenden die Interfaces keine getaggte Pakete

Das kommt ganz sicher weil du vermutlich NICHT den Promiscous Mode aktiviert hast in deiner netzwerkkarte des Wireshark !
Linux hat diese Problematik nicht !

Tatsächlich läuft der Server nicht headless, deswegen habe ich wireshark direkt auf dem Server installiert. Wenn ich die Schnittstelle enp2s0.50 untersuche, wird kein vlan-tag angezeigt. Lass ich wireshark aber direkt auf der enp2s0 laufen, wird es angezeigt. Das ist für den Profi offenbar klar (Dein Tipp mit tcpdump bezieht sich ja auch auf die enp2s0), mir erschließt es sich noch nicht so ganz...

Also Workaround kannst du aber auch auf dem Ubuntu tcpdump benutzen sofern du es mit apt install tcpdump installiert hast. Ein tcpdump -i enp2s0 -nn -e vlan sollte dir das auch anzeigen. Oder mit tcpdump -i enp2s0 -nn -e vlan -w /tmp/vlan.pcap kannst du es auch in eine .pcap Datei schreiben die du dir dann mit dem Wireshark ansehen kannst.

Das hat funktioniert, die richtige vlan-ID wird angezeigt

Also kann ich damit bestimmen, mit welchem tag das physische Interface selbst die Pakete versendet.

Nein !
Denn das physische Interface versendet alle Pakete generell immer ohne VLAN Tags ! Das ist in allen Betriebssystemen so.

Ich meinte damit auch, dass die PVID bestimmt, welches Tag der Switch/Router dem Paket anhängt, das zuvor untagged vom pyhsischen Interface versand wurde. So wie ich es formuliert hatte, ist es tatsächlich nicht zutreffend.

Erneut vielen Dank für Deine Hilfe!

Lass ich wireshark aber direkt auf der enp2s0 laufen, wird es angezeigt. Das ist für den Profi offenbar klar

Ja, ist auch völlig klar, denn die virtuellen Subinterfaces sind ja die internen Schnittstellen zum Kernel. Es ist also verständlich und auch irgendwie logisch das dort keine VLAN Tags angezeigt werden, denn durch die Separation auf ein Subinterface ist ja die Zuordung vorgegeben.
Auf dem physischen Interface aber nicht, dort muss der VLAN Tag eingefügt sein, denn das ist wie gesagt die Physik von wo es dann auf den eigentlichen netzwerk Draht geht. Das Anzeigeverhalten ist also logisch nachvollziehbar.

Das hat funktioniert, die richtige vlan-ID wird angezeigt

👍 Das zeigt das alles richtig ist. Zeigt ja auch schon die richtige Zuweisung der IP Adressen. Das wäre nicht der Fall wenn etwas grundsätzlich mit dem Tagging nicht stimmt. Also alles richtig gemacht...!

Ich meinte damit auch, dass die PVID bestimmt, welches Tag der Switch/Router dem Paket anhängt, das zuvor untagged vom pyhsischen Interface versand wurde.

Jein... Wenn dann gilt das für den Switch/Router rein nur intern. Aber ich denke genau so meinst du es auch und das wäre dann richtig. Die PVID bestimmt grundsätzlich was mit ungetaggten Paketen gemacht werden soll.
Eigentlich ein ziemlich blödes Feature bei billigen Websmart Switches was fast immer VLAN Anfänger verwirrt weil diese meist nicht verstehen das man den Port einmal in den Untagged Mode setzen muss im betreffenden VLAN und zusätzlich noch die PVID.
Unsinnig und bessere Websmart Switches wie z.B. Cisco SG usw. haben deshalb ein Auto PVID Feature was die PVID automatisch für das Untagged VLAN übernimmt. Sehr viel sinnvoller da fehlertoleranter.
Aber im Billigsektor gehts eben rein nur ums Geld und da kostet jede Minute Entwicklungsarbeit zu viel, den Kunden in diesem Sektor kaufen rein nur preisorientiert.

Erneut vielen Dank für Deine Hilfe!

Immer gerne...

Zitat von @aqui:
Eigentlich ein ziemlich blödes Feature bei billigen Websmart Switches was fast immer VLAN Anfänger verwirrt weil diese meist nicht verstehen das man den Port einmal in den Untagged Mode setzen muss im betreffenden VLAN und zusätzlich noch die PVID.
Unsinnig und bessere Websmart Switches wie z.B. Cisco SG usw. haben deshalb ein Auto PVID Feature was die PVID automatisch für das Untagged VLAN übernimmt. Sehr viel sinnvoller da fehlertoleranter.
Aber im Billigsektor gehts eben rein nur ums Geld und da kostet jede Minute Entwicklungsarbeit zu viel, den Kunden in diesem Sektor kaufen rein nur preisorientiert.

Ich würde mich selbst als interessierten Endkunden beschreiben

Und auch wenn ich das Aufsetzen eines Linux-Servers ganz gut hinbekommen habe mitsamt Docker-Containern, VM, Konfiguration per ssh und so weiter, ist die Netzwerkthematik eine ganz andere Hausnummer. Das dürfte für Leute wie mich gerne noch etwas einfacher werden

Auf Grund der Tutorials und der Beiträge hier habe ich mich für Mikrotik entschieden. Wenn es mit Cisco deutlich einfacher und schneller gegangen wäre, hätte ich auch mehr Geld ausgegeben. Ich fürchte aber, dass zumindest bei mir und meinen Anforderungen der Hersteller allenfalls eine untergeordnete Rolle spielt.

Aber das ist jetzt auch egal. Es rennt alles und ich kann mir wieder neue Sachen ausdenken, die ich umsetzen will. Die dynamische VLAN-Zusweisung im WLAN mit RADIUS z.B. hat dank Deines Tutorials funktioniert - und das ganz ohne Nachfrage

Das dürfte für Leute wie mich gerne noch etwas einfacher werden

Lieber nicht denn andere Leute verdienen damit ihre Brötchen ! Und was daraus werden kann siehst du dann an einem Betriebssystem wie Microsoft. Es ist gut so das die Funktionen im Netzwerk so wie sie sind.

Wenn es mit Cisco deutlich einfacher und schneller gegangen wäre, hätte ich auch mehr Geld ausgegeben.

Nope, das ist es nicht. Zumal es Switchhardware mit Routerfunktion so nur eingeschränkt gibt. Oder, wenn dann in gänzlich anderen Preisdimensionen.

ch fürchte aber, dass zumindest bei mir und meinen Anforderungen der Hersteller allenfalls eine untergeordnete Rolle spielt.

So ist es... Aber egal, du hast das wunderbar hinbekommen was dafür spricht das deine Wahl des Mikrotik so falsch nicht gewesen ist !

im WLAN mit RADIUS z.B. hat dank Deines Tutorials funktioniert - und das ganz ohne Nachfrage

👍 Dann bist du aber schon halber Netzwerkprofi, denn das ist schon eine Klasse für sich !

Zitat von @aqui:

Lieber nicht denn andere Leute verdienen damit ihre Brötchen ! Und was daraus werden kann siehst du dann an einem Betriebssystem wie Microsoft. Es ist gut so das die Funktionen im Netzwerk so wie sie sind.

Das sollen sie auch gerne weiterhin. Aber so, wie ein Router mittlerweile zur Standardausstattung eines Haushalts gehört und zumindest die Grundfunktionen recht einfach eingerichtet werden können, darf es meinetwegen gerne künftig auch wenigstens für kleine VLAN-Setups werden...

👍 Dann bist du aber schon halber Netzwerkprofi, denn das ist schon eine Klasse für sich !

Allenfalls ein Abschreibprofi

Na ja Router und Router ist immer relativ... Autos gibt es auch von Dacia Logan zu Lamborghini oder dachtest du die Backbone Router im Internet sind alles FritzBoxen mit 10, 40 oder 100 Gigabit ?
Bei billigen Consumer Plasterouter sollte es so sein, da hast du recht. Dort sind es immer Laien die damit umgehen aber auch das sollten sie nicht. Deshalb werden diese auch immer über das TR-069 Schnüffelprotokoll vom Provider automatisch fernkonfiguriert. DAUs müssen also nur die Strippe in die Dose stecken. Das ist aber eine ganz andere Welt und hat mit eigentlichen Routern und Netzwerken nicht das Geringste oder nur 0,2% zu tun !

Nur um deinen (Router) Horizont mal wieder etwas gerade zu rücken...

German solved Question LAN, WAN, Wireless Networks