I plan to buy router for a firewall and ipsec tasks.
Layout: 1 SFP from ISP, one trunk from LAN. 1 VLAN should go through ipsec, another to default route.
I read hEX hardware specs and looks like it has absolutely no hardware acceleration for VLANs, but on the other hand, it has CPU galore (2 cores, 4 threads) and AES hardware acceleration.

1. Is VLANs works at all and reliable ? Old posts on the forum draws unclear picture: there were reports that some users got 'not implemented' errors when tried to configure VLANs on hEX device and recommendation to grab atheros devices with VLAN table capability.
2. Can I expect at least 100 Mbps for each of two VLANs at the same time ?

It was never implemented. I am using the hEX S with VLAN on the PPPoE with a software VLAN.

The SFP is a nice feature but the XOR should be made with the first ether port instead on one of the two lanes to the CPU. I went back to complete using ethernet cables after using fiber.

Traffic goes through the CPU so a software VLAN is the only eay.

Then I love my two hEX S working in series, to increase encrypting power for my VPN.

I can enable switching...but it does not stick so assume it is not there.

So, VLANs work, but only on CPU ? Is this a significant impact ? I thought, hEX S has enough CPU power.
I have fiber from ISP and would like to avoid another active device. I saw a scheme, according to it, SPF slot will use entire 1Gbps lane, right ? This is not a disaster, as I have another one exclusive for my trunk port (I'll connect all copper stuff to CRS112 switch, hEX S just to bring everything to Internet and forward ports)

If you have a media converter like I then it will not make a difference. It is passive so transparant and FTC is the media converter Mikrotik offfers.

https://mikrotik.com/product/RBFTC11

Vlan is only 4 bytes added to the PPPoE and you won't notice it.

When you can spent more money then have a look at the 4011 which much more powerfull.

Don't take it as definitive answer, but it may not be the best choice.

I got hEX S last week as my new home router. It's nice little device. And there's really not many devices that have the options I want (SFP, IPSec acceleration, USB), only this one, RB3011 and then it's all overkill for home CCRs. The idea was to have public vlan (untagged at sfp1 and ether1, tagged at ether2-5), and other three vlans (for start all tagged at ether2-5, with possible future change to dedicate some untagged ports to some vlans). I tried the new bridge vlan filtering and it was nice, I really like the way how this configuration is done.

Problem is, routing between public vlan and another vlan went barely over 200Mbit/s. Removing public vlan and moving the config to single interface (either sfp1 or ether1) got me over 400Mbit/s, which is better, but still not great. I don't remember exactly (I got a little lost in all the configs I tried), but I think that without vlans it was close to full gigabit, so the bridge vlan filtering seems to be real performance killer here. Additionally, when vlan is involved, it seems that fasttrack doesn't work either (I don't normally use it at all, it was an attempt to speed things up).

I have yet to try if something can be done with the switch menu, aka the old unintuitive way (at least for me), but I'm not hopeful, half of the options are refused with "not supported". All in all, I'm sure it will be good enough for me in the end, but I have to admit that I'm a little bit disappointed, I thought that it would be more performant. Maybe there's still a chance that I did some stupid mistake, but I don't see it, I kept everything very simple.

Thanks for sharing your experience! I definitely have the answers on both of my question. 200mbps is enough now and later I can buy bigger Mikrotik.
However, I'm interested what options are 'not supported'?
As I have 1 SFP and 1 copper wire, I have no need in bridge at all, just for my trunk and leave switching to CRS112

This way router is routing and switch is switching. Is this scheme supported? It should be very-very basic.

I assume that simple vlans like this will have no problem going full speed. I'll test it later.

As for the switch options, I can add entries under VLAN, but I'm not sure if that does anything. Can't add anything under Rules, "not supported for this switch". Changes under Port return "vlan header mode not supported".

If you check the switch chip features table, it is obvious that VLAN features are not supported under ROS on MT7621. I don't know the reason for this, but for RTL8367, which otherwise supports VLANs, the urban legend goes that MT sacrified VLANs on switch chip for ability to use ports individually (as opposed to group of switched ports). They were able to do it without sacrifying VLAN functionality on Qualcomm switch chips because Qualcomm has a proprietary extension which indicates ingress or egress port.

I read that too. And if it's true, I think it would also make sense to optionally sacrifice individual ports and have some vlan-only mode, where user would configure vlans on switch chip (preferably transparently using bridge vlan filtering) and access individual vlans from there. Even individual ports could be used this way, you'd simply add each as different untagged vlan. I hope I'm not missing something. I'm also not holding my breath for it.

I wouldn't hold my breath either. After all, hEX S is considered to be a router, not a switch ... using ports individually is a paramount on routers ...

I know, but it always breaks my heart to see capable hardware limited by software. According to some datasheets I found online, the MT7621 switch should be pretty clever, it should support VLANs, RSTP, MSTP, rules and everything. And if RouterOS (mis)uses VLANs to give impression of individual ports, user could do the same manually, with added flexibility as bonus.

I feel the same way Sob about my RB450Gx4, it certainly has the oopmh to do better and naively thought MT would firmware upgrade the capability of the router wrt switch capabilities.

Well, you two at least know that MT crippled your devices. I don't have such consolation, my RBD52 is simply buggy ...

But wait, RB450Gx4 has AR8327 (or equivalent), it should be possible to configure it with VLAN stuff in /interface ethernet switch?

So, you approve the idea to use CRS112 switch with hEX S like on this scheme https://wiki.mikrotik.com/images/9/9a/Image12005.gif ?
Who provide DHCP service and inter - VLAN communication filtering here ? "router" ?

CRS + hEX should be fine. All routing should be done by hEX, CRS is an L2 switch more or less ...

DHCP could be done by either, but I'd use CRS only for switching, nothing more ...

I'm an optimist (sometimes), I think that they just didn't have enough time to give it all the right finishing touches. It can still happen. Like IPSec acceleration for RB3011, who really believed that it would ever arrive? And see, just few years later and it's there. Same way they could finish automatic HW offload for bridge VLAN filtering on all devices where possible.

....Same way they could finish automatic HW offload for bridge VLAN filtering on all devices where possible.

I'll keep my fingers crossed.

Good news, it's actually better than I initially thought. My mistake was testing with only one tcp connection. Well, I don't like "mistake", because I don't see anything wrong with wanting high throughput tcp connection, singular. Anyway, here are some numbers (<number of tcp connections> = <speed in Mbit/s> / <CPU usage>):

1 = 550 / 26; 2 = 870 / 52; 3 = 960 / 63 (routing between ether4 and ether5)
1 = 600 / 32; 2 = 880 / 58; 3 = 970 / 62 (routing between ether4 and simple vlan on ether5)
1 = 490 / 39; 2 = 680 / 56; 3 = 930 / 85 (routing between ether4 and vlan on bridge containing ether5 with bridge vlan filtering)
1 = 330 / 28; 2 = 690 / 61; 3 = 850 / 84 (routing between vlan1 on ether4 and vlan2 on ether5, all configured using bridge with bridge vlan filtering)

The numbers are very rough and reproducibility is worse than I'd think, even though router is not doing anything else and both testing computers were barely doing anything too. But some things are visible. First, simple vlan on interface makes no difference (above are slightly different numbers, but as I wrote, they are very rough, it's not any longer stable average). Once bridge vlan filtering is involved, even on one interface, there's visible drop in throughput and CPU usage goes up at the same time. Have it on both interfaces and it's even worse.

What I find interesting is that with bridge vlan filtering it seem quite unpredictable. I used iperf with long time and -P x to set how many connections should be used. I expected more or less constant speed once it started, but it often jumps in the range of about 100Mbit. Even more interesting, sometimes it's like it gets stuck. I start the test once with three connections and it's flowing happily at 900Mbit and even doesn't jump much. Then I do the same again, without changing anything, it starts at 600Mbit and stays there, doesn't go up.

So I guess I'll be happy camper in the end, even without any compromises. I may try to test some bridging later.

Well, you two at least know that MT crippled your devices. I don't have such consolation, my RBD52 is simply buggy ...

But wait, RB450Gx4 has AR8327 (or equivalent), it should be possible to configure it with VLAN stuff in /interface ethernet switch?

You are hired for job of torturer. I am fat dumb and happy with my software vlan configuration. What is it exactly are you proposing here?

I am having a PPPoE (MTU 1500) with VLAN (software) not in bridge. Speedtest for 524 Mbit/s is good and before ISP throttling catches I have over 900 Mbit/s up-stream. It drops too almost 700Mbit/s being throttled. This traffic is fasttracked otherwise it would drop below 200Mbit/s.

It goes through a second hEX S through a switch to my computer running the speedtest.

I have in my RAW table untrack rules to have local traffic that get lost there to have not a huge impact on the wirespeed. It is not predictable when it happens so that untrack line is permanent.

Well, you two at least know that MT crippled your devices. I don't have such consolation, my RBD52 is simply buggy ...

But wait, RB450Gx4 has AR8327 (or equivalent), it should be possible to configure it with VLAN stuff in /interface ethernet switch?

You are hired for job of torturer. I am fat dumb and happy with my software vlan configuration. What is it exactly are you proposing here?

My point is that @Sob can not make his hEX S to switch VLAN-tagged traffic in hardware no matter what he does even though its switch chip is capable of doing it. You, on the other hand, could do it if you wanted to, but you don't want to and have that clearly proclaimed a few times so far.

Okay I am game. What do I lose by going the vlan switch route although I cannot find evidence of what you speak in the charts provided by MT.
What are the changes I would have to consider to my config??

Generally speaking, hardware processing should be better than doing the same in software. So it could be faster by few microseconds, and use few milliwatts less energy. It may not sounds as much, but think big, have few millions of routers and you'll save small powerplant and hours of waiting.

I'm not sure how much you can combine current direct switch config with bridge vlan filtering. It would be best if MikroTik completely replaced the former by improving the latter, so that you could use only that and it would automatically use all hardware offloading supported by every device.