20.06.2020, aktualisiert um 15:06:01 Uhr

7518

Netzwerk-Design und Geräte für zu Hause

Moin,

nachdem wir unser neues Eigenheim bezogen haben, möchte ich mich an die Überarbeitung des Netzwerks machen. Da mir KNX zu teuer war habe ich mich für Wifi-Schalter (Shelly) entschieden und möchte nun anfangen, die ersten Jalousien steuerbar zu machen. Nach und nach sollen weitere Schalter, Sensoren, Kameras usw dazukommen. Allerdings möchte ich zunächst die Grundlage in Form eines gut und sicher strukturierten Netzwerks mit vernünftigem Kostenkompromiss schaffen.

Leider habe ich keine Netzwerk-Expertise, sondern eine Entwickler-Historie. Einiges habe ich mir schon hier im Forum angelesen, aber dennoch verbleiben einige Fragen. Mir fehlt bei etwas komplexeren Netzwerken schlichtweg die praktische Erfahrung.

Ursprünglich hatte ich mit mehreren Routern geplant, aber das ist sehr statisch. VLANs scheinen mir da deutlich flexibler, insbesondere muss man nicht bei Änderungen, z.B. neues Teilnetz, gleich einen neuen Router anschaffen. Dann wird aber auch schon wieder spannend. Leider ist der Feature-Vergleich bei Netzwerk-HW zwischen den einzelnen Herstellern zeitintensiv. Ein Web Smart Switch kann nicht immer VLAN-Routing auf L3 oder hat auch nicht immer einen DHCP-Server an Bord.

Meine ersten Gedanken sehen wie folgt aus:

2020-06-20 - netzwerkstrukturplan - draft 0.2

Das WLAN1 (Gäste-WLAN) dient rein dem Internetzugriff für Besucher und kann wie heute auch schon, auf der FB aktiviert werden.
Für den Zugriff von außen habe ich heute einen PiVPN mit OpenVPN (bzw. eigentlich einen PiHole). Der wird in diesem Zuge auf Wireguard umgestellt. Ich möchte von außen sowohl auf das VLAN1 (=> PiNAS) und vor allem auch auf das VLAN3 (=> OpenHAB-Server) zugreifen können. Ansonsten dient der PiVPN dem "sicheren" Surfen von unterwegs.
VLAN1 für dient der "echten" privaten IT, sprich Notebooks & Co. Hier steht auch ein PiNAS als Fileserver.
VLAN2 für Mobilgeräte und Unterhaltung, z.B Smartphones, Tablets und Fernseher.
VLAN3 für IoT bzw. Gebäudeautomatisierung. Hier drin stecken die ganzen Schalter, Sensoren, Kameras, etc. Ebenfalls steht dort der openHAB-Server, welchen ich aus den anderen Netzen heraus erreichen möchte.

Allgemein:

Was sagen die Experten zur Struktur?
Was sollte ich anders lösen?

Im Detail:

Im Entwurf ist der L3-Switch ein All-in-One-Gerät und muss neben dem VLAN-Routing mindestens einen DHCP-Server im Bauch haben. Gut wäre es, wenn dieser auch gleich eine FW dabei hätte. Welche L3-Switche kommen dafür in Frage? Oder alternativ einen VLAN-fähigen Router und zusätzliche L2-Switche?
Verständnisfrage: Die anzulegenden Routen beziehen sich immer auf das Netzwerk, oder nur auf einzelne Rechner im Netzwerk?
Verständnisfrage: Kann man eigentlich innerhalb eines Port-basierten VLANs auch normale L2 Switche installieren (bei Tag-basierten geht das vermutlich nicht, weil die Tags im Paket entfernt würden)?
Spätestens für VLAN3 brauche ich definitiv eine FW, damit der dort versammelte Technikzoo keinen Quatsch macht. Der openHAB-Server muss aber von Zeit zu Zeit Updates erhalten. Insbesondere wenn der L3-Switch keine FW hat, welche FWs sind empfehlenswert?
Welche WLAN-AP sind empfehlenswert?

Danke + Gruß,
Tripod

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 580861

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

Ausgedruckt am: 26.11.2024 um 06:11 Uhr

94 Kommentare

Neuester Kommentar

Hallo.

Prinzipiell klingt das schon sehr danach, dass Du Dich mit dem Thema auseinander gesetzt hast.

Mikrotik Geräte sind im Grunde ein sehr guter Kompromiss aus Funktionalität und Preis. Die Konfiguration ist jedoch mit einer etwas steilen Lernkurve versehen.

Aber @aqui hat schon unzählige Tutorials verfasst, damit Du das Projekt zum Fliegen bringst.

Auch wäre es denkbar ein kleines APU Board mit PFsense/Opensense auszustatten und als Firewall / Router/ OpenVPN Server / Werbeblocker (PFBlocker) einzusetzen. Dahinter sitzen dann L2 Switches. Für das WLAN würde aktuell auch die Wahl auf Mikrotik cAP AC fallen.

Eventuell ließt Du Dich kurz in die VLAN Tutorials hier im Forum ein, dann beantwortest Du die meisten Deiner Fragen selbst.

Das Budget spielt hier natürlich eine Rolle und auch, welche Art Modem sich um den Internetaufbau kümmert.

Du könntest die Fritzbox "degradieren" und die Firewall als Exposed Host dahinter betreiben oder Dir ein Modem á la Draytek beschaffen.

Gruß
Radiogugu

Guckst du hier:
VLAN Design mit Layer 2 VLAN Switch:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
VLAN Design mit Layer 3 VLAN Switch:
Verständnissproblem Routing mit SG300-28

Such dir das Schönste und Passenste für dich raus...

Moin,

OK, die verlinkten Beiträge hatte ich schon mal gelesen, aber offenbar nicht alles verstanden:

Im Prinzip ist es wurscht, ob ich einen VLAN-fähigen Mikrotik Router nehme und dahinter VLAN-fähige L2 Switch, z.B. Cisco SG 250, (=Variante 1); oder einen L3 Switch, z.B. Cisco SG 350 (=Variante 2; wobei der SG 250 auch statische Routen auf L3 beherrscht, aber keinen DHCP-Server mitbringt). Um zwischen beiden Varianten zu entscheiden ist es vermutlich ist am besten, wenn ich die jeweils benötigten Netzwerkgeräte durchzähle und deren Preise summiere.

Eines geht mir noch nicht ganz in die Birne, daher sicherheitshalber nachgefragt: Hinter einen VLAN-fähigen Router/Switch kann ich auch einen unmanaged Switch, der mit VLANs nix anfangen kann, dranhängen?

Ich habe noch zwei unmanaged Cisco 100er, die eigentlich als reine Kabelverzweiger in einzelnen Räumen dienen. Sämtliche Endgeräte die am unmanaged Switch hängen, wären dann im selben VLAN (weil Port-basiert am vorgelagerten VLAN-fähigen Router/Switch).
Wenn ich hingegen auch innerhalb des Raumes Endgeräte in verschiedenen VLANs haben möchte, dann muss das ein VLAN-fähiger Switch mit Trunk-Port sein.

Die FW in der Fritzbox kann man nicht wirklich gut konfigurieren. Leider ist meine FB auch (noch?) nicht kompatibel mit OpenWrt. Wird dann doch eher auf das Tandem aus APU Board und pfSense hinauslaufen. Schade, dass das nicht mit dem Pi geht.

Hinter einen VLAN-fähigen Router/Switch kann ich auch einen unmanaged Switch, der mit VLANs nix anfangen kann, dranhängen?

Ja, natürlich geht das auch.
Dann hast du aber ein Problem das du für jedes getrennte Netz (VLAN) auch einen physischen Netzwerk Port benutzt. Du kannst ja dann kein VLAN Tagging nutzen am Router.
Oder du brauchst dann wenigstens einen kleinen 5 oder 8 Port VLAN L2 Switch der dir die VLANs vom Router oder Firewall dir dann wieder auf 4 bzw 7 Ports aufsplittet solange du nicht mehr Segmente brauchst was dann 16 oder 24 Ports erfordert.
An diese 4 oder 7 Ports des kleinen VLAN Verteilerswitches kannst du dann wieder dumme, ungemanagte 10 Euro Plasteswitches vom Blödmarkt anschliessen, denn der Switch davor splittet ja alles wieder auf für dich. Als reine "Kabelverzweiger" pro Netzwerk Segment ist das natürlich absolut OK so.

Sämtliche Endgeräte die am unmanaged Switch hängen, wären dann im selben VLAN

Absolut richtig !

innerhalb des Raumes Endgeräte in verschiedenen VLANs haben möchte, dann muss das ein VLAN-fähiger Switch mit Trunk-Port sein.

Auch absolut richtig !

Wird dann doch eher auf das Tandem aus APU Board und pfSense hinauslaufen.

Damit machst du absolut nichts falsch ! Wenn du mit einer Router Kaskade mit der FB arbeiten willst wäre allerdings ein Mikrotik RB3011 auch eine gangbare Alternative, hat aber eine etwas höhere Lernkurve.
Wie gesagt je nachdem ob Kaskade oder nicht..?!

Moin,

der Mikrotik-Router hex sieht nach einem kleinen Wundergerät aus. Das RouterOS hat sogar eine FW im Bauch. Müsste damit nicht bereits eine erste Abschottung auf gewünschte Verknüpfungen zwischen den VLANs/Teilnetzen möglich sein - Beispiel:

Routen zwischen den VLANs/Teilnetzen einrichten und dann
per FW auf erlaubte Kommunikation einschränken (z.B. bei VLAN3 keine Kommunikation in/aus dem Teilnetz hinein/heraus mit Ausnahme des OpenHAB-Servers)
Oder habe ich gerade einen Denkfehler?

Bzgl. der Router-Kaskade:

Vermutlich würde ich die FB zum LWL-Modem degradieren und daran den Mikrotik-Router dranhängen. An den Mikrotik-Router dann wiederum sämtliche weitere Netzwerkgeräte. Dann wäre der VPN-Server (und die FB) Teil eines 4. VLANs.
Alternativ müsste die FB das Teilnetz aufmachen. An die FB dann den VPN-Server und den Mikrotik-Router hängen.
Beides müsste eigentlich möglich sein - oder mag die FB eine der beiden Alternativen nicht?

Gruß,
Tripod

Zitat von @Tripod:

Moin,

der Mikrotik-Router hex sieht nach einem kleinen Wundergerät aus. Das RouterOS hat sogar eine FW im Bauch. Müsste damit nicht bereits eine erste Abschottung auf gewünschte Verknüpfungen zwischen den VLANs/Teilnetzen möglich sein - Beispiel:

Routen zwischen den VLANs/Teilnetzen einrichten und dann
per FW auf erlaubte Kommunikation einschränken (z.B. bei VLAN3 keine Kommunikation in/aus dem Teilnetz hinein/heraus mit Ausnahme des OpenHAB-Servers)
Oder habe ich gerade einen Denkfehler?

Nein hast Du nicht. Der Mikrotik würde dann das Routing der dahinterliegenden Netze übernehmen. Nur für den Internet-Aufbau benötigst Du noch ein separates Gerät ("Modem").

Bzgl. der Router-Kaskade:

Vermutlich würde ich die FB zum LWL-Modem degradieren und daran den Mikrotik-Router dranhängen. An den Mikrotik-Router dann wiederum sämtliche weitere Netzwerkgeräte. Dann wäre der VPN-Server (und die FB) Teil eines 4. VLANs.

Nein. In der Fritzbox den Mikrotik als "Exposed Host" definieren und den DHCP und WLAN deaktivieren. Im Mikrotik dann alles konfigurieren und eventuell ein paar Mikrotik Access Points gleich mit bestellen und entsprechende VLANs für WLAN (Gäste / IOT / Smartphones / etc.) einrichten.

* Alternativ müsste die FB das Teilnetz aufmachen. An die FB dann den VPN-Server und den Mikrotik-Router hängen.

Alles den Mikrotik machen lassen. Dort die PPPoE Daten Deines Providers eintragen und die Fritzbox wirklich nur als Modem zu nutzen. Du schriebst "LWL-Modem". Hast Du einen ONT Deines Providers in der Wohnung / im Keller? Dann könntest Du die Fritzbox gänzlich bei Seite lassen und direkt den Mikrotik an den ONT via Ethernet anschließen und dort die PPPoE Einwahl konfigurieren (dieses Setup habe ich bei mir Zuhause vor einigen Monaten umgesetzt).

* Beides müsste eigentlich möglich sein - oder mag die FB eine der beiden Alternativen nicht?

Die Fritzbox kann viel, aber mit VLAN umgehen gehört nicht dazu.

Gruß
Radiogugu

Das RouterOS hat sogar eine FW im Bauch.

Nicht nur das sondern auch einen kompletten WLAN Controller...

Kollege @radiogugu hat ja schon alles zu dem Thema gesagt. Das ist die richtige Viorgehensweise...

Zitat von @Tripod:

Moin,

Morje,

der Mikrotik-Router hex sieht nach einem kleinen Wundergerät aus. Das RouterOS hat sogar eine FW im Bauch. Müsste damit nicht bereits eine erste Abschottung auf gewünschte Verknüpfungen zwischen den VLANs/Teilnetzen möglich sein - Beispiel:

Routen zwischen den VLANs/Teilnetzen einrichten und dann
per FW auf erlaubte Kommunikation einschränken (z.B. bei VLAN3 keine Kommunikation in/aus dem Teilnetz hinein/heraus mit Ausnahme des OpenHAB-Servers)
Oder habe ich gerade einen Denkfehler?

Das ist so machbar, achte nur auf den Unterschied "Router-Firewall" und Firewall (Routing zwischen VLANs verhindern)
Stichwort: Default-Regel

Bzgl. der Router-Kaskade:

Vermutlich würde ich die FB zum LWL-Modem degradieren und daran den Mikrotik-Router dranhängen. An den Mikrotik-Router dann wiederum sämtliche weitere Netzwerkgeräte. Dann wäre der VPN-Server (und die FB) Teil eines 4. VLANs.
Alternativ müsste die FB das Teilnetz aufmachen. An die FB dann den VPN-Server und den Mikrotik-Router hängen.
Beides müsste eigentlich möglich sein - oder mag die FB eine der beiden Alternativen nicht?

Zwecks einfacherer Verwaltung, würde ich, wenn möglich, dann den Mikrotik als einzigen Router nutzen und wie @radiogugu schon schreibt die FB 7530 aus deiner Übersicht als Modem verwenden, bzw. diese komplett entfernen , wenn ein LWL-Modem eh noch davor hängt.
So brauchst du dich um einen Router weniger zu kümmern ;)

Gruß,
Tripod

Viele Grüße
Cossi

Edit: Verlinkung angepasst

Moin,

sorry, war die letzten Tage wegen eines Projektes unter Wasser.

Ja, genau. Ich habe einen Glasfaseranschluss und der Netzabschluss des Providers (EWE) ist quasi der ONT. Aber: Die Zugangsdaten sind in der FB konfiguriert. Was mich gerade irritiert ist, das in der FB die Option "Internetzugang: Über die FB" aktiviert ist - und nicht die Option "Internetzugang: Über ein externes Modem".

Mit beiden MikroTik-Routern, also hex/RB750 sowie RB3011, sind beide Konstellationen, also a) direkt anschließen und b) die FB als Zugang zu nutzen (Kaskade), möglich (=> auf beiden ist ja das Router OS, nur in verschiedenen Lizenzstufen, installiert)?

Bin gerade dabei die Bestell-Liste zusammenzustellen ;)

Gruß,
Tripod

Zitat von @Tripod:

Moin,

Mahlzeit,

sorry, war die letzten Tage wegen eines Projektes unter Wasser.

nicht schlimm

Dann vermute ich ganz stark, dass du von deinem Netzbetreiber "nur" einen Medienwandler direkt am Glasfaser hast und die FB direkt dahinter per RJ-45 angeklemmt ist und als dein Router mit Modem fungiert.

Mit beiden MikroTik-Routern, also hex/RB750 sowie RB3011, sind beide Konstellationen, also a) direkt anschließen und b) die FB als Zugang zu nutzen (Kaskade), möglich (=> auf beiden ist ja das Router OS, nur in verschiedenen Lizenzstufen, installiert)?

Variante a) klappt nicht, da die Mikrotiks kein Modem bereitstellen!
Variante b) kannst du nach @aqui s Tutorials (Mehrzahl) einrichten, dann rennt das!
Hier dann am besten, wie oben beschrieben, die FB als reines Modem betreiben.

Bin gerade dabei die Bestell-Liste zusammenzustellen ;)

Gruß,
Tripod

Viele Güße
Cossi

Variante a) klappt nicht, da die Mikrotiks kein Modem bereitstellen!

Bei Glasfaser bedarf es auch keines Modems in dem Sinne sondern rein nur einer simplen SFP Optik. Guckst du auch hier:
Mikrotik RB4011iGS+5HacQ2HnD-IN welches SFP Modul für FTTH (Deutsche Glasfaser)
Oder, sofern das Übergabe Device rein nur ein simpler, passiver Glas-Kupfer Wandler ist, kann man den Mikrotik WAN Port dort direkt aufstecken. Im Default agiert der als DHCP Client dort und requestet eine IP vom Provider.
In der Regel machen die da rein nur DHCP auf dem Provider Link.

Moin,

Bei Glasfaser bedarf es auch keines Modems in dem Sinne sondern rein nur einer simplen SFP Optik. Guckst du auch hier:
Mikrotik RB4011iGS+5HacQ2HnD-IN welches SFP Modul für FTTH (Deutsche Glasfaser)
Oder, sofern das Übergabe Device rein nur ein simpler, passiver Glas-Kupfer Wandler ist, kann man den Mikrotik WAN Port dort direkt aufstecken. Im > Default agiert der als DHCP Client dort und requestet eine IP vom Provider.
In der Regel machen die da rein nur DHCP auf dem Provider Link.

Besten dank, das hilft mir weiter. Es ist tatsächlich mein erster LWL-Anschluss, bisher sonst nur DSL oder Kabel gehabt. Mit dem zusätzlichen SFP-Modul am RB3011 könnte man diesen also direkt am ONT anschließen. Im ersten Schritt werde ich die FB erstmal dranlassen und mich an die Netzwerkstrukturen machen. Wenn das stabil funktioniert, dann werde ich das mal ausprobieren - die FB als reines Modem ist auf Dauer ja eigentlich auch rausgeworfenes Geld.

Gruß,
Tripod

die FB als reines Modem ist auf Dauer ja eigentlich auch rausgeworfenes Geld.

Richtig, das wäre Quatsch denn die ist dann nur sinnfreier "Durchlauferhitzer" in einer überflüssigen Kaskade. Sinnvoller ist natürlich den Router direkt an den ONT anzuschliessen.
Routerfreiheit ist eine gesetzliche Vorgabe.

Moin,

beim Blick in die Doku von der FB bekomme ich wegen der eingeschränkten Konfigurierbarkeit eine kleine Halskrause. Daher habe ich mir die FB und den ONT nochmal genauer angeschaut - und mir ist etwas wieder eingefallen, was mich bei der Erstinstallation schon so gewundert hatte:

Es ist das Modell 7530 in der "LWL-Edition".
Mit LWL hat das Teil aber gar offenbar nix am Hut: Dieses Modell hat einen ganz normalen DSL-Port.
Der Anschluss des ONT erfolgt per Ethernet auf LAN-Port 1 (siehe Technische Details).

@aqui , @radiogugu : Da der LAN-Port dann ja ein "normaler" Port sein muss - und nix spezifisches für LWL - müsste ich eigentlich den RB3011 direkt per Ethernet an den ONT klemmen können - ein SFP-Modul ist dann nicht mehr notwendig?

Das wäre super, dann rupfe ich die FB direkt von der Wand sobald der RB3011 hier eintrudelt ;)

Gruß,
Tripod

Mit LWL hat das Teil aber gar offenbar nix am Hut: Dieses Modell hat einen ganz normalen DSL-Port.

Das wäre technisch Quatsch, denn damit unterstellst du der FB das sie ein integriertes xDSL Modem hat mit einem xDSL Port. Der wäre völlig inkompatibel zu deiner Hardware und Infrastruktur. Das wäre so wenn du an eine Gasleitung einen Wasserhahn montierst...
Vermutlich hast du hier laienhaft einen normalen RJ-45 Ethernet Port mit einem RJ11 Modem Port verwechselt.
Sehr wahrscheinlich ist als ein simpler RJ-45 Kupferport der an den ONT geht und dort stinknormal per DHCP eine Provider IP zieht.
Wenn dem so ist kannst du jeden beliebigen Baumarkt Router bei dir anschliessen.

und nix spezifisches für LWL - müsste ich eigentlich den RB3011 direkt per Ethernet an den ONT klemmen können

Ja, davon ist auszugehen und das wird ganz sicher funktionieren.
Kannst du ja auch ganz einfach mit einem simplern PC mal ausprobieren. Einfach aufstecken, NIC im DHCP Mode und dann mit ifconfig -all (Winblows) mal nachsehen ob du eine IP bekommen hast.
Auf diesen simplen Test kommt auch ein Netzwerk Laie doch gleich als erstes....

Das wäre super, dann rupfe ich die FB direkt von der Wand sobald der RB3011 hier eintrudelt

Wäre dann absolut die richtige Vorgehensweise !
3011er natürlich vorher noch sauber konfigurieren !!

Moin,

Das wäre technisch Quatsch

klick mal mal auf den Link zur FB 7530, da sieht man auch ein Bild von der Anschluss-Seite. Meine FB hat einen DSL-Port - vielleicht fehlt in der LWL-Edition auch einfach das integrierte DSL-Modem und der Port ist tot, keine Ahnung. Letztlich es ist aber auch wurscht, weil der ONT ja nicht am DSL-Port hängt, sondern an LAN1.

Dann werde ich mich mal als Nächstes mit der FW vom 3011er beschäftigen, da sollte dann ja ab der ersten (Betriebs)Sekunde alles von außen abgeschottet werden.

Gruß,
Tripod

Meine FB hat einen DSL-Port -

Logisch, denn das ist der Output des integrieten xDSL Modems. Das ist aber kein Ethernet was aus diese Buchse kommt sondern das xDSL Modemsignal was auf einen xDSL Draht des Providers geht.
Mit Glasfaser hat das nichts zu tun.
Man kann aber bei jeder FritzBox, wie jedermann ja weiss, das interne xDSL Modem per Setup überbrücken und den Router WAN/Internet Port dann direkt per Setup auf einen der Ethernet Ports legen. In der Regel ist das der LAN 1 Port.
DER wird dann auf ein vorhandenes Glasfasermodem mit Ethernet Port gesteckt. Deshalb ist auch im Prospekt "...Routerbetrieb auch mit Kabelmodem, Glasfaseranschluss" vermerkt.

weil der ONT ja nicht am DSL-Port hängt, sondern an LAN1.

Binge ! Genau deshal ist im Setup das interne Kabelmodem totgelegt bzw. überbrückt worden.
Einen direkten Glasfaser Anschluss der ja zwingen einen SFP oder SFP+ Port für eine entsprechende Glasfaseroptik erfordert hat die o.a. Box ja nicht. Folglich geht es also nur über Kupfer.

Ethernet Breitbandport hat aber jeder popelige Baumarkt Router und auch renomierte Router vom freien Markt so das man bei Vorhandensein eines FTTH Umsetzers (ONT) auch alles andere vom freien Markt anschliessen kann. Natürlich auch den RB3011er !

Dann werde ich mich mal als Nächstes mit der FW vom 3011er beschäftigen

Musst du nicht !!!
Die Mikrotik Router bringen mit der DEFAULT Konfiguration von Haus aus schon eine wasserdicht konfigurierte Internet Firewall mit.
Du musst lediglich bei der Erstkonfiguration mit der WinBox das Dialog Popup Window "Default Konfig verwenden JA oder NEIN ?" mit einem JA abnicken. Damit "tankt" der Mikrotik dann eine Default Internet Router Konfig auf die Maschine.
Dann ist ether1 immer dein heißer Internet Port im DHCP Client Mode mit aktivierter Internet Firewall und alle anderen Ports sind erstmal als Bridge zusammengefasst als lokales LAN.
Ether1 kannst du dann in deinen ONT stecken und solltest dann sofort eine Provider IP bekommen.
Auf den lokalen LAN Interfaces rennt ein Default IP Netz 192.168.88.0 /24 mit aktivem DHCP Server so das du dann dort auch sofort loslegen kannst.
Plug and Play also !

Wie man das dann entsprechend mit VLANs und allem Drum und Dran customized erklären dir die entsprechenden Foren Tutorials hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
usw.

Dann habe ich ja ein paar spannende Nachtschichten vor mir ;)

Ether 1 kannst du dann in deinen ONT stecken und solltest dann sofort eine Provider IP bekommen.

Die Zugangsdaten des Providers (Benutzername und Passwort) kann man sicherlich irgendwo an ether1 konfigurieren?
Was mich gerade etwas wundert ist, dass auf dem Zettel für die manuelle Einrichtung vom Provider eine VLAN ID angegeben ist - muss ich da was bei der Konfig am 3011er berücksichtigen, oder kann ich diese Info knicken?

Noch zwei ergänzende Fragen:

Mein PiVPN verwendet einen dynDNS-Dienst - wo kann ich im RouterOS einen dynDNS konfigurieren, damit die aktuelle externe IP an den Dienst kommuniziert wird?
Der cAP ac kann vermutlich nicht mit VLANs / MSSIDs umgehen (das wäre jetzt aber auch wirklich zu schön)?

Die Zugangsdaten des Providers...

Nöö, muss man in der Regel nicht, denn üblicherweise wird im Glasfasernetz DHCP gemacht. Möglich das die Mac Adresse der FB registriert ist aber die kann man problemlos im RB3011 faken dafür.
Falls er wider Erwarten PPPoE macht musst du ether 1 als PPPoE Client konfigurieren.

dass auf dem Zettel für die manuelle Einrichtung vom Provider eine VLAN ID angegeben ist

Das ist mittlerweile üblich bei allen Providern und weiss man als Netzwerker auch.
Guckst du auch hier:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV

muss ich da was bei der Konfig am 3011er berücksichtigen

Ja ! Du musst logischerweise diesen VLAN Tag mitschicken. Ansonsten würde das Paket verworfen vom Provider wenn der Tag fehlt. Das machst du indem du auf dem ether 1 Port einen entsprechenden VLAN Tag setzt.
Bitte lies dir die VLAN Grundlagen genau durch damit du verstehst was VLAN Tags sind und was nicht:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
Zu den Fragen:

wo kann ich im RouterOS einen dynDNS konfigurieren

Das machst du mit einem Script:
https://indibit.de/mikrotik-ddns-update-script/
Oder wenn es dem Standard enspricht auch onboard:
https://wiki.mikrotik.com/wiki/Manual:Tools/Dynamic_DNS

Der cAP ac kann vermutlich nicht mit VLANs / MSSIDs umgehen

Du liest scheinbar keine Handbücher und Datenblätter ?! Eine überflüssige Frage in einem Administrator Forum !

Natürlich kann er das:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Oder auch mit dynamischen VLANs:
WLAN: VLAN-Zuordnung anhand Radius-Eigenschaften? MikroTik CAPsMAN
Bzw. das ganze mit dem onbard WLAN Controller CapsMan:
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik

Lesen und verstehen !!

Moin,

vielen Dank für die Infos.

Du liest scheinbar keine Handbücher und Datenblätter ?! Eine überflüssige Frage in einem Administrator Forum !

Bitte nicht falsch verstehen: Aber ich habe nie behauptet, dass ich Netzwerker bin, sondern im Gegenteil (siehe Eingangspost) geschrieben, dass ich eben kein Experte auf dem Gebiet bin. Sämtliche Doku kann ich mir nicht auf einen Schlag reinbimsen, selbst wenn, müsste ich sie mehrfach Lesen um alles zu verstehen ;)

Ich ging davon aus, dass virtuelle AP / VLAN / MSSID zunächst mal eine Eigenschaft des AP sind und da ich in der Spezifikation des cAP ac nix dazu gefunden hatte, habe ich diese Rückfrage gestellt. Nur weil die Software ein bestimmtes Feature-Set beherrscht, heißt das nicht automatisch, das die umgebende Hardware das auch kann - im Gegenteil, bei vielen Herstellern ist sowas ja gerade die Produktpolitik.

Gruß,
Tripod

MSSID zunächst mal eine Eigenschaft des AP sind

Nein, das ist natürlich falsch und sagt einem auch der gesunde IT Verstand. Es ist doch immer eine Eigenschaft der Firmware die auf dem AP rennt. Jednefalls std as so im gehobeben und Premium Segment.
Oder siehst du auch ins Datenblatt deine PC Mainboards wenn du wissen willst ob Winblows einen HTTP Browser an Bord hat oder DHCP kann ?? Macht doch keiner so...

Wenn also dann hättest du sinnvollerweise in das Featureset von Router OS gesehen. Das ist doch die Firmware die auf der Kiste rennt.

im Gegenteil, bei vielen Herstellern ist sowas ja gerade die Produktpolitik.

Ja bei den billigen Chinaböllern aus dem Blödmarkt für den Massenmarkt. Aber du hast dir ja in weiser Voraussicht genau deshalb einen Mikrotik zugelegt damit dir das alles nicht passiert !

Mit anderen Worten: Alles richtig gemacht bis jetzt !!

Moin,

ich habe mir die o.a. Tutorials zum VLAN-Setup mit Miktrotik noch mal angeschaut, aber offenbar noch ein grundsätzliches Verständnisproblem - "nur" nachmachen reicht mir nicht, ich würde es gerne verstehen:

Ursprünglich habe ich angenommen, dass für jedes VLAN bzw. Teilnetz eine Bridge angelegt werden müsste. Warum? Ein Switch ist ja eigentlich eine Bridge und ermöglicht die Kommunikation innerhalb eines Teilnetzes über die Ports des Switches.
Aber das Gegenteil ist ja offenbar der Fall: Man legt eine Bridge an und legt sämtliche VLANs/Teilnetze da mit drauf. Für die Kommunikation zwischen den VLANs/Teilnetzen hätte ich gedacht, dass der Router das auf Teilnetzebene per IP "routet" (Layer 3).
Die einzige Erklärung, die mir dafür einfällt wäre, dass das Routing zwischen den VLANs (=Layer 2) durch die konfigurierte Bridge abgekürzt wird bzw. von Layer 3 auf Layer 2 verschoben wird?
Ergänzend gefragt: Welche Funktion hätte die Bridge ohne die VLAN-Funktionalität?

Gruß,
Tripod

Ursprünglich habe ich angenommen, dass für jedes VLAN bzw. Teilnetz eine Bridge angelegt werden müsste.

Nein das ist natürlich Quatsch. Das rennt über Tagging und nur eine einzige Bridge. Guckst du hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Lesen und verstehen...!

Aber das Gegenteil ist ja offenbar der Fall:

So ist es. Wozu gibt es denn sonst VLAN Tags ?! Vielleicht solltest du besser die VLAN_Schnellschulung besser nochmal genau lesen ?!

dass der Router das auf Teilnetzebene per IP "routet" (Layer 3).

So ist es auch. Der Router im Switch hat in jedem Teilnetz (VLAN) ein Bein (IP VLAN Interface) über das er dann das VLAN Segment routet. Simpler Klassiker und bei allen L3 Switches auf der ganzen Welt so.

durch die konfigurierte Bridge abgekürzt wird bzw. von Layer 3 auf Layer 2 verschoben wird?

Etwas verschwurbelt und kryptisch beschrieben aber mit ganz viel Bauchschmerzen könnte man dem zustimmen. Man muss immer L2 und L3 völlig getrennt betrachten !!

Welche Funktion hätte die Bridge ohne die VLAN-Funktionalität?

Sie wäre dann nur eine dumme, flache Bridge die nur ein einziges L2 Segment (Collision Domain) bedienen könnte. Ohne .1q Tagging könnte man auf so eine Bridge unmöglich mehrere L2 Segmente abbilden.

Nein das ist natürlich Quatsch. Das rennt über Tagging und nur eine einzige Bridge. Guckst du hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Lesen und verstehen...!

Das verlinkte Tutorial hilft mir für das Verstehen des tieferen, technischen Backgrounds nicht mehr weiter. Mir geht es darum, die einzelnen Schritte zu verstehen und nicht nur nachzumachen.

Beispiel: Im Tutorial ist vermerkt, dass ether1 nicht Mitglied der VLAN Bridge sein darf. In meinem Fall muss ich ether1 aber mit dem VLAN 7 taggen. Heißt das in der Quintessenz nun auch, dass ich ether1 bzw. VLAN 7 auf die Bridge legen muss?

So ist es auch. Der Router im Switch hat in jedem Teilnetz (VLAN) ein Bein (IP VLAN Interface) über das er dann das VLAN Segment routet. Simpler > Klassiker und bei allen L3 Switches auf der ganzen Welt so.

Ich ging bisher davon aus, dass ein Router dass auch im VLAN-Zeitalter über die IPs der einzelnen Teilnetze macht, sprich in einer Routing-Tabelle die Netzwerkadressen samt nächsten Hop vermerkt. Aber hier fehlt mir offenbar noch tieferes VLAN+Bridging Know-How.

Mir geht es darum, die einzelnen Schritte zu verstehen und nicht nur nachzumachen.

Dann bitte die VLAN Schnellschulung lesen:
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
oder besorge dir ein entsprechendes Fachbuch was das Paket Forwarding via L2 und Tag Handling genau beschreibt. Das im Einzelnen zu beschreiben sprengt den Rahmen dieses Forums.
Es sei denn du kannst ggf. einschränken WO es bei dir noch kneift mit dem Verständnis ?!

Im Tutorial ist vermerkt, dass ether1 nicht Mitglied der VLAN Bridge sein darf.

Das ist richtig !
Das Tutorial geht aber davon aus das diese ein reiner Routing Port zu einem davor kasladierten Router ist der NICHT Tagging fähig ist. Ein klassisches Standard Szenario für die meisten Usern von Klein- oder Kleinstnetzen.
Ein reiner Routerport darf niemals Teil der VLAN Bridge sein und ist immer separat.

Wird der Switch nur als reiner L3 Switch betrieben kann man das Routing aber natürlich auch über ein internes VLAN IP Interface machen.
Das ist mehr oder minder eine Designfrage. Beides führt zum Ziel. Für eine reines Switchdesign hat das Tutorial auch einen Link:
Mikrotik - mehrere VLANs auf cAP AC mit CAPsMAN
Wie gesagt...beide Designs sind richtig. Geschmackssache welches man nimmt.

In meinem Fall muss ich ether1 aber mit dem VLAN 7 taggen.

Auch ein reines Routing Interface kann man mit einem Tag versehen.
In deinem Falle ist dann aber der Link über ein VLAN IP Interface und ein entsprechends Tagging am Switch VLAN Port hier die sinnvollere, da technisch bessere Lösung. Keine Frage...

Ich ging bisher davon aus, dass ein Router dass auch im VLAN-Zeitalter über die IPs der einzelnen Teilnetze macht,

Ja, das ist auch so. Das VLAN IP Interface ist ja das Interface in diesem Teilnetz. Dein Problem hier ist das du L2 Forwarding und Layer 3 Forwarding wild durcheinanderwürfelst. Das sind aber 2 strikt zu trennende Prozesse auf einem Layer 3 VLAN Switch.

sprich in einer Routing-Tabelle die Netzwerkadressen samt nächsten Hop vermerkt

Genau so ist es auch ! Das ist die Layer 3 Forwarding Database auch TCAM genannt. Die hat aber mit dem L2 nicht das geringste zu tun. 2 unterschiedliche Baustellen...

Aber hier fehlt mir offenbar noch tieferes VLAN+Bridging Know-How.

Dem kann man abhelfen. Hier gehts dazu aber richtig ins Eingemachte wenn auch nur einfach erklärt...:
https://community.cisco.com/t5/networking-documents/cam-content-addressa ...

Zwischenzeitlich habe ich mich weiter in die Unterschiede zwischen L2 und L3 eingelesen. Im Gehirn ist noch nicht alles angekommen, aber es wird hoffentlich besser

Ein grundsätzliches Missverständnis war tatsächlich, dass ich die Kommunikation auf L2 komplett ausgeblendet habe. Die Bridge verstehe ich als Element, welches die Kommunikation auf L2 ermöglicht bzw. reduziert - mit entsprechenden Performance-Vorteilen, weil nur geswitcht und nicht geroutet wird. Ohne die Bridge müsste vermutlich (?) alles auf L3 per IP geroutet werden.

Bis Anfang kommende Woche sollte sämtliche Hardware da sein, dann geht's los - dann kommen vermutlich die Detailfragen ;)

Im Gehirn ist noch nicht alles angekommen, aber es wird hoffentlich besser

Das hoffen wir !! Sonst einfach fragen...

Eine Bridge war und ist immer nur Layer 2 und immer nur Forwarding Entscheidung rein auf Mac Adress Basis !
Alles was die Forwarding Entscheidung auf IP Adress Basis fällt ist ein Router !
Eine Bridge kann also schon deshalb nie ein Router sein und umgekehrt. Logisch, denn eine Bridge "sieht" gar nicht in den Layer 3 (IP) sie guckt rein nur auf die Macs im Layer2, alles andere ist ihr Wumpe.
Eigentlich eine sehr einfache Logik die aber immer wieder ausgeblendet wird.
Das es mal Unterschiede im Layer 2 und Layer 3 Forwarding aus Performance Sicht gab ist schon zig Jahre her. Seit den letzten 20 Jahren wird auch Layer 3 Forwarding komplett in Silizium gemacht und es gibt da keinerlei Unterschiede mehr, weder bei v4 noch bei v6.

dann geht's los - dann kommen vermutlich die Detailfragen

Wir sind gespannt !!!

Moin,

ein Projektabschluss und der anschließende Urlaub haben mich vom Netzwerk ferngehalten - aber nun möchte ich loslegen, stolpere aber über Verbindungsprobleme zum RB4011.

Die erste Verbindung hatte geklappt. Dann habe ich wie im Tutorial den Reset durchgeführt (Haken bei No Default Config und No Backup gesetzt). Danach klappt der Verbindungsaufbau zum RB4011 nicht mehr.

Mein Notebook (Ubuntu) ist per LAN-Kabel am Port 2 des RB4011 verbunden. Mittels Wine läuft die Winbox auf dem Notebook. Mal wird kein Gerät aufgelistet, mal findet er eines (das finde ich bereits seltsam). Aber: Nach dem Klick auf Connect kassiere ich eine Fehlermeldung "ERROR: Could not connect to <MAC>".

Auch wenn ich einen anderen LAN-Port nehme und die MAC-Adresse manuell eingebe, lande ich beim selben Ergebnis (der Bereich der MAC-Adressen der Ports 1-11 ist auf der Unterseite vermerkt).

Der einzige Unterschied zum ersten, erfolgreichen Login am Anfang ist, dass er nun via MAC-Adresse geht und nicht mehr per (voreingestellte) IP-Adresse. Hat die Winbox Probleme mit Wine?

Ergänzung: Sehe gerade im Mikrotik-Forum, dass es wohl häufiger Verbindungsprobleme via MAC-Adresse gibt. Offenbar ein Problem mit der FW bzw. Iptables.

Ist in der aktuellsten Stable und Long Term Version gefixt !

Läuft dennoch nicht. Auch wenn ich die Iptables lösche - der Verbindungsaufbau klappt nicht.

Die Discovery klappt ebenfalls nur selten bzw. vereinzelt, i.d.R. wird kein Gerät gefunden. Selbst in den seltenen Fällen, wo er was findet klappt es nicht - siehe Bild:

Update: Im Winbox-Manual gibt es einen Hinweis, dass die Verbindung via MAC-Adresse mitunter nicht funktioniert, weil ggf. Treiberseitig der IP-Stack erst funktioniert, wenn eine IP-Adresse konfiguriert ist. Als Workaround soll man einfach manuell eine IP-Adresse festlegen. Das scheint bei mir der Fall der zu sein - jedenfalls konnte ich mich gerade via MAC-Adresse verbinden, nachdem ich eine manuelle IP-Adresse konfiguriert habe.

Du bekommst ja so oder so immer nach einem Timeout eine APIPA (Zeroconf) IP Adresse 169.254.x.y was du ja auch mit ipconfig immer selber sehen kannst. Damit klappt der Zugriff dann so oder so immer !

Der Rest rennt mit der aktuellen Stable 6.47.2 hier völlig fehlerlos.

Zitat von @aqui:

Damit klappt der Zugriff dann so oder so immer !

Leider nein - egal wie lange man wartet, ein Verbindungsaufbau ist nicht möglich. Mit der manuell konfigurierten IP klappt es dann aber problemlos. Gerade mal nachgeschaut: Unter Ubuntu lautet das Pendant avahi, ist bei mir auch installiert aber offenbar der Daemon standardmäßig nicht aktiv.

Gestern Abend habe ich die VLANs (VLANs 10, 20, 30, 40, 50 plus VLAN 7 für den Provider) und IP-Konfiguration vorgenommen. Wie gewünscht kassiert mein Notebook jetzt je nach Port eine IP aus dem entsprechenden Subnetz. Allerdings bin ich auf zwei "Problemzonen" gestoßen:

1. VLAN und Filtering
Beim Aktivieren des VLAN-Filterings muss man eine PVID angeben. Das hat mich gewundert, ich hätte erwartet, dass man hier sämtliche VLAN-IDs angibt - aber das geht nicht.

Die MT Dokumentation verstehe ich an der Stelle so, dass diese PVID für die Bride selbst steht. Dann müsste ich zusätzlich, "nur" für die Bridge ein VLAN 1 konfigurieren (aber ohne IP-Pool usw)?
Darüber hinaus muss man die Frame Types beim VLAN Filtering konfigurieren - passt das mit "Admit all"?

2. Telefon
Designbug: Ich habe das Telefon vergessen! Aktuell steckt ein analoges Telefon an FON via RJ11 in der FB. Jetzt wird es ganz blöd: Die Anzahl der Ports am RB4011 reicht nicht aus, um da noch ein Telefon reinzustecken.

Jetzt muss ich also entweder (a) einen Switch daneben hängen und mir ein IP-Telefon besorgen oder (b) ich lasse die FB erstmal noch an der Wand und hänge den MT dahinter.
Prinzipielle Frage: In welches Teilnetz sollte man das IP-Telefon stecken (oder ein neues Teilnetz dafür aufmachen)?
Vermutlich ist jedoch Variante b schneller/leichter zu realisieren, was aber wieder in die Routerkaskade führt

Das ist schon merkwürdig. Funktioniert hier auf einem heX und diversen 2011ern völlig fehlerfrei ob mit oder ohne oder APIPA IP. Kann das sein das du die betreffenden Interfaces nicht in die Interface List eingetragen hast die WinBox und neigborhood Hellos erlauben ?
Mit AVAHI hat das nichts zu tun, das ist ein CDP ähnliches Protokoll was der MT sendet und die WinBox detektiert. Dazu muss es aber in die Interface List eingetragen sein die diese Protokoll Hellos sendet sonst geht es nicht oder du musst dediziert immer die mac Adresse manuell angeben.

Beim Aktivieren des VLAN-Filterings muss man eine PVID angeben.

Ist ja auch logisch, das ist bei allen VLANs von Herstellern so die kein Auto PVID supporten. Mikrotik gehört dazu. Bei UNtagged Ports muss man also immer die PVID im Port Setup angeben. Wie sollte der Switch auch sonst wissen in welches VLAN er diesen Taraffic ohne VLAN Information forwarden soll. mehr oder weniger doch logisch.

dass diese PVID für die Bride selbst steht.

Nein. Das Thema PVID findest du hier ganz gut erklärt:
Warum gibt es PVID bei VLANs?

muss man die Frame Types beim VLAN Filtering konfigurieren - passt das mit "Admit all"?

Ja, kann man als Schrotschuss so belassen. ALL bedeutet dann das der Port sowohl Tagged als auch UNtagged Frames akzeptiert.
Wer es genau machen will klickt auf Untagged Endgeräte Ports aber immer untagged or priority tagegd und auf reinen Tagged Ports wie z.B. den VLAN IP Interfaces tagged only.

Die Anzahl der Ports am RB4011 reicht nicht aus, um da noch ein Telefon reinzustecken.

Du meinst ein reines VoIP Telefon, oder ? Analoge RJ11 Telefone machen dort ja wenig Sinn.
Alternativ kannst du einen VoIP Adapter verwenden der 2 telefone oder Fax kann:
https://www.amazon.de/Cisco-SPA112-Telefonadapter/dp/B00684PN54/ref=sr_1 ...
Oder eben ein VoIP Telefon:
https://www.amazon.de/Gigaset-C430HX-Telefon-Schnurlostelefon-Freisprech ...
Da die Mobilteile mit DECT arbeiten kannst du hier mehrere Mobilteile anmelden die dann über eine SIP Basisstation arbeiten. Das dürfte ja dein Port Problem lösen.

Oha, da habe ich wohl weit daneben gegriffen. In dem Fall kann ich dann aber die halbgabe Konfiguration für VLAN 1 wieder rausnehmen und mir ein VLAN bzw. eine VLAN-ID als default aussuchen (z.B. 20, statt wie jetzt 1). Allerdings wundert es mich trotzdem etwas:

Mit Ausnahme des Trunk-Ports für meinen AP, entsprechen die einzelnen Ports jeweils einem VLAN. Bei denen kann so was praktisch nicht passieren (oder?)

Du meinst ein reines VoIP Telefon, oder ?

Ja genau. Die Gigasets habe ich mir zwischendurch auch schon angeschaut, war aber überrascht, dass keine LAN-Ports vorhanden sind. Mittels einer SIP-Basisstation könnte man das machen, aber auch die muss irgendwie an den RB4011 ran - entweder per LAN-Kabel oder WLAN. Per Kabel fehlt wieder ein Port, per WLAN ginge es.

Die Gigasets habe ich mir zwischendurch auch schon angeschaut, war aber überrascht, dass keine LAN-Ports vorhanden sind.

Ooops...die werden aber laut Datenblatt als VoIP Telefone deklariert. Also sollten sie zwangsweise einen LAN Port haben.
Amazon ist da aber technisch recht dumm und deklariert auch simple Analogtelefone als "IP" sofern man sie mit RJ11 an einen vorhandenen Router anschliessen kann der VoIP Analogports hat. Ein Schelm wer Böses dabei denkt !!
Diese sind in jedem Falle reinrassige VoIP Telefone mit LAN Anschluss !!

https://www.amazon.de/Gigaset-C430A-Telefon-Schnurlostelefon-Freisprechf ...
https://www.amazon.de/Yealink-YEA-W52P-W52P-IP-Phone-schwarz/dp/B00BIV3Y ...
Usw.

Diese sind in jedem Falle reinrassige VoIP Telefone mit LAN Anschluss !!

Stimmt. Die Basisstation hat einen LAN-Anschluss. Laut Beschreibung, kann man die VoIP-Verbindungsdaten direkt im Telefon bzw. der Basisstation konfigurieren. Mmmhhh, mal eine doofe Frage: Kann man an den ONT einen Switch dranhängen und dahinter dann MT Router und Telefon jeweils an einem Port des Switches?

=> Müsste doch eigentlich gehen, allerdings nur mit einem VLAN-fähigen Switch (wegen des Provider VLANs 7). Damit würde ich mir die "weitere" VoIP-Konfiguration ersparen (z.B. FW-Regeln, Telefon-VLAN, etc.) im RB4011 ersparen.

Mal eine ganz andere Frage:

Entgegen der Skizze im Eingangspost möchte ich sämtliche Teilnetze über den RB4011 konfigurieren. Jedes VLAN entspricht einem eigenen Teilnetz mit zugehörigen IP-Adressbereich, DHCP-Server usw. Jedes Teilnetz soll ein eigenes, zugehöriges WLAN/SSID haben. Jetzt habe ich alles auf einer Bridge geklemmt. Aber: Macht das beim Gäste-WLAN (=VLAN 50) so überhaupt Sinn? Das Gäste-WLAN soll ja möglichst autark ohne Zugriffsmöglichkeit auf andere Netzbereiche sein. Sollte das von der Bridge wieder runter (die FW-Regeln muss ich so oder so konfigurieren)?

Für die WLANs (virtuelle APs) habe ich einen CAP ac dazugekauft, der an Port 10 des RB4011 angeschlossen ist. Port 10 ist als Tagged Uplink konfiguriert und bietet darüber hinaus PoE zwecks Stromversorgung des CAPs.

und dahinter dann MT Router und Telefon jeweils an einem Port des Switches?

Das würde dann bedeuten das man diese Endgeräte mit nacktem Ar... und ohne jeglichen Schutz im Internet bzw. der öffentlichen IP Range des Providers hat. Willst du das wirklich ??
Für den Router ist das kein Problem, denn der hat eine Firewall an Bord aber für die anderen Geräte ??
Sowas laienhaftes ist wohl eher eine Schnappsidee was wir hier mal nicht weiter kommentieren....

möchte ich sämtliche Teilnetze über den RB4011 konfigurieren.

Was ja Sinn macht...

Jetzt habe ich alles auf einer Bridge geklemmt.

Solange diese Bridge als VLAN Bridge mit Layer 3 IP Interfaces dort definiert ist, ist alles richtig und OK so !
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41

Macht das beim Gäste-WLAN (=VLAN 50) so überhaupt Sinn?

Dort ganz besonders !
Ohne eine solche Segmentierung hättest du die Gäste ja dann frei in deinem privaten LAN und die könnten dann fröhlich alles ausschnüffeln und rumhacken. Würdest du das wollen ??
Gäste gehören natürlich strikt abgeschottet und idealerweise noch mit einem Captive Portal abgesichert um Rechtssicherheit zu wahren. Würden die Straftaten über deinen Anschluss begehen und kannst du die Nutzer nicht nachweisen bist du voll haftbar ! Vergiss das nicht.
Wie man sowas intelligent umsetzt kannst du hier sehen:
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Wobei die dynamische VLAN Zuweisung nicht zwingend sein muss. Es geht natürlich auch ohne wenn man mit MSSIDs arbeitet !

Da unser Internetzugang tagsüber wegen Homeoffice gebraucht wird, kann ich nur in Pausen oder nachts Dinge ausprobieren. Daher wäre der Weg, auf die FB komplett verzichten zu können, natürlich der bessere - damit hat man ein funktionierendes Setup auf das man bei anfänglichen Konfig-Fehlern am RB4011 zurückfallen kann. Naja, gerade war so eine Arbeitspause:

Rein DHCP klappt bei unserem LWL-Anschluss nicht. Habe im RB4011 einen PPPoE-Client mit den Zugangsdaten eingerichtet und tatsächlich konnte ich danach von dort aus Pings absetzen.

Eine Sache habe ich dabei aber noch nicht verstanden:

Zuerst hatte ich den PPPoE-Client auf Port ether1 konfiguriert. Das hat nicht funktioniert, obwohl ether1 ein tagged Port (VLAN 7) ist. Danach habe ich den PPPoE-Client am Port vlan7 konfiguriert, das war dann erfolgreich. Ist da was schief oder habe ich was nicht verstanden?

Ergänzend 1: Im Prinzip stellt sich daran dann ja die Anschlussfrage, an welchen Port ich NATten (masquerade) muss, ether1 oder vlan7?

Ergänzend 2: Unter Bridge / VLANs ist eine Übersicht der VLANs inkl. Spalten "Current Tagged" und "Current Untagged". Ist das eine Live-Anzeige (also abhängig von den gerade eingesteckten Kabeln) oder basiert die rein auf der Konfiguration? Unter "Current Tagged" steht zeilenweise für jedes VLAN bridge1 und vlan<X>. Normalerweise hätte ich erwartet, dass hier auch die beiden Ports ether1 (=> VLAN 7) und ether10 (=> tagged Uplink/Trunk mit den VLANs 10-50) unter "Current Tagged" aufgeführt werden

Denkfehler oder Konfigurationsfehler (und wenn ja, ein Tipp wo ich mich verhauen haben könnte)?

(Via ether7 war ich per Winbox mit dem RB4011 verbunden)

Ist da was schief oder habe ich was nicht verstanden?

Da ist dann etwas gehörig schief !
Wenn eth1 ein dediziertes Routing Interface ist (was es als Internet Port auch zwingend sein sollte !!) dann MUSS der PPPoE Client auch auf das Interface eth1 gemappt werden und niemals auf VLAN 7.
Ein VLAN 7 Interface darf es gar nicht geben, denn das wäre fatal. Damit wäre das offene Internet Interface ein Teil deiner lokalen Bridge und damit deiner lokalen Heimnetze !! Ein böses NoGo denn damit exponierst du alles offen ins Internet ! Folgen davon muss man hier sicher nicht beschreiben...

Du hast vermutlich, wie leider so häufig, den fatalen Kardinalsfehler begangen und auch den eth1 Port als Bridge Member konfiguriert, was er aber niemals sein darf !!! Das Tutorial weisst explizit darauf hin !
Er ist ein isolierter und dedizierter Routing Port ins Internet der niemals Member der oder irgendeiner internen Bridge sein darf. Es darf deshalb auch niemals ein VLAN 7 Interface auf dieser Bridge geben das Bezug auf eth1 hat !
Das VLAN Tagging wird dediziert auf der Physik des eth1 Routing Ports eingestellt und dann darauf der PPPoE Client gemappt.
So wäre es richtig und auch absolut wasserdicht !
Vielleicht hilft dir dieser Thread dazu:
Ping-Sequenzen fehlen im LAN sowie sporadische Zugriffsprobleme

Oha, dann habe ich deinen Kommentar (weiter oben, 05.07.)

In deinem Falle ist dann aber der Link über ein VLAN IP Interface und ein entsprechends Tagging am Switch VLAN Port hier die sinnvollere, da technisch bessere Lösung.

total falsch verstanden (der RB4011 hängt ja bei mir direkt am ONT) und werde es nachher so ändern, wie im MT VLAN Tutorial beschrieben - nur eben zusätzlich mit einen VLAN 7 Tag.

ether1 und vlan7 habe ich von der bridge entfernt. Allerdings klappt es immer noch nicht wie es soll:

Eine Verbindung zum Internet bekomme ich nur, wenn ich auf dem VLAN7 Interface den PPPoE Client ziehe; direkt auf ether1 bekomme ich keine Verbindung
Wenn die Internetverbindung via VLAN7 da ist, kann ich trotz NAT von den Clients aus nicht rauspingen (egal ob ich beim Out Interface ether1 oder VLAN7 nehme).

Wenn ich ether1 direkt nehmen soll, muss ich ihm irgendwo das VLAN 7 Tag mitgeben. Unter Interfaces / ether0 finde ich dazu keine Möglichkeit. Daher habe ich dort ein VLAN7 Interface konfiguriert (siehe Screenshot).

Irgendwie stehe ich gerade auf dem Schlauch

Du musst natürlich auf dem eth1 Interface den VLAN Tag 7 auch aktivieren. Tust du das nicht werden die PPPoE Pakete nicht getaggt und das mag der Provider dann nicht.
Hast du das entsprechend gesetzt in den Interface Settings von eth1 ?

Genau diese Funktion suche ich, finde sie jedoch nicht.

Nur sicherheitshalber, @aqui: Du meinst unter Interfaces => Tab Interface => ether1 => In dem Dialog kann man das setzen?

Anbei ein Screenshot vom Status Quo

Eine zusätzliche Funktion zur Aktivierung des VLAN-Tags auf ether1 finde ich nicht. Insofern habe ich an diesem Teil der Konfiguration (siehe o.a. Screenshot) nix geändert.

In der NAT-Regel habe ich nun aber nicht ether1 oder vlan7, sondern den pppoe-client konfiguriert. Damit klappt jetzt zumindest Ping von den Clients ins Internet (auf eine IP).

Beim DNS passt aber was noch nicht. Ein Ping auf eine Webseite vom Client aus, kann nicht aufgelöst werden. In den DNS-Settings ist "Allow Remote Requests" aktiviert. Aber das reicht offenbar nicht. Auffällig ist die Spalte DNS-Server in der Konfiguration der DHCP-Server. Testweise habe ich dort (statt der aktuellen 0.0.0.0), einfach mal die IP des DHCP-Server eingetragen, aber damit klappt die Auflösung ebenfalls nicht. Ich vermute aber, das es genau hier klemmt und entsprechende Einträge vorgenommen werden müssen - aber welche?

Das Problem mit dem DNS ist gelöst. Offenbar hat es nicht funktioniert, weil ich Client-seitig kein renew der LAN-Verbindung vorgenommen habe - dadurch hat der Client die Konfig-Änderungen am RB4011 nicht erhalten bzw. erst nach Ablauf der Lease Zeit. Im Ergebnis stehen da jetzt die IP-Adressen der DHCPs/Gateways drin. Im Augenblick lasse ich die Gateways dort ersteinmal stehen, später kommt da die IP meines PiHole hinein.

Allerdings hat mich das Ganze nochmal tiefer in das MT Manual eintauchen lassen - was sicherlich nicht verkehrt ist

Im MT Manual habe ich unter Layer 2 misconfigs was gefunden, was mich stutzig macht:

Aktuell habe ich nahezu sämtliche Ports (ether2-10 sowie vlans) auf einer Bridge. ether10 ist als Trunk-Port zum CAP gedacht, auf dem die VLANs 10,20,30,50 transportiert werden sollen. So zumindest die Idee:

ether2-5 (untagged, VLAN10)
ether6 (untagged, VLAN20)
ether7 (untagged, VLAN30)
ether8 (untagged, VLAN40)
ether9 (untagged, VLAN50)
ether10 (tagged, VLANs 10,20,30,50) => Trunk-Port zum CAP, VLAN 40 benötigt kein WLAN

Aber wenn ich das MT Manual richtig verstehe, geht das nicht bzw. führt zu Fehlern. Der RB4011 hat genau wie RB2011/3011 zwei Switch-Chips und wenn beide auf einer Bridge liegen bzw. sämtliche Ports Chip-übergreifend gebridged sind, wird es spätestens mit dem als Trunk-Port für alle VLANs ausgelegten ether10 nicht mehr richtig funktionieren. Im Detail habe ich es noch nicht ganz verstanden, wie ich es konfigurieren muss. Aber prinzipiell verstehe ich es so:

ether2-3 (bridge1, untagged, VLAN10)
ether4 (bridge1, untagged, VLAN20)
ether5 (bridge1, tagged, VLANs 10,20) => per Patchkabel mit ether6 verbinden
ether6 (bridge2, tagged, VLANs 30,40,50) => per Patchkabel mit ether5 verbinden
ether7 (bridge2, untagged, VLAN30)
ether8 (bridge2, untagged, VLAN40)
ether9 (bridge2, untagged, VLAN50)
ether10 (bridge2, tagged, VLANs 10,20,30,50) => Trunk-Port zum CAP, VLAN 40 benötigt kein WLAN

Es gibt allerdings einen Unterschied: Im MT Manual ist bereits in der Ursprungs-Config die Zuordnung von physischen und virtuellen Ports aufgeführt. Ich nehmen an, dass damit das gemeint ist, was im Text mit by using the /interface ethernet switch menu gemeint ist. Das VLAN-Filtering erfolgt dabei nicht über die Checkbox an der Bridge, sondern über die Konfiguration auf Ebene der Switch-Chips - um Wirespeed bei den VLANs zu erreichen.

Hat jemand damit Erfahrungen?

Aktuell habe ich nahezu sämtliche Ports (ether2-10 sowie vlans) auf einer Bridge.

Was auch zwingend notwendig ist wenn du mit VLANs arbeitest.

wird es spätestens mit dem als Trunk-Port für alle VLANs ausgelegten ether10 nicht mehr richtig funktionieren.

Kann ich hier auf einem RB2011 der auch 2 Switch Chips hat nicht nachvollziehen. Das funktioniert fehlerlos !
Dort sind 2 separate Bridges definitiv NICHT erforderlich.
Das mit dem Tagging auf eth1 checke ich !

Sorry, ich habe meinen Post parallel gerade noch mal aktualisiert und folgendes hinzugefügt:

Es gibt allerdings einen Unterschied: Im MT Manual ist bereits in der Ursprungs-Config die Zuordnung von physischen und virtuellen Ports aufgeführt. Ich nehmen an, dass damit das gemeint ist, was im Text mit by using the /interface ethernet switch menu gemeint ist. Das VLAN-Filtering erfolgt dabei nicht über die Checkbox an der Bridge, sondern über die Konfiguration auf Ebene der Switch-Chips - um Wirespeed bei den VLANs zu erreichen.

In Kombination mit deiner Erfahrung

Kann ich hier auf einem RB2011 der auch 2 Switch Chips hat nicht nachvollziehen. Das funktioniert fehlerlos !

ist das folglich nur dann der Fall, wenn es um genau die "Wirespeed-Konfiguration" geht. Mmmhh, die spannende Frage lautet dann natürlich, ob es einen merklichen Geschwindigkeitsvorteil gibt (im Prinzip läuft dann ja ein VLAN im Endeffekt auf je einem Kabel) - allerdings muss ich dann wiederum einen weiteren Switch an die Wand klemmen um mehr Access Ports für bestimmte VLANs zu haben

Was das Tagging anbetrifft hast du übrigens Recht. Es geht definitiv nicht auf der Interface Physik selber. Man braucht zwingend ~~eine Bridge~~ ein VLAN Interface !
Das VLAN Interface muss dann unten im Setup fest auf das physische Interface eth1 gebunden werden mit dem entsprechenden VLAN Tag. Eine extra Bridge ist definitiv nicht erforderlich !
Das Ethernet Interface ist kein Member der VLAN Bridge und ist damit dann auch vollkommen von dieser getrennt.
Du solltest den eth1 Port dann aber besser nicht in die Bridge integrieren die den lokalen LAN/VLAN Traffic steuert. Es mach aus Sicherheits Sicht Sinn eine separate Bridhe anzulegen und dort als Port Member lediglich das VLAN 7 Interface und den physischen Port eth1 zu integrieren.
So gehtst du immer auf Nummer sicher das dir offener Internet Traffic nie durch Fehler in der Konfig deine lokalen LANs kompromitiert.

Man braucht zwingend eine Bridge.

Wobei mich das tatsächlich etwas irritiert:

Einerseits macht es Sinn, weil man an der Bridge das VLAN-Filering aktiviert (und damit nach meinem Verständnis praktisch das VLAN-Verhalten).
Andererseits funktioniert meine aktuelle Konfiguration in Richtung des Provider, der ja zwingend ein VLAN7 Tag haben möchte. Und die hat via ether1 Port nicht funktioniert, aber über den virtuellen Port am ether1 (VLAN 7) schon => damit müsste dann ja dort ein VLAN 7 Tagging stattfinden.

Update:

Nach meinem Verständnis ist die konfigurierbare Bridge ja nix anderes als ein "Software" Switch. Vermutung:

Das VLAN-Filtering aktiviert das VLAN-Verhalten auf dem gesamten "Software" Switch und ermöglicht damit "Software-Switching" statt Routing auf Ebene der VLANs.
Wenn nun ein virtueller LAN-Port nicht an einer Bridge hängt, sondern direkt am physischen Interface, dann ist der per se tagged (bei nur einem virtuellen Port könnte dieser auch noch untagged sein, aber man kann da ja beliebig viele drauf definieren, daher läuft es auf tagging hinaus). Konfigurationsseitig lässt sich das bei der Bridge kaum anders lösen, man muss ja irgendwie zwischen untagged und tagged Ports unterscheiden.

Bei den VLAN-Beiträgen der Pascom Brüder gibt es ein paar Hinweise in diese Richtung:

MT Tutorial 17 VLAN Praxisbeispiel => Das Beispiel ist ohne Bridge. Es werden zwei virtuelle Ports angelegt. Beide VLANs gehen am selben physischen Port raus. Hier wird also ganz sicher getagged.
MT Tutorial 18 VLAN Bridge => In den ersten 30s sprechen sie über die Unterschiede a) Routing, b) Bridge und c) Switch-Chip. Unter c) könnte sich womöglich die Lösung verbergen, die bei Vorhandensein zweier Switch-Chips zu den o.a. Problemen führen könnte.

Mmmhhh, ich werde wohl erstmal bei meiner ersten Lösung bleiben. Allerdings würde mich schon sehr interessieren, welchen Geschwindigkeitsvorteil man erzielt, wenn man statt der Software-Bridge die zugrunde liegende Hardware berücksichtigt und die Switch-Chips verwendet.

Wobei mich das tatsächlich etwas irritiert:

Sorry, ich muss mich korrigieren. Eine Bridge ist nicht erforderlich aber ein VLAN Interface !
Du kannst im VLAN Interface unten ja den physischen Target Port angeben und dort das VLAN Tagging setzen. Das erzwingt natürlich KEINE Bridge !

Wenn nun ein virtueller LAN-Port nicht an einer Bridge hängt, sondern direkt am physischen Interface, dann ist der per se tagged

Das stimmt aber ganz genau richtig ist dann...
Wenn nun ein virtueller VLAN-Port nicht an einer Bridge hängt, sondern direkt am physischen Interface, dann ist der per se tagged...und auch isoliert von der lokalen VLAN Bridge.
Alles richtig also...
Sorry nochmals für die Verwirrung !

Was die Bridge anbetrifft ist das richtig. Für maximale L2 Performance muss man darauf achten das die Ports dann auf einem Switch Chip liegen und dann kann man über die Switch Konfig arbeiten. Nachteil ist das etwas geringere Command Set und das man Ports auf unterschiedlichen Switch Chips nicht verbinden kann, klar. Dafür aber maximalen L2 Durchsatz. Siehe auch:
https://cyberlab.pacific.edu/resources/lab-network-hardware
Eine Bridge anlegen bedeutet in dem Sinne einen Software Switch generieren und Software bedeutet immer via CPU. Das bedeutet dann so ein Switch bzw. Bridge ist nicht beliebig skalierbar in Bezug auf Last und Durchsatz. Das muss man berücksichtigen. Vorteil ist dann aber das umfängliche Featureset was man damit hat und kein Limit in Bezug auf die Switch Chips.

Sorry nochmals für die Verwirrung !

Macht nix! Im Augenblick lerne einfach nur dazu (schade ist nur, das ich wegen Arbeit, Familie & Co nur zu beknackten Uhrzeiten hier rumprobieren kann

).

Als Nächstes werde ich mal versuchen den CAP anzuklemmen und für jedes VLAN ein zugehöriges WLAN bzw. einen virtuellen AP zu konfigurieren. Danach FW ... und dann kommen die ganzen Details, wie z.B. VoIP, Abwägung ob OpenVPN vom MT oder doch lieber Wireguard auf Raspi usw. Noch einiges zu tun, aber ich freue mich, bei den Netzwerkthemen dazuzulernen

OpenVPN vom MT...

Erspart dir ja zusätzliche Hardware und wäre vernüftiger:
Clientverbindung OpenVPN Mikrotik

Alternative wäre ggf. L2TP auf dem Mikrotik, denn das würde dir zusätzlich einen extra VPN Client ersparen, denn L2TP Clients haben alle Betriebssysteme und Smartphones gleich von sich aus an Bord:
Scheitern am IPsec VPN mit MikroTik

Der Hausbau fordert leider seinen Tribut und hält mich von Zeit zu Zeit vom Netzwerk fern

Heute habe ich mich an die Konfiguration des cAP gemacht, diesen möchte ich via CAPsMAN vom RB4011 steuern. Anders als im Tutorial vorgesehen, möchte ich je VLAN eine SSID haben.

RB4011
Den CAPsMAN manager habe ich aktiviert, die Zertifikate (certificate, ca-certificate) auf auto gesetzt und die upgrade-policy auf suggest-same-upgrade.

In CAPsMAN habe ich Profile für die Konfig-Gruppen

Configurations
Channels
Datapaths
Security Cfg

angelegt.

Dazu zwei Fragen:

Laufen die 4 SSIDs eigentlich über denselben Kanal oder benötigt man je SSID einen Kanal? Letzteres habe ich erstmal so konfiguriert, aber eine Formulierung im MT-Manual lässt mich da etwas aufhorchen.
Beim Provisioning gibt es immer nur ein Gespann aus 1 Master und 1 Slave-Konfiguration. Da ich 4 VLANs / SSIDs habe, habe ich dort 3 Einträge vorgenommen. Jeder Eintrag hat immer dieselbe Master, aber eine andere Slave-Konfiguration. Ist das so korrekt oder Schwachsinn?

cAP ac
Danach habe ich den cAP per LAN-Kabel an mein Notebook angeschlossen und mich via Winbox damit verbunden. In der Winbox habe ich dann Reset Configuration ausgewählt und den CAPs Mode aktiviert. Anschließend dann den cAP per LAN-Kabel mit dem Tagged Uplink Port des RB4011 verbunden.

Im CAPsMAN (RB4011) taucht unter Remote CAP aber der cAP nicht auf. Ab und an ist dieser dort für 1..2 Sekunden mal zu sehen, aber für gewöhnlich bleibt die Tabelle dort leer. Mir scheint, ich mache hier noch etwas grundsätzliches falsch - hat jemand einen Tipp?

Laufen die 4 SSIDs eigentlich über denselben Kanal

Ja, die nutzen alle den gleichen Kanal wie die Master SSID. Ist ja auch logisch, denn die zusätzlichen SSIDs konfigurierst du ja nur mit einem Virtual AP. Siehe auch hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Du musst nur aufpassen das die einzelnen APs in sich immer einen Kanalabstand von 4 Kanälen haben wenn die sich im Funkbereich überschneiden. Du musst im CapsMan als zwingend mehrere 4 kanalige Channel Profile anlegen und die deinen physischen APs zuweise das das gewährleistet ist sonst funken die alle auf den gleichen Kanälen und stören sich massiv. Siehe dazu auch hier:
Seit WLAN Umstellung von Cisco WAP 200 auf Zyxel NWA3560-N schlechtere Verbindung
Das gilt auch für ggf. vorhandene Nachbar WLANs zu denen auch ein 4 kanaliger Abstand bestehen muss !

Jeder Eintrag hat immer dieselbe Master, aber eine andere Slave-Konfiguration. Ist das so korrekt oder Schwachsinn?

Ist korrekt. Wie sollte es auch anders sein wenn du für jede SSID eine unterschiedliche Authentisierung bzw. Verfahren vorsiehst. Z.B. Gastnetz ist in der Regel immer offen und arbeitet mit einem Captive Portal.

Im CAPsMAN (RB4011) taucht unter Remote CAP aber der cAP nicht auf.

Dann "sehen" sich dein cAP und dein 4011er nicht. Sprich sie sind NICHT im gleichen Layer 2 LAN oder VLAN. Du solltest hier am besten immer das default VLAN 1 nehmen, denn der AP ist wenn er im CapsMan Mode startet immer nackig, kennt also keinerlei VLAN Tags usw. Er sendet auf dem Interface ein CapsMan Hello und such nach dem Controller.
Ggf. hast du also den CapsMan auf ein anderes VLAN oder Layer 2 Netz gemappt. AP und CapsMan Controller müssen sich zwingend "sehen" können im Layer 2 sonst klappt das nicht.
Zusätzlich solltest du zwingend darauf achten das deine cAPs das gleiche Image fahren wie der 4011er

Im Logfile vom RB4011 kann ich sehen, dass der cAP sich in einer Art Dauerschleife befindet:

[C4:AD:34:F5:73:3F/4/6b9b,Join,[F1:39:74:52:34:7F]] joined, provides radio(s): C4:AD:34:F5:73:41,C4:AD:34:F5:73:42
[C4:AD:34:F5:73:3F/4/6b9b,Run,[F1:39:74:52:34:7F]] should auto upgrade
[C4:AD:34:F5:73:3F/4/6b9b,Run,[F1:39:74:52:34:7F]] ask to upgrade, version 6.45.8
[C4:AD:34:F5:73:3F/4/6b9b,Run,[F1:39:74:52:34:7F]] upgrade status: rebooting, disconnect

Könnte das vielleicht die Ursache sein, dass der cAP nur sporadisch unter den Remote CAPs auftaucht? Warum er das Update nicht bekommt, keine Ahnung (die FW sollte dies nicht verhindern, habe sogar testweise die DROP-Regeln deaktiviert)

Ergänzend noch zwei eine andere Frage:

Unter Provisioning sind bei den 3 Master-Slave-Einträgen noch Pseudo-MACs 00:00...00:00 enthalten. Hier muss man vermutlich manuell MAC-Adressen für die virtuellen APs eintragen?
Wenn ich einen Online-Speedtest via RB4011 mache (ether1 <= CAT6a-Kabel => ONT; ether2 <= CAT6a-Kabel => Notebook) dann bleibt der Download bei ca 94 MBit; wenn ich das umstöpsle und die FB statt den RB4011 beim Speedtest verwende, dann lande ich bei 150 MBit. Sind die Ports am RB4011 irgendwo auf 100 MBit gedrosselt oder was könnte da schräg sein?

Es scheitert an einem Mismatch deiner Firmware ! Der Auto Update scheitert weil du das Image nicht provisioniert hast für den AP.
Zudem nutzt du auch noch eine uralt Firmware die gar NICHT mehr supportet ist !

Du solltest also dringenst ALLE deine Komponenten auf die aktuelle Stable 6.47.4 updaten ! https://mikrotik.com/download

Das Firmware Update ist kinderleicht indem du das Image einfach per Drag and Drop in das "File" Windows der Winbox fallen lässt. Alle deine Komponenten cAP ac und RB4011 verwenden ein ARM Image.
Danach Reboot
Nach dem Reboot updatest du die Bootloader Firmware unter System --> Routerboard auch noch und Rebbotest nochmal... Fertisch.
Dann klappt das auch fehlerlos. Solche simplen Basics solltest du aber schon beachten.

Zitat von @aqui:
Das Firmware Update ist kinderleicht indem du das Image einfach per Drag and Drop in das "File" Windows der Winbox fallen lässt. Alle deine Komponenten cAP ac und RB4011 verwenden ein ARM Image.
Danach Reboot
Nach dem Reboot updatest du die Bootloader Firmware unter System --> Routerboard auch noch und Rebbotest nochmal... Fertisch.
Dann klappt das auch fehlerlos. Solche simplen Basics solltest du aber schon beachten.

Super! Das hat geklappt. Der cAP hat nun eine aktuelle Firmware.

Leider sind aber nur 2 der 4 konfigurierten SSIDs zu sehen bzw. per WLAN-Scanner kann man sehen, dass auch nur 2 existieren. Seltsamerweise sind es genau die beiden, die unter Provisioning als erster Eintrag vorhanden sind (btw: die Radio-MACs habe ich dort manuell/frei vergeben):

Sämtliche SSIDs bzw. virtuelle APs liegen auf demselben Kanal (es ist aktuell erst einmal nur ein physischer AP):

Laut MT Manual wird mit jedem Eintrag bzw. mit jeder Slave-Config ein virtueller AP erzeugt. Aber das klappt offenbar nicht, da nur die beiden SSIDs des ersten Eintrags (Master=cfg10 und Slave=cfg20) verfügbar sind. Muss man da noch irgendwo was extra aktivieren?

Ergänzend: Irgendeine Idee für den beobachteten Geschwindigkeitsverlust (Internet/WAN-Anbindung bleibt unter 100 MBit, trotz höherer Verfügbarkeit)?

Der cAP hat nun eine aktuelle Firmware.

Hoffentlich nicht nur der cAP sondern auch der RB4011er ???

Irgendeine Idee für den beobachteten Geschwindigkeitsverlust

Ansehen und umsetzen:
https://www.youtube.com/watch?v=JRbAqie1_AM

Was die 2 nicht sichtbaren Virtual APs anbetrifft, lösche die einmal im CapsMan und lege die neu an. Ggf. hat sich der Controller da "verschluckt".

Der cAP hat nun eine aktuelle Firmware.

Hoffentlich nicht nur der cAP sondern auch der RB4011er ???

Selbstverständlich. Beide sind nun auf demselben Softwarestand.

Irgendeine Idee für den beobachteten Geschwindigkeitsverlust

Ansehen und umsetzen:
https://www.youtube.com/watch?v=JRbAqie1_AM

Leider nein. Das Geschwindigkeitsproblem besteht bereits beim Kabel-LAN:

Beim Online-Speedtest via RB4011 (ether1 <= CAT6a-Kabel => ONT; ether2 <= CAT6a-Kabel => Notebook) bleibt der Download bei ca 94 MBit; wenn ich das umstöpsle und die FB statt den RB4011 beim Speedtest verwende, dann lande ich bei 150 MBit.
Sind die Ports am RB4011 irgendwo auf 100 MBit gedrosselt oder was könnte da schräg sein?

Was die 2 nicht sichtbaren Virtual APs anbetrifft, lösche die einmal im CapsMan und lege die neu an. Ggf. hat sich der Controller da "verschluckt".

Werde ich gleich morgen mal ausprobieren

Das Geschwindigkeitsproblem besteht bereits beim Kabel-LAN:

Oha... Das ist gut möglich das du ein Autonegotiation Problem dort hast. Sprich das automatische Aushandeln von Speed und Duplex Mode scheitert so das eine Seite eine falsche Einstellung hat und es so zu einem Mismatch kommt. Speziell beim Duplex Mode führt das dann zu massiven Kollisionen die ansteigen je mehr Traffic auf dem Port ist.
Das kommt mal vor und kann man leicht fixen indem man die Port Settings statisch einträgt. Am besten immer beidseitig. Den Test solltest du einmal machen.
Ansonsten lokal nur auf der Kupferseite einmal einen Speedtest mit NetIO oder iPerf3 machen:
https://web.ars.de/netio/
http://www.nwlab.net/art/netio/netio.html
https://www.msxfaq.de/tools/3rdparty/netio.htm

Vielen Dank für die Tipps!!

Konnte beide Probleme nun lösen:

Virtuelle APs: War ein Bedienfehler meinerseits. Man muss unter Provisioning nicht mehrere Einträge vornehmen, sondern kann bei einem Eintrag beliebig viele Slave-Configs hinzufügen
100 MBit: Der MT bietet z.B. mit
/interface ethernet monitor <ether>
einen Befehl mit dem man sich die aktuelle Config des jeweiligen Ports anschauen kann. Darüber habe ich herausgefunden, dass es doch am Kabeĺ liegt. Durch Wechsel des LAN-Kabels ist nun wieder alles gut.

Normalerweise ist hier alles mit CAT6A verkabelt, beim Testen der Config habe ich aber aus der Ersatzteilekiste ein CAT6 Kabel gezogen, was aus irgendwelchen Gründen nur 100 MBit bringt. Die weiteren LAN-Kabel aus der Ersatzteilekiste (CAT 5e und CAT6) haben das gleiche Problem: Mit denen bekomme ich kein GBit, sondern nur 100 MBit. Die CAT6er sind geschirmt (SSTP). Seltsam seltsam.

Mal eine Frage bzgl. der Firewall im MT (iptables): Sollte man beim Festlegen der Regeln eher

IP-basiert (z.B. mit "source address"); oder
VLAN-basiert (z.B. mit "in interface")

arbeiten?

Beide Varianten führen häufig ans Ziel, aber was ist das bessere Mittel?

In einigen Fällen geht nur eines von beiden, aber ich meine hier den Fall, wo beides parallel geht.

Sollte man beim Festlegen der Regeln eher...

Eine goldene Regel gibt es da nicht. Das muss man immer individuell nach seiner eigenen festgelegten Security Policy entscheiden und WAS genau man blocken will. Ein pauschales besser oder schlechter gibt es da nicht wirklich.

* Ergänzend 2: Unter Bridge / VLANs ist eine Übersicht der VLANs inkl. Spalten "Current Tagged" und "Current Untagged". ...

Ist das je beantwortet worden, den mir ist die Angabe auch schleierhaft.

Zitat von @PackElend:
Ist das je beantwortet worden, den mir ist die Angabe auch schleierhaft.

Das muss eine "Live-Anzeige" sein und dürfte das Winbox-Äquivalent zum Befehl

/interface bridge vlan print

sein.

Wenn ich z.B. an einem als Untagged konfigurierten Port kein Gerät dran habe, dann taucht in der Liste der Port nicht mehr auf; wenn ein Gerät dranhängt, dann wird die betreffende VLAN-Zeile aktualisiert.

Ist das je beantwortet worden, den mir ist die Angabe auch schleierhaft.

Das besagt welche und wieviele Interfaces fürs Tagging konfiguriert sind bzw. ungetaggt sind. Die Anzeige ist aber nur aktiv wenn auf diesen Interfaces auch aktive Links sind. Kollege @Tripod hat es oben schon richtig gesagt.
Interfaces die rein nur konfiguriert sind aber ohne aktiven Link werden nicht angezeigt. Ist in gewissem Sinne auch logisch, denn warum sollte man etwas anzeigen wenn es inaktiv ist ?!

tut mir wirklich leid aber der Groschen fällt bei mir einfach nicht.

Ich kratze mal meinen ganzen Hinschmalz zusammen und versuche es mal anhand von meine VLANs zu erklären, relevant sind hier VLAN 10 (MGMT) vom Lieferanten, dynamisches VLAN 1 (default, fallback, auto) und VLAN 100 (Gegensprechanlage) von mir erstellt.

Am CRS328-24P sind ether01 bis ether10 verwendet, an ether16 war mein Gerät kurzzeitig angeschlossen. Das CRS328-24P ist über einen uplink mit einem CRS328-20S verbunden, welches wiederum über einen uplink mit einem CCR1009 verbunden ist. Momentan wird nur die Gegensprechanlage versorgt, da die Netzwerkumbauten noch nicht abgeschlossen sind, final ist es so:

FTTH -> CCR1009 __ CRS328-20S __ CRS328-24P
        |   |      |   |         |_PoE to Intercom System
        |   |      |   | 
        |   |      |   |__fiberes to multiple Hex S with connected cAP ac (WiFi, LAN per flat)
        |   |      |__fibres to Hex PoE what powers some hAP ac3 for common area WiFi etc. 
        |   |       
        |   |__DMZ  
        |___Terminal PC for Management, accessible via remote access (set configuration, don't change a running system)   
         

Es ist eine gemischte Sammlung von 2N Geräten bei der Gegensprechanlage installiert worden, manche Geräte kommen mit Hersteller OS, manche mit Android. Erstes arbeiten mit VLAN-Tag, Zweiters leider nicht, obwohl Android dies unterstützen sollte. Dadruch ergibt sich folgende Einstellungen auf den Ports:

ether01: untagged traffic VLAN ID=---, PVID=100	   ether05:   tagged traffic VLAN ID=100, PVID=001	   ether09: untagged traffic VLAN ID=---, PVID=100	     		
ether02:   tagged traffic VLAN ID=100, PVID=001	   ether06:   tagged traffic VLAN ID=100, PVID=001	   ether10:   tagged traffic VLAN ID=100, PVID=001	     		
ether03:   tagged traffic VLAN ID=100, PVID=001	   ether07: untagged traffic VLAN ID=---, PVID=100	     		
ether04:   tagged traffic VLAN ID=100, PVID=001	   ether08: untagged traffic VLAN ID=---, PVID=100	     		

Das Management VLAN10 ist noch auf allen Port aktiv, da hier noch gewartet wird, bis alle Installationsarbeiten abgeschlossen sind.

Das Gegensprechanlagen VLAN100 ist nur auf den Port 01 - 10 aktiv, sowie dem Uplink.

2021-04-05 15_14_03-admin@48_8f_5a_b1_0b_ad (mt_crs328-24p) - winbox (64bit) v6.47.8 on crs328-24p-4

Das dynamische VLAN ist mir noch schleierhaft aber es ergibt sich vielleicht aus der Antwort auf meine eigentliche Frage

2021-04-05 15_12_42-admin@48_8f_5a_b1_0b_ad (mt_crs328-24p) - winbox (64bit) v6.47.8 on crs328-24p-4

Meinem Verständnis nach wird mit den VLAN-Tags wie folgt umgegangen:

ingress, Bridge -> Ports -> Bridge Port -> VLAN PVID (priority tagged nicht speziell berücksichtigt):

Untagged traffic eingehend:

frame-types=admit all & Ingress Filtering=off

Die VLAN-Markierung wird laut PVID hinzugefügt, traffic geht rein.

frame-types=admit only VLAN tagged all & Ingress Filtering=off

dropped, da kein VLAN-Tag im Traffic

frame-types=admit only untagged and priority tagged & Ingress Filtering=off

Die VLAN-Markierung wird laut PVID hinzugefügt, traffic geht rein.

frame-types=any & Ingress Filtering=ON

Die obigen Regeln angewandt, nachfolgend wird geprüft, ob die VLAN-ID als Regel im egress, VLAN-Filter (siehe unten) hinterlegt ist, sprich, diese VLAN-ID auf diesem

tagged traffic eingehend:

frame-types=admit all & Ingress Filtering=off

die VLAN-Markierung wird gelesen aber nicht verändert, traffic geht rein.

frame-types=admit only VLAN tagged all & Ingress Filtering=off

die VLAN-Markierung wird gelesen aber nicht verändert, traffic geht rein.

frame-types=admit only untagged and priority tagged & Ingress Filtering=off

dropped, da VLAN-Tag vorhanden

frame-types=any & Ingress Filtering=ON

Die obigen Regeln angewandt, nachfolgend wird geprüft, ob die VLAN-ID als Regel im egress, VLAN-Filter (siehe unten) hinterlegt ist, Port erlaubt ist. Wenn so, Traffic geht rein, sonst dropped.

egress, Bridge -> VLAN -> Bridge VLAN. Ich gehe davon aus, hierbei handelt es ich um die Egress-Regel.

Untagged traffic ausgehend: traffic dropped, gibt es gar nicht, da Default VLAN1 vergeben wird, wenn es keinen VLAN-Tag hat. Daraus ergeben sich andere Implikationen, wenn ich mich durch Wiki etc lese, dass wird dann hier zu viel (?)
tagged traffic ausgehend, VLAN ID wird geprüft:

Es gibt überhaupt keine Filterregel für diese VLAN ID: traffic dropped
Regel für VLAN-ID existiert:

Port, wo der Traffic auftritt, ist gelistet als Tagged: VLAN ID wird nicht verändert
Port, wo der Traffic auftritt, ist gelistet als Untagged: VLAN ID wird entfernt
Port, wo der Traffic auftritt, ist nicht gelistet: traffic dropped

Was ich jetzt erwartet hätte, wäre, dass ich in der Spalte Current Tagged nur die Ports gelistet werden, worauf das VLAN verwendet wird und Traffic mit VLAN-Tag unterwegs ist. In der Spalte Current Untagged entsprechend Traffic ohne VLNA-Tag
Dies jeweils nach PVID Anwendung, bzw. dem Entfernen des VLAN-Tag.

Warum listet VLAN10 nun ports (ether1 bis ether 10) auf denen nun überhaupt keine Traffic mit der VLAN-ID 10 unterwegs ist

?

VLAN100 ist da schon logischer, es hat nur Regel für Port 01-10 und unterscheided, wei weiter oben aufgelistet. Merkwürderigerweise ist aber das Trnk-Port sfp-sfpplus1 nicht gelistet.

Was das dynamischen VLAN1 da macht, ist mir sowieso schleierhaft und warum die Brdige be.ether-sfp selber auch ein VLAN-Tag hat, bzw. entfernt wird...

Ich hoffe ich habe hier nun niemanden erschlagen mit all den Informationen aber bei mir stappeln sich die Fragezeichen.

Das Gegensprechanlagen VLAN100 ist nur auf den Port 01 - 10 aktiv, sowie dem Uplink.

Tagged oder UNtagged ??
Zumindestens für Port 02, 03, 04, 05, 06 und 10 ist deine Angabe falsch, denn dort ist fälschlicherweise die Port PVID auf 1 statt auf 100 wie bei den anderen Ports. Angeschlossene Endgeräte landen also nicht im VLAN 100 sondern im VLAN 1 wie man an deinem Output oben ja sehen kann.
Diese 10 Ports sind also entgegen deiner Angabe falsch konfiguriert ! Zumindestens sind sie nicht einheitlich im VLAN 100 konfiguriert wie du das fälschlicherweise angibst.

Das Management VLAN10 ist noch auf allen Port aktiv

Aber nur tagged ! Sprich Endgeräte müssen an diesen Ports mit einem gültigen VLAN 10 Tag ankommen ansonsten wird untagged Traffic immer in das VLAN geforwardet was als Port PVID dort konfiguriert ist !
Du machst hier vermutlich fundamentale Denkfehler wie PVID Traffic, getaggter Traffic und der Mode Filter zu sehen ist.
Zumal auch deine gepostete Konfig nicht mit dem übereinstimmt was du oben im Text behauptest.
So drehen wir uns hier nur total verwirt im Kreis.

Mal ganz davon abgesehen davon das eine 3er Switch Kaskade eher von sehr schlechtem Netzwerk Design zeugt...aber das ist eine andere Baustelle.

der Router hat nur ein Ausgang für DAC, was hier genutzt wird, Link Aggregation könnte auch gemacht werden, evtl. braucht es dies gar nicht aber so komme ich nicht in die Situation dies testen zu müssen.
Hatte damals leider keine bessere Kombination gefunden für min. 10 SFP für Glasfaser und min. 10 PoE für die Gegensprechanlage (mit Aussicht auf zukünftiger Erweiterung) .

Tagged oder UNtagged ??

Geräte welche untagged arbeiten, sind an folgenden Ports.
Ihnen wird die VLAN-ID 100 hinzugefügt für den Verkehr zum Uplink:

ether01: untagged traffic VLAN ID=---, PVID=100
ether07: untagged traffic VLAN ID=---, PVID=100
ether08: untagged traffic VLAN ID=---, PVID=100
ether09: untagged traffic VLAN ID=---, PVID=100

add bridge=br.ether-sfp comment="UG Ost" interface=ether1 pvid=100  
add bridge=br.ether-sfp comment="1.OG Ost" interface=ether7 pvid=100  
add bridge=br.ether-sfp comment="1.OG West" interface=ether8 pvid=100  
add bridge=br.ether-sfp comment=2.OG interface=ether9 pvid=100

Geräte mit VLAN-TAG, VLAN-ID=100, sind an folgenden Ports, PVID=1 ist somit nicht relevant:

ether02:   tagged traffic VLAN ID=100, PVID=001	   ether06:   tagged traffic VLAN ID=100, PVID=001
ether03:   tagged traffic VLAN ID=100, PVID=001	   ether10:   tagged traffic VLAN ID=100, PVID=001
ether04:   tagged traffic VLAN ID=100, PVID=001	   	     		
ether05:   tagged traffic VLAN ID=100, PVID=001	   	   

add bridge=br.ether-sfp comment="UG Nord" interface=ether2  
add bridge=br.ether-sfp comment="UG West" interface=ether3  
add bridge=br.ether-sfp comment="EG Ost" interface=ether4  
add bridge=br.ether-sfp comment="EG Nord" interface=ether5  
add bridge=br.ether-sfp comment="EG West" interface=ether6  
add bridge=br.ether-sfp comment=3.OG interface=ether10  		

Die Bridge nimmt den Tag für den Verkehr zu den Geräten wieder weg wo nötig (ether1 und ether 7-9)

add bridge=br.ether-sfp comment=Gegensprechanlage tagged="ether2,ether3,ether4\  
    ,ether5,ether6,ether10,sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4\
    " untagged=ether1,ether7,ether8,ether9 vlan-ids=100  

Zumal auch deine gepostete Konfig nicht mit dem übereinstimmt was du oben im Text behauptest.

besser nun?
Sie bekommen alle die IP vom DHCP für das VLAN100, soweit klappt es und sie erreichen sich auch untereinander

Das sieht ja schon ganz anders aus und nun passt es wieder.

Einziger Fehler ist das du die UNtagged Ports auch in die Bridge VLAN Konfig eingetragen hast, das ist unnötig, denn das wird eh fest über die PVID vorgegeben. Kann man besser entfernen.
Ansonsten ist das jetzt alles korrekt so !

Zitat von @aqui:
> Das sieht ja schon ganz anders aus und nun passt es wieder.

danke

Zitat von @aqui:
Einziger Fehler ist das du die UNtagged Ports auch in die Bridge VLAN Konfig eingetragen hast, das ist unnötig, denn das wird eh fest über die PVID vorgegeben. Kann man besser entfernen.

Ist damit

untagged=ether1,ether7,ether8,ether9 vlan-ids=100

gemeint?
Ich ich bin mir da nicht sicher, die PVID ist für mich nur für eingehende Daten. Die Rückmeldungen von anderen Geräten zu einem UNtagged Geräte kommt ja erstmal mit einem VLAN-Tag, welcher entfernt werden muss, bevor er das Port zu dem UNtagged Gerät, verlässt. Dies passiert meines Wissens nur in der Bridge VLAN Konfig

Das Mysterium der Spalten Current Tagged und Current Untagged klärt dies aber nicht auf?

PVID gilt auch für ausgehenden untagged Traffic bzw. bestimmt generell in welches VLAN ungetaggter Traffic ein- und ausgehend vermittelt wird ! Die untagged Ports müssen nicht zwingend im VLAN Setup der Bridge konfiguriert werden.
Current tagged und untagged zeigen nur aktive Ports an also welche mit aktivem, physischen Link. Rennt hier auf allen MT Switches mit Router OS fehlerlos und passt exakt zum aktuellen Status !

Zitat von @aqui:
PVID gilt auch für ausgehenden untagged Traffic bzw. bestimmt generell in welches VLAN ungetaggter Traffic ein- und ausgehend vermittelt wird ! Die untagged Ports müssen nicht zwingend im VLAN Setup der Bridge konfiguriert werden.

ich habe doch nur noch Tagged-Traffic auf der Bridge/Switch/Router, die

untagged=ether1,ether7,ether8,ether9 vlan-ids=100

sorgt doch dafür, dass das VLAN-Tag entfernt wird, bevor es das Port verlässt und dann zum angeschlossenen Gerät geht.
PVID ist mir nicht bekannt, dass es den VLAN-Tag entfernt, wenn Traffic das Port verlassen möchte nach aussen.
Wenn ich deine Aussage richtig verstehe, verpasst es ausgehendem Traffic, welcher untagged ist, den VLAN-Tag welcher in PVID definiert ist, welcher hier (noch nicht) existiert.
Die vorherige Regel, greift dann hoffentlich erst, nachdem PVID aktiv war, ansonsten hat jeder ausgehende Traffic ein VLAN-Tag, womit nicht zwingend umgehen kann.

Zitat von @aqui:
Current tagged und untagged zeigen nur aktive Ports an also welche mit aktivem, physischen Link. Rennt hier auf allen MT Switches mit Router OS fehlerlos und passt exakt zum aktuellen Status !

einen aktivem, physischen Link gibt es nur auf Port 01-10 (und 16). Über Port 01-10 läuft nur Traffic mit VLAN-ID=100, warum sagt dann VLAN10 dass auf ether 01 bis 10 tagged traffic unterwegs ist, obwohl manche Port UNtagged traffic ausgeben???

PVID ist mir nicht bekannt, dass es den VLAN-Tag entfernt, wenn Traffic das Port verlassen möchte nach aussen.

Tut es aber !
Aller Traffic der Untagged am Port reinkommt wird ins PVID VLAN geforwardet. Aller Traffic der aus dem PVID VLAN kommt wird ebenfalls untagged ausgesendet. PVID wirkt beidseitig.
Kannst du auch selber sehen wenn du einfach nur mal einen Wireshark Sniffer an diesen Port klemmst. Du siehst dann alle Broad- und Multicast Frames aus dem PVID VLAN untagged an dem Port. Alle tagged VLANs an dem Port kommen dann mit einem 801.1q Tag dort an.
Ein einfacher Wireshark Trace hatte dir da Gewissheit verschafft ! Aber egal...

Wenn ich deine Aussage richtig verstehe, verpasst es ausgehendem Traffic, welcher untagged ist, den VLAN-Tag welcher in PVID definiert ist, welcher hier (noch nicht) existiert.

Hast du falsch verstanden... Siehe oben. Aller PVID Traffic ist an diesem Port untagged, egal ob inbound oder outbound. Das war damit gemeint. Bei getaggten VLANs wird an dem Port immer der VLAN Tag mitgesendet. Egal ob inbound oder outbound.

aktivem, physischen Link gibt es nur auf Port 01-10 (und 16).

Dann sollte in der Anzeige die Ports 1 bis 10 so stehen:
Currently untagged vlan 100 = 1, 7, 8, 9
Currently untagged vlan 1 = 2, 3, 4, 5, 6, 10
Currently tagged vlan 100 = 2, 3, 4, 5, 6, 10

warum sagt dann VLAN10 dass auf ether 01 bis 10 tagged traffic unterwegs ist

Das kann nur der Fall sein wenn im Bridge VLAN Setup das VLAN 10 für diese Ports irgendwie eimngetragen ist. Wenn es dort gar kein VLAN 10 gibt dann ist das ein Bug in der Anzeige. Ggf. hilft dann mal ein Reload der Box.

Zitat von @aqui:
Ein einfacher Wireshark Trace hatte dir da Gewissheit verschafft ! Aber egal...

sorry heute ist mein Bewegungsradius sehr eingeschränkt, mich hatte ne leichte Magen-Darm umgehauen und wenn es auch nicht weit von unsere Wohnung in den Keller ist, halte ich lieber in der Nähe vom stillen Örtchen auf...und morgen kommen die Elektriker, kann ja heiter werden

Zitat von @aqui:
Aller Traffic der Untagged am Port reinkommt wird ins PVID VLAN geforwardet. Aller Traffic der aus dem PVID VLAN kommt wird ebenfalls untagged ausgesendet. PVID wirkt beidseitig.

Kannst du auch selber sehen wenn du einfach nur mal einen Wireshark Sniffer an diesen Port klemmst. Du siehst dann alle Broad- und Multicast Frames aus dem PVID VLAN untagged an dem Port. Alle tagged VLANs an dem Port kommen dann mit einem 801.1q Tag dort an.

Wenn ich deine Aussage richtig verstehe, verpasst es ausgehendem Traffic, welcher untagged ist, den VLAN-Tag welcher in PVID definiert ist, welcher hier (noch nicht) existiert.

Ich versuche es mal so, ich habe die vorherige Beschreibung mal angepasst. Hoffe es stimm nun:

~~ingress~~ VLAN action at Port:, Bridge -> Ports -> Bridge Port -> VLAN PVID

Untagged traffic EINGEHEND:

frame-types=admit all & Ingress Filtering=off

Die VLAN-Markierung wird laut PVID hinzugefügt, traffic geht rein.

frame-types=admit only VLAN tagged all & Ingress Filtering=off

dropped, da kein VLAN-Tag im Traffic

frame-types=admit only untagged and priority tagged & Ingress Filtering=off

Die VLAN-Markierung wird laut PVID hinzugefügt, traffic geht rein.

frame-types=any & Ingress Filtering=ON

Die obigen Regeln angewandt, nachfolgend wird geprüft, ob die VLAN-ID als Regel im egress, VLAN-Filter (siehe unten) hinterlegt ist, sprich, diese VLAN-ID auf diesem

tagged traffic EINGEHEND:

frame-types=admit all & Ingress Filtering=off

die VLAN-Markierung wird gelesen aber nicht verändert, traffic geht rein.

frame-types=admit only VLAN tagged all & Ingress Filtering=off

die VLAN-Markierung wird gelesen aber nicht verändert, traffic geht rein.

frame-types=admit only untagged and priority tagged & Ingress Filtering=off

dropped, da VLAN-Tag vorhanden

frame-types=any & Ingress Filtering=ON

Die obigen Regeln angewandt, nachfolgend wird geprüft, ob die VLAN-ID als Regel im egress, VLAN-Filter (siehe unten) hinterlegt ist, Port erlaubt ist. Wenn so, Traffic geht rein, sonst dropped.

Untagged traffic AUSGEHEND (falls es den Fall überhaupt gibt):

Die VLAN-Markierung wird laut PVID hinzugefügt, traffic geht raus

tagged traffic AUSGEHEND:

VLAN-ID und PVID sind nicht identisch:

traffic bleibt unverändert

VLAN-ID und PVID sind identisch:

traffic wird die VLAN-ID entfernt

aktivem, physischen Link gibt es nur auf Port 01-10 (und 16).

Dann sollte in der Anzeige die Ports 1 bis 10 so stehen: Currently untagged vlan 100 = 1, 7, 8, 9
Currently untagged vlan 1 = 2, 3, 4, 5, 6, 10
Currently tagged vlan 100 = 2, 3, 4, 5, 6, 10

Currently untagged vlan 1 = 2, 3, 4, 5, 6, 10

warum sagt dann VLAN10 dass auf ether 01 bis 10 tagged traffic unterwegs ist

Wenn du mir nun sagst, warum Currently untagged vlan 1 = 2, 3, 4, 5, 6, 10 richtig ist, komme ich hoffentlich endlich dahinter.

Sieh dir oben deinen von dir selber geposteten Ausdruck der Port PVIDs an. Alle diese Ports 2, 3, 4, 5, 6 und 10 sind mit der PVID 1 untagged fürs VLAN 1 eingetragen.
Sowie diese Ports dann einen aktiven Link haben werden sie folglich auch untagged für das VLAN 1 angezeigt weil aller VLAN 1 Traffic in und outbound durch die PVID an diesen Ports anliegt !
Eigentlich doch ganz logisch und einfach, oder ?! 😉

sprich meine Erweiterung der Aussage um:

Untagged traffic AUSGEHEND (z.B. durch das CPU Port/Bridge):

Die VLAN-Markierung wird laut PVID hinzugefügt, traffic geht raus

tagged traffic AUSGEHEND:

VLAN-ID und PVID sind nicht identisch:

traffic bleibt unverändert

VLAN-ID und PVID sind identisch:

traffic wird die VLAN-ID entfernt

ist korrekt?

Das heisst, dass jeglicher Traffic mit der VLAN-ID=1, der aus den Ports 2, 3, 4, 5, 6 und 10 heraus möchte, wir der VLAN-Tag entfernt, korrekt?
Somit macht
Currently untagged vlan 100 = 1, 7, 8, 9
Currently untagged vlan 1 = 2, 3, 4, 5, 6, 10
Currently tagged vlan 100 = 2, 3, 4, 5, 6, 10
tatächlich Sinn und alles ist logisch

Hier gleich noch eine weitere Frage, wo steht dies im MT-Wiki, finde dazu nichts darin, was drauf hinweisst.

Abrunden möchte ich es noch mit der Frage nach der Brdige. Die Bridge arbiert als CPU-Port, sprich WinBox Zugriff etc. geht über diese aber was ist das CPU-Port, wenn keine Bridge eingerichtet ist? Ist dies dann das Port wo mein aktiven Link draufsitzt (soweit nicht von Firewall entsprechend eingeschränkt)?

Ich frage, da ich meine langsam zu verstehen, warum ich über WinBox alle Geräte sich ereichen lassen über MAC, wenn ich mit dem CRS328-24P verbinde aber nur den Router sehe, wenn ich mit dem CCR1009 verbinde.
Je nachdem wie die PVIDs etc. gesetzt sind sehe ich halt die anderen Geräte oder halt nicht.
Wenn die CPU/Bridge über eine IP erreichbar sein soll, braucht sie noch ne IP und evtl. Routen zwischen Subnetzen. Wenn auf der Bridge VLAN-Filtering und evtl. Ingress Filtering aktiv sind, gelten dort auch das von mir beschriebene Regelwerk.

Wenn das nun so stimmt, habe ich es wohl begriffen

Hier gleich noch eine weitere Frage, wo steht dies im MT-Wiki

https://www.andisa.net/wp-content/uploads/2018/11/VLAN-configuration-pos ...

Je nachdem wie die PVIDs etc. gesetzt sind sehe ich halt die anderen Geräte oder halt nicht.

Das ist klar, denn die PVID bestimmt massgeblich über die Layer 2 Connectivity. Das vergessen viele leider. Dummerweise supportet MT wie auch NetGear, TP-Link, Zyxel usw. kein Auto PVID wie Cisco u.a. Hersteller was die ganze Sache für Laien etwas komplizierter macht, da man immer zusätzlich zum Tagging auch das Port PVID Setup auf dem Radar haben muss. Mit Auto PVID wäre das erheblich einfacher.

sprich WinBox Zugriff etc. geht über diese

Nein, das ist Unsinn. Eine Bridge ist dafür nicht notwendig es geht auch ohne.
WinBox hat immer 2 Optionen: Entweder geht man über die IP oder über die Mac Adresse. Das Tolle an WB ist das es auch eine Verbindung völlig unabhängig von IP über die Layer 2 Mac Adresse machen kann. So wird man immer unabhängig von der IP Adressierung. Ein Riesenvorteil z.B. im Vergleich zum WebGUI was immer eine saubere IP Infrastruktur braucht zum konfigurieren.

Wenn das nun so stimmt

Das stimmt so...

Zitat von @aqui:

Hier gleich noch eine weitere Frage, wo steht dies im MT-Wiki

https://www.andisa.net/wp-content/uploads/2018/11/VLAN-configuration-pos ...

da ist es gut versteckt, sollte hier erwähnt sein:
https://help.mikrotik.com/docs/display/ROS/Bridge#Bridge-BridgeVLANFilte ...
https://help.mikrotik.com/docs/display/ROS/Bridge+VLAN+Table
aber MT ist eher

was die ganze Sache für Laien etwas komplizierter macht,

sprich WinBox Zugriff etc. geht über diese

da habe ich mich falsch ausgedrückt, wenn VLAN eingerichtet ist muss man darauf achten, sonst hat es wir bei meinen gelieferten MTs, dass ich von vorne nur den Router sehe und von hinten aber alle Geräte.
Ich hatte eine Teststrecke CCR1109-->hEX S-->cAP ac aufgebaut, um mal zusehen, wie es mit CAPsMAN klappt, bzw. wie weit das WLAN reicht. Da hatte ich alle über WB erreicht egal wo ich verbunden war, jetzt kinkelt es wieder

Guten Abend,
ich bin es mal wieder. Ich betrachte

/ interface bridge port

und

/ interface bridge vlan

momentan aus einem anderem Blickwinkel.

Eigentlich ist / interface bridge port voll und ganz ausreichend, wenn man nur Access-Ports (APs) hat.
Wenn / Ingress Filtering = yes ist, bekommt jedes Packet beim Eintritt in das Switch einen 802.1Q-TAG und der Switch-Chip füllt seinen Forwarding information base - Wikipedia dementsprechend. Wenn noch ein Router auf dem gleichen Gerät konfiguriert ist (sprich DHCP etc.) wird auch der Address Resolution Protocol - Wikipedia Table gefüllt.
Hierfür brauche ich jetzt keine weiteren Einstellungen, soweit auf dem Port learning = yes ist.
Somit ist es so, dass wenn etwas über einen Port rein kommt und dass Ziel ist im gleichen VLAN ist, auch der Ziel-AP bekannt ist. Der Switch-Chip weiss dann, was zu tun ist.
Wenn es das Packet in ein anderes Netz gehen soll, geht es auch noch so, wenn nur ein Router für ein VLAN konfiguriert ist.

Wenn nun ein zweiter DHCP-Server etc. ins Spiel kommt, wird das bridge port (CPU-Port zur Switch/Router CPU) plötzlich zum Trunk Port (TP).
Erst wenn ein TP (oder Hybrid Port) ins Spiel kommt, sei es auf dem Bridge Port oder auf einem anderen physisches Port, brauche ich / interface bridge vlan.
Damit teile ich dem Switch (oder Router) mit, welche VLANs auf diesem TP, einem physischen Port oder Bridge Port, erwartet werden, bzw. gefiltert werden sollen.
Es kommt auch hinzu, dass der Switch-Chip dann das TP dem jeweiligen VLAN-FDI hinzufügt.

Ist es wirklich so schlicht?

Bei der Aussage

Es kommt auch hinzu, dass der Switch-Chip dann das TP dem jeweiligen VLAN-FDI hinzufügt.

habe ich noch Bauchweh.
Ist eher nicht so, dass der Switch-Chip bei einer unbekannten Destination-MAC, das zugehörige einkommende Ethernet II frame an alle Ports sendet.
Nun ist es so, dass der Port-Filter nur Packets mit übereinstimmenden 802.1Q-TAG (der PVID) weiterleitet. Somit sind nur Geräte an APs, welche zu diesem VLAN gehöhren in der Lage zu antworten. Dadurch ergibt sich die Einteilung der Ports per VLAN automatisch.

wenn ich nun nicht meilenweit weg bin, sehe ich noch Hoffnung für mich und MikroTik: kaskadisches Core-Netzwerk CCR-CRS-CRS mit Satelliten-Swichtes+APs - ein Versuch einer Anleitung von A-Z könnte etwas nachhaltiges werden...

Eigentlich ist Port voll und ganz ausreichend, wenn man nur Access-Ports (AP) hat.

Ja, da hast du Recht. Bei Access Ports ist einzig und allein die Port PVID im Bridge Setup relevant, nichts anderes !

Hierfür brauche ich jetzt keine weiteren Einstellungen

Das ist richtig für AP Ports.

Wenn nun ein zweiter DHCP-Server etc. ins Spiel kommt, dann wird das bridge port (CPU-Port zur Switch/Router CPU) plötzlich zum Trunk Port.

Das ist völliger Quatsch. Nur weil man einen DHCP Server konfiguriert setzt sich niemals ein Port von Geisterhand selber in den Tagged Mode. Vergiss diesen Unsinn also ganz schnell wieder !
Was richtig ist und wo du recht hast ist das Ports die die VLAN Information transportieren sollen, also Tagged Ports, im Bridge VLAN Setup mit ihren Ports definiert sein müssen !
Das hiesige VLAN_Schnellschulungs_Tutorial (etwas runterscrollen) erklärt das mit einfachen, leicht verständlichen Worten.
Dein "kaskadisches Netzwerk" (kein kaukasisches !) wird garantiert etwas ganz Nachhaltiges werden wenn du es alles richtig machst.

@aqui habe gerade das Kommentar angepasst, leider gab es ein Zwangsneustart und es ist erst jetzt (nach deiner Antwort raus), aber Sinn bleibt der gleiche

Zitat von @aqui:
Das ist völliger Quatsch. Nur weil man einen DHCP Server konfiguriert setzt sich niemals ein Port von Geisterhand selber in den Tagged Mode. Vergiss diesen Unsinn also ganz schnell wieder !

Das ist etwas unglücklich ausgedrückt. Ich wollte darauf hinauf, dass ich zusätzliche Dienste aufschalte, welche eine Netzwerksegmentierung verlangen, sonst geht es schief. Ich erwarte nicht, dass sich die VLANs wie von Zauberhand selber konfigurieren.

Was richtig ist und wo du recht hast ist das Ports die die VLAN Information transportieren sollen, also Tagged Ports, im Bridge VLAN Setup mit ihren Ports definiert sein müssen !
Das hiesige VLAN_Schnellschulungs_Tutorial (etwas runterscrollen) erklärt das mit einfachen, leicht verständlichen Worten.

nur um sicher zu gehen,

deine Tagged Ports sind meine Trunk Ports?
/ interface bridge vlan ist allein für die Konfiguration dieser Tagged Ports / Trunk Ports?

Zitat von @aqui:
Dein "kaskadisches Netzwerk" (kein kaukasisches !) wird garantiert etwas ganz Nachhaltiges werden wenn du es alles richtig machst.

face-wink

Merci

, ich fange einfach mal von ganz vorne an und hoffe den einen oder anderen mitzunehmen.
Die Schwierigkeit ist doch, dass alles Infos zu erfassen. Ich unternehme jetzt den Versuch, diese Sammeln und zu Kanalisieren.

Ich erwarte nicht, dass sich die VLANs wie von Zauberhand selber konfigurieren.

Das hätte einen Netzwerk Admin auch schwer verwundert...

deine Tagged Ports sind meine Trunk Ports?

Ja ! Tagged Ports, Trunks, Tagged Uplinks usw. besagen immer dasselbe. Allerdings muss man beim Begriff "Trunk" höllisch aufpassen, denn der ist immer doppeldeutig. Die Hälfte aller Hersteller benutzen diesen Begriff ausschliesslich für LACP LAGs also Link Aggregation.
In so fern ist es immer intelligenter und zudem eindeutiger von Tagged Ports oder Tagged Uplinks zu reden um immer Klarheit zu schaffen und Missverständnisse sicher zu vermeiden. Besonders wenn man wie in einem Forum nicht verbal kommunizieren kann.

Zitat von @aqui:
In so fern ist es immer intelligenter und zudem eindeutiger von Tagged Ports oder Tagged Uplinks zu reden um immer Klarheit zu schaffen und Missverständnisse sicher zu vermeiden.

voll dabei, möchte ich dann entsprechend festhalten. Mich treibt der Begriff Bridge bei MT hier und da in den Wahnsinn, da diese doch viel mehr macht als einfach nur eine Trennung von Collision-Domains (mein Verständnis die Aufgabe einer Bridge)

stimmt
/ interface bridge vlan ist allein für die Konfiguration dieser Tagged Ports / Trunk Ports?
auch soweit?

ich muss mich mal wieder selbst korrigieren.
Nachdem ich zum x-ten mal lesen von Bridge VLAN Table - RouterOS - MikroTik Documentation und dem hinweis wegen tagged port und trunk port steige ich so langsam dahinter

der VLAN-Table / interface bridge vlan ist ein weiterer Filter, welcher den Port-Filter / interface bridge vlan ergänzt. Wann ich im Port-Filter gesetzt habe, muss ich nicht mehr im VLAN-Table nochmals erwähnen, damit gibt es eigentlich nur noch die Trunk-Verbindungen zwischen Switches in Frage für zusätzliche Filterregeln, plus Management Access usw.
Entscheidend ist jetzt wie hier noch das CPU-Port mit ins Spiel kommt.
Das versuche ich im Kommentar PackElend schreibt am 15.06.2021 um 20:33:40 Uhr zu beantworten

Eine Frage hätte ich noch, was hat den Vorrang / interface bridge vlan oder / interface bridge port?
Nehmen wir mal an ich sage über Ersteres AP_Port1 ist tagged mit VLAN1 aber ist auch PVID=1.
Ich gehe davon aus, dass das Port nach dem VLAN-Table kommt bei der Abarbeitung der Regeln, da das Port das letzte Glied in der Reihe ist, bevor das Packet das Switch physisch verlässt.
Es fürht evtl. aber zu einer merkwüridgen Auflisten in / interface bridge vlan print

steige ich so langsam dahinter

👍
Tip: Du solltest in dem Zusammenhang der Konfig das Wort "Filter" vermeiden, denn das verwirrt hier nur alle denn es ist KEIN Filter in dem Sinne.

damit gibt es eigentlich nur noch die Trunk-Verbindungen zwischen Switches in Frage für zusätzliche Filterregeln, plus Management Access usw.

Richtig !

Entscheidend ist jetzt wie hier noch das CPU-Port mit ins Spiel kommt.

Du sprichst wieder in Rätseln !
Du meinst vermutlich wie du den Management Port sprich die Mamnagement IP anbindest, richtig ?
Das geht ganz einfach

VLAN Interface erstellen mit VLAN ID 99
VLAN ID unten an die VLAN Bridge binden mit dem Tag 99
Unter IP -> Adresses deine .99er Management IP an das Interface "vlan99" binden
Unter IP -> Routes eine Default Route 0.0.0.0/0 auf die 99er IP des Layer 3 Switches eintragen
Fertisch

Alternativ kannst du die Management IPs auch dynamisch vergeben lassen sofern ein DHCP Server im Management VLAN 99 rennt.
Dann trägst du keine statische IP ein sondern bindest den IP -> DHCP Client auf das Interface vlan99
Später solltest du dann im DHCP Server den Mac Eintrag statisch machen um dem Device immer eine feste IP zu vergeben.

Eine Frage hätte ich noch, was hat den Vorrang

Es gibt keinen Vorrang, denn beides sind völlig unterschiedliche Setup Punktre die du BEIDE brauchst !

Bridge Port = Definiert die VLAN-Bridge Member Ports, sprich also alle Ports die am VLAN Bridging teilnehmen. Bei dir sind das alle Ports. Port die hier NICHT eingetragen sind, sind dedizierte Router Ports erfordern also eine IP Adresse direkt auf dem Interface. Erinner dich dran was oben gesagt wurde: Router OS kann sowohl als dedizierter Router oder Layer 3 Switch oder in einer Kombination von beiden arbeiten. In deinem Setup hier hast du aber ein reines VLAN Umfeld. Folglich trägst du also alle physischen Ports als Member Ports dort ein !!
Bridge VLANs = Hier definierst du WELCHE VLANs an WELCHEM Port TAGGED übertragen werden. Sprich also welches VLAN WO and welchem Port Tagged rauskommen soll. NUR tagged. Untagged Ports musst du hier NICHT eintragen das läuft einzig über die PVID !!

bei der Abarbeitung der Regeln

Es gibt keine Regeln !!! Als Regeln bezeichnet man in dem Umfeld Access Regeln auf Basis von Mac oder IP Adressen. Ist der Bereich der Firewall und hat mit dem VLAN Setting rein gar nichts zu tun. Wieder ein verwiirend genutzter Begriff bei dir hier.

da das Port das letzte Glied in der Reihe ist, bevor das Packet das Switch physisch verlässt.

Der Port ist ein Mann ! Technisch hast du Recht hier.

Es fürht evtl. aber zu einer merkwüridgen Auflisten

Solange DU dort nicht etwas "Merkwürdiges" konfiguriert wird dort auch NICHTS Merkwürdiges angezeigt !!
Es liegt also immer ausschliesslich an dir und was du da konfigurierst !

Zitat von @aqui:

steige ich so langsam dahinter
Entscheidend ist jetzt wie hier noch das CPU-Port mit ins Spiel kommt.

Du sprichst wieder in Rätseln !

CPU port steht in Background - Bridge VLAN Table - RouterOS - MikroTik Documentation und bezieht sich darauf, wenn Traffic nicht rein über Layer 2 läuft (reines switching). Hier geht es mir darum, was passiert, wenn der Traffic das VLAN verlässt. Welche Rolle hat hier das CPU Port.
Das versuche ich im Kommentar PackElend schreibt am 15.06.2021 um 20:33:40 Uhr zu beantworten

Zitat von @aqui:
Du meinst vermutlich wie du den Management Port sprich die Mamnagement IP anbindest, richtig ?
Das geht ganz einfach

VLAN Interface erstellen mit VLAN ID 99
VLAN ID unten an die VLAN Bridge binden mit dem Tag 99
Unter IP -> Adresses deine .99er Management IP an das Interface "vlan99" binden
Unter IP -> Routes eine Default Route 0.0.0.0/0 auf die 99er IP des Layer 3 Switches eintragen
Fertisch

das mache ich aber nur auf den Switches, soweit nicht / interface ethernet switch rule switch= switch1 redirect-to-cpu= yes ist, für z.B. weitere Analyse, falls der Traffic sonst nur über den Switch-Chip geht und nie beim Router ankommt.
Auf dem Router gebe ich dann eine explizite Route an z.B. 10.99.99.0/24 -> VLAN ID 99 Interface.

Zitat von @aqui:
Alternativ kannst du die Management IPs auch dynamisch vergeben lassen sofern ein DHCP Server im Management VLAN 99 rennt.
Dann trägst du keine statische IP ein sondern bindest den IP -> DHCP Client auf das Interface vlan99
Später solltest du dann im DHCP Server den Mac Eintrag statisch machen um dem Device immer eine feste IP zu vergeben.

Das betrifft aber nur die Endgeräte, denn / interface ethernet switch rule add ... muss ich immer noch für jedes VLAN Interface auf dem Router machen und für jedes Management VLAN Interfaces auf den Swtiches.

ÜbER / interface ethernet switch rule add ... richte ich den Gateway auf jedem Interface ein, welches die Anfragen aus dem VLAN annimmt und an die entsprechenden Dienste, wie z.B. DHCP weiterleitet, richtig?

Zitat von @aqui:
Tip: Du solltest in dem Zusammenhang der Konfig das Wort "Filter" vermeiden, denn das verwirrt hier nur alle denn es ist KEIN Filter in dem Sinne.

mache ich gleich mal bei

Zitat von @aqui:

Eine Frage hätte ich noch, was hat den Vorrang

Es gibt keinen Vorrang, denn beides sind völlig unterschiedliche Setup Punktre die du BEIDE brauchst !

Bridge Port = Definiert die VLAN-Bridge Member Ports, sprich also alle Ports die am VLAN Bridging teilnehmen. ...
Bridge VLANs = Hier definierst du WELCHE VLANs an WELCHEM Port TAGGED übertragen werden. Sprich also welches VLAN WO and welchem Port Tagged rauskommen soll. NUR tagged. Untagged Ports musst du hier NICHT eintragen das läuft einzig über die PVID !!

bei der Abarbeitung der Regeln

Habe gerade VLAN Forwarding - VLAN Table - Switch Chip Features - RouterOS - MikroTik Documentation entdeckt , was auf das gleiche hinaus läuft, was ich weiter oben mit meiner Auflistung versucht habe festzuhalten (ich habe es aber noch nicht im Detail verglichen), zudem scheint es gilt es nur für meinen CCR1009. Die CRS3xx series switches haben dieses nicht in der Doku, warum auch immer , dennoch muss hier aber wohl sagen lieber spät als nie entdeckt.
Ich nehme jetzt mal eine falsche Konfiguration an, sprich ich trage ein Untagged Port in im VLAN Table ein:

Port: Port1=PVID5, ingress-filter=no --> nicht VLAN5 traffic: egrees tagged
VLAN-Table: VLAN4, untagged=Port1 --> VLAN4 traffic: egrees untagged
nun will dort an Port1 raus: frame_VLAN4 => wer gewinnt ???

Der Konfigurationsfehler / Denkfehler ist hier, dass ich aus einem untagged / access port ein tagged / trunk port mache aber generell würde mich interessieren wer gewinnt hier?
Ist es ganz anderes, sprich dass erst der VLAN Table angewandt wird, sprich Traffic wird untagged. Dann kommt so am Port an und das Port macht nichts, da der PVID nur bein Ingress hinzugefügt wird?

das mache ich aber nur auf den Switches,

Das Submenü "Switch" fast du in der WinBox bzw. für dein Setup NICHT an ! Dort bleibt alles im Default und es muss dort rein gar nichts verändert werden und ist Tabu !

Auf dem Router gebe ich dann eine explizite Route an z.B. 10.99.99.0/24 -> VLAN ID 99 Interface.

Nein ! Wäre ja auch völliger Quatsch einen Route einzurichten auf ein Interface was selber direkt am Router liegt und der Router somit als eigenes Netz kennt. Sinnfrei also dafür noch eine Route einzusetzen ! Abgesehen davon ginge das syntaktisch auch gar nicht.

ÜbER / interface ethernet switch rule add ... richte ich den Gateway auf jedem Interface ein

Nein !
Nochmals: Im "Switch" Menü ist NICHTS und wirklich nichts zu konfigurieren. Da gilt: DO'NT TOUCH !

Ich nehme jetzt mal eine falsche Konfiguration an

Ja, ganz sicher wird dem so sein !
Ein Screenshot deines WinBox Setups oder eine export vom CLI Interface wäre hier hilfreich fürs Troubleshooting !

dass ich aus einem untagged / access port ein tagged / trunk port mache aber generell würde mich interessieren wer gewinnt hier?

Es gewinnt keiner sondern ein Trunk Port transportiert IMMER auch das UNtagged VLAN welches per PVID anliegt. Das ist so definiert im 802.1q Standard.
Es ist also immer ein Dualismus zwischen untagged PVID Traffic und den fürs Tagging eingetragenen VLANs an dem Ports so das tagged und untagged Traffic immer gemeinsam übertragen wird !

Das Submenü "Switch" fast du in der WinBox bzw. für dein Setup NICHT an ! Dort bleibt alles im Default und es muss dort rein gar nichts verändert werden und ist Tabu !

Auf dem Router gebe ich dann eine explizite Route an z.B. 10.99.99.0/24 -> VLAN ID 99 Interface.

Habe mich von den dynamisch erstellen Connected Routes - Manual:IP/Route - MikroTik Wiki verwirren lassen. Dies sind ja nichts anderes als die Broadcast Domains, worin die Clients in dem in Des. Addresses angeben Subnet direkt miteinander reden, sprich hier findet dann reines L2-Switching statt.
Der Begriff Pref. Source liess mich auf falsche Gedanken kommen. Deren Zweck ist aber schön gezeigt in Manual:Route lookup example - MikroTik Wiki. Hier hat es auch noch eine Kiffelaufgabe dazu: When is a Connected Route Not Used? :: packetmischief.ca

Eine Frage hätte ich dennoch, warum soll ich Default Route zu VLAN99 einrichten.

Zitat von @aqui:
Unter IP -> Routes eine Default Route 0.0.0.0/0 auf die 99er IP des Layer 3 Switches eintragen

heisst ja mach dies nur auf dem Edge und Core Switches, ziel ist die IP des Management VLAN Interface auf dem Core Router.
Das benötige ich aber nur, wenn ich aus dem Management VLAN Layer2+ Dienste brauche, das wären:

Geräte schiebt Daten nach aussen
Geräte holt update
Endgeräte im Management VLAN möchten ins www.

Wenn ich aber nun möchte, dass aus dem Management VLAN nichts nach aussen soll, sprich nur Layer 2 Switching, kann ich die Route auch weglassen?

Zitat von @aqui:
das mache ich aber nur auf den Switches,

damit ich meine ich, ich richte dies nur auf den Geräte Switch ein, nicht WinBox-> Switch. Ich sage in Zukunft Core Router, Core Switch und Edge Switch, wenn ich die Geräte meinte. (Nur der Core Router für für L2+ Sachen eingesetzt, bis auf Managment VLAN auf jedem Core und Edge Switch)
Das Menü Switch werde ich den Anfangsschritten nicht anfassen. Später vielleicht mal, wenn es explizite Gründe gibt dies zu tun. Davon habe ich aber gerade keinen auf dem Radar.

Zitat von @aqui:

ÜbER / interface ethernet switch rule add ... richte ich den Gateway auf jedem Interface ein

Nein !

keine Ahnung, warum ich den Schwachsinn dort schreibe, ich meinte mittels / ip address add ....

Zitat von @aqui:

Ich nehme jetzt mal eine falsche Konfiguration an

Ja, ganz sicher wird dem so sein !
Ein Screenshot deines WinBox Setups oder eine export vom CLI Interface wäre hier hilfreich fürs Troubleshooting !

Habe ich so noch nicht konfiguriert, ist nur eine hypothetische Überlegung, was wäre wenn...?
Ich versuche es mal so. Meine hypothetische Aufstellung ist wie folgt:

Port1- Port10 sollen ein Access Port sein
Port 1 bis 5 sind PVID 10
Port 6 bis 10 sind PVID 20
Port 11 ist ein tagged port

nun habe ich bei z.B. Port1 den Hacken bei Ingress Filter nicht gesetzt, somit erwarte ich, dass alle andere VLANs als VLAN10 das Port tagged verlassen.
Das PVID wirkt nur bei Ingress aber wir ich mittlerweile (wieder) gelernt habe, trägt ROS trägt diese Port als untagged im VLAN-Table ein,

Zitat von @aqui:
Über die PVID "erkennt" der MT diese Ports und trägt sie automatisch als untagegd ein.

Jetzt habe dummerweise aus Versehen noch VLAN-Table: VLAN20, untagged=Port1 gesetzt, dass würde dann heissen, dass wenn traffic von VLAN20 dort ankommt, dieser das Port1 untagged verlässt. Wenn ich aber nun VLAN20 dort erwarte kann ich nun ewig warten.

Hier hat es auch noch eine Kiffelaufgabe dazu:

Hat das was mit Kiffen zu tun ?? 🤣

Das benötige ich aber nur, wenn ich aus dem Management VLAN Layer2+ Dienste brauche

Nein, die statische Default Route auf den Access Switches benötigst du nur wenn du auch aus anderen VLANs oder IP Segmenten (VPN etc.) auf dein Management IP Netz zugreifen willst.
Wenn du aber absolut sicherstellen kannst das dein Management Rechner immer nur im VLAN 99 beheimatet ist dann benötigst du diese Default Route natürlich nicht und kannst sie in der Tat weglassen, das ist klar, denn dann muss ja nicht mehr geroutet werden.
Alle am Core direkt angeschlossenen IP Netze routet der L3 Core Switch aber immer. In sofern besteht also zumindestens zwischen den lokalen VLANs immer eine Verbindung was auch für dein Mamnagement Netz gilt.
Hier greift dann eine Access Liste in der Firewall die den Zugriff auf das VLAN 99 verbietet.

nun habe ich bei z.B. Port1 den Hacken ...

Einen Hacken benutzt man im Garten oder hat ihn unten am Fuß. Du meinst sicher einen:
https://www.duden.de/rechtschreibung/Haken
Richtig ?

Zitat von @aqui:

Hier hat es auch noch eine Kiffelaufgabe dazu:

Hat das was mit Kiffen zu tun ?? 🤣

schöner Wortverwechsler

aber nicht so weit Weg von der Knobelaufgabe, schön das wir mal Platz für andere Themen haben

Zitat von @aqui:

nun habe ich bei z.B. Port1 den Hacken ...

Einen Hacken benutzt man im Garten oder hat ihn unten am Fuß. Du meinst sicher einen:
https://www.duden.de/rechtschreibung/Haken
Richtig ?

Richtig

Zitat von @aqui:
Alle am Core direkt angeschlossenen IP Netze routet der L3 Core Switch aber immer. In sofern besteht also zumindestens zwischen den lokalen VLANs immer eine Verbindung was auch für dein Mamnagement Netz gilt.

Tut mir echt leid aber auf den ersten Blick habe ich keinen blassen Schimmer was du meinst.
Meinst du vielleicht damit, dass ROS die Routen zu den Subnetzen automatisch einträgt in die Route List und damit der L3 Switch, was meinem Fall der CCR1009 ist. Damit sind die Routen im FIB/RIB von CCR1009 und er wird Anfragen aus anderen VLANs in das ins Management-Netz weiterreichen.

Tut mir echt leid aber auf den ersten Blick habe ich keinen blassen Schimmer was du meinst.

Will sagen das der L3 Switch natürlich ALLE IP Netze die direkt an ihm angeschlossen sind per se immer uneingeschränkt routet. Sprich du hast mit diesen lokalen IP Netzen immer eine any zu any Connectivity OHNE jegliche Einschränkung.
Betrifft dann auch dein management VLAN so das jeder auf jedes Netz also auch dein Mgmt. Netz zugreifen kann.
Letztlich genau das was du oben auch schon richtig mit FIB/RIB beschrieben hast.

gelöst Frage Netzwerke

Mehr von Tripod

Mikrotik WireGuard VPN ProblemeTripod - 9 Kommentare

Mikrotik: Datum und Uhrzeit im Netzwerk verteilenTripod - 12 Kommentare

Mikrotik: Technische Details in WLAN-Signal verbergenTripod - 4 Kommentare

Mikrotik: WLAN komplett oder einzelne WLAN-Configs zeitweise ausschaltenTripod - 7 Kommentare

Heiß diskutiert