packelend
Goto Top

MikroTik: kaskadisches Core-Netzwerk CCR-CRS-CRS mit Satelliten-Swichtes+APs - ein Versuch einer Anleitung von A-Z

Hallo zusammen,
da ich mit der gelieferten Konfiguration meiner MikroTiks nicht so zufrieden bin, fange ich von vorne an.
Das liegt daran, dass ich Änderungen/Erweiterungen nicht so einfach transparent dokumentieren kann und die Fehlersuche doch erschwert ist bei den vielen aktiven Optionen.

Die Netzwerktopologie ist doch recht umfangreich.
Die Kasskade im Kern liegt daran, dass Router hat nur ein Ausgang für DAC hat, 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.
Zudem hatte ich Ende letzten Jahres keine besseren Switches 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).
Die Satelliten, sprich die hEX... und cAP... ergeben sich durch die bauliche Situation des Mehrfamilienhauses. Die Netzwerkübersicht ist noch nicht komplett, da fehlen noch ein paar Satelliten aber für eine erste Grundkonfiguration reicht es.

Da ich irgendwann an die Grenzen einer sauberen Dokumentation stossen werden, dokumentiere ich ganzen Umfang und Detail auf PackElend/MikroTik (github.com) und würde es hier nur die Schritte stichwortartig festhalten. Wenn immer nötig werde ich auch die Konfiguration hier festhalten.

Ich möchte die Reise auf mehrere Etappen, wie schon auf GitHub angedeutet, aufteilen. Ich fange erstmal an mit der reinen LAN-Netzwerksegmentierung. Da noch der ISP-Router (eien FRITZ!Box) in der Kette hängt, macht diese erstmal die Firewall.

Hier die Netzwerkübersicht:
network topology

Was sind nun meine ersten Schritte???

Nach den exzellenten Beschreibungen
    1. Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
    2. Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik (ich glaube die c't hat dies für Funkkutscher | c't | Heise Magazine verwendet)
    3. Using RouterOS to VLAN your network - MikroTik
    4. Changes to ROS since 6.41 - MUM - MikroTik
    5. und weiteren (finde sie gerade leider nicht alle)
würde ich mal sagen:

  • (1) DHCP-Client auf dem WAN-Port (Combo-Port) des CCR1009 einrichten
      1. Standard Route wird von RouterOS dynamisch erstellt, da es www auf dem WAN-Port erkennt.

  • (2) auf jedem Router und Switch eine Bridge-Interface einrichten, genannt bridge-VLANs
      1. jedem Bridge-Interface, sog. Bridge-Port oder CPU-Port eine IP geben: /ip address add ...
      2. die jeweiligen APs und TPs hinzufügen, auf dem jeweiligen Gerät hinzufügen. Bei den TPs kann man entscheiden, ob man alle VLANs dort einrichtet oder nur diese, die dort erwartet werden, sprich das IoT-VLAN wird nur auf den CORE-Geräten eingerichtet. Eine schlichte Übersicht für die CORE-Geräte:
          • APs werden über / interface bridge port eingerichtet!
          • TPs werden über / interface bridge vlan eingerichtet!
          • CCR:
            • Bridge-Port = AP für VLAN 99
            • Eth2 = AP für VLAN99
            • SFP+ = TP für VLAN10, 20, 30, 99
          • CSR_SFP
            • Bridge-Port = AP für VLAN 99
            • SFP = TP für VLAN 10, 20, 99
            • SFP+ = TP für VLAN 30, 99
          • CSR_PoE:
            • Bridge-Port = AP für VLAN 99
            • Eth1-3 = AP für VLAN 30
            • SFP+ = TP für VLAN 30, 99
  • (3) auf dem CCR die VLAN-Interfaces unter der bridge-VLANs einrichten
        1. hierauf dann je einen DHCP-Server einrichten
              1. DNS-Server ist der Gateway, warum?, siehe hier: MikroTik RouterOS: (dämliche) Frage, wie DNS-Abfragen weitergeleitet werden, DCHP DNS-Einstellungen

    • (4) dem CCR mitteilen auf welchen Interface welche IPs anzutreffen sind: /ip address add ...

    • (5) DNS-Server auf dem CCR mit der Option allow-remote-requests=yes

    • (6) VLAN-Filter aktivieren


    Hier nun die Frage, ist das Vorgehen soweit korrekt?

    Content-Key: 667592

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

    Printed on: April 19, 2024 at 00:04 o'clock

    Member: ukulele-7
    ukulele-7 Jun 15, 2021 at 06:11:24 (UTC)
    Goto Top
    Warum ist das als Frage klassifiziert, was ist die Frage?
    Member: PackElend
    PackElend Jun 15, 2021 at 06:25:36 (UTC)
    Goto Top
    stimmt, das habe ich gestern Abend doch glatt vergessen.
    Sind die Schritte so korrekt?
    Member: PackElend
    PackElend Jun 15, 2021 at 07:29:48 (UTC)
    Goto Top
    habe die Frage an den schluss gestellt und anders formatiert, hoffe der unter teil ist jetzt gut lesbar
    Member: aqui
    Solution aqui Jun 15, 2021 updated at 09:53:21 (UTC)
    Goto Top
    da ich mit der gelieferten Konfiguration meiner MikroTiks nicht so zufrieden bin
    Sorry, aber was ist das für eine sinnfreie Aussage ?! Jeder Hersteller liefert seine Switches mit einer Banalkonfig: alle Ports in VLAN 1 und keinerlei andere Konfig. Quasi also wie ein ungemanagter Banalswitch.
    Jeder muss also IMMER die Konfiguration eines jeden Switches auf der Welt konfigtechnisch anfassen wenn er etwas gehobene Ansprüche an seine Netzwerk Infrastruktur hat als ein simples, banales Heimnetz wo alles dumm in einer gemeinsamen, flachen L2 Hierarchie liegt.
    Deine Logik ist da also etwas schwer verständlich...
    Die Netzwerktopologie ist doch recht umfangreich.
    Gegen ein Krankenhaus Netzwerk mit 3000 Ports ist das eher eine Lachnummer auf Heimnetz Niveau. Auch hier sind Ansichten immer relativ und in einem Administrator Forum sollte man sowas nie so unreflektiert werten...
    So und nun erstmal zurüch zum Thread....
    1.)
    Eine DHCP Client Anbindung an den ISP Router ist immer eine schelchte Lösung. Grund: Du bekommst eine dynamische IP die sich immer ändern kann. An dieser IP Adresse hängt eine deiner wichtigstens Routen vom ISP Router zu deinem VLAN Router. Es ist logischerweise keine gute Idee diese auf dynamischen IP Adressen basieren zu lassen, das weiss auch ein Laie. Hier solltest du imemr eine feste statische IP Adressierung verwenden !
    Ausnahme: Du kannst mit dem ISP Router Mac Adress basierte feste IPs im DHCP Server vergeben, dann ist das tolerabel mit den DHCP Client.
    2.)
    Punkt 2.1 Ist hier vollkommen falsch !!!
    Du musst erstmal bestimmen WELCHER Switch dein Layer 3 Switch werden soll ! Der Switch also der zwischen den VLANs routen soll. Sinnvoll ist hier der CCR1009 oder der zentrale CRS328-4C. Einzig nur dieser Switch bekommt VLAN IP Adressen die anderen NICHT !!!
    Wenn du es allerdings ganz toll machen willst dann lässt du BEIDE MTs in einem HA Design laufen im Core mit VRRP Redundanz. So hast du ein Hochverfügbarkeits Core. Ob du das machst oder nicht ist abhängig von deinen Anforderungen ans Netzwerk.
    Alle anderen sind Layer 2 Switches und haben rein NUR die VLANs konfiguriert bzw. switchen rein nur im Layer 2 ! Einzig eine IP Adresse haben die und das ist die Management IP im VLAN 99. KEINE anderen IPs !
    ALLE Ports sind immer VLAN-Bridge Member Ports !!!
    Mit der PVID bestimmst du un welchem VLAN Endgeräte untagged arbeiten sollen und mit dem Tagging bestimmst du wenn sie selber VLANs übertragen bekommen sollen wie z.B. bei MSSID APs usw.
    Hier machst du also im Punkt 2.1 und 2.2 einen fundamentalen Design und Konfg Denkfehler oben !
    Ansonsten ist dein Vorgehen soweit korrekt !

    Das große Ganze sähe aus Switch Sicht für L2 und L3 bezogen auf dein Netz dann so aus:

    vlan-allgemein4
    Member: PackElend
    PackElend Jun 15, 2021 at 09:14:37 (UTC)
    Goto Top
    meine Ausdrucksweise lässt wohl sehr zu wünschen übrig face-smile
    Zitat von @aqui:
    da ich mit der gelieferten Konfiguration meiner MikroTiks nicht so zufrieden bin
    Sorry, aber was ist das für eine sinnfreie Aussage ?! Jeder Hersteller liefert seine Switches mit einer Banalkonfig: alle Ports in VLAN 1 und keinerlei andere Konfig. Quasi also wie ein ungemanagter Banalswitch.
    Ich habe mir diese bei einem MT-Lieferanten bestellt mit einer funktionallen Ersteinrichtung. Das Problem ist nun das die Konfig nun so voll ist, dass anpassungen mühsam sind aus den eingangs erwähnten gründen.
    Ist es besser so?


    Zitat von @aqui:
    Die Netzwerktopologie ist doch recht umfangreich.
    Gegen ein Krankenhaus Netzwerk mit 3000 Ports ist das eher eine Lachnummer auf Heimnetz Niveau. Auch hier sind Ansichten immer relativ und in einem Administrator Forum sollte man sowas nie so unreflektiert werten...
    Ansichtssache face-smile ja aber gegen ein KH-Netzwerk ist es ein Witz.


    Zitat von @aqui:
    1.)
    Eine DHCP Client Anbindung an den ISP Router ist immer eine schelchte Lösung. Grund: Du bekommst eine dynamische IP die sich immer ändern kann. An dieser IP Adresse hängt eine deiner wichtigstens Routen vom ISP Router zu deinem VLAN Router. Es ist logischerweise keine gute Idee diese auf dynamischen IP Adressen basieren zu lassen, das weiss auch ein Laie. Hier solltest du imemr eine feste statische IP Adressierung verwenden !
    Ausnahme: Du kannst mit dem ISP Router Mac Adress basierte feste IPs im DHCP Server vergeben, dann ist das tolerabel mit den DHCP Client.
    kann ich machen, würde dann alles für DHCPund Standard Route statisch einstellen.
    Fixe-IP würde dann später beim ISP bestellt, wenn denn mal soweit alles läuft.


    Zitat von @aqui:
    2.)
    Punkt 2.1 Ist hier vollkommen falsch !!!
    Du musst erstmal bestimmen WELCHER Switch dein Layer 3 Switch werden soll ! Der Switch also der zwischen den VLANs routen soll. Sinnvoll ist hier der CCR1009 oder der zentrale CRS328-4C. Einzig nur dieser Switch bekommt VLAN IP Adressen die anderen NICHT !!!
    ...
    Alle anderen sind Layer 2 Switches und haben rein NUR die VLANs konfiguriert bzw. switchen rein nur im Layer 2 ! Einzig eine IP Adresse haben die und das ist die Management IP im VLAN 99. KEINE anderen IPs !
    Meine Audrucksweise face-monkey
    • CCR1009 ist Layer 3, dort hier werden die DHCP-Server und IP-Addressen Bereiche pro Interface eingerichtet, da meinen wir das gleiche
    • CRS... hier wird nur eine IP-Addresse für das Bridge-Port angeben
    das deckt sich auch mit dem letzten Absatz des Zitates.
    Wenn meine Ausdrucksweise nun so passt, passe ich den OP an.


    Zitat von @aqui:
    Wenn du es allerdings ganz toll machen willst dann lässt du BEIDE MTs in einem HA Design laufen im Core mit VRRP Redundanz. So hast du ein Hochverfügbarkeits Core. Ob du das machst oder nicht ist abhängig von deinen Anforderungen ans Netzwerk.
    Sprich die CRS würden als Router einspringen, wenn der CCR ausfällt?
    Glaube eher nicht, da jedem Geräte schon eine Rolle zugeordnet ist. Wenn die CPU in den CRS immer noch stark genug ist für die Layer 3 Aufgaben kann ich es mal in Betracht ziehen. Ich habe auch im Hinterkopf, dass die PoE-IoT-Geräte ne seperate Backup Speisung bekommen. In diese, Zusammenhang könnte es noch Sinn machen aber sind die SFP-Ports der Flaschenhals.


    Zitat von @aqui:
    ALLE Ports sind immer VLAN-Bridge Member Ports !!!
    du beziehst dich darauf, dass RouterOS unter /interface bridge vlan dynamisch Einträge macht, wenn er ein VLAN erkennt, was aber dort nicht eingetragen ist?
    Ich hänge mich gerade nur an dem Begriff "ALLE" auf, da ich in /interface brdige ports die Ports manuell einer Bridge zu ordne. Zumindest haben ich da noch keine dynamsichen Einträge gesehen.

    Mal so ne Frage am Rande dazu, was passiert eigentlich in diesem Fall, wenn kein /interface bridge konfigiert ist?
    Wenn sich "ALLE" auf die in /interface bridge ports eingetragnen Ports handelt, hat sich die Frage erledigt.


    Zitat von @aqui:
    Mit der PVID bestimmst du un welchem VLAN Endgeräte untagged arbeiten sollen und mit dem Tagging bestimmst du wenn sie selber VLANs übertragen bekommen sollen wie z.B. bei MSSID APs usw.
    Ich vergass zu erwähnen, dass ich:
    • keine VLAN=1 mehr sehen möchte, was heisst, dass ich irgendwo etwas übersehen habe
    • VLAN = 1 soll ein Sackgase enden
    • VLAN
    Member: aqui
    Solution aqui Jun 15, 2021 updated at 10:09:48 (UTC)
    Goto Top
    Ich habe mir diese bei einem MT-Lieferanten bestellt mit einer funktionallen Ersteinrichtung.
    Aaahhsoo...sorry, missverstanden bzw. hattest du in der Tat nicht erwähnt. Dann solltest du aber sehr schnell mal den Lieferanten wechseln, denn wenn der so ein banales Setup nicht hinbekommt ist der wohl ein Reinfall bzw. gänzlich die falsche Wahl was seine MT Kenntnisse angetrifft.
    kann ich machen, würde dann alles für DHCP und Standard Route statisch einstellen.
    Wäre der bessere Weg !
    Fixe-IP würde dann später beim ISP bestellt, wenn denn mal soweit alles läuft.
    Hat ja aber erstmal rein gar nix mit deiner interen IP Adressierung zu tun und brauchst du auch nicht zwingend. Nicht das du hier schon wieder etwas missverstehst.
    Die Provider Adressierung ist für dein internes Netzwerk natürlich erstmal völlig irrelevant !
    CCR1009 ist Layer 3, dort hier werden die DHCP-Server und IP-Addressen Bereiche pro Interface eingerichtet
    Pro VLAN Interfacemeinst du sicher und das passt dann auch bzw. siehst du ja auch so in der obigen Zeichnung wie es auszusehen hat !
    CRS... hier wird nur eine IP-Addresse für das Bridge-Port angeben
    Nein ! Niemals in einem VLAN Setup eine IP auf das Bridgeport Interface setzen. Das führt zum sofortigen Scheitern des Setups ! Das MT VLAN Tutorial weiss MEHRFACH auf diesen Fehler hin es nicht zu tun !! IP immer auf das Management VLAN Interface !!
    du beziehst dich darauf, dass RouterOS unter /interface bridge vlan dynamisch Einträge macht, wenn er ein VLAN erkennt
    Ja, aber dort wird niemals etwas dynamisch eingetragen und schon gar nichts erkannt. Diese Zuordnung musst immer DU im Switch Setup machen !
    Unter "Bridge Ports" werden generell die Member Ports der VLAN Bridge eingetragen. Das sind bei dir immer alle physischen Ports in deinem VLAN Setup.
    Router OS kann auch ein reiner Router sein mit dedizierten IP Adressen auf den physischen Interfaces. Das ist aber ein Setup was du hier gar nicht hast. Also musst du alle physischen Ports auch als Member Ports definieren.
    Das Bridge VLAN definiert dann die VLANs des Switches und welche Ports Taggen sollen. Nur Taggen. Untagged bestimmst du allein mit der Port PVID. All das steht aber auch so explizit mehrfach im VLAN Tutorial ! Lesen und verstehen...! face-wink
    was passiert eigentlich in diesem Fall, wenn kein /interface bridge konfigiert ist?
    Dann arbeitet dein MT rein als Port basierter IP Router. Damit ist dein VLAN Setup oben unmöglich. Router OS kann eben beides. Es hängt rein von DIR und deiner Konfig ab wie das Gerät arbeitet oder arbeiten soll.
    keine VLAN=1 mehr sehen möchte, was heisst, dass ich irgendwo etwas übersehen habe
    Macht aus Sicherheitssicht auch Sinn
    VLAN = 1 soll ein Sackgase enden
    Dann vergibt man keinerlei PVID 1 auf den Ports und konfiguriert KEIN IP Interface fürs VLAN 1. Ganz einfach und simpel. face-wink
    Member: PackElend
    PackElend Jun 15, 2021 updated at 18:39:43 (UTC)
    Goto Top
    Zitat von @aqui:
    Fixe-IP würde dann später beim ISP bestellt, wenn denn mal soweit alles läuft.
    Hat ja aber erstmal rein gar nix mit deiner interen IP Adressierung zu tun und brauchst du auch nicht zwingend. Nicht das du hier schon wieder etwas missverstehst.
    Die Provider Adressierung ist für dein internes Netzwerk natürlich erstmal völlig irrelevant !
    habe hier schon wieder nur den halben Gedanken niedergeschrieben. Das passiert dann zu dem Schritt, wenn die Firewall soweit eingerichtet ist und ich eigentlich das Glasfaserkable vom ISP direkt an den CCR1009 hängen kann.


    Zitat von @aqui:
    CCR1009 ist Layer 3, dort hier werden die DHCP-Server und IP-Addressen Bereiche pro Interface eingerichtet
    Pro VLAN Interfacemeinst du sicher und das passt dann auch bzw. siehst du ja auch so in der obigen Zeichnung wie es auszusehen hat !
    Jo so meinte ich das face-smile


    Zitat von @aqui:
    CRS... hier wird nur eine IP-Addresse für das Bridge-Port angeben
    Nein ! Niemals in einem VLAN Setup eine IP auf das Bridgeport Interface setzen. Das führt zum sofortigen Scheitern des Setups ! Das MT VLAN Tutorial weiss MEHRFACH auf diesen Fehler hin es nicht zu tun !! IP immer auf das Management VLAN Interface !!
    habe mittleirweile wohl das Word Bridge-Prot und CPU-Port in den mundgenommen und mich selber verwirrt.
    Steht in Mikrotik VLAN Konfiguration ab RouterOS Version 6.41 ja schön in rot und auch in anderen Konfigs so, z.B.:
    /interface vlan add interface=BR1 name=BASE_VLAN vlan-id=99
    /ip address add address=192.168.0.2/24 interface=BASE_VLAN
    anstatt
    /interface bridge add  name=bridge_VLAN vlan-id=99
    /ip address add address=192.168.0.2/24 interface=bridge_VLAN
    Ich versuche mir gerade klar zu machen, warum ich in /interface bridge vlan die Bridge nochmals hinzufügen muss, nur dieses Mal in der Rolle als Bridge-Port.
    Hier meine zwei Erklärungsversuche, wobei ich für den Zweiten tendiere:

    1. Die Layer 3+ Funktionen, stehen prinzipiel direkt an jedem IP-fähigen /interface zur Verfügung, bzw. werden dort angewandt. Wenn etwas Interface-spezifisch eingestellt wird, gibt es diese Funktion dann halt nur dort usw.
        • Layer3+ Zugriff wäre dann wie folgt:
          • VLAN-Interface -> Layer3+-Funktion
        • Zugriff auf RouterOS, dies beinhaltet die Konfiguration, SSH, FTP usw. geht wie folgt
          • VLAN -> BRIDGE -> BRIDGE-PORT -> CPU (RouterOS)
        • Wenn nun /interface bridge name=bridge-VLANs vlan-filtering=yes, muss der Traffic den richtigen 802.1Q-TAG besitzen im Ethernet II frame. Dies bekommt er nur, wenn er zuvor im entsprechenden VLAN war (Mangagement VLAN e.g. 99). Dadurch, dass die Mangagement-IP auf dem Mangagement VLAN sitzt, geht der Traffic erstmal dorthin und dann weiter zu BRIDGE -> BRIDGE-PORT .... Wenn die Anfrage aus dem gleichen VLAN kommt, hat er natürlich schon den richtigen 802.1Q-TAG.
        • Eigentlich wäre es nun vorteilhaft, wenn ich unter /interface bridge ports das BRIDGE-PORT hinzufügen kann, ist es doch ein AP zur CPU oder ???
        • Weil ich es nicht kann muss unter /interface bridge vlan, das BRIDGE-PORT wird per se als tagged/trunk port betrachtet, warum ???
      • ...
    2. Die Layer 3+ Funktionen, kommen erst in der CPU zu tragen. Dies deckt sich auch besser mit CPU-Port | Background | Bridge VLAN Table - RouterOS - MikroTik Documentation deckt. Somit geht es immer so:
          • VLAN -> BRIDGE -> BRIDGE-PORT -> CPU für Layer 3+ Funktion
          • VLAN -> BRIDGE -> BRIDGE-PORT -> CPU (RouterOS)

        • Wenn nun /interface bridge name=bridge-VLANs vlan-filtering=yes, muss der Traffic den richtigen 802.1Q-TAG besitzen im Ethernet II frame. Dies bekommt er nur, wenn er zuvor im entsprechenden VLAN war (Mangagement VLAN e.g. 99). Dadurch, dass die Mangagement-IP auf dem Mangagement VLAN sitzt, geht der Traffic erstmal dorthin und dann weiter zu BRIDGE -> BRIDGE-PORT .... Wenn die Anfrage aus dem gleichen VLAN kommt, hat er natürlich schon den richtigen 802.1Q-TAG.
        • Jetzt kommt ein wichtiger Unterschied zu 1.: Da nun jedes Packet aus einem VLAN über das Bridge-Port muss, ist es per se ein tagged port / trunk port, d. h.
          • es steht mir nicht als einzelnes Trunk Port zur Verfüfung in /interface bridge ports
          • da nun durchaus mehere Subnetzte (VLANs) über diese Port laufen, ist es unlogisch diesem Port, bzw. der Bridge eine IP zuzuordnen, zudem passt es nicht zu der eingangs beschriebenen Route
        • bis gerade eben hatte ich immer noch nicht verstanden, warum /interface bridge vlan add bridge=bridge-VLANs tagged=bridge-VLANs vlan-ids=30 nötig ist aber evtl. ist gerade der Groschen gefallen:
      • .
      ----

      Zitat von @aqui:
      du beziehst dich darauf, dass RouterOS unter /interface bridge vlan dynamisch Einträge macht, wenn er ein VLAN erkennt
      Ja, aber dort wird niemals etwas dynamisch eingetragen und schon gar nichts erkannt. Diese Zuordnung musst immer DU im Switch Setup machen !
      Meiner mach aber eine dynamischen Eintrag:
      crs328_24p_4-dynamic vlan entry


      Zitat von @aqui:
      Untagged bestimmst du allein mit der Port PVID.
      stimmt aber nicht so ganz oder?
      Deine Aussage bezieht sich auf Egress. Bei Ingrees, wenn untagged traffic am Port ankommt, wird es mit der PVID getagged.


      Noch zwei Sachen:
      1. Vielen dank für das super Bild, worin hast du das so schnell gezeichnet?
      2. kann man dir mal ein Bier spendieren für die ganze Unterstützung?
    Member: aqui
    Solution aqui Jun 16, 2021 updated at 10:08:58 (UTC)
    Goto Top
    wohl das Word Bridge-Prot und CPU-Port in den mundgenommen und mich selber verwirrt.
    Nicht nur dich selber sondern auch die Community hier... face-wink
    Steht in Mikrotik VLAN Konfiguration ab RouterOS Version 6.41 ja schön in rot und auch in anderen Konfigs so, z.B.:
    Nein !
    Das ist schlicht falsch und du solltest aufhören solche falschen Tatsachen hier zu verbreiten. Zumindestens was das hiesige VLAN Tutorial anbetrifft steht dort mehrmals der Hinweis in einem VLAN Setup keine IP Adressen direkt auf das Bridge Interface zu legen !! Wenn also dann bitte RICHTIG lesen und zitieren !
    Es ist sogar ein Bild der IP Adressierung dort gepostet was nirgendwo das Bridge Interface selber in der IP Adressierung zeigt sondern ausschliesslich VLAN Interfaces:
    adress
    Woher hast du also diese Falschinformation ??
    IP Adressen in deinem VLAN Umfeld also immer nur auf VLAN Interfaces ! Einzige Ausnahme mag nur der Koppelport auf den ISP Router sein. Ob man den als dedizierten Routing Port (kein Bridge Member !) oder über ein VLAN IP Interface routet ist eine rein kosmetische und persönliche Geschmacksfrage.
    Dies bekommt er nur, wenn er zuvor im entsprechenden VLAN war
    Nein, dies bekommt er nur wenn er in der Bridge VLAN Konfig als Tagged Port für dieses VLAN eingetragen ist.
    Kommen wir mal zu den Topic Punkten von dir...
    1.)
    Die Layer 3+ Funktionen, stehen prinzipiel direkt an jedem IP-fähigen /interface zur Verfügung
    Ja, das ist bei allen Geräten mit Router OS so. Wie sie das tun ist allein von DEINER Konfig abhängig.
    Zugriff auf das Router OS geschieht dann ganz simpel über die IP Adresse die du dem Management VLAN IP Interface vergeben hast, fertisch.
    Und ja alles muss natürlich den richtigen VLAN Tag haben um wieder dem Interface oder dem VLAN zugeordnet werden zu können. Welche VLAN IDs der Switch "kennt" und wie er Taggen soll definierst du wie bei jedem Switch in den "Bridge VLANs".
    Eigentlich wäre es nun vorteilhaft, wenn ich unter /interface bridge ports das BRIDGE-PORT hinzufügen kann
    Erstmal ist der Port ein Mann und zweitens ist das ja auch so. Alle physischen Ports sind in deinem Setup ja Member der VLAN Bridge, folglich sollte dann dort auch jeder physische Port aufgelistet sein !
    Das also was du als vorteilhaft ansiehst ist ein simples Muss !
    In den VLAN Bridge Settings sagst du lediglich ob dieser Port für VLAN x getagged werden soll oder nicht. Nicht mehr und nicht weniger....
    2.)
    Nein ! Auch Layer 3 Switching macht Mikrotik in Hardware. (Fast Switching) Das "siehst" du aber nicht in der Konfig da es Switch Chip intern passiert. Ist für die Konfiguration an sich also nicht relevant.
    ist es per se ein tagged port / trunk port, d. h.
    Intern ja. Auch ein untagged Endgeräte Port (PVID) wird in der internen Switching Backplane getagged damit der Switch alles eindeutig zuordnen kann. Das aktiviert man mit dem Button "VLAN Filtering".
    Hat dich aber auch nicht zu kümmern, denn für dich als Konfigurator kann es völlig Wumpe sein was intern im Silizium passiert. Du siehst das ja letzutlich auch nicht in der Konfig.
    ich dachte bis dahin, das der Filter, der Zugriff auf CPU über VLAN30 erlaubt
    Der MT ist ein Router. Dort ist generell erstmal Zugriff auf alles erlaubt sofern das konfiguriert ist. Wenn du etwas unterbinden willst musst du das immer über die Firewall Konfig machen mit einer Blacklist.
    Firewall hat aber erstmal mit dem grundsätzlichen VLAN Setup NICHTS zu tun und sollte immer erst ganz am Schluss passieren wenn alles rennt. Wie üblich bei IP Accesslisten.
    und daher die dyamischen /interface bridge vlan-Table-Einträge enstehen.
    Diese "entstehen" ausschliesslich nur für UNtagged Ports die du da NICHT eingtragen musst. Das passiert durch die PVID Settings. Über die PVID "erkennt" der MT diese Ports und trägt sie automatisch als untagegd ein. Wie gesagt einzig NUR für untagged Ports NICHT aber für Tagged Ports die du als Konfigurator explizit setzen musst. Da ist rein gar nix dynamisch.
    Meiner mach aber eine dynamischen Eintrag:
    Wie bereits mehrfach gesagt und oben beschrieben: NUR die UNtagged Ports via PVID !
    wie kommen die anderen VLANs zur CPU durch?
    Wie bei jedem Router werden sie geroutet sofern ein Layer 3 Switching definiert ist.
    Das ist immer definiert sowie ein VLAN eine IP Adresse zugewiesen bekommen hat. In diesem Moment kann darüber, wie üblich bei L3, geroutet werden ohne Einschränkung.
    Deshalb ja auch der Appell an dich die IP VLAN Adressen einzig und allein NUR auf dem Layer 3 Core Switch zu definieren und NICHT aber auf den Layer 2 Access Switches. Diese haben lediglich NUR ihre Management IP Adresse in VLAN 99 und gut iss !!
    Das passt würde dann auch zur MikroTik VLAN Anleitung passen
    Was hattest du gedacht, das wir hier etwas posten was Unsinn ist ? Das wäre ja mehr als peinlich in einem Administrator Forum. face-wink
    Zugriff über WinBox etc. auf die CPU muss ich dann über Firewall regeln verhindern
    Jein...
    Kann man machen ist aber viel zu aufwendig und ineffizient. Das machst du über die IP Neigbor Discovery Funktion indem du die SMDP Neigbor Discovery nur im Management VLAN aktivierst. Damit erkennt die Winbox das Gerät nicht mehr automatisch über den Layer 2 Broadcast.
    WinBox hat ja den Vorteil das du auch bei komplett fehlender IP Connectivity das Gerät immer sicher erkennst und connecten kannst und das geht über Layer 2 Broadcasts.
    Den Rest, also IP basierte Zugriffe wie WebGUI über Browser und Telnet oder SSH (PuTTY, TeraTerm etc.), musst du in der Tat über die Firewall blocken. (Input Chain)
    Wie man das macht bekommen wir aber später wenn dein ganzes Setup endlich fehlerfrei rennt !
    Es gilt: Immer so wenig (Konfig) Fussfallen beim Setup wie möglich !! face-wink
    Noch zwei Sachen:
    1.)
    Visio, LibreOffice Draw, dia, OmniGraffle je nachdem was du bevorzugst (Win, Mac, Linux) unter Nutzung der freien Cisco Topology Icons: https://www.cisco.com/c/en/us/about/brand-center/network-topology-icons. ...
    2.)
    Immer gerne aber bitte keine westdeutsche Massenplörre ala Krombacher sondern ein schönes (virtuelles) Craft Beer !!! 🤣
    Member: PackElend
    PackElend Jun 16, 2021 at 10:32:26 (UTC)
    Goto Top
    Zitat von @aqui:
    wohl das Word Bridge-Prot und CPU-Port in den mundgenommen und mich selber verwirrt.
    Nicht nur dich selber sondern auch die Community hier... face-wink
    Steht in Mikrotik VLAN Konfiguration ab RouterOS Version 6.41 ja schön in rot und auch in anderen Konfigs so, z.B.:
    Nein !
    Das ist schlicht falsch und du solltest aufhören solche falschen Tatsachen hier zu verbreiten. Zumindestens was das hiesige VLAN Tutorial anbetrifft steht dort mehrmals der Hinweis in einem VLAN Setup keine IP Adressen direkt auf das Bridge Interface zu legen !! Wenn also dann bitte RICHTIG lesen und zitieren !
    Es ist sogar ein Bild der IP Adressierung dort gepostet was nirgendwo das Bridge Interface selber in der IP Adressierung zeigt sondern ausschliesslich VLAN Interfaces:
    adress
    Woher hast du also diese Falschinformation ??
    muss mich hier gleich für meine unvollständige Aussage entschuldigen, ich meine das mein Murks, sprich das IP auf die Bridge, dort in rot geschrieben steht mach es nicht so, die IP muss auf das VLAN interface
    Member: PackElend
    PackElend Jun 16, 2021 at 12:16:11 (UTC)
    Goto Top
    Zitat von @aqui:
    ist es per se ein tagged port / trunk port, d. h.
    Intern ja. Auch ein untagged Endgeräte Port (PVID) wird in der internen Switching Backplane getagged damit der Switch alles eindeutig zuordnen kann. Das aktiviert man mit dem Button "VLAN Filtering".
    Hat dich aber auch nicht zu kümmern, denn für dich als Konfigurator kann es völlig Wumpe sein was intern im Silizium passiert. Du siehst das ja letzutlich auch nicht in der Konfig.
    Ich möchte nur vestehen, warum ich zum Beispiel die IP auf das VLAN-Interface setzte muss und nicht auf die Bridge. Aus Fehlern lernt man bekanntlich am besten.
    Meine zweite Erklärung finde ich irgendwo schlüssig, wenn ich mir vorstelle, dass jedes VLAN ein eigener Switch ist und die werden alle über je ein Kabel mit der CPU verbunden. Jetzt führe ich diese in ein Kabel zusammen, damit wird es en Trunk. Da nun mehrere Broadcast Domains über das gleiche Port gehen, wird das nun ein tagged port.
    Wenn dies so ist, kann ich es mir bildlich gut vorstellen und kann es später auch entsprechend schlüssig erklären. Dann wäre das Thema VLAN-Handhabung durch das Gerät und RouterOS erstmal abgeschlossen face-smile.

    Die einzige Einstellung, die ich noch erklären muss sind
    • /interface ethernet switch rule add ...
      • hier richte ich den Gateway auf jedem Interface ein, welches die Anfragen aus dem Interface, in unserem dem jeweiligen VLAN annimmt und an die entsprechenden Dienste, wie z.B. DHCP weiterleitet, richtig?
    • /ip dhcp-server address-pool vs /ip dhcp-server network address, da ich die Beschreibung im Wiki dazu irgendwie als doppelt gemoppelt ansehe.
      • ich muss den Pool bekannt geben, aus welchen er die IPs für die Clients vergibt, dass ist klar, mache ich über address-pool
      • /ip dhcp-server network Gateway, DNS-Server usw. sind Informationen für die Clients
      • für was brauch ich aber nun /ip dhcp-server network address?
        • vieleicht ist es so: kann zwar einem Interface nur einen DCHP-Server hinzufügen. Dieser hat nur einen DHCP-Pool (ausser ich bastle mir weitere pools über ein zughöriges Skript). RouterOS schaut dann, welches /ip dhcp-server network die gleiche Broadcast Domain hat wie der address-pool über den Vergleich von address-pool und den Einträgen in address und gibt die entsprechenden Einträge aus der zugehörigen Zeile in /ip dhcp-server network an die Clients weiter, welche auf diesem Interface ankommen. Passt das so?

    Zitat von @aqui:
    Nein ! Auch Layer 3 Switching macht Mikrotik in Hardware. (Fast Switching) Das "siehst" du aber nicht in der Konfig da es Switch Chip intern passiert. Ist für die Konfiguration an sich also nicht relevant.
    aber das hängt ja stark vom ROS und Gerät ab: L3 Hardware Offloading - RouterOS - MikroTik Documentation, sprich sobald ROSv7 stabil ist, habe ich es in meinen CSSxxx dann auch verfügbar face-smile.
    Wenn ich es richtig sehe, kann momentan kann nur, STP IGMP/MLD Snooping, DHCP Snooping and DHCP Option 82, MLP und ACL auf dem Switch-Chip laufen.


    Zitat von @aqui:
    Deshalb ja auch der Appell an dich die IP VLAN Adressen einzig und allein NUR auf dem Layer 3 Core Switch zu definieren und NICHT aber auf den Layer 2 Access Switches. Diese haben lediglich NUR ihre Management IP Adresse in VLAN 99 und gut iss !!
    Hatte nichts anderes vor, bzw. dass passiert alles nur auf dem CCR, dort und nur dort, soll das ganze Routing usw. stattfinden.


    Zitat von @aqui:
    Eigentlich wäre es nun vorteilhaft, wenn ich unter /interface bridge ports das BRIDGE-PORT hinzufügen kann
    Erstmal ist der Port ein Mann und zweitens ist das ja auch so. Alle physischen Ports sind in deinem Setup ja Member der VLAN Bridge, folglich sollte dann dort auch jeder physische Port aufgelistet sein !
    Das also was du als vorteilhaft ansiehst ist ein simples Muss !
    ich meinte damit, dass das CPU-Port als phyisches Port vorhanden sein sollte, somit ist es eher greifbar (bei mir im Kopf) und taucht nicht indirekt auf im VLAN-Table mit dem Name der Bridge.
    CPU port - Every device with a switch chip has a special purpose port called CPU port and it is used to communicate with the device's CPU. For devices that support VLAN filtering with hardware offloading, this port is the bridge interface itself. This port is mostly used to create management access but can be used for other purposes as well, for example, to route traffic between VLANs, to mark packets and apply queues.


    Zitat von @aqui:
    Immer gerne aber bitte keine westdeutsche Massenplörre ala Krombacher sondern ein schönes (virtuelles) Craft Beer !!! 🤣
    Craft Beer sicher, gibt bei mir nix anderes, wie ich das in die Leitung bekomme muss ich noch schauen aber sonst im Zürich immer auf ein Bier willkommen.
    Danke face-smile


    Zugriff über WinBox etc. auf die CPU muss ich dann über Firewall regeln verhindern
    Jein...
    Kann man machen ist aber viel zu aufwendig und ineffizient. Das machst du über die IP Neigbor Discovery Funktion indem du die SMDP Neigbor Discovery nur im Management VLAN aktivierst. Damit erkennt die Winbox das Gerät nicht mehr automatisch über den Layer 2 Broadcast....
    Danke
    Member: PackElend
    PackElend Jun 16, 2021 at 12:57:33 (UTC)
    Goto Top
    wenn das nun alles in die Richtung geht, würde ich anfangen das Skript Network Segregation & Basic Optimization für jedes Gerät erstellen. Es sind doch am Schluss mehr Geräte als gezeigt, da ich drei cAP ac3 habe und vier hex S mit je einem cAP ac und sich da schnell Tippfehler / Kopierfehler einschleichen.
    Würde dann am Wochenende die Konfiguration aufspielen.

    Mit Basic Optimizationmeine ich Standarddinge HW-Offloading, FastPath etc. was eigentlich default ist
    Member: aqui
    aqui Jun 16, 2021 updated at 13:56:29 (UTC)
    Goto Top
    vestehen, warum ich zum Beispiel die IP auf das VLAN-Interface setzte muss und nicht auf die Bridge.
    Weil du dem Bridge Interface an sich keinen VLAN Tag mitgeben kannst. Das musst du aber zwingend denn ansonsten weiss die VLAN Bridge natürlich nicht welchem Traffic sie welchem IP Interface zuweisen muss.
    Über die VLAN IP Interfaces ist das aber sichergestellt. Im Setup zu den Interfaces unten kannst du ja auch genau sehen das sie eine VLAN ID mitbekommen und auf die Bridge gebunden sind. So ist das sichere und richtige VLAN Tagging an den Interfaces bzw. der Bridge sichergestellt weil das nackte Bridge Interface eben keinen Tag supportet oder konfiguriert haben kann.
    Im Grunde hängst du also schon auf dem "Bridge Interface" aber über den Umweg Tag was über das VLAN Interface geregelt ist. face-wink
    Hoffe das hilft zur bildlichen Vorstellung...?! Oder vielleicht verstärkt es ein buntes Bildchen...
    l3
    (Den o.a. Router musst du dir natürlich innerhalb des L3 Switches vorstellen !!)
    da ich die Beschreibung im Wiki dazu irgendwie als doppelt gemoppelt ansehe.
    Nein ist sie nicht. Der DHCP muss doch zwingend das netzwerk kennen (Subnetzmakse !) und muss auch zwingend wissen aus welchem Pool von IP Adressen er Client IPs verteilen soll. Du musst also beides setzen.
    Mache dir das Leben da leicht und klicke im DHCP Server Menü einfach nur den ganz großen Button "DHCP Setup" !! Das fragt alles Menü geführt ab und du musst nur noch abnicken ! face-wink
    So, und nun genug der Theorie ! Bring das endlich alles zum Laufen ! face-big-smile
    Member: PackElend
    PackElend Jun 16, 2021 at 22:40:47 (UTC)
    Goto Top
    Zitat von @aqui:
    Nein ist sie nicht. Der DHCP muss doch zwingend das netzwerk kennen (Subnetzmakse !) und muss auch zwingend wissen aus welchem Pool von IP Adressen er Client IPs verteilen soll. Du musst also beides setzen.
    das meinte ich damit aber warum muss RouterOS dies indirekt herausfinden, in dem es schaut, wo Subnetzmakse von /ip dhcp-server address-pool = Subnetzmakse von /ip dhcp-server network address ist?
    Die ist für mich der einzige ersichtliche Zusammenhang, wie man die voneinander getrennten Einstellungen verheiraten kann.


    Zitat von @aqui:
    vestehen, warum ich zum Beispiel die IP auf das VLAN-Interface setzte muss und nicht auf die Bridge.
    Weil du dem Bridge Interface an sich keinen VLAN Tag mitgeben kannst. Das musst du aber zwingend denn ansonsten weiss die VLAN Bridge natürlich nicht welchem Traffic sie welchem IP Interface zuweisen muss.
    Jetzt ist der Groschen glaube ich wirklich am Fallen. Ich bin bisher davon ausgegangen, dass mit Bridge eine Bridge in Sinne einer klassischen Bridge gemeint ist, sprich die Trennung von Collision Domains aber ich habe nochmal darüber nachgedacht und bin dann auf flgendes gestossen:
    Man sagt, die Bridge ist ein Software Switch welche über die CPU läuft.
    Ich rate jetzt mal, dass in der MT-Welt eine klare Unterscheidung zwischen Switch-Chip Aktionen und CPU-Aktionen angestrebt worden ist, was man mit den Begriff Bridge und Switch ereichen möchte. Dies scheint mir, ist in der Linux-Welt auch nicht unbekannt, siehe VLAN Bridging and Trunking (802.1q) - docs.bisdn.de.
    Das Bridge-Interface ist auch schön illustriert in Bridge Interface (Bridge Function) - Network Devices - Yamaha aber hier kann man die IP auf das Bridge-Interface setzten, was uns nicht weiterhilft.
    Der wieso, weshalb warum kommt wohl eher aus folgenden Ecken, da RouterOS auf einem Linux Kernel aufgebaut ist.

    Das half mir hier auch ein wenig
    * /interface ethernet switch rule add ...
    • hier richte ich den Gateway auf jedem Interface ein, welches die Anfragen aus dem Interface, in unserem dem jeweiligen VLAN annimmt und an die entsprechenden Dienste, wie z.B. DHCP weiterleitet, richtig?
    Es heist ziemlich oft das Gateway ist das Tor zu anderen Netzwerken. Dass ist prinzipiell korrekt aber eher indirekt, erklärt ihn ganz gut.
    Ich meinte immer, dass ist ein Dienst der da sitzt und dann die Traffic aktiv weiterverteilt aber eigentlich ist es das Schleusse von Layer 2 zu Layer 3, worin je nach Anfrage, ein Aktion stattfindet. Dies ist in der Regel das Routing und hierzu geht es dann gen FIB&RIB.
    Damit ist er dann das Tor zu anderen Netzwerken aber allein aus der Tatsache heraus, dass das OSI-Schichtmodell von unten nach oben abgerbeiten wird. Es ist aber mehr, es schliesst die Broadcast Domain und öffnet Layer2+-Funktionen den Zugriff auf den Traffic bietet diese der Broadcast-Domain somit an.
    Das Wesentliche was ich dem Gateway zuorden ist der ARP-Table, so dass er weiss, welche IP aus seine Subnetz welche MAC gehört, womit der Switch dann afu Layer 2 arbeitet.

    Wenn nun aber die Gateway-Adresse des Subnetzes, welches im DHCP defeniert, eine andere ist, als die des Interface, worauf der DHCP-Server arbeitet, geht dann immer noch alles gut?
    Das Gatway muss im gleichen Subnetz sein, dass ist klar, sonnst kommt da nie was an aus dem Subnetz (siehe auch networking - does the gateway have to be on the subnet? - Unix & Linux Stack Exchange aber wie geht es dann weiter. Ist der Gateway schon eine Interface, welches auf FIB/RIB zugriff hat und somit das Routen anleiern kann?
    Ich sage mal nein, da ich Gateway in /interface... nicht finde und nach router - Network Gateways vs Interfaces - Network Engineering Stack Exchange nie finden werde, da es sich um einen Pfad handelt. Die IP-Addresse und MAC bezieht sich immer auf ein Interface. Wenn nun Interface-IP und Gateway-IP nicht übereinstimmen, wird es nichts mit ARP, FIB und RIB, siehe auch Is an IP address necessary for a gateway? - Network Engineering Stack Exchange.
    (Ich glaube jetzte habe ich es endlich...bis zur nächsten Korrektur face-smile )


    Zitat von @aqui:
    So, und nun genug der Theorie ! Bring das endlich alles zum Laufen ! face-big-smile face-big-smile
    Lege morgen los, der kleine hatte heute Abend Vorrang und nun ist doch schon a bissle spät.
    Member: aqui
    aqui Jun 17, 2021 at 07:06:10 (UTC)
    Goto Top
    Man sagt, die Bridge ist ein Software Switch welche über die CPU läuft.
    Nein, das war zu Neandertaler Netzwerk Zeiten mal so. Heute passiert das alles direkt im Silizium !
    Die CPU erledigt heute nur noch Management Aufgaben aber mit dem Paket Forwarding hat sie nichts mehr zu tun. Das passiert im L2 und L3 heute nur noch direkt in den Port ASICS, sprich also direkt im Silizium.
    die Gateway-Adresse des Subnetzes, welches im DHCP defeniert, eine andere ist, als die des Interface, worauf der DHCP-Server arbeitet, geht dann immer noch alles gut?
    Nein, das geht dann immer in die Hose weil ein gravierender Konfig Fehler. Das next Hop Gateway muss natürlich logischerweise immer in einem IP Netz liegen was direkt erreichbar ist.
    Gateway IP Adressen findest du deshalb auch logisch NICHT in der Interface Konfig sondern immer im globalen Routing Konfig Menü. face-wink
    Member: PackElend
    PackElend Jun 17, 2021 updated at 14:00:40 (UTC)
    Goto Top
    die Antworten werden schmaler, scheint wir kommen voran face-smile

    Meine fundamentalen Fehler:
    • Bridge ist ne Bridge wie in Neandertaler Netzwerk Zeiten, sprich Trennung der Collision Domains face-surprise
    • Gateway ist ein Dienst, ist aber nur eine Router zu einem IP-fähigen Interface, worauf Dienst zur Verfügung stehen. Der Begriff ist so ausgelutscht... face-devilish
    • Nicht geht über das Routing, alles was ich die mit IPs mache geht in den RIB/FIB, so das in Interface wohin es Traffic weiterreichen muss.
    What is a default gateway? | IT PRO
    What Is a Default Gateway in Networking?
    Das Interface hat Zugriff, bzw. redet mit ROS, wegen der Landkarte (RIB/FIB), worin neben dem Ausgang (Gateway, next hop) auch Passbüro (DCHP) usw. eingetragen sind, da ich die Routen entsprechen eingetragen habe. Das Passbüro weiss z. B. nicht von selbst wo das Interface ist, sonder muss auch erst auf die Landkarte schauen.
    Ich hoffe die Analogie ist so passend.


    Meine nächsten Aufgaben.
    • Configs erstellen
    • auf der FritzBox die statische IP für das WAN interface auf dem CCR eintragen
    • LAN zum Laufen bringen
    • WLAN zum Laufen bringen
    • Firewall einstellen für meine Gegensprechanlage: https://2nwiki.2n.cz/display/FAQ/My2N+-+Mobile+Video+troubleshooting
    • das hier gelernt dokumentieren in der Hoffnung das ich für alles eine bildliche Beschreibung finde , welche aus dem alltäglichen Leben kommt (sonst habe ich es in einem halben Jahr schon wieder vergessen)
    • dann mal schauen was mache als nächstes
    Member: aqui
    aqui Jun 17, 2021 at 14:38:03 (UTC)
    Goto Top
    scheint wir kommen voran
    👍 So ist es !
    Dann auf zu deinen "nächsten Aufgaben" !! 😉
    dann mal schauen was mache als nächstes
    Vielleicht WLAN_mit_dynamischer_VLAN_Zuweisung face-big-smile
    Spaß...Im Ernst: Erstmal ein Projekt sauber zuende bringen !!!
    Member: PackElend
    PackElend Jun 21, 2021 updated at 20:56:22 (UTC)
    Goto Top
    Guten Abend,
    erstmal die guten Nachricht vorne Weg, ES LÄUFT face-smile face-smile, VIELEN DANK (einzig VOIP hat vielleicht noch Schluckauf).
    Nachdem ich so gefühlt zwei Tag die Konfigurationsdateien erstellte habe, habe ich gestern angefangen alles aufzuspielen. Ging natürlich nicht reibungsfrei, hier mal eine Kleinigkeit vergessen oder vertippt, bzw. da mal ein Leerzeichen zuviel.
    Ich habe gerade das letzte momentan aktive Edge-Gerät eingerichtet. Bei den cAP ac habe ich noch gar nichts gemacht.

    Das letzte Geräte war ein hAP ac3, wobei ich dort eine IP aus dem MGMT-Netz bekommen habe über das AP, mit welchem ich verbunden war. PVID war aber für das dort vorgesehene VLAN eingestellt. Warum das so ist, obwohl VLAN-Filtering noch nicht aktiv war ist mir noch nicht ganz klar.
    Dies bringt mich aber zu der eigentliche Frage, wie sollen VLANs auf den Edge-Geräte eingerichtet werden?
    Die Edge-Swichtes
    • hEX S
    • hEX PoE (momentan ohne aktives VLAN-Filtering)
    sowie meine Edge-Swichtes und AP in einem
    • hAP ac3
    verfügen alle über einen Switch-Chip, der nur begrenzt Hardware-Offloading unterstüzt. Wenn über die nun mehere Netz laufen, vor allem die Teilnehmer im WLAN, wäre es natürlich schon schick, wenn so viel wie geht nur über den Switch-Chip geht.
    Vor allem beim hEX PoE wäre es wünschenswert, da dieser drei (vielleicht auch 4) hAP ac3 versorgt, worüber später durchaus einige Teilnehmer mit dem WLAN verbinden. Hinzu kommt, dass bei zwei hAP ac3, je LAN2 ein AP hat.
    Einige sind sicher nicht mehr als 10 Teilnehmer, wobei sicher nicht alle zugleich Streams ziehen.
    Insgesammt sind es vier (fünf mit Dach) Etagen die abgedeckt werden, worüber 8 Parteien verteilt sind.
    Ich habe mir nochmals die Switch-Chip der Geräte angeschaut, Switch Chip Features - RouterOS - MikroTik Documentation sowie die Bridge - RouterOS - MikroTik Documentation]:

    Block Diagram SW Chip Port Switching Vlan table Rule table Features in Switch menu BR STP/RSTP BR MSTP BR IGMP Snooping BR DHCP Snooping BR VLAN Filtering
    hEX S Switching OFF ------ no no no - - - - - -
    hEX S Switching ON MT7621 yes no no + - - - - -
    hEX PoE QCA8337 yes 4096 entries 92 rules + + - - (+) -
    hAP ac3 Atheros8327 yes 4096 entries 92 rules + + - - (+) -
    cAP ac Atheros8327 yes 4096 entries 92 rules + + - - (+) -
    CCR1009-8G-1S-1S+ Atheros8327 yes 4096 entries 92 rules + + - - (+) -

    Mit VLAN filtering ist nichts zumdem kommt hinzu das der SFP nicht am Switch-Chip hängt, somit geht es beim Weg zu VLAN-Trunk immer über die CPU.
    Beim hEX PoE hätte ich noch ein Port frei und könnte ein weiters Kupfer in den Keller ziehen, wenn es der Sache hilft. Die hEX S können nur mittels Glas angeschlossen werden.
    Es kommt auch hinzu, dass ich auf dem NAS Unmengen an Fotos etc. habe, da wäre es schickt, wenn so wenig möglich de Verbindung vom Endgerät zum NAS über Switch-CPUs geht face-monkey-

    So ist die Frage nun das ganze optimieren, da ich mich mit nicht-Bridge-VLAN noch nicht im Detial beschäftigt habe, kann ich dazu noch nichts sagen.
    Wisst ihr Rat?


    Jetzt kommt die spannende Frage, wie richte ich die VLANs auf den APs ein. Momentan sind alle WLAN-VLANs auf dem tagged-port angeben, ist das schon mal die richtige Vorraussetzung für das WLAN später?
    Nach Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik und Funkkutscher | c't | Heise Magazinezu urteilen ja.
    Ich frage, da es ja zwei Optionen gibt, wie es vom WLAN-Chip zum Router geht:
    1. VLAN per SSID / VLAN per Radius-Eintrag --> WLAN-Controller --> AP-CPU --> tagged port
    2. VLAN per SSID / VLAN per Radius-Eintrag --> WLAN-Controller--> CAPsMAN Tunnel --> AP-CPU --> tagged port aber weniger VLANs im VLAN Table
    Nun die Frage, mag es angesicht des nicht möglichen Hardware-Offloading des VLAN-Filtering sinnvoll sein alles in einen CAP to CAPsMAN Tunnel zu legen, welcher dann auf dem Router ausgekoppelt wird?


    Abschliessend für heute, wie sind die Schritte für eine schlichtes WLAN, so dass die Benutzer auf die Web-Oberflächen ihrer jeweilgen Innensprechstelle im IoT-Intercom-VLAN zu greifen können?
    WLAN einfacher der Bridge-VLAN hinzufügen und fertig?
    Ich lese mich gerade in CAPsMAN | MUM MikroTik


    Wenn ich die Einstellungen auf LAN-Seite dann durchgekaut sind, schiebe ich die Konfigurationen auf GitHub und mache mich nach der WLAN-Einrichtung an die Dokumentation mit meinen "was habe ich gelernt" um endlich die gefühlt 100+ Tabs schliessen zu können.


    Hier noch meine lokalen Netze. Die erlaubten Bereiche sind etwas inflationär verwendet aber so ist die Verwechslungsgefahr für mich geringer.
    War eine entsprechende Klick-Orgie auf der Fritz!Box aber die Konfigurationen hat es nicht unnötig verkompliziert danke Notepad++ face-smile.
    ip-range subnet vlan-id comment
    192.168.066.066/24 ---- WAN INTERFACE IP
    010.010.000.000/21 255.255.248.0 x COMMON SERVICES AND DEVICES / OFFICE
    010.010.001.000/24 1 BLACKHOLE
    010.010.002.000/24 2 PRINTERS, SCANNERS
    010.020.000.000/16 255.255.0.0 xx IoT SUBNETS
    010.020.001.000/24 11 IoT_INTERCOM
    010.099.099.000/24 99 BASE (MGMT) VLAN
    010.1xx.000.000/xx 1xx PERSONAL VLANs
    010.110.000.000/24 255.255.0.0 110 MAIN VLAN OF USER1 FOR LAN
    010.110.001.000/24 111 MAIN VLAN OF USER1 FOR WLAN
    010.120.000.000/24 255.255.0.0 120 MAIN VLAN OF USER2 FOR LAN
    010.120.001.000/24 121 MAIN VLAN OF USER2 FOR WLAN
    010.130.000.000/24 255.255.0.0 130 MAIN VLAN OF USER3 FOR LAN
    010.130.001.000/24 131 MAIN VLAN OF USER3 FOR WLAN
    010.140.000.000/24 255.255.0.0 140 MAIN VLAN OF USER4 FOR LAN
    010.140.001.000/24 141 MAIN VLAN OF USER4 FOR WLAN
    010.150.000.000/24 255.255.0.0 150 MAIN VLAN OF USER5 FOR LAN
    010.150.001.000/24 151 MAIN VLAN OF USER5 FOR WLAN
    010.160.000.000/24 255.255.0.0 160 MAIN VLAN OF USER6 FOR LAN
    010.160.001.000/24 161 MAIN VLAN OF USER6 FOR WLAN
    010.170.000.000/24 255.255.0.0 170 MAIN VLAN OF USER7 FOR LAN
    010.170.001.000/24 171 MAIN VLAN OF USER7 FOR WLAN
    010.180.000.000/24 255.255.0.0 180 MAIN VLAN OF USER8 FOR LAN
    010.180.001.000/24 181 MAIN VLAN OF USER8 FOR WLAN
    010.200.000.000/15 255.254.0.0 2xx GUEST VLANs
    010.200.000.000/16 200 GUEST LAN
    010.201.000.000/16 201 GUEST WLAN
    172.016.000.000/12 255.240.0.0 3xx DMZ
    172.016.001.000/24 301 NAS(s)
    192.168.000.000/16 255.255.0.0 4xx LAB
    192.168.001.000/24 401 JOB DEVICES
    Member: aqui
    aqui Jun 22, 2021 at 10:10:31 (UTC)
    Goto Top
    wie richte ich die VLANs auf den APs ein.
    Kommt drauf an ob statisch oder dynamisch ?
    Statisch konfiguriert findest du es im Mikrotik Tutorial, Kapitel 4 und 5.
    Dynamisch dann unter dem oben von dir schon zitierten Tutorial.
    Zentral auf den Controller getunnelte AP Verbindungen solltest du heutzutage wegen der schlechten Skalierbarkeit nie mehr nutzen. Das ist Steinzeit. Wenn solltest du immer nur mit sog. local Termination arbeiten also dem direkten Auskoppeln des WLAN Traffics am AP auf die Switching Infrastruktur.
    Ein Tunnel ist absolut kontraproduktiv. Bei 10 Tunneln mit .11ac Bandbreiten müsstest du in den 10G Bereich gehen. Solche Datenraten in Tunnel zu en- und dekapsulieren erfordert riesige CPU Performance von der Infrastruktur mal ganz abgesehen. Sowas ist heutzutage unsinnig. Macht man nur in sehr seltenen Ausnahmen wenn du z.B. AP Traffic über ein öffentliches Netz transportieren musst.
    WLAN einfacher der Bridge-VLAN hinzufügen und fertig?
    Jepp, genau so ist es bei einer einfachen Anbindung.
    Member: PackElend
    PackElend Jun 22, 2021 updated at 13:20:20 (UTC)
    Goto Top
    Wenn ich es richtig sehe, ist egal ob ich mit CAPsMAN weitergehe oder jeden AP individuell einrichte, keine Einstellungen auf jeweiligen Bridge anzupassen.
    Auf den APs fliegen nur die 111, 121, 131, 141 .. 181 VLANs aus dem VLAN-Table und werden später, im Schritt 02, einfaches WLAN, durch die (virtuellen) Wireless Interfaces ersetzt. Somit könnte ich diesbzgl. die Konfiguration abschliessen und sie auf GitHub schieben.
    Auf den APs nenne ich dann die Bridge_VLAN noch in Bridge_VLANs&WLANs um.


    Ich frage mich aber ob VLAN Filtering auf dem hEX PoE nötig ist, denn es gibt ja nur tagged ports.
    Allein Ether1 ist noch Reserve und ist ein Management Backup Port.
    Ich frage deshalb, weil ich malwieder So you have 500Mbps-1Gbps fiber and need a router READ THIS FIRST - Hardware Questions and Recommendations - OpenWrt Forum lese, ich aber noch keinen vernüftigen Zusammenhang finden konnte zwischen CPU und maximalen Durchsatz, wenn auf meinen Edge Switches ein Software-Switch arbeitet, da Harware Offloading aufgrund von VLAN-Filtering nicht geht, Fast Forward ist aber zumindest aktiv.
    Die Testergebnisse sagen es reicht wohl:
    aber bin mir nicht hunderprozentig sicher ob mein Szenario abgedeckt ist.
    Lese dazu auch gerade Understanding throughput - MUM - MikroTik aber 1 G
    Frage mich aber weiterhing was mit
    1G all port test
    gemeint ist.
    Schlicht und einfach, alle Port sind über 1G verbunden und jetzt mal schauen wieviel die CPU durchlässt?


    Weitere Frage, macht Bridge VLAN ingress filtering Sinn?
    Ich erwarte ja eigentlich keine anderes VLAN von der CPU kommend, auf den Switches, aber dann wäre es konsistent mit den anderen untagged ports?


    Die nächsten Schritte sind dann
    1. WLAN einrichten
    2. min. Firewall einrichten NATs, min .Schutz von aussen, als gäbe es die Firtx!Box nicht
    3. dokumentieren
    4. Simulation auf GNS3 einrichten
    5. Log-Server einrichten, so dass ich sehe was alles passiert
    6. mit Dude vertraut machen und WLAN APs optimal platzieren
    7. Radius-Server einrichten
    8. dann so Sachen wir Zertifikate einbinden, so dass es bei dem Zugriff auf IoT-Geräte zu keiner Warnung mehr kommt
    klingt vernünftig oder?
    Member: aqui
    aqui Jun 22, 2021 updated at 14:11:24 (UTC)
    Goto Top
    Wenn ich es richtig sehe, ist egal ob ich mit CAPsMAN weitergehe oder jeden AP individuell einrichte
    Das ist richtig !
    keinen vernüftigen Zusammenhang finden konnte zwischen CPU und maximalen Durchsatz
    Einfach mal selber messen ! iPerf3 oder NetIO sind deine besten Freunde und rennen auf jeder Plattform.
    https://web.ars.de/netio/ bzw. http://www.nwlab.net/art/netio/netio.html und http://www.nwlab.net/art/iperf/
    Weitere Frage, macht Bridge VLAN ingress filtering Sinn?
    Nein, da reicht es wenn du in Bridge VLANs die VLAN IDs definierst und die dazugehörigen tagged Ports.
    klingt vernünftig oder?
    Absolut ! Ein ToDo Plan ist die halbe Miete ! face-wink
    Zu Logging und Radius Server findest du hier noch ein paar Anregungen. Ebenso wenn du mit sFlow oder NetFlow ein paar Flow Analysen machen willst was so an Traffic und wieviel im Netzwerk bei dir so rumwerkelt.
    https://mum.mikrotik.com/presentations/LB19/presentation_6352_1548734037 ...
    Member: PackElend
    PackElend Jun 22, 2021 at 15:04:39 (UTC)
    Goto Top
    Zitat von @aqui:
    keinen vernüftigen Zusammenhang finden konnte zwischen CPU und maximalen Durchsatz
    Einfach mal selber messen ! iPerf3 oder NetIO sind deine besten Freunde und rennen auf jeder Plattform.
    https://web.ars.de/netio/ bzw. http://www.nwlab.net/art/netio/netio.html und http://www.nwlab.net/art/iperf/
    und wie ist es mit dem Bandwidth Test von ROS?
    Member: aqui
    aqui Jun 22, 2021 at 16:26:18 (UTC)
    Goto Top
    Kann ich nicht sagen hab ich noch nie genutzt. M.E. ist auch ein Test mit Clients erheblich realitätsnäher.
    Member: PackElend
    PackElend Jul 04, 2021 at 21:40:47 (UTC)
    Goto Top
    Guten Abend,
    da bin ich wieder. Ein Gerätetyp meine 2N Gegensprechanlage macht(e) mir noch Bauchschmerzen aber ich habe mich diese Wochenende an das WLAN gemacht und es scheint es geht teilweise.
    Die Konfiguration für das LAN haben ich auf GitHub hochgeladen.

    Hier meine Erfahrungen:
    1. Wenn VLAN-Filtering auf dem AP (cAP AC) nicht aktiv ist wird dieser mit seiner IP in /caps-man remote-cap angezeigt. Wenn es aber nur aktiv sehe ich es ihn nur mit seiner MAC. Liegt dies daran, dass die CAP zu CAPsMAN Kommunikation nun im VLAN99 stattfindet und alles über die MAC läuft. Davor hat der CAP->CAPsMAN den VLAN-TAG 1 bekommen als er in das tagged Port des uplink Switches eingetreten ist und sie über Layer 3 miteinander geredet haben (obwohl die statische IP auf dem CAP im gleichen Netz ist, wieder die des Routers worauf der CAPsMAN läuft)
    2. Wenn mein Android nur mit einem Balken mit dem 2.4 GHz WiFi vom hAP ac3 verbunden ist, gibt es kein Internet mehr aber sonst klappt es face-smile, liegt wohl an noch nicht optimierten WLAN-Einstellungen(?).
    3. Die dynamischen Wireless-Interface werden in /interface vlan als tagged ports gelistet aber sind dies nicht untagged / access ports da sie ja nur eine einzige, in /caps-man datapath eingestellte, VLAN-ID zulassen?


    Zudem bin ich einer miessen Sache heute aufgelaufen, was mich doch einiges an Zeit gekostet hat.
    Eventuell kann mir jemand sagen wie es dazu kam.
    Ich habe zuerst den CAP auf dem cAP ACkonfiguriert und dann denn CAPsMAN. Dadurch ist es wohl dazugkekommen, das CAPsMAN zwei CAP Interfaces (cap1 und cap2) angelegt werden, welche ich als in /caps-man interfaces mit Status MB sehe.
    Ich dachte die hat mir CAPsMAN angelegt, dass ich je ein Master Interface für 2.4 GHz und 5 GHz habe.
    So habe ich dann angefangen /caps-man datapath, /caps-man security und /caps-man configuration anzulegen aber das Provisionig und die dynamische Interface-Erstellung per SSID hat nie geklappt.
    Dann habe ich den CAP auf einem hAP ac3 eingeschaltet und das Provisionig ging einwand frei und ich fragte mich die gnaze Zeit warum.
    Mir ist dann mal aufgefallen, dass in /caps-man radio unter /INTERFACE cap1 steht, anstatt was ähnliches wie für den hAP ac3. Bei dieseem steht dort AP&ES_1F_MT-hAP-ac3-1. Erst hatte ich angenommen, ich kann die Auswahl des Interface beeinflussen aber die Einstellungen sind bei beiden Geräten identisch. So habe ich einfach mal cap1 und cap2 gelöscht und plötzlich ging es.
    Davor musste ich in cap1 die Einstellungen vornehmen, es ging nicht über /caps-man provisionig.
    Kann mir jemand sagen, warum CAPsMAN die zwei Interfaces angelegt hat??? Dies war auch sicher ricthtig von CAPsMAN aber hat es mich doch einges an Nerven gekostet.


    Was ist denn eine vernüftige Struktur bei /caps-man radio master-configuration und slave-configuration
    • master-configuration: nur Allgemeines wie country, channel usw.
    • slave-configuration: SSID/VLAN Spezifisches wie ssid, security usw.
    bzw. wie 5 GHZ und 2GHz am besten verwalten (trennen in den Einstellungen)


    Ich werde dann wohl noch Fragen habe zu
    • "create enabled" versus "create dynamic enabled"
    • Static Virtual
    • Save Selected
    • /caps-man security "security.encryption" vs "security.group-encryption"
    • /caps-man rate sehr tief machen