For those interested, i created an extended container image based on the github repo and a setup script which simplifies the mDNS repeating setup:

Mikrotik: mDNS Repeater as Docker-Container on the Router (ARM,ARM64,X86) (english version)
Mikrotik: mDNS Repeater als Docker-Container auf dem Router (ARM,ARM64,X86) (german version)

Thanks for your work, @colinardo!
I've tried it with with your arm64 docker image and also built an own container with the help of your sources.
In both cases the following error message appears while starting the container on a RB5009UG+S+ (arm64) or on a CHR (x86_64) with v7.10.2:

ip: RTNETLINK answers: Not supported

Any idea about the root cause?
Thank you!

Thanks for your work, @colinardo!
I've tried it with with your arm64 docker image and also built an own container with the help of your sources.
In both cases the following error message appears while starting the container on a RB5009UG+S+ (arm64) or on a CHR (x86_64) with v7.10.2:

ip: RTNETLINK answers: Not supported

Any idea about the root cause?
Thank you!

Cannot confirm this, successfully works both on CHR(x86) as well on a RB5009 on current fresh RouterOS Release Version 7.10.2, with the provided container.
You have to follow the guide precisely!

Regards @colinardo

p.s. If you have any other questions please only post them on administrator.de in the corresponding tutorial. I am not following this post regularly, thanks.

Cannot confirm this, successfully works both on CHR(x86) as well on a RB5009 on current fresh RouterOS Release Version 7.10.2, with the provided container.

You have to follow the guide precisely!

Argh! Didn't follow the guide in detail - my fault! After naming the VLAN interfaces in the proper way and assigning the IPs, the container started successfully.

Additionally I had to activate the Multicast Helper (set to 'full') on the wireless interfaces and disable NAT between both networks.
Now the connection to AirPlay devices is running.
Unfortunately the connection to AirPlay2 devices doesn't work. Can anyone confirm that or does anyone have an idea?

Thank you guys!

Unfortunately the connection to AirPlay2 devices doesn't work. Can anyone confirm that or does anyone have an idea?

I think the airplay protocol enforces a same subnet rule before starting a stream. So I’m guess the mDNS is working, and AirPlay internally is enforcing DRM/anti piracy.

Argh! Didn't follow the guide in detail - my fault! After naming the VLAN interfaces in the proper way and assigning the IPs, the container started successfully.

Additionally I had to activate the Multicast Helper (set to 'full') on the wireless interfaces and disable NAT between both networks.
Now the connection to AirPlay devices is running.
Unfortunately the connection to AirPlay2 devices doesn't work. Can anyone confirm that or does anyone have an idea?

Thank you guys!

No problem, shit happens .

The mDNS Protocol is responsible only for device announcement in the subnets, it has nothing to do with connections between the devices itself.
If the connection depends on multicast streams (wich is normally the case when media is streamed to multiple devices) which also have a TTL value of 1 they will never leave their own subnet. In this case you have to enable the IGMP Proxy Feature with an upstream to the source subnet where the stream comes from to make them accessible for the other subnet. And don't forget firewall rules for UDP traffic and multicast address range (224.0.0.0/4). Capture the traffic with the sniffer tool and you will get more information about the connections and their needs.

Wish you good luck. Sorry but I don't have apple equipment available for testing.

Regards

Thanks again, @colinardo!
mDNS is completely working now here.
All test devices (AirPlay with Samsung TV, Yamaha MusicCast, Bose SoundTouch; AirPrint with HP MFD) are working fine, even without IGMP Proxy and without Multicast Firewall Rules. All these devices are happy without NAT.
Only a newer Bose SoundBar is refusing to work. Seems like a shitty implementation on their side. First of all, traffic needs to be natted because Bose in this series seems not to be aware of using a gateway. And even then, an AirPlay 2 stream doesn't work. Anyway, I'm ignoring this device right now

Did anyone figure out why an IGMP proxy would work for the chromecast discovery across a vlan boundary?
I've been performing some tests in a single-router environment with a Mikrotik Hex S router connected via trunk port to a Unifi AP with two SSID:s where one contains an android device and the other contains a chromecast. Each SSID corresponds to a vlan on the trunk and both these vlans are created as interfaces on the bridge. Vlan-filtering is enabled and only vlan tagged packets are allowed on the trunk port to the AP.

Reading about IGMP-Proxy it seems like the upstream port should be connected towards the root of the multicast tree and it is used to send IGMP membership reports e.g., to indicate interest/join a multicast group. However if the chromecast is on vlan 20 and android phone on vlan 10, both connected via the same switch trunk port in the Hex S router, it seems logical that the IGMP-proxy upstream interface would be vlan 20 if the android phone wants the router to forward the IGMP membership report to the chromecast. Connecting a computer with wireshark sniffing on vlan 20 does not reveal any IGMP membership reports coming from the router, nor is any multicast traffic originating at the chromecast forwarded to vlan 10.
Must multicast traffic be forwarded in both directions for the chromecast discovery to work?

In an attempt to remove problems with the firewall I temporarily allowed any traffic destined to 224.0.0.0/4 in both directions (vlan10 <-> vlan20) and I also tried the same thing with bridge filtering.
Per earlier suggestions in this thread I also enabled igmp-snooping on the bridge but I did not notice any difference.
I also added a loopback bridge as upstream interface for the igmp-router as DarkNate suggested but did not see any difference in traffic on the two vlans and I struggle to understand why and if a loopback bridge would provide better connectivity than using the vlan interface as the IGMP-router upstream.

However, I'm pretty sure I haven't grasped entirely how it is supposed to work so would appreciate if anyone had any insights to share apart from just using a mDNS reflector/repeater container to solve it or to put everything in the same network.

I think the Chromecast works(/can work) because it's using DIAL/SSDP, which uses IGMP. But the IGMP proxy has be setup pretty exactly even in that case... For mDNS itself, I think the conclusion was something in mDNS protocol or bug in IGMP proxy causes it to not work.

MikroTik IGMP Proxy doesn't support IPv6 it seems, after further PCAPs myself, meaning it isn't performing MLD Proxying in the process, even though you configure it right.

I suggest you talk to MikroTik official support about it. If they make it work with IPv6, then all these problems disappear overnight.

The other advanced solution is PIM. I personally would never use PIM in a home network, too much complexity.

I guess I don't understand the extent of what the IGMP Proxy can do for IPv4.
Will the proxy forward more than just the IGMP report and query messages? It seems to me that IGMP is used to join/leave the multicast groups for mDNS and SSDP/DIAL, but once joined will the proxy also forward the other non-IGMP multicast packets that are part of mDNS and SSDP/DIAL?

PIM seems more likely to do the above mentioned tasks but as you said DarkNate, it seems to add a lot of complexity.
Is there anything more that IPv6 MLD would do other than what the IGMP-Proxy already does for IPv4? E.g., something that would make it more suited to allow multicast traffic and mDNS discovery to traverse a subnet/vlan boundary?

I guess I don't understand the extent of what the IGMP Proxy can do for IPv4.
Will the proxy forward more than just the IGMP report and query messages? It seems to me that IGMP is used to join/leave the multicast groups for mDNS and SSDP/DIAL, but once joined will the proxy also forward the other non-IGMP multicast packets that are part of mDNS and SSDP/DIAL?

PIM seems more likely to do the above mentioned tasks but as you said DarkNate, it seems to add a lot of complexity.
Is there anything more that IPv6 MLD would do other than what the IGMP-Proxy already does for IPv4? E.g., something that would make it more suited to allow multicast traffic and mDNS discovery to traverse a subnet/vlan boundary?

I think you should ask for proper documentation from MikroTik.
1. Proper documentation for IGMP Proxy (IPv4, what it does, can't do for inter-VLAN)
2. Proper documentation and support for MLD Proxy (IPv6, what it does, can't do for inter-VLAN)

For those interested, i created an extended container image based on the github repo and a setup script which simplifies the mDNS repeating setup:

Mikrotik: mDNS Repeater as Docker-Container on the Router (ARM,ARM64,X86) (english version)
Mikrotik: mDNS Repeater als Docker-Container auf dem Router (ARM,ARM64,X86) (german version)

I was able to get this functioning, however, I cannot get it to work as my default LAN (192.168.1.0) does not have a tag so it does not grab an IP from this subnet. How would I go about doing this without breaking the network?

hi everyone, I read somewhere here that mDns forwarding will be available as part of DNS overhaul change in the future ROS, is that true?

thanks

I was able to get this functioning, however, I cannot get it to work as my default LAN (192.168.1.0) does not have a tag so it does not grab an IP from this subnet. How would I go about doing this without breaking the network?

It is simple.

1. Get shell access in the container: /container/shell 0
2. Edit /app/run.sh: vi /app/run.sh
3. Modify line "exec /bin/mdns-repeater -f $ALLVLANIF" to "exec /bin/mdns-repeater -f eth0 $ALLVLANIF"
4. Save and restart container

In my configuration example, I have one router and an L2 switch connected to it for Wi-Fi, keep that in mind:

Code: Select all

<snipped>

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.

Thanks for the detailed example.

I know you have already answered the question, but I don't quite get it: why use a loopback device as the upstream of the IGMP proxy, instead of a regular or VLAN interface?

In fact, I would have thought that using a loopback bridge as the upstream for the IGMP proxy would not work. For example, if I have the following (simplified) topology:

Printer Network <192.168.100.0/24> -> (ether1) ROS (ether2) <- Computer Network <192.168.101.0/24>

mDNS announcements from the printer network would reach ether1 at the router and be dropped because ether1 is not marked as upstream (!) if you used a loopback as upstream instead, wouldn't they?

I stopped using IGMP Proxy. I migrated to PIM, it works and I stopped worrying. You need ROS v7.11.2 in my testing.

Here:
viewtopic.php?t=198798#p1022915

do we have any update from Mirktotik re adding mDNS support officially? I do believe they mentioned somewhere that DNS is getting complete rework done and mDNS will be part of it as well??

I suspect @DarkNate is right here...

I migrated to PIM, it works and I stopped worrying. [...]
viewtopic.php?t=198798#p1022915

I think IGMP Proxy may ignore mDNS's IP 224.0.0.51/24 since defined as "Local Network Control Block" in RFC-5771

Addresses in the Local Network Control Block are used for protocol
control traffic that is not forwarded off link. Examples of this
type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].

It's ironic that PIM is easier, but there be less complex than the ill-defined IGMP Proxy....

I suspect @DarkNate is right here...

I think IGMP Proxy may ignore mDNS's IP 224.0.0.51/24 since defined as "Local Network Control Block" in RFC-5771

It's ironic that PIM is easier, but there be less complex than the ill-defined IGMP Proxy....

IGMP Proxy was never really a “best practices” or an industry-wide accepted method and never standardized to my knowledge, which means, different vendors do it differently, so it's usually half-baked.

PIM on the other hand is a well-defined standard:
https://www.rfc-editor.org/rfc/rfc7761.html

I'm having absolutely no success with getting chromecast to work. Read the entire thread, followed posted examples, not working

First question which may answer why its not working: Does all multicast traffic need to be in the same 'bridge' for PIM or IGMP Proxy to work?
I've been testing with a lab router using a more appropriate config for the actual environments i'd want to use this in, which is a more complicated topology that isn't just VLAN's on a single bridge. They're either 1 or more physical interfaces or multiple bridges
Theoretically I don't see why it should matter, yet its just not working

Here is the full config of a simple hAP AC2 lab (ROS v7.11.2) used for testing purposes, with topology as follows
ether2 and wlan2 are in bridge1 (this is where the chromecast is connected)
ether3 and wlan3 (virtual AP on wlan2) are in bridge2 (this is for testing multicast routing, connect phone here)
As expected everything works properly when connected to wlan2/mcasttest_1 as its in the same L2 segment
when joining wlan3/mcasttest_2 then can't see the chromecast

Have also tried IGMP Proxy instead of using PIM which also does not work and have no success

I've been testing with a lab router using a more appropriate config for the actual environments i'd want to use this in, which is a more complicated topology that isn't just VLAN's on a single bridge.

You're violating the Linux DSA network stack by having multiple bridges. Multiple bridges is a concept that has been depreciated with the introduction of VLAN aware bridging, migrate to proper single bridge configuration. Your topology is improper if you can't do it with single bridges and VLAN awareness.

viewtopic.php?p=1024789#p1024575

https://help.mikrotik.com/docs/display/ ... plebridges

Have used multiple phones and found this to be woefully unreliable, some it works and others it just does not work whatsoever. Multicast routing itself seems to work but evidently multicast routing alone its not the only thing required for chromecast streaming to work 100% of the time (am testing with other multicast software which is working no issue). The chromecast just does not show up the majority of the time with most devices unless situated on the same L2 segment (in which case it works flawlessly)

mDNS Repeating would absolutely be a worthwhile implementation, as using Avahi to do mDNS repeating instead of multicast routing then it does actually work as expected. The real 'problem' is googles home based implementation that is hell bent on not working with any sort of corporate network, as evident by having a TTL of 1 on its discovery protocol.
The way I see it mDNS repeating is a good solution to a problem that exists in the real world). This is how other vendors have made it work and it solves the issue in a reliable way

You're violating the Linux DSA network stack by having multiple bridges. Multiple bridges is a concept that has been depreciated with the introduction of VLAN aware bridging, migrate to proper single bridge configuration. Your topology is improper if you can't do it with single bridges and VLAN awareness.

viewtopic.php?p=1024789#p1024575

https://help.mikrotik.com/docs/display/ ... plebridges

sorry, off-topic but ... an additional empty bridge "Lo0" for example would not violate that, right? (for loopback addressing)

I really wouldn't worry about it, if there is a valid use case (practical management is absolutely a viable one) then by all means use multiple bridges. If its just a home based setup with multiple VLAN's sure single bridge is a good idea. However as with everything it depends on the use case. Often it can be more practical and sensible to just use more than 1 bridge, i.e. template based configurations with varying topologies. When your physical port assignments vary greatly then it makes more sense to put Firewall/DHCP/Addressing/etc onto a bridge interface, then assign ports to that bridge as required. If the goal is network segregation and the traffic is still hitting the CPU anyway then it arguably doesn't matter
If you setup to specific interfaces you need to move all the relevant entries around constantly on every deployment, and if you need need i.e. 2 physical ports in the 'Staff A' network and 3 in the 'Services B' network (both untagged and/or with overlapping VLAN numbers) at the location of the router, then you either need to add physical switches just to break out those extra ports or setup VRF's. If it makes you feel all warm and fuzzy go for it, but if simply using multiple bridges makes everything simpler, easier to read/visualize/troubleshoot and still accomplishes the same result, by all means use multiple bridges

And yes zero issues with an empty bridge as a loopback interface. There are bigger problems in the world to worry about

sorry, off-topic but ... an additional empty bridge "Lo0" for example would not violate that, right? (for loopback addressing)

Loopback is fine, I have single bridge for physical ports/LACP/The works, and separate bridge with STP disabled for loopback.

But in some cases, such as MPLS/VPLS use-cases, you might be forced to use two bridges for physical ports, VPLS tunnels, but still, if you use VLAN filtering, single bridge should be enough for all possible use-cases that rely on Ethernet standard.

In the future, when Ethernet is surpassed by something else, the story may differ.

I really wouldn't worry about it, if there is a valid use case (practical management is absolutely a viable one) then by all means use multiple bridges. If its just a home based setup with multiple VLAN's sure single bridge is a good idea. However as with everything it depends on the use case. Often it can be more practical and sensible to just use more than 1 bridge, i.e. template based configurations with varying topologies. When your physical port assignments vary greatly then it makes more sense to put Firewall/DHCP/Addressing/etc onto a bridge interface, then assign ports to that bridge as required. If the goal is network segregation and the traffic is still hitting the CPU anyway then it arguably doesn't matter
If you setup to specific interfaces you need to move all the relevant entries around constantly on every deployment, and if you need need i.e. 2 physical ports in the 'Staff A' network and 3 in the 'Services B' network (both untagged and/or with overlapping VLAN numbers) at the location of the router, then you either need to add physical switches just to break out those extra ports or setup VRF's. If it makes you feel all warm and fuzzy go for it, but if simply using multiple bridges makes everything simpler, easier to read/visualize/troubleshoot and still accomplishes the same result, by all means use multiple bridges

And yes zero issues with an empty bridge as a loopback interface. There are bigger problems in the world to worry about

I see another user here, is not well versed with Linux netfilter and Linux DSA

A lot of these people came from Unix/BSD oriented pf networking such as traditional Cisco, Juniper etc, that dates back to the early 90s and 2000s, where you can have multiple IRBs aka Linux bridge alternative with no problem as long as the specific hardware model is designed with an ASIC that can carry said multiple IRBs.

The same people proactively refuse to educate themselves on Linux Netfilter framework and DSA from scratch and catch up to modern-day 2023 networking where even Cisco's IOS variants and Juniper's Junos Evolved is 100% Linux.

Single bridge is mandatory for production use-cases to ensure proper hardware offloading when there's an ASIC across all ports, and if no ASIC to ensure CPU fast-path across all ports, read these:
https://docs.nvidia.com/networking-ethe ... idge-Mode/

https://docs.kernel.org/networking/dsa/dsa.html

https://docs.bisdn.de/network_configura ... %20bridges

https://developers.redhat.com/articles/ ... N%20filter

Do some reading here for MikroTik-specific and also do your own research Marvell ASICs functionality and bridge capabilities on Linux.
https://help.mikrotik.com/docs/display/ ... plebridges

multiple bridges may lead to undefined behavior.

If you're well-connected in the merchant silicon industry, sign an NDA with Marvell, Broadcom, or Nvidia/Mellanox and see for yourself internally, there's no way of NOT doing single bridge-only to ensure 100% clean hardware offloading without incurring computational costs or financial costs of manufacturing such ASICs.

sorry, off-topic but ... an additional empty bridge "Lo0" for example would not violate that, right? (for loopback addressing)

Loopback is fine, I have single bridge for physical ports/LACP/The works, and separate bridge with STP disabled for loopback.

But in some cases, such as MPLS/VPLS use-cases, you might be forced to use two bridges for physical ports, VPLS tunnels, but still, if you use VLAN filtering, single bridge should be enough for all possible use-cases that rely on Ethernet standard.

In the future, when Ethernet is surpassed by something else, the story may differ.

thank's for summing this up - so my understanding was right in the first place here.

But in some cases, such as MPLS/VPLS use-cases, you might be forced to use two bridges for physical ports, VPLS tunnels, but still, if you use VLAN filtering, single bridge should be enough for all possible use-cases that rely on Ethernet standard.

Indeed, the single-bridge design cannot be used in conjunction with BGP VPLS (viewtopic.php?p=925249#p925249).

Indeed, the single-bridge design cannot be used in conjunction with BGP VPLS (viewtopic.php?p=925249#p925249).

MikroTik needs to give proper solution for this. Maybe contact support?

What about option two here:
viewtopic.php?p=925249#p845362

I contacted support about this issue and they responded that they will consider improving the behavior for VPLS when they are added to the bridge and VLANs are used.

I contacted support about this issue and they responded that they will consider improving the behavior for VPLS when they are added to the bridge and VLANs are used.

I would like to remove VPLS permanently and replace it with EVPN and make use of Ethernet Segment Identifiers, but alas, MikroTik supports none.

Changelog

What's new in 7.16beta3 (2024-Jun-27 08:33):\

*) dns - added support for mDNS proxy (CLI only);