For instance, they're good as VPN gateways in cases where the connection speed is sufficiently bottle-necked upstream that you don't need enough CPU grunt for gigabit-class forwarding. They're better used as smart switches in the core of a SOHO LAN, using their routing capabilities to handle only a small proportion of the traffic. If your router is sufficiently fast, it often isn't worth playing fast-track type games, because it complicates the configuration, makes it harder to reason about, and prevents you from using things like queues to shape traffic beyond the initial connection packet exchange.Ĭontrast devices like the CRS3xx series, which have relatively weak CPUs, making them unsuited to being pressed into service as a proper router. In that sort of situation, you need to disable hardware acceleration anyway, at least until the traffic's classified in a way that lets you fast-track the connection or similar. You might have firewall rules and other configured features that require the traffic to cross the CPU. Now, if you're using a router-class device in the mode it was designed to support, hardware acceleration might not matter. RouterOS chooses which one automatically by default, but you can force it to choose the right one with the ' hw=yes' flag when setting up the bridge and setting the others to ' hw=no'. You can have multiple bridges configured, but only one will be hardware-accelerated. Implicit in this is that every other series of RouterOS based devices MikroTik currently sell support only the one hardware bridge per switch chip. The CRS1xx/2xx series switches support multiple hardware offloaded bridges per switch chip. This is normally good advice, since as the Bridging & Switching documentation page correctly points out: It's common wisdom in RouterOS that it's best to have only one bridge per router if you need/want hardware acceleration.

Switch os mikrotik