I need two switches that support VLANs, connected with 10Gb optical trunk. Currently I'm deciding between CRS312-4C+8XG-RM and CRS309-1G-8S+IN from Mikrotik, or TL-SX3008F from TPLink.

For Mikrotik CRS3xx switches I'm not certain IF and WHERE their difference in "bridging" speed as compared to "switching" speed would be applicable to my use scenario (where I only need VLANs, no need for advanced filtering rules etc). For example:
1) if PC connected to switch#1 is communicating to PC connected to switch#2, and both PCs are in same VLAN ( and I do not need filtering etc), will both switches consider that communication as "switching"?
2) is adding VLAN tags to ethernet packets sent by PCs considered basic "sweitching" feature, and does not require CPU and/or "bridging"?
3) are ports in Mikrotik CRS3xx switches by default set to "switching"? Ie, if I just unpack two of them and connect in above scenarion, will 2 PCs communicate at "switching" speeds?
4) what useful features require bridging?
5) is conversion from switching to bridging visible on Mikrotik OS ( requires user setup/configuration) or is it silently done if/when some feature that need bridging is turned on ?

Reason for these questions is that I need 10Gb connection between clients on one switch and servers on other switch, for different VLANs. And I noticed that both CRS312 and CRS309 offer same "switching" speed (and backplane speed to match 10Gbe per each port), but CRS309 is much faster for "bridging" speed (which is still far under 10Gbe). So main question is if I can avoid bridging completely while still having VLANs.

Tnx,

1 - yes, assuming hardware offload has not been disabled on the interfaces.
2 - yes, when using the VLAN-aware bridge setup merely adding/removing tags between access and trunk ports is still performed at wire speed.
3 - yes.
4 - bridge filtering, if you cannot achieve what is necessary with switch rules / ACLs.
5 - L2 hardware offloading being operational is indicated by the H flag on bridge ports, it may be disabled by choice or if an incompatible bridge feature is being utilised.

See https://help.mikrotik.com/docs/display/ ... p+features and https://help.mikrotik.com/docs/display/ ... Offloading

Mikrotik have also been adding L3 hardware offloading to CRS3xx, CRS5xx and CCR2xxx models, the functionality available depends on the switch chip in the particular model, see https://help.mikrotik.com/docs/display/ ... iceSupport

CRS3xx devices use the Bridge VLAN Filtering model. I recommend these RouterOS documentation pages:

• Bridging and Switching - https://help.mikrotik.com/docs/display/ ... +Switching
  • Bridge VLAN Filtering - https://help.mikrotik.com/docs/display/ ... NFiltering
• CRS3xx, CRS5xx, CCR2116, CCR2216 switch chip features - https://help.mikrotik.com/docs/display/ ... p+features
• L3 Hardware Offloading - https://help.mikrotik.com/docs/display/ ... Offloading
• Layer2 misconfiguration - https://help.mikrotik.com/docs/display/ ... figuration
• Packet Flow in RouterOS - https://help.mikrotik.com/docs/display/ ... n+RouterOS

Question answers:

1. Yes, switching.
2. Yes, it's a switching function managed using the RouterOS bridge.
3. Yes, it's a switch and does so by default at switch chip wire speeds.
4. CRS3xx devices program the switch chip by setting values for a single RouterOS bridge with hardware offload enabled.
5. CRS3xx "bridging" and "switching" are not distinct. If done correctly the functions are merged and executing in hardware at wire speed.

The definition of a switch is a hardware device that bridges all it's ports by default.

The integrated switch chips can't execute all possible bridge features. Such features fall to CPU which is where the "bridging" performance number applies. Compare the CPU configuration between the respective devices.

CRS3xx "bridging" and "switching" are not distinct.

Yes they are, see post by @tdw above (so it can be done on purpose, but then only masochists would gladly do it). And for that reason, both switching and bridging test results are shown in product page.

Since the RouterOS bridge is the management device for the underlying switch chip, that blurs a sharp distinction IMO.

You're right, for inexperienced admins the difference is sometimes hard to spot. But that still doesn't make these two "not distinct" ...

But that still doesn't make these two "not distinct" ...

If the line is drawn at hardware offload or not then I agree.
Are these idiomatic distinctions helpful to the OP?

Are these idiomatic distinctions helpful to the OP?

There are real differences (not just idiomatic distinctions) and @OP did open a thread to ask about it.

1 - yes, assuming hardware offload has not been disabled on the interfaces.
2 - yes, when using the VLAN-aware bridge setup merely adding/removing tags between access and trunk ports is still performed at wire speed.
3 - yes.
4 - bridge filtering, if you cannot achieve what is necessary with switch rules / ACLs.
5 - L2 hardware offloading being operational is indicated by the H flag on bridge ports, it may be disabled by choice or if an incompatible bridge feature is being utilised.

See https://help.mikrotik.com/docs/display/ ... p+features and https://help.mikrotik.com/docs/display/ ... Offloading

Mikrotik have also been adding L3 hardware offloading to CRS3xx, CRS5xx and CCR2xxx models, the functionality available depends on the switch chip in the particular model, see https://help.mikrotik.com/docs/display/ ... iceSupport

Thanks, this answers my question.
My main conclusion is that, if VLAN features (802.1q) are fully offloaded, I should not care if CRS312 has slower CPU/bridging than CRS309.

My main conclusion is that, if VLAN features (802.1q) are fully offloaded, I should not care if CRS312 has slower CPU/bridging than CRS309.

Generally true if VLAN 802.1Q is the only bridge feature in play, it should be hardware offloaded.
Perform due diligence on possible future bridge features falling outside hardware offload envelope.
This is a user forum; writers are sincere is generally true; writers are always correct is not universal.

Related question ( in case it makes CPU speed relevant again for this switch selection): Is it possible to use CRS3xx as regular router?

For internet access I currently have two ISP providers connected to two ports of Mikrotik hAP ac² router which is doing load balancing so that PCs from LAN can have download speeds of both IPSs combined (for sites where I allowed load balancing, like Steam etc ). That worked well when my ISP links were 600Mbs + 400Mbs ... PCs were able to download with near 1Gbs speeds. That hAP ac² was also fast enough to allow 600Mbs IPSEC VPN from outside while IPSEC was multithreaded, but its now questionable due to 'feature' where Mikrotik use single core for IPSEC.

Since now I have 1Gbs from both of those ISPs, my plan was to get new Mikrotik router similar to hAP ac² but with SPF+ port to connect that router to one of above 10G switches, so that PCs connected to 10Gb port of switch can have 2Gbs internet download speed. Also that new Mikrotik would probably need better CPU than hAP ac² to support 1Gbs IPSEC on single core.

But is there an option to use directly CRS3xxx as regular router that can do both switching and "high performance" routing? Specifically:
1) can CRS3xx do anything that RouterOS allow in 'normal' Mikrotiks like hAP ac² ? [ I assume yes ]
2) Is their processor faster than hAP ac², for eg 2Gbs IPSEC ? [ Mikrotik lists IPSEC speeds for ac2, but not for CRS3xx ]
3) since CRS309 has better CPU related bridging speeds than CRS312, I assumed it has faster CPU - but is that correct?
4) I noticed that CRS309 has 98DX8208 listed both as CPU and switch chip - is that two of those or came chip does both? If same, will switching slow down IPSEC and vice versa?
5) if CRS3xx are not good match for 2Gbs performance of above internet+IPSEC scenario, what Mikrotik router (or CPU) would be advisable?

You can - however the CRS devices were originally designed to support wire-speed L2 switching and also be able to support L3 functionality, but much limited by their CPU performance. As RouterOS v7 has developed some L3 hardware offload has been added by utilising previously unused capabilities of the switch chip, but this does not accelerate all L3 functionality.

1 - yes
2 - no
3 - from the specifications CRS309: dual-core 800 MHz CPU, 512 MB RAM; CRS312-4C+8XG-RM: single-core 650MHz MIPSBE CPU, 64MB RAM
4 - the CPU and switch are part of the same SoC https://i.mt.lv/cdn/product_files/CRS30 ... 220900.png
5 - not sure how you manged 600Mbps IPsec on a hAP ac2, the test results show just over 400. Beyond the hAP ac2 in terms of performance the RB4011, RB5009 or even CCR2004.

5 - not sure how you manged 600Mbps IPsec on a hAP ac2, the test results show just over 400. Beyond the hAP ac2 in terms of performance the RB4011, RB5009 or even CCR2004.

Tnx, RB5009 is something I was considering for ac2 replacement, since it lists IPSEC speed as 1.3Gbs, but I was hoping that maybe CRS could do both router and switch job ... but I see now that it woul dnot be fast enough for IPSEC.

Related to "how you manged 600Mbps IPsec on a hAP ac2", it was what I measured few years ago when I got 600Mbs from one of those two ISPs. But when I measured few months ago I was surprised to see that it only hit 200Mbs or so. I posted separate issue/question here regarding that, but I found by searching around that Mikrotik seems to have been supporting multithreaded IPSEC back at that time when I measured, but have since limited IPSEC to only single thread ( CPU core), and thus performance dropped significantly - on site they may list 400Mbs, but I mostly get 200Mbs - probably those 400Mbs are for multiple connections over single tunnel, and they limit one connection per one thread.

Supposedly reason why Mikrotik downgraded/limited IPSEC is that in some rare cases for some people it was making problems on eg Windows clients due to reordering of IPSEC packets ( due to multiple threads ). Personally I mostly use Windows clients and I never noticed that problem, but it seems Mikrotik considered it a problem and decided to "solve" it quite heavy handedly - by limiting IPSEC to single core for single connection. Whats worse, they did not do any smart scheduling of threads over cores, so networking task (for IPSEC en/decryption) is often put on same core as firewall task (filtering packets etc) - and that core hit 100% ( 60% for networking and 40% for firewall ) with barely 200Mbs of IPSEC over 600Mbs or 1Gbs links. Sometimes, when random luck is on my side, Mikrotik schedule firewall and network tasks on different cores, and I get around 350Mbs IPSEC for single connection - but that is still far from 600Mbs that it was able to do before (or much more, my link was 600Mbs back then)