Hello all,

after month of visiting the forum as a guest mainly for some specific IP work I now have a (in theory) much simpler problem which I haven't found a solution for (yet).

Goal: I'm trying to forward L2 Ethernet traffic from one ether-port to another in RouterOS 7.4. The traffic is raw L2 traffic and not IP traffic. I'm currently testing with a RB3011.
Background: The traffic is from a Linsn LED installation where LED display data is communicated via Ethernet packages and normal CAT6 cables from a "sender card" to a "receiver card". The connection between sender and receiver card normalle is 1:1 (direct) but I'm trying to switch the L2 traffic through RouterOS with the goal to (A) extend the cable run, (B) dynamically select target port/cable route and (C) select multiple target ports to send data from one sender card to multiple receiver cards at once.

When connecting the sender card to a RB3011 port, the incoming ethernet port shows a high activity with 30.000+ Rx Packet (p/s). I've already tried a switch rule, switch mirror source/target etc. but it looks like the RB3011 is too smart expecting IP traffic while it only receives raw L2 frames.

Does anybody have any ideas for configuring a simple forwarding of the receiving packets? Thanks very much in advance!

CD

For devices with Atheros/Qualcomm switch chips you have to use a non-VLAN-aware bridge, otherwise hardware offload / switching is disabled, and then use switch rules - see https://help.mikrotik.com/docs/display/ ... -RuleTable.

There are specific issues with the 3011 as it has two switch chips - see https://help.mikrotik.com/docs/display/ ... witchchips. Depending on the number of ports and what packet processing you require a CRS1xx/2xx or CRS3xx/CRS5xx device may be more suitable.

Hi tdw, thanks for the heads up with the non-VLAN bridge.

As it turns out, it looks like the L2 frames that the Linsn card is sending are faulty and they're discarded with "Rx FCS Error". For the interface the count of all packets combined equals the number of packets with FCS error. Thats probably the reason why they're immediately dropped and no router configuration can be applied. Increasing the MTUs to the maximum value didn't help.

I presume there's no chance to disable FCS/CRC checks, right? Therefore it looks like my goals are unreachable caused by the data frames from the sender card.

Not that I am aware of. I don't imagine any other network switch would pass them either if the packets have an invalid CRC.

Are you sure that the LED displays are talking valid Ethernet and not some custom protocol?

Are you sure that the LED displays are talking valid Ethernet and not some custom protocol?

You may be right. I found a german forum topic that contained a WireShark capture with L2 frames - but that could have been newer Linsn hardware. I tried to directly capture the output of a sender card with WireShark but nothing was received even though there was activity on both sides. So the hypothesis that there is L2 traffic to be switched may already be wrong.

Are you sure that the LED displays are talking valid Ethernet and not some custom protocol?

You may be right. I found a german forum topic that contained a WireShark capture with L2 frames - but that could have been newer Linsn hardware. I tried to directly capture the output of a sender card with WireShark but nothing was received even though there was activity on both sides. So the hypothesis that there is L2 traffic to be switched may already be wrong.

the NIC on your PC possibly discard frames because of FCS error before you can capture them, like happened in the switch

It's possible that the FCS bits is completly unused to keep complexity down. Any bit-errors will just show up as "bad pixels", thus no point to discard the whole frame.

Remember that "it uses ethernet cabling" does not necessarily mean that it uses ethernet compatible framing, as already indicated in above replies.
There also exist "HDMI extenders" to put a video display at larger distance from a source, and they "can work over CAT6 cabling" but that does not mean it is ethernet.
Two different types of those exist: those that require a direct UTP wire and are not ethernet, and those that use ethernet framing and are compatible with switches etc.
You need to carefully look at the specs when ordering them...