Bonjour/ZeroConf/Rendezvous/mDNS across multiple subnets
Avahi, Zeroconf, mDNS, Bonjour, whatever you want to call it, is great for dealing with service discovery on your LAN where all hosts are located in the same broadcast domain. Indeed, the zeroconf protocol relies heavily on multicast for advertising and discovering services.
Sometimes, however, it is not possible to have a flat configuration and you have built different subnets for administrative purposes. Still, you think it would be cool to have services advertised by machines on a given subnet, available to machines on any other subnet.
One way of dealing with this is to use multicast routing and have your interconnection equipment pass multicast traffic from one subnet to another around your organisation. The zeroconf protocol uses only a few group addresses so this is not a big hassle to implement.
However, routing multicast is not always possible. As crazy as it may seem, even in the 21st century, some routers or wireless access points don’t support multicast routing :( Furthermore, as pointed out by one of the comments to this post, mDNS uses multicast groups which’s scope is limited to the local subnet and thus, even with multicast routing it wouldn’t work across subnets. In this case, another solution that exists is the use of service proxies.
A zeroconf proxy is a server software that will advertise services which are not hosted on the same machine. In this way, you could have one machine on subnet 1 advertising all the services that are provided by machines on subnet 2 and vice-versa.
For OS X there is the excellent network beacon from chaotic software available which should help you solve almost any problem with subnets and bonjour, zeroconf.
When it comes to linux, the avahi deamon is the way to go, twenty seconds, a simple file in /etc is all it takes to advertise a service.
On Windows on the other hand, the search can be quite longer. Indeed, you might find Rendezvous Proxy from iLeech to be quite nice until you start playing with multi-field TXT records (for any elaborated service such as Airfoil Speakers for example). At that point you’ll find out it is broken and generates malformed packets so you’ll search a little more and eventually come across a google code project named Bonjour Beacon and voilà, you’re all set!
To summarize a long post, bonjour, rendezvous, zeronconf, avahi, mDNS are the name of the protocol and the software implementations of it but they all do the same thing (and play nice with one another).
If you subnet, you have to use a proxy for services on one subnet to get advertised on another one (the protocol uses a link local multicast address).
Good proxies are, avahi on Linux, Bonjour Beacon on Windows and network beacon on OS X.
Tags: networking zeroconf
nice sharing, thank you.
Basically going through the above blog post we like it because it is reality and it is great.
Hi, thanks for that blogpost. But one question: How to find out which type of service and protocol my AirPlay-Receivers on the other subnets have? Bonjour Beacon says in it’s documentation anything about _airfoilspeaker._tcp./5000
but i think it could also be _raop._tcp./49152
I don’t know over which tool i can find out that. I have a Pioneer VSX-921 as AirPlay-Receiver and a Raspberry Pi.
Thank you for your comment, you can use Wireshark to capture a working mDNS request/response transaction on your LAN. Wirehsark has a good dissector for mDNS so you can use that to see what is actually advertised. _airfoilspeaker._tcp./5000 is what Airfoil Speaker (an Airplay compatible receiver) uses. _raop stands for Remote Audio Output Protocol, that’s how Airplay devices advertise themselves to iTunes among others. I see the Pioneer VSX-921 supports DLNA, that could also be a way to go if you use a RPi as the source.
Thanks for the great info.
I realise this is a few years old, but would like to correct the points about multicast routing.
Bonjour/Zeroconf/mDNS use the multicast address 224.0.0.251 to advertise services to the local subnet. This address range is classed in multicast as link-local or local subnet only addressing – it isn’t routable regardless of the capabilities of your switches/routers. See http://en.wikipedia.org/wiki/Multicast_address#Local_subnetwork
Advertising the information to other subnets requires a proxy on the local subnet to forward the requests to the mDNS server on the remote subnet.
The answers you provided for this are great, I’m just trying to stop network guys getting bashed for an application issue….
Thank you for your comment and the information you provide, I’ve updated the post to reflect that multicast routing is never going to be a solution given the use of a link local address in mDNS protocol definition