I was tooling through the Help as it likes to change unannounced from time to time and I noticed and read about MACVLAN. Of course it's been around a few months as a tab in Winbox but I never looked into it. This interface solves the problem of being able to do this bridge filtering technique BUT ON YOUR MAIN ROUTER. No offsider router like I used in the OP.
The cool thing about MACVLAN it it gives you another MAC address and interface endpoint hanging off an existing ethernet or VLAN interface. This is just awesome because until now you couldn't add another VLAN interface to a bridge with the same VLAN ID.
My main VLAN is 100 and a test VLAN is 101. I joined MACVLAN interfaces to each VLAN interface and added an mDNS bridge from above. Voila, it works. My phone on 101 can now see the Chromecast on 100 and control it.
* I have VLAN100 and VLAN101 interfaces with their subnet IP addresses and normal L3 routing and filtering - this is where all the main traffic goes between a device and the CC after discovery. I had to disable the DROP rule I had that blocked traffic non-established and related traffic between 101 -> 100.
* I added MACVLANs to each VLAN and joined them on a common (non-VLANed) bridge with bridge filtering. It appears I didn't need to use a BridgeNAT rule as before. Not sure why, needs more testing.
* Just to be clear, my main bridge which the VLAN interfaces hang off is VLAN-filtered.
* The thing about this technique is you don't need a container running some reflector like Avahi and it'll work even on the puniest SMIPS device.
* You can make bridge filter rules that block certain MAC addresses (so you can just allow the mDNS ads from only a printer and not your other gadgets for example).
* Technically it's more efficient than a container as you obviously don't need the resources of a container, but mainly all the packet management is done in kernel space rather than user space.
Can you add more VLANs into the mix? It's untested but why not? All you need to do is add another MACVLAN interface to the additional VLANs. If you're keen you can make certain ACCEPT/DROP rules that only allow particular MACs to traverse between particular VLANs by adding rules with in-interface and out-interface.
The cool thing about MACVLAN it it gives you another MAC address and interface endpoint hanging off an existing ethernet or VLAN interface. This is just awesome because until now you couldn't add another VLAN interface to a bridge with the same VLAN ID.
My main VLAN is 100 and a test VLAN is 101. I joined MACVLAN interfaces to each VLAN interface and added an mDNS bridge from above. Voila, it works. My phone on 101 can now see the Chromecast on 100 and control it.
* I have VLAN100 and VLAN101 interfaces with their subnet IP addresses and normal L3 routing and filtering - this is where all the main traffic goes between a device and the CC after discovery. I had to disable the DROP rule I had that blocked traffic non-established and related traffic between 101 -> 100.
* I added MACVLANs to each VLAN and joined them on a common (non-VLANed) bridge with bridge filtering. It appears I didn't need to use a BridgeNAT rule as before. Not sure why, needs more testing.
* Just to be clear, my main bridge which the VLAN interfaces hang off is VLAN-filtered.
Code:
/interface bridgeadd name=BridgemDNS protocol-mode=none/interface macvlanadd interface=VLAN100 name=macvlan100add interface=VLAN101 name=macvlan101/interface bridge filteradd action=accept chain=forward comment="Allow mDNS only" dst-address=\ 224.0.0.251/32 dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF \ dst-port=5353 in-bridge=BridgemDNS ip-protocol=udp \ mac-protocol=ip out-bridge=BridgemDNS src-port=5353add action=drop chain=forward in-bridge=BridgemDNS comment="Drop all other L2 traffic" \ out-bridge=BridgemDNS * You can make bridge filter rules that block certain MAC addresses (so you can just allow the mDNS ads from only a printer and not your other gadgets for example).
* Technically it's more efficient than a container as you obviously don't need the resources of a container, but mainly all the packet management is done in kernel space rather than user space.
Can you add more VLANs into the mix? It's untested but why not? All you need to do is add another MACVLAN interface to the additional VLANs. If you're keen you can make certain ACCEPT/DROP rules that only allow particular MACs to traverse between particular VLANs by adding rules with in-interface and out-interface.
Statistics: Posted by UpRunTech — Tue Feb 13, 2024 10:05 pm