MikroTik CRS354-48P hohe CPU-Auslastung im Switching
Moin zusammen!
Hier sind im Netzwerk zwei MikroTik CRS354-48P-4S+2Q+RM im Einsatz. Aktuell sind an den Switches kaum Geräte angeschlossen. (max. 10 Geräte).
Leider ist die CPU fasst immer auf 100 % in der Auslastung, ich habe die Sorge, dass dadurch die Switching-Geschwindigkeit etwas ausgebremst wird. Ich habe schon unter Tools/Profile überprüft, was die CPU-Auslastung verursacht. Dort steht Networking mit 40 - 50 % an der Spitze. Auf dem Uplink Port ist momentan ein Durchsatz von ca. 500mbit/s - max. 1,2 GBit/s.
Auf dem Switch ist RouterOS in der Version 7.9.2 installiert. Der Switch hat keine Firewall Regeln hinterlegt und nur eine IPv4-Adresse auf das VLAN-Interface im Management VLAN erhalten. Der Switch soll auch nicht routen.
Im Switch selbst ist eine VLAN-Bridge angelegt, welche die einzelnen Ports mit den entsprechenden VLANs hinterlegt sind. Auf dem Switch sind 12 VLANS angelegt. Ansonsten ist RSTP und VLAN-Filtering aktiviert.
Die physischen Ports sind unter Bridge/Ports mit H (Hw. Offloaded) markiert.
Wir haben an dem Switch 2 Uplink Verbindungen.
Uplink 1: 2x 10G SFP+ Richtung Core-Switch (Bonding Mode: balance)
Uplink 2: 2x QSFP+ Kabel (XQ+DA0001) Richtung zweiten Switch (Bonding Mode: balance)
Hat da jemand eine Idee was man machen kann, um die CPU Auslastung zu senken?
Hier sind im Netzwerk zwei MikroTik CRS354-48P-4S+2Q+RM im Einsatz. Aktuell sind an den Switches kaum Geräte angeschlossen. (max. 10 Geräte).
Leider ist die CPU fasst immer auf 100 % in der Auslastung, ich habe die Sorge, dass dadurch die Switching-Geschwindigkeit etwas ausgebremst wird. Ich habe schon unter Tools/Profile überprüft, was die CPU-Auslastung verursacht. Dort steht Networking mit 40 - 50 % an der Spitze. Auf dem Uplink Port ist momentan ein Durchsatz von ca. 500mbit/s - max. 1,2 GBit/s.
Auf dem Switch ist RouterOS in der Version 7.9.2 installiert. Der Switch hat keine Firewall Regeln hinterlegt und nur eine IPv4-Adresse auf das VLAN-Interface im Management VLAN erhalten. Der Switch soll auch nicht routen.
Im Switch selbst ist eine VLAN-Bridge angelegt, welche die einzelnen Ports mit den entsprechenden VLANs hinterlegt sind. Auf dem Switch sind 12 VLANS angelegt. Ansonsten ist RSTP und VLAN-Filtering aktiviert.
Die physischen Ports sind unter Bridge/Ports mit H (Hw. Offloaded) markiert.
Wir haben an dem Switch 2 Uplink Verbindungen.
Uplink 1: 2x 10G SFP+ Richtung Core-Switch (Bonding Mode: balance)
Uplink 2: 2x QSFP+ Kabel (XQ+DA0001) Richtung zweiten Switch (Bonding Mode: balance)
Hat da jemand eine Idee was man machen kann, um die CPU Auslastung zu senken?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7468924248
Url: https://administrator.de/forum/mikrotik-crs354-48p-hohe-cpu-auslastung-im-switching-7468924248.html
Ausgedruckt am: 27.12.2024 um 06:12 Uhr
17 Kommentare
Neuester Kommentar
Moin,
wie schaut denn deine Konfig aus? Nutzt du VLans oder spielt der CRS354 Gateway?
In dem Fall, dass der "Switch" routet, läuft sämtlicher Traffic über die CPU da kein Offloading möglich ist. Laut Block-Diagram ist die Anbindung an die CPU auch nur 1Gbs.
Unter den Ports (ink SFP+/QSFP+) sollte wirespeed möglich sein.
Gruß
Spirit
Block-Diagram:
https://i.mt.lv/cdn/product_files/CRS354-48G-4Splus2Qplus_200122.png
wie schaut denn deine Konfig aus? Nutzt du VLans oder spielt der CRS354 Gateway?
In dem Fall, dass der "Switch" routet, läuft sämtlicher Traffic über die CPU da kein Offloading möglich ist. Laut Block-Diagram ist die Anbindung an die CPU auch nur 1Gbs.
Unter den Ports (ink SFP+/QSFP+) sollte wirespeed möglich sein.
Gruß
Spirit
Block-Diagram:
https://i.mt.lv/cdn/product_files/CRS354-48G-4Splus2Qplus_200122.png
Wieso taggst du überall die VLAN-Bridge?? Der soll doch nur switchen... fürs reine Switchen brauchst du die VLANs auf dem Bridge-Interface nicht taggen, außer dem MGMT VLAN100 welches dort eine IP bezieht ...
https://wiki.mikrotik.com/wiki/Manual:CRS3xx_VLANs_with_Bonds
Was erwartest du mit proprietärem Bonding statt 803.2ad und 10GBit? Das Ding hat nur 1 CPU mit 650MHz, da ist das normal das das Teil schnell am Anschlag ist, auch ohne Routing. You get what you pay
Zeppel.
p.s. die 7.9.2 Release hat ein paar Bugs bezüglich Hardware-Offload, einige davon wurden in den aktuellen Testing-Releases behoben.
https://wiki.mikrotik.com/wiki/Manual:CRS3xx_VLANs_with_Bonds
Was erwartest du mit proprietärem Bonding statt 803.2ad und 10GBit? Das Ding hat nur 1 CPU mit 650MHz, da ist das normal das das Teil schnell am Anschlag ist, auch ohne Routing. You get what you pay
Zeppel.
p.s. die 7.9.2 Release hat ein paar Bugs bezüglich Hardware-Offload, einige davon wurden in den aktuellen Testing-Releases behoben.
Zitat von @Phil-DE:
Ich hatte das damals so gezeigt bekommen, dass das nötig ist. Aber ändert das was an der Performance?
Ja, weniger tagged packets an die CPU == CPU hat mehr freie Zeitslots = geringere CPU Last.Ich hatte das damals so gezeigt bekommen, dass das nötig ist. Aber ändert das was an der Performance?
Aber dann frage ich mich, wie die auf die Testergebnisse kommen? 300.000 sieht dann ja etwas anders aus ...
Das ist alles ohne VLAN-Filtering und Bonding/MLAG gemessen, das sind alles Features die auch die CPU zu einem Anteil belasten nicht nur den Switch-Chip.Würde es mit SwitchOS anders aussehen?
Nein, SwitchOS ist nur ein Feature reduziertes RouterOS das ehrlich gesagt auch nicht mehr großartig weiterentwickelt wird.Nutze halt keine CPU lastigen Features dann geht das mit der Möhre, alles andere hat mit der CPU keinen Sinn, selbst ne Fritte hat da um das x fache mehr Power.
Würde es mit SwitchOS anders aussehen?
Ja! Mein 326er arbeitet jetzt mit SwitchOS problemlos und ohne Performance-Issues. Zudem sind viele Fehlerquellen zus. abhängig von ROS-Version, schlicht nicht vorhanden.Backup Dir Dein aktuelles Setup und probiere es einfach aus! Die MT-Testergebnisse werden mit „using mentioned hardware and software configuration“ erhoben. Das ist bei Switch halt SwitchOS.
SwitchOS ist nur ein Feature reduziertes RouterOS das ehrlich gesagt auch nicht mehr großartig weiterentwickelt wird.
Ist das so was „gefühltes“ oder lässt sich das mit irgendwas erhärten? Frag nur, wegen der non-Dualboot-Modelledann geht das mit der Möhre
Naja Möhre?! Ist halt ne Switch-HW mit Routerfunktionalität (unter Router-OS). Ich wage zu behaupten, dass 80% der manuell konfigurierten ROS-HW nicht in ihrem Sweet-Spot läuft.
SwitchOS ist halt quasi nur ein WebGUI Interface zur Generierung von Switch-Chip Konfigurationsdateien. Die meisten Bugs/Fehler sind somit schon in Silikon gegossen und werden wohl niemals behoben werden können ohne die Hardware zu wechseln oder ein anderes OS zu verwenden was es erlaubt Workarounds darauf anzuwenden.
SwitchOS macht es dem "Laien" halt einfacher nicht in die config technischen Performance-Fallen von RouterOS zu tappen, insofern kann er es gerne ausprobieren.
Sofern man die Fallen kennt lohnt ein Wechsel nicht wirklich. Die Hardware bleibt die selbe.
SwitchOS macht es dem "Laien" halt einfacher nicht in die config technischen Performance-Fallen von RouterOS zu tappen, insofern kann er es gerne ausprobieren.
Sofern man die Fallen kennt lohnt ein Wechsel nicht wirklich. Die Hardware bleibt die selbe.
RouterOS in der Version 7.9.2 installiert.
Hast du auch den Bootloader unter System - Routerboard entsprechend auf diese Version upgedated?? Das sollte man nicht vergessen!Bonding Mode: balance
Das ist keine gute Idee und ein proprietäres Verfahren. Du solltest hier immer den Standard 802.3ad wählen. Siehe:Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Im Regelfall gilt bei Mikrotik:
Wie praktisch immer, trifft der Kollege @aqui hier wahrscheinlich den Punkt:
Alternativ könnte auch das ein Problem sein:
https://help.mikrotik.com/docs/display/ROS/Multi-chassis+Link+Aggregatio ...
wobei ich auch die Schnelle jetzt bei Dir kein L3 Routing o.ä. sehe.
Und das
ist natürlich nur richtig, soweit man mit SWOS bestimmte Konfigurationsfehler vermeidet, weil es leichter zu handhaben ist. MLAG wäre in diesem Fall auch kein Problem - das gibt es bei SWOS gar nicht.
Ich halte es für besser, sich ernsthaft mit ROS zu beschäftigen.
Viele Grüße, commodity
- Hohe CPU-Last liegt an einer Fehlkonfiguration oder Funktionsbeschränkung, die Traffic, der eigentlich im Offload laufen sollte, über die CPU leitet.
- Mögliche Fehlkonfiguration wird in den Docs direkt angesprochen.
- Man übersieht es (kennen wir wohl alle )
Wie praktisch immer, trifft der Kollege @aqui hier wahrscheinlich den Punkt:
Das ist keine gute Idee
https://help.mikrotik.com/docs/display/ROS/BondingAlternativ könnte auch das ein Problem sein:
https://help.mikrotik.com/docs/display/ROS/Multi-chassis+Link+Aggregatio ...
wobei ich auch die Schnelle jetzt bei Dir kein L3 Routing o.ä. sehe.
Und das
ist natürlich nur richtig, soweit man mit SWOS bestimmte Konfigurationsfehler vermeidet, weil es leichter zu handhaben ist. MLAG wäre in diesem Fall auch kein Problem - das gibt es bei SWOS gar nicht.
Ich halte es für besser, sich ernsthaft mit ROS zu beschäftigen.
Viele Grüße, commodity
Kannst ja mal zum Test das MLAG deaktivieren. Ich könnte mir vorstellen, dass das CPU braucht. 20 % ist ja tragbar. Sonst musst Du weiter suchen, was als CPU-lastig in Frage kommt. Ein paar Hausarbeiten können ja auch bleiben.
Ich habe hier einen CRS326. Der nur ein paar VLANs switcht und meist nicht viel tut. Liegt bei <2% Management.
Viele Grüße, commodity
Ich habe hier einen CRS326. Der nur ein paar VLANs switcht und meist nicht viel tut. Liegt bei <2% Management.
Viele Grüße, commodity
Beachte aber das der TO einen MLAG hat, also einen auf beide Member gesplitteten LAG von einem 3ten Switch. MLAG benötigt schon etwas mehr CPU, da hier Forwarding Tabellen usw. der MLAG Member übertragen werden müssen etc. Ein MLAG benötigt also immer etwas mehr CPU als ein Standard LAG der meistens ganz ohne CPU in den Port ASICS gehandhabt wird.