2012
Sep 20

As I’ve written about in the past (here), Apple’s AirPlay technology relies on Bonjour which is Apple’s implementation of “zero config” networking. One of the things that Bonjour enables is the automatic discovery of services on the network. For example, an Apple TV might advertise itself as being able to receive AirPlay streams. An iPad that is looking for AirPlay receivers would use Bonjour to discover the Apple TV and present it to the user as an AirPlay destination. Both the Apple TV and iPad do all this without any user intervention or configuration (hence the “zero config” part).

That’s fine and dandy but what my earlier article focused on was how Bonjour broke down in a network where what I’ll call the “server” and the “client” are not in the same Layer 2 domain/VLAN. This is because the service discovery aspect of Bonjour relies on link-local scope multicast. These packets will not cross Layer 3 boundaries in the network.

Bonjour packets will not pass a Layer 3 boundary

What’s needed to make Bonjour work across subnets is a proxy that can take the service announcements on one subnet and announce them on the other(s) (and vice-versa). What’s perfect about this is that service discovery works just like DNS. In fact, it is DNS: multicast DNS (mDNS). The DNS system provides a lookup service that sits out of band of the actual traffic flow. mDNS is exactly the same. The mDNS proxy will need a leg into each subnet where AirPlay clients and servers live, but it does not have to relay traffic between the subnets. It’s merely the lookup mechanism. The reason I’m stressing this concept is because it means that the mDNS proxy can be deployed in the network without changing the network architecture. It also does nothing to change security zoning, doesn’t affect the resiliency of the network and doesn’t create a bottleneck for network traffic. It’s a very simple way to address the need (demand?) for AirPlay in a business network. Eventually all the Wi-Fi vendors will have this kind of thing built into their products but for now, this gives the IT Network team the ability to say “yes, our network can support AirPlay”.

The software I’ve used as an mDNS proxy is called Avahi. It appears to be the defacto open source software for service discovery and mDNS services. Yeah that’s right, you can use it to advertise the services that are running on the local box (SSH, HTTP, etc). But what’s really interesting is the setting that enables the “reflector” functionality.

[reflector]
enable-reflector=yes

This little knob in avahi-daemon.conf turns Avahi into an mDNS proxy where it will pick up service advertisements received on one interface and send them out on any other interface where a discovery query is received. The list of participating interfaces can be restricted using the allow-interfaces knob.

[server]
allow-interfaces=vlan10,vlan20

Bonjour packet flow with Avahi

As the diagram illustrates, this is the packet flow now between the iPad and the Apple TV:

  1. Apple TV advertises itself as an AirPlay receiver using Bonjour’s Service Discovery mechanism
  2. Since the Avahi server is connected to the same VLAN as the Apple TV, it hears the advertisement and stores the details in its database
  3. The iPad uses Service Discovery to try and locate an AirPlay receiver on the network
  4. Since the Avahi server is also connected to the same VLAN as the iPad, it hears the discovery and responds with the information for the Apple TV
  5. Within the response from Avahi, the iPad will learn the IP address and port that it should connect to the Apple TV on. The iPad will initiate a direct connection to the Apple TV

Avahi is a really lightweight piece of software. It can run on a small UNIX machine — physical or virtual — and handle discovery messages on multiple VLANs. Avahi is present in all the major Linux distributions and in the OpenBSD and FreeBSD ports collections.

Go run it.

Disclaimer

The opinions and information expressed in this blog post are my own and not necessarily those of Cisco Systems.

45 Comments

  1. By Frank Denis (@jedisct1) on Sep 20, 2012 at 10:24am MST |

    RT @knight_joel: {blog} AirPlay, VLANs, and an Open Source Solution – Get Bonjour working across Layer 2 domains http://t.co/uctxelXK

  2. By @troymart on Sep 20, 2012 at 5:20pm MST |

    RT @knight_joel: {blog} AirPlay, VLANs, and an Open Source Solution – Get Bonjour working across Layer 2 domains http://t.co/t3Yk4G5v

  3. By @damacus on Sep 20, 2012 at 10:27pm MST |

    RT @knight_joel: {blog} AirPlay, VLANs, and an Open Source Solution – Get Bonjour working across Layer 2 domains http://t.co/t3Yk4G5v

  4. By Angelo Luciani (@AngeloLuciani) on Sep 22, 2012 at 9:45am MST |

    AirPlay, VLANs, and an Open Source Solution http://t.co/8cJVPxYa (via @knight_joel)

  5. By @SVvmug on Sep 23, 2012 at 11:18am MST |

    AirPlay, VLANs, and an Open Source Solution http://t.co/aqOBs9J5 (via @knight_joel)

  6. By Toronto VMUG (@TorontoVMUG) on Sep 23, 2012 at 5:14pm MST |

    AirPlay, VLANs, and an Open Source Solution http://t.co/ZD7tdE0E (via @knight_joel)

  7. By AirPlay in an Enterprise Setting « Beep Boop on Jan 28, 2013 at 2:22pm MST |

    [...] as possible, but in the mean time, here are a couple of articles touching on the subject from packetmischief.ca and Prolixium dot [...]

  8. By @selric on Feb 24, 2013 at 8:06am MST |

    Nice
    http://t.co/AizCEvwaiL

  9. By @ExtremeNetworks on Feb 24, 2013 at 8:55am MST |

    RT @selric: Nice
    http://t.co/AizCEvwaiL

  10. [...] rooms and sound booths for AirPlay from iOS devices and recent Macs. AirPlay works great — even across VLANs — if you have your network set up [...]

  11. By Managing 40 Apple TVs in education | TechKudos on Mar 3, 2013 at 1:09pm MST |

    [...] rooms and sound booths for AirPlay from iOS devices and recent Macs. AirPlay works great — even across VLANs — if you have your network set up [...]

  12. By iPhone Droids – Latest in Mobile on Mar 3, 2013 at 1:48pm MST |

    [...] rooms and sound booths for AirPlay from iOS devices and recent Macs. AirPlay works great — even across VLANs — if you have your network set up [...]

  13. [...] rooms and sound booths for AirPlay from iOS devices and recent Macs. AirPlay works great — even across VLANs — if you have your network set up [...]

  14. By Managing 40 Apple TVs in education | iPhone 4 everyone on Mar 3, 2013 at 3:43pm MST |

    [...] rooms and sound booths for AirPlay from iOS devices and recent Macs. AirPlay works great — even across VLANs — if you have your network set up [...]

  15. By Managing 40 Apple TVs in education | Gadget Tech on Mar 3, 2013 at 4:21pm MST |

    [...] rooms and sound booths for AirPlay from iOS devices and recent Macs. AirPlay works great — even across VLANs — if you have your network set up [...]

  16. By @lindertobias on Mar 9, 2013 at 1:43pm MST |

    AirPlay, VLANs, and an Open Source Solution | packetmischief.ca http://t.co/z5998anjL1 (via Instapaper)

  17. By Mike on Feb 17, 2014 at 1:33pm MST |

    Thank you for this excellent solution. I implemented this at a High School segmented into 12 wired VLANs and 4 wireless. Since I am using Microsoft Hyper-V to run Avahi, I had to create two Avahi servers to connect all of the VLANs (Hyper-V) has a limitation of 12 virtual ethernet interfaces per VM). Now everything works great, but I fear that the two servers are echoing each other’s broadcasts, since they share the wireless VLANs. What can be done to remedy this?

    • By Joel Knight on Feb 17, 2014 at 8:04pm MST |

      Hey Mike, thanks for the feedback. Have you considered giving your VM a single vNIC (sorry, I don’t know the HyperV term for the guest NIC) and tagging your VLANs all the way to the VM? You would end up with a VM-on-a-stick instead of a multi-legged VM.

  18. By Chris on Apr 3, 2014 at 9:23am MST |

    Can a single computer with a Single NIC be used? if so how would you configure the NIC and the Port on a 2960G cisco switch.

    • By Joel Knight on Apr 7, 2014 at 8:36pm MST |

      Hey Chris,

      Yes, a single NIC would work as long as you’re able to do VLAN tagging (802.1Q) on the NIC of your Avahi box. You’d create one VLAN interface for each of the VLANs you want to exchange Bonjour messages between. The configuration for this is going to be up to whatever OS you’re running; they’re all different.

      On the Catalyst you’d do something like this:

      conf t
      interface gigX/Y
      description To Avahi box
      switch trunk encap dot1q
      switch mode trunk
      spann portfast trunk

  19. By David Fung on Jun 3, 2014 at 10:43pm MST |

    Hi,

    Sorry, based on the above link (http://avahi.org/) redirection, I can’t locate the Avahi open source software. Do you know where I can download it?

    Thanks!

    • By Joel Knight on Jun 4, 2014 at 7:31pm MST |

      Hmm, looks like their site is off air. I don’t know of any other official site or mirror. Most of the Linux distros and the BSDs all have binary packages though. Have you tried that?

  20. By David Fung on Jun 7, 2014 at 1:03am MST |

    Thanks. I will try other Linux OS.

  21. By Niko K on Jul 22, 2014 at 6:18pm MST |

    Hi Joel, this is an awesome post! I tried using the idea and apply it to VPN. I have a device with two NICs and also acts as a router gateway and VPN server.

    I have avahi running properly on the device with reflecting turned on. I also see in the logs that avahi successfully registers eth0 (internet), eth1(lan) and ppp0 (my machine VPNed in) for mDNS pooling.

    But still no dice! iOS device that is in eth1′s network cannot see the AirServer I have running on my laptop that is VPNed in through ppp0.

    Just as extra info:
    my laptop can ping addresses in eth1.
    addresses in eth1 have internet traffic routed properly through eth0.
    VPN technology is PPTP.
    System logs says that avahi says: “avahi-daemon[1540]: Invalid query packet.” Is that the query from the iOS device asking for an AirPlay server?

    In any case, I’m at the end of my wits now and was hoping maybe you could give a tip or two to get through this!

    Thanks!

    Niko

    • By Joel Knight on Jul 23, 2014 at 9:48am MST |

      Thanks Niko!

      What does the output of “avahi-browse -at” look like? (I think that’s the right command. Maybe avahi-browse -ac?)

      My first thought is that multicast is not passing on your PPTP link and Avahi has nothing in its cache to reflect on the eth1 LAN interface. If memory serves, I too get that invalid query packet message from time to time. I chalked that up to Avahi falling behind a little bit with respect to the current versions of the AirPlay protocol, but I never chased it down or dug into it.

      • By Niko K on Jul 23, 2014 at 11:01am MST |

        Hi Joel

        I think your hunch is valid, before and after I connected via PPTP VPN the avahi-browse -ac and -at both showed only devices from the eth1 interface, no devices from ppp0.

        This is despite the fact that after connecting via PPTP VPN the system logs shows this:

        Joining mDNS multicast group on interface ppp0.IPv4 with address 192.168.1.37.
        daemon.info avahi-daemon[2007]: New relevant interface ppp0.IPv4 for mDNS.
        daemon.info avahi-daemon[2007]: Registering new address record for 192.168.1.37 on ppp0.IPv4.

        To test your hunch, I will VPN my iPhone which for sure broadcasts AirPlay multicast (as opposed to AirServer which is a 3rd party app on my macbook pro) and then re-examine the avahi-browse -ac, -at outputs… OK just did the test and same results, outputs only show eth1 devices.

        Not sure if relevant but when connecting through PPTP VPN the IP address that the devices is configured to give to the connecting client (on pppX) is from the same subnet that eth1 has (192.168.1.X)

        Here is a sample log of when I connect via PPTP VPN:

        daemon.notice pppd[10158]: Connect: ppp1 /dev/pts/2
        daemon.notice pppd[10158]: local IP address 192.168.1.36
        daemon.notice pppd[10158]: remote IP address 192.168.1.38

        This is with my laptop already connected (ppp0) and given IP of 192.168.1.37…

        • By Joel Knight on Jul 23, 2014 at 12:13pm MST |

          If you plug your laptop into the LAN and look at avahi-browse -ac/-at, do you see the AirPlay service showing up?

          • By Niko K on Jul 24, 2014 at 4:57pm MST |

            yes I do! on the correct interface too, eth1.

            • By Joel Knight on Jul 24, 2014 at 7:12pm MST |

              Ok, that would indicate to me that multicast is not being passed on your PPP interface.

              • By Niko K on Jul 25, 2014 at 4:16pm MST |

                Yes that does seem to be the case. Kind of discouraging since the config file has an option for allow-point-to-point and I set it to ‘yes’ which resulted in it adding and registering the ppp0 interface.

                No idea why it would not go just one more step and actually hear the PPP broadcast. Maybe its a setting on my laptop I need to look at then, if it is choosing not to broadcast on a ppp interface

  22. By Bob on Jul 28, 2014 at 8:40am MST |

    Quick question: Would this work for 3 VLANs? For example if I have VLANs 1,2,3. Traffic is enabled between VLANs 1 and 2, and 1 and 3 (2 & 3 can’t communicate). Can I put the RPi on all three VLANs and airplay from devices on VLAN 2 or 3 to a receiver on VLAN 1? Thanks!

    • By Joel Knight on Jul 28, 2014 at 9:22am MST |

      Hi Bob,

      I’m not sure what you mean by RPi so I hope I’m not confusing things, but yes, you can run Avahi on all three VLANs and services will be reflected from each to the other two.

      I’m not sure if it’s possible to tell Avahi not to reflect between VLANs 2 and 3. By default, if you have a player in VLAN 2 and 3 and you also had a receiver in say VLAN 3, that receiver would see the player in VLAN 2 as well as the player in VLAN 3. That might be confusing to users if you don’t allow traffic from 3->2.

      Hope this helps! Thanks for reading.

    • By ebob9 on Jul 28, 2014 at 4:59pm MST |

      I think this would be possible with 2 Avahi proxies – one between VLAN 1 & 2, and one between VLAN 2 & 3.

      We’re planning on trying something similar for security. Basically, we want to set up an “Airplay DMZ” that will allow people from the “Office Network” and people from the “Wireless Guest Network” to both see and Airplay to the same set of AppleTVs. In our case, the “AirPlay DMZ” would be VLAN 2, with VLAN 1 and VLAN 3 not being able to see or reach resources in each other.

      • By Joel Knight on Jul 28, 2014 at 8:01pm MST |

        Wouldn’t the two Avahi boxes connected to VLAN 2 end up reflecting services from their non-DMZ VLANs to each other?

        I’m struggling to remember all the details but if you’re a Cisco shop, IOS and the WLC both have features in them for selectively allowing Bonjour between VLANs. It may have enough features to allow you to do what you want natively in the network. You probably want to look at fairly recent code.

  23. By Niko K on Jul 28, 2014 at 7:12pm MST |

    RPi = raspberry pi!

  24. By egoff on Aug 11, 2014 at 9:58pm MST |

    I’ve gotten Avahi working to enable AirPlay and Mac OS X printer sharing among 3 VLANs. It works fine except for one extremely annoying problem: intermittently, Apple devices will decide that there’s another machine on the network with the same name, so they change their name by adding a number at the end: “mymac” becomes “mymac (2),” or “Fred’s Apple TV” becomes “Fred’s Apple TV (2)”. Even the name of a shared printer on a Mac OS X Server machine may change, from “hp printer @ macserver” to “hp printer @ macserver (2)”; if you’ve added a printer on a Mac with the original name, then if the printer’s Bonjour name changes, you can no longer print to it. Any idea why this might be happening and what to do to stop it?

    • By Joel Knight on Aug 12, 2014 at 7:18am MST |

      Hi egoff,

      This happens to me too and I’m not sure what causes it. My assumption is that it’s Avahi doing it because it believes there’s two devices on the network with the same name so it adds a number the the newest one. In my network, this happens a lot with a particular Apple TV that gets powered on and off a lot. I wonder if restarting Avahi or even just clearing its cache would resolve this?

      • By egoff on Aug 12, 2014 at 9:48am MST |

        It would be a cosmetic issue, except that it renders OS X shared printers unusable. I’ve assumed it was the devices changing their own Bonjour names, since just stopping Avahi doesn’t resolve it. My Apple TVs and Mac laptops that have added numbers to their names have held onto the new names, and I’ve had to stop Avahi and then restart print sharing in OS X Server to get a shared printer to revert to its original name. I’ve seen a few forum posts saying it’s a bug in Avahi, and nothing’s been done to Avahi since early 2012… I’m getting desperate for some kind of solution that actually works. I tried setting up mdns on an AD DNS server, but it’s a pain to set up, and once I started publishing services, OS X clients seemed to go blind to everything except what’s advertised on the DNS server.

        • By Joel Knight on Aug 12, 2014 at 10:41am MST |

          Sorry man, wish I had better advice. If you do find a remedy, myself and others would appreciate if you posted the info here.

          • By egoff on Aug 12, 2014 at 12:16pm MST |

            Well…maybe I’m jumping the gun, but it seems to be behaving now, after setting cache-entries-max=0 in /etc/avahi/avahi-daemon.conf. That kind of makes sense, since we don’t want it to cache anything, just reflect. I was able to trigger the problem by printing to a shared printer from a Mac with 2 network interfaces connected to 2 Avahi-enabled VLANs at the same time. Now with cache-entries-max=0 in place, I can no longer get the problem to happen. We’ll see if that did it. Thanks for the cache hint!!!

            • By Joel Knight on Aug 12, 2014 at 9:36pm MST |

              I just made the same change. Watching now to see if there’s any difference in behavior. Do you notice that “avahi-browse -at” shows no output now?

              • By egoff on Aug 14, 2014 at 2:49pm MST |

                Hmm, I didn’t notice that, but my only objective is connecting iPads, MacBook Pros, Apple TVs, and Mac-shared printers across subnets. With caching turned off, Avahi seems to be working perfectly for that now, and no longer doing any of the destructive things it was doing before.

  25. By @spuk_o0 on Aug 14, 2014 at 8:53pm MST |

    http://t.co/XsUJo3XAWA <- como usar o Avahi pro Airplay da AppleTV funcionar entre sub-redes diferentes

  26. By Peter on Aug 25, 2014 at 8:38pm MST |

    Hi Joel,

    Thanks a lot for your article! I was trying to get AirPlay working between VLANs today, but I didn’t succeed. I’m sure I just forgot something… Here’s my setup:

    Ubuntu 14.04 VM on ESXi host, 2 virtual NICs (one on std. VLAN 1 [192.168.111.0/24], the other one on VLAN 20 [10.20.0.0/24]). Avahi and Avahi-Utils installed, reflecting is on and allowed-interfaces is set to eth0 and eth1. The VM is reachable from within both subnets and gets its addresses via dhcp from our watchguard router.

    We have an Apple TV on VLAN 20, and so far only clients in the same VLAN can successfully connect to it. When in VLAN 1, clients can discover and “see” the Apple TV on VLAN 20, thanks to the VM, but it errors out when they try to connect to it.

    Any clues? Do I need to set up routing for the actual traffic between the subnets?

    Thanks a lot,
    Peter

    • By Joel Knight on Aug 31, 2014 at 1:28pm MST |

      Hi Peter!

      Is the Watchguard the default gateway for hosts in vlans 1 and 20? If so, I suspect that the firewall policy is not allowing the Airplay traffic to cross between the VLANs.

      It can be a little confusing, but the way this works is the Avahi box reflects the Airplay announcements between the VLANs (thereby bypassing the firewall). Then when an iDevice tries to connect to an Airplay source, that traffic is actually sent towards the Watchguard (and not through the Ubuntu host). Because of that, the Watchguard will need to be configured to allow Airplay between the VLANs.