Send L2 traffic over EoIP, IP traffic in parallel outside of EoIP

RouterOS General
1

I’ve been stumped by this for a few days now and am running out of ideas.

I have a WiFi link (one L22UGS-5HaxD2HaxD and one old LtAP, although will be two 5HaxD2HaxDs once installed). Each device has a single ethernet port connected to switches on each end. There is a mixture of non-IP L2-only traffic (latency-sensitive industrial protocols with weird ethertypes) and normal IP traffic (camera streams).

To get the L2-only traffic through, I’ve set up an EoIP tunnel over the WiFi link that is bridged to the Ethernet port. This works, but ends up transporting all traffic (not just the L2-only traffic), and I’d like to separate out the IP traffic to go around the tunnel so I can apply strong QoS priorities to the L2-only traffic - the camera traffic causes latency spikes which eventually (after a few hours) causes major issues with the industrial L2-only stuff. I’ve added a “set-priority” rule on the bridge to help the L2-only traffic which helped greatly when the camera stream is switched on(hours of stability instead of seconds), but I need to go further.

I’ve tried lots of ideas to split out the IP traffic, including a filters on the bridge to drop IP traffic (with routes and/or NAT rules to send it through the WiFi link without using a bridge) but the bridge seems to be “greedy” and eats all of the traffic first before I can do anything with it - any firewall/NAT/etc. rules are never hit with the bridge filter dropping IP packets first.

Worth mentioning that I can’t totally isolate everything - one of the industrial devices speaks both L2-only and TCP and needs to contact a couple of the cameras to read some metadata.

Here’s the basic setup without any of the complicated filters/firewall rules I’ve attempted:
Device 1:

/ip address add address=172.16.16.128/24 interface=ether1 network=172.16.16.0
/ip address add address=172.16.17.128/24 interface=wifi1 network=172.16.17.0

/interface bridge add admin-mac=<MAC of ethernet port> auto-mac=no comment=defconf name=bridge protocol-mode=none

/interface eoip add mac-address=00:00:5E:80:00:80 mtu=1500 name=eoip-tunnel1 remote-address=172.16.17.130 tunnel-id=0

/interface bridge port add bridge=bridge interface=ether1
/interface bridge port add bridge=bridge interface=eoip-tunnel1
/interface bridge filter add action=set-priority chain=forward mac-protocol=0x8892 new-priority=1

Device 2:

/ip address add address=172.16.16.130/24 interface=ether1 network=172.16.16.0
/ip address add address=172.16.17.130/24 interface=wifi1 network=172.16.17.0

/interface bridge add admin-mac=<MAC of ethernet port> auto-mac=no comment=defconf name=bridge protocol-mode=none

/interface eoip add mac-address=00:00:5E:80:00:82 mtu=1500 name=eoip-tunnel1 remote-address=172.16.17.128 tunnel-id=0

/interface bridge port add bridge=bridge interface=ether1
/interface bridge port add bridge=bridge interface=eoip-tunnel1
/interface bridge filter add action=set-priority chain=forward mac-protocol=0x8892 new-priority=1

Any ideas would be greatly appreciated.

2

Hi,

Somewhat of a guess

You need to have 2 ip address ranges to get things to route. With the device sending its packet at the router, not
at the other device.

You could perhaps split the 172.16.16.0 range into 2 /25 ranges.
with side 1 having 172.16.16.0/25 gateway 172.16.16.1, side 2 having 172.16.16.128/125 gateway 172.16.16.128

With bridge filters for the eoip tunnel blocking both ip and arp in both directions.

You can fudge this with proxy arp as well. (Less good, but depending on devices may be the only option)

So devices on each side, think they have a /24 range, (While their router knows they only have a /25 range, and only hands out
their half of the range via dhcp, but with a /24 subnet)

When the device arps for a device on other side, local router knows it is remote, and answers with its own address, and routes the packets across.

There is also published arp. (similar to proxy arp, but has less potential side effects, but more effort to setup)

3

Another simpler option if (it works at all) is to enable local proxy arp.
(Without changing original config)
Not quite sure where you would apply this, on the bridge, or the actual interfaces??

Then maybe all ip traffic would get routed.

4

Yet another option might be to have dhcp hand out /32 ip address ranges.
So everything IP has to be routed.

(Likely not well handled by older devices)