Contents

Introduction

Prerequisites

Requirements

Components Used

Background Information

Network Diagram

Configurations

Enable mDNS Globally in the WLC

Select mDNS Services within a Service List

Merge the Service Lists with a Service Policy

Configure an mDNS Flex Profile

Configure the WLAN with mDNS Gateway Mode

Apply the mDNS Service Policy to the WLAN-Policy

Configure mDNS Flex Profile in FlexConnect Policy

Verify

WLC Show Commands

AP Show Commands

Troubleshoot

Wired Service Provider

Wireless Service Provider

Primary mDNS AP

Services Not Allowed per mDNS Service List

Custom mDNS Services Configuration in Service Definition

FlexConnect mDNS Bridging mode

Flexconnect mDNS Drop Mode

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.

Configurations

Enable mDNS Globally in the WLC

For the AP to work as mDNS Gateway, the feature needs to be turned on by enabling mDNS Gateway globally.

WLC GUI

mDNS Global Configuration

WLC CLI

WLC#

WLC#conf t

WLC(config)#mdns-sd gateway

WLC(config-mdns-sd)#end

WLC#

Select mDNS Services within a Service List

Configure a Service List to allow the mDNS services of preference. The list has to be configured in two directions which are IN and OUT, which filters what ingress and egress services are allowed by the Access Point acting as mDNS gateway.

WLC GUI

Select the services needed in the Service List

WLC CLI

WLC#

WLC#conf t

WLC(config)#mdns-sd service-list FlexIN IN

WLC(config-mdns-sl-in)#match airplay

WLC(config-mdns-sl-in)#match spotify

WLC(config-mdns-sl-in)#exit

WLC(config)#mdns-sd service-list FlexOUT OUT

WLC(config-mdns-sl-out)#match airplay

WLC(config-mdns-sl-out)#match spotify

WLC(config-mdns-sl-out)#end

WLC#

Merge the Service Lists with a Service Policy

Once the Service List IN and OUT are configured with the needed services a Service Policy is used to merge them. Once merged this Service Policy can be used in the WLAN-Policy, FlexConnect profile and mDNS Flex Policy.

WLC GUI

Merge the mDNS Service Lists in an mDNS Policy

WLC CLI

WLC#

WLC#conf t

WLC(config)#mdns-sd service-policy mDNSFlexSSIDPolicy

WLC(config-mdns-ser-pol)#service-list FlexIN IN

WLC(config-mdns-ser-pol)#service-list FlexOUT OUT

WLC(config-mdns-ser-pol)#end

WLC#

Configure an mDNS Flex Profile

In the mDNS Flex Profile, the FlexConnect Local Switching Vlans where mDNS is used need to be added to the Flex Profile, the Vlan of the Service Provider and Service User must be added to the mDNS Flex Profile, along with the mDNS Service Policy which allows to filter the services via wired.

WLC GUI

Create an mDNS FlexConnect Profile

WLC CLI

WLC#

WLC#conf t

WLC(config)#mdns-sd flex-profile mDNSFlexPolicy

WLC(config-mdns-flex-prof)#wired-vlan-range 11,21

WLC(config-mdns-flex-prof)#wired-service-policy mDNSFlexSSIDPolicy

WLC(config-mdns-flex-prof)#end

WLC#

Configure the WLAN with mDNS Gateway Mode

Every WLAN has by default the mDNS mode as Bridging. For the AP to know when to act as an mDNS Gateway for Service Providers connected via wireless and for Service Users the WLAN must be configured with mDNS as Gateway mode.

WLC GUI

Configure the SSID in mDNS Gateway mode

WLC CLI

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:

1. 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.

2. 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:0C@0.0.0.0._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