Configuration de FlexConnect mDNS dans le contrôleur LAN sans fil 9800

Introduction

Ce document décrit comment configurer la passerelle mDNS (Multicast Domain Name System) FlexConnect dans le contrôleur LAN sans fil 9800.

Conditions préalables

Exigences

Cisco recommande de posséder des connaissances sur ces sujets :

• Concepts mDNS du contrôleur LAN sans fil 9800
• Concepts de commutation locale FlexConnect

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Gamme de contrôleurs sans fil Catalyst 9800 (Catalyst 9800-L), Cisco IOS® XE Cupertino 17.9.5
• Routeurs à services intégrés (ISR), Cisco IOS® XE Gibraltar 17.6.5
• Commutateur Catalyst 3560, Cisco IOS® 15.2.4E10
• Point d'accès 9117AXI-B, Point d'accès 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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

mDNS (Multicast Domain Name System) est un protocole qui offre la flexibilité nécessaire pour découvrir et partager des services entre les fournisseurs de services (SP) et les utilisateurs de services (clients sans fil). Les fournisseurs de services sont des périphériques qui fournissent un service, tels que des imprimantes, des téléviseurs intelligents, des services de partage de fichiers, etc., que les utilisateurs de services peuvent utiliser.

Le protocole mDNS est basé sur UDP et utilise le port 5353, l'adresse Mac 01:00:5E:00:00:FB et l'adresse IP 224.0.0.251 pour IPv4 et FF02::FB pour IPv6.

Il y a deux modes que mDNS fonctionne dans le WLC : Bridging et Gateway. Le mode de pontage fonctionne uniquement dans le même VLAN (couche 2) où le fournisseur de services et l’utilisateur de services doivent se trouver dans le même sous-réseau. Le mode passerelle fonctionne avec le fournisseur de services et l'utilisateur de services dans le même VLAN ou dans des VLAN différents, le WLC ou l'AP faisant Bonjour Gateway pour mettre en cache les services du fournisseur de services et les partager avec les utilisateurs de services.

Ce document est basé sur la commutation locale mDNS FlexConnect seulement, qui dans ce cas le point d'accès agit comme la passerelle mDNS pour mettre en cache les services annoncés par les fournisseurs de services et partage ces services avec les utilisateurs de services.  

Remarque : pour la configuration mDNS de commutation centrale, reportez-vous à la section Comprendre mDNS sur le contrôleur sans fil Catalyst 9800

Diagramme du réseau

Le fournisseur de services filaires et sans fil annonce les services mDNS dans un environnement de commutation locale FlexConnect, ainsi qu'un client sans fil (utilisateur de services) qui utilise les services mDNS.

Configurations

Activer mDNS globalement dans le WLC

Pour que l'AP fonctionne comme passerelle mDNS, la fonctionnalité doit être activée en activant la passerelle mDNS globalement.

GUI WLC

Configuration globale mDNS

CLI WLC

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

Sélectionner les services mDNS dans une liste de services

Configurez une liste de services pour autoriser les services mDNS de préférence. La liste doit être configurée dans deux directions, IN et OUT, qui filtrent les services d'entrée et de sortie autorisés par le point d'accès agissant comme passerelle mDNS.

GUI WLC

Sélectionnez les services requis dans la liste des services

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#

Fusionner les listes de services avec une stratégie de service

Une fois que les listes de services IN et OUT sont configurées avec les services nécessaires, une stratégie de service est utilisée pour les fusionner. Une fois fusionnée, cette stratégie de service peut être utilisée dans la stratégie WLAN, le profil FlexConnect et la stratégie mDNS Flex.

GUI WLC

Fusionner les listes de services mDNS dans une stratégie mDNS

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#

Configurer un profil flexible mDNS

Dans le profil flexible mDNS, les VLAN de commutation locale FlexConnect où mDNS est utilisé doivent être ajoutés au profil flexible, le VLAN du fournisseur de services et de l'utilisateur de services doit être ajouté au profil flexible mDNS, ainsi que la stratégie de service mDNS qui permet de filtrer les services par câble. 

GUI WLC

Créer un profil mDNS FlexConnect

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#

Configuration du WLAN avec le mode passerelle mDNS

Par défaut, chaque réseau local sans fil utilise le mode mDNS comme mode de pontage. Pour que le point d'accès sache quand agir en tant que passerelle mDNS pour les fournisseurs de services connectés via le sans fil et pour les utilisateurs de services, le WLAN doit être configuré avec mDNS en mode passerelle.

GUI WLC

Configurez le SSID en mode passerelle mDNS

CLI WLC

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

Avertissement : les modifications de configuration dans le WLAN provoquent l'abandon des clients sans fil connectés du SSID. Soyez prudent en cas de modification de la configuration des réseaux locaux sans fil pendant la production.

Application de la stratégie de service mDNS à la stratégie WLAN

Pour les fournisseurs de services sans fil et les fournisseurs d'utilisateurs sans fil, les services mDNS sont filtrés avec la stratégie mDNS précédemment configurée une fois qu'elle est appliquée à la stratégie WLAN des WLAN.

GUI WLC

Attribution de la stratégie mDNS

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#

Avertissement : les modifications de configuration apportées à la stratégie WLAN provoquent l'abandon des clients sans fil connectés du WLAN. Soyez prudent avec toute configuration dans la politique WLAN pendant la production.

Remarque : pour une configuration FlexConnect générale, reportez-vous à la section Comprendre FlexConnect sur le contrôleur sans fil Catalyst 9800

Configurer le profil flexible mDNS dans la stratégie FlexConnect 

Dans la politique FlexConnect, où la configuration comme les VLAN, les ACL et plus encore sont appliquées, le profil Flex mDNS doit être sélectionné pour l'appliquer aux AP qui appartiennent à la politique FlexConnect.

GUI WLC

Attribuer le profil flexible mDNS

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#

Vérifier

À partir du WLC et de l'AP, la configuration peut être vérifiée avec ces commandes.

Commandes show du WLC

Un exemple de configuration mDNS FlexConnect générale peut être vérifié à l'aide des commandes suivantes :

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

Le mode WLAN mDNS peut être vérifié avec cette commande :

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

La configuration mDNS de la stratégie WLAN peut être vérifiée à l'aide de cette commande :

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

Commandes show AP

La configuration relative à mDNS peut être vérifiée du côté AP avec ces commandes :

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

Dépannage

À des fins de dépannage, ce document va expliquer le flux de travail par lequel mDNS passe dans la commutation locale FlexConnect. Il est important de se rappeler que le WLC n'aura aucun rôle dans la façon dont mDNS est géré en raison du mode de déploiement qui est la commutation locale FlexConnect.

Le point d'accès lui-même va être le périphérique de passerelle mDNS, le point d'accès apprend les services des fournisseurs de services et partage les services avec l'utilisateur de services, ceci alors que le point d'accès, le fournisseur de services et l'utilisateur de services sont placés dans différents VLAN.

Section Par schéma de réseau :

• Le fournisseur de services se trouve dans le VLAN 11
• L'utilisateur du service est dans le VLAN 21
• Le point d'accès se trouve dans le VLAN 10

Fournisseur de services filaires

Une fois qu’il détecte une connectivité au réseau, le fournisseur de services utilise un mécanisme appelé sonde, il envoie une requête mDNS pour s’assurer qu’il existe un autre périphérique réseau qui offre ou non les mêmes services mDNS. Après l'analyse, le fournisseur de services filaires utilise un mécanisme d'annonce, il envoie une réponse de type mDNS pour annoncer les services qu'il prend en charge.

Ensuite, une capture de paquets est effectuée à partir du port de commutation AP de la passerelle mDNS, qui montre que le fournisseur de services annonce les services qu'il prend en charge. Le paquet provient de l'adresse MAC et de l'adresse IP du fournisseur de services dans le VLAN 11 et il a une destination de l'adresse MAC et de l'adresse IP de mDNS, y compris le port mDNS 5353 sur UDP, il contient également les réponses qui sont les services pris en charge par le fournisseur de services.

La section des réponses dans l'image suivante montre les services de notre intérêt qui sont airplay et spotify, plus tard l'AP cache ces services et les enregistrer dans la base de données.

Services du fournisseur de services mDNS

À partir de l'interface de ligne de commande de l'AP, le fournisseur de service filaire annonce peut également être vu, pour voir toutes les informations mDNS de l'AP lui-même ces débogages doivent être activés :

• 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

Une fois que le point d'accès apprend les services, il les enregistre dans la base de données.

Les services enregistrés dans la base de données AP peuvent être vérifiés avec cette commande :

• AP#show mdns cache

Pour les besoins de ce document, le résultat suivant montre les informations pertinentes pour prouver que le point d'accès de passerelle mDNS a dans son cache les services, cependant, le résultat est plus long.

Ensuite, mettez en surbrillance les services, l’adresse MAC du fournisseur de services et le VLAN où ils ont été appris.

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

Une fois que le fournisseur de services filaires a annoncé les services et que le point d'accès a mis en cache les services et enregistré dans sa base de données comme indiqué dans les étapes précédentes, l'utilisateur de services (client sans fil) cherche à mettre en miroir le contenu du périphérique (ordinateur portable) sur le téléviseur intelligent pour un affichage miroir. Pour réaliser l'affichage miroir, l'utilisateur du service utilise le service de diffusion dans cet exemple.

Étant donné que l'utilisateur de service est connecté via une connexion sans fil, une capture de paquets Over the Air était nécessaire pour voir le flux mDNS de connexion du côté de l'utilisateur de service.

À partir des captures Over the Air, on peut voir comment l'utilisateur de service qui est le client sans fil dans le VLAN 21, envoie une requête mDNS avec l'adresse MAC de destination 802.11 de mDNS et à partir de la section IP Address, l'adresse IP de mDNS est utilisée ainsi que la destination, le port est UDP 5353 et dans les requêtes mDNS, la diffusion est demandée. En tant que source, l'adresse MAC de l'utilisateur du service a été utilisée avec son adresse IP.

Demande de services utilisateur du service mDNS

À partir du débogage AP, on peut voir comment l'AP reçoit un paquet mDNS sans fil. Le débogage affiche les services demandés qui sont les mêmes services que ceux que la capture de paquets de l'étape précédente a montrés. Les débogages mDNS utilisés sont les suivants :

• 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'

Remarque : pour reprendre les captures de paquets Air avec un point d'accès en mode renifleur, reportez-vous à ce document Configurer le point d'accès en mode renifleur sur les contrôleurs sans fil Catalyst 9800. Pour utiliser un MacBook pour prendre le contrôle des captures de paquets Air, veuillez vous reporter à ce document Collecter des captures de paquets Over the Air sur un MacBook

Une fois que le point d'accès a reçu la requête mDNS de l'utilisateur du service, il crée une réponse mDNS et l'envoie sur le réseau sans fil. La réponse provient également de l'ajout MAC du point d'accès et de l'adresse IP, la destination est l'adresse MAC de l'utilisateur de service (client sans fil), mais l'adresse IP mDNS est utilisée avec les services nécessaires inclus comme réponses, ce qui signifie que ce paquet va à l'utilisateur de service et qu'il s'agit d'un paquet mDNS.

À partir du paquet, on peut également voir comment le point d'accès utilise sa propre adresse IP dans la section IP pour envoyer le paquet vers l'adresse IP mDNS avec le port UDP 5353 mDNS, puisque le point d'accès agit comme passerelle mDNS.

Réponse des services mDNS du point d'accès

À partir du débogage, il peut être vu que la réponse mDNS a été envoyée à l'utilisateur de service, la façon de savoir que la réponse mDNS était pour l'utilisateur de service spécifique est de vérifier l'adresse MAC de l'utilisateur de service et l'adresse MAC du point d'accès dans la réponse. Ils sont regroupés comme indiqué dans la partie mise en surbrillance du débogage suivant, comme indiqué à l'étape précédente de la capture de paquets, l'adresse MAC de l'utilisateur de service est a6c515dcdd57 et l'adresse MAC du point d'accès est 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

Les étapes précédentes permettent d'effectuer un flux de paquets mDNS réussi pour la commutation locale FlexConnect, où le fournisseur de services était connecté par câble dans le VLAN 11, le point d'accès dans le VLAN 10 et l'utilisateur de services dans le VLAN 21.

Fournisseur de services sans fil

Le fournisseur de services sans fil fonctionne exactement de la même manière que le mécanisme du fournisseur de services câblés, il envoie un sondage et également une annonce pour les services, le point d'accès met en cache les services et les enregistre dans la base de données. Cette section a pour but d'expliquer comment le point d'accès faisant la passerelle mDNS apprend les services quand le fournisseur de services est connecté via le sans fil.

La différence entre un fournisseur de services filaire et un fournisseur de services sans fil réside dans la manière dont le paquet regarde dans les airs depuis que la norme 802.11 a été appliquée. Dans le paquet suivant, il peut voir comment le fournisseur de services sans fil dans le VLAN 11 envoie un paquet mDNS avec sa propre adresse MAC et sa propre adresse IP source et la destination est l'adresse Mac mDNS et les ajouts IP, sur le port UDP 5353 avec les services répertoriés comme réponses.

Services mDNS du fournisseur de services sans fil

À partir des débogages d'AP, on peut voir comment l'AP obtient un paquet mDNS sans fil et ajoute les services appris à la base de données.

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

Une fois que le point d'accès met en cache les services, la base de données est construite et montre quelques différences par rapport aux services du fournisseur de services câblés, puisque la base de données du fournisseur de services sans fil dans le point d'accès affiche des détails tels que le nom SSID, le nom du site (balise de site) et plus en surbrillance ci-dessous.

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 requête du service utilisateur mDNS et la réponse de la passerelle AP mDNS sont exactement les mêmes que celles déjà expliquées dans la section Fournisseur de services filaires. L'utilisateur de service envoie une requête mDNS et l'AP mDNS agit comme une passerelle et envoie une réponse à l'utilisateur de service avec les détails des services nécessaires. 

Point d'accès mDNS principal

Il n'y a qu'un seul point d'accès mDNS principal par balise de site et il est responsable de deux tâches :

1. Gardez toutes les bases de données mDNS des AP mises à jour tant qu'elles appartiennent à la même balise de site, de sorte que la base de données mDNS de chaque AP soit la même et qu'il n'y ait pas de services mDNS manquants.
2. Informer le WLC des services mDNS appris sur le site distant (ceci est juste informatif et à des fins de gestion seulement, le WLC ne peut pas utiliser ces services).

Point d'accès principal informer la mise à jour d'une perspective de point d'accès non principal, gardez à l'esprit tous les points d'accès sont dans le VLAN 10 dans ce 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#

Point d'accès mDNS principal informant les autres points d'accès sur les services appris dans la balise de site et le réseau auquel le point d'accès principal appartient, une fois que le paquet d'informations mDNS atteint les autres points d'accès dans la même balise de site, la base de données de cache mDNS est mise à jour dans les points d'accès si de nouveaux services sont appris :

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

Mise à jour de la base de données principale AP mDNS vers le 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

Les services informés par le point d'accès principal au WLC fournissent des informations qui contiennent les services appris, si les services sont appris via filaire ou sans fil par les points d'accès (dans cet exemple, c'est un fournisseur de service filaire), la balise de site et le VLAN à partir desquels ils ont été appris et le nom du fournisseur de service. Pour le fournisseur d'accès sans fil, l'ID WLAN reflète le WLAN auquel le fournisseur d'accès est connecté.

Surveillance des services mDNS depuis l'interface graphique WLC

Services non autorisés par liste de services mDNS 

La liste et les politiques de services mDNS permettent de contrôler les services mDNS autorisés sur le réseau, voici un exemple de la façon dont les services mDNS non autorisés dans la liste de services IN et OUT sont filtrés.

Pour voir les services annoncés ou interrogés, mais non autorisés, veuillez activer ce débogage dans l'AP :

• AP#debug mdns errors

Ces services mDNS

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

Ne sont pas autorisés, car ils ne sont pas configurés et sélectionnés dans la liste de services configurée dans le Sélectionner les services 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.

Configuration des services mDNS personnalisés dans la définition de service

Si une liste de services spéciale est nécessaire, la même chose doit être ajoutée à la section Définition de service dans la configuration mDNS dans le WLC.

Une fois que les services sont ajoutés en tant que service dans le WLC et sélectionnés dans la liste de services IN et OUT, ils sont poussés vers les points d'accès FlexConnect via la politique de service mDNS.

Pour ce faire, nous devons connaître le service exact requis et, à partir de la section Définition de service, ajouter un nom personnalisé pour le service et la chaîne de service.

Dans cet exemple, j'ai ajouté les deux services qui ont été filtrés par les points d'accès de passerelle mDNS dans la section Services non autorisés par liste de services mDNS.

Définition de service personnalisé mDNS

Mode de pontage mDNS FlexConnect

Ce document ne couvre pas le mode de pontage mDNS parce que ce mode mDNS est traité comme un trafic de données régulier du point de vue AP dans la commutation locale FlexConnect. Lorsque le mode de pontage est activé pour mDNS dans la commutation locale FlexConnect, le point d'accès transfère simplement les paquets mDNS reçus du réseau filaire ou sans fil. Ces paquets sont transférés uniquement dans le même réseau local virtuel, ce qui signifie que le fournisseur de services et l’utilisateur de services doivent se trouver dans le même réseau local virtuel pour que mDNS fonctionne. Le pontage mDNS ne fonctionne pas sur les réseaux locaux virtuels.

Mode d'abandon mDNS Flexconnect

Si mDNS n'est pas requis dans certains WLAN, mais qu'il est en effet nécessaire dans d'autres WLAN, la suppression du mode mDNS peut être configurée par WLAN. Une fois que la suppression mDNS est activée, mDNS ne passe pas par les périphériques connectés au WLAN.

mDNS drop mode