目录

简介

先决条件

要求

使用的组件

核心架构和操作模式

网关（推荐）

中央mDNS网关（本地模式AP）

FlexConnect mDNS AP（分布式网关）

桥接

丢弃

配置最佳实践

最佳实践和要求

有线配置

何时使用mDNS网关（不同的VLAN/企业部署）

SVI要求

设计建议

确保跨网络配置组播配置

常见场景和现场补救

场景 A：跨VLAN服务发现失败(AirPrint/AirPlay)

症状

根本原因分析

补救

场景 B:FlexConnect本地交换mDNS故障

症状

补救

场景 C：CPU使用率过高、MSG_Queue已满或网络降级

症状

补救和隔离（阻止mDNS）

通过mDNS发现Scenario Chromecast，但转换失败(“No Internet Connection”)

症状

补救

场景E:Vocera广播/组播流量丢弃时音频不稳定

症状

根本原因

补救

全面的日志记录和诊断步骤

第 1 阶段：CLI验证检查

第 2 阶段：跟踪和调试机制

第 3 阶段:嵌入式数据包捕获 (EPC)

分析

参考信息和正式文档

简介

本文档介绍Cisco Catalyst 9800系列WLC中mDNS的建议设计和mDNS问题场景。

先决条件

要求

Cisco 建议您了解以下主题：

- Cisco Catalyst 9800系列无线局域网控制器(WLC)组播域名服务器(mDNS)概念

- Cisco Catalyst 9800系列WLC配置

使用的组件

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

- Cisco Catalyst 9800无线控制器系列(Catalyst 9800-CL)、Cisco IOS® XE Cupertino 17.18.3

- Cisco Catalyst 3560系列交换机，Cisco IOS® 15.2.4E10

- 思科Catalyst接入点CW9178

核心架构和操作模式

在排除故障之前，请验证9800应该在哪种模式下运行。应用于策略配置文件的mDNS策略模式规定WLC如何处理mDNS数据包。

网关（推荐）

WLC监听mDNS数据包，构建服务缓存，并通过单播响应不同VLAN的客户端查询。

在网关架构中，有两种基于AP所在位置的部署模式：

中央mDNS网关（本地模式AP）

Cisco Catalyst 9800 WLC本身充当网关。所有mDNS流量通过CAPWAP隧道传输到WLC，WLC在此构建缓存并代理响应。

FlexConnect mDNS AP（分布式网关）

在AP处于FlexConnect本地交换模式的分支机构部署中，通过广域网将广播/组播mDNS流量发送回WLC效率非常低。通过在Flex配置文件中启用mDNS AP，接入点本身运行网关引擎。AP在分支机构的本地交换机上建立打印机本地缓存，并直接响应分支机构的无线客户端，使mDNS流量完全不通过WAN链路。

桥接

WLC只是将组播数据包桥接到有线/无线网络。仅当客户端和服务位于完全相同的VLAN上时才有用。

丢弃

所有mDNS数据包都会被丢弃。（对于不支持mDNS以节省通话时间的高密度网络很有用）。

配置最佳实践

需要检查以下架构强制性配置：

- 有线端流量验证:9800 mDNS网关充当代理。如果无线客户端查询有线打印机，则WLC必须将该查询转发到有线网络并接收响应。您必须确认mDNS流量正在通过有线中继到达WLC。如果上游交换机丢弃UDP 5353，则WLC缓存保持为空。

- SVI规定：9800上的mDNS网关模块需要一个活动SVI（接口VLAN），该SVI的IP地址应分配给需要监听的每个VLAN（客户端和服务VLAN）。 WLC无法在VLAN之间路由mDNS缓存，这些SVI不会打开/打开。

- 广播/组播与空中单播：建议将通话时间利用率降至最低。通过使用mDNS网关，WLC通过单播应答客户端mDNS查询，从而保护RF环境免受过度组播泛洪的影响。不要仅为了修复mDNS而启用全局组播路由。

- 何时使用mDNS桥接（相同VLAN）：当无线客户端（如iPhone）和服务提供商（如Apple TV或AirPrint打印机）位于完全相同的VLAN/子网时。

最佳实践和要求

有线配置

必须在有线交换机上启用全局组播路由和IGMP监听，以便组播流量可以实际到达该VLAN上的其他设备。

- 无线配置：在9800 WLC上，必须启用全局组播和无线广播。

- 警告：不建议对超大型子网（例如/16或/22企业网络）进行桥接。 组播流量以最低的基本数据速率发送，这会消耗大量的无线通话时间和WLC上的CPU。桥接只能用于小型部署或隔离的专用VLAN。

何时使用mDNS网关（不同的VLAN/企业部署）

当无线客户端（例如访客或员工VLAN）和服务提供商（例如打印机VLAN、IoT VLAN）位于不同的VLAN/子网时。这是企业网络的标准部署模式。

SVI要求

9800 WLC 必须具有一个活动的交换虚拟接口(SVI)，该接口的IP地址必须对应于需要监听的每个VLAN（例如，客户端接口VLAN 10，打印机接口VLAN 20）。 WLC使用此IP来应答查询。

- 策略控制：必须将mDNS服务策略应用于策略配置文件。这允许您精确定义允许哪些服务跨越VLAN边界（例如，允许apple-airprint但拒绝apple-timecapsule）。通过不盲目使用传统AireOS概念，正确迁移服务列表。

- 位置特定服务(LSS)：在使用网关的大型企业中，始终启用LSS。这可确保大楼A中的用户只能看到实际位于大楼A中的打印机，而不是看到整个全局网络中缓存的每台打印机。如果在服务策略中未指定位置，则从全局mDNS网关考虑该位置。默认情况下，全局mDNS网关位置定义为lss。

- 活动查询：启用mdns-sd active-query。这允许WLC定期轮询网络的服务，而不是严格等待设备通告自身。

- 同一VLAN分支机构部署（依赖于L2桥接）

设计建议

如果您的部署使用FlexConnect本地交换，并且无线客户端和有线服务（如打印机、Apple TV）都位于完全相同的VLAN（广播域）中

- 完全绕过基于AP的mDNS网关功能。在FlexConnect AP上允许本地第2层桥接。

- 确保在本地分支交换机上启用标准IGMP监听和组播转发。

确保跨网络配置组播配置

要确保组播转发和Bonjour/mDNS通告在所需的VLAN中运行，请端到端检验这些区域：

1. 在WLC上全局启用mDNS网关。

2. 在WLAN策略配置文件下创建并应用mDNS策略。

3. 将所需的服务定义（例如Google Chromecast、AirPlay、打印机等）添加到策略。

4. 确保参与mDNS的客户端VLAN在网络中具有可访问的SVI/接口。

5. 如果流量经过第3层边界，则检验组播路由/PIM配置。

6. 在承载无线VLAN的所有交换基础设施上启用IGMP监听。

7. 确认组播未被ACL、防火墙规则或安全策略阻止。

8. 确保WLAN对等/客户端隔离设置不会阻止所需的服务发现流量。

9. 检验AP交换机端口和中继链路是否允许所需的VLAN。

10. 如果交换设计需要，请确认VLAN中存在查询器功能。

常见场景和现场补救

场景 A：跨VLAN服务发现失败(AirPrint/AirPlay)

症状

VLAN 10上的客户端无法看到VLAN 20上的打印机(AirPrint)。

根本原因分析

- 缺少SVI：如上所述，WLC缺少VLAN 10或VLAN 20的SVI。

- 策略配置错误：应用于客户端策略配置文件的mDNS策略仅允许IN（学习），而不允许OUT（查询）。

补救

1. 确保WLC上的接口VLAN X具有有效的IP且处于up/up状态。

2. 验证mDNS策略是否允许所需服务(apple-airplay、apple-airprint)的IN和OUT方向。

场景 B:FlexConnect本地交换mDNS故障

症状

处于FlexConnect模式的AP丢弃mDNS流量或无法应用位置特定服务(LSS)。

补救

1. 导航到配置>标记和配置文件> Flex。

2. 在Flex配置文件下，确保mDNS选项卡已配置为启用mDNS AP（如果执行分布式网关）。

3. LSS上的注意：如果启用了位置特定服务(LSS),WLC将根据AP的物理位置（MAC/站点标记）过滤服务。如果打印机位于距离AP很远的有线交换机上，LSS可以将其过滤掉。尝试暂时禁用mDNS配置文件中的LSS以隔离问题。

场景 C：CPU使用率过高、MSG_Queue已满或网络降级

症状

WLC日志显示MSG_Queue定期获得全量、数据路径进程的CPU使用率高或mDNS功能完全丢失。

补救和隔离（阻止mDNS）

如果组播环路或Bonjour聊天过多，导致WLC停机，您可能需要临时阻止mDNS以实现稳定性：

要集中阻止mDNS，请创建拒绝UDP 5353的IPv4 ACL并将其应用于无线客户端策略配置文件，或者在Configuration > Services > mDNS下完全禁用mDNS。

1. 禁用mDNS桥接：在大型子网上禁用全局mDNS桥接和无线广播。严格依赖mDNS网关。

2. 审核有线交换机，确保启用IGMP监听，以防止连接到WLC的有线中继上的mDNS泛洪。

场景   通过mDNS发现Chromecast，但转换失败(“No Internet Connection”)

症状

Google Chromecast设备可以成功加入WLAN并被客户端通过mDNS发现。但是，当用户尝试实际播放媒体时，播放失败，并显示以下错误消息：“您没有Internet连接，请检查您的Internet连接。”

补救

启用P2P阻止：启用WLAN对等(P2P)阻止（通常设置为Forward-UpStream以强制客户端到客户端流量通过网关，而不是将其丢弃到AP）。

场景E:Vocera广播/组播流量丢弃时音频不稳定

症状

Vocera徽章会在广播呼叫期间遇到不稳定的音频，或IPTV流严重像素化。

根本原因

如果全局启用了Multicast-Direct，但在媒体流配置下未明确允许特定组播流（例如Vocera 239.x.x.x地址），或者如果AP无线电配置为在带宽已满时丢弃流（准入控制）。

补救

1. 准入控制：检查媒体流的5GHz/2.4GHz无线电配置。如果您看到违规丢弃，则WLC在RF信道利用率过高时丢弃组播流。

- 将违规更改为fallback: ap dot11 5ghz media-stream multicast-direct admission-besteffort（这允许其在单播转换带宽不可用时回退到标准组播）。

2. 流配置：明确定义需要转换的组播IP范围：wireless media-stream group <Stream_Name> <Start_IP> <End_IP>

全面的日志记录和诊断步骤

在排除故障时，请按照以下操作顺序隔离发生中断的位置(Client -> AP -> WLC -> Server)。

第 1 阶段：CLI验证检查

#是否已全局启用mDNS?

show mdns-sd summary

#WLC是否已学习该服务？（查找打印机/电视MAC或IP）

show mdns-sd cache

show mdns-sd cache detail

#查询是否到达WLC并被丢弃？

show mdns-sd statistics

#Is和AP之间是否建立了组播控制平面？

show ap multicast mom

#验证应用到客户端的策略

show wireless profile policy all | inc mDNS

第 2 阶段：跟踪和调试机制

放射性跟踪（始终从此处开始）：对客户端和服务提供商的MAC地址运行RA跟踪。

- debug wireless mac <Client_MAC> internal

- debug wireless mac <Printer_MAC> internal（这显示由于策略或LSS过滤，WLC数据路径是否有意丢弃UDP 5353数据包）。

- Set platform software trace wncd <0-7> chassis active R0 mdns debug

要获取日志，请显示日志：

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

第 3 阶段:嵌入式数据包捕获 (EPC)

为了明确证明数据包是从有线端到达WLC还是从空中离开WLC:

1. 在9800 GUI中导航到故障排除>数据包捕获。

2. 在WLC上行链路（Te0/0/0或端口通道）上设置EPC以验证有线基础设施。

3. 在特定SVI上设置EPC以验证无线路由。

4. 创建面向UDP端口5353的IPv4 ACL。

5. 将PCAP导出到Wireshark并按udp.port == 5353进行过滤 || mdns。

分析

验证WLC从客户端收到查询，对其进行路由，然后向包含打印机/Apple TV详细信息的客户端发送单播响应。

参考信息和正式文档

- 了解Catalyst 9800 WLC上的mDNS