This document describes the different types of multicast Domain Name System (mDNS) queries sent by the Wireless LAN Controller (WLC) and the scenarios under which these are sent.
Types of Queries
There are mainly four types of queries that are sent:
Aggregated query: Query which consists of all services in the Master list.
Set of services query: This is for set of services for which the query timer is enabled.
Service specific query: Query consists of only one service.
Service provider query: Query for a specific service provider.
These different query messages can again be sent at different workflows, either by the WLC or the wireless clients which is explained as follows:
Periodic mDNS Query
In general, any device that supports a service would advertise the same after power-on. However, it has been observed that some devices do not advertise their services. In such cases, the WLC would send periodic mDNS query messages (service specific query).
This query would not have QU (unicast query) bit set so that answers are multicasted on that VLAN. The explicit mDNS query mechanism ensures that services are learnt for devices that do not advertise the services on power-on as well. By default, WLC sends a query every fifteen minutes and it can be configured as needed.
WLC Boot-Up Query
After boot-up (2 minutes after boot) WLC sends one time query, aggregated for all the services allowed in master-service-list on all VLAN's. The master-service-list has a default set of services on startup. This query would have QU bit set so that answers are unicasted to WLC.
New Interface Creation Query
When a new Interface is created, WLC must send a one time query, aggregated for all the services allowed in master-service-list. This query would have QU bit set so that the answers are unicasted to WLC.
New Service Creation in Master-Service-List Query
When a new service is added to the master-service-list, WLC sends a one time query for that service to all VLAN's. This query would have the QU bit set so that answers are unicasted to WLC.
L2 Roam Query
WLC learns the bonjour advertisements from the wireless clients of other WLC's from wired side. This service provider entry would be maintained in the database as wired entry. In such a case, if bonjour service provider roams from another WLC to this WLC (L2 roam) then you need to migrate the entry from wired side to wireless side. In order to ensure that all the entries are migrated, WLC would send a mDNS query, aggregated for all the services allowed in the master-service-list (only if mDNS is enabled on client’s WLAN).
mDNS Query from Wired Clients
For any mDNS query messages received from the wired side, the WLC responds with services on the same VLAN of wireless service providers only. This is to ensure that we do not cross the subnet boundary on the wired side. The response would be Unicasted or Multicasted based on the QU bit in the query. Basically the WLC cannot enforce policy for wired hosts unlike the wireless clients and for the wired hosts Bonjour is restricted to the same VLAN.
This can be summarized in the table as follows:
In the table:
Type 1 - Aggregated query Type 2 - Set of services query Type 3 - Service specific query Type 4 - Service provider query
Device Deletion Triggers
You can now have a look at the triggers that causes the deletion of a device from the service provider database:
WLC starts a timer once it adds the client in the service provider database. When the timer reaches 85% of TTL WLC sends an unicast query to the service provider. It repeats this for every 5% of TTL until 95% of TTL. In case it does not get a response it deletes the client entry.
When the WLAN is disabled, all the clients on the WLAN would get disassociated and the client’s mscb would be deleted. At the same time client entry in the service provider database is also deleted.
Access Point (AP) disassociated
When there is an AP disassociation or its radio is disabled the clients associated with the AP/Radio are disassociated and the client mscb is deleted. Here also the database cleanup gets triggered as mentioned earlier.
When client does a L2 roam
When a Bonjour client / server (who provides some bonjour service) does a L2 roam the client mscb is deleted and triggers the cleanup of the database.