mDNS on a corporate WiFi network

You know how your WiFi 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 tends not to be good news for enterprise networks.

Multicast DNS is a really useful way of allowing devices to discover each other. Without getting into the fine points of the protocol, suffice to say that it works by sending requests and announcements that every device on the network subnet sees. 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.

On a small network this works really well. There’s little need to configure anything beyond getting everything onto the same network. Once your Chromecast is on your home WiFi 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 this presents a challenge for 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 pfsense, but this in turn just presents a much bigger problem.

Multicast DNS is 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.

WiFi networks are a different animal, firstly because there’s just less bandwidth but there’s also a broadcast transmission cost. If my iPhone sends an mDNS query the AP then has to pass that on as a multicast transmission, so it’s sent twice on the RF space I’m using. It also gets passed on by every AP with clients on that vlan.

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) you can see that 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 WiFi network will know that disabling broadcasts is a must or the network can be completely filled up with broadcast traffic all contending for the airtime. 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.

Aruba networks have a solution to the mDNS problem called Airgroups. It’s been around for a few years now and essentially the mobility controller intercepts mDNS announcements and builds a table of available airgroups servers. Queries are intercepted as well and the controller responds. This approach removes the need to send a broadcast across the wireless medium. By acting as a man in the middle of the discovery process the Aruba controller can also add some smarts to the system.

Because many devices using mDNS are designed for a domestic setting they lack any access control. The Chromecast for example just lets anyone connect.

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. How many 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.