I’m reading this forum for a long time but now is a time to make an account since I’m stuck with a problem and there is no solution (or at least I did not find it)
I have a hAP Lite with newest RouterOS.
The eth1 has a tagged VLAN50 and port 4 is untagged VLAN50. There is an extra bridge to connect those 2 interfaces (eth1-vlan50 and ether4)
The VLAN is created for an IPTV (multicast).
My question is how can I priority the VLAN50 in Mikrotik, so the internet traffic would not affect IPTV since it’s very sensitive. When someone is downloading the TV image gets shuttered.
as you say you have configured “another” bridge for the IPTV VLAN, it is likely that this particular bridge doesn’t enjoy the “hardware support” which means that the frames between the two Ethernet ports have to pass through CPU instead of being switched by the switch chip, which theoretically means that if your CPU load is high, some frames may get seriously delayed or lost.
prioritization consists in sorting packets into different queues on output, so that the more important ones could overtake the less important ones when choosing the next one to be sent out over a limited bandwidth link. But as you are sending the IPTV packets to your STB via a dedicated Ethernet port, the output bandwidth should not be an issue (because it is not shared with any other traffic). So either the CPU load is the reason, and in such case, using a common bridge for all VLANs (which would mean that the switch chip would take care of all L2 processing) should be enough, or there is something wrong with prioritization of the traffic already at your ISP, and in such case, your only possibility is to throttle the speed of the download by limiting the output bandwidth of the other-than-IPTV traffic to the value of your total downlink bandwidth minus the bandwidth required for the IPTV traffic.
Can you post the output of “/export hide-sensitive” and the output of “/tool profile” while the issue you describe exists (heavy download causing the IPTV picture to deteriorate)?
Would probably be best to make Ether1 part of the switch group with all other ports (default the untagged internet to something like vlan 40 and make that your new WAN interface) and let the switch do the work of passing the multicast at wire speed.
Then the router just has to work on the routing for your internet and not the IPTV multicast.
Well, I wasn’t clear enough, suggesting to move everything into a single (and thus hardware-assisted) “bridge” in my second point instead of the first one.
So to be more specific for @Kazek - yes, VLAN1 in the “one-for-everything” bridge will stay for the LAN, a new interface of type “VLAN” with VLAN X (e.g., 40) will be created to become the new WAN interface, and you move to it the WAN IP address from ether1. Doing so will make ether1 free for making it a member of the “one-for-everything” bridge and permitting only VLAN 40 (untagged, i.e. pvid=40) and VLAN 50 on it. Ports ether2 and ether3 will be members of that switch on which only VLAN 1 will be permitted untagged (pvid=1) as they are now, port ether4 will be a member with only VLAN50 permitted untagged (pvid=50).
Although I do understand the idea of your solution I’m not quite sure how to achieve it. To help I will show you my config I’m using but with this solution all the IPTV traffic goes through CPU instead of a switch, right?
/interface vlan add interface=ether1 name=eth1-vlan50 vlan-id=50
/interface bridge add name=bridge-vlan50
/interface bridge port add bridge=bridge-vlan50 interface=eth1-vlan50
/interface bridge set bridge-vlan50 protocol-mode=none
/interface bridge port set bridge=bridge-vlan50 [find interface="ether4"]
Yes. If your RouterOS version is 6.41 or higher as I suppose from what you wrote initially, place here the complete output of “/interface export hide-sensitive”, I’ll send you back a modified version. (the hide-sensitive prevents your wireless passwords from being exported).
About the same can be achieved in older ROS versions where settings for switch and bridge are completely separated, by setting handling of VLAN 50 on the switch, but I never needed to do that on these older versions so it would be only a theoretic solution from my side.
Are you sure this is caused by the router? How is the VLAN50 to ISP connection? Is ether1 directly connected to the ISP? Is VLAN50 prioritized by the ISP?
What is the total datarate of the connection and the rate used by TV? Is the CPU load of the router at or near 100% when you download?
No, but I want to start with setting it up correctly, so the traffic is processed by switch not CPU.
How is the VLAN50 to ISP connection? Is ether1 directly connected to the ISP? Is VLAN50 prioritized by the ISP?
VLAN50 is connected to separate router and separate ISP (separate uplinks for each VLAN in the switch).
The switch has QoS with VLAN1 on 802.1p level 0 and VLAN50 on level 6
What is the total datarate of the connection and the rate used by TV? Is the CPU load of the router at or near 100% when you download?
IPTV ISP is 200/20mbps, SDTV is using 3-4mbps per stream, HDTV 8-9mbps per stream. It’s a multicast stream. The CPU gets to 50-60% on full load
Ok you can still configure the switch to do this VLAN instead of the bridge, in the old way.
(add the VLAN to the switch and configure port 4 with that VLAN and always-strip)
This performs better than the new “vlan aware bridge” which does not support hardware-accel, no idea why.
The reason I ask is because when the line is saturated by internet traffic and there is not the proper priority for the VLAN, there will still be problems.
So e.g. when your internet connection is faster than the ethernet link, this could be the case.
Buying such low-end equipment for situations like this does not help either…
Can you be more specific? Do you have in mind that the hardware acceleration is not supported on this particular Mikrotik model or in general?
My experience is such that the hardware support works for just one of the bridges created the new way, which seems quite logical to me so I never thought deeper about that. So creation of a single common bridge for everything which requires more than a single ethernet interface is normally enough to have the switch do everything it can do.
This is really a big pity, because before this new bridge was introduced the natural way was to configure
the VLANs in the switch config and it was hardware accelerated on almost all models.
(there are some problems with hybrid ports in that method)
Taking into account what @pe1chl has pointed out, here’s my response:
Assuming that you configure the router while connected to ether2, ether3 or wlan, and that you can interrupt the internet uplink and the IPTV transit for a while, you would do the following:
backup the existing configuration in order to be able to restore it if something doesn’t work as expected
check in the configuration of the upstream router that VLAN 40 is not permitted at the port to which your mikrotik’s ether1 is connected; if it is, choose a VLAN ID not permitted at that port for use instead of the 40 for the steps below
change the interface to which your static uplink IP address is attached from “ether1” to “vlan40”, or move the dhcp client from “ether1” to “vlan40” if you don’t use a static address
replace “ether1” by “vlan40” in “/interface list member” for list=WAN
check all your firewall rules (filter, NAT, mangle, raw) and if any of them checks for in-interface or out-interface “ether1”, replace that respectively by in-interface-list or out-interface-list “WAN”
remove the following items from the configuration:
inform us about the result (whether it works at all and whether it has removed the issue with the IPTV performance)
As you wouldn’t add the vlan filtering rules and wouldn’t switch on the vlan-filtering for the bridge, hardware acceleration should work (please put here the result of “/interface bridge port print”) and VLAN 50 should be only running through the switch.
Not completely true. Only if you set the switch bridge to use vlan-filtering=yes and try to use the bridge vlan menu to set up vlans.
That’s not the proper method for the smaller/non-CRS3xx switch chips.
You can still get hardware accelerated vlans by using the pre-6.41 way with only a couple changes. Only difference is to use a bridge to set up the swtich group instead of a master port and then, for any needed management/routing vlans,under /interface vlan use the bridge as the parent interface instead of the old master-port. You still use the switch menu to set up what vlans are allowed on what ports, default vlan-id, etc.
I know that the old method still works, but I expect that it is to be phased out.
At the moment the switch/bridge situation, that was already difficult for some people, has become completely unclear.
As it is now, when I configure all the VLAN stuff on the bridge (including tagged/untagged ports) but I just leave out the “vlan-filtering=yes”,
what will happen? Will it still process the VLANs and enable hw accell but is there some lack of filtering e.g. of unspecified VLANs?
That is not clear from the documentation, at least not to me.
And in fact I don’t understand why the old situation of having a configured switch chip with a couple of VLANs and some tagged/untagged
ports plus VLAN interfaces on the master-port (cpu port) to attach them to the router, cannot be translated into the new VLAN-aware bridge configuration
with all VLANs in a single bridge and the same VLAN interfaces on the bridge instead of the master-port, without losing the hardware
accelleration between the ports. I can understand that it is lost when you enable some advanced function like bridge firewall, IGMP
snooping, spanning tree etc on a chip that does not have the capability, but why not simple VLAN tagging/untagging??? All those chips
should support that in hardware…
This is why I hope that the current stage of integration of “bridge” and “switch” configuration into one is only an intermediate one - as even the simpler switch chips can be told to filter VLANs, I hope the vlan filtering will eventually also be made “hardware-assisted”. Similarly, the need to explicitly indicate that the bridge is a tagged member of itself in the vlan-filtering rules under “/interface bridge vlan” if you want to open the path to CPU (and thus wlan and vlan interfaces) will I hope disappear later on.
I agree! This one got me when I tried to convert my old multi-bridge + switch VLAN configuration into the new single-bridge.
It is shown in an example but it is easy to miss and it should not really be required to have this, it could be default or it could be auto-enabled when there is a VLAN interface attached to the bridge.
Only when I came back to this task on another day I found this mistake…
As I’ve found in the meantime, the incorporation of switch chip configuration into bridge configuration is not as tight as it seemed to be, plus the switch chip used in your machine (hAP lite) is an ar8227 which does not support hybrid ports (where one or more VLANs may be present tagged and a exactly one VLAN untagged). Luckily, it does support ingress tagging and egress untagging on an access port as well as internal forwarding of untagged packets.
So if you could make the internet come also tagged with VLAN ID 40 to ether1, it would be much easier to handle and it would be possible to have ether2 and ether3 (LAN ports) hardware accelerated; if you don’t mind having the LAN ports not hardware-switched together, it would make it a bit easier but there may still be problems. What is your standpoint on these two points?
(whether it works at all and whether it has removed the issue with the IPTV performance)