驗證Wi-Fi吞吐量：測試和監控指南

簡介

本文檔介紹如何監控大型Wi-Fi網路中的吞吐量問題並對其進行故障排除。

上下文

在Wi-Fi網路中，終端使用者發現的問題型別並不多。

報告的問題範圍包括：

• 客戶端無法連線；
• 客戶端突然斷開連線或；
• 使用者裝置上的應用的感知速度並不令人滿意。

在這些簡單的症狀背後，可能有數百種問題，大多數甚至都不涉及實際的Wi-Fi網路，如DNS問題、Internet連線問題等。

Cisco Catalyst Center等管理伺服器可幫助管理員排除特定問題，本文不會詳細介紹通過Catalyst Center可以輕鬆檢視和修復的許多日常問題。相反，本文檔重點介紹終端使用者對網路速度慢的比較模糊的反饋意見。

如何測試？如何驗證整個網路的實際吞吐量？如何將速度相關問題分類到可操作的專案中，以改善整體終端使用者體驗？

這些都是本文檔試圖回答的問題。

定義最大預期吞吐量

每個網路中的第一個問題是：可能且實際達到的最大速度是多少？

由於Wi-Fi是共用介質，因此所體驗的速度直接取決於同一通道上同時使用Wi-Fi的客戶端和裝置的數量。因此，這個可以直接達到的實際最大速度的問題意味著在安靜的隔離區域（無人使用同一個Wi-Fi通道）中有一個單獨的客戶端裝置和單個接入點。在這些情況下，確定最大速度的因素歸結為：

• 使用的Wi-Fi協定(Wi-Fi 5、Wi-Fi 6、...)
• 客戶端和接入點的硬體功能（天線數、空間流數、接入點的乙太網連線數……）
• 配置（通道寬度， ...）

瞭解這些因素後，您就可以估計在實驗室條件下達到的最大實際吞吐量。

為了快速瞭解情況，您需要檢查要連線到接入點的客戶端報告的資料速率。此資料速率不是您在測試中可以證明的實際吞吐量。這是因為Wi-Fi是半雙工介質，它有一些管理開銷（需要確認幀，需要傳送信標），並且幀之間的靜音時間短，以便更好地接收和解碼。這意味著，當傳送資料時，資料按記錄的資料速率傳送，但資料並不總是傳送。管理和控制幀以低得多的資料速率傳送，以確保接收。據估計，您可以考慮達到實際吞吐量測試中使用的資料速率的65%至70%。例如，如果您的客戶端報告已連線且正在以866Mbps的速度傳送資料，則實際測試必須報告傳輸速度約為600Mbps。

如果您知道正在使用的配置引數以及涉及的裝置的硬體功能，您還可以計算出必須達到的最大資料速率（因此通過使用本節中記錄的百分比計算可以得出吞吐量）。

如果報告的資料速率與希望達到的速率不匹配，可以通過配置開始故障排除過程，並驗證各種引數以瞭解差距的位置。

一個示例：如果您擁有接入點型號C9120在5Ghz頻段內以20Mhz通道寬度進行廣播和典型的2空間流Wi-Fi 6客戶端，則可以計算出，在非常乾淨的RF（射頻）環境中，在單個客戶端上，您希望在單個檔案傳輸中實現160至200Mbps的速度。

有關吞吐量測試和驗證的更多資訊，請參閱https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/212892-802-11ac-wireless-throughput-testing-and.html。

建立基線體驗

瞭解在典型情況下您的場所中可預期的內容非常重要。通常情況下，技術人員會在部署實施前先訪問空白站點，執行速度測試並記錄預期數量。

然後，員工或顧客來了，網站變得繁忙，實際體驗差異很大。

部署啟動後，派遣技術人員衡量每個區域的實際體驗，記錄網路在平均良好時期的外觀，這是個聰明的想法。

這包括當網路在令人滿意的水準運行時，每個無線電台的平均客戶機數量，以及通過速度測試獲得的平均吞吐量。

查詢體驗偏差

在運行網路時，可以輕鬆監控重大警報或突然關閉的裝置。本文檔重點介紹難點：如何發現仍在運行但提供欠佳終端使用者體驗的無線網路。

查詢問題的證據（被動測試）

您已經親自測試了您的網路；您知道它運行良好，並且您正在監控管理系統和儀表板。沒有任何東西被報導為下降：你可以退後一步放鬆一下。還是你能？

如果你等待那些抱怨體驗不佳的終端使用者的呼應，你可能會為時已晚。當終端使用者投訴時，問題已經持續了很長時間，您只會聽到少數幾個發出足夠響亮的聲音的使用者投訴。

無數的使用者已經感到沮喪，對您或您的幫助台隻字不提，但卻給您的網路留下不好的名聲。

所以，問題是：你如何能一發現不良體驗的發生？

1. Cisco Catalyst Center上的客戶端保證控制面板

在Cisco Catalyst Center保證控制面板中，有一個客戶端健康狀況的整體圖表。

由於有人輸入錯誤的金鑰或裝置位於覆蓋範圍的最邊緣，因此始終存在一些無法連線的客戶端，因此不要希望達到100%的正常客戶端，但要熟悉在您的環境中正常客戶端的比例有多高。

90年代是典型的好消息。

只需快速掃一眼，您就能看到不健康的客戶發生了什麼事情：

• 它們是否距離AP（接入點）很遠？
• 是驗證問題嗎？

在此圖中，您可以很容易地看到每個類別的比率。

在相同的想法範圍內，您可以滾動到該頁面的底部並進行過濾，以顯示報告為健康狀況不佳的客戶端裝置。然後您可以嘗試找出是否存在任何模式：

• 它們可能都連線在2.4Ghz頻段（已知在許多情況下會提供較差的體驗）；
• 它們可能都是在低訊號強度下被報告的；
• 它們可能都位於同一物理區域。

2. Cisco Catalyst Center上的網路保證控制面板和裝置360

要發現特定潛在問題區域，一個特別好的指標是訪問Cisco Catalyst Center的「網路保證」頁面。您有一個小部件，按客戶端數量顯示頂級接入點：

如果網路中的頂級接入點已連線40個客戶端，則表明您狀態良好。這表示所有其他AP（接入點）的客戶端計數都較低。

另一方面，如果您發現頂級AP的客戶端數量異常多，則可以推測該客戶端的體驗特別差（除非大多數客戶端都在睡眠且不在網路中活動）。

然後，您可以轉到「每個AP」調查，在該調查中，您可以放大此小元件中報告的特定頂級AP，以瞭解其當前運行狀況。

檢視客戶端計數的另一種方法是轉到Catalyst Center的「網路層次結構」頁中的對映。進入樓層檢視頁面後，點選「檢視選項」(View Options)，然後在「接入點」(Access Points)部分將顯示更改為「關聯」(Assoc)。Clients」，顯示每個AP的客戶端計數：

對映技術的優點是您可以發現具有高客戶端數的AP的位置，並評估高計數是否合理（在給定時刻人群聚集在該位置可能有很好的理由）。

您還可以檢視相鄰的AP：如果它們共用一些負載，則情況良好。如果一個AP的客戶端計數異常高，而相鄰AP完全沒有客戶端，情況會變得更加可疑。

相鄰AP可能存在問題（如果其客戶端計數為零），或者RF設計可能導致有問題的AP吸引與其鄰居相比的所有客戶端（例如，由於TX功率和/或天線不同）。

該對映為您提供每個AP上關聯的客戶端的良好概述

一旦您確定了客戶端計數極高的潛在有問題的AP，您可以搜尋該AP名稱並開啟裝置360頁面。

運行狀況圖提供該無線接入點的運行狀況是剛剛出現不佳還是在最後一天或更長時間一直處於不佳狀態的概述。

在同一頁面上，您會看到與該AP相關的一系列問題。在這種情況下，顯然兩個無線電都處於高使用率狀態。

事件檢視器可以讓您瞭解是否存在與該AP相關的特定事件。

例如，RRM演算法設定運行過於頻繁並且導致通道頻繁更改，從而影響連線的客戶端，或者無線電由於各種問題或干擾而不斷重置其自身。

在裝置360頁面的末尾，您可以將檢視設定為「RF」，選擇特定的無線電，並且您會獲得有趣的資訊，以便評估問題的根源。

擁有大量客戶並不一定是個問題，這完全取決於他們的活躍程度。

有時，即使有少數客戶端，AP也可能忙碌，並提供不良體驗。實際指標是通道利用率。

當通道利用率接近100%（甚至從70%開始）時，客戶端開始為介質訪問、經歷延遲和衝突而激烈競爭。

這些圖表允許您比較總通道利用率和此AP部分責任。

例如，如果通道利用率為80%，這意味著有「某人」通過通道傳輸的時間為80%。如果AP顯示40%的Rx利用率和40%的Tx利用率，您知道只有此AP負責保持通道忙碌（即沒有其它AP在傳輸），並且它在接收和傳輸之間處於良好的平衡狀態。如果AP組合的Rx和Tx使用率遠遠低於通道使用率，則意味著另一個AP（欺詐或受管）正在使用相同的通道並導致同通道干擾。

此螢幕截圖顯示了通道非常繁忙的AP(91%):

該圖顯示，只有7%的利用率是由其他AP和非WiFi源造成的，而AP在82%的時間內忙於傳輸，只有2%的時間處於接收狀態。

客戶端數量和總吞吐量表明一個或多個客戶端可能正在下載大型檔案。

干擾圖允許您確定通道是否因Wi-Fi傳輸或實際干擾（非Wi-Fi）而保持繁忙：

作為結論，根據經驗法則，您需要照顧客戶端計數最高且通道利用率最高的AP。然後，您需要評估此負載是否合理，以及它是否給該領域的終端使用者帶來不良體驗。

3.人工智慧分析

AI分析為您提供更智慧的監控。監控不再基於固定閾值，而是根據您的基線使用情況進行調整。

網路熱圖為您提供客戶端計數的演變，讓您發現一週內客戶端計數最高的AP。您還可以輕鬆發現始終未連線客戶端的AP：相反的問題也是問題。

這些AP可能存在物理問題（安裝問題、天線問題等），或者如果無線電凍結（並且該AP的重新啟動修復了它）則存在軟體問題。

Trends and Insights頁面為您提供定期顯示高通道利用率或客戶端活動的AP清單，以便您可以輕鬆交叉檢查這是否與最繁忙的區域相匹配，或者是否存在異常情況：

主動測試基礎架構

當使用者報告特定領域的體驗較差時，您希望積極測試該體驗以確認他們的反饋。典型測試與實際客戶端流量有很大差異，瞭解這一點很重要。

使用者通常會嘗試使用他們喜愛的應用程式，如果應用程式能運行，使用者會感到高興。他們很少傳輸大檔案。他們最喜愛的應用程式可能有不同的行為：

• 隨選影片：這可能會佔用任意數量的頻寬（視影片是720p還是4K而定）。
  • 它非常容忍抖動，因為它預先緩衝幾秒鐘或幾分鐘影片。該模式在短時間內看起來像一個大型檔案傳輸，然後在影片從緩衝區播放期間保持靜默，直到下次預載入為止。
• 語音呼叫：這僅佔用極少量的頻寬，但對延遲和抖動極為敏感。
  • 這可以潛在地使用QoS（服務品質）標籤，因而面對與盡力流量不同的體驗（按優先順序排序）。
• 資料：社群媒體應用程式以突發方式下載資料。
  • 根據內容以及使用者滾動的速度，數量會有所不同。

典型的吞吐量測試應用程式會最大化協定以達到儘可能高的傳輸速度：它嘗試預訂介質並傳送儘可能多的資料幀。這並不是與實際應用程式（檔案傳輸除外）相同的使用型別，這些應用程式在本質上是非常易爆發的。

測試真實的應用程式會模仿使用者行為，但無法得到要比較的實際指標和數字。只有網路暢通與否時，才會產生主觀感受。

在吞吐量測試方面，許多網站很受歡迎，在測試客戶端和網際網路之間的整個頻寬時，它們提供了終端使用者體驗的真實情況。但是，如果您要單獨驗證您的無線網路與Internet連線、路由和防火牆問題，建議使用專用的吞吐量測試工具，如Iperf:https://community.cisco.com/t5/wireless-mobility-knowledge-base/iperf-test-for-measuring-the-throughput-speed-of-a-wlan-client/ta-p/3142047。

此工具允許在客戶端和您放置到網路中的伺服器之間進行特定測試。這樣，您就可以將伺服器移動到網路中的特定位置，並測試較長網路部分的吞吐量，以驗證每個部分。首先將Iperf伺服器放在與無線客戶端所在的AP相同的交換機上（如果是本地交換或支援結構的無線），或者放在與WLC（無線LAN控制器）相同的交換機上（如果可能，放在客戶端VLAN中）（如果是集中交換）。

如果您使用錨點WLC，則必須將Iperf伺服器放在與錨點WLC相同的交換器上，因為錨點WLC是流量終止的位置。有時建立非錨點WLAN（無線LAN）很有趣，看看是否錨點本身與非錨點WLAN相比，會造成潛在令人失望的吞吐量結果。

使用多個客戶端同時進行吞吐量測試實際上並不合理。在吞吐量測試期間，希望該單個客戶端使用整個可用通道通話時間。因此，如果兩個客戶端同時執行吞吐量測試，則它們各自將結果至少分為一半。如果使用更多客戶端，衝突開始以數字形式出現，結果不再具有代表性。

有多個第三^方工具可自動執行網路測試。請注意，當您在一個區域測試吞吐量時，您實際上是在測試期間使用所有通話時間，因此，過於頻繁地測試網路會干擾其他客戶端，是不明智的做法。

排除吞吐量問題

確定吞吐量問題時，可以考慮以下幾件事來隔離問題：

• 如果在開始測試之前RF環境已經繁忙，請隔離。通道利用率越高（超出測試範圍），吞吐量測試結果就越低。如果發現通道利用率問題，請檢查同一通道上的同一區域中是否存在其他AP，並重新考慮您的RF設計。減少通道寬度、消除欺詐以及使用覆蓋範圍更集中的不同天線都是很好的選擇。新增更多AP並非總是最佳選擇。
• 獲取吞吐量測試的Over-The-Air捕獲，檢視在802.11層是否有大量資料重試（以所有資料幀的百分比計）。重試次數多意味著RF環境可能是問題。還要檢查使用的資料速率、潛在的次優協定或使用空間流的數量。在空中捕捉中，大型資料傳輸是非常典型的，您會看到數十個資料幀具有相同的源和目標，彼此之間的增量時間非常短，隨後是塊ACK。如果傳輸的特徵是在每個資料幀之後都有一個常規ACK，或者存在大量請求傳送/清除傳送，那麼可以很容易地解釋低吞吐量。
• 驗證WLAN上的所有安全型別是否均發生吞吐量問題。有時，客戶端和AP之間的特定安全不相容會導致吞吐量降低。