Configurar o FlexConnect mDNS no controlador de LAN sem fio 9800

Introdução

Este documento descreve como configurar o gateway do Sistema de Nome de Domínio (mDNS) Multicast FlexConnect no Controlador LAN sem fio 9800.

Pré-requisitos

Requisitos

A Cisco recomenda que você conheça estes tópicos:

• Conceitos mDNS do controlador de LAN sem fio 9800
• Conceitos do FlexConnect Local Switching

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Catalyst 9800 Wireless Controller Series (Catalyst 9800-L), Cisco IOS® XE Cupertino 17.9.5
• Roteadores de Serviços Integrados (ISR), Cisco IOS® XE Gibraltar 17.6.5
• Switch Catalyst 3560 Series, Cisco IOS® 15.2.4E10
• Access point 9117AXI-B, Access point 9130AXI-B

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

O Multicast Domain Name System (mDNS) é um protocolo que oferece flexibilidade para descobrir e compartilhar serviços entre provedores de serviços (SP) e usuários de serviços (clientes sem fio). Os provedores de serviços são dispositivos que fornecem um serviço como impressoras, smart tv, serviços de compartilhamento de arquivos e muito mais que os usuários de serviços podem utilizar.

O protocolo mDNS é baseado em UDP, utiliza a porta 5353, Endereço Mac 01:00:5E:00:00:FB e Endereço IP 224.0.0.251 para IPv4 e FF02::FB para IPv6.

Há dois modos em que o mDNS funciona no WLC: Bridging e Gateway. O modo de Bridging funciona apenas na mesma Vlan (camada dois) em que o Provedor de Serviços e o Usuário de Serviços devem estar na mesma sub-rede. O modo de gateway funciona com o provedor de serviços e o usuário de serviços nas mesmas Vlans ou em diferentes, com a WLC ou o AP fazendo o gateway Bonjour para armazenar em cache os serviços do provedor de serviços e compartilhá-los com os usuários de serviços.

Este documento é baseado somente no mDNS FlexConnect Local Switching, que, neste caso, o AP atua como o Gateway mDNS para armazenar em cache os serviços anunciados pelos provedores de serviço e compartilha esses serviços com os usuários de serviço.  

Observação: para a configuração mDNS de switching central, consulte Compreender mDNS no Catalyst 9800 Wireless Controller

Diagrama de Rede

Os provedores de serviços com e sem fio anunciam os serviços mDNS em um ambiente de switching local FlexConnect, juntamente com um cliente sem fio (usuário do serviço) que utiliza os serviços mDNS.

Configurações

Ativar o mDNS globalmente no WLC

Para que o AP funcione como Gateway mDNS, o recurso precisa ser ativado habilitando o Gateway mDNS globalmente.

GUI da WLC

Configuração global do mDNS

CLI WLC

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

Selecionar serviços mDNS em uma lista de serviços

Configure uma lista de serviços para permitir os serviços mDNS de preferência. A lista deve ser configurada em duas direções, que são IN e OUT, que filtram quais serviços de entrada e saída são permitidos pelo Ponto de acesso que atua como gateway mDNS.

GUI da WLC

Selecione os serviços necessários na Lista de serviços

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#

Mesclar as listas de serviços com uma política de serviços

Depois que a Lista de serviços IN e OUT é configurada com os serviços necessários, uma Política de serviço é usada para mesclá-los. Depois de mesclada, essa política de serviço pode ser usada na política de WLAN, no perfil FlexConnect e na política de mDNS Flex.

GUI da WLC

Mesclar as listas de serviço mDNS em uma política 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#

Configurar um perfil mDNS Flex

No mDNS Flex Profile, as Vlans de switching local do FlexConnect onde o mDNS é usado precisam ser adicionadas ao Flex Profile, a Vlan do provedor de serviços e do usuário de serviços deve ser adicionada ao mDNS Flex Profile, junto com a Política de serviços do mDNS, que permite filtrar os serviços por meio de rede com fio. 

GUI da WLC

Criar um perfil do 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#

Configurar a WLAN com o Modo de Gateway mDNS

Cada WLAN tem, por padrão, o modo mDNS como Bridging. Para que o AP saiba quando atuar como um Gateway mDNS para Provedores de Serviço conectados via rede sem fio e para Usuários de Serviço, a WLAN deve ser configurada com mDNS como modo de Gateway.

GUI da WLC

Configurar o SSID no modo Gateway mDNS

CLI WLC

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

Aviso: as alterações de configuração na WLAN provocam a queda de clientes sem fio conectados do SSID. Tome cuidado com qualquer alteração de configuração nas WLANs durante o tempo de produção.

Aplique a política de serviço mDNS à política de WLAN

Para provedores de serviços sem fio e provedores de usuários sem fio, os serviços mDNS são filtrados com a política mDNS previamente configurada, uma vez que ela é aplicada à política de WLAN das WLANs.

GUI da WLC

Atribuir a política 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#

Aviso: as alterações de configuração na Política de WLAN provocam a queda de clientes sem fio conectados da WLAN. Tenha cuidado com qualquer configuração na Política de WLAN durante o tempo de produção.

Observação: para obter a configuração geral do FlexConnect, consulte Compreender o FlexConnect no Catalyst 9800 Wireless Controller

Configurar perfil mDNS Flex na política do FlexConnect 

Na política do FlexConnect, onde configurações como Vlans, ACLs e outras são aplicadas, o perfil do mDNS Flex precisa ser selecionado para aplicá-lo aos APs que pertencem à política do FlexConnect.

GUI da WLC

Atribuir o perfil mDNS Flex

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#

Verificar

A partir da WLC e do AP, a configuração pode ser verificada com esses comandos.

Comandos show da WLC

Um exemplo de configuração geral do FlexConnect mDNS pode ser verificado com estes 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

O modo mDNS da WLAN pode ser verificado com este comando:

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

A configuração mDNS da política de WLAN pode ser verificada com 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

Comandos show do AP

A configuração relacionada ao mDNS pode ser verificada do lado do AP com estes 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

Troubleshooting

Para fins de solução de problemas, este documento explicará o fluxo de trabalho pelo qual o mDNS passa no FlexConnect Local Switching. É importante lembrar que a WLC não terá nenhuma função em como o mDNS está sendo gerenciado devido ao modo de implantação, que é o FlexConnect Local Switching.

O próprio AP será o dispositivo Gateway mDNS, o AP aprenderá os serviços dos Provedores de Serviços e compartilhará os serviços com o Usuário de Serviços, enquanto o AP, o Provedor de Serviços e o Usuário de Serviços são colocados em Vlans diferentes.

Por seção do diagrama de rede:

• O provedor de serviços está na VLAN 11
• O usuário do serviço está na VLAN 21
• O Ponto de Acesso está na Vlan 10

Provedor de serviços com fio

Quando o provedor de serviços detecta que há conectividade com a rede, ele usa um mecanismo chamado sonda, e envia uma consulta mDNS para verificar se há qualquer outro dispositivo de rede que ofereça ou não os mesmos serviços mDNS. Após a sonda, o provedor de serviços com fio usa um mecanismo de anúncio, ele envia uma resposta do tipo mDNS para anunciar os serviços aos quais dá suporte.

Em seguida, uma captura de pacote feita da porta de switch do gateway do mDNS, que mostra que o provedor de serviços anuncia os serviços aos quais dá suporte. O pacote tem como origem o endereço MAC e o endereço IP do provedor de serviços na VLAN 11 e tem como destino o endereço MAC e o endereço IP do mDNS, incluindo a porta mDNS 5353 sobre UDP, e também contém as respostas que são os serviços suportados pelo provedor de serviços.

A seção de respostas na imagem a seguir mostra os serviços de nosso interesse que são airplay e spotify, mais tarde o AP cache esses serviços e salvá-los no banco de dados.

Serviços do provedor de serviços mDNS

Na CLI do AP, o provedor de serviços com fio anuncia que também pode ser visto, para ver qualquer informação mDNS do próprio AP, essas depurações devem ser habilitadas:

• 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

Depois que o AP aprende os serviços, ele salva os mesmos no banco de dados.

Os serviços salvos no banco de dados do AP podem ser verificados com este comando:

• AP#show mdns cache

Para os fins deste documento, a próxima saída mostra as informações relevantes para provar que o AP de Gateway mDNS tem em seu cache os serviços, no entanto, a saída é mais longa.

Em seguida, destacou os serviços, o endereço MAC do provedor de serviços e a VLAN onde foi aprendido.

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

Depois que o provedor de serviços com fio anunciar os serviços e o AP tiver armazenado em cache os serviços e salvo em seu banco de dados, como mostrado nas etapas anteriores, o usuário do serviço (cliente sem fio) procura espelhar o conteúdo do dispositivo (laptop) para a smart TV para exibição espelhada. Para realizar a exibição de espelho, o Usuário de serviço utiliza o serviço airplay neste exemplo.

Como o usuário de serviço está conectado via rede sem fio, a captura de pacote via satélite foi necessária para ver o fluxo de mDNS da conexão do lado do usuário de serviço.

Nas capturas Over the Air, pode-se ver como o usuário de serviço, que é o cliente sem fio na VLAN 21, envia uma consulta mDNS com o endereço MAC de destino 802.11 do mDNS e, na seção de endereço IP, o endereço IP do mDNS é usado, bem como o destino, a porta é UDP 5353 e, dentro das consultas mDNS, o airplay é solicitado. Como origem, o Endereço MAC do Usuário de Serviço foi usado junto com seu Endereço IP.

Solicitação de serviços do usuário do serviço mDNS

A partir da depuração do AP, pode-se ver como o AP recebe um pacote mDNS sem fio. A depuração exibe os serviços solicitados, que são os mesmos serviços mostrados pela captura de pacotes na etapa anterior. As depurações mDNS utilizadas são:

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

Observação: para assumir as capturas de pacotes Air com um AP no modo Sniffer, consulte este documento Configurar Ponto de Acesso no Modo Sniffer nos Catalyst 9800 Wireless Controllers. Para usar um MacBook para assumir as capturas de pacotes Air, consulte este documento Coletar capturas de pacotes pelo ar em um MacBook

Depois que o AP recebeu a consulta mDNS do usuário de serviço, ele cria uma resposta mDNS e a envia pela rede sem fio. A resposta é originada com o Access Point MAC Add e o IP Address, o destino é o Service User (cliente sem fio) MAC Address, mas o mDNS IP Address é usado com os serviços necessários incluídos como respostas, o que significa que esse pacote vai para o Service User e é um pacote mDNS.

A partir do pacote, também pode ser visto como o AP usa seu próprio endereço IP na seção IP para originar o pacote em direção ao endereço IP mDNS junto com a porta mDNS UDP 5353, já que o AP está atuando como gateway mDNS.

Resposta de serviços mDNS do AP

A partir da depuração, pode-se ver que a resposta mDNS foi enviada ao Usuário de Serviço, a forma de saber a resposta mDNS foi para o Usuário de Serviço específico é verificar o Endereço MAC do Usuário de Serviço e o Endereço MAC do Ponto de Acesso na resposta. Eles estão juntos como visto na parte destacada da depuração mostrada a seguir, conforme visto da etapa anterior na captura de pacotes, o endereço MAC do usuário do serviço é a6c515dcdd57 e o endereço MAC do ponto de acesso é 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

As etapas anteriores concluem um fluxo de pacote mDNS bem-sucedido para o FlexConnect Local Switching, no qual o provedor de serviços estava conectado na Vlan 11, o AP na Vlan 10 e o usuário de serviço na Vlan 21.

Provedor de serviços sem fio

O provedor de serviços sem fio funciona exatamente da mesma forma que o mecanismo do provedor de serviços com fio, ele envia uma sondagem e também um anúncio para os serviços, o AP armazena em cache os serviços e os salva no banco de dados. Esta seção pretende explicar como o AP que faz o Gateway mDNS aprende os serviços quando o provedor de serviços está conectado via rede sem fio.

A diferença entre um provedor de serviços com e sem fio é como o pacote fica no ar desde que o 802.11 ocorre. No próximo pacote, é possível ver como o provedor de serviços sem fio na VLAN 11 envia um pacote mDNS com origem em seu próprio endereço MAC e endereço IP, e o destino é o endereço Mac mDNS e os ADDs IP, pela porta UDP 5353 com os serviços listados como respostas.

Serviços mDNS do provedor de serviços sem fio

Nas depurações de AP, pode-se ver como o AP obtém um pacote mDNS sem fio e adiciona os serviços aprendidos ao banco de dados.

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

Depois que o AP armazena em cache os serviços, o banco de dados é criado e ele mostra algumas diferenças em comparação com os serviços do provedor de serviços com fio, já que o banco de dados do provedor de serviços sem fio no AP mostra detalhes como nome SSID, nome do site (TAG do site) e mais realçados em seguida.

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

A consulta do Serviço de Usuário mDNS e a resposta do Gateway mDNS AP são exatamente as mesmas já explicadas na seção Provedor de Serviços com Fio, o Usuário de Serviço envia uma consulta mDNS e o mDNS AP atua como um Gateway e envia uma resposta ao Usuário de Serviço com os detalhes de serviços necessários. 

AP mDNS primário

Há apenas um AP mDNS primário por marca de site e ele é responsável por dois trabalhos:

1. Mantenha todos os bancos de dados mDNS dos APs atualizados, contanto que pertençam à mesma TAG de site, para que o banco de dados mDNS de cada AP seja o mesmo e não faltem serviços mDNS.
2. Informe ao WLC sobre os serviços mDNS aprendidos no local remoto (isso é apenas informativo e, somente para fins de gerenciamento, o WLC não pode usar esses serviços).

O AP principal informa a atualização a partir de uma perspectiva de AP não principal, lembre-se de que todos os APs estão na VLAN 10 neste local:

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#

AP mDNS primário informando os outros APs sobre os serviços aprendidos na TAG de site e na rede à qual o AP primário pertence, assim que o pacote informativo mDNS alcançar os outros APs na mesma marca de site, o banco de dados de cache mDNS será atualizado nos APs se novos serviços forem aprendidos:

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

Atualização do banco de dados do AP mDNS primário para o 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

Os serviços informados pelo AP Principal para a WLC fornecem informações que contêm os serviços aprendidos, se os serviços forem aprendidos via Com Fio ou Sem Fio pelos APs (neste exemplo é um Provedor de Serviços com Fio), a TAG do Site e a Vlan da qual foram aprendidos e o nome do Provedor de Serviços. Para o provedor de serviços sem fio, a ID da WLAN reflete a WLAN à qual o provedor de serviços está conectado.

Monitoramento de serviços mDNS a partir da GUI da WLC

Serviços não permitidos por lista de serviços mDNS 

A lista de serviços e as políticas mDNS permitem controlar os serviços mDNS permitidos na rede, aqui está um exemplo de como os serviços mDNS não permitidos na lista de serviços IN e OUT são filtrados.

Para ver os serviços que estão sendo anunciados ou consultados, mas não permitidos, habilite esta depuração no AP:

• AP#debug mdns errors

Esses serviços mDNS

• _airplay-bds._tcp.local
• _despertar._tcp.local

Não são permitidos, pois não estão configurados e selecionados na lista de serviços configurada em Selecionar serviços 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.

Configuração de serviços mDNS personalizados na definição de serviço

Caso seja necessária uma lista de serviços especial, o mesmo deverá ser adicionado à seção Service Definition na configuração mDNS no WLC.

Depois que os serviços são adicionados como um serviço na WLC e selecionados na lista de serviços IN e OUT, eles são enviados para os APs FlexConnect por meio da Política de serviços mDNS.

Para fazer isso, precisamos saber o serviço exato necessário e, na Seção de definição de serviço, adicionar um nome personalizado para o serviço e a sequência de caracteres de serviço.

Neste exemplo, adicionei os dois serviços que foram filtrados pelos APs do gateway mDNS na seção Serviços não permitidos por lista de serviços mDNS.

Definição de serviço personalizado mDNS

Modo de ponte mDNS FlexConnect

Este documento não aborda o modo de Bridging mDNS devido ao fato de que esse modo mDNS é tratado como tráfego de dados regular da perspectiva do AP no FlexConnect Local Switching. Quando o modo de Bridging está ativado para mDNS no FlexConnect Local Switching, o AP simplesmente encaminha os pacotes mDNS recebidos do switch com ou sem fio. Esses pacotes são encaminhados somente na mesma Vlan, o que significa que o provedor de serviços e o usuário de serviços devem estar na mesma Vlan para que o mDNS funcione. O mDNS Bridging não funciona entre Vlans.

Modo drop mDNS do Flexconnect

Se mDNS não for desejado em algumas WLANs, mas for realmente necessário em outras WLANs, a queda do modo mDNS pode ser configurada por WLAN. Quando o descarte de mDNS é habilitado, o mDNS não passa pelos dispositivos conectados à WLAN.

modo drop mDNS