對Catalyst 9000交換機上的網路相關音訊問題進行故障排除

簡介

本文說明如何在IP語音(VoIP)環境中排除與網路相關的音訊問題。

需求

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

• Qos
• VoIP網路
• SPAN（交換器連線埠分析器）
• Wireshark

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• Catalyst 9200
• Catalyst 9300
• Catalyst 9400
• Catalyst 9500
• Catalyst 9600

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

在VoIP基礎架構中，音訊品質可能受到網路相關問題的影響，這些問題包括：

• 語音或斷斷續續的音訊存在斷斷續續的間隙。
• 單向音訊。
• 不是隔離給單個使用者，而是隔離給具有共同特徵（例如共用同一個VLAN或共用同一接入交換機）的一組使用者。

為了排除與網路相關的問題，語音資料包的源到目的地之間必須有一個清晰的拓撲。問題的診斷可以從網路中交換或路由語音資料包的任何點開始，但建議從接入層開始排除故障並轉到路由層。

網路圖表

在路徑中選擇一個捕獲點。它可以是A（最接近一個IP電話）、B（路由之前）、C（最接近目的地）。

SPAN擷取通常是在兩個方向（TX和RX）擷取，以識別對話的兩端，並從擷取各自的音訊，以及其他變數（例如抖動、或封包遺失）以進行進一步分析。

確定擷取點後，在交換器上設定SPAN組態。

Switch(config)#monitor session 1 source interface Gig1/0/1 both
Switch(config)#monitor session 1 destination interface Gig1/0/6 encapsulation replicate 
Switch#show monitor session all
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/0/1
Destination Ports : Gi1/0/6
Encapsulation : Replicate
Ingress : Disabled

發起測試呼叫，以捕獲來自使用Wireshark的PC/筆記型電腦中選定捕獲點的音訊流。

捕獲分析

1.開啟使用Wireshark捕獲的資料包並導航到Statistics > Conversations。根據相關裝置的IP地址（IP電話源和目標）查詢音訊對話。

2.通常，音訊流由UDP協定承載，並且大多數時候未以適當的格式進行解碼，Wireshark無法提取嵌入其中的音訊。然後，下一步是將UDP流解碼成音訊格式，預設情況下使用RTP。按一下右鍵流的任何資料包，然後按一下Decode as。

3.查詢Current列並選擇RTP。按一下「OK」（確定）。

Wireshark將整個UDP流解碼為RTP，現在我們可以分析內容。

注意:RTP Player能夠播放已安裝外掛支援的任何編解碼器。RTP Player支援的編解碼器取決於您正在使用的Wireshark版本。官方版本包含由Wireshark開發人員維護的所有外掛，但是自定義/分發版本不包括這些編解碼器中的一些。要檢查您的Wireshark安裝的編解碼器外掛，請執行以下操作：開啟Help>關於Wireshark。選擇「外掛」頁籤。在「Filter by type」選單中，選擇「Codec」。

4.檢查RTP統計資訊，檢視音訊流中是否存在任何抖動或丟失。要檢視分析，請導航到Telephony > RTP > RTP Stream Analysis。

抖動：通過網路傳送語音資料包的時延。這通常是由網路擁塞或路由變化引起的。此測量值必須小於30ms。

丟失：未作為音訊流的一部分接收的資料包。丟包率不得超過1%。

5.在電話> RTP > RTP流中轉換來自此流的音訊波

6.選擇要將其轉換為音訊的流，然後按一下播放流。

必須顯示音訊波，並且播放按鈕可用於收聽音訊資料。聽到音訊有助於識別流是否存在語音波動或單向音訊問題。

7.按一下匯出>檔案同步音訊，將流匯出到副檔名為.wav的音訊檔案中。

疑難排解

使用SPAN功能通過Wireshark收集和分析捕獲後，我們就會瞭解問題是否與抖動、封包丟失或單向音訊有關。如果在資料包捕獲中發現任何問題，下一步是檢查捕獲的裝置，查詢可能會影響RTP音訊流的常見問題。

斷斷續續的音訊

頻寬不足、抖動和/或丟包可能是音訊捕獲中聽到語音中斷或失真的常見原因。

1.檢查捕獲上的抖動是否大於30毫秒。如果是，則表示接收資料包時存在時間延遲，這可能是由於QoS策略或路由問題造成的。

2.檢驗捕獲時丟失的資料包是否大於1%。如果此值很高，則需要查詢音訊流路徑上的資料包丟包。

3.檢查路徑中涉及的輸入和輸出介面上是否有捨棄專案。

Switch#show interface Gi1/0/1 | inc drops
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
0 unknown protocol drops

Switch#show interfaces Gi1/0/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi1/0/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Gi1/0/1 0 0 0 0 0 0

驗證介面上沒有遞增的輸入/輸出捨棄或其他遞增錯誤。

4.檢查路徑中涉及的介面上的QoS出口策略。確保您的流量在優先順序隊列中對映/分類，並且此隊列中沒有丟棄。

Switch#show platform hardware fed switch 1 qos queue stats interface Gi1/0/1
----------------------------------------------------------------------------------------------
AQM Global counters
GlobalHardLimit:  3976   |   GlobalHardBufCount: 0
GlobalSoftLimit: 15872   |   GlobalSoftBufCount: 0

----------------------------------------------------------------------------------------------
High Watermark Soft Buffers:  Port Monitor Disabled
----------------------------------------------------------------------------------------------
Asic:0 Core:1 DATA Port:0 Hardware Enqueue Counters
----------------------------------------------------------------------------------------------
 Q Buffers          Enqueue-TH0          Enqueue-TH1          Enqueue-TH2             Qpolicer
   (Count)              (Bytes)              (Bytes)              (Bytes)              (Bytes)
-- ------- -------------------- -------------------- -------------------- --------------------
 0       0                    0               707354              2529238                    0 <<< Priority Q
 1       0                    0                    0              1858516                    0
 2       0                    0                    0                    0                    0
 3       0                    0                    0                    0                    0
 4       0                    0                    0                    0                    0
 5       0                    0                    0                    0                    0
 6       0                    0                    0                    0                    0
 7       0                    0                    0                    0                    0
Asic:0 Core:1 DATA Port:0 Hardware Drop Counters
--------------------------------------------------------------------------------------------------------------------------------
 Q             Drop-TH0             Drop-TH1             Drop-TH2             SBufDrop              QebDrop         QpolicerDrop
                (Bytes)              (Bytes)              (Bytes)              (Bytes)              (Bytes)              (Bytes)
-- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
 0                    0                    0                    0                    0                    0                    0 <<< Priority Q Drops
 1                    0                    0                    0                    0                    0                    0
 2                    0                    0                    0                    0                    0                    0
 3                    0                    0                    0                    0                    0                    0
 4                    0                    0                    0                    0                    0                    0
 5                    0                    0                    0                    0                    0                    0
 6                    0                    0                    0                    0                    0                    0
 7                    0                    0                    0                    0                    0                    0 

注意：如果存在丟棄，請確保使用DSCP加速轉發(EF)標籤正確分析語音流量，並確認沒有其他惡意流錯誤地標籤了EF位，因此導致優先順序隊列擁塞。

單向音訊

當電話呼叫建立時，只有一方接收音訊。此問題的常見原因與連通性問題、路由問題或NAT/防火牆問題有關。

1.對目標子網或目標網關執行ping操作以確認存在雙向可達性。

Switch#ping 192.168.1.150
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.150, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

2.執行從源子網到目標子網的traceroute，反之亦然。這有助於檢查路徑中的跳數以及它是否對稱。

Switch#traceroute 192.168.1.150
Type escape sequence to abort.
Tracing the route to 192.168.1.150
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.2.12 2 msec * 1 msec
2 192.168.1.12 2 msec * 1 msec
3 192.168.1.150 2 msec 2 msec 1 msec

3.檢查每個子網的網關裝置是否具有最佳路由，並且沒有可能會影響通訊的非對稱路徑。

提示：常見的單向音訊問題與防火牆規則或NAT問題上的ACL配置錯誤有關。建議驗證這些事物是否可能影響音訊流流。

4.在最後一台裝置上進行資料包捕獲，在該裝置上看到音訊流量指向故障方向。這有助於隔離哪台路徑中的裝置丟失了音訊流。這一點非常重要，因為可以通過NAT或防火牆裝置允許ping流量，但是可以阻止或無法正確轉換特定音訊流量。

相關資訊

• 思科技術支援與下載