Thursday, July 29, 2021

Static mDNS-SD records on a Cisco WLC

First off, I'm not an expert on mDNS by any stretch of the imagination, so apologies if I get some of the terminology incorrect. TL;DR - Is it possible to create something approximating a static mDNS record that a WLC can cache and serve to clients, essentially saying "XYZ service is available at 1.2.3.4", irrespective of whether 1.2.3.4 has actually advertised that service?

I'm having a problem with a server that is supposed to serve AirPrint queues to wireless devices querying for them--essentially, the server is a wired client on an otherwise wireless subnet that serves up AirPrint queues. When things are working, the WLC sees the mDNS advertisements of these queues, and makes them available to iDevices and other things that query for ipp/ipps (AirPrint).

Initially, we ran into a problem with the server not sending out advertisements. I read through the mDNS RFC and I think I determined why that was occurring--I believe the RFC states that devices should not forward out unsolicited advertisements of available services, but should only respond to queries for those services, possibly to cut down on network traffic (no sense in a device spamming out that it supports GoogleCast if there isn't anything trying to cast content).

We have global multicast shut off, and if I understand the documentation correctly (https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/210835-Troubleshooting-mDNS.html), that means mDNS queries from clients remain local to the access point they're attached to, or maybe to APs in the near proximity--that way if you're sitting in conference room 101 in Building A, you only see the Apple TV in that room; you don't see the Apple TV that's in conference room 203 in Building E a half mile away.

Since the print server is a "wired" client, and global multicast is disabled, it's essentially positioned such that it's never going to receive a query from a client; if it only responds to received queries and it never receives a query, it'll never advertise the AirPrint queues, and they'll never be cached on the WLC and thus never be available to wireless clients. To address this, we attached a wired client to the otherwise wireless network and set it up to periodically send out queries for AirPrint; since it was a wired client, its multicast traffic would not be subject to the limitation of having global multicast disabled.

(As an aside: I've since seen in packet captures that the WLC actually periodically sends out queries for mDNS services on its wired interfaces, and the documentation linked above states as much: "When mDNS is enabled globally, the controller sends mDNS queries to 224.0.0.251 for all the services on wired (management and dynamic interfaces) and wireless network." That would seem to suggest the wired client is wholly unnecessary in terms of getting the mDNS server to respond to queries, but that's a challenge for another time.)

The above solution sort of worked for a while, but I'm finding lately that the print server doesn't seem to reliably send out AirPrint advertisements, even when I can see in packet captures that the wired client (and the WLC) are sending queries. It's probably not an ideal solution and I may be falling into an xy problem trap, but is there a way on the WLC to create something like a static mDNS record? What I mean is, instead of depending on the server at 1.2.3.4 to send out advertisements of AirPrint services for the WLC to cache and serve to clients, is there a way to explicitly configure an entry on the WLC saying "IPP/S queue ABC is available on 1.2.3.4" and serve that to clients? I know that runs the risk of advertising a service as available when it really isn't because of some unrelated issue on the server, but I just want to see what options are available.



No comments:

Post a Comment