I have a HEX s with RouterOS 7.13.2 connected to ISP (a cisco router in a university, no access there) on Eth1 (WAN port).
Eth5 is bridged with Eth1 and assigned to a public IP accepted by the router to connect an IP phone on Eth5.
Eth1’s MAC address had to be changed to be accepted by the ISP.
These two ports behave like a “dumb” switch.
Eth 2,3 and 4 are bridged together and assigned a local IP with DHCP enabled for connected devices.
When PC is connected to Eth5, speedtest gives almost 1000/1000 with CPU at 1%.
When PC is connected to Eth2,3 or 4, speedtest gives 450/450 with CPU at 80-90%
If -in addition- IP phone is connected to Eth5, speedtest gives 350/90 with CPU at 90% in downloading (350Mbps) and 20% in uploading (90Mbps)
If PC and IP phone are on the same “switch” bridge (eg. Eth1, Eth5 and Eth4) then speeds are almost 1000/1000.
Is there something wrong in my configuration or did I reach the hardware’s limitations?
I attach my configuration, maybe something is wrong… config.txt (1.9 KB)
If you look at the specs [ TEST RESULTS } for the router, 512 byte sized packets at Mbps speed, with about 25 filter rules provides the most realistic view into what one should get for real world speeds it looks like
No rules - 1820 Mbps
25 queue rules - 735 Mbps
25 filter rules - 385.4 Mbps
Conclusion, a realistic speed with Default rules for most means you should reasonable expect to get somewhere between 385 450 Mbps.
I’d day your results are bang on, the 1K Mbps result you have makes no sense to me, more of a switch speed result than a through the WAN routing result.
Thank you for your answer!
You are right, the almost 1k/1k Mbps speed (1820Mbps) with no cpu usage applies when the eth ports are on bridge mode with protocol-mode=none, which makes the ports behave like a switch.
On the other hand, my firewall rules are almost none, I even tried it with these disabled with no difference. Shouldn’t the ports work in fast path mode? In this case the speed should be 1820 as well.
And anyway, as you say, (even without fast path) I should see speeds above 385. Isn’t 350/90 too low?
Nope, that would be true if routing was HW offloaded to switch chip, which isn’t. Packets still oass CPU, what fasttrack (and consequently fastpath) does is that packets bypass most of firewall processing (but not routing).
Regarding official test results: only MT knows how exactly those tests are done (AFAIK testing procedure description was never published) so it’s completely unclear which figure might represent which real-life scenario. And collective experience of forum n+members show that the figure @anav mentioned is the one which resembles most real life scenarios (and even that figure has to be used with a pinch of salt, in certain scenarios actual performance might be better by 100%, in some it might be lower by 50%). If you think that you should be able to reach advertised speeds, you have to bring that to MT directly (support@mikrotik.com, mikrotik.com/support ), this is an user forum which MT seems to neglect lately.
Indeed only one bridge will be offloaded to hardware (switch chip) and I don’t know how automatic selection determines which one to offload.
However, CPU in hEX S is capable of wirespeed bridging (it will considerably increase CPU load), but realistically it can’t route and firewall wirespeed. So @OP seeing slow throughput is almost certainly due to limited routing speed.
Yes, since ROS v7.1 there is a way which would allow @OP to have wirespeed switching both between ether1-ether5 and between group ether2-3-4 while keeping these two separated on L2. That’s possible by using single bridge and two VLANs (internally to hEX S) to “partition” device into two separate parts. Such setup can be fully offloaded to switch chip, freeing CPU resources for other tasks (routing and firewalling).
Is there a way to select which of the two bridges will be offloaded to hardware? Since one bridge only has an IP phone and the WAN port, there is not much traffic there I think…
Can one of these two VLANs be between WAN and one LAN port and behave like a switch? In my case, the phone must be “seen” by the ISP “directly” to assign IP or whatever it does… (the hEX S should be invisible).
In the attached image there is the current setup and the desired setup.
There’s a property of each bridge port called hw. I guess that if all ports on some bridge would have hw=no, then that bridge then wouldn’t be picked for HW offload.
If one executes (in CLI) command /interface/bridge/port/print, only ports of HW-offloaded bridge will have ‘H’ flag shown in flags column (between index number and interface name).
Yes. You could set ether1 (ISP-facing port) with PVID X, ether5 with same PVID X and this would establish ethernet connectivity between IP phone and ISP.
IF the phone doesn’t use VLANs (which they often do). If it does, then you have to find out the VLAN ID which your ISP uses for VoIP and then configure both mentioned ports for hybrid use (tagged VoIP VLAN and untagged with VID X for internet).
Then you could set the rest of ports with PVID Y.
And then complete config with bridge port, bridge interface and vlan interface config (to unwind your brain off these bridge personalities check bridge mysteries explained … it actually helps to understand tutorial linked in next paragraph).
If you’ll look into VLANs, then study this excelent tutorial. None of examples directly apply to your use case, but you should get some insight.
It is probably easier starting with your worst case scenario (a single bridge + a WAN port) and finding what speed you can reach in that case. If that speed satisfies you, then you can also try the VLANs…
(I mean, without buying the external switch)
Yes, thank you, that is the second thing I 'll try. Firtsly, hw=no will be applied to the IP phone+WAN bridge and hope that hw=yes could be applied to the PCs bridge. Then check if I can speak on the phone while doing a bw test…
My suggestion was to start by resetting and using the quick set (without the phone). This is the best speed you can aim at. Then you can check other configurations and see how much bw you loose. My 2 cents.
I beg to differ, I originally bought the hex because the specs for 25 filter rules was easily double instead of 384 or whatever it was more like 700ish.
When did it change, when v7 came out.
In case of hEX S (having MT7621A SoC) it’s actually beneficial to use v7 in certain use cases since it enables L2 HW offload. And if @OP is going to go with VLAN-enabled bridge, then this is one of cases where running v7 on hEX S is almost necessity.
[quote=wfburton post_id=1050518 time=1705878416 user_id=215408]
What brand/model voip phone do you have?
I’m assuming it only has one ethernet port.
Would it be possible to exchange the ip phone with one that has two ethernet ports?
[/quote]
It is a cisco cp-7821. It has two ports. One Ethernet port to connect to ISP and one more to provide internet to local network. Unfortunately, it is only 100/100 Mbps.
After applying the hw=no to the IP phone+WAN bridge (Eth1,5), hw=yes was automatically applied to the PCs bridge (Eth2,3,4) but dl/ul speeds remained low.
So, I reset as you said, selected automatic configuration for router, entered correct mac and IP/subnet/gw to the Eth1 port and I have full speed (950/950) to internet as well as between PCs connected on ports 2,3,4.
The speed issue seems that was indeed caused by the two bridges.
While the IP phone was automatically registered to the Cisco Router (ISP) and got its number, during calls I could not hear peer’s sound on the IP phone.
Supposing this was a firewall issue, I disabled all blocking rules with no result.
If you’re using vlan interface, anchored off bridge1, then bridge1 has to be tagged for that VLAN. So I suggest you to set pvid on bridge back to 1 (which is default).
Bridge port has to be untagged both ingress (pvid setting in bridge/port) and egress (tagged property in bridge/vlan). Esentially ether1 is (with the minor glitch above) configured as trunk (all tagged) port. If client (machine, connected to ether1) isn’t configured for trunk operation, then traffic can not pass bi-directionally right now.
And an omission, which prevent bridge from taking part in communication of vlans 15 and 234: bridge port has to be tagged member of said VLANs:
/interface/bridge/vlan
# remove ether1 from the list if ether1 is not meant to be trunk port ...
# or remove it from some of VLANs if ether1 is meant to be hybrid (some tagged, one untagged).
set [ find bridge=bridge1 vlan-ids=15 ] tagged=bridge,ether1
set [ find bridge=bridge1 vlan-ids=234 ] tagged=bridge,ether1
