I’m experiencing throughput performance issues on my router RB750Gr3 (hEX). I’m not able to get download throughput above ~ 14-15 MB/sec (~ 140 Mbps).
I see that one CPU is pegged at 100% CPU/IRQ and suspect that this is the bottleneck.
I have tried offloading VLANs and bridges on the LAN side but my provider forces me to use VLANs on the WAN side due to their setup.
Current setup:
WAN: VLAN 4 & 6 for IPTV and internet, PPPoE interface on VLAN 6 for internet access.
LAN: Bridge on remaining ethernet ports
Ofcourse there is a (fairly basic) firewall in between.
Any ideas to optimize performance or should I just consider a more powerful router? In case of the latter, what is a proper one for such a configuration?
Hi there I was shocked to see that hex numbers were modified downwards by MT sometime in the past.
After I bought mine (subsequently moved on so not a personal concern).
One should expect realistically around 700Mbps with light rules/load and 380Mbps with heavy rules/load.
HAPAC2 is significantly better for the same price.
Do you need to route the IPTV or it would be sufficient to dedicate LAN ports as access ones for the IPTV VLAN? Not possible on hEX anyway, but using a router with a switch chip better handled by RouterOS, like hAP ac2, you may let the IPTV traffic bypass the CPU completely. But if the IPTV gear needs to access internet as well, it may be more complicated or even impossible - still worth trying, though. Of course the PPPoE client creates an extra load.
Routed iptv is mandatory otherwise the apps (eg. Netflix) fail.
Contract speed is 200 Mbps and that is achieved nicely using the router provided by the provider.
I’ll check the hAP devices to see what is different in the hardware although I’d prefer some without wifi.
One thing I yet need to try out is putting a switch in front of the router to do the VLAN splitting and remove the bridge on the LAN side, maybe that gives just enough offload to reach the desired speed. I have spare ports on one of my Netgear switches that can be used.
You can always disable the WiFi interface. hAP ac2 has no outside antennas so that’s not an issue.
Other than that, it might be possible to assign a local subnet to the IPTV VLAN, and use bridge filter rules or switch chip rules to prevent the traffic from that local subnet from leaking via the IPTV WAN link. Not sure if your Netgear supports traffic filtering, but if so, the same thing could be done that way. I.e. the traffic to internet would be routed as usual, but the multicast traffic would be switched.
The Netgear switch will only be used to split VLAN-ed WAN traffic into an untagged IPTV WAN and internet WAN, more logic is not possible in there. So this will offload only the VLAN processing.
On the IPTV port there will be a dhcp client and igmp router, on the internet port there must be a PPPoE interface because the provider mandates it.
What I do not understand is why my download currently is lower than the upload. It seems that when downloading the router can not use the available CPU cores efficiently. I guess it is impossible to figure out what is using the CPU (although that would be helpful to determine how to optimize).
The idea was that the multicast routing would not be necessary if the multicast traffic could be forwarded at L2; to do that, you have to prevent unicast traffic and DHCP requests from leaking between the LAN area and the WAN area of the IPTV VLAN. But there’s little or no advantage of bridging, especially with filtering, as compared to multicast routing, if either has to be done in CPU. So this setup is worth trying at hAP ac2 that can handle both VLANs and L2 filtering on the switch chip, not on the hEX.
The /tool profile only shows CPU usage per type of activity, so download cannot be told from upload, bud bridging can normally be told from routing; not sure about pppoe, nowhere to look for me and the activities only pop up if they occupy some minimum amount of CPU. Do you use any QoS setup (queues, mangle rules)? If not, do you use the action=fasttrack-connection rule in firewall?
Using Bridge IGMP Snooping will disable bridge hardware offloading on a lot of devices: https://help.mikrotik.com/docs/display/ROS/Bridge#Bridge-BridgeHardwareOffloading
Regarding hEX, maybe read this too: http://forum.mikrotik.com/t/hex-block-diagram/114819/1
Short version, try using port 2 or 4 for LAN instead of 5 or 3.
LE: meh, you’re using vlans so bridge hardware offloading is disabled anyway on RouterOS 6.
LE2: obviously i’ve misread the whole config, points above still valid.
LE3: I see mtu/mru=1500 set on the pppoe interface but no mtu change for the vlan interface & ethernet interface that it sits on?
What kind of device are you using for playing IPTV? If it’s device provided by ISP, it often expects/accepts tagged VLAN for multicasts (same VID as on WAN, i.e. VID 4) and uses untagged for general internet access. In this case one doesn’t need routed multicast …
That is fine as Mikrotik splits layer2 and layer3 MTUs (defaults 1596 & 1500 for an ethernet interface on a 750Gr3), and the ethernet & VLAN interfaces are merely transporting the layer2 PPPoE frames.
My provider uses routed IPTV, it explicitely specifies so. I theory bridging IPTV could work (loosing some features) but it is not supported. All provider traffic is tagged on the WAN side but untagged in the LAN. However, the IPTV is not my biggest concern as most of the time this isn’t used and hardly imposes a load when unused (only low rate TV guide updates).
Anyway, this weekend I hope to find some time to offload VLAN and remove the bridge I still unnecessary have in the config, as described before. Hopefully this helps enough to achieve the 200 Mbps mark. Based on the profiling the networking is an issue so anxious to find out what this brings.
Also as mentioned above, change to another port I will try although I don’t expect to much from this. The speeds are well below the interface rate to the CPU so there should be no bottleneck there yet. I may put load on another IRQ and/or CPU maybe, that could be helpful be the proof of the pudding is in the eating.
Apparently the router must have ran into some peculiar state because after a reboot the problem disappeared and CPU usage was back to levels seen before.