mDNS Gateway in the Cisco Wireless LAN Controller

I’m not sure why I’ve taken such an interest in mDNS, service discovery, and the Bonjour protocol, but I have. It probably has something to do with my not being able to use AirPlay at home for such a long time because, like any true network geek, I put my wireless devices on a separate VLAN from my home media devices. I mean, duh. So now I keep an eye out for different methods of enabling mDNS in the network in anticipation of my own experience in my home network becoming one of my customer’s experience in their enterprise network.

To that end, I took special note of a feature introduced in Cisco’s latest software release (v7.4) for the Wireless LAN Controller (WLC). This feature is called mDNS Gateway. As the name implies, it enables the WLC to act as a gateway between an mDNS client in VLAN A and an mDNS server in VLAN B.

The idea is very similar to the way Avahi works, as I described in a previous post (AirPlay, VLANs, and an Open Source Solution). The WLC has an arm into whatever VLANs contain mDNS clients and servers. Note that I did not differentiate between wireless or wired, just “VLANs”. If there is an mDNS device on a wired VLAN, as long as that VLAN is trunked to the WLC, it is capable of acting as an mDNS gateway for that VLAN too. As servers advertise their services, the WLC caches the service information along with the IP and MAC of the server. After that, service discovery messages from clients are seen by the WLC which responds based on information in the cache.

That’s all pretty straightforward. There’s more to this though than just helping devices see each other across VLANs. Since the WLC is able to see all the servers and therefore know exactly what services are available on the network, when a client issues a multicast discovery packet, the WLC does two things.

It does not forward that multicast packet out to the rest of the ports/APs in that VLAN. It doesn’t need to. The WLC itself knows where the services are so it will reply to the client. This eliminates the flooding of multicast discovery packets across the network.

The WLC dips into its cache of services, finds the right one, and unicasts a reply back to the client.

If the WLC does not have knowledge of an appropriate service, it does not respond to the discovery request from the client.

The importance of item #1 above cannot be overlooked. If the WLC was simply bridging the client’s multicast packets (as is the default behavior), those packets will go out to every single AP and out every single wired port that belongs to that client’s VLAN. Multiply that out by the number of mDNS clients on the network and the number of multicast packets flooding the network goes up very, very quickly. This drives up CPU utilization on the WLC and consumes network bandwidth.

One more neat thing about mDNS Gateway is the ability to put policy around it. Imagine a corporate environment where you have a guest wifi network and an employee wifi network. You want guests to only have access to AirPlay services while employees have access to AirPlay, AirPrint, and File Share services. By building a Service Discovery Policy on the WLC, you can define what service(s) will be made available to each wireless LAN.

I’m wondering if there’s a way for Cisco devices that are acting as “Service Discovery Gateways” to communicate services to each other (i.e., an inter-SDG protocol of some kind). Being able to trunk all networks that offer services to a WLC is not likely in an enterprise network of any size at all. I see that the SDG service will be available on many Catalyst switches about now (Aug. 2013), and am wondering if this “proxy” sort of service will only be local to a single L3 device, or if there will be some way that they can share information with each other. I have many customers where WLANs can easily span multiple IDFs, and so multiple L3 environments (limiting spanning tree to IDFs according to best practice medianet design).

Great question. I hadn’t even considered that but it makes perfect sense. Peering into the SDG roadmap, I can see enhancements that are coming but I can’t really post them in this forum. Do you have a Cisco SE that you work with? They could brief you on what’s coming around the corner. If they get in touch with me I’m happy to show them where I’m looking for this information.

What sort of environment do you work in? K-12, enterprise? I haven’t yet seen Bonjour/SD make much of an impact in the enterprise customers I deal with. Curious what you’re seeing.

Hey, Joel. Thanks for your reply. I don’t have a Cisco SE that I often work with, since my customers are all over the place (both geographically and type). For example, I just set up a brand new small network for a company moving to a new facility. An MDF, and two IDFs. Stack of switches in each. Local VLANs/subnets in each (QoS primarily protecting VoIP and video, but since I was at it, a bunch of other apps and needs, too). They have lots of Apple and other zeronconf devices looking for printers. Problem! Right now I’m rolling out a bunch of new network equipment (Nexus, 3560s, 2960Ses) for a school district that includes 7 high schools. Also going to roll out a new FlexController (moving off of WISMs), and Cisco Prime. This is a big deal for them, too. I have another job on the horizon for a company that sets up retirement homes (all networked to a central location), and they will have the same need. Frankly, I think it’s pretty much a need these days in *any* environment that allows BYOD.

Anyway, I’m glad to hear that enhancements are coming, even if I can’t know exactly what they are at the present time!

Thanks for explaining the networks you’re working in. Very cool. And interesting environments for zeroconf too.

Is the issue mostly around devices on wifi where the IP/MAC appears on the central controller (their point of presence) but the printer/AirPlay device is wired into the network in the IDF and therefore on a different subnet? Does that describe things somewhat accurately?

In most cases, yes, that does describe the situation. Although for the small company that recently moved into a new location (one MDF, two IDFs), they did not go with a WLC. They installed their own high-end, standalone consumer APs. Without getting into the exact details of the VLAN/subnet design, after changing things from the original plan so that *some* part of the AirPlay environment would work, if the WLAN connected to is on the same switch stack as the printer, they can see it (ended up putting users, WLAN users, and printers all on the same VLAN on a stack, which was not really desired). However, it’s often the case that a user will connect to a WLAN that is on a different IDF stack, and so cannot see the printers near their physical location.

Also, I haven’t really thought through the implications yet for FlexConnected, locally terminated but “roamable” (is that a word?!?? LOL!) WLAN users.

So, it seems like there are a bunch of different situations. Having a means for the network devices to communicate the services available in any flexibly-designed environment to end-users in a completely controllable way (i.e., so that what users get to know about what services is easily configurable) would seem to be the most desirable end state.