Hi, I have a monster vlan on MT and when I send something in between the transfer is low, what could be the reason?
Hex S Lag 802.3ad router - ether4 sfp1
Switch CSS326-24G-2S +
At the other end, proxmox also with LAG 802.3ad 1 Gbps
Before split into vlans, it flicked a full 1 Gb / s
About 25 rules per firewall, all for pppoe-out1 only
Yes, one core is 100% loaded, I changed to ethernet and the transfer improved to 30MB / s, CPU0 load: 15% CPU1: 0% CPU2: 58% CPU3: 98% - load while copying, LAG on Ethernet port 3 and 4 without SFP
Without console config files( export ), its hard to see how you have configured devices correctly. Especially the hex S which is not designed for massive loads.
That said, if your are offloading to the SWITCH CHIP of each device and NOT the CPU as you have by the looks of your winbox screen shot, you should not be having a CPU issue at all as the data should be getting transferred at wire speed. But the screen shot you are showing looks like the hex and your trying to get the CPU to do the work !
Remember most MT Router gear works like Ether— ( <–>Switch chip )-<---->(CPU), you should program for hardware switch chip offload when you can and only bring vlans up to the cpu if you actually need to firewall/filter against…
Hi.
Just FYI, when you do a export use : export hide-sensitive so that passwords etc are not shown..
Looking over your config further shows me that you are doing a LOT of CPU intensive work.
As for switch chip native & vlan traffic, it looks like all your processing needs are CPU based not switch based so there is no point trying to use the switch chip configs.
Notably you have a significant amount of firewall rules, which for each one there is a lot of work you should be able to realistically drop that to < 6 rules in the /firewall filter for efficiency, I know you have a lot there for ddos/ syn flood, but if you take a birds eye view of required rules to effectively achieve the same thing, as rules wont stop people auto scanning anyhow, because even if they are unsuccessful, your router needs to waste time still looking at the traffic, match the rule and still drop the traffic, so you better off just blocking everything except what you need to come in.
/ip firewall filter
add action=accept chain=input comment=“defconf: accept ICMP after RAW” protocol=icmp
add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=established,related,untracked
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN
That is probably all you need, even then you can remove the ICMP rule if you want so you cant ICMP to the device( or just add the “in-interface” to just the WAN for specific stuff)
Dont go overboard on filtering stuff, unless your an ISP and your passing on( forwarding ) public IP addresses to downstream - LAN devices, if your front end device is just the router and its NAT(Masquerading ), then those rules about right for ( input chain filtering rules) .
I would suggest if you have a small i5/i7 computer lying around around install CHR version of RouterOS on that and forget your processing limitation troubles( a get a P1 license from mikrotik ). I run it in VMWare Esxi and can move significant amounts of VLAN traffic thats filtered on a x86 box and it doesnt break a sweat !!
Edit: I just realized you were possibly asking about inter-vlan (i.e. between vlan) performance, and that is going to be limited by routing performance. The following will improve performance between devices in the same vlan however, since in that case the CPU will never even see the packets. But if you are talking about traffic between vlans, then that traffic must be routed, and the MT7621 isn’t a high performance router.
Edit2: And I didn’t read the part about bonding (lag) and one core at 100%. You have reached a CPU limitation. what does /tool profile show?
What specific files would you need to evaluate my configuration?
aug/19/2022 18:10:36 by RouterOS 6.49.6
model = RB760iGS
Hardware offloading of vlan-filtering to switch ASIC in MT7621 was not added until v7.1-rc5 and there have been more patches to bridge since then. See note 3 in Switch Chip Features Introduction
Backup your config, then upgrade the hEX S to 7.4 stable.
What is the reason for the lag (bonding1) on the hEX S? My guess is that is won’t help performance, and will probably reduce it. That is all done by the CPU if it is anything like on the Ubituiti ER-X which is also based on the MT7621.
I am not sure exactly what that question means. The MT7621 has two cores, with hyperthreading to make it look like 4 virtual cores. Was the question “why isn’t one CPU 100% saturated”? I don’t know for sure, but I would guess is has to do with the load and the way the linux kernel does SMP scheduling.
You evidently didn’t see the edits I made. Since the hEX S is routing, offloading to the switch will have little effect, since all inter-vlan routing is done by the CPU.
It would be interesting to see what the performance was like without bonding.
I don’t know if the bonding CPU usage shows up under Networking or not. The profiler documentation for v6 only states “networking - core packet processing”, and the v7 documentation has nothing but the statement that the classifications “are self-explanatory and do not require detailed explanation.” This seems to be a case where the limited documentation in V6 was better than the V7 lack of any documentation, other than the “name”.
I assume you understand the difference between routing and switching?
The hEX S running v7.4 can switch traffic with the ASIC. But that isn’t what is used when going between vlans; that requires routing. And Routing requires the CPU, and traversing the “internal trunk” link between the switch ASIC and the CPU. And that limits aggregate routing bandwidth.
Here’s a post from ycombinator by tbyehl - it had links to these images https://imgur.com/a/vtgUp02 which describe 1Gb aggregate limitation that applies to any “1-armed router” or “router on a stick” (e.g. a single full duplex 1Gbps link to a router).
this is how I understand the differences between routing and switching, will CRS305-1G-4S + IN under RouterOs control serve me traffic on the full range of the link, i.e. 1 GB / s or 10 GB / s?
To me it seems you have at least one configuration error. If you are going to specify the pvid on the bridge, then you should not create a vlan interface with the same vlan id (the MGMT interface). Instead you should use bridge1 where you use MGMT. @anav will say you should never specify a pvid for a bridge. I am not that strict, but you shouldn’t do both at the same time. I am not even sure what it actually does, when you do. ROS is very happy to allow you to enter invalid configuration without any warnings; it assumes you know what you want to do, and interprets what you enter in some undefined way.
Normally the “link” between the CPU’s base bridge interface and the Switch ASIC will be untagged, but you have told it to use tagged (in the /interface bridge vlan stanza).
And if performance is your goal, I would at least try not using bond (LAG) between the hEX S and the CRS305. I don’t have the ability to test with the equipment I have, but my guess is that it will be slower than a single link (and force the involvement of the CPU) even within the same vlan.
I have highlighted what I think are incompatible parts of your config. Perhaps @sindy or @tdw will chime in, as they know much more about the ROS bridge than I do.