Configure FlexConnect mDNS in 9800 Wireless LAN Controller

Available Languages

Download Options

PDF (1.6 MB)
View with Adobe Reader on a variety of devices
ePub (1.8 MB)
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle) (1.4 MB)
View on Kindle device or Kindle app on multiple devices

Updated:July 29, 2024

Document ID:222239

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

This document describes how to configure FlexConnect Multicast Domain Name System (mDNS) Gateway in 9800 Wireless LAN Controller.

Prerequisites

Requirements

Cisco recommends you have knowledge of these topics:

9800 Wireless LAN Controller mDNS concepts
FlexConnect Local Switching concepts

Components Used

The information in this document is based on these software and hardware versions:

Catalyst 9800 Wireless Controller Series (Catalyst 9800-L), Cisco IOS® XE Cupertino 17.9.5
Integrated Services Routers (ISR), Cisco IOS® XE Gibraltar 17.6.5
Catalyst 3560 Series Switch, Cisco IOS® 15.2.4E10
Access Point 9117AXI-B, Access Point 9130AXI-B

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

Multicast Domain Name System (mDNS) is a protocol that provides flexibility to discover and share services between Service Providers (SP) and Service Users (wireless clients). Service Providers are devices that provide a service such as printers, smart tv, file sharing services and more that Service Users can utilize.

The mDNS protocol is based on UDP, utilizes port 5353, Mac Address 01:00:5E:00:00:FB and IP Address 224.0.0.251 for IPv4 and FF02::FB for IPv6.

There are two modes mDNS works in the WLC: Bridging and Gateway. Bridging mode works only in the same Vlan (layer two) where the Service Provider and Service User must be in the same subnet. Gateway mode works with the Service Provider and Service User in the same or different Vlans, with the WLC or the AP doing Bonjour Gateway to cache the services from the Service Provider and share it with Service Users.

This document is based in mDNS FlexConnect Local Switching only, which in this case the AP acts as the mDNS Gateway to cache the services advertised by the Service Providers and shares these services with the Service Users.

Note: For Central Switching mDNS configuration, please refer to Understand mDNS on Catalyst 9800 Wireless Controller

Network Diagram

Wireless and wired Service Provider advertise mDNS services in a FlexConnect Local Switching environment, along with a Wireless Client (Service User) that utilizes the mDNS services.

Service Provider Flow

WLC#
WLC#conf t
WLC(config)#wlan ServiceUser
WLC(config-wlan)#mdns-sd-interface gateway
WLC(config-wlan)#end
WLC#

Warning: Configuration changes in the WLAN provoke connected wireless clients to drop from the SSID. Please be cautious with any configuration change in the WLANs during production time.

Apply the mDNS Service Policy to the WLAN-Policy

For wireless Service Porviders and wireless User Providers, the mDNS services are filtered with the mDNS Poicy previously configured once it is applied to the WLAN-Policy of the WLANs.

WLC GUI

Assign the mDNS Policy

WLC CLI

WLC#
WLC#conf t
WLC(config)#wireless profile policy ServiceUser-Policy
WLC(config-wireless-policy)#mdns-sd service-policy mDNSFlexSSIDPolicy
WLC(config-wireless-policy)#end
WLC#

Warning: Configuration changes in the WLAN-Policy provoke connected wireless clients to drop from the WLAN. Please be cautious with any configuration in the WLAN-Policy during production time.

Note: For general FlexConnect configuration, please refer to Understand FlexConnect on Catalyst 9800 Wireless Controller

Configure mDNS Flex Profile in FlexConnect Policy

In the FlexConnect Policy, where configuration like Vlans, ACLs and more are applied, the mDNS Flex Profile needs to be selected to apply it to the APs that belong to the FlexConnect Policy.

WLC GUI

Assign the mDNS Flex Profile

WLC CLI

WLC#
WLC#conf t
WLC(config)#wireless profile flex mDNSFlexPolicy
WLC(config-wireless-flex-profile)#mdns-sd profile mDNSFlexPolicy
WLC(config-wireless-flex-profile)#end
WLC#

Verify

From the WLC and AP, the configuration can be checked with these commands.

WLC Show Commands

Example of general FlexConnect mDNS configuration can be checked with these commands:

WLC#show run | sec mdns-sd
mdns-sd gateway
mdns-sd service-list FlexIN IN
  match airplay
  match spotify
  match airtunes
  match apple-tv
  match airserver
  match web-server
  match homesharing
mdns-sd service-list FlexOUT OUT
  match airplay
  match spotify
  match airtunes
  match apple-tv
  match airserver
  match web-server
  match homesharing
mdns-sd service-policy mDNSFlexSSIDPolicy
  service-list FlexIN IN
  service-list FlexOUT OUT
mdns-sd flex-profile mDNSFlexPolicy
  wired-vlan-range 11,21
  wired-service-policy mDNSFlexSSIDPolicy
  mdns-sd profile mDNSFlexPolicy

WLAN mDNS mode can checked with this command:

WLC#show wlan name ServiceUser | in mDNS
  mDNS Gateway Status : Gateway
WLC#show wlan name ServiceProvider | in mDNS
  mDNS Gateway Status : Gateway

WLAN-Policy mDNS configuration can be checked with this command:

WLC#show wireless profile policy detailed ServiceUser-Policy | in mDNS
  mDNS Service Policy name : mDNSFlexSSIDPolicy
WLC#show wireless profile policy detailed ServiceProvider-Policy | in mDNS
  mDNS Service Policy name : mDNSFlexSSIDPolicy

AP Show Commands

Configuration related to mDNS can be checked from the AP side with these commands:

9130mDNSAP#show mdns profile detail
  FlexIN_IN _home-sharing._tcp.local ANY
  FlexIN_IN _airplay._tcp.local ANY
  FlexIN_IN _airserver._tcp.local ANY
  FlexIN_IN _raop._tcp.local ANY
  FlexIN_IN _spotify-connect._tcp.local ANY
  FlexIN_IN _http._tcp.local ANY
  FlexOUT_OUT _home-sharing._tcp.local ANY
  FlexOUT_OUT _airplay._tcp.local ANY
  FlexOUT_OUT _airserver._tcp.local ANY
  FlexOUT_OUT _raop._tcp.local ANY
  FlexOUT_OUT _spotify-connect._tcp.local ANY
  FlexOUT_OUT _http._tcp.local ANY

9130mDNSAP#show mdns status
  Global mDNS gateway:Enabled
  vap_id ssid mdns_mode
  0 ServiceUser Gateway
  1 ServiceProvider Gateway
  Active query interval:30
  vap service_list_in service_list_out location
  0 FlexIN_IN FlexOUT_OUT 0
  1 FlexIN_IN FlexOUT_OUT 0
  Wired vlan configuration: 11 21
  mdns stats timer: 1
  mdns cache timer: 1
  AP Sync VLAN: 10
  Wired service list IN: FlexIN_IN
  Wired service list OUT: FlexOUT_OUT

9130mDNSAP#show mdns ap-table
  AP_ETH_MAC Last_message_time Msg_seq Is_primary_ap
  3C:57:31:55:E4:28 1721178339 133 YES
  0C:D0:F8:98:1B:F0 1721178339 133 NO

Troubleshoot

For troubleshooting purposes, this document is going to explain the workflow mDNS goes through in FlexConnect Local Switching. It is important to remember the WLC is not going to have any role in how mDNS is being managed due to the deployment mode which is FlexConnect Local Switching.

The AP itself is going to be the mDNS Gateway device, the AP learns the services from the Service Providers and shares the services with the Services User, this while the AP, Service Provider and Service User are placed in different Vlans.

Per Network Diagram section:

Service Provider is in Vlan 11
Service User is in Vlan 21
Access Point is in Vlan 10

Wired Service Provider

The Service Provider once it detects there is connectivity to the network uses a mechanism called probe, it sends an mDNS query to make sure if there is any other network device that offers the same mDNS services or not. After the probe, the Wired Service provider uses an announce mechanism, it sends an mDNS type response to announce the services it supports.

As next a packet capture taken from the mDNS Gateway AP switchport which shows the Service Provider announces the services it supports. The packet is sourced with the MAC Address and IP Address of the Service Provider in Vlan 11 and it has a destination of the MAC Address and IP Address of mDNS, including the mDNS port 5353 over UDP, it also contains the answers which are the services supported by the Service Provider.

The answers section in next image shows the services of our interest which are airplay and spotify, later the AP cache these services and save it them in the database.

mDNS Service Provider services

From the AP CLI, the wired Service Provider announces can be seen as well, to see any mDNS information from the AP itself these debugs have to be enabled:

AP#debug mdns events
AP#debug mdns packets

Jul 17 23:51:32 kernel: [*07/17/2024 23:51:32.0403] chatter: MDNSGW-EVENT: flex mdns gw: Recieved wired mdns packet on vlan 11
Jul 17 23:51:32 kernel: [*07/17/2024 23:51:32.0403] chatter: MDNSGW-EVENT: push: adding ptr record to cache: srv_name: _spotify-connect._tcp.local
Jul 17 23:51:32 kernel: [*07/17/2024 23:51:32.0404] chatter: MDNSGW-EVENT: mdns_ptr_db:updated TXT record TTL for ed9583d2b239afa30d7b0e7106c3710ddcfe5769._spotify-connect._tcp.local to 4500
Jul 17 23:51:32 kernel: [*07/17/2024 23:51:32.0404] chatter: MDNSGW-EVENT: mdns_ptr_db:added/updated PTR record for _spotify-connect._tcp.local
Jul 17 23:51:32 kernel: [*07/17/2024 23:51:32.0404] chatter: MDNSGW-EVENT: push: added ptr record to cache: srv_name: _spotify-connect._tcp.local
Jul 17 23:51:32 kernel: [*07/17/2024 23:51:32.0404] chatter: MDNSGW-EVENT: push: adding ptr record to cache: srv_name: _airplay._tcp.local
Jul 17 23:51:32 kernel: [*07/17/2024 23:51:32.0404] chatter: MDNSGW-EVENT: mdns_ptr_db:updated TXT record TTL for Samsung CU7000 55 TV._airplay._tcp.local to 4500
Jul 17 23:51:32 kernel: [*07/17/2024 23:51:32.0405] chatter: MDNSGW-EVENT: mdns_ptr_db:added/updated PTR record for _airplay._tcp.local
Jul 17 23:51:32 kernel: [*07/17/2024 23:51:32.0405] chatter: MDNSGW-EVENT: push: added ptr record to cache: srv_name: _airplay._tcp.local

Once the AP learns the services it saves the same in the database.

The saved services in the AP database can be checked with this command:

AP#show mdns cache

For the purpose of this document, the next output shows the relevant information to prove the mDNS Gateway AP has in its cache the services, however, the output is longer.

Next and highlighted the services, the MAC Address of the Service Provider and the Vlan where it was learned.

AP#show mdns cache
--------------------------------------------------- Service Provider Records--------------------------------------------------------------
 service_name                                                                            service_providers
 _airplay._tcp.local                                                                   Samsung CU7000 55 TV._airplay._tcp.local
_spotify-connect._tcp.local                                           ed9583d2b239afa30d7b0e7106c3710ddcfe5769._spotify-connect._tcp.local

Total Services: 2
Total Service Providers: 2
------------------------------------------------------------ PTR Records -----------------------------------------------------------------
service_name client_mac ap_mac ap_ether_mac wired is_rlan is_aaa_override vlan wlan_id ttl flags client_type record_type target site_name ap_location ssid type
Samsung CU7000 55 TV._airplay._tcp.local E0:03:6B:45:8E:26 00:00:00:00:00:00 00:00:00:00:00:00 true false false 11 16 3840 132 0 12 _airplay._tcp.local PTR
ed9583d2b239afa30d7b0e7106c3710ddcfe5769._spotify-connect._tcp.local E0:03:6B:45:8E:26 00:00:00:00:00:00 00:00:00:00:00:00 true false false 11 16 3840 132 0 12 _spotify-connect._tcp.local PTR

Once the wired Service Provider has announced the services and the AP has cache the services and saved in its database as shown in previous steps, the Service User (wireless client) looks to mirror the content of the device (laptop) to the smart TV for mirror display. To accomplish the mirror display the Service User utilizes airplay service in this example.

Since the Service User is connected via wireless an Over the Air packet capture was needed to see the connection mDNS flow from the Service User side.

From the Over the Air captures, it can be seen how the Service User which is the wireless client in Vlan 21, sends an mDNS query with the 802.11 destination MAC Address of mDNS and from the IP Address section the IP Address of mDNS is used as well as destination, the port is UDP 5353 and within the mDNS queries airplay is requested. As source the MAC Address of the Service User was used along with its IP Address.

mDNS Service User services request

From the AP debug, it can be seen how the AP receives a wireless mDNS packet. The debug displays the services requested which are the same services the packet capture in previous step showed. The mDNS debugs utilized are:

AP#debug mdns events
AP#debug mdns packets

Jul 18 02:04:45 kernel: [*07/18/2024 02:04:45.1824] chatter: MDNSGW-EVENT: flex mdns gw: Recieved wireless mdns packet
Jul 18 02:04:45 kernel: [*07/18/2024 02:04:45.1824] chatter: MDNSGW-PAK: query: 0/3 '_companion-link._tcp.local'
Jul 18 02:04:45 kernel: [*07/18/2024 02:04:45.1824] chatter: MDNSGW-PAK: query: 1/3 '_rdlink._tcp.local'
Jul 18 02:04:45 kernel: [*07/18/2024 02:04:45.1824] chatter: MDNSGW-PAK: query: 2/3 '_sleep-proxy._udp.local'
Jul 18 02:04:45 kernel: [*07/18/2024 02:04:45.7442] chatter: MDNSGW-PAK: query: 0/1 '_airplay._tcp.local'

Note: To take Over The Air packet captures with an AP in Sniffer mode, please refer to this document Configure Access Point in Sniffer Mode on Catalyst 9800 Wireless Controllers. To use a MacBook to take Over The Air packet captures, please refer to this document Collect Packet Captures Over the Air on a MacBook

Once the AP received the mDNS query from the Service User it builds an mDNS response and send it over wireless. The response is sourced with the Access Point MAC Add and IP Address as well, the destination is the Service User (wireless client) MAC Address but, the mDNS IP Address is used with the needed services included as answers, which means this packet goes to the Service User and it is an mDNS packet.

From the packet, it can also be seen how the AP uses its own IP Address in the IP section to source the packet towards the mDNS IP Address along with the mDNS port UDP 5353, since the AP is acting as mDNS Gateway.

mDNS Services Response from AP

From the debug, it can be seen the mDNS response was sent to the Service User, the way to know the mDNS response was for the specific Service User is to check the MAC Address of the Service User and the MAC Address of the Access Point in the response. They are together as seen in the highlighted part of the debug shown next, as seen from the previous step in the packet capture the MAC Address of the Service User is a6c515dcdd57 and the MAC Address of the Access Point is 0c75bdb5e9d0.

Jul 18 02:04:45 kernel: [*07/18/2024 02:04:45.7450] chatter: mdns response packet 599 | a6c515dc dd570c75 bdb5e9d0 08004500 02490000 0000fa11 1ddec0a8 0a3fc0a8 153614e9 14e90235 6b330000 80000000 00030000 00000e5f 6d657461 5f726573 706f6e73 65055f6d 646e7308 5f676174 65776179 035f6170 065f6c6f 63616c00 00100001 00000000 0000085f 61697270 6c617904 5f746370 056c6f63 616c0000 0c000100 0010a400 17145361 6d73756e 67204355 37303030 20353520 5456c040 c05f0010 00010000 10a401ab 0561636c 3d301a64 65766963 6569643d 45303a30 333a3642 3a34353a 38453a32 361b6665 61747572 65733d30 78374638 4144302c 30783338 42434634 36126665 783d3049 702f4145 62506977 4e414341 07727366 3d307833 1a66763d 7032302e 542d4b53 55324543 414b5543 2d313430 322e3806 61743d30 78310b66 6c616773 3d307832 30340d6d 6f64656c 3d554355 37303030 12696e74 65677261 746f723d 53616d73 756e6714 6d616e75 66616374 75726572 3d53616d 73756e67 1c736572 69616c4e 756d6265 723d3046 47463343 47573630 32313834 4b0d7072 6f746f76 6572733d 312e3111 73726376 6572733d 3337

The previous steps complete a successful mDNS packet flow for FlexConnect Local Switching, where the Service Provider was wired connected in Vlan 11, the AP in Vlan 10 and the Service User in Vlan 21.

Wireless Service Provider

The Wireless Service provider works exactly the same as the Wired Service Provider mechanism, it sends a probing and also an announcement for the services, the AP cache the services and save them in the database. This section intends to explain how the AP doing mDNS Gateway learns the services when the Service Provider is connected via wireless.

The difference between a Wired and a Wireless Service Provider is how the packet looks over the air since 802.11 takes place. In the next packet it can seen how the Wireless Service provider in Vlan 11 sends an mDNS packet with source its own MAC Address and IP Address and the destination is the mDNS Mac Address and IP ADDs, over port UDP 5353 with the Services listed as answers.

Wireless Service Provider mDNS services

From the AP debugs, it can be seen how the AP gets a wireless mDNS packet and add the services learned to the database.

Jul 18 02:42:01 kernel: [*07/18/2024 02:42:01.7785] chatter: MDNSGW-EVENT: flex mdns gw: Recieved wireless mdns packet
Jul 18 02:42:01 kernel: [*07/18/2024 02:42:01.7786] chatter: MDNSGW-EVENT: push: added ptr record to cache: srv_name: _spotify-connect._tcp.local
Jul 18 02:42:01 kernel: [*07/18/2024 02:42:01.7786] chatter: MDNSGW-EVENT: push: adding ptr record to cache: srv_name: _services._dns-sd._udp.local
Jul 18 02:42:01 kernel: [*07/18/2024 02:42:01.7786] chatter: MDNSGW-EVENT: push: adding ptr record to cache: srv_name: _airplay._tcp.local
Jul 18 02:42:01 kernel: [*07/18/2024 02:42:01.7787] chatter: MDNSGW-EVENT: mdns_ptr_db:updated TXT record TTL for Samsung CU7000 55 TV._airplay._tcp.local to 4500
Jul 18 02:42:01 kernel: [*07/18/2024 02:42:01.7787] chatter: MDNSGW-EVENT: mdns_ptr_db:added/updated PTR record for _airplay._tcp.local
Jul 18 02:42:01 kernel: [*07/18/2024 02:42:01.7787] chatter: MDNSGW-EVENT: push: added ptr record to cache: srv_name: _airplay._tcp.local

Once the AP caches the services the database is built and it shows some differences compared to the Wired Services provider services, since the Wireless Service provider database in the AP shows details like SSID name, site name (site TAG) and more highlighted shown next.

AP#show mdns cache
--------------------------------------------------- Service Provider Records--------------------------------------------------------------
service_name                                                                            service_providers
 _airplay._tcp.local                                                         Samsung CU7000 55 TV._airplay._tcp.local
_spotify-connect._tcp.local                                     ed9583d2b239afa30d7b0e7106c3710ddcfe5769._spotify-connect._tcp.local

Total Services: 2
Total Service Providers: 2
------------------------------------------------------------ PTR Records -----------------------------------------------------------------
 service_name client_mac ap_mac ap_ether_mac wired is_rlan is_aaa_override vlan wlan_id ttl flags client_type record_type target site_name ap_location ssid type
 Samsung CU7000 55 TV._airplay._tcp.local 68:FC:CA:6E:EB:0C 0C:75:BD:B3:20:A0 0C:75:BD:B5:E9:D0 false false false 11 1 4320 132 0 12 _airplay._tcp.local mDNSFlex-Site-TAG RemoteLocation ServiceProvider PTR
ed9583d2b239afa30d7b0e7106c3710ddcfe5769._spotify-connect._tcp.local 68:FC:CA:6E:EB:0C 0C:75:BD:B3:20:A0 0C:75:BD:B5:E9:D0 false false false 11 1 4320 132 0 12 _spotify-connect._tcp.local mDNSFlex-Site-TAG RemoteLocation ServiceProvider PTR

The mDNS User Service query and the AP mDNS Gateway answer are exactly the same already explained in the Wired Service Provider section, the Service User sends an mDNS query and the AP mDNS acts as a Gateway and sends a response to the Service User with the needed services details.

Primary mDNS AP

There is only one Primary mDNS AP per Site Tag and it is in charge of two jobs:

Keep all the APs mDNS database updated as long as they belong to the same Site TAG, so the mDNS database of each AP is the same and there are no missing mDNS services.
Inform the WLC about the mDNS services learned at the remote location (this is just informational and for management purposes only, the WLC cannot use these services).

Primary AP inform update from a non-Primary AP perspective, keep in mind all the APs are in Vlan 10 in this site:

Jul 18 03:26:25 kernel: [*07/18/2024 03:26:25.4852] chatter: MDNSGW-EVENT: flex mdns gw: Recieved wired mdns packet on vlan 10
Jul 18 03:26:25 kernel: [*07/18/2024 03:26:25.4853] chatter: MDNSGW-EVENT: Received _heartbeat record. data: digest=f7adbb063c274f6e4219f3a36abf7f787075b7e1
Jul 18 03:26:25 kernel: [*07/18/2024 03:26:25.4853] chatter: seq=355
Jul 18 03:26:25 kernel: [*07/18/2024 03:26:25.4853] chatter: is_primary_ap=true
Jul 18 03:26:25 kernel: [*07/18/2024 03:26:25.4854] chatter: MDNSGW-EVENT: Calculated digest=f7adbb063c274f6e4219f3a36abf7f787075b7e1
Jul 18 03:26:25 kernel: [*07/18/2024 03:26:25.4854] chatter: MDNSGW-EVENT: Verified meta message
Jul 18 03:26:25 kernel: [*07/18/2024 03:26:25.4854] chatter: MDNSGW-EVENT: [0C:75:BD:B5:E9:D0] Verified message from 3C:57:31:55:E4:28
Jul 18 03:26:25 kernel: [*07/18/2024 03:26:25.4854] chatter: MDNSGW-EVENT: New pkt from 3C:57:31:55:E4:28. Hash added to list
Jul 18 03:26:25 kernel: [*07/18/2024 03:26:25.4854] chatter: MDNSGW-EVENT: mdns_gw_ap_mgr :: MdnsGwApMgr: [3C:57:31:55:E4:28] Received _meta_heartbeat with message: seq=355, is_primary=true

9130mDNSAP#show mdns ap-table
AP_ETH_MAC Last_message_time Msg_seq Is_primary_ap
3C:57:31:55:E4:28 1721273666 363 YES
9130mDNSAP#

Primary mDNS AP informing the other APs about the services learned in the Site TAG and network the Primary AP belongs to, once the mDNS informational packet reaches the other APs in the same site tag the mDNS cache databse is updated in the APs if new services are learned:

Jul 18 03:41:26 kernel: [*07/18/2024 03:41:26.1021] chatter: MDNSGW-EVENT: forward_packet: sending packet on vlan 10
Jul 18 03:41:26 kernel: [*07/18/2024 03:41:26.1023] chatter: send meta packet 177 | 01005e00 00fb3c57 3155e428 08004500 00a30000 0000fa11 1469c0a8 0a3de000 00fb14e9 14e9008f 450e0000 80000000 00010000 00000a5f 68656172 74626561 74055f6d 646e7308 5f676174 65776179 035f6170 065f6c6f 63616c00 00100001 00000000 004b2f64 69676573 743d6233 36336564 65343334 39643531 64613039 66613765 61313739 35346633 64666235 39383763 35340773 65713d33 37301269 735f7072 696d6172 795f6170 3d747275 65

Primary mDNS AP database update to the WLC:

Jul 18 03:35:26 kernel: [*07/18/2024 03:35:26.3127] chatter: MDNSGW-EVENT: mdns_gw_visibility :: MdnsGwVisibility: MDNS Stats Timer triggered
Jul 18 03:35:26 kernel: [*07/18/2024 03:35:26.3128] chatter: MDNSGW-PAK: mdns_gw_visibility :: MdnsGwVisibility: sending mdns stats payload to capwapd
Jul 18 03:35:26 kernel: [*07/18/2024 03:35:26.3130] chatter: MDNSGW-EVENT: mdns_gw_visibility :: MdnsGwVisibility: MDNS Cache Timer triggered
Jul 18 03:35:26 kernel: [*07/18/2024 03:35:26.3131] chatter: MDNSGW-EVENT: mdns_gw_visibility :: MdnsGwVisibility: sending mdns cache IAPP payload. Total payloads sent - 2

The services informed by the Primary AP to the WLC provide information that contains the services learned, if the services are learned via Wired or Wireless by the APs (in this example is a Wired Service Provider), the Site TAG and Vlan they were learned from and the Service Provider name. For the Wireless Service Provider the WLAN ID reflects the WLAN the Service Provider is connected to.

mDNS services monitoring from WLC GUI

Services Not Allowed per mDNS Service List

The mDNS service list and policies allows to have control of the mDNS services permitted in the network, here an example of how mDNS services not allowed in the Service List IN and OUT are filtered.

To see the services being advertised or queried, but not allowed pleas enable this debug in the AP:

AP#debug mdns errors

These mDNS services

_airplay-bds._tcp.local
_wake._tcp.local

Are not allowed, since they are not configured and selected in the Service List configured in the Select mDNS Services.

Jul 18 03:46:41 kernel: [*07/18/2024 03:46:41.6986] chatter: MDNSGW-ERROR: Handle query: service_string:_airplay-bds._tcp.local not allowed by policy. Skipping it.
Jul 18 03:46:53 kernel: [*07/18/2024 03:46:53.7270] chatter: MDNSGW-ERROR: Handle query: service_string:6A:FC:CA:6E:EB:[email protected]._wake._tcp.local not allowed by policy. Skipping it.

Custom mDNS Services Configuration in Service Definition

In case a special service list is needed, the same need to be added to the Service Definition section in the mDNS configuration in the WLC.

Once the services are added as a service in the WLC and selected in the Service List IN and OUT they are pushed to the FlexConnect APs through the mDNS Service Policy.

To do it, we need to know the exact service needed and from the Service Definition Section add a custom name for the service and the service string.

In this example I added the two services that were filtered by the mDNS Gateway APs in the section Services not allowed per mDNS Service List.

mDNS custom Service Definition

FlexConnect mDNS Bridging mode

This document does not cover mDNS bridging mode due to the fact that this mDNS mode is treated as regular data traffic from the AP perspective in FlexConnect Local Switching. When bridging mode is enabled for mDNS in FlexConnect Local Switching the AP simply forwards the mDNS packets received from the wired or wireless. These packets are forwarded only in the same Vlan, which means that the Service Provider and the Service User must be in the same Vlan for mDNS to work. mDNS Bridging does not work across Vlans.

Flexconnect mDNS Drop Mode

If mDNS is not desire in some WLANs but it is indeed needed in other WLANs, the mDNS mode drop can be configured per WLAN. Once mDNS drop is enabled mDNS does not go through the devices connected to the WLAN.

mDNS drop mode

Revision History

Revision	Publish Date	Comments
1.0	29-Jul-2024	Initial Release

Contributed by Cisco Engineers

Tim Padilla
Technical Consulting Engineer