First, a little background on Apple’s “Bonjour” protocol is in order. Then I’ll get to the good stuff:
Apple’s iOS devices (iPhone, iPad, Apple TV) use their “Bonjour” protocol to discover and set up communications between each other. This is Apple’s version of “Zero Configuration Networking”, which allows devices to communicate with each other on a network without an administrator having to configure each device. This is the magic that makes Apple products “just work” when it comes to connecting your iPad to your Apple TV to display video, or to connect your Mac computer to that shiny new wireless printer you just bought.
However, this magic comes with some limitations.
Specifically, it’s meant to be used on small, uncomplicated networks, like the wireless networks we have at home. There you’ve got one wireless router that not only handles the handful of wireless devices you have, but it also has some network jacks on it that lets you plug a couple “wired” devices into the network, like the desktop computer in the family room or the network hard drive you just got. Nothing complicated, nothing weird, just a regular home network. Apple’s Bonjour protocol works great here, and your Apple devices all talk to each other with no problems.
For Apple’s largest target audience, the home user, this is perfect. For enterprise-level users however, there’s one big issue. Most enterprise wireless products are configured so that each wireless network is separate from the others, on it’s own VLAN and with it’s own unique range of IP addresses, for security and performance reasons. Bonjour is a link-local multicast protocol, and by design, Bonjour queries and advertisements are sent to the local subnet only. This means that if you have a wireless network named “Staff”, then only devices connected to that network will be able to communicate with each other. An iPad on the “Guest” wireless network will not be able to communicate with an Apple TV on the “Staff” network.
For some, this isn’t a huge problem. If all your devices are going to be on the same network, then they’ll talk to each other just fine. However, a lot of businesses, mine included, have these devices all throughout their network and need them to be able to communicate with each other.
Cisco has a support document named “Wireless LAN Apple Bonjour Deployment Guide”, which contains a few different methods that network administrators can use to allow Bonjour traffic to move between networks so that the devices can talk to each other. Towards the end of the document, in the section labeled “Bonjour Gateway Deployment”, they mention the open-source Avahi mDNS gateway, which runs on Linux. It’s the configuration of this system that I wanted to talk about in this post, as I had some issues with Cisco’s configuration instructions and ended up coming up with a different approach that ended up working for me.
THE GOOD STUFF:
Told you I’d get here.
Anyway, Cisco’s instructions tell you to install the Avahi Daemon and VLAN packages, and then use this command to add additional ethernet interfaces that are bound to a specific VLAN:
ubuntu@ubuntu:~$ sudo vconfig add eth0 20
Added VLAN with VID == 20 to IF -:eth0:-
The Avahi mDNS gateway daemon looks at traffic on all the network interfaces you’ve got configured on the host system and allows that traffic to move between all those interfaces. By running the command above, you’re creating a new interface for each VLAN, which Avahi will automatically start looking at once that interface gets an IP address, which is the next step.
You’re then instructed to run another command for each of these new interfaces (the interface created in the above example will be “eth0.20″) so that they get their IP address via DHCP:
ubuntu@ubuntu:~$ sudo dhclient eth0.20
It’s at this point where things break down for me. I issue that command and nothing happens for the next few minutes. At some point (I’ve not timed it exactly) it gives up trying to get an IP address from my DHCP server and gives me back the command prompt. After double-checking the port configuration on my switch and making sure I didn’t miss any steps in the instructions, I gave up and put it to the side for a while.
After coming back to it an hour or so later, I decided to create the new network interfaces a different way. This is an installation of Ubuntu Desktop 12.04 LTS, and it’s running as a virtual machine in Microsoft Hyper-V 2012. Microsoft’s Linux Integration Services are already a part of Ubuntu, which means that as soon as you install it into your virtual machine it’ll recognize any synthetic network adapters you’ve configured for that virtual machine. I powered the VM down and added two additional network adapters to it, each one having the “Enable virtual LAN identification” box checked, and the appropriate VLAN number entered into the box. I saved the VM’s settings and powered it back on. When Ubuntu came back up I went into the network settings menu and there were two new network interfaces there. A quick trip into Terminal and an “ifconfig” command showed that the two new interfaces (eth1 and eth2) were each getting a correct IP address from the DHCP server range for their VLANs.
At this point, the Avahi mDNS gateway started matching Bonjour queries on VLAN 300 to advertisements on VLAN 70 and vice-versa. I’m now able to run the “Reflector” app on my desktop machine on VLAN 90 and have my iPad on VLAN 300 see it as an available AirPlay Mirroring target. Success!
What I know about Linux would fill a thimble. It’s entirely possible that I missed some common-knowledge step that was keeping these new interfaces I was creating from getting an IP address. I’m sure that the steps Cisco outlines in their document for configuration of the Avahi mDNS gateway will work for some people, but I figured if I had problems with it, someone else might be having the same ones. Hopefully this helps, or at least gets you thinking about the problem a different way.