設計手冊CX — 適用於大型公共網路的無線

簡介

本文檔介紹大型公共Wi-Fi網路的設計和配置指南。

CX設計手冊

CX設計手冊由思科技術支援中心(TAC)和思科專業服務(PS)的專家撰寫，並由思科內部的專家進行同行評審；這些指南以思科領先實踐以及多年來從無數客戶實施中獲得的知識和經驗為基礎。根據本文檔的建議設計和配置網路有助於避免常見缺陷並改善網路操作。

範圍和定義

本文檔提供大型公共無線網路的設計和配置指南。

定義:大型公共網路 — 通常以高密度進行無線部署，為數千台未知和/或未管理的客戶端裝置提供網路連線。

本文檔通常假定目標網路為大型和/或臨時事件提供服務。它還適用於接待大量訪客的場所的靜態永久網路。例如，購物中心或機場與體育場或音樂會場地的Wi-Fi網路有相似之處，因為對終端使用者沒有控制，而且它們通常只在網路中存在幾個小時，或最多只存在一天。

大型活動或場館的無線覆蓋有它自己的要求，這些要求往往不同於企業、製造甚至大型教育網路。大型公共網路可以容納數千人，集中在一棟或幾棟建築中。它們可以有非常頻繁的客戶端漫遊（持續進行或在高峰期），此外，網路必須儘可能相容無線客戶端裝置方面的任何內容，而不控制客戶端裝置配置或安全。

本指南介紹了用於高密度的通用RF概念以及實施細節。本指南中的許多無線電概念適用於所有高密度網路，與硬體平台無關。但是，實施詳細資訊和配置主要針對使用Catalyst 9800無線控制器的Catalyst無線，因為這是目前為大型公共網路部署的最常見的解決方案。

本檔案會將「無線控制器」和「無線LAN控制器(WLC)」這兩個術語互換使用。

大型公共網路

大型公共網路和活動網路在很多方面都有其獨特性，本文檔對這些關鍵領域進行了探索並提供指導。

• 大型公共網路非常密集；在減少的射頻(RF)空間和大量漫遊中，有成千上萬台裝置可供人們四處走動。某些活動和場所可能會更為靜態，在特定時間出現頻寬峰值。對於進入該區域並在該區域內移動的客戶端，基礎設施需要儘可能平穩地處理所有這些狀態更改。  
• 輕鬆自註冊是重中之重。關聯的客戶端是快樂的客戶端。這表示您希望使客戶端與網路的關聯儘可能快。未連線到Wi-Fi的客戶端會掃描可用接入點，這會產生不需要的射頻能量，進而導致額外擁塞和在空中丟失容量。
• RF部署需要儘可能仔細地設計。如果需要非常高的密度，或者場地有大的開放空間和/或高高的天花板，必須使用定向天線的適當RF設計。
• 另一個關鍵設計驅動器是相容性。某些功能是802.11規範中的標準功能，而其他功能是專有功能，兩者都不會給客戶端帶來任何問題。然而，現實情況卻有所不同，許多程式設計不當的客戶端驅動程式在面對複雜信標或它們不理解的功能/設定時行為不當。
• 由於規模和時間限制，故障排除非常困難。如果某些內容不能與特定客戶端配合使用，則您無法與該終端使用者配合來瞭解問題。使用者可能很難找到，但也可能不合作，因為他們在會場的訪問是暫時的。
• 安全是一個重要的因素。由於訪客數量非常多，且攻擊面大得多，因此控制較少。

外部參照

簡介

本文檔根據從大量部署中獲得的某些方案、假設和知識提供建議。但是，讀者負責確定網路設計、業務、合規性、安全性、隱私性和其他要求，包括是否遵循本指南中提供的指導或建議。

設計網路

RF注意事項

場地型別

本指南主要介紹大型訪客網路，通常對公眾開放，對終端使用者和客戶端裝置型別的控制有限。這些型別的網路可以部署在多種位置，可以是臨時的，也可以是永久的。主要的用例通常是提供網際網路接入給訪問者，雖然這很少是唯一的用例。

典型位置：

• 體育場館
• 會議地點
• 大型禮堂

從RF的角度來看，每種位置型別都有自己的一組細微差別。這些例子中大多數是永久設施，除了會議/音樂會場館，因為這些場館可以是永久的，也可以是臨時的為特定展覽而設定。

其他位置：

• 遊輪
• 機場
• 購物中心/購物中心

機場和遊輪也是適合大型公共網路類別的部署示例；但是，這些技術具有特定於每種情況的額外注意事項，並且通常使用內部全向AP。

覆蓋策略

覆蓋策略主要取決於場地型別、使用的天線以及可用的天線安裝位置。

開銷

儘可能優先使用開銷覆蓋。

開銷解決方案有一個明顯的優勢，即所有客戶端裝置通常都直接到達天線開銷，即使在擁擠的場景中也是如此。使用定向天線的開銷解決方案提供了更受控且定義更明確的覆蓋區域，從無線電調諧的角度來看，使得覆蓋區域更簡單，同時提供了優異的負載平衡和客戶端漫遊特性。參見功率平衡部分以瞭解其他資訊。

客戶端上方的AP

側面

側裝式定向天線是常用的選擇，在各種情況下都能很好地工作，尤其是當由於高度或安裝限制而無法進行額外安裝時。使用側安裝時，瞭解天線所覆蓋的區域型別非常重要，例如，它是開放的室外區域還是密集的室內區域？如果覆蓋區域是人多的高密度區域，那麼天線必須儘可能地高度，因為訊號在人群中的傳播總是很差。請記住，大多數流動裝置用於腰部下部，而不是使用者頭部的上方！當覆蓋區域為較低密度區域時，天線的高度不顯著。

天線高度總是更好

全向

通常必須在非常高密度的場景中避免使用全向天線（內部或外部），這是因為共通道干擾的潛在高影響區域。全向天線不得使用在6米以上的高度（不適用於高增益室外機）。

座位下

在某些體育場或體育場中，可能會出現沒有合適天線安裝位置的情況。最後剩下的備選方案是通過將AP置於使用者坐下的座位下而從下方提供覆蓋。這種型別的解決方案更難正確部署，並且通常成本更高，需要更多的AP和特定的安裝過程。

席位不足部署的主要挑戰是，全場館與空場館的覆蓋範圍存在巨大差異。人體在衰減無線電訊號方面非常有效，這意味著當存在人群圍繞AP時，與沒有人群時相比，最終的覆蓋範圍要小得多。這種人為人群衰減因素允許部署更多無線接入點，從而增加整體容量。然而，當場地空空時，人體沒有衰減，並且受到顯著干擾，這會導致場地部分空滿時的復雜。

附註：席位下部署是一個有效但不常見的解決方案，必須逐個進行評估。本檔案中不再進一步討論座位下部署。

美學

在一些部署中，美學問題開始發揮作用。這些區域可以是具有特定建築設計、歷史價值或空間的地區，在這些區域裡，廣告和/或品牌規定可以安裝裝置（或不能安裝裝置）。可能需要特定的解決方案來解決任何放置限制。其中一些變通方法包括隱藏AP/天線、繪製AP/天線、將裝置安裝在機箱中，或只使用不同的位置。但是，如果選擇了繪製天線，則繪製天線將始終使用非金屬繪製，因此該保修無效。思科一般不銷售天線外殼，但許多產品可通過不同的提供商輕鬆獲得。

所有此類變通方法都會對網路效能產生影響。無線架構師總是從提出最佳安裝位置開始，以獲得最佳無線電覆蓋，而這些初始位置通常提供最佳效能。對這些位置的任何改變通常會導致天線偏離其最佳位置。

天線安裝位置通常是高架的，可以是天花板、貓道、屋頂結構、橫樑、人行道，以及任何在預定覆蓋區域提供一定高程的位置。這些位置通常與其他安裝共用，例如：音訊裝置、空調、照明、監視器和各種探測器/感測器。例如，音訊和照明裝置必須安裝在非常特定的位置 — 但這是為什麼？簡單來說，這是因為音訊和照明裝置隱藏在盒子中或牆壁後面時無法正常工作。

同樣適用於無線天線，當無線客戶端裝置有視線時，它們的工作效果最佳。優先考慮美觀可能會對無線效能產生負面影響，從而降低基礎設施投資的價值（這種情況經常出現）。

欺詐網路

非法Wi-Fi網路是共用一個公共RF空間但不由同一運營商管理的無線網路。這些裝置可以是臨時的或永久的，包括基礎設施裝置(AP)和個人裝置（例如共用Wi-Fi熱點的行動電話）。 惡意Wi-Fi網路是干擾源，在某些情況下還會帶來安全風險。不可低估欺詐對無線效能的影響。Wi-Fi傳輸僅限於在所有Wi-Fi裝置之間共用的相對較小的無線電頻譜，臨近的任何行為不當的裝置都有可能中斷許多使用者的網路效能。

在大型公共網路中，通常使用專用天線精心設計和調整這些網路。良好的RF設計僅覆蓋所需的區域，通常使用具有調諧傳送和接收特性的定向天線來實現最高效率。

頻譜的另一端是消費級裝置，或網際網路服務提供商提供的裝置。這些裝置或者具有有限的RF微調選項，或者配置為提供最大範圍和感知效能，通常採用高功率、低資料速率和寬通道。將此類裝置引入大型事件網路有可能造成嚴重破壞。

我們能做些什麼呢？

就個人熱點而言，能做的事情很少，因為要監控數萬人進入場館幾乎是不可能的。對於基礎設施或半永久性裝置，有一些選擇。可能的補救措施從簡單的教育、通過簽署的無線電政策檔案進行宣傳標牌開始，最後是積極的實施和頻譜分析。在所有情況下，都必須就指定地點內的無線電頻譜保護問題作出業務決定，同時採取具體步驟執行業務決定。

當受第三方控制的裝置通告與託管網路相同的SSID時^,流氓網路的安全方面將發揮作用。這相當於蜜罐攻擊，可用作竊取使用者憑證的方法。始終建議創建欺詐規則，以針對檢測非託管裝置通告的基礎架構SSID發出警報。安全部分更詳細地討論了惡意程式。

單5GHz與雙5GHz

雙5GHz是指在支援的AP上使用兩個5GHz無線電。使用外部天線的雙5GHz和使用內部天線的雙5GHz（例如，全向AP上的微/宏信元）之間存在一個關鍵差異。 在外接天線的情況下，雙5GHz通常是一種有效的機制，可提供額外的覆蓋範圍和容量，同時減少總AP數量。

微型/宏型/微型

內部AP的兩根天線都緊閉在一起（在AP內部），並且在使用雙5GHz時受與最大Tx功率相關的限制約束。第二個無線電被限製為低Tx功率（這由無線控制器實施），從而導致無線電之間的Tx功率有很大不平衡。這會導致主（更高功率）無線電吸引許多客戶端，而輔助（較低功率）無線電利用不足。在這種情況下，第二個無線電向環境增加能量，而沒有給客戶帶來好處。如果觀察到這種情況，最好禁用第二個無線電，在需要額外容量時，只需新增另一個（單個5GHz）AP。

不同的AP型號有不同的配置選項，第二個5GHz無線電可以在較新的宏/中型AP（如9130和9136）中以較高的功率水準運行，而一些內部Wi-Fi 6E AP（如9160系列）甚至可以在宏/宏中運行。請始終驗證準確的AP型號的功能。第二個5GHz插槽的通道使用也受到限制，當一個插槽在一個UNII頻帶中工作時，另一個插槽被限制到不同的UNII頻帶，這影響了通道規劃和隨後的可用傳輸功率。請始終考慮雙5GHz無線電之間的發射功率差異，這在所有情況下都適用，包括帶內建天線的AP。

FRA

靈活無線電分配(FRA)作為一種技術被引入，通過將額外的2.4GHz無線電切換到5GHz模式，或將潛在未使用的5GHz無線電切換到monitor模式（適用於支援它的AP），來提高5GHz覆蓋率。 由於本文檔涵蓋大型公共網路，因此假設使用定向天線可以很好地定義覆蓋區域和無線電設計，因此首選確定性配置而非動態配置。建議不要在大型公共網路中使用FRA。

或者，當網路設定為幫助確定要轉換到5GHz的無線電時，可以使用FRA，但一旦您對轉換結果滿意，建議凍結FRA。

監管

每個監管域都定義可使用哪些通道及其最大功率水準，對室內和室外可使用哪些通道也有限制。根據管制範圍，有時無法有效地利用雙5GHz解決方案。例如，ETSI域在UNII-2e通道上允許30dBm，但在UNII1/2通道上僅允許23dBm。在此示例中，如果設計要求使用30dBm（通常由於到天線的距離較遠），則使用單個5GHz無線電可能是唯一可行的解決方案。

有時，在更高的軟體版本中，會為某些管制網域新增額外通道，但也可能是因為這些通道也具有不同的最大傳輸功率：驗證您的使用者端是否支援這些通道，並僅使用在傳輸功率不會出現問題的AP上。
如果您想使用所有可用通道，最好建立RF配置檔案，其中要求最高發射功率的AP（例如安裝在非常高的天花板上的AP）只使用可用較高功率的通道，並保留較低功率的通道到密度較高的AP靠近地面。

天線

大型公共網路可以使用任何型別的天線，並且通常部署最適合工作的天線。在同一覆蓋區域內混合天線使無線電設計過程更具挑戰性，如果可能必須加以避免。但是，大型公共網路通常具有覆蓋範圍大、安裝選項不同的區域，即使在同一區域內，因此在某些情況下，必須混合天線。 

下表列出了最常用的外部天線：

下表列出了最常用的整合定向天線：

選擇天線時需要考慮的主要因素是天線波束寬度和安裝天線的距離/高度。下表顯示了常用天線的波束寬度，括弧中的數字顯示圓角（更易於記住）值。

表中建議的距離不是硬規則，而是基於經驗的指南。無線電波以光速傳播，在到達任意距離後不會簡單地停止。天線的工作距離均超出建議距離，但是隨著距離的增加，效能會下降。在規劃過程中，安裝高度是關鍵因素。

下圖顯示同一天線在高密度區域大約33英尺（10米）和66英尺（20米）處的兩個可能的安裝高度。請注意，天線可以看到(並接受來自的連接)的客戶端數量會隨著距離增加而增加。隨著距離變長，維持更小的蜂窩尺寸變得更具挑戰性。

一般規則是使用者密度越高，在給定的距離內使用正確的天線就顯得越重要。

體育場天線

CW9179F非常適合覆蓋高距離的高密度區域，有關資訊，請參閱思科無線9179F接入點部署指南。

隨時間推移發生的變化

隨著時間推移，物理環境變化在幾乎所有無線安裝中都很常見（例如，移動內牆或改造場地座椅）。 定期實地考察和目視檢查一直是一個推薦的做法。對於事件網路來說，處理音訊和照明系統，以及在很多情況下處理其他通訊系統（如5G）會更加複雜。 所有這些系統通常安裝在使用者上方的高架位置，有時會導致對同一空間的爭用。無線體育場天線的良好位置通常也是5G天線的良好位置！此外，隨著時間推移，這些系統可以被重新定位到阻礙和/或主動干擾無線系統的位置。必須跟蹤其他安裝，並與安裝它們的團隊進行溝通，以確保所有系統都安裝在合適的位置，彼此之間不會相互干擾（物理或電磁干擾）。

高密度和6GHz

更乾淨且擁塞更少的6GHz頻段可提供比5GHz更佳的體驗，同時由於更多的客戶端裝置採用6GHz，還具有減少5GHz通話時間的額外好處。現代網路應設計為5GHz和6GHz覆蓋範圍，包括大型公共網路。
思科產品組合包括幾台支援6GHz的裝置，可用於高密度部署；9179F用於覆蓋範圍更廣且重點更突出，而91x6D1型號則用於覆蓋範圍更廣的低距離 — 這些產品的組合可支援多種位置的6GHz設計選項。
6GHz覆蓋的設計方法一般與5GHz相同。關於選擇資料速率、通道寬度和Rx-Sop值的准則保持不變，儘管還必須考慮一些額外的6GHz安全配置以及通道規劃和主掃描(PSC)通道使用。

在大型公共網路環境中，這些網路通常具有各種大區域，並且需要在各種高度使用天線組合。由於距離模擬，僅使用60°x60°天線來部署大型公共網路端到端具有挑戰性。因此，對於大型公共網路而言，僅使用CW9166D1在6GHz提供端到端覆蓋也極具挑戰性。

一種可能的方法是使用5GHz作為主覆蓋頻段，同時僅在特定區域使用6GHz以將具有能力的客戶端裝置解除安裝到更乾淨的6GHz頻段。這種型別的方案在較大的區域使用5GHz天線，同時在可能和需要額外容量的地方使用6GHz天線。

本文檔稍後將討論5GHz和6GHz頻段之間的客戶端漫遊。

監管

與5GHz一樣，6GHz的可用功率和通道在管制域之間有很大差異。值得注意的是，FCC和ETSI域之間的可用頻譜有很大差異，以及對於室內和室外使用的可用發射功率、低功率室內(LPI)和標準功率(SP)分別有嚴格的指導方針。對於6GHz，額外的限制包括客戶端功率限制、使用外部天線和天線向下傾斜，以及（目前僅在美國）對SP部署的自動頻率協調(AFC)的要求。

有關Wi-Fi 6E的詳細資訊，請參閱Wi-Fi 6E:Wi-Fi白皮書中的下一個重要章節。

無線電資源管理

無線電資源管理(RRM)是一組控制無線電操作的演算法。本指南參考兩個關鍵的RRM演算法，即動態通道分配(DCA)和傳輸功率控制(TPC)。RRM是靜態通道和電源配置的替代方案。

• DCA按可配置的計畫運行（預設時間為10分鐘）。
• TPC按自動計畫運行（預設時間為10分鐘）。

Cisco Event Driven RRM(ED-RRM)是一個DCA選項，允許在標準DCA計畫之外做出通道更改決定，通常是為了響應嚴重的RF條件。ED-RRM可以在檢測到過多的干擾水準時立即更改通道。在吵鬧和/或不穩定的環境中，啟用ED-RRM會帶來通道更改過多的風險，這對客戶端裝置有潛在的負面影響。

RRM的使用受到鼓勵，並且通常優於靜態配置 — 但是，存在某些警告和例外。

• TPC必須根據需要使用TPC最小/最大設定限制到適當的值範圍，並始終與RF設計保持一致。
  • 在高密度環境中啟用TPC Channel Aware。

• DCA週期必須從預設設定10分鐘更改。
  • 請勿在繁忙、嘈雜和高密度環境中使用ED-RRM。
  • 禁用避免Cisco AP載入。
  • 如果存在許多欺詐，諸如避免外部AP干擾之類的欺詐接入點規避選項可能會導致環境不穩定。移除流氓總是比試圖應對流氓更好。
• RRM決策可能受到不能正確偵聽彼此的AP/天線的影響，如定向天線相互背離的情況。
• 某些天線（例如C9104）不支援RRM，始終需要靜態配置。
• RRM 無法修復不良的RF設計。

在所有情況下，RRM的部署必須理解預期結果，並調整為在適合給定射頻環境的邊界內運行。本文檔後面的部分將更詳細地探討這些要點。

RF配置

通道

一般來說，管道越多越好。在高密度部署中，部署的AP和無線電數量可能比可用通道多幾個數量級，這意味著較大的通道重複使用率，以及更高的同頻干擾水準。必須使用所有可用通道，並且一般不建議限制可用通道清單。

某些情況下，特定（且獨立的）無線系統需要共存於同一物理空間中，並且必須為其分配專用通道，同時從主系統的DCA清單中刪除已分配的通道。必須非常認真地評估這些型別的通道排除，僅在必要時使用。例如，在與主網路相鄰的開放區域中運行的點對點鏈路，或者體育場內的壓力區域。如果從DCA清單中排除超過一個或兩個通道，則會導致重新評估建議的解決方案。在一些情況下，例如密度非常高的體育場館，甚至排除單個通道有時也不是可行的選擇。

動態通道分配(DCA)可與基於WLC的RRM或AI增強的RRM一起使用。

預設DCA間隔為10分鐘，這會導致不穩定的RF環境中的頻繁通道更改。在所有情況下，預設DCA計時器都必須從預設10分鐘增加，特定DCA間隔必須與所討論網路的運行要求保持一致。示例配置可以是：DCA間隔4小時，錨點時間8。這將通道更改限製為每4小時一次，從上午8點開始。

由於干擾是必然的，對每個DCA循環進行自適應不一定能帶來價值，因為許多干擾是暫時的。一個很好的技術是在最初幾個小時使用自動DCA，並在您滿意的穩定對象出現時凍結演算法和通道計畫。

重新啟動WLC後，DCA在主動模式下運行100分鐘，以找到合適的通道計畫。在對RF設計進行重大更改（例如新增或刪除多個AP或更改通道寬度）時，最好手動重新啟動該流程。 要手動啟動此過程，請使用此命令。

ap dot11 [24ghz | 5ghz | 6ghz] rrm dca restart

附註：通道更改可能會對客戶端裝置造成中斷。

2.4 GHz

2.4GHz頻段經常受到批評。它只有三個非重疊通道，並且除Wi-Fi以外的許多技術也使用它，從而產生不需要的干擾。一些組織堅持要提供這方面的服務，那麼合理的結論是什麼？事實上，2.4GHz頻段無法為終端使用者提供令人滿意的體驗。更糟糕的是，如果嘗試以2.4GHz提供服務，則會影響其他2.4GHz技術，例如藍芽。在大型場地或活動中，許多人在撥打電話或智慧可穿戴裝置時仍期望無線耳機正常工作。如果您的高密度Wi-Fi以2.4GHz運行，您會影響到那些甚至未使用2.4GHz Wi-Fi的裝置。

有一點是肯定的，如果您確實必須提供2.4GHz Wi-Fi服務，最好在單獨的SSID上執行該操作（將其專用於IoT裝置或將其稱為「傳統」）。 這意味著雙頻段裝置不會非自願連線到2.4GHz，並且只有單頻段2.4GHz裝置連線到該裝置。

思科不建議或支援在2.4GHz中使用40MHz通道。

5 GHz

高密度無線的典型部署。儘可能使用所有可用通道。

通道數量因管制範圍而異。考慮雷達在特定位置的影響，儘可能使用DFS通道（包括TDWR通道）。

對於所有高密度部署,強烈建議使用20MHz通道寬度。

40MHz可與2.4GHz以相同的方式使用，這僅在絕對需要時（和絕對需要時）使用。

評估特定環境中40MHz通道的需求和實際優勢。40MHz通道需要更高的訊雜比(SNR)才能實現吞吐量的任何可能的改進，如果不可能有更高的SNR，則40MHz通道沒有用處。高密度網路將所有使用者的平均吞吐量優先於任何單個使用者的潛在較高吞吐量。最好在20MHz通道上放置更多AP，而不是使用40MHz作為輔助通道的AP僅用於資料幀，因此其使用效率遠遠低於使用兩個不同的無線信元，每個無線信元都以20MHz運行（就總容量而言，而不是單客戶端吞吐量）。

最關鍵的細節是在給定區域內保持相同的通道寬度。實際上，如果配置不同的通道寬度，客戶端會傾向於粘住具有最大通道寬度的AP，即使有另一個AP更接近更強的訊號強度。

6GHz

6GHz頻段尚未在所有國家提供。此外，某些裝置具有支援6GHz的Wi-Fi介面卡，但需要BIOS更新才能為特定國家/地區啟用。當前客戶端發現6GHz無線電最常用的方式是通過減少鄰居報告(RNR)通告，這將向使用其他AP無線電的客戶端通告6GHz網路的存在。這意味著6GHz不能在沒有同一AP上的另一個無線電的情況下單獨運行。

配置雙頻SSID（5GHz和6GHz）時，5GHz通告將包含6GHz SSID的RNR，使客戶端可以快速找到6GHz SSID，而無需掃描頻段。

另一種方法是在2.4GHz上配置虛假（和/或隱藏）SSID，這裡的意圖是使用2.4GHz無線電通告6GHz RNR，而不提供2.4GHz SSID。此方法適用於需要新增6GHz容量而不向環境中新增5GHz無線電的情況。

6GHz允許使用更大的通道頻寬，但這在很大程度上取決於管制域中可用的通道數量。由於歐洲有24個6GHz通道，考慮40MHz通道以提供比5GHz中可能使用的20MHz更好的最大吞吐量並非不合理。在美國，通道數量幾乎是美國的兩倍，使用40MHz是理所當然之事，甚至使用80MHz也不無道理。在高密度活動或場地中不得使用更大的頻寬。

6GHz通道寬度較大的警告是，可能無法在5GHz中使用相同的通道寬度，這將影響一些客戶端裝置的漫遊行為。最關鍵的細節是在給定區域內保持相同的通道寬度。實際上，如果配置不同的通道寬度，客戶端會傾向於粘住具有最大通道寬度的AP，即使存在另一個訊號強度更強的AP，這也適用於5GHz和6GHz頻段之間的漫遊。

資料速率

客戶端與AP協商的資料速率主要是該連線的訊雜比(SNR)的函數，相反的情況也是如此，較高的資料速率需要較高的SNR。事實上，SNR大部分決定著最大可能的鏈路速度，但在配置資料速率時，為什麼這一點如此重要呢？這是因為一些資料速率具有特殊的意義。

可以在以下三種設定之一中配置傳統OFDM(802.11a)資料速率：Disabled、Supported或Mandatory。OFDM速率是(Mbps):6、9、12、18、24、36、48、54，客戶端和AP都必須支援某個速率才能使用。

支援 — AP使用速率

強制 — AP使用速率，並使用此速率傳送管理流量

已禁用 — AP不使用速率，強制客戶端使用其他速率

附註：強制性費率也稱為基本費率

強制速率的意義在於使用此速率傳送所有管理幀以及廣播和多播幀。如果配置了多個強制速率，則管理幀使用配置的最低強制速率，而廣播和組播使用強制速率之一（這一點可在RF配置檔案中配置）。

管理幀包括客戶端必須偵聽才能與AP關聯的信標。增加強制速率也會增加該傳輸的SNR要求，回想一下，較高的資料速率需要較高的SNR，這通常意味著客戶端需要更接近AP才能解碼信標並進行關聯。因此，通過操縱強制性資料速率，我們還操縱接入點的有效關聯範圍，迫使客戶端更接近接入點，或者朝向潛在的漫遊決策。接近AP的客戶端使用較高的資料速率，而較高的資料速率使用更少的通話時間 — 預期效果是更高效的蜂窩。必須記住，增加資料速率僅影響特定幀的傳輸速率，它不影響天線的RF傳播或干擾範圍。仍需要良好的RF設計實踐來最小化同通道干擾和雜訊。 

相反，將較低速率保留為必需值通常意味著客戶端可以從更遠的距離進行關聯，這在較低的AP密度場景中很有用，但在較高密度場景中漫遊可能會造成混亂。任何試圖定位以6Mbps速度廣播的惡意AP的人都知道，您可以檢測到遠離其物理位置的AP!

在廣播和組播主題上，在某些情況下，配置第二（較高）強制速率以提高組播流量的交付速率。這很少會成功，因為在幀丟失的情況下，組播從不會得到確認並且從不重新傳輸。由於某些丟失是所有無線系統中固有的，因此無論配置的速率如何，某些組播幀都不可避免地會丟失。可靠組播傳送的更好方法是組播到單播轉換技術，它將組播作為單播流傳送，這具有更高的資料速率和可靠（確認）傳送的優點。

僅使用單個強制費率是優先選項，禁用所有低於強制費率的費率，並且保留所有高於強制費率的費率作為支援。具體使用速率取決於使用案例，如前所述，較低速率適用於較低密度和AP之間距離較大的室外場景。對於高密度和事件網路，必須禁用低速率。

如果您不確定從何處開始；低密度部署使用12Mbps的強制性速率，高密度部署使用24Mbps。事實證明，許多大型活動、體育場甚至高密度企業辦公室部署都能夠可靠地運行24Mbps的強制性速率設定。對於需要低於12Mbps或高於24Mbps速率的特定使用情形，建議進行相應的測試。

附註：最好保留所有802.11n/ac/ax/be速率啟用狀態（WLC GUI的「高吞吐量」部分中的所有速率），很少需要停用這些速率中的任何一個。

發射功率

發射功率建議因部署型別而異。在這裡，我們將使用全向天線的室內部署與使用定向天線的室內部署區分開來。這兩種型別的天線都可以在大型公共網路中存在，儘管它們通常覆蓋不同型別的區域。

對於全向部署，通常使用自動傳輸功率控制(TPC)與靜態配置的最小閾值，在某些情況下還使用靜態配置的最大閾值。

附註：TPC閾值是指無線電發射功率和排除天線增益。始終確保已正確配置使用的天線型號的天線增益，對於內建天線和自識別天線，將自動完成此操作。

範例 1

TPC最小值：5dBm，TPC最大值：最大(30dBm)

這將導致TPC演算法自動確定發射功率，但永遠不會低於配置的最小閾值5dBm。

範例 2

TPC最小值：2dBm，TPC最大值：11 dBm

這會導致TPC演算法自動確定發射功率，但始終保持在2dBm和11dBm之間。

較好的方法是建立具有不同閾值的多個RF配置檔案，例如低功率(2-5dBm)、中等功率(5-11dbM)和高功率(11-17dBM)，然後根據需要為每個RF配置檔案分配全向AP。每個RF簡檔的值都可以調整到預期的使用情形和覆蓋區域。這允許RRM演算法動態運行，同時保持在預定義邊界內。

定向天線的方法非常相似，唯一的區別是所需的精度水準。在部署前RF勘測期間，必須設計和驗證定向天線放置，而特定的無線電配置值通常是此過程的結果。  

例如，如果需要天花板安裝貼片天線覆蓋約26英尺（8米）高度的特定區域，RF勘測必須確定達到該預定覆蓋範圍所需的最小Tx功率（這確定RF剖面的最小TPC值）。 同樣，通過同一次RF調查，我們可以瞭解該天線與下一條天線之間可能需要的重疊，甚至我們希望覆蓋結束的位置 — 這將為RF配置提供最大TPC值。

定向天線的RF簡檔通常配置有相同的最小TPC值和最大TPC值，或具有窄範圍的可能值（通常<= 3dBm）。

RF配置檔案是首選，以確保配置一致性，建議不要對單個AP進行靜態配置。根據覆蓋區域、天線型別和使用案例（例如RF-Auditorium-Patch-Ceiling）命名RF配置檔案是很好的做法。

Tx功率的正確量是指所需的SNR值由預期覆蓋區域中最弱的客戶端達到時，並且不超過該值。30dBm是真實世界條件下（即在人滿為患的場所中）的一個很好的客戶端SNR目標值。

CHD

覆蓋空洞檢測(Coverage Hole Detection， CHD)是識別和修正覆蓋空洞的單獨演算法。CHD是全域性配置的，也是根據WLAN配置的。CHD可能產生的影響是增加發射功率以補償覆蓋漏洞（客戶端始終檢測到訊號較差的區域），此影響在無線電級別且影響所有WLAN，即使由為CHD配置的單個WLAN觸發也是如此。

大型公共網路通常使用RF配置檔案配置為特定功率級別，一些公共網路可能位於客戶端漫遊進出這些區域的開放區域，不需要演算法來動態調整AP Tx功率以響應這些客戶端事件。

大型公共網路必須全域性禁用CHD。

電源平衡

大多數客戶端裝置在選擇要關聯到哪個AP時，會優先使用接收訊號較高的訊號。必須避免配置AP時與其他周圍AP相比AP的發射功率明顯較高的情況。以較高的Tx功率運行的AP會吸引更多的客戶端，導致AP之間的客戶端分佈不均（例如，單個AP/無線電客戶端過載，而周圍的AP未得到充分利用）。 這種情況常見於多天線重疊覆蓋範圍大的部署，以及一個AP連線多個天線的情況。

C9104等體育場天線在選擇Tx功率時需要特別注意，因為天線波束在設計上重疊，有關詳情，請參閱相關天線部署指南。

在下圖中，中間天線配置比周圍天線更高的Tx功率。此配置可能會導致客戶端「粘滯」到中間天線。

功率高於其鄰居AP的AP會吸引周圍的所有客戶端

下圖顯示了一個更複雜的情況，並非所有天線都位於同一高度，而且並非所有天線都使用相同的傾斜/方向。實現功率平衡比簡單地配置所有無線電裝置具有相同的Tx功率更複雜。在諸如此類的場景中，可能需要部署後現場勘測，這將從客戶端裝置的角度（在地面上）提供覆蓋範圍檢視。 然後，調查資料可用於平衡配置，以實現最佳覆蓋範圍和客戶端分佈。

設計統一AP放置位置以避免類似複雜情況的發生是防止出現具有挑戰性的RF調整場景的最佳方法（儘管有時沒有其他選擇！）。

儘管Tx功率相似，但一個AP正在吸引所有客戶端，但高度和角度在其中起著作用

RxSOP

與諸如發射功率或資料速率之類的影響發射信元特性的機制不同，RxSOP（接收器開始分組檢測）旨在影響接收信元的大小。本質上，RxSOP可以視為雜訊閾值，因為它定義了接收的訊號電平，AP在該電平下不會嘗試解碼傳輸。到達訊號電平小於所配置的RxSOP閾值的任何傳輸不會由AP處理，並被有效視為雜訊。

已解釋RxSOP概念

RxSOP的意義

RxSOP具有多種用途。它可用於提高無線接入點在雜訊環境中傳輸的能力，控制客戶端在天線之間的分佈，以及最佳化弱客戶端和粘客戶端。

在有雜訊的環境中，請回想一下，在傳輸802.11幀之前，傳輸站（本例中為AP）首先需要評估介質的可用性，此過程的一部分是首先偵聽已發生的傳輸。在密集型Wi-Fi環境中，通常許多AP會在相對有限的空間內共存，通常使用相同的通道。在如此繁忙的環境中，AP可以報告來自周圍的AP的通道利用率（包括反射），並延遲其自身的傳輸。通過設定適當的RxSOP閾值，AP可以忽略那些較弱傳輸（感知通道利用率降低），從而導致更頻繁的傳輸機會並提高效能。AP報告顯著通道利用率（例如>10%）而沒有任何客戶端負載（例如，空場）的環境是RxSOP調整的良好候選者。

對於使用RxSOP的客戶端最佳化，請考慮以下圖表。

受rxsop影響的客戶端漫遊

在此範例中，有兩個存取點/天線具有明確界定的覆蓋範圍。客戶端B正在從AP1的覆蓋區域移動到AP2的覆蓋區域。存在一個交叉點，在該點上AP2比AP1更好地偵聽客戶端，但客戶端尚未漫遊到AP2。這是設定RxSOP閾值可以強制實施覆蓋區域邊界的良好示例。確保客戶端始終連線到最近的AP，通過消除以較低資料速率服務的遠端和/或弱客戶端連線來提高效能。通過這種方式配置RxSOP閾值需要透徹瞭解每個AP的預期覆蓋區域開始和結束的位置。

RxSOP的危險。

設定RxSOP閾值過於激進會導致覆蓋空洞，因為AP無法解碼來自有效客戶端裝置的有效傳輸。這會對客戶端產生不利影響，因為AP沒有響應；畢竟，如果沒有聽到客戶端傳輸，就沒有理由做出響應。必須謹慎調整RxSOP閾值，始終確保配置的值不會排除覆蓋區域內的有效客戶端。請注意，某些客戶端可能在此方式下被忽略後反應不佳，過於激進的RxSOP設定不能讓客戶端有機會自然漫遊，從而有效地迫使客戶端查詢另一個AP。能夠解碼來自AP的信標的客戶端假定它能夠傳輸給該AP，因此，RxSOP調優的意圖是將接收信元的大小與AP的信標範圍相匹配。請記住，（有效的）客戶端裝置並不總是能夠直接到達AP，訊號通常因使用者背離天線或將其裝置放在袋子或口袋中而衰減。

配置RxSOP

RxSOP是按射頻配置檔案配置的。

每個頻段都有預置的閾值（低/中/高），該值為預定義的dBm值。每個頻段的這些預設值不同（例如，「低」在2.4GHz和5GHz之間的dBm中有不同的值）這裡的建議是始終使用自定義值，即使預期值是可用的預設值之一，這樣會使配置更易讀。「自動」設定會有效禁用RxSOP，即AP會嘗試像往常一樣解碼任何資料包。

RxSop設定表

附註：RxSOP更改不需要無線電重置，可以即時完成。

擴展網路

一般而言，將裝置發揮到其已記錄功能的最大程度是一個不好的主意。資料表報告了真實情況，但所提及的數字可能處於特定的活動狀態。無線控制器經過測試和認證，可支援特定數量的客戶端和AP以及特定吞吐量，但這並不假設客戶端每秒漫遊一次，或者您可以為每個客戶端配置超長的唯一ACL，或者啟用所有可用的監聽功能。因此，必須認真考慮所有方面，以確保網路在高峰時段能夠擴展，並為將來增長保持安全邊際。

AP數量

部署任何網路的首要任務之一是編制預算並訂購正確的裝置數量，而最大的可變因素則是接入點和天線的數量和型別。無線解決方案必須始終以射頻設計為基礎，但是（很不幸地），這經常是專案生命週期中的第二步。在簡單的室內企業部署中，有許多估計技術可以在無線架構師檢視樓層規劃之前，以合理的確定性水準預測可能需要多少個AP。預測模型在這種情況下也非常有用。

對於更具挑戰性的安裝（例如工業、戶外、大型公共網路或需要外部天線的任何地方），簡單的估算技術通常是不夠的。對以前的類似安裝需要一定程度的經驗，才能充分估計所需裝置的型別和數量。無線架構師進行現場探訪是瞭解複雜場地或設施佈局的最低要求。

本部分提供了有關如何確定給定部署的AP和天線的最小數量的准則。最終數量和特定安裝位置將始終通過需求分析和無線電設計流程來確定。

初始物料清單必須基於兩個因素：天線型別和天線數量。

天線型別

這裡沒有捷徑。天線型別由需要覆蓋的區域以及該區域中的可用安裝選項確定。如果不瞭解物理空間，則不可能確定這一點，這意味著瞭解天線及其覆蓋模式的人需要進行站點訪問。

天線數量

所需裝置的數量可以通過瞭解預期客戶端連線的數量得出。

每個人的裝置

使用者數量可以通過場所的座位容量、售票數量或基於歷史統計的預期遊客數量來確定。每個人類使用者可攜帶多個裝置，通常假設每個使用者擁有多個裝置，但人類使用者同時主動使用多個裝置的能力值得懷疑。主動連線到網路的訪問者數量也取決於事件和/或部署的型別。

範例 1：一個80,000個座位的體育場通常沒有80,000個連線的裝置，這一比例通常要低得多。在體育賽事中，20%的連線使用者比例並不罕見，這意味著，對於80,000個席位的體育場示例，預期連線裝置數量可以為16,000(80,000 x 20% = 16,000)。 此數字還取決於使用的自註冊機制，如果使用者需要執行某些操作（例如按一下Web門戶），則數字低於裝置自動自註冊時的數字。自動登入可以簡單到從以前的事件中記住的PSK，也可以更加高級的操作，如使用OpenRoaming登入裝置而不進行使用者互動。OpenRoaming網路可以將使用者連線率大大推高到50%以上，這對容量規劃有重大影響。

範例 2：期望技術會議具有高使用者連線率是合理的。會議參與者花費更長的時間連線到網路，並希望能夠訪問其電子郵件並在全天執行日常任務。此外，這種型別的使用者也可能將多個裝置連線到網路 — 儘管他們一次可能仍只使用一台裝置。對於技術會議，假設所有訪客都連線到網路，此數字可能較低，具體取決於會議型別。

在這兩個示例中，關鍵是要瞭解預期連線的裝置數量，並且沒有針對每個大型公共網路的單一解決方案。無論哪種情況，天線都會連線到無線電，並且連線到該無線電的是客戶端裝置（而不是使用者裝置）。因此，每個無線電的客戶端裝置是一個可用指標。

每無線電裝置

對於Wi-Fi 6個AP，思科AP的最大客戶端計數為每無線電台200個連線的裝置；對於Wi-Fi 6E AP，每無線電台400個裝置。但是，不建議為最大客戶端計數進行設計。出於規劃目的，建議將每個無線電的客戶端計數保持在遠遠低於最大AP容量的50%。此外，無線電數量取決於使用的無線接入點和天線的型別，關於單頻和雙5GHz的部分對此做了更詳細的探討。

在這個階段，最好將網路劃分為不同的區域，每個區域都有預期的裝置數量。回想一下，本節旨在估計最小AP和天線數量。

以三個不同覆蓋區域的示例為例，會為每個區域提供預期客戶端數量，並使用每個無線電75個客戶端的（正常）值來估計所需的無線電數量。

每個區域的預期無線電/客戶端數量

現在，這些初始數字需要與瞭解每個區域中部署的AP和天線型別以及是否使用單或雙5GHz結合使用。6GHz的計算遵循與5GHz相同的邏輯。本示例中未考慮2.4GHz。

假設三個區域都使用2566P貼片天線和9104體育場天線的組合，以及單頻和雙5GHz的組合 — 此場景用於說明目的。

每個區域的天線

每個區域都列出了所需的天線和AP的型別。請注意，在雙5GHz的情況下，比值為兩個天線與一個AP。

本節演示了估計部署所需的初始天線和AP數量的方法。此估算需要瞭解物理區域、每個區域中可能的安裝選項、每個區域中要使用的天線型別以及預期客戶端裝置的數量。

每次部署都不同，通常需要增加裝置來覆蓋具體或具有挑戰性的領域，這種估算只考慮客戶的能力（而非覆蓋範圍），並用於概述所需投資的規模。最終AP/天線放置位置和裝置總數始終取決於經驗豐富的無線專業人員對使用案例和現場驗證的透徹瞭解。

預期吞吐量

每個無線通道都可以提供一定量的可用容量，通常轉換為吞吐量。此容量在連線到無線電的所有裝置之間共用，這意味著當無線電中新增更多使用者連線時，每個使用者的效能都會下降。這種效能下降並非線性，而且還取決於所連線的客戶端的確切組合。

客戶端功能因客戶端晶片集和客戶端支援的空間流數量不同而不同。下表中列出了每個受支援空間流數的最大客戶端資料速率。請注意，大多數客戶端裝置最多支援2個空間流。

每種客戶端型別的預期最大實際吞吐量

列出的速率是理論上的最大MCS（調制和編碼方案）速率（從802.11標準匯出），並假設訊雜比(SNR)>30dBm。效能良好的無線網路的主要設計目標是使所有位置的所有客戶端達到這一級別的SNR，但很少有這種情況。無線網路本質上是動態的，並且使用未經許可的頻率，除了客戶端功能外，各種不受控制的干擾也會影響客戶端SNR。

即使在達到所需的SNR級別的情況下，先前列出的速率也不考慮協定開銷，因此，不會直接對映到實際吞吐量（由各種速度測試工具測量）。 真實世界中始終低於MCS速率。

對於所有無線網路（包括大型公共網路），客戶端吞吐量始終取決於：

• 客戶端的功能。
• 客戶端在該特定時間點的訊雜比。
• 在該特定時間點連線的其他客戶端的數量。
• 其他客戶端在該特定時間點的功能。
• 其他客戶端在該特定時間點的活動。
• 特定時間點的干擾。

根據這些因素的不同，無論裝置供應商是誰，都不能保證無線網路的每客戶端最低配置。

有關詳細資訊，請參閱驗證Wi-Fi吞吐量：測試和監控指南。

WLC平台

選擇您的WLC平台看起來很簡單。您首先要考慮的是，檢視要管理的估計的AP數量和客戶端數量。每個WLC平台的資料表包含平台上支援的所有最大對象：ACL、客戶端計數、站點標籤等。這些只是字面上的最大數字，而且往往需要嚴格執行。例如，不能將6001 AP加入僅支援6000 AP的9800-80。但在任何地方都追求最大目標是明智的嗎？

思科無線控制器經過測試可以達到這些最大值，但是它們不一定能同時達到所有條件中記錄的所有最大值。讓我們以吞吐量為例，9800-80可以達到高達80 Gbps的客戶端資料轉發，但是在這種情況下，每個客戶端資料包的最大、最佳大小為1500位元組。混合資料包大小後，有效最大吞吐量會降低。如果啟用DTLS加密，吞吐量會進一步降低，而應用可視性也是如此。在啟用了許多功能的大型網路中，期望在9800-80實際條件下能實現40Gbps以上的頻寬。由於這取決於使用的功能和網路活動的型別，因此要瞭解實際容量，唯一的方法是使用這個命令測量資料路徑利用率。請關注load指標，該指標是控制器可以轉發的最大吞吐量的百分比。

WLC#show platform hardware chassis active qfp datapath utilization summary

  CPP 0:                     5 secs        1 min        5 min       60 min

Input:     Total (pps)            9            5            5            8

                 (bps)        17776         7632         9024        10568

Output:    Total (pps)            5            3            3            6

                 (bps)        11136        11640        11440        41448

Processing: Load (pct)            0            0            0            0

 

WLC#

同樣地，9800-80也能通過正常活動完美地處理6000個AP。但是，體育場或機場等公共場所的6000個AP不算常規活動。考慮到客戶端漫遊數量和環境探測數量，最大規模的大型公共網路可能會增加單個WLC上的CPU利用率。如果新增監控和SNMP陷阱，以便每次客戶端移動時傳送，負載可能會很快變得過大。大型公共場所或大型活動的一個關鍵具體特點是，隨著人們四處活動並不斷關聯/取消關聯，客戶入職活動顯著增加，因此這會對CPU和控制平面造成額外壓力。

眾多部署表明，一對9800-80無線控制器可以處理超過1000個AP的大型體育場部署。對於正常運行時間和可用性成為主要關注點的關鍵事件，通常還會通過兩個或更多控制器對分發AP。當大型網路分佈在多個WLC上時，控制器間漫遊會更加複雜，因此必須在體育場碗等封閉空間仔細考慮客戶端漫遊。

另請參閱本文檔中的站點標籤部分。

WLC高可用性

建議使用高可用性狀態切換(HA SSO)配對，這樣既可提供硬體冗餘，又可防止軟體故障。使用HA SSO，當輔助WLC無縫接管時，一台裝置上的軟體崩潰對於終端使用者是透明的。HA SSO配對的另一個優勢是服務中軟體升級(ISSU)功能提供的無中斷升級。

如果網路足夠大，也建議使用額外的控制器(N+1)。 它可以滿足HA SSO無法實現的多個目的。升級生產對之前，您可以在此WLC上測試新軟體版本（並僅將幾個測試AP移到該版本以測試網路的特定部分）。 某些罕見情況可能會影響HA對中的兩個WLC（當問題複製到備用時），這裡N+1允許在主動 — 主動情況下提供安全的WLC，您可以在此情況下逐步將存取點移入和移出。它還可以用作配置新AP的調配控制器。

9800-CL具有很強的擴展性和強大功能。需要注意的是，它們的資料轉發容量要小得多（對於SR-IOV映像，從2 Gbps到4 Gbps），這往往會限制它們使用FlexConnect本地交換方案（在中心交換中可能還包括少量AP）。 但是，在維護時段或排除故障時，當您需要額外的控制器時，它們可以作為N+1裝置提供幫助。

外部系統

儘管本文檔主要介紹大型事件網路的無線元件，但在擴展和設計階段，還有許多需要考慮的支援系統，其中一些將在本文中討論。

核心網路

大型無線網路通常以集中交換模式部署，而且子網規模較大。這意味著大量客戶端MAC地址和ARP條目被推送到相鄰的有線基礎架構。專用於各種L2和L3功能的相鄰系統必須擁有足夠的資源來處理此負載。對於L2交換機，常見的配置是調整Switch Device Manager(SDM)模板，該模板負責分配系統資源，並根據網路中裝置的功能在L2和L3功能之間實現平衡。確保核心L2裝置能夠支援預期的MAC地址條目數，這一點非常重要。

網關NAT

公共網路的最常見用例是為訪客提供Internet訪問。資料路徑上的某個位置必須有一個裝置負責NAT/PAT轉換。Internet網關必須擁有所需的硬體資源和IP池配置才能處理負載。請記住，單個無線客戶端裝置可以負責多種NAT/PAT轉換。

DNS/DHCP

這兩個系統是確保良好客戶端體驗的關鍵。DNS和DHCP服務不僅需要適當的擴展來處理負載，還需要考慮在網路中的位置。與WLC位於同一位置的快速響應系統可確保最佳體驗並避免客戶端登入時間過長。

AAA/Web門戶

沒有人喜歡速度慢的網頁，因此選擇合適且擴展良好的外部Web驗證系統對於良好的客戶端登入體驗非常重要。類似地，對於AAA，RADIUS身份驗證伺服器必須能夠應對無線系統的需求。請記住，在某些情況下，負載會在關鍵時刻突然增加，例如在足球比賽期間的半小時內，這會在很短的時間內生成較高的身份驗證負載。擴展系統以獲得足夠的併發負載是關鍵。使用AAA記賬等功能時必須特別小心。不惜一切代價避免基於時間的記帳，如果您使用記帳，請嘗試禁用臨時記帳。要考慮的另一個重要事項是使用負載均衡器，這裡必須使用會話觸發機制來確保完整的身份驗證流程。確保將RADIUS超時保持在5秒或以上。

如果使用具有較大客戶端數量的802.1X SSID（例如使用OpenRoaming），請確保啟用802.11r快速轉換(FT)，否則客戶端每次漫遊時都會引發身份驗證風暴。

DNS/DHCP

DHCP的一些建議：

• 確保DHCP地址池至少是預期客戶端數量的三倍。即使在客戶端斷開連線後，IP也會保持分配一段時間，因此，根據訪客的駐留時間，這可能會佔用更多的IP地址。嘗試將租用時間與使用者訪問場所的預期持續時間相匹配，如果典型訪問持續時間為兩小時，則無需分配一週的IP地址，這有助於淘汰陳舊租約。
• 建議為使用者端使用單一大型子網路，WLC具有代理ARP功能，且預設不會轉送廣播（DHCP除外）。 為客戶端使用大型（例如/16）客戶端子網不會帶來問題。與具有多個VLAN的VLAN組相比，單個大型VLAN更簡單。配置許多較小的子網（例如/24）和VLAN組不會影響廣播域，只會導致配置更加複雜，從而導致VLAN髒亂以及必須跟蹤無法平均使用的各種DHCP池等問題。此建議適用於本地模式AP和集中交換流量。在使用本地交換的FlexConnect的情況下，不支援將100個以上（或17.9之後的300個）AP置於同一個子網中，因為它們會遭受大量廣播傳輸。Flexconnect要求AP為同一個VLAN提供服務，以便支援無縫漫遊，因此在此情況下不建議支援大型子網。
  
• 使用子網的第3層網關處理的DHCP中繼功能，在無線控制器上保持DHCP處於橋接模式。這樣可實現最高效率和簡便性。其理念是根本不需要將無線控制器參與DHCP過程。
• 在任何公共WLAN上使用DHCP Required，無論身份驗證方法如何。雖然這可以觸發一小部分的失敗客戶端關聯，但是它可以防止出現嚴重的安全問題，原因可能是客戶端嘗試為自己分配靜態IP地址，或者客戶端行為不當，並在未經允許的情況下嘗試重複使用以前的IP地址。

運行網路

正確的配置

讓許多選項從現代Wi-Fi的所有最新功能中受益很有誘惑力。但是，某些功能在小型環境中效果很好，但在大型和密集環境中影響很大。同樣，某些功能也會造成相容性問題。儘管思科裝置遵守所有標準並提供與各種經過測試的客戶端的相容性，但世界上仍有許多獨特的客戶端裝置，這些客戶端裝置的驅動程式軟體版本有時會出錯，或與某些功能不相容。

根據您對客戶端的控制級別，您必須保守一些。例如，如果您為貴公司的大型年度聚會部署Wi-Fi，您知道大多數客戶端都是公司裝置，您可以相應地規劃啟用功能集。另一方面，如果您運營的是機場Wi-Fi，您的訪客滿意度直接與其連線到您網路的能力相關，而您對使用者可使用的客戶端裝置沒有任何控制權。

SSID

多少個SSID?

建議始終使用儘可能少的SSID。在高密度網路中，這種情況會更加嚴重，因為幾乎可以保證在同一個通道上有多個AP。通常，許多部署使用過多的SSID，承認它們擁有過多的SSID，但宣告它們不能使用更少的SSID。您必須對每個SSID執行業務和技術研究，以瞭解SSID與將多個SSID合併為一個SSID的選項之間的相似之處。

讓我們來瞭解一下幾個安全/SSID型別及其用途。

WPA2/3個人

預共用金鑰SSID由於其簡單性而非常流行。你可以把鑰匙印在徽章上的某個地方，或者印在紙上，或者標語上，或者用某種方式把它傳達給參觀者。有時候，即使訪客SSID也首選預共用金鑰SSID（前提是所有參與者都知道該金鑰）。 它有助於防止DHCP池因連線的故意性而耗盡。經過的裝置不會自動連線到網路，因此無法使用DHCP池中的IP地址。

WPA2 PSK不提供隱私保護，因為流量很容易解密，因為每個人都使用相同的金鑰。相反，WPA3 SAE提供私密性，即使每個人都擁有主金鑰，也無法派生其他客戶端使用的加密金鑰。

WPA3 SAE是更好的安全選擇，許多智慧手機、筆記型電腦和作業系統都支援它。某些IoT裝置或智慧可穿戴式裝置仍可能具有有限的支援，如果較舊的客戶端未收到最新的驅動程式或韌體更新，則通常很容易出現問題。

考慮過渡模式WPA2 PSK-WPA3 SAE SSID來簡化操作可能很誘人，但是該欄位顯示會導致一些相容性問題。程式設計不當的客戶端不需要在同一個SSID上使用兩種型別的共用金鑰方法。如果要同時提供WPA2和WPA3選項，建議配置單獨的SSID。

Wi-Fi 7要求在WPA3 SSID上配置兩個新的AKM（SAE-EXT和SAE-EXT-FT），並使用GCMP256加密，這增強了選擇的必要性（如果您要保持WPA2相容性，最好忘記Wi-Fi 7功能）。 目前並非所有AP型號或客戶端都支援GCMP256。

WPA2/3企業版

WPA3 Enterprise（使用AES 128位加密）在技術上與WPA2 Enterprise採用相同的安全方法（至少如SSID信標中通告的），可提供最大的相容性。

對於802.1X，建議使用轉換模式SSID，因為最近裝置沒有出現相容性問題（Android 8或舊Apple IOS版本報告了問題）。IOS XE 17.12及更高版本允許具有單個過渡企業SSID，其中在6GHz上僅使用WPA3並通告，而在5GHz頻段上提供WPA2作為選項。建議儘快在企業SSID上啟用WPA3。

WPA企業SSID可用於具有身份提供者資料庫的金鑰使用者，該身份提供者資料庫允許根據使用者身份返回AAA引數（如VLAN或ACL）。此類型別的SSID可以包括eduroam或OpenRoaming，它們結合了訪客SSID的優點（通過允許訪客輕鬆連線而無需輸入任何憑證）與公司SSID的安全性。它們大大降低了通常與802.1X相關的登入的複雜性，因為如果客戶端在電話上有一個配置檔案（可通過事件應用輕鬆提供），則客戶端無需執行任何操作即可加入教育或OpenRoaming SSID

Wi-Fi 7支援可能要求（使用最嚴格的客戶端）AP也提供GCMP256加密，這需要IOS-XE 17.18.3及更高版本的軟體。

訪客SSID

訪客SSID通常與開放式身份驗證同義。您可以在其後新增Web門戶（或不新增）（取決於所需的友好性或本地要求），其形式多種多樣：外部、本地或中央web驗證，但概念保持不變。使用訪客門戶時，可擴充性很快會成為大型環境中的問題。有關此項的詳細資訊，請檢視配置可伸縮性部分。

6GHz操作要求您的訪客SSID使用增強型Open，而不是僅使用Open。這仍允許任何人進行連線，但提供了隱私（甚至比WPA2-PSK更好的隱私！）和加密，在連線SSID時都不提供任何金鑰或憑證。主要智慧手機供應商和作業系統現在支援Enhanced Open，但是在無線客戶端中這種支援還不是很普遍。Wi-Fi 7和6GHz操作禁止增強型開放式過渡模式。因此，正確的方法可能是僅在6GHz頻段上運行增強型開放式SSID，並在5GHz頻段上保持完全開放式SSID以確保相容性。您需要為SSID指定不同的名稱，因為它們具有不同的安全方法。這會將SSID新增到客戶端掃描清單中，但不會在空中新增額外的SSID，因為它們存在於不同的頻段。

在大型事件和場合，通常建議在訪客SSID上配置PSK，而不是完全保持其開放狀態（增強開放過渡模式會更好，但這樣會建立兩個SSID，並且還必須經過廣泛的客戶端相容性驗證）。 雖然這會使自註冊變得更為複雜（您必須將PSK列印在人的徽章或門票上，或者以某種方式將其通告），但這樣可以避免臨時客戶端自動連線到網路，而終端使用者沒有任何使用網路的意圖。越來越多的移動作業系統供應商也降低了開放網路的優先順序並顯示安全警告。在其他情況下，您可能希望連線最大數量的路人，因此最好選擇開啟。

關於SSID數量的結論

對於必須保留多少個SSID的問題，沒有令人滿意的答案。其效果取決於最小配置的資料速率、SSID數以及在同一通道上廣播的AP數。在思科的一次大型活動中，無線基礎設施使用了5個SSID:主WPA2 PSK、用於安全和6GHz覆蓋的WPA 3 SAE SSID、用於教育參與者輕鬆訪問的企業教育SSID、用於安全歡迎任何在事件應用中配置Wi-Fi的OpenRoaming SSID，以及用於員工和管理網路訪問的獨立802.1X SSID。 這幾乎已經太多了，但是由於大量的可用通道，並且使用定向天線來儘可能減少通道重疊，因此效果仍然合理。

傳統SSID與主SSID概念

建議將2.4GHz服務限製為僅在2.4GHz中通告的「傳統」獨立SSID。隨著人們完全停止提供2.4GHz服務，這種情況越來越少了。然而，這個想法可以而且必須堅持下去，但會與其他概念結合使用。您想推廣WPA3 SAE，但是過渡模式是否給您帶來了與客戶端的相容性問題？具有WPA2「傳統」SSID和主WPA3 SAE SSID。通過將效能最低的SSID命名為「legacy」，它不會吸引客戶端，您可以輕鬆檢視有多少客戶端仍然面臨與您的主SSID的相容問題，並且需要此舊的SSID。

但為何止步於此？您聽到傳言說802.11v導致一些較舊客戶端出現問題，或者某些客戶端驅動程式不希望看到SSID上啟用了「Device Analytics」？在高級主SSID上啟用所有這些方便的功能，並在舊版/相容SSID上禁用這些功能。這允許您測試主SSID上新功能的推出，同時仍然為客戶端提供最大相容性SSID以回退到。這個系統只能這樣運作。如果您將您的相容性驅動型SSID作為您的主要名稱，並將您的高級SSID命名為「<name>-WPA3」，則您會發現人們粘在他們以前使用的SSID上，並且在您的「新」SSID上採用小數年。由於連線到新設定或功能的客戶端數量較少，因此滾動新設定或功能會產生不確定的結果。

SSID功能

• 最好禁用Aironet擴展。這些對於站點調查和WGB操作特別有用，但有時會導致一些傳統客戶端出現問題。Aironet IE還會通告AP主機名，這在需要安全保護的部署中是不必要的。
• CCKM是已棄用的協定（支援FT），必須禁用。
• 目前，最好使用AES-128加密，即使在WPA3中也是如此，因為客戶端對更高加密的支援較低（除非您能提供特定的更安全且更嚴格的SSID）
• 最好禁用覆蓋盲區檢測（對於所有SSID）。 大型部署通常使用定向天線，需要進行全面的現場勘測。每個天線的功率電平是RF設計流程的結果，通常配置為特定電平。
• 必須禁用自適應FT，因為當FT未完全通告但存在於某些屬性中時，某些客戶端可能會出現問題。完全禁用FT（以獲得最大相容性）或使用FT+802.1X(大多數客戶端（除非它們更舊或更面向IoT）)支援FT+802.1X。配置FT+802.1X時，甚至允許非FT客戶端加入SSID。唯一可能的問題是某些客戶端無法容忍在同一個SSID上看到兩個安全選項。
• 禁用802.11ac MU-MIMO。它增加了複雜性，在802.11ac中的優勢非常低。
• 禁用BSS目標喚醒時間。目前客戶端對它的採用率很低。
• 禁用主動負載均衡和頻段選擇。如果您沒有在2.4GHz中通告SSID（或者它位於專用SSID上），則無需頻段選擇，並且如果客戶端堅持連線到已載入的AP，主動負載平衡會在最終接受之前拒絕客戶端幾次，從而延遲客戶端關聯。您仍然是在繁忙環境中載入AP，這對於客戶端體驗來說是不利的。
• 禁用Fastlane+。
• 禁用通用管理，此功能用於3700 AP，並且僅用於 — UX域。如果保留它，就會開啟不必要的攻擊媒介。
• 保持啟用機會金鑰快取(OKC)。對於不支援FT的客戶端，它充當快速漫遊機制。
• 保持WMM允許。禁用它會將您的網路帶回802.11g時代，並且要求它不會在9800平台上帶來任何優勢。
• 啟用IP源防護。
• 禁用RADIUS分析。在非常繁忙的環境中，這可能會傳送過多的RADIUS記帳訊息（每當使用者端執行DHCP或傳送HTTP封包時），而且很有可能會使您的RADIUS伺服器超載。
• 避免使用隱藏的SSID。這不能用於任何安全目的，但通過簡單的應用程式或通過捕獲監聽器仍可以輕鬆發現SSID名稱。隱藏SSID會減慢所有客戶端漫遊的速度，因為他們不再受益於被動信標掃描，必須依靠主動掃描來獲取相鄰的AP資訊。
• 嘗試每個無線電使用不超過4個WLAN，因為這會對射頻利用率產生重大影響。使用五個WLAN並不是一個硬性限制，但使用越來越多的WLAN會非常清楚浪費通話時間。
• 802.11v和802.11k是流行客戶端型別越來越支援的標準。它們通常不會造成客戶端連線問題。這些協定帶來的好處在很大程度上取決於客戶端如何使用這些協定，並且有時（對於802.11k），會導致CPU使用率略高。您可以將其置於IoT或傳統SSID之外，但必須在您的生產SSID上啟用它們（如果可能）。

站點標籤

站點標籤是一個配置專案，允許對共用相同FlexConnect設定以及AP加入配置檔案設定（如憑據、SSH詳細資訊和國家/地區代碼）的接入點進行分組。 為什麼站點標籤很重要？站點標籤還定義Catalyst 9800中WNCD進程處理AP的方式。讓我們舉幾個例子來說明：

• 如果在具有八個WNCD進程的9800-80上配置四個站點標籤，則每個站點標籤將被分配到不同的WNCD進程（在單獨的CPU核心上運行每個），而四個WNCD進程則不執行任何操作。這表示您沒有使用9800-80的所有CPU，建議不要使用最多支援6000個AP來載入。

站點標籤平衡的第一個示例

• 如果您在具有8個WNCD進程的9800-80上配置10個站點標籤，則兩個WNCD進程分別處理兩個站點標籤，而其餘6個進程分別處理一個站點標籤。

站點標籤平衡的第二個示例

對於具有多個站點和多個站點標籤的地理上大型部署，站點標籤的數量建議是所使用平台上WNCD進程數量的倍數。

但是，對於通常位於同一屋頂下或同一地點有多個建築的活動網路，建議將地點標籤數量與給定平台上的實際WNCD數量相匹配。最終目標是每個WNCD進程（因此分配給無線任務的每個CPU核心）處理數量大致相近的客戶端漫遊事件，以便所有CPU核心之間的負載均衡。

每種平台型別的WNCD進程數

在核心層，真正重要的是將位於同一物理鄰居的AP分組到同一站點標籤中，以便這些AP之間的頻繁客戶端漫遊事件保持在同一個CPU進程中。這意味著，即使您有一個大型場所，仍建議將該場所分成多個站點標籤（與處理場所的WNCD流程相同），並將儘可能邏輯上分組的AP以組成邏輯上的RF鄰居組，這些組也均勻分佈在站點標籤之間。

從IOS XE 17.12開始，可以啟用負載均衡演算法，以便WLC根據RF接近程度對AP分組。這樣可以減輕您的負擔，並使AP在WNCD流程中均衡分佈。如果您無法輕鬆地繪製鄰居接入點組，以放置到正確的站點標籤數量中，這將很有幫助。該演算法的一個特點是，它將AP分配給WNCD進程，而不考慮其站點標籤分配，這意味著它不會更改AP的站點標籤分配。然後，您可以完全根據配置邏輯分配站點標籤，並讓演算法以最佳方式在CPU之間平衡AP。

Cisco Catalyst 9800系列無線控制器軟體配置指南(Cisco IOS XE Dublin 17.12.x)中記錄了基於RF的自動AP負載平衡功能。

在大事件期間，必須監控WNCD進程的CPU使用情況。如果有一個或多個WNCD進程顯示高利用率，則可能是WNCD正在處理過多的AP或客戶端，或者它處理的AP或客戶端比平均值更繁忙（如果所有進程都持續漫遊，例如在機場）。

策略配置檔案

• 啟用ARP和重複位址偵測(DAD)代理，這允許WLC在裝置嘗試得知無線裝置的MAC位址時，代表無線使用者端回覆。這還可以節省無線客戶端電池。
• 除非需要，否則請勿啟用WGB功能。
• 啟用DHCP以避免客戶端使用靜態IP地址。
• 保持空閒超時較短（300秒）。 有些管理員會花很長時間來避免客戶端必須重新進行身份驗證，但是由於客戶端計數從即時開始延遲，過長的空閒超時會產生虛影客戶端條目（影響報告）。最好將idle -timeout保持在低於組金鑰輪替計時器的水準，以避免刪除客戶端時發生的記帳泛洪。在Web UI中的Configuration > Security > Advanced EAP下，可將組金鑰輪替間隔配置為「EAP-Broadcast Key Interval」
• 使會話超時為86400秒，以避免不必要的斷開和重新身份驗證。

AP加入配置檔案

• 確保已啟用TCP adjust MSS。
• 啟用信任DSCP上游。很遺憾，許多無線客戶端不執行802.11e WMM UP標籤，信任DSCP欄位是為語音應用提供正確優先順序的可靠方法。
• 為您的接入點啟用Syslog。配置Syslog伺服器IP會使AP向其單播其控制檯日誌。這不僅對AP進行故障排除很有用，而且它比預設設定（使AP在本地VLAN中廣播其Syslog）更適合於網路。AP日誌記錄可以生成大量消息負載，即使在AP系統日誌未受監控的情況下，通過設定適當的消息嚴重性和/或配置虛設系統日誌IP地址(例如0.0.0.0)來防止廣播消息來限制事件數量仍是一個好主意。
• 最大化CAPWAP重試次數和超時。問題檢測速度較慢，但網路更能夠抵抗輕微的暫時性資料包丟棄。
• 啟用SSH並配置憑證。禁用AP控制檯
• 根據需要啟用AP監視器，但不啟用無線電監視器。
• 啟用欺詐檢測並將RSSI閾值配置為–70 dBm。

監控網路

網路啟動並運行後，您必須密切監控網路是否有問題。在標準辦公環境中，使用者瞭解網路，在發生問題時可以互相幫助，也可以開啟內部幫助台票證。在一個有更多訪客訪問的大型場地中，您希望將注意力集中在最大的問題上，而不是那些可能僅僅配置錯誤的特定個體，因此，您需要制定正確的監控策略。

通過Catalyst 9800 CLI或GUI監控網路是可能的，但它不是日常監控的最佳工具。如果您已經對問題產生懷疑和/或資料，並且希望即時運行特定命令，則此命令是最直接的。主要監控選項為Cisco Catalyst Center或可能的自定義遙測控制面板。使用第三方監控工具是可^能的，但是當這些工具使用SNMP作為協定時，資料距離即時性很遠，並且通常的第三方監控工具對於所有無線供應商的特定要求不夠精^細。如果選擇SNMP協定，請確保使用SNMPv3，因為SNMPv2的安全性已過時。

Cisco Catalyst Center是最佳選擇，因為它允許您在監控網路的基礎上管理網路。除了監控之外，它還允許即時故障排除和修復許多情況。

如果您希望以永遠線上的方式在螢幕上顯示NOC或SOC的非常特定的度量和小部件，自定義遙測控制面板會非常有用。如果您需要關注網路的特定區域，您可以構建專用小部件，以您選擇的方式顯示這些區域的網路指標。

對於事件網路，最好監控系統範圍的RF統計資訊，尤其是每個AP的通道利用率和客戶端數量。這可以通過CLI完成，但只提供特定時間點的快照，通道利用率往往是動態的，更適合於隨時間推移進行監控。對於這種型別的監控，自定義控制面板通常是一種很好的方法。隨時間推移進行監控時更有價值的其他指標包括WNCD利用率、客戶端數量及其狀態，以及場所特定指標。例如，會場特定指標是監控特定區域或位置的使用和/或負載，例如，會議中心的會場X廳，或活動會場的會場Y。

對於自定義監控，NETCONF RPC(pull)和NETCONF流遙測(push)都是有效的方法，儘管將自定義流遙測與Catalyst Center結合使用需要一些注意，因為WLC上可配置的遙測訂閱數量有限，並且Catalyst Center預填充（和利用）其中許多遙測訂閱。

使用NETCONF RPC時，需要執行一些測試以確保WLC不因NETCONF請求而超載，尤其重要的是要記住某些資料點的刷新率以及要返回的資料所花費的時間。例如，AP通道利用率每60秒刷新一次（從AP刷新到WLC），1000個AP的RF指標的收集可能需要幾秒鐘，在本示例中，每5秒輪詢一次WLC將沒有用處，更好的方法是每3分鐘收集系統範圍的RF指標。

NETCONF總是比SNMP優先使用。

不能忽視對核心網路元件的持續監控，包括DHCP池利用率、核心路由器上的NAT條目數量等。因為其中任何一項的故障都很容易導致無線中斷。

你監視得越嚴你越能造成你自己的問題

過多的監控會造成一些問題的典型場景：

• 充當客戶端的無線感測器網路可以很好的測量網路中特定位置的吞吐量和連通性，但請記住，設定高測試頻率意味著感測器將花費大量時間進行大型資料傳輸，因此即使沒有其他方式，通道和網路實際上也很繁忙。這是「你監控的越嚴厲，你的指標看上去越糟糕」的典型例子。
• 如前所述，SNMP是一種對CPU影響較大的傳統協定。一旦您經常監控所有無線客戶端或AP（當您擁有大量無線客戶端或AP時），執行大量SNMP輪詢會很容易使您的無線網路CPU充滿請求。在設定主動輪詢間隔之前，請始終考慮正在輪詢的對象數量。SNMP守護程式位於IOS-XE中的IOSd進程內，因此當它位於高CPU時，可能會影響其餘的IOS功能。
• 即使遙測比SNMP更有效，大型無線網路也會有大量的客戶端、AP，但也會有干擾和欺詐裝置。如果您的遙測配置設定過於集中，並且WLC必須不斷報告任何欺詐裝置的訊號變化，則這也很容易導致任何控制器裝置飽和。請務必留意您負責遙測的「public」進程，並確保該進程的CPU使用率不高。如果是這樣，請重新考慮閾值並確保遵循9800最佳實踐。

大型網路特有的問題

如果您使用的是Web驗證的SSID，一個問題可能是連線到該SSID並獲得IP地址的客戶端，但由於終端使用者沒有主動嘗試連線（裝置自動連線），因此從不進行驗證。 控制器必須攔截那些處於稱為Web驗證掛起狀態且使用WLC資源的客戶端傳送的每個HTTP資料包。網路運行後，請定期監視在給定時間處於Web身份驗證掛起狀態的客戶端數量，以檢視其與基線數量的比較。處於IP Learn（IP學習）狀態的客戶端也一樣。客戶端執行DHCP過程時，您總是處於該狀態，但瞭解適合您的網路的工作編號有助於設定基線並確定該編號可能過高的時刻以及指示更大的問題。

對於大型場所，經常會看到~10%的客戶端處於Web Auth Pending狀態。

第2天監控：關注使用者滿意度

網路啟動並運行後，有兩種典型的終端使用者投訴：它們無法連線或難以連線（斷開連線），或者Wi-Fi運行速度低於預期。後者很難識別，因為它首先取決於對速度的期望以及給定區域的即時密度。讓我們討論一些資源，它們有助於您對大型公共場所網路的日常監控。

驗證Wi-Fi吞吐量：測試和監控指南。cisco.com文檔介紹如何監控網路以發現吞吐量問題。它通過計算當環境安靜時，客戶端可以合理地預期網路吞吐量，並估算隨著客戶端數量和負載增加，這些估計值會下降多少。從技術角度評估終端使用者對吞吐量的投訴是否合法，以及是否需要針對可能面臨的負載重新設計該區域，這一點至關重要。

當客戶端報告連線問題時，在通過Catalyst Center隔離並澄清後，請檢視Catalyst 9800客戶端連線問題故障排除流程。

最後，作為一般最佳實踐，藉助Monitor Catalyst 9800 KPI（關鍵效能指標）來關注WLC的總體關鍵指標。

配置以實現可擴充性

9800上的SVI和介面

避免在WLC上為客戶端VLAN建立SVI。管理員習慣於較舊的AireOS WLC，他們往往有反射能力為每個客戶端VLAN建立第3層介面，但很少需要這樣做。介面會增加控制平面攻擊向量，並且可能需要更多ACL以及更複雜的條目。預設情況下，WLC可在其任何介面上存取，但需要更多工作才能保護具有更多介面的WLC。它也會使路由複雜化，因此最好避免它。

從IOS XE 17.9開始，mDNS監聽或DHCP中繼方案不再需要使用SVI介面。因此，在客戶端VLAN中配置SVI介面的原因很少。

聚合探測響應

對於大型公共網路，建議修改接入點傳送的預設聚合探測間隔。預設情況下，AP每500毫秒更新一次WLC來更新客戶端傳送的探測器。此資訊用於負載平衡、頻段選擇、位置和802.11k功能。如果有多個客戶端和接入點，建議修改更新間隔以防止WLC中的控制平面效能問題。建議的設定是每64秒有50個聚合探測響應。此外，請確保您的AP未報告本地管理的MAC地址中的探測，因為考慮到在掃描時單個客戶端可能使用許多本地管理的MAC來避免故意跟蹤，因此跟蹤沒有意義。

wireless probe limit 50 64000

no wireless probe locally-administered-mac

IPv6

許多網路管理員仍然處於拒絕IPv6的狀態。對於IPv6，只有兩個可接受的選項：您要麼支援它，並且必須在所有位置部署足夠的配置，要麼不這樣做，而且必須阻止它。如果不關心IPV6，而讓它在沒有正確配置的某些位置處於啟用狀態，這是不可接受的。這會導致您網路安全人員對整個IP世界視而不見。

如果啟用IPv6，則必須在2001:DB8::/32範圍內配置虛擬IPv6地址（這通常是一個被遺忘的步驟）。

必須注意的是，儘管IPv6的基本操作在很大程度上依賴於組播，但如果您在WLC上禁用組播轉發，IPv6仍可以運行。組播轉發是指客戶端組播資料轉發，而不是指鄰居發現、路由器請求和其他運行IPv6所需的協定。

如果您的Internet連線或Internet服務提供商提供IPv6地址，您可以決定為客戶端允許IPv6。這與在您的基礎架構中啟用IPv6是不同的決定。您的AP只能在IPv4中運行，但仍在其CAPWAP資料包中傳輸IPv6客戶端資料流量。要在您的基礎設施上啟用IPv6，也需要考慮保護客戶端對AP、WLC和管理子網的訪問。

驗證客戶端網關的RA頻率。WLC提供一個RA限制策略，限制轉送到使用者端的RA數量，因為這些RA有時可能會變得繁瑣。

mDNS

通常，最好在大型場地部署中完全禁用mDNS。

mDNS橋接是指允許mDNS資料包作為第2層組播傳送（因此傳送到整個客戶端子網）的概念。mDNS在家庭和小型辦公室場景中非常流行，因為在這種場景中，發現子網中的服務非常實用。但是，在大型網路中，這意味著將資料包傳送到子網中的所有客戶端，這在大型公共網路中從流量角度來看是有問題的。另一方面，橋接不會給AP或WLC CPU造成任何開銷，因為它被視為常規資料流量。mDNS代理或mDNS網關是指將WLC用作網路中所有服務的目錄這一概念。這允許以高效的方式跨第2層邊界提供mDNS服務，同時減少整體流量。例如，透過mDNS閘道，印表機會透過使用相同子網第2層多點傳送的mDNS傳送其定期服務通告，但WLC不會將其轉送到所有其他無線使用者端。相反，它會記錄所提供的服務，並將其註冊到其服務目錄中。每當任何使用者端要求提供給定型別的可用服務時，WLC都會代表印表機回覆通知。這避免了所有其他無線客戶端聽到不必要的請求和服務產品，並且只有在他們詢問存在哪些服務時才會得到回覆。雖然它大幅提升流量效率，但由於mDNS流量的窺探，確實會造成WLC（或AP，如果您在FlexConnect場景中依賴AP mDNS）上的額外負荷。如果使用mDNS網關，請密切關注CPU的使用情況至關重要。

橋接會導致大型子網中的組播風暴，而窺探（使用mDNS網關功能）會導致大量CPU使用率。全域性禁用它，並在每個WLAN上禁用。

有些管理員啟用mDNS，因為一些服務在特定位置需要它，但瞭解這增加了多少不需要的流量很重要。蘋果裝置經常在自我廣告的同時不斷尋找服務，導致了mDNS查詢的背景噪音，即使沒有人專門使用任何服務時。如果您由於特定業務需求而需要允許mDNS，請全域性啟用它，然後僅在需要的WLAN上啟用它，並嘗試限制允許mDNS的作用域。

強化網路

安全性

在大型公共網路中，許多事情在管理員不知情的情況下都會發生。人們會隨機要求電纜掉落，或在某個位置插入家庭級交換機，以便為其詐騙行為設定更多交換機埠……他們通常會先嘗試這些功能，而無需事先徵得許可。這意味著，即使沒有壞行動者的參與，安全也可能會被心甘情願的客戶和/或員工破壞。這樣一來，一個行為不端的參與者就很容易四處走動，找到一條可以接入的電纜，並檢視他們從那裡獲得了什麼網路接入。在所有交換機埠上配置802.1X身份驗證是維護大型網路中良好安全性的基本要求。Catalyst Center可以幫助您自動執行此部署，並且可以為不支援802.1X身份驗證的特定裝置設定例外，但儘量少依賴基於MAC的身份驗證，因為這是（真誠的）不是真正的安全性。

惡意接入點

你對付流氓的策略取決於幾個因素。很多管理者本能地追求非常嚴格的規定，但主要問題是：

• 當您收到數百個（如果不是數千個）惡意警報時，您是否擁有人力資源來檢視所有這些警報並對它們執行操作？
• 您的目標是否是在物理上移除無用裝置，以保持射頻頻譜的清潔？如果是，您需要很多人來執行此操作。或者，你的目標可能只是關注安全因素，確保這些流氓不構成任何危險？這會造成更易管理的人類工作成本。
• 啟用惡意檢測可能會對您的通話時間產生影響，而惡意遏制通常會產生更大的影響。您是否分析了這種影響並將其考慮在內？

關於欺詐檢測的影響，9120和9130具有專用的清潔空氣晶片，負責通道外掃描（因此是欺詐檢測），使得對客戶服務無線電的影響幾乎為零。9160系列AP與其CleanAir Pro晶片具有類似的無影響掃描功能，但其他沒有CleanAir晶片的AP需要將客戶端服務無線電「離通道」掃描惡作劇或進行限制。因此，您正在使用的AP模型將在是否使用專用監控模式AP進行欺詐檢測和遏制決策中發揮作用。

附註：共用Wi-Fi熱點的行動電話以「基礎設施」模式運行，就像傳統AP一樣，「ad-hoc」模式是指流動裝置之間的直接連線，因此不太常見。

非法遏制通常被監管規則禁止，因此您必須在啟用之前與您的當地權威部門進行核實。包含欺詐並不表示遠端關閉欺詐，而是通過取消身份驗證幀向試圖連線到欺詐接入點的客戶端傳送垃圾郵件，使其無法連線。由於您的接入點無法正確對去驗證幀進行簽名，因此它只能對舊式安全SSID起作用（在WPA3中或在WPA2中啟用PMF時不起作用）。密封會對目標通道上的RF效能產生負面影響，因為您的AP正在用取消身份驗證幀填充空時時間。因此，只能將其視為一種安全措施，以防止您自己的合法客戶端錯誤地關聯到欺詐接入點。由於上面提到的所有原因，建議不要進行任何控制，因為它不能完全解決欺詐問題並且會導致更多的RF問題。如果您需要使用遏制措施，則只需為欺騙其中一個受管SSID的惡意使用者啟用該措施即可，因為這是一種明顯的蜜罐攻擊。

您可以使用「使用我們的SSID」選項配置自動包含：

自動包含設定

您還可以配置欺詐規則，根據自己的標準將其分類為惡意欺詐接入點。不要忘記輸入相鄰和已批准的SSID的名稱作為友好無用裝置，以便將其從警報清單中刪除。

啟用AP身份驗證或PMF以保護您的AP免受模擬。

有線欺詐是連線到有線網路的欺詐接入點，這顯然會增加安全威脅。有線欺詐的檢測更為複雜，因為欺詐的乙太網MAC地址通常與其無線電MAC地址不同。Cisco Catalyst Center的演算法仍會嘗試檢測是否有線欺詐，並搜尋在有線基礎架構上可見的無線偵聽惡意客戶端MAC。要完全防止有線欺詐，最好的解決方案是使用802.1X身份驗證保護您的所有交換機埠。

如果您要對欺詐接入點進行物理操作，則利用Cisco Spaces是獲得欺詐接入點準確位置的關鍵。您很可能仍然需要一次在現場進行搜尋，因為有時人們傾向於隱藏惡意AP，但是將搜尋區域縮小到幾米就非常可行了。如果不使用Spaces，則惡意軟體會顯示在地圖上，旁邊的AP會檢測到該惡意軟體，該惡意軟體會發出最大聲響，從而造成相當大的搜尋範圍。許多無線工具和裝置可以即時顯示惡意接入點的訊號，幫助您在物理上定位惡意接入點。

與惡作劇並不完全相關，但因為CleanAir剛剛被覆蓋，所以必須注意，啟用CleanAir對效能沒有明顯的負面影響，除了BLE信標檢測，因為這影響了2.4GHz的效能。您可以將無線配置為完全忽略藍芽干擾源，因為藍芽干擾源在當今世界上無處不在，並且您無法阻止您的客戶端啟用其藍芽。

您的欺詐檢測清單中沒有顯示另一類欺詐。某些客戶端可以在彼此之間使用Wi-Fi直接連線，因此不使用任何接入點。這並不是真正的安全問題，但確實使用RF廣播時間。
其中一個例子是Apple AirDrop，兩台裝置通過藍芽相互檢測，然後可以同意使用Wi-Fi通道傳輸檔案。使用者仍然希望傳輸此檔案，因此最好讓使用者儘快傳輸它，以便干擾儘快停止。但是，請注意，如果VPN應用無法正確處理AWDL介面狀態更改，空投檢測有時會導致VPN隧道翻動；對於終端使用者而言，當實際是其VPN應用與空投協定的組合導致翻動時，您覺得您的基礎設施Wi-Fi品質很差。如果在客戶端上禁用藍芽可以解決問題，則在Wi-Fi端不會出現問題。
另一個眾所周知的例子是Apple SideCar，你可以用iPad將電腦螢幕延伸至另一個顯示器。這會導致顯著的RF利用率，因為流是連續的，並且可以使用較大的通道寬度。

WiPS

WiPS涵蓋更高級的攻擊媒介，而不只是檢測是否存在未經授權的欺詐裝置。除了這些攻擊之外，它有時還會為取證分析提供事件的PCAP。

雖然這對企業來說是一個非常有用的安全功能，但是面向公眾的網路必須面對一個永恆的問題：要怎麼做呢？

由於難以管理許多不受您控制的客戶端，因此可以將警報分為兩類。如果您看到過多的警報，可以決定從Cisco Catalyst Center忽略這些警報：

• 10001:DoS:驗證泛洪警報
• 10002:DoS:關聯請求警報
• 10003:DoS:廣播探測泛洪警報
• 10004:DoS:解除關聯泛洪警報
• 10005:DoS:廣播解除關聯警報
• 10006:DoS:解除驗證泛洪警報
• 10007:DOS:廣播解除驗證警報
• 10008: DOS:EAPOL-Logoff攻擊警報
• 10009:CTS泛洪警報
• 10010:RTS關聯請求警報
• 10011:按對取消身份驗證泛洪
• 10021:Airdrop Session（此會話通常在任何網路中都會發生，並且只描述Apple裝置之間的常規對等活動）
• 10022:關聯請求格式不正確
• 10023:按簽名泛洪的身份驗證失敗
• 10024:簽名的MAC OUI無效
• 10025:身份驗證格式不正確

這些警報可能是由行為不當的客戶端引起的。無法自動阻止拒絕服務攻擊，因為從本質上說，您無法阻止有故障的客戶端讓通話時間處於忙碌狀態。即使基礎結構忽略客戶端，它仍然能夠使用介質和廣播時間進行傳輸，從而影響其周圍的客戶端效能。

其他警報是如此具體，以至於它們極有可能描繪實際的惡意攻擊，而且由於客戶端驅動程式不正確而很難發生。最好持續監控這些警報：

• 10012:模糊信標
• 10013:模糊化探測請求
• 10014:模糊化探測響應
• 10015:按簽名的PS輪詢泛洪
• 10016:EAPOL開始V1泛洪（通過簽名）
• 10017:按目標重新關聯請求泛洪
• 10018:按簽名劃分的信標泛洪
• 10019:按目的地顯示的探測響應泛洪
• 10020:通過簽名阻止Ack泛洪
• 10026/10027 :RTS和CTS虛擬載波偵聽攻擊

無線基礎架構有時可以採取緩解措施，例如阻止列出違規裝置，但擺脫此類攻擊的唯一實際操作是實際前往該位置並刪除違規裝置。

建議啟用所有形式的客戶端排除，以節省與故障客戶端互動所浪費的通話時間。

速率限制客戶端

管理層和管理員會忍不住考慮對使用者進行速率限制，以防止一個使用者在特定位置佔用頻寬。然而，在現場已經多次證明，從總飛行時間的角度來看，不進行任何速率限制會更有效。使用者訪問網路和進行活動的速度越快，離開網路的速度也越快。速率限制傳輸速度不會阻止使用者執行大型檔案傳輸，只會減慢傳輸速度，並在該過程中丟棄資料包，這意味著浪費的總空閒時間比沒有任何限制時更常見。無線速率限制是通過AP在某個時間視窗內從客戶端轉發一定數量的資料包後丟棄資料包來完成的，如果您不按應用程式進行此操作，則有從客戶端丟棄重要流量的風險。但是，如果對每個應用程式都進行此操作，可能會產生與所需不同的效果，因為某些應用程式使用多個連線，這會導致此應用程式的吞吐量計算複雜化。Cisco CX專家建議完全丟棄您不想要的某些應用，而不是使用速率限制。Cisco Wireless Meraki雲文檔也包含此內容：https://documentation.meraki.com/Wireless/Operate_and_Maintain/How_Tos/Firewall_and_Traffic_Shaping/Configuring_Bandwidth_Limitations_and_Enabling_Speed_Burst_on_Wireless_Networks

以及Cisco Wireless Catalyst文檔https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/215441-configure-qos-rate-limiting-on-catalyst.html

限制客戶端訪問

建議在所有WLAN上啟用點對點封鎖（除非您對使用者端與使用者端通訊有硬性要求 — 但必須慎重考慮且可能加以限制）。 此功能可防止同一WLAN上的使用者端彼此連線。這不是一個完美的解決方案，因為不同WLAN上的客戶端仍然能夠彼此聯絡，並且移動組中屬於不同WLC的客戶端也可以繞過此限制。但它是簡單而高效的第一層安全和最佳化。這種點對點阻止功能的另一個優點是它還防止了客戶端到客戶端的ARP，這阻止了應用程式發現本地網路上的其他裝置。如果不進行對等阻塞，在客戶端上安裝簡單的應用程式可能會顯示連線到子網中的所有其它客戶端，其中可能包含其IP地址和主機名。

除此之外，建議在WLAN上同時套用IPv4和IPv6（如果在網路中使用IPv6）ACL，以防止使用者端與使用者端的通訊。無論您是否有客戶端SVI，在WLAN級別應用阻止客戶端與客戶端通訊的ACL都是有效的。

另一個強制步驟是防止無線客戶端訪問任何形式的無線控制器管理。

範例：

ip access-list extended ACL_DENY_CLIENT_VLANS

 10 deny ip any 10.131.0.0 0.0.255.255

 20 deny ip 10.131.0.0 0.0.255.255 any

 30 deny ip any 10.132.0.0 0.0.255.255

 40 deny ip 10.132.0.0 0.0.255.255 any

 50 deny ip any 10.133.0.0 0.0.255.255

 60 deny ip 10.133.0.0 0.0.255.255 any

 70 deny ip any 10.134.0.0 0.0.255.255

 80 deny ip 10.134.0.0 0.0.255.255 any

 90 deny ip any 10.135.0.0 0.0.255.255

 100 deny ip 10.135.0.0 0.0.255.255 any

 110 deny ip any 10.136.0.0 0.0.255.255

 120 deny ip 10.136.0.0 0.0.255.255 any

 130 deny ip any 10.137.0.0 0.0.255.255

 140 deny ip 10.137.0.0 0.0.255.255 any

 150 permit ip any any

此ACL可應用於管理介面SVI:

interface Vlan130

 ip access-group ACL_DENY_CLIENT_VLANS in

這會在具有在第2層VLAN資料庫中建立之使用者端VLAN 131到137的WLC上完成，但沒有對應的SVI，且對於VLAN 130，只有一個SVI存在，而VLAN 130是管理WLC的方式。此ACL可防止所有無線使用者端將任何流量完全傳送到WLC管理和控制平面。不要忘記，SSH或Web UI管理並不是您唯一需要允許的情況，因為還需要允許到所有AP的CAPWAP連線。這就是此ACL具有預設permit但阻止無線客戶端範圍的原因，而不是依賴預設deny all操作來指定所有允許的AP子網範圍和管理範圍。

同樣，您可以建立指定所有可能管理子網的另一個ACL:

ip access-list standard ACL_MGMT

 10 permit 10.128.0.0 0.0.255.255

 20 permit 10.127.0.0 0.0.255.255

 30 permit 10.100.0.0 0.0.255.255

 40 permit 10.121.0.0 0.0.255.255

 50 permit 10.141.0.0 0.0.255.255

然後可以應用此ACL進行CLI訪問：

line vty 0 50

 access-class ACL_MGMT in

 exec-timeout 180 0

 ipv6 access-class ACL_IPV6_MGMT in

 logging synchronous

 length 0

 transport preferred none

 transport input ssh

 transport output ssh

同一ACL也可應用於Web管理員訪問。

防止交通風暴

組播和廣播在某些應用中的使用量比其他應用要多。當考慮純有線網路時，防範廣播風暴通常是唯一的防範措施。但是，當通過空中傳送時，組播與廣播一樣痛苦，瞭解其原因非常重要。首先，假設一個資料包傳送到所有無線客戶端（無論通過廣播還是組播），該資料包可以快速累加到多個目的地。然後，每個AP都需要以儘可能最可靠的方式（儘管不能保證其可靠）在空中傳輸此幀，而這是通過使用強制資料速率來實現的（可以使用強制速率之一進行配置）。 用一般術語來說，這意味著幀是使用OFDM(802.11a/g)資料速率傳送的，這顯然不是很理想。

在大型公共網路中，建議不要依靠組播來保持通話時間。但是，在大型企業網路中，您可能要求為特定應用程式啟用組播，不過您必須儘可能地控制它以限制其影響。最好記錄應用詳細資訊、組播IP，並確保阻止其他形式的組播。如前所述，啟用組播轉發不是啟用IPv6的必要條件。最好完全禁用廣播轉發。應用程式有時會使用廣播來發現同一子網中的其他裝置，這顯然是一個大型網路的安全問題。

如果啟用全域性組播轉發，請確保使用組播 — 組播AP CAPWAP設定。啟用此功能後，WLC收到來自有線基礎架構的多點傳送封包時，會將其透過單一多點傳送封包傳送到所有有興趣的AP，從而節省大量的封包重複成本。確保為每個WLC設定不同的CAPWAP多點傳送IP，否則AP會從其他WLC接收不需要的多點傳送流量。

如果您的AP位於WLC的無線管理介面（可能在大型網路中）的其他子網中，則必須在有線基礎架構上啟用組播路由。您可以使用以下命令驗證所有AP是否正確接收組播流量：

show ap multicast mom

如果需要依賴多點傳送，也建議在所有情況下啟用IGMP（用於IPv4多點傳送）和MLD（用於IPv6）多點傳送。它們僅允許感興趣的無線客戶端（因此僅允許具有感興趣的客戶端的AP）接收組播流量。WLC代理註冊到組播流量，並負責保持註冊活動，從而解除安裝客戶端。

 結論

大型公共網路非常複雜，每個網路都有其獨特的要求和結果。

遵守本文檔中的指導原則是很好的起點，有助於在避免最常見問題的同時實現部署的成功。但是，這些准則只是准則，可能需要在具體地點的背景下進行解釋或調整。

Cisco CX擁有專門從事大型無線部署的無線專業人員團隊，並在包括體育賽事和會議在內的眾多大型活動中擁有豐富的經驗。請與您的客戶團隊聯絡以獲得進一步幫助。