Mikrotik CRS NAT-Performance

visucius
Goto Top
article-picture
Hallo in die Runde.

Die letzten Wochen habe ich ja etwas mit RouterOS 7.1.1 und zwei CRS rumgespielt (326 und 328). Die HW der beiden ist ja ziemlich vergleichbar (inkl. System-Image) – von PoE abgesehen.

https://mikrotik.com/product/CRS326-24G-2SplusRM#fndtn-downloads

Folgende Erkenntnisse fielen da über mich her: ;-) face-wink

a) Mache ich @aquis vLAN-Standardsetup über die Bridge, bleibts bei rund 300 Mbit/s von einem vLAN ins andere. Dabei ist in der Bridge hw-offloading schon per MT-Default aktiviert. RAM ist durchgängig bei ca. 400 MB-Auslastung, Prozessor springt aber im iperf3 auf rund 50%

b) Der Switch-Chip im CRS kann natürlich mehr. Dazu muss aber ZUSÄTZLICH im Menue "Switch" ... hw-offloading Layer 3 aktiviert werden (/interface ethernet switch set 0 l3-hw-offloading=yes name=switch) mit nachfolgendem Neustart (Screenshots). Dann bekomme ich da problemlos die 940 Mbit/s im iPerf3 von einem ins andere vLAN hin. Innerhalb der vLANs ist das alles ja eh kein Thema.

Um Internetzugang am WAN-Port nutzen zu können muss ich jedoch leider das Layer3-offloading deaktivieren ... was dann wieder zu a) führt. Die FW-Regeln machen da keinen Unterschied. NAT ist aktiv (CRS hängt an einem gebridgten Vodefone-Kabel-Modem).

Jetzt die Fragen:

1. In wie fern ist NAT etwas anderes als "Routing"?!

2. Warum muss ich Layer3-hw-offload in diesem Fall überhaupt deaktivieren?!

bildschirmfoto 2022-01-22 um 16.38.00

Viele Grüße

PS: Mir ist völlig klar, dass die "Router-Branch" bei Mikrotik und den Konkurrenten – nicht umsonst – die doppelte CPU-Performance hat. Bei mir hing bis letzte Woche auch noch ein EdgeRouter mit 2 x 880 Mhz vor dem CRS: Der kann zwar kein hw-offload im Routing (d.h. max 600 Mbit/s zwischen vLAN), dafür aber 1 Gbit/s am WAN.

Mir gehts aber konkret um die 2 Fragen.

Content-Key: 1731592255

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

Ausgedruckt am: 17.05.2022 um 20:05 Uhr

Mitglied: Spirit-of-Eli
Spirit-of-Eli 22.01.2022 aktualisiert um 17:51:08 Uhr
Goto Top
Moin,

ich kann dir gerade keine gesicherten Infos liefern.
NAT ist jedoch eine Tabelle für die Portzuordnung. Das kann, soweit ich weiß, nur mit spezial-HW auf der HW selbst gemacht werden.
Ähnliches gilt übrigens für BGP Router mit der Routingtable. Da kann ich dann doch aus Erfahrung sprechen. (Im 7er Release gab es da gerade Anpassungen bei Mikrotik)

Der Punkt weswegen ich mich melden, ist die Aktivierung von "L3 Hw Offloading". Ich habe das gerade bei meinem CRS326 aktiviert und einen immensen Performance Schub feststellen können, obwohl die CPU vorher auch nicht großartig ausgelastet war. Ich frage mich, wieso dies nicht default aktiviert wird? (Die Ports zeigen in der Bridge das offloading auch ohne den Haken an, daher dachte ich, dies wäre bereits aktiv.) Hast du da eine Idee?

Gruß
Spirit
Mitglied: Visucius
Visucius 22.01.2022 aktualisiert um 18:06:28 Uhr
Goto Top
Der Punkt weswegen ich mich melden, ist die Aktivierung von "L3 Hw Offloading".
Cool, gelle?! ;-) face-wink

Ging mir ähnlich. Ich habe den 326 jetzt seit Mai/21 und ihn mit - viel Ausdauer von @aqui - damals schon versucht zu konfigurieren. Der hatte dann max 165 Mbit/s zwischen den vLANs und auch dem Support von Mikrotik ist dazu nix eingefallen, außer, dass sie es im Labor nachstellen konnten ...

Für mich war das dann ein sehr unbefriedigender "Bug" und die Kiste lief deshalb bis letzte Woche erstmal mit switchOS hinter dem edgerouter der die vlans verwaltete.

Das mit dem "Switch-Menue" hatte ich irgendwo in der Doku von Mikrotik gefunden und jetzt mal ausprobiert. Der Kunden-CRS328 kam mir dafür gerade Recht.

Beruhigt mich irgendwie, dass ich nicht der einzige bin, der das noch nicht wusste ;-) face-wink

Hast du da eine Idee?
Nö. Evtl. aber weil es bei den WAN-Ports ja nicht aktiviert sein darf und man sich diese Komplikation sparen möchte?! Ich verstehe auch nciht, warum der Support damit so Probleme hattte?! Die hatten mein komplettes Setup ja vorliegen gehabt. Es scheint aber ein reines "CRS"Thema unter routerOS zu sein.
Mitglied: Spirit-of-Eli
Spirit-of-Eli 22.01.2022 um 18:17:30 Uhr
Goto Top
Ich habe ebenfalls irre lange an dem Hobel herumgebastelt.
Mit dem flag konnte ich gerade echt die Bandbreite im selben VLan über mehrere Ports hinweg auf 1Gbit steigern. Meine Test blieben dabei ziemlich konstant.

Allerdings muss ich auch gestehen, dass ich mit aquis Guides nicht 100% konform gehe, oder sie ggf. nicht ganz verstanden habe.
Ein Bridge Setup bau ich immer wie folgt auf:
  • tagged Ports immer tagged in der bridge eintragen.
  • nur eine einzige bridge verwenden.
  • untagged Ports untagged in der bridge eintragen und PVID setzen.
  • Nur für Mgmt oder Router Dienste ein Interface mit IP sowie VLan erstellen und der bridge tagged hinzufügen.

Damit ist die Performance schon sehr gut. Ich fahre hier im Regelfall 600-800MBit ohne das offloading flag im Switch selbst. Die Bridge zeigt aber, wie schon erwähnt, das offloading an. Sehr merkwürdig.
Zugegeben trifft dies jetzt nicht dein Setup. Fürs Routing/NAT nutze ich persönlich meine Sense oder im Business Bereich einen Router.
Mitglied: Spirit-of-Eli
Lösung Spirit-of-Eli 22.01.2022 aktualisiert um 18:25:26 Uhr
Goto Top
Zitat von @Visucius:
Hast du da eine Idee?
Es scheint aber ein reines "CRS"Thema unter routerOS zu sein.

Okay, das ist schon interessant. Bin gespannt ob sich das noch irgendwie vereinfachen lässt.

Was passiert denn, wenn du das Offloading im Switch Chip aktivierst und es für den WAN Port explizit raus nimmst?
Dieser WAN Port darf ja auch nicht Teil der Bridge sein, wenn man aquis Tut folgt.

Edit: habe es gerade in deiner Konfig gesehen. Die WAN Ports sind zumindest nicht Teil der bridge.
Edit 2: Und das hier deaktiviert es, wie von mir vorgeschlagen, richtig?

Hast du hiermit schonmal Probleme gehabt?:
Habe habe das mittlerweile auf all meinen Mikrotiks deaktiviert da es zu den bescheuertsten Phänomenen geführt hat.
Mitglied: colinardo
Lösung colinardo 22.01.2022 aktualisiert um 19:14:33 Uhr
Goto Top
Servus,
Hast du dir das Beispiel (und die Erläuterungen darüber) hier durchgelesen?
Inter-VLAN Routing with Upstream Port Behind Firewall/NAT

Zu Frage 1:
NAT ist ein Firewall-Feature in der POST- und PREROUTING Chain und um dieses nutzen zu können muss der entsprechende Port vom L3 HW Offload ausgenommen werden da die Pakete sonst an der CPU/Firewall vorbei gehen.

Zu Frage 2:
L3 HW Offload musst du nur am Uplink (WAN) Switch-Port deaktivieren da dort sonst die Firewall umgangen wird (siehe Beispiel im Link).

Grüße Uwe
Mitglied: sk
Lösung sk 22.01.2022 aktualisiert um 19:12:30 Uhr
Goto Top
Hallo,

Zitat von @Visucius:
Mache ich @aquis vLAN-Standardsetup über die Bridge, bleibts bei rund 300 Mbit/s von einem vLAN ins andere. Dabei ist in der Bridge hw-offloading schon per MT-Default aktiviert. ... Der Switch-Chip im CRS kann natürlich mehr. Dazu muss aber ZUSÄTZLICH im Menue "Switch" ... hw-offloading Layer 3 aktiviert werden (/interface ethernet switch set 0 l3-hw-offloading=yes name=switch) mit nachfolgendem Neustart (Screenshots). Dann bekomme ich da problemlos die 940 Mbit/s im iPerf3 von einem ins andere vLAN hin.

Du wirfst die Layer durcheinander!
Das Hardware-Offloading in der VLAN-Bridge betrifft das Layer2-Forwarding. Ohne dieses muss der MT bereits die Ethernetframes zwischen den Switchports auf der CPU verarbeiten.
Beim L3-Hardware-Offloading geht es - wie der Name schon sagt - um Layer3-Forwarding, also um die IP-Ebene.

Wie Uwe schon richtig ausführte, macht der MT Firewalling und dessen Abfallprodukt NAT auf der CPU. Lässt Du den IP-Traffic vom Switch-Chip abarbeiten, dann läuft dieser am Firewallregelwerk vorbei.
Ich erinnere mich aber noch ganz dunkel an meine MTCNA-Schulung vor ziemlich genau 10 Jahren, dass es mittels "Fasttrack" dennoch die Möglichkeit gab, auch den Firewalltraffic zu beschleunigen. Viel mehr als der Begriff ist mir aber leider nicht hängen geblieben. Ich nutze MT im Wesentlichen nur privat als Accesspoints und beruflich nur für ganz wenige Spezialfälle, wo es auf Performence bisher nie ankam.

Gruß
Steffen
Mitglied: Spirit-of-Eli
Spirit-of-Eli 22.01.2022 um 19:17:50 Uhr
Goto Top
Danke für die Erklärung!
Mitglied: Visucius
Visucius 23.01.2022 aktualisiert um 11:31:30 Uhr
Goto Top
@Spirit-of-Eli
aquis Guides nicht 100% konform gehe
Also ich habe da zusätzlich noch:
https://help.mikrotik.com/docs/display/ROS/Bridging+and+Switching
und Teilen dieses Videos hier:
https://www.youtube.com/watch?v=YLtGQAQ8iS0

zu Rate gezogen.

Jo, bei mir gibts auch nur eine Bridge und die 2 x WAN sind sozusagen "außerhalb" (siehe Screenshot).
Bridge > vLANs ist überall die Bridge als "tagged" eingetragen (siehe Video) und ggfs. die Trunk-Ports. Untagged ist NICHT eingetragen, das geht automatisch.
Das Mgmnt-vLAN kommt aktuell noch am Port4 untagged raus. Mit dem Konzept "mgmnt-vLAN" bin ich noch nicht so ganz warm geworden. Mikrotik bietet ja auch "Hybrid-Ports" an. Das wollte ich mir nochmal ansehen.

bildschirmfoto 2022-01-23 um 10.39.33
bildschirmfoto 2022-01-23 um 10.54.46

re hier im Regelfall 600-800MBit ohne das offloading flag im Switch selbst.
Wow, das sind ja Werte von denen ich nur träumen konnte. Meine 165 mbit waren halt einfach inakzeptabel ... weshalb ich mir das nochmal genauer angesehen habe.

Was passiert denn, wenn du das Offloading im Switch Chip aktivierst und es für den WAN Port explizit raus nimmst?
Genau so ist es ja (wie Du schon anmerktest). "Global" wirds am Chip aktiviert. Ich meine - das müsste ich prüfen - damit ist es auf allen Ports auch aktiviert und muss bei den WAN-Ports wieder deaktiviert werden. Hatte ne Weile gedauert, bis ich das merkte. Ich kam nur drauf, wegen des dann "defekten" Internetzugangs ;-) face-wink

/interface detect-internet
Hm, das ist ne super Frage. Ich hatte das nur aktiviert um zu sehen ob der Port das Internet "sieht". Weil mit hw-offloading ja der WAN Probleme machte. Und danach blieb das aktiviert. Manchmal scheint der Router allerdings extrem langsam auf Internet-Anfragen zu warten bzw. abzubrechen. Das habe ich aber aktuell eher auf meine 2 WANs bzw. deren Routing geschoben. Dafür habe ich mir übrigens dieses Script hier abgewandelt:

https://buananetpbun.github.io/mikrotik-failover-script-generator.html (netwatch).

Und aktuell testweise die "distance" in der 2. Route von 2 auf 5 erhöht.

@colinardo
Neee, habe ich nicht ;-) face-wink Aber Danke Dir, das erklärt mit dem Best-Practice-Beispiel ja die Performance-Aspekte. Ich vergleiche das mal mit meinem Setup nachher im Büro.

Und nochmals Danke für die Erläuterung des Verhaltens! Was allerdings auch dazu führt, dass ich das hw-offload an meinem Mgmnt-Port deaktivieren muss 😡

@sk
Du wirfst die Layer durcheinander!
Bestimmt immer mal wieder – hier aber nicht. Ich habs nur ggfs. missverständlich formuliert. Layer3 = routing = zwischen vlans, Layer2 = switching innerhalb des vlans. Und die Frage kam dann, ob NAT was anderes ist als Layer3-Routing.

Mir war aber der Rest nicht klar. Wo was abläuft und das hw-offloading am "hirn" vorbeiführt. Auch wenn das jetzt - im Nachhinein - ganz logisch klingt ;-) face-wink

Das "Fasttrack"-Thema hatte ich irgendwo gesehen aber wusste nicht, was es damit auf sich hat. In @colinardo s Best-Practice-Setup ist es ebenfalls aktiviert und wenn ich mir mal die Ergebnisse auf nem lütten 600 Mhz RB2011 ansehe (ganz unten)

https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack

wird das mein Problem bestimmt hinreichend adressieren! Dickes Danke dafür, ich probiere das nachher gleich mal!

Viele Grüße aus dem verschneiten Süden
Mitglied: Spirit-of-Eli
Spirit-of-Eli 23.01.2022 um 19:56:57 Uhr
Goto Top
Ich habe hier noch einen Foren Beitrag zum L3 HW Offloading gefunden:
https://help.mikrotik.com/docs/display/ROS/L3+Hardware+Offloading

Das macht einen guten Eindruck. Vor allem wird für mich die L2 und L3 Konfig explizit differenziert.
Mitglied: aqui
aqui 23.01.2022 um 22:50:48 Uhr
Goto Top
Ein Bridge Setup bau ich immer wie folgt auf:
Entspricht doch vollständig auch dem was im Tutorial steht ?! Ist also konform zu dem was du auch machst.
Ob man den WAN Port über einen dedizierten Port im Routing Mode laufen lässt oder über ein VLAN IP Port ist eher eine kosmetische Frage
UNtagged Ports müssen nicht in der VLAN Bridge eingetragen werden. Die richtige PVID Zuordnung reicht dafür völlig aus.
Steht aber so auch alles im Tutorial. ;-) face-wink
Mitglied: Spirit-of-Eli
Spirit-of-Eli 23.01.2022 um 23:14:05 Uhr
Goto Top
Zitat von @aqui:

Ein Bridge Setup bau ich immer wie folgt auf:
Entspricht doch vollständig auch dem was im Tutorial steht ?! Ist also konform zu dem was du auch machst.

Okay, dann habe ich es doch richtig verstanden.

UNtagged Ports müssen nicht in der VLAN Bridge eingetragen werden. Die richtige PVID Zuordnung reicht dafür völlig aus.
Steht aber so auch alles im Tutorial. ;-) face-wink

Macht es einen unterschied ob die Ports auch untagged in der bridge stehen? Ich habe bisher immer beides gemacht.
Mitglied: aqui
aqui 23.01.2022 aktualisiert um 23:27:26 Uhr
Goto Top
Es schadet nicht, ist aber völlig überflüssige Arbeit. Denn wenn die Ports einen aktiven Link haben trägt der Switch sie eh automatisch ein. PVID reicht also völlig. ;-) face-wink
Mitglied: Visucius
Visucius 30.01.2022 aktualisiert um 17:06:51 Uhr
Goto Top
So, jetzt wollte ich doch nochmal kurz Feedback in die Runde werfen!

Neben dem oben genannten
https://help.mikrotik.com/docs/display/ROS/L3+Hardware+Offloading
ist zum Verständnis durchaus auch sinnvoll sich mal
https://help.mikrotik.com/docs/display/ROS/Basic+Concepts > FastTrack
durchzulesen.

Es genügt – von der Standard-FW aus kommend - unterhalb der Input-Chain noch eine Forward-Chain mit fasttrack (established, related) anzulegen. UND darunter(!) noch eine zweite identische OHNE FastTrack und OHNE hw-offload, als Fallback, bzw. den Datenverkehr, der nicht über Fasttrack laufen kann. Der Rest (z.B. Mangle-Rules) werden automatisch angelegt.

Anmerkung für Neulinge:
Ich habe den hw-offload dafür nicht übers Interface gefunden sondern nur über den CLI-Befehl. Ohne "hw-offload=yes" bringt die Regel nix und man sieht auch, dass kein Traffic darüber läuft. Das klingt zwar logisch ... im Mikrotik-Beispiel wird die Regel aber ohne hw-offload angelegt!

Dafür wird hier sogar noch eine Dritte Forward-Chain angelegt (die mittlere), ohne hw-offload aber mit Fasttrack, ... macht (imho) keine Sinn und geht auch ohne problemlos (unabhängig von der TCP-Einschränkung).

Lt. Mikrotik ist natürlich ausgerechnet mein CRS (328 und 326) mit dem 98DX3236 Chip vom hw-offloading im NAT und FastTrack ausgeschlossen. Ich kann aber berichten, dass der Datendurchsatz am WAN-Port trotzdem von 250 bis 300 Mbit/s auf 400 bis 450 Mbit/s angestiegen ist. Mehr ist natürlich immer toll – wir benötigen das außerhalb von Performance-Tests aber nicht ;-) face-wink

Anbei ein Screenshot meiner aktuellen FW - Feedback erbeten. Ganz besonders wegen der letzten Regel 7. Stimmt die überhaupt oder funktioniert die so nicht?! Bytes/Packets = 0:

bildschirmfoto 2022-01-30 um 16.15.17

Grundsätzlich tue ich mir etwas schwer mit der Mikrotik-Firewall. Nimmt man sich für den Anfang das "Configuration-Example" und deaktiviert "Allow ICMP", "Winbox and SSH" ... wird einem beim Portscan der öffentlichen IP erst Port 80 und dann das Login-Fenster präsentiert ... ;-(

Jetzt verstehe ich zwar, warum Mikrotik so viel Wert aufs PW legt ... das fand ich Naivling aber trotzdem etwas befremdlich?! Ganz davon abgesehen, dass das ja alles nur "Input-Chain" ist?! Ich hätte gedacht, dass auch im Standard-Setup etwas mehr Schutz von außen kommt, als nur NAT?! Ich will ja nicht ausschließlich meinen Router sichern, sondern auch das Netzwerk dahinter?!

PS: Eine Frage noch: Es scheint, als ob zwischen der Standard-FW und dem obigen Setup innerhalb eines vLANs der Chromcast nicht mehr erreichbar ist?! Airplay macht in den Nachbar-vLANs keine Probleme. Und wie gesagt - Chromcast UND Client arbeiten innerhalb des gleichen vLANs (kein Mgmnt-vLAN!). Kann doch eigentlich nur an Regel 7 liegen?! Ich kanns nur gerade nicht testen.
Mitglied: aqui
aqui 30.01.2022 aktualisiert um 17:54:05 Uhr
Goto Top
wird einem beim Portscan der öffentlichen IP erst Port 80 und dann das Login-Fenster präsentiert
Sorry, aber diese Aussage ist so nicht richtig !! Zumindestens nicht was die Mikrotik Default FW Konfiguration anbetrifft.
Dort siehst du es ja eindeutig in der Regel 5:
mtdefrule
Entsprechende Connect Requests mit dem Browser auf die WAN Port IP scheitern deshalb logischerweise auch. Wäre ja auch ziemlich fatal das HTTP Interface am WAN Port ungeschützt zu exponieren !
Auch die L2 Infrastruktprotokolle wie LLDP, CDP und das WinBox Hello sind natürlich am WAN Port per Default immer deaktiviert (WAN Interface Liste, Neighbor Discovery).
Entweder hast du also dein Default Ruleset der Firewall verfummelt oder die Interface Zuordnung in deiner Mgmt Liste oder Interface Bezeichnung oder was auch immer stimmt nicht. So kann man deine Aussage jedenfalls nicht stehenlassen wenn du vermutlich selber PEBKAC Fehler am Regelwerk fabrizierst ?! ;-) face-wink
Ein Portscan auf den WAN Port mit Default Regeln zeigt erwartbar nix an. Wie auch mit Action drop ?!
Mitglied: Visucius
Visucius 30.01.2022 aktualisiert um 20:05:44 Uhr
Goto Top
Das kann schon sein .... nur ist es ja so, dass der CRS im Default KEINE Firewall mitbringt. Habe ich hier ja schon mal nen Thread zu gemacht (und auch belegt, falls das angezweifelt wird)

Sucht man sich dann erstmal ne Default-Lösung kann man - so wie ich - durchaus im Handbuch (auch) unter
https://help.mikrotik.com/docs/display/ROS/Basic+Concepts fündig werden.

Und das - hier jetzt hier nochmal(!) - Zitat "Configuration-Example" sieht dann so aus:

bildschirmfoto 2022-01-30 um 19.27.18

Natürlich erklärt mir hier jetzt jeder, dass ich nur richtig (und umfangreich) lesen muss, gefälligst verstehen soll, es auch ein Video dazu gibt, dass ich die "First config" durchgehen soll und ich auch die IP-Bereiche des Zugriffs einschränken kann.
Nur liest man ja kreuz und quer und diese Anleitungen unterscheiden sich auch jeweils ein wenig (z.B. in der Reihenfolge) und es besteht für so Naivlinge wie mich durchaus das Risiko den kleinen eingeschobenen "ether1" (den WAN-Port in der First-Config) zu übersehen, bzw. genau das "falsche" Beispiel zu nehmen ;-) face-wink

Das sich der Effekt am Ende mit der richtigen Konfiguration beheben lässt, sieht man ja (hoffentlich) an dem Screenshot meines aktuellen Setups?! Ich unterstelle nur, dass womöglich nicht jeder seine Setups prüft.

PS: Evtl. auch Ideen zu meinen Frage(n)?!
Mitglied: aqui
aqui 31.01.2022 aktualisiert um 09:40:55 Uhr
Goto Top
nur ist es ja so, dass der CRS im Default KEINE Firewall mitbringt.
Dann bleibt es ja beim PEBKAC Fehler...! 😉
Das Beispiel Regelwerk von oben ist ja schon richtig. Nur das natürlich auch SSH und ganz besonders die WinBox nichts auf dem WAN Port zu suchen haben. Hier wäre es sinnvoller dann mit einer Liste "Mgmt" zu arbeiten dort alle Interfaces zu listen die den Zugang erlauben und die Input DROP Regel dann auf "!Mgmt" zu setzen, also alles was nicht Management ist.
Das sollte die WAN Port Problematik dann im Handumdrehen lösen.
Mitglied: Visucius
Visucius 31.01.2022 um 09:54:43 Uhr
Goto Top
Dann bleibt es ja beim PEBKAC Fehler...! 😉

Ja, kann man so sehen - wie bei fast allem, auf das man Einfluss hat. Deshalb habe ich das ja in meinem eigenem Setup letztens auch geändert.

Aber ich weise ebenso darauf hin, damit der geneigte "NOOB", der den Thread evtl. hier findet bei seinem Setup darauf achtet.

Wobei ich mir bei ner Firewall durchaus auch ne Rückfrage vorstellen könnte, a la: "Sehr geehrter Nutzer, Sie konfigurieren eine Firewall, wollen Sie das Management-Interface Ihres Routers ernsthaft mit dem nackten Arsch an Ihre öffentliche IP-Adresse dängeln?! (oder ähnliches ;-) face-wink )
Mitglied: aqui
aqui 31.01.2022 aktualisiert um 10:15:35 Uhr
Goto Top
Auf welches Niveau, meinst du denn, müssen sich Firewall Hersteller herablassen für die Konfiguration die ein solch customizebares Produkt vertreiben was ja gerade deshalb verkauft und auch nachgefragt wird ? Vielleicht solltest du hier doch einmal ein klein wenig deine eigene Perspektive wechseln ???
Auch Profis verifizieren doch immer ob ihr Regelwerk wasserdicht ist oder willst du dich auf irgendwelche obskuren, DAU freundlichen Security Modelle der Hersteller verlassen ?
Auf solchen "Rückfrage" Produkten gibt es keine Rückfragen weil Hersteller DAUs aus guten Gründen niemals an so ein Regelwerk lassen. Die müssen dann mit dem des Herstellers leben oder hast du bei einer FritzBox schon einmal gesehen das man dort die Firewall so customizen kann wie du es oben kannst ?!
Du bist doch Netzwerk Profi ! Da sind solche Dinge wie "Sehr geehrter Nutzer..." ganz sicher überflüssig.
Aber genug geschwafelt... Sei ein Profi ! Heul nich, fixe dein Regelwerk und jutt iss... !! ;-) face-wink
Mitglied: Visucius
Visucius 31.01.2022 aktualisiert um 10:27:13 Uhr
Goto Top
Du bist doch Netzwerk Profi !

Ich erkenne feine Ironie, wenn ich drüber stolpere! ;-) face-wink

Jetzt glaube ich ja
a) nicht, dass das MT-Handbuch und vor allem die einleitenden Firewall-Setups "Profis" als Zielgruppe haben.

Und lese
b) jede Woche auf IT-news-Seiten von gut ausgebildeten und bezahlten "Profis", nationaler und internationaler Unternehmen, bei denen eine zusätzlcihe Rückfrage im richtigen Moment ein Desaster verhindert hätte.

Ich - mit meiner Schusslichkeit - bin bestimmt der letzte der da Steine werfen möchte. Vermutlich sind wenig Mikrotiks in so kurzer Zeit so häufig neu aufgesetzt worden. Mittlerweile habe ich auch jede Zugangsmöglichkeit inkl. Console und jede Reset-Option ausgiebigst auf ihre Dauerbelastbarkeit testen dürfen ;-) face-wink
Mitglied: PackElend
PackElend 10.02.2022 um 21:49:05 Uhr
Goto Top
Guten Abend zusammen,
ich würde gerne nochmals das Layer3-offloading diskutieren.

Ich versuche die eigentliche Funktionsweise zu verstehen. Den einzigen Hinweis finde ich in L3HW Feature Support:

This works only for directly connected networks. Since HW does not know how to send ARP requests,
CPU sends an ARP request and waits for a reply to find out a DST MAC address on the first received packet of the connection that matches a DST IP address.
After DST MAC is determined, HW entry is added and all further packets will be processed by the switch chip.

Ich verstehe es so. Für alle CRS300 und CCR2000 gilt:
  1. neues packet kommt an und geht durch die CPU und durchläuft alles wie in Manual:Packet Flow beschrieben, wenn eine direkte Route in ein benachbartes Netzwerk (VLAN) offen ist, ohne Einschränkungen/Sonderbehandlungen wie z. B. NAT, Queuing, etc. vorgesehen sind, wird ei Route in den Speicher des Switch-Chip eingetragen
  2. weitere Pakete der gleichen Verbindung gehen nun direkt über den Switch-Chip
  3. nicht aktive Verbindungen werden aus den Speicher des Switch-Chip entfernt
--> das heisst, wenn mehrere VLANs über ein Tagged Port werden dann über Switch-Chip miteinander reden, soweit erlaubt, nicht mehr über die CPU

Bei den DX8000 and DX4000 Series, sowie dem CCR2000 kommen noch zwei Punkte hinzu:

  1. NAT, z.B. Masquerade
    1. das Erlernen der NAT Regel erfolgt analog zu allgemeinen Regel 1 oben
    2. die Übersetzung der IPs bei NAT'd wird in den Switch-Chip eingetragen
    3. weitere Pakete der gleichen Verbindung gehen nun direkt über den Switch-Chip und ich kann die individuellen IPs aus deinem VLAN bei der Kommunikation mit einem anderem VLAN verbergen

  1. FASTTRACK. für Verbindungen die nicht mehr über die gleiche Bridge laufen aber nachdem sie ESTABLISHED sind, keine Behandlung durch z. B.Queuing erfahren. Bestes Beispiel ist hier die LAN2WAN-Verbindung.
      1. das Erlernen der FASTTRACK-Verbindungen erfolgt analog zu allgemeinen Regel 1 oben
      2. Quell- und Zielschnittstellen der direkt verbundenen Netzwerke wird in den Switch-Chip eingetragen
      3. weitere Pakete der gleichen Verbindung gehen nun direkt über den Switch-Chip

Mitglied: PackElend
PackElend 11.02.2022 um 08:00:16 Uhr
Goto Top
bzgl. tagged traffic bin ich mir jetzt nicht mehr sicher wenn ich https://forum.mikrotik.com/viewtopic.php?p=910717 lese, sollte aber kommen.