CRS112-8G-4S-IN as fiber coupler & media converter

RouterOS General
1

hello

is there a better solution for this task:

  • incoming fiber from VDSL modem/router (connected to SFP9)

  • fiber to next building (connected to SFP10)

  • ether 1-4 as “outlets” for clients

  • set ether1,ether2,ether3,ether4,sfp10 master-port=sfp9

and the same CRS112-8G-4S-IN serves for a second switch funtion on a second set of fibers (a second VDSL connection)

  • set ether5,ether6,ether7,ether8,sfp11 master-port=sfp12

So, in short, the CRS112-8G-4S-IN serves as a dual combination of:

  • coupler between fiber in and fiber out
  • switch between those fibers and 4 ether ports

This I want to repeat several times:

  • VDSL modem/router – building1 – building 2 – building 3

Comments? Tips?

Thanks!
Dirk111

2

I’d configure VLANs. They would be kind of imaginary as they would be only used internally inside single RB. They would only have access ports, no trunk ports. Use two VLANs, one per SFP/ether port group … If number of fibres between the buildings is a problem, trunk ports could be used for those connections, but in that case VLAN IDs would have to be consistent (=same) on all RBs.

3

I have little experience with VLAN’s…
In the manual of the CRS1xx I found this:
Dynamic reserved VLAN entries (VLAN4091; VLAN4090; VLAN4089; etc.) are created in CRS switch when switched port groups are added by setting new master-ports. These VLANs are necessary for internal operation and have lower precedence than user configured VLANs.

OK, these are dynamic VLAN’s, but is this in essence what you suggest? Or is a user configured VLAN better…

Trunk: for each network connection I have a pair of fiber installed.

Dirk111

4

switched to ROS 6.42.1
port bridging with hw-offload: works . Should be layer 2 switching…

Since RouterOS v6.40rc29 there are user interface changes which convert RouterBoard master-port configuration into a bridge with hardware offloading. From now on bridges will handle all Layer2 forwarding and the use of switch chip (hw-offload) will automatically turn on if appropriate conditions are met. The rest of RouterOS Switch features remain untouched in usual menus. By default all newly created bridge ports have hw=yes option and it allows enabling of hw-offload when possible. If such functionality is not required, it can be disabled by hw=no on bridge port to have completely software operated bridging.

Dirk111

5

The problem with bridges in current post-6.40 versions of ROS is that only one can have hardware offloading enabled, or so they say … So better use single bridge to enjoy full speed and explicitly create a couple of VLANs. Explicit configuration is better than implicit, when reviewing settings after a while one doesn’t have to think about why certain things work in certain way.

So yes, I’m suggesting something like dynamic VLANs but user-defined due to reasons stated above.

6

tomorrow I’l be testing this last solution in ROS 6.42, but this time in “real life”
Here (today) in the work shop everything went OK.

There should be a real change (ROS 6.40 vs 6.42)…
So I use
interface/bridge add name XX ig.snoop=no prot.mode=none
interface/bridge add name YY ig.snoop=no prot.mode=none

interface/bridge/port add bridge XX interface =ether1
interface/bridge/port add bridge XX interface =ether2
interface/bridge/port add bridge XX interface =sfp9

interface/bridge/port add bridge YY interface =ether3
interface/bridge/port add bridge YY interface =ether4
interface/bridge/port add bridge YY interface =sfp10

but realy, MKX, thanks for the feedback!!
I’m learning!

Dirk111