El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
En este documento se describe cómo configurar la puerta de enlace del sistema de nombres de dominio (mDNS) de multidifusión FlexConnect en el controlador de LAN inalámbrica 9800.
Cisco recomienda tener conocimientos de estos temas:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
El sistema de nombres de dominio multidifusión (mDNS) es un protocolo que proporciona flexibilidad para detectar y compartir servicios entre proveedores de servicios (SP) y usuarios de servicios (clientes inalámbricos). Los proveedores de servicios son dispositivos que proporcionan un servicio como impresoras, smart tv, servicios de intercambio de archivos y mucho más que los usuarios de servicios pueden utilizar.
El protocolo mDNS se basa en UDP, utiliza el puerto 5353, la dirección Mac 01:00:5E:00:00:FB y la dirección IP 224.0.0.251 para IPv4 y FF02::FB para IPv6.
Hay dos modos que mDNS funciona en el WLC: Bridging y Gateway. El modo de puente funciona solamente en la misma VLAN (capa dos) en la que el proveedor de servicios y el usuario de servicios deben estar en la misma subred. El modo de gateway funciona con el proveedor de servicios y el usuario de servicio en las mismas o diferentes VLAN, con el WLC o el AP haciendo Bonjour Gateway para almacenar en caché los servicios del proveedor de servicio y compartirlos con los usuarios de servicio.
Este documento se basa solamente en mDNS FlexConnect Local Switching, que en este caso el AP actúa como la gateway mDNS para almacenar en caché los servicios anunciados por los proveedores de servicios y comparte estos servicios con los usuarios del servicio.
Nota: Para obtener información sobre la configuración de mDNS de conmutación central, consulte Introducción a mDNS en el controlador inalámbrico Catalyst 9800
Los proveedores de servicios por cable e inalámbricos anuncian los servicios mDNS en un entorno de switching local FlexConnect, junto con un cliente inalámbrico (usuario de servicio) que utiliza los servicios mDNS.
Para que el AP funcione como gateway mDNS, la función debe activarse habilitando mDNS Gateway globalmente.
GUI WLC
CLI WLC
WLC#
WLC#conf t
WLC(config)#mdns-sd gateway
WLC(config-mdns-sd)#end
WLC#
Configure una lista de servicios para permitir los servicios mDNS de preferencia. La lista debe configurarse en dos direcciones: IN y OUT, que filtra los servicios de entrada y salida permitidos por el punto de acceso que actúa como gateway mDNS.
GUI WLC
CLI WLC
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#
Una vez que las listas de servicios IN y OUT están configuradas con los servicios necesarios, se utiliza una política de servicio para fusionarlas. Una vez fusionada, esta política de servicio se puede utilizar en el perfil de FlexConnect y la política flexible de mDNS, así como en la política de WLAN.
GUI WLC
CLI WLC
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#
En el perfil flexible de mDNS, las VLAN de switching local de FlexConnect donde se utiliza mDNS deben agregarse al perfil flexible, la VLAN del proveedor de servicios y el usuario de servicios debe agregarse al perfil flexible de mDNS, junto con la política de servicio de mDNS que permite filtrar los servicios a través de conexiones por cable.
GUI WLC
CLI WLC
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#
Cada WLAN tiene de forma predeterminada el modo mDNS como Bridging (Puente). Para que el AP sepa cuándo actuar como gateway mDNS para los proveedores de servicio conectados vía inalámbrica y para los usuarios del servicio el WLAN debe ser configurado con mDNS como modo gateway.
GUI WLC
CLI WLC
WLC#
WLC#conf t
WLC(config)#wlan ServiceUser
WLC(config-wlan)#mdns-sd-interface gateway
WLC(config-wlan)#end
WLC#
Advertencia: los cambios de configuración en la WLAN provocan que los clientes inalámbricos conectados se borren del SSID. Tenga cuidado con cualquier cambio de configuración en las WLAN durante el tiempo de producción.
Para los proveedores de servicios inalámbricos y los proveedores de usuarios inalámbricos, los servicios mDNS se filtran con la política mDNS previamente configurada una vez que se aplica a la política WLAN de las WLAN.
GUI WLC
CLI WLC
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#
Advertencia: Los cambios de configuración en la política de WLAN provocan que los clientes inalámbricos conectados se desconecten de la WLAN. Tenga cuidado con cualquier configuración en la WLAN-Policy durante el tiempo de producción.
Nota: Para obtener información sobre la configuración general de FlexConnect, consulte Introducción a FlexConnect en el controlador inalámbrico Catalyst 9800
En la política de FlexConnect, donde se aplican configuraciones como VLAN, ACL y más, debe seleccionarse el perfil flexible de mDNS para aplicarlo a los AP que pertenecen a la política de FlexConnect.
GUI WLC
CLI WLC
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#
Desde el WLC y el AP, la configuración se puede verificar con estos comandos.
Se puede comprobar un ejemplo de configuración general de mDNS de FlexConnect con estos comandos:
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
El modo mDNS de WLAN se puede verificar con este comando:
WLC#show wlan name ServiceUser | in mDNS
mDNS Gateway Status : Gateway
WLC#show wlan name ServiceProvider | in mDNS
mDNS Gateway Status : Gateway
La configuración mDNS de la política WLAN se puede verificar con este comando:
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
La configuración relacionada con mDNS se puede verificar desde el lado del AP con estos comandos:
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
Para solucionar problemas, este documento explica el flujo de trabajo que mDNS realiza en el switching local de FlexConnect. Es importante recordar que el WLC no va a tener ningún papel en cómo mDNS se está gestionando debido al modo de implementación que es el switching local de FlexConnect.
El AP en sí mismo va a ser el dispositivo de gateway mDNS, el AP aprende los servicios de los proveedores de servicios y comparte los servicios con el usuario de servicios, esto mientras que el AP, el proveedor de servicios y el usuario de servicios se colocan en diferentes VLAN.
Sección Por Diagrama de Red:
El proveedor de servicios, una vez que detecta que hay conectividad con la red, utiliza un mecanismo llamado sonda y envía una consulta mDNS para asegurarse de que haya algún otro dispositivo de red que ofrezca los mismos servicios mDNS o no. Después del sondeo, el proveedor de servicios por cable utiliza un mecanismo de anuncio y envía una respuesta de tipo mDNS para anunciar los servicios que admite.
A continuación, una captura de paquetes tomada del puerto de switch AP de la gateway mDNS que muestra al proveedor de servicios los servicios que admite. El paquete se origina con la dirección MAC e IP del proveedor de servicios en la VLAN 11 y tiene un destino de la dirección MAC y la dirección IP de mDNS, incluido el puerto mDNS 5353 sobre UDP. También contiene las respuestas que son los servicios admitidos por el proveedor de servicios.
La sección de respuestas en la siguiente imagen muestra los servicios de nuestro interés que son airplay y spotify, más tarde el AP almacena en caché estos servicios y los guarda en la base de datos.
Desde la CLI del AP, el proveedor de servicios por cable anuncia que también se puede ver, para ver cualquier información de mDNS desde el propio AP, estas depuraciones deben estar habilitadas:
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
Una vez que el AP aprende los servicios, guarda los mismos en la base de datos.
Los servicios guardados en la base de datos AP se pueden verificar con este comando:
A efectos de este documento, el siguiente resultado muestra la información relevante para probar que el AP de gateway mDNS tiene en su caché los servicios, sin embargo, el resultado es más largo.
A continuación, se resaltaron los servicios, la dirección MAC del proveedor de servicios y la VLAN donde se aprendió.
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
Una vez que el proveedor de servicios por cable ha anunciado los servicios y el AP ha almacenado en caché los servicios y guardado en su base de datos como se muestra en los pasos anteriores, el usuario de servicio (cliente inalámbrico) busca reflejar el contenido del dispositivo (portátil) en el televisor inteligente para la visualización de reflejo. Para lograr la visualización de reflejo, el usuario del servicio utiliza el servicio Airplay en este ejemplo.
Dado que el usuario del servicio está conectado a través de la red inalámbrica, fue necesaria la captura de paquetes Over the Air para ver el flujo de mDNS de la conexión desde el lado del usuario del servicio.
En las capturas Over the Air, se puede ver cómo el usuario de servicio, que es el cliente inalámbrico en Vlan 21, envía una consulta mDNS con la dirección MAC de destino 802.11 de mDNS y desde la sección de dirección IP se utiliza la dirección IP de mDNS así como el destino, el puerto es UDP 5353 y dentro de las consultas mDNS se solicita la reproducción aérea. Como origen, se utilizó la dirección MAC del usuario de servicio junto con su dirección IP.
Desde la depuración de AP, se puede ver cómo el AP recibe un paquete mDNS inalámbrico. La depuración muestra los servicios solicitados que son los mismos servicios que mostró la captura de paquetes en el paso anterior. Las depuraciones mDNS utilizadas son:
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'
Nota: Para hacerse cargo de las capturas de paquetes de Air con un AP en modo Sniffer, consulte este documento Configure Access Point in Sniffer Mode on Catalyst 9800 Wireless Controllers. Para utilizar un MacBook para tomar el control de las capturas de paquetes Air, consulte este documento Recopilar capturas de paquetes sobre el aire en un MacBook
Una vez que el AP recibió la consulta mDNS del usuario de servicio, genera una respuesta mDNS y la envía a través de la red inalámbrica. La respuesta se origina también con la dirección IP y el complemento MAC del punto de acceso, el destino es la dirección MAC del usuario de servicio (cliente inalámbrico), pero la dirección IP mDNS se utiliza con los servicios necesarios incluidos como respuestas, lo que significa que este paquete va al usuario de servicio y es un paquete mDNS.
Desde el paquete, también se puede ver cómo el AP utiliza su propia dirección IP en la sección IP para originar el paquete hacia la dirección IP mDNS junto con el puerto mDNS UDP 5353, ya que el AP está actuando como gateway mDNS.
A partir de la depuración, se puede ver que la respuesta mDNS se envió al usuario de servicio, la manera de saber que la respuesta mDNS fue para el usuario de servicio específico es verificar la dirección MAC del usuario de servicio y la dirección MAC del punto de acceso en la respuesta. Están juntos como se ve en la parte resaltada de la depuración que se muestra a continuación, como se ve en el paso anterior en la captura de paquetes, la dirección MAC del usuario del servicio es a6c515dcdd57 y la dirección MAC del punto de acceso es 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
Los pasos anteriores completan un flujo de paquetes mDNS correcto para el switching local de FlexConnect, donde el proveedor de servicios estaba conectado por cable en la Vlan 11, el AP en la Vlan 10 y el usuario de servicio en la Vlan 21.
El proveedor de servicios inalámbricos funciona exactamente igual que el mecanismo del proveedor de servicios por cable, envía un sondeo y también un anuncio para los servicios, la memoria caché de AP para los servicios y los guarda en la base de datos. Esta sección pretende explicar cómo el AP que hace el gateway mDNS aprende los servicios cuando el proveedor de servicios está conectado vía inalámbrica.
La diferencia entre un proveedor de servicios por cable y uno inalámbrico es la forma en que el paquete se ve por el aire desde que se produce 802.11. En el siguiente paquete se puede ver cómo el proveedor de servicios inalámbricos en Vlan 11 envía un paquete mDNS con su propia dirección MAC y dirección IP de origen y el destino es la dirección Mac mDNS y los complementos IP, a través del puerto UDP 5353 con los servicios enumerados como respuestas.
Desde los debugs de AP, se puede ver cómo el AP obtiene un paquete mDNS inalámbrico y agrega los servicios aprendidos a la base de datos.
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
Una vez que el AP almacena en caché los servicios, se crea la base de datos y muestra algunas diferencias en comparación con los servicios del proveedor de servicios por cable, ya que la base de datos del proveedor de servicios inalámbricos en el AP muestra detalles como el nombre SSID, el nombre del sitio (TAG del sitio) y más resaltados que se muestran a continuación.
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
La consulta de servicio de usuario mDNS y la respuesta de gateway mDNS AP son exactamente las mismas que ya se explicaron en la sección Proveedor de servicios por cable, el usuario de servicio envía una consulta mDNS y el mDNS AP actúa como gateway y envía una respuesta al usuario de servicio con los detalles de servicios necesarios.
Solo hay un punto de acceso mDNS principal por etiqueta de sitio y se encarga de dos tareas:
Actualización de información de AP primario desde una perspectiva de AP no primario, tenga en cuenta que todos los AP están en la VLAN 10 en este sitio:
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#
El AP mDNS primario que informa a los otros APs sobre los servicios aprendidos en la ETIQUETA DEL SITIO y la red a la que pertenece el AP primario, una vez que el paquete informativo mDNS alcanza los otros APs en la misma etiqueta del sitio, la base de datos de caché mDNS se actualiza en los APs si se aprenden nuevos servicios:
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
Actualización de la base de datos mDNS AP principal al 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
Los servicios informados por el AP Primario al WLC proporcionan información que contiene los servicios aprendidos, si los servicios son aprendidos vía Wired o Wireless por los AP (en este ejemplo es un proveedor de servicio por cable), la ETIQUETA del sitio y la VLAN de la que fueron aprendidos y el nombre del proveedor de servicio. Para el proveedor de servicios inalámbricos, la ID de WLAN refleja la WLAN a la que está conectado el proveedor de servicios.
La lista y las políticas del servicio mDNS permiten controlar los servicios mDNS permitidos en la red. Aquí se incluye un ejemplo de cómo se filtran los servicios mDNS no permitidos en las listas de servicios IN y OUT.
Para ver los servicios que se están anunciando o consultando, pero que no están permitidos, habilite esta depuración en el AP:
Estos servicios mDNS
No están permitidos, ya que no están configurados y seleccionados en la lista de servicios configurada en la opción Seleccionar servicios mDNS.
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.
En caso de que se necesite una lista de servicio especial, se debe agregar la misma a la sección de definición de servicio en la configuración mDNS en el WLC.
Una vez que los servicios se agregan como un servicio en el WLC y se seleccionan en la lista de servicios IN y OUT, se envían a los AP de FlexConnect a través de la política de servicio mDNS.
Para ello, necesitamos conocer el servicio exacto que se necesita y, desde la sección Definición de servicio, agregar un nombre personalizado para el servicio y la cadena de servicio.
En este ejemplo, he agregado los dos servicios filtrados por los puntos de acceso de la puerta de enlace mDNS en la sección Services not allowed per mDNS Service List (Servicios no permitidos por lista de servicios mDNS).
Este documento no cubre el modo de conexión en puente mDNS debido al hecho de que este modo mDNS se trata como tráfico de datos regular desde la perspectiva AP en FlexConnect Local Switching. Cuando el modo de bridging está habilitado para mDNS en el switching local de FlexConnect, el AP simplemente reenvía los paquetes mDNS recibidos desde la red por cable o inalámbrica. Estos paquetes se reenvían sólo en la misma VLAN, lo que significa que el proveedor de servicios y el usuario de servicios deben estar en la misma VLAN para que mDNS funcione. La conexión en puente mDNS no funciona en las VLAN.
Si mDNS no es deseado en algunas WLANs pero sí es necesario en otras WLANs, la caída del modo mDNS se puede configurar por WLANs. Una vez que se activa la eliminación de mDNS, mDNS no pasa a través de los dispositivos conectados a la WLAN.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
29-Jul-2024 |
Versión inicial |