Configurar o design mais recomendado de acordo com problemas conhecidos com serviços mDNS Bonjour no Catalyst 9800 WLC

Introdução

Este documento descreve o projeto recomendado para mDNS e cenários de problemas com mDNS no Cisco Catalyst 9800 Series WLC.

Pré-requisitos

Requisitos

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

• Conceitos do servidor de nome de domínio (mDNS) multicast Wireless LAN Controller (WLC) do Cisco Catalyst 9800 Series
• Configuração de WLC do Cisco Catalyst 9800 Series

Componentes Utilizados

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.

• Controlador sem fio Cisco Catalyst 9800 Series (Catalyst 9800-CL), Cisco IOS® XE Cupertino 17.18.3
• Switch Cisco Catalyst 3560 Series, Cisco IOS® 15.2.4E10
• Access point Cisco Catalyst CW9178

Arquitetura central e modos de operação

Antes da solução de problemas, verifique em que modo o 9800 deve operar. O modo de política mDNS aplicado a um perfil de política determina como a WLC trata os pacotes mDNS.

Gateway (recomendado)

A WLC rastreia pacotes mDNS, cria um cache de serviços e responde, via unicast, às consultas do cliente em diferentes VLANs.

Na arquitetura do Gateway, há dois modelos de implantação baseados em onde o AP está localizado:

Gateway mDNS central (APs de modo local)

A própria WLC do Cisco Catalyst 9800 atua como o gateway. Todo o tráfego mDNS é encapsulado pelo CAPWAP para o WLC, onde o WLC cria o cache e faz o proxy das respostas.

AP mDNS FlexConnect (gateway distribuído)

 Em implantações em filiais, onde os APs estão no modo de switching local FlexConnect, o envio de tráfego mDNS de broadcast/multicast pela WAN de volta para a WLC é altamente ineficiente. Ao habilitar o mDNS AP no perfil Flex, o próprio ponto de acesso executa o mecanismo Gateway. O AP cria um cache local de impressoras no switch local da filial e responde diretamente aos clientes sem fio na filial, mantendo o tráfego mDNS completamente fora do link da WAN.

Bridging

 A WLC simplesmente conecta os pacotes multicast à rede com fio/sem fio. Útil apenas se os clientes e serviços estiverem na mesma VLAN.

Soltar

Todos os pacotes mDNS são descartados. (Útil para redes de alta densidade onde mDNS não é suportado para economizar tempo de transmissão).

Práticas recomendadas de configuração

As seguintes configurações arquitetônicas obrigatórias precisam ser verificadas:

• Validação de tráfego com fio: o gateway mDNS 9800 atua como um proxy. Se um cliente sem fio consultar uma impressora com fio, a WLC deverá encaminhar essa consulta à rede com fio e receber a resposta. Você deve confirmar se o tráfego de mDNS está passando pelos troncos com fio para a WLC. Se o switch upstream descarta o UDP 5353, o cache da WLC permanece vazio.
• Mandato de SVI: o módulo de gateway mDNS no 9800 requer uma SVI (Interface VLAN) ativa com um endereço IP para cada VLAN que precisa rastrear (VLANs de cliente e de serviço). A WLC não pode rotear o cache mDNS entre VLANs sem que essas SVIs estejam up/up.
• Broadcast/Multicast vs. Unicast Over the Air: É recomendável minimizar a utilização do tempo de transmissão. Ao usar o Gateway mDNS, a WLC responde às consultas mDNS do cliente via Unicast, protegendo o ambiente de RF de inundação de multicast excessiva. Não ative o roteamento multicast global apenas para corrigir o mDNS.
• Quando usar o mDNS Bridging (Mesma VLAN): Quando o cliente sem fio, como um iPhone, e o provedor de serviços (como uma impressora Apple TV ou AirPrint) residem exatamente na mesma VLAN/sub-rede.

Práticas recomendadas e requisitos

Configuração com fio 

Você deve ter o Roteamento Multicast global e o Snooping IGMP habilitados em seus switches com fio para que o tráfego multicast possa alcançar fisicamente outros dispositivos nessa VLAN.

• Configuração sem fio: na WLC 9800, você deve habilitar o Multicast global e o broadcast sem fio.
• Advertência: Bridging não é recomendada para sub-redes muito grandes (como /16 ou /22 redes corporativas). O tráfego multicast é enviado à menor taxa básica de dados, que consome quantidades maciças de tempo de transmissão sem fio e de CPU na WLC. O Bridging deve ser usado apenas em pequenas implantações ou em VLANs isoladas e dedicadas.

Quando usar o gateway mDNS (VLANs diferentes / implantações corporativas)

Quando o cliente sem fio (como Guest ou Employee VLAN) e o provedor de serviços (como Printers VLAN, IoT VLAN) residem em VLANs/sub-redes diferentes. Esse é o modelo de implantação padrão para redes corporativas.

Requisito de SVI

A WLC 9800 deve ter uma SVI (Switched Virtual Interface - Interface Virtual Comutada) ativa com um endereço IP para cada VLAN que precise rastrear (por exemplo, interface vlan 10 para clientes, interface vlan 20 para impressoras). A WLC usa esse IP para responder consultas.

• Controle de Política: você deve aplicar uma Política de Serviço mDNS ao Perfil de Política. Isso permite que você defina exatamente quais serviços têm permissão para cruzar os limites da VLAN (por exemplo, permitir apple-airprint, mas negar apple-timecapsule).Migre a lista de serviços adequadamente, não usando os conceitos herdados do AireOS cegamente.
• Serviços específicos de local (LSS): em uma grande empresa usando o Gateway, sempre habilite o LSS. Isso garante que um usuário no Prédio A veja apenas as impressoras localizadas fisicamente no Prédio A, em vez de ver todas as impressoras armazenadas em cache em toda a rede global. Se o local não for especificado na política de serviço, o local será considerado a partir do gateway mDNS global. Por padrão, o local do gateway mDNS global é definido como lss .
• Consulta ativa: Ative mdns-sd ative-query. Isso permite que a WLC faça o poll periódico da rede para obter serviços, em vez de esperar que um dispositivo anuncie a si mesmo.
• Implantações de filiais com a mesma VLAN (confie no L2 Bridging)

Recomendação de projeto

Se a sua implantação utiliza o FlexConnect Local Switching, os clientes sem fio e os serviços com fio (como impressoras, Apple TVs) residem exatamente na mesma VLAN (Domínio de broadcast)

• Ignore totalmente os recursos do gateway mDNS baseado em AP. Permita o bridging nativo de Camada 2 no AP FlexConnect.
• Certifique-se de que o Snooping IGMP padrão e o encaminhamento multicast estejam habilitados no switch da filial local.

Verifique se a configuração multicast está configurada na rede

Para garantir que o encaminhamento multicast e os anúncios Bonjour/mDNS funcionem nas VLANs necessárias, verifique estas áreas fim-a-fim:

1. Ative o gateway mDNS globalmente no WLC.
2. Crie e aplique uma política mDNS no Perfil de Política de WLAN.
3. Adicione as definições de serviço necessárias (por exemplo, Google Chromecast, AirPlay, impressoras e mais) à política.
4. Certifique-se de que as VLANs clientes que participam do mDNS tenham SVIs/interfaces acessíveis na rede.
5. Verifique a configuração do roteamento multicast/PIM se o tráfego atravessar os limites da Camada 3.
6. Ative o rastreamento IGMP em toda a infraestrutura de switching que transporta as VLANs sem fio.
7. Confirme se o multicast não está bloqueado por ACLs, regras de firewall ou políticas de segurança.
8. Verifique se as configurações de isolamento de peer/cliente da WLAN não bloqueiam o tráfego de descoberta de serviços necessário.
9. Verifique se as portas de switch AP e os links de tronco permitem as VLANs necessárias.
10. Confirme se a funcionalidade do consultante existe na VLAN, se exigido pelo projeto de switching.

Cenários comuns e correções de campo

Cenário A: Falha na descoberta de serviços entre VLANs (AirPrint / AirPlay)

Sintoma

Os clientes na VLAN 10 não podem ver as impressoras (AirPrint) na VLAN 20.

Análise da causa raiz

• SVIs ausentes: como observado acima, a WLC não tem uma SVI para VLAN 10 ou VLAN 20.
• Configuração incorreta de política: a política mDNS aplicada ao perfil de política do lado do cliente permite apenas IN (aprendizado), mas não OUT (consulta). 

Correção

1. Verifique se a interface vlan X existe na WLC com um IP válido e está up/up.
2. Verifique se a Política mDNS tem as direções IN e OUT permitidas para os serviços necessários (apple-airplay, apple-airprint).

Cenário B: Falhas do mDNS de switching local do FlexConnect

Sintoma

Os APs no modo FlexConnect estão descartando o tráfego mDNS ou falhando ao aplicar serviços específicos de local (LSS).

Correção

1. Navegue até Configuration > Tags and Profiles > Flex.
2. No perfil Flex, verifique se a guia mDNS está configurada para ativar o AP mDNS (se estiver fazendo gateway distribuído).
3. Observação sobre LSS: se o Location Specific Services (LSS) estiver habilitado, o WLC filtrará os serviços com base na localização física (tag MAC/Site) do AP. Se uma impressora estiver em um switch com fio distante do AP, o LSS poderá filtrá-la. Tente desabilitar temporariamente o LSS no perfil mDNS para isolar o problema.

Cenário C: CPU alta, MSG_Queue cheia ou degradação de rede

Sintoma

Os registros de WLC mostram que MSG_Queue fica cheio, com alta utilização de CPU em processos de caminho de dados ou com perda total de recursos mDNS periodicamente.

Correção e isolamento (bloqueio do mDNS)

Se um loop de multicast ou uma conversa excessiva do Bonjour estiver desativando o WLC, você poderá precisar bloquear temporariamente o mDNS para obter estabilidade:

Para bloquear o mDNS centralmente, crie uma ACL IPv4 que negue o UDP 5353 e aplique-a ao perfil de política do lado do cliente sem fio, ou desabilite totalmente o mDNS em Configuration > Services > mDNS.

1. Desativar mDNS Bridging: Desativar mDNS Bridging global e Wireless Broadcast em sub-redes grandes. Confie estritamente no gateway mDNS.
2. Audite os switches com fio para garantir que o Snooping IGMP esteja habilitado para evitar a inundação de mDNS nos troncos com fio conectados à WLC.

Cenário   Chromecast descoberto via mDNS, mas a conversão falha ("Sem conexão com a Internet")

Sintoma

Os dispositivos do Google Chromecast poderiam se unir com êxito à WLAN e ser descobertos pelos clientes via mDNS. No entanto, quando os usuários tentaram realmente transmitir mídia, a transmissão falhou com a mensagem de erro: "Você não tem conexão com a Internet, verifique sua conexão com a Internet."

Correção

Habilitar bloqueio P2P: habilitado o bloqueio peer-to-peer (P2P) da WLAN (geralmente definido como Forward-UpStream para forçar o tráfego de cliente para cliente através do gateway em vez de soltá-lo no AP).

Cenário E: Áudio cortado em transmissões Vocera / queda de tráfego multicast

Sintoma

Os crachás da Vocera apresentam áudio instável durante as chamadas de difusão, ou os fluxos de IPTV são muito pixelizados.

Causa raiz

Se o Multicast-Direct estiver habilitado globalmente, mas o fluxo multicast específico (como o endereço Vocera 239.x.x.x) não for explicitamente permitido na configuração de fluxo de mídia, ou se o rádio AP estiver configurado para descartar fluxos quando a largura de banda estiver cheia (Controle de Admissão).

Correção

1. Controle de admissão: verifique as configurações de rádio de 5 GHz/2,4 GHz para o fluxo de mídia. Se você vir uma queda de violação, a WLC descartará o fluxo de multicast se a utilização do canal de RF for muito alta.
• Altere a violação para fallback: ap dot11 5ghz media-stream multicast-direct admission-besteffort (isso permite que ele volte para o multicast padrão se a largura de banda de conversão unicast não estiver disponível).
2. Configuração do fluxo: defina explicitamente o intervalo de IP multicast que precisa de conversão: wireless media-stream group <Stream_Name> <Start_IP> <End_IP>

Etapas de registro e diagnóstico abrangentes

Ao Troubleshoot, siga esta ordem de operações para isolar onde a interrupção ocorre (Client -> AP -> WLC -> Server).

Fase 1: Verificações de verificação CLI

# O mDNS está habilitado globalmente?

show mdns-sd summary

# A WLC aprendeu o serviço? (Procure Impressora/TV MAC ou IP)

show mdns-sd cache

show mdns-sd cache detail

# As consultas estão atingindo a WLC e sendo descartadas?

show mdns-sd statistics

#Is plano de controle multicast entre a WLC e o AP foi estabelecido?

show ap multicast mom

# Verificar a política aplicada ao cliente

show wireless profile policy all | inc mDNS

Fase 2: Mecanismos de Rastreamento e Depuração

Traço radioativo (sempre comece aqui): Execute um rastreamento de RA no endereço MAC do cliente E do provedor de serviços.

• debug wireless mac <Client_MAC> internal
• debug wireless mac <Printer_MAC> internal (Isso mostra se o caminho de dados da WLC está descartando intencionalmente o pacote UDP 5353 devido à política ou à filtragem LSS).
• Definir o depurador mdns de R0 ativo do chassi do wcd <0-7> do software da plataforma

Para obter os logs, mostre o log:

show platform software trace message wncd <0-7> chassis ative R0

Fase 3: Captura de pacotes incorporada (EPC)

Para provar definitivamente se os pacotes estão chegando à WLC pelo lado com fio ou deixando a WLC pelo ar:

1. Navegue para Troubleshooting > Packet Capture na GUI do 9800.
2. Configure um EPC no uplink da WLC (Te0/0/0 ou Port-Channel) para validar a infraestrutura com fio.
3. Configure um EPC nas SVIs específicas para validar o roteamento sem fio.
4. Crie uma ACL IPv4 direcionada à porta UDP 5353.
5. Exporte o PCAP para o Wireshark e filtre por udp.port == 5353 || mdns.

Análise

Verifique se a WLC recebe a consulta do cliente, a roteia e envia uma resposta Unicast de volta ao cliente que contém os detalhes da Impressora/Apple TV.

Informações de referência e documentação oficial

• Entender o mDNS no Catalyst 9800 WLC

Histórico de revisões

Revisão	Data de publicação	Comentários
1.0	27-Aug-2026	Versão inicial