The CRS series is CPU-limited compared to a proper “router.” They’re better thought of as uncommonly smart and adroit L3 switches.
It’s common wisdom that the most predictive entry on the official test results table for CPU-mediated traffic is the one for 512-byte packets with 25 filter rules, which in this case shows 428 Mbit/sec. That matches up pretty well with my own iperf3 results.
Now, don’t get yourself confused on this point. An iperf3 test with the client and server running across the CRS328 gives near line-speed results. The previously-linked test has iperf3 running on the CRS328’s CPU inside a container, though, forcing all traffic through the CPU, not the switch chip.
The trick is, “router” type functions often require use of the CPU. If the switch chip can’t do a given thing itself, that traffic ends up shunted down through the Linux kernel running on the CPU to accomplish the goals you gave RouterOS through the configuration. Different switches in MT’s lineup have widely differing features, but they give you line-speed results only as long as you stay within those limitations.
You may be wondering why I’m telling you about this even though you are not (yet) complaining of limited speed. It’s because you’ve selected a device with a 10G SFP+ port and are using that port for the Internet uplink and calling it a “router” even though it isn’t grouped with the routers on MikroTik’s product pages. You aren’t even going to get a single gigabit through a CRS328 if you make it do anything substantial that can’t be offloaded to the hardware. As soon as you start loading the CRS328 with significant CPU-mediated traffic, it’ll become the bottleneck in your network, somewhere in the 400 megabit range.
It’s better to split the roles into router and switch so that the only traffic that hits the router’s CPU is traffic that is crossing the router from one side to the other. That keeps all LAN-only traffic on the CRS switches, ideally fully hardware-offloaded, including all this internal IPcam traffic you speak of.
All ethernet ports on the first router together with optical port that is administering connection to the second router are groupped into a bridge.
That’s good. Either you have read and understood the warning in the docs, here, or you have stumbled into a correct configuration. I wouldn’t bring it up if it wasn’t for what you say next, though…
I can dedicate one more port in each router and connect via dedicated secondary ethernet cable connecting the camera “islands” together.
That sounds like you’d end up with 2+ bridges, which as I’ve pointed out will cause one set of ports to be handled by the CPU, not the switch chip. This is bad enough by itself, but this atop your current use of a lowly CRS328 as a fiber Internet router…? Madness.
Is VLAN the correct approach or is there any other way?
That’s pretty much the only sane approach here since it uses the CRS switches as they’re meant to be used.
The only other sensible option is full-blown port isolation, which is simpler to set up but doesn’t allow any exceptions to its absolute boundaries as VLANs do.