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.
This document describes how to configure FlexConnect Multicast Domain Name System (mDNS) Gateway in 9800 Wireless LAN Controller.
Cisco recommends you have knowledge of these topics:
The information in this document is based on these software and hardware versions:
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.
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
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.
For the AP to work as mDNS Gateway, the feature needs to be turned on by enabling mDNS Gateway globally.
WLC GUI
WLC CLI
WLC#
WLC#conf t
WLC(config)#mdns-sd gateway
WLC(config-mdns-sd)#end
WLC#
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
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#
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
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#
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
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#
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
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.
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
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
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
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#
From the WLC and AP, the configuration can be checked with these 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
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
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:
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.
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:
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:
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.
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:
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.
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.
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.
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.
There is only one Primary mDNS AP per Site Tag and it is in charge of two jobs:
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.
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:
These mDNS services
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.
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.
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.
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.
Revision | Publish Date | Comments |
---|---|---|
1.0 |
29-Jul-2024 |
Initial Release |