I have a very simple setup in mind for a home situation with a CRS125 and consumer ASUS router, but I need some clarifications. There's a fiber uplink connected on ether24 with WAN access on VLAN 4. Since the CRS cannot route the full bandwidth of the uplink this is to be done on that ASUS router. I want to make ether23 an access port for vlan 4 for this router. The LAN segment of this router will have a wire back to the CRS125 on port ether22.
Ports ether1-ether22 should be untagged as simple desktop ports with WAN access.
Of course I wish to retain switch chip functionality wherever possible.
My questions:
- do I make separate bridges for ports 1-22 and 23-24 or can they all go on the same one since they're separated by VLAN anyway?
- do I configure anything besides 1) vlan id 4 and port members ether23, ether24; 2) ingres translation 0 - - > 4 on ether23; 3) egress translation 4-->0 on ether23?
- do I need another VLAN for ports 1-22?
- do I specify any VLAN configuration under /interface bridge?
Thanks for any insights

You don't really need VLAN to achieve what you are doing.

Is there a "need" to go in and out of the CRS? Why not deliver the internet directly into the ASUS and then LAN link down into the CRS?

Just use bridges and hardware offload and you should be fine.

The ASUS doesn't understand VLANs. Additionally once this is up and running I want to use the sfp1 module instead of having an extra fiber NTU.

You can do it using single bridge or using two bridges. I'm using single bridge, I feel it is simpler if I want to change VLAN membership of any given ethernet port.

I have a VLAN for normal access ports (in your case ports 1-22) even though it's internal to RB device. You never know when you'll be adding additional VLAN- capable switch. Or you might want to split your LAN to two or more VLANs so why not prepare for it in advance. Be careful, though: if you introduce VLAN to all access ports, you'll need to create vlan device on bridge and assign RBs IP address to that particular vlan device in order to have management access to RB device. And anything else your RB device might serve to your LAN (e.g. DHCP server) gets configured on that vlan device as well. In short, bridge "device" will not be directly seen anymore. You don't configure anything regarding VLANs on bridge device though.

If you'd introduce VLAN 999 to be used internally for access ports, you'd configure your ethernet ports as following: N is for ports 1-22. On port 24 all ethernet frames are expected to be marked with VLAN headers, hence no default VID settings. Since that ethernet port is only member of VLAN 4 group, any packets with different VLAN ID will be rejected.

If your RB has several switch chips, you'll need to split the "add ports=" command to several commands, one per switch chip ... and remember to add switch-cpu "port" to all of them so the bridge will see VLAN-tagged packets from all of them.
If switch-cpu is not on the list of ports for a given VLAN ID, that VLAN is not available upwards (e.g. bridge connecting switched ports with wlan or whatever else). Meaning that for VLAN 4 your RB will be completely transparent, no interaction with routerOS will be possible using that VLAN. Actually if you'd create separate bridge for this VLAN, it would never get used.

A side note: even though ROS allows it, I don't think you can use VLAN ID 1 for any settings, it didn't work for me. I suspect that VLAN ID 1 is actually used implicitly for untagged ethernet frames and using it explicitly screwes things up.

Thanks for your detailed explanation, clears up a whole bunch. I take it then that the new bridge functionality encompasses all that used to be done under '/interface ethernet switch' w.r.t. ingress/egress tagging and translation?

I haven't done any configuration in ROS 6.41+ ... what I've got is ported from previous versions. From what I observed, nothing fundamental changed with new bridge implementation regarding VLANs. The examples in my previous post are from working ROS 6.41.1 ...

My impression might well be wrong though.