Chromecasting and Casing (audio/ video / printer discovery )in general between the vlans, for example cast from the phone that is on the main network to Iot network etc
****This is my original post. Still no progress on mDNS Repeating.
Why do i own a ton of Mikrotik, because its complex technically capable gear and thats who I am. My house is full of segmented networks, VLANS and SSIDs. I run everything from Sat, LORA, WiFi and etherything I can bolt onto my home lab. Mikrotik is at the heart of it all.
If you run a big flat network that is your choice. no criticism here. I choose not to do that and I choose to use my tiks the way they can be used.
So why does Mikrotik, a company that makes such amazing kit continue to ignore this simple little feature request?
My house is full of Google and Apple and i want mDNS to repeat and propegate across my network segments.
Mikrotik Devs. Admins & Management - Does anyone from Mikrotik read our forums, do you have any interest in understaning your loyal communities feedback.
AGAIN - Humbly requesting an mDNS Repeater feature for these amazing product so we can use our tiks the way we want them.
+1
While I currently don’t need it myself, there are tons of valid use cases for a mDNS repeater. There are multiple ready-to-use open source implementations and required configuration is minimal, this really should be implemented as a feature in ROS.
Just deploy IGMP Proxy correctly:
https://help.mikrotik.com/docs/display/ROS/IGMP+Proxy
Upstream interface will be loopback, “downstream” interface will be the L3 subinterface VLANs that sit on top of the bridge. Enable IGMP Snooping on the bridge, disable multicast querier.
I use it, and mDNS along with other multicast routing based apps works fine inter-VLAN.
@DarkNate, interesting, could you share an example of your configuration? igmp-snooping will disable bridge hardware offloading on many low-end devices, multicast-querier must be disabled on the router?
Thanks
I still can achieve 1Gig end-to-end routing performance inter-VLAN on RB450Gx4, hAP ax2 etc. I don’t see what’s the problem with losing hardware offloading. As long as you use single bridge per switch chip, bridge fast-foward/fast-path will work:
https://help.mikrotik.com/docs/display/ROS/L3+Hardware+Offloading#L3HardwareOffloading-Creatingmultiplebridges
Yes multicast-querier must be disabled.
IMO, mDNS repeater is for lazy bums who refuse to learn PIM-SM and/or IGMP Proxy as evident in this group. Hardly any real network engineering efforts are made.
I appreciate that MikroTik doesn’t bend down to lazy-bums’ demand for years. One of the few good vendors in that regard.
In my configuration example, I have one router and an L2 switch connected to it for Wi-Fi, keep that in mind:
#Router side#
/interface bridge
add frame-types=admit-only-vlan-tagged igmp-snooping=yes igmp-version=3 mld-version=2 name=bridge priority=0x1000 vlan-filtering=yes
add arp=disabled name=loopback protocol-mode=none
/interface vlan
add interface=bridge mtu=9214 name="VLAN40" vlan-id=40
add interface=bridge mtu=9214 name="VLAN30" vlan-id=30
/interface bridge port
#This is the trunk port connected to the L2 switch#
add bridge=bridge edge=no frame-types=admit-only-vlan-tagged interface=ether1 point-to-point=yes
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=40
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=40
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=40
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=40
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether6 pvid=40
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether7 pvid=40
add bridge=bridge edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether8 point-to-point=yes pvid=30
/interface bridge vlan
add bridge=bridge comment="VLAN40 + MGMT VLAN" tagged=bridge,ether1 vlan-ids=30,40
/ip address
add address=100.64.0.1/24 comment="VLAN40" interface="VLAN40" network=100.64.0.0
add address=30.0.0.0 comment="Loopback" interface=loopback network=10.0.0.0
add address=100.64.2.1/25 comment="VLAN30" interface="VLAN30" network=100.64.2.0
/routing igmp-proxy interface
add interface=loopback upstream=yes
add interface="VLAN40"
add interface="VLAN30"
#On L2 switch side#
/interface bridge
add frame-types=admit-only-vlan-tagged igmp-snooping=yes igmp-version=3 mld-version=2 name=bridge priority=0x2000 vlan-filtering=yes
/interface bridge port
#Ether1 is trunk port connected to router#
add bridge=bridge comment=defconf edge=no frame-types=admit-only-vlan-tagged interface=ether1 point-to-point=yes trusted=yes
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=40
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=40
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=40
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=5GHz_1 pvid=40
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=2GHz_1 pvid=40
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=30
/interface bridge vlan
add bridge=bridge tagged=ether1,bridge vlan-ids=30
add bridge=bridge tagged=ether1,bridge vlan-ids=40
If you have IPv6, which you should, be sure to configure a /128 GUA on the loopback interface or some ULA addressing. Without IP addressing on the loopback interface for both v4 and v6, IGMP Proxying will fail.
That’s one way to look at it. But why is MikroTik selling hAP ax lite into the home market? Most home users are not network engineers.
Your argument sounds similar to:
IMO, the nano editor is for lazy bums who refuse to learn vi. …
MikroTik sells hardware running a single version of RouterOS, the same thing found in ISPs, Telcos and Data Centres. Which vendor other than MikroTik sells an AP like ax lite supporting MPLS over IPv6 out of the box? None.
Their target “home users” are power users. Not your grandma or grandpa who can’t tell IPv4 from IPv6.
If your “home users” can’t configure IGMP Proxy (like my example config or even the official docs), they should stick to TP-Link with OpenWRT.
Well I’m not sure using OpenWRT is needed either. If you use just one LAN at a home, that solves the problem too.
And if you’re are using VLANs, don’t put stuff that needs multicast (e.g. mDNS [AirPrint, etc.]) on different subnets, also solve this. Since there are containers that support mDNS, that’s an easy out here for Mikrotik when someone wants to do something non-standard. Or want to get more creative? DarkNate’s complex world of multicast routing awaits – for those that just got the hang of VLANs…
But even after 50K views, no one has described how it work in practice, beyond “others vendors do it” or “add X package”… e.g. how would Mikrotik even define the needed mDNS “overlay network” in the RouterOS config? I don’t think this is a trivial or easy thing to do.
While not a fan of @DarkNate’s tone, have to agree I’m glad Mikrotik has NOT “caved in” to mob here. The standards/RFCs advise against repeating mDNS. And unicast DNS-SD is the RFC approved method for “mDNS” accross subnets/segments.
Use IGMP Proxy in simple VLAN segregated home networks and call it a day. iPhone in VLAN1 can talk to iPhone in VLAN2 for AirFuckKnowsWhat, no problem.
Unicast DNS-SD defeats the whole purpose of multicast aka saving computing resources on L2 and L3.
"Sorry bro" but unicast is way more efficient than multicast. Not saying don't use IGMP or a container to solve mDNS via milticast... but I can totally see why Mikrotik doesn't add this. e.g.
What are you talking about? Multicast is superior for saving resources:
https://networkengineering.stackexchange.com/a/19587
https://www.researchgate.net/publication/258790065_A_Multicast_IPTV_Bandwidth_Saving_Method
https://research.ijcaonline.org/volume64/number14/pxc3885611.pdf
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=acd09c1f6afe53611e91a97adf789348a684cc44
https://cims.nyu.edu/~eyal/papers/ngc.pdf
Why do you need mDNS proxy when IGMP Proxy for inter-VLAN multicast routing works fine, to begin with?
I’ll give that at some small scale multicast may be more efficient – but you can’t IGMP proxy a large enterprise/campus/etc network – exactly where it breaks down is harder to predict. And compared to TTL-based caching of unicast DNS-SD results, I’m not sure even at smaller scales… But certainly multicast isn’t friendly to Wi-Fi with duplicative mDNS data taking up airtime…
But I think we’re in agreement: Mikrotik shouldn’t blindly ignore the RFCs WRT to how mDNS/DNS-SD works by promoting it to a mDNS redirection/reflection/etc into a built-in feature. If you want to expand the scope of all multicast (e.g. not just mDNS), then certainly PIM and IGMP proxy are valid ways to go. As would a container.
It seems you aren’t aware that multicast is used in large scale from stock trading which is nanosecond sensitive to TV networks where multicast serves hundreds of millions of users per second, that unicast simply cannot do without choking a 10G or even 100G link.
I suggest you read this thread, where real network engineers who deploy multicast for a living discuss further:
https://twitter.com/danieldibswe/status/1461200782540353540
And oh, duplicate multicast packets are eliminated or reduced when IGMP Snooping + IGMP Proxy or PIM is correctly deployed in a network, you can go even further with EVPN like DE-CIX did.
@DarkNate
You are little bit arrogant, aren’t you?
That you are expert in multicast routing does not mean that everyone else must be too. Good for you, but call anyone else lazy-bum?
Not everyone needs to know multicast routing even if they work in IT.
Mikrotik sells wireless APs on consumer market and with “wizard” for simple setup. Do you think that user who buys mikrotik and uses wizard should be able to setup multicast routing and IGMP proxy?
Mikrotik sells to consumers too and configuration should be simple.
And another point. I got briefly over “Multicast DNS” RFC6762 and on several places it counts with “Multicast DNS Proxy Servers” for example as with duplicate answer suppression.
So I do not see anything wrong or proxy/repeater.
Other vendors, even big names have such feature.
So if Mikrotik still plans to sell on consumer market they should consider this functionality. No consumer will do IGMP proxy, multicast etc.
I am not a multicast routing expert. But I work with those who are. None of them are in this thread.
@DarkNate, appreciated your help, followed suggestions on the previous post but not working, could be my fault.
Tried setting the bridge as upstream and then the VLAN2, printer was not visible on both cases, connected to VLAN1 and worked immediately.
I’m OK with IGMP Proxy, the MT complicated way instead of the more consumer repeater, I worked for a short time on huge CISCO campus network (but I’m not experienced as you), never had any problem printing or sharing contents on Apple devices between VLANs with the “repeater” function.
In my case I’m a low-end user, I can print with my computer using the static IP of the isolated device, using an iPhone is not possible to set the IP. How can you eventually build a network for a client with this missing feature?
Why is the bridge upstream? Who told you to do that? I said the loopback needs to be upstream and then the L3 VLANs are separate downstream.
Read it properly:
http://forum.mikrotik.com/t/mdns-repeater-feature/148334/1
I have mDNS repeating running over a Wireguard link. I had started the process of building this https://github.com/TheMickeyMike/docker-mdns-repeater-mikrotik but then as the container system only allows one interface and the trick with this container is to feed in VLANs over it so things started to look messy or not possible this way with EoIP. I thought there might be another simpler method with bridge filters.
Wireguard is joining the subnets on L3 and each subnet is routed to the other with no filter rules.
EoIP is joining the bridges at each end using the same Wireguard link - no IPSEC used. The following filters are applied at each end as well to only let mDNS and SSDP (for UPnP) frames through on EoIP.
/interface bridge filter
add action=accept chain=forward 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 ip-protocol=udp \
mac-protocol=ip out-interface=EoIP src-port=5353 comment=mDNS
add action=accept chain=forward comment=SSDP dst-address=239.255.255.250/32 \
dst-mac-address=01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF dst-port=1900 \
ip-protocol=udp log-prefix=SSDP mac-protocol=ip out-interface=EoIP
add action=drop chain=output out-interface=EoIP
add action=drop chain=forward out-interface=EoIP
My iPad and CUPs on my PC can both discover and print to the printer at the other side. The LG Smart TV at the other house with the Photos and Videos App can discover (using SSDP) and play from my MythTV server.
Nothing seemed to work quite right until I reduced the MTU of the Wireguard interface to 1412 bytes as one end is using PPPoE. Also, the neighbour discovery service (dest. MAC FF:FF:FF:FF:FF:FF UDP:5678) seems to be out of the capture reach of the bridge filter so those frames get through. Mitigation would be to make sure that interface in question isn’t included in the discovery process.
This method should work fine with VLANs or any other sets of bridge interfaces Mikrotik supports. No mDNS repeater software in containers, rPi’s or IGMP snoopers needed; certainly not for small cases like this. I have tested using iPads at each site to discover and print to printers on the other site. So it works.
Here is a quick config I just knocked up on a hAPAC Lite to illustrate mDNS relaying between VLANs using bridge filtering and no IGMP snooping. IPv4 only.
- To be clear this mDNS relay config only relays mDNS traffic. It does not proxy any other data or do any IGMP or other multcast tasks.
- VLAN filtering is enabled using BridgeMain. Tagged VLANs 100 and 200 go to it for the VLANs interface to access.
- eth2 has PVID100, eth3 has PVID200.
- BridgeVLANs is the bridge that will straddle the 2 VLANs. It has the VLAN100 and VLAN200 ports attached as members. If left unfiltered all layer 2 broadcast traffic on both VLANs will pass between them.
- The bridge filter setup operates on each VLAN port only allowing mDNS to pass each way and blocking all other layer 2 traffic.
- Any actual data traffic that clients or servers use on either VLAN using addresses learned in the mDNS packets will pass via the routes on layer 3. You’ll need add firewall rules to limit the traffic interaction but is out of the scope of this example.
- I would imagine this would work just fine on a CRS3xx switch as well but you might as well use the rolled gold standard of IGMP snooping.
/interface bridge
add comment="Main Bridge VLAN filtering runs on" frame-types=admit-only-vlan-tagged name=BridgeMain protocol-mode=none pvid=999 vlan-filtering=yes
add comment="Bridge for linking VLANs with filtering" name=BridgeVLANs protocol-mode=none
/interface ethernet
set [ find default-name=ether2 ] comment="Eth PVID100"
set [ find default-name=ether3 ] comment="Eth PVID200"
/interface vlan
add comment="VLAN100 on main bridge" interface=BridgeMain name=VLAN100 vlan-id=100
add comment="VLAN200 on main bridge" interface=BridgeMain name=VLAN200 vlan-id=200
/interface bridge filter
add action=accept chain=forward comment="Allow VLAN100 mDNS traffic out" 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 out-interface=VLAN100 ip-protocol=udp mac-protocol=ip src-port=5353
add action=accept chain=forward comment="Allow VLAN200 mDNS traffic out" 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 out-interface=VLAN200 ip-protocol=udp mac-protocol=ip src-port=5353
add action=drop chain=forward comment="VLAN100 drop all other forwarding" out-interface=VLAN100
add action=drop chain=output comment="VLAN100 drop all output" out-interface=VLAN100
add action=drop chain=forward comment="VLAN200 drop all other forwarding" out-interface=VLAN200
add action=drop chain=output comment="VLAN200 drop all output" out-interface=VLAN200
/interface bridge port
add bridge=BridgeVLANs comment="VLAN100 Port" interface=VLAN100
add bridge=BridgeVLANs comment="VLAN200 port" interface=VLAN200
add bridge=BridgeMain comment="Eth PVID100" frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=100
add bridge=BridgeMain comment="Eth PVID200" frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=200
/interface bridge settings
set use-ip-firewall=yes use-ip-firewall-for-vlan=yes
/interface bridge vlan
add bridge=BridgeMain comment="VLAN100 port definitions" tagged=BridgeMain vlan-ids=100
add bridge=BridgeMain comment="VLAN200 port definitions" tagged=BridgeMain vlan-ids=200
/ip address
add address=172.16.200.254/24 comment="VLAN200 interface address" interface=VLAN200 network=172.16.200.0
add address=172.16.100.254/24 comment="VLAN100 interface address" interface=VLAN100 network=172.16.100.0
I attempted to run mDSN discovery over wireguard but at two DIFFERENT LOCATIONs…
Feel free to test it, to make sure it works…academic at this point.
https://forum.mikrotik.com/viewtopic.php?p=990840#p990840