You know how your Wi-Fi printer or Apple TV or Google Chromecast just sort of magically works at home? These devices do this using mDNS to allow things to discover each other, but this method of “just works TM” tends not to be good news for enterprise networks.

Multicast DNS is a really useful way of allowing devices to discover each other. Device offering services, such as a printer or TV box, periodically announce their wares and other devices can send out queries asking if anyone has a particular service to offer. These are sent as multicast so are seen by all devices on the subnet.

On the small network this was designed for it works really well. There’s little need to configure anything beyond getting everything onto the same network. Once your Chromecast is on your home Wi-Fi network it just appears in the apps that support it as they send out the mDNS request for anything offering the Google Cast service and the Chromecast responds “ooooh oooh, pick me!”.

The problem is this method doesn’t scale very well.

The first issue is all devices have to be on the same subnet in order to discover each other. So immediately it doesn’t work on larger, segmented networks.

There are ways of proxying mDNS packets from one subnet to another, and indeed I’ve done this in the past using avahi, but this in turn just presents a much bigger problem.

Multicast DNS is effectively broadcast traffic that everyone has to see. For the most part we don’t worry about broadcasts on ethernet networks. Unless something has gone badly wrong or the design is very poor, a modern network can handle a lot of broadcast traffic without anyone really noticing.

Wi-Fi networks are a different animal, firstly because there’s just less bandwidth but there’s also a much greater transmission cost. The Multicast traffic is sent at the lowest available data rate. Optimizations to make this less bad are implemented by most vendors, but these are not enabled by default. It’s also pretty common to have a very large number of clients in a single subnet on Wi-Fi networks.

Let’s scale this up and imagine we have 500 APs and 4000 clients. If each client is a device that looks for available mDNS services (every mobile device does) with the traffic being sent at the lowest data rate a significant amount of your airtime can be used by mDNS traffic.

This is a problem for broadcast traffic in general, and anyone running a large Wi-Fi network will know that blocking broadcasts is a must or the network can be overwhelmed.

So how can we make our Chromecast work?

Something that’s important to understand about devices like the Chromecast or Apple TV is mDNS is only used for discovery. Once my iPhone has found an Apple TV actually talking to that device is unicast.

The answer is to use some sort of mDNS proxy. The implementation I’m most familiar with is Aruba’s Airgroups. The controller intercepts mDNS announcements and builds a table of available airgroups servers. Queries are intercepted as well and the controller responds, as appropriate, as if it were the device offering a service.

This approach removes the need to relay mDNS across the wireless medium. By acting as a man in the middle of the discovery process the Aruba controller can also add some access control smarts to the system.

Airgroups allows a server device to be restricted to users with a particular role or connected to a specific AP group. Pairing airgroups with Clearpass nicely centralises this and means setting up an airgroups server and permissions can be enhanced through the clearpass API.

In my university context this means we can have airplay devices in a seminar room and only if you’re on an AP near that room will it be visible. We can also restrict the user roles that can see a device if we wish.

Next is to allow users to register their own airgroup servers. We hope to automate adding user clients through our onboarding process too. What we’re aiming for is a student to be able to connect from their phone to their Chromecast (or whatever) in their room, much as they would on a domestic network. Hopefully this is something that will just require the mac address of the Chromecast (in this example) to be registered in clearpass.

We’re getting close to this, but there are limitations. The number of airgroups servers and clients that can be supported on a mobility controller is limited in hardware. We could easily hit those limits, so we have to tread carefully. Aruba OS8 deals with airgroups in a different way, which will make this less of a problem.

Suffice to say making something as easy as mDNS device discovery work on an enterprise network, and it appear as straight forward as it is at home, is really quite a challenge.