Bridge forwarding using both MAC and VLAN together

I have been experimenting with the new vlan bridge filtering in the hope that it may solve an issue I have been having with peering. I am talking to a remote host that presents to me with the same MAC over two physical interfaces. Each physical interface has a separate vlan tag on it and of course different L3 addresses.

I have a CRS317 switch between my router and the two interfaces - my intention is to bridge the two interfaces and allow the vlans to both be presented onto a single interface on my router. The issue seems to be that the despite the hosts table in the bridge being able to handle multiple lines with the same MAC and different vlan, they must have the same physical interface. In other word the bridge router is unable to lookup which interface to send the packet down based on the MAC and the VLAN tag, but instead can only use the MAC.

I have recreated the much simpler situation in the lab and have recreated the fault. Here in the configuration:-

My Router - ether1 connected across to ether1 on the “switch”

/interface vlan
add interface=ether1 name=vlan20 vlan-id=20
add interface=ether1 name=vlan30 vlan-id=30
/ip address
add address=192.168.20.1/24 interface=vlan20 network=192.168.20.0
add address=192.168.30.1/24 interface=vlan30 network=192.168.30.0

The “switch” (actually another router) ether2 and ether3 carry vlans 20 and 30 and are plugged into ether2 and ether3 respectively on the far end router.

/interface bridge
add name=bridge-main vlan-filtering=yes
/interface bridge port
add bridge=bridge-main interface=ether1
add bridge=bridge-main interface=ether2
add bridge=bridge-main interface=ether3
/interface bridge vlan
add bridge=bridge-main tagged=ether1,ether2 vlan-ids=20
add bridge=bridge-main tagged=ether1,ether3 vlan-ids=30

The far end router (which I don’t control). Given it presents with a single MAC over both interfaces I assume this must be the MAC address of a bridge.

/interface bridge
add admin-mac=02:CA:6D:3F:62:F1 auto-mac=no name=bridge-peering \
    vlan-filtering=yes
/interface bridge port
add bridge=bridge-peering interface=ether2 pvid=40
add bridge=bridge-peering interface=ether3 pvid=50
/interface bridge vlan
add bridge=bridge-peering tagged=ether2,bridge-peering vlan-ids=20
add bridge=bridge-peering tagged=ether3,bridge-peering vlan-ids=30
/interface vlan
add interface=bridge-peering name=vlan20 vlan-id=20
add interface=bridge-peering name=vlan30 vlan-id=30
/ip address
add address=192.168.20.2/24 interface=vlan20 network=192.168.20.0
add address=192.168.30.2/24 interface=vlan30 network=192.168.30.0

N.B. under /interface bridge port I set the pvid to be 40 and 50 so there was no chance of conflict - we are not interested in any untagged traffic

From the first router I am able to ping 192.168.20.2 but not 192.168.30.2

Only a single entry appears in the “switch” host table:-

 #       MAC-ADDRESS        VID ON-INTERFACE                        BRIDGE                        AGE                 
 7   D   02:CA:6D:3F:62:F1   20 ether2                              bridge-main                   1s

I am able to ping 192.168.30.2 only by disabling ether2, relaxing the vlan filtering and allowing the traffic to all go over ether3. Then I get the same mac address on vlan 30, but they now both are on ether3.

 #       MAC-ADDRESS        VID ON-INTERFACE                        BRIDGE                        AGE                 
 5   D   02:CA:6D:3F:62:F1   20 ether3                              bridge-main                   0s                  
 9   D   02:CA:6D:3F:62:F1   30 ether3                              bridge-main                   7s

If I am asking too much of the vlan filtering, can anyone suggest another way to do this? I can’t change the far end of course. I would also like to continue to use the hw acceleration features of the CRS317 (so I can’t put bridges on top of vlans). I would also like to avoid pulling the physical interfaces back to the router (don’t have enough sfp+).

What you expect should work normally, but at both the “router-used-as-a-switch” and “far end router”, you haven’t specified any protocol-mode for the bridges you use, which causes them to run RSTP by default. I’m afraid that RSTP blocks one of the two connections between the “far end router” and your “router-used-as-a-switch” to prevent an L2 loop. RSTP doesn’t care about VLANs, so it has no knowledge that only one VLAN is permitted on each of the two ports.

Worse than that, I was doing something roughly similar recently (to find out whether a blackbox switch uses independent learning per VLAN or not), and to my surprise the vlan-filtering did not actually filter packets with “wrong” VLAN ID neither on ingress nor on egress (which may have been a bug of that RC version, I haven’t tested that again after an upgrade). So if that’s still true, by just setting protocol-mode to none on the bridges you would trigger an L2 loop. To get rid of it, I had to use /interface bridge filter to permit only the “right” VLAN on the ports.

The cleanest solution would be to properly configure MSTP on both the “far end router” and “router-used-as-a-switch” (or, simpler, to keep RSTP in operation and permit both VLANs on both connections, thus obtaining redundancy), but if that’s out of question, you may set the ingress filtering by VLAN ID as suggested above on your “router-used-as-a-switch” and then set the protocol-mode to none on the bridge only on that device. I’m however not sure whether in such case the RouterOS won’t flood the RSTP frames transparently just like any other frame with an unknown destination MAC address; if it does, you have to block them on ingress as well.

As for the hardware “accelerated” bridging, I don’t have any CRS I could play with, but I suppose you can set up the ingress VLAN filter using the /interface ethernet switch menu rather than /interface bridge filter menu to keep the hardware acceleration active.

Other than that, I am a bit lost in your configuration exports. The first one comes from “your router” and the last one from the “far end router”, correct? In such case, having the same IP address (x.x.x.2/24) on both is not a good idea.

My apologies, I pasted the config from the wrong router - I have now fixed the OP.

You other suggestions are very helpful - it is possible my recreation of the problem is not perfect - particularly around the far end router, that is not under my control so I can only guess at it’s config. I am going to set all the bridges to protocol=none and then attempt to deal with any loops that occur using filtering.

Perfect! That was the issue. I just set the protocol-mode=none in both bridges (the far router and the “switch”) and now it is indeed forwarding based on the mac and the vlan. I didn’t end up having to deal with any L2 loops, so I am guessing the vlan filtering is working properly.

 #       MAC-ADDRESS        VID ON-INTERFACE     BRIDGE    AGE                 
 0   D   02:CA:6D:3F:62:F1   20 ether2           bridge... 13s                 
 1   D   02:CA:6D:3F:62:F1   30 ether3           bridge... 14s

In other words my emulation of the situation was not perfect!