根據Catalyst 9800 WLC上的mDNS連線服務已知問題配置最佳建議設計

簡介

本檔案介紹Cisco Catalyst 9800系列WLC中mDNS的建議設計和使用mDNS的問題案例。

必要條件

需求

思科建議您瞭解以下主題：

• Cisco Catalyst 9800系列無線LAN控制器(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
• Cisco 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本地交換模式的分支機構部署中，通過WAN將廣播/組播mDNS流量傳送回WLC的效率非常低。通過在Flex配置檔案中啟用mDNS AP，接入點本身運行網關引擎。AP在分支機構的本地交換機上建立印表機本地快取，並直接響應分支機構的無線客戶端，使mDNS流量完全不通過WAN鏈路。

橋接

 WLC只需將多點傳播封包橋接至有線/無線網路。僅當客戶端和服務位於完全相同的VLAN上時才非常有用。

drop

所有mDNS資料包都會被丟棄。（對於不支援mDNS以節省通話時間的高密度網路很有用）。

配置最佳實踐

需要檢查以下架構強制配置：

• 有線端流量驗證:9800 mDNS閘道充當局理。如果無線客戶端查詢有線印表機，WLC必須將該查詢轉發到有線網路並接收響應。您必須確認mDNS流量通過有線中繼到WLC。如果上游交換機丟棄UDP 5353，則WLC快取保持為空。
• SVI授權：9800上的mDNS網關模組需要一個活動SVI(介面VLAN)，該SVI的IP地址必須用於其需要監聽的每個VLAN（客戶端和服務VLAN）。 如果這些SVI沒有啟用/啟用，WLC就無法在VLAN之間路由mDNS快取。
• 廣播/組播與無線單播：建議將廣播時間利用率降至最低。通過使用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)，該介面具有其需要窺探的每個VLAN的IP位址（例如，使用者端的介面vlan 10，印表機的介面vlan 20）。 WLC使用此IP來應答查詢。

• 策略控制：必須將mDNS服務策略應用於策略配置檔案。這允許您精確定義允許哪些服務跨越VLAN邊界（例如，允許apple-airprint但拒絕apple-timecpaspure）。通過不使用傳統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 Policy Profile下建立和應用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. 確認具有有效IP的WLC上存在介面VLAN X，且介面VLAN X為up/up。
2. 驗證mDNS策略是否允許所需服務(apple-airplay、apple-airprint)的IN和OUT方向。

案例B:FlexConnect本地交換mDNS故障

症狀

處於FlexConnect模式的AP丟棄mDNS流量或無法應用位置特定服務(LSS)。

補救

1. 導航至Configuration > Tags and Profiles > 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無線電配置。如果您看到違規捨棄，那麼如果RF通道使用率過高，WLC會捨棄該多點傳播流。
• 將違規更改為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 ->伺服器)。

第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（這顯示WLC資料路徑是否因策略或LSS過濾而故意丟棄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中導覽至Troubleshooting > Packet Capture。
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

修訂記錄

修訂	發佈日期	意見
1.0	27-Aug-2026	初始版本