使用Cisco服務保證代理和Internetwork Performance Monitor管理IP語音網路中的服務品質

下載選項

PDF (448.6 KB)
在多種裝置上使用 Adobe Reader 檢視
ePub (243.9 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
Mobi (Kindle) (318.8 KB)
在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視

已更新: 2017 年 8 月 29 日

文件 ID:13938

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本檔案介紹使用思科服務保證代理(SAA)和網際網路效能監控器(IPM)來衡量IP語音(VoIP)網路中的服務品質(QoS)。此資訊基於真實的IP電話專案。本文檔重點介紹產品的應用，而不是產品本身。您應該已經熟悉Cisco SAA和IPM，並有權訪問所需的產品文檔。請參閱相關資訊以獲取對其他文檔的引用。

注意：Cisco IOS®軟體中的Cisco SAA功能以前稱為Response Time Reporter(RTR)。

管理大規模VoIP網路時，您必須擁有必要的工具來客觀地監控和報告網路中的語音品質。僅僅依靠使用者反饋是不可行的，因為這通常是主觀的，而且是不完整的。語音品質問題通常源自網路QoS問題。因此，當您發現語音品質問題時，您需要第二個工具來管理和監控網路QoS。本文檔中的示例為此使用Cisco SAA和IPM。

Cisco Voice Manager(CVM)與Telemate.net配合使用來管理語音品質。它通過Cisco IOS網關為每個呼叫計算的減值/計算規劃減值係數(ICPIF)報告呼叫的語音品質。這樣，網路管理員就可以識別語音品質較差的站點。如需詳細資訊，請參閱使用Cisco Voice Manager(CVM)和Telemate管理語音品質。

必要條件

採用元件

本檔案所述內容不限於特定軟體或硬體版本，但本檔案中的範例使用以下軟體和硬體版本：

Cisco IOS 軟體版本 12.1(4)
IPM 2.5 for Windows NT
Catalyst 4500系列交換器

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

VoIP網路中的QoS問題

在分組化語音網路中，有多種因素會降低語音品質：

封包遺失
過度延遲
過度抖動

如果WAN中使用分組交換服務（例如ATM、幀中繼或IP虛擬專用網路），則持續監控這些數字尤為重要。在許多情況下，運營商網路中的擁塞、邊緣裝置上的流量整形配置錯誤或運營商側上的策略配置錯誤都可能導致資料包丟失或過度緩衝。當運營商丟棄資料包時，邊緣裝置上沒有明顯的證據。因此，您需要像Cisco SAA這樣的端到端工具，能夠在入口處注入流量，並驗證流量是否成功到達出口。

使用Cisco SAA和IPM管理QoS

有三個Cisco SAA和IPM元件：

RTR探測
RTR響應程式
IPM控制檯

RTR探測器向RTR響應器傳送分組突發。RTR應答器將它們轉過身來將它們傳送回探測器。這種簡單的操作允許探測器測量資料包丟失和往返延遲。為了測量抖動，探測器在啟動資料包突發之前向響應方傳送控制資料包。控制資料包通知響應方突發中每個資料包之間的預期毫秒(ms)。然後，響應方測量突發期間的包間延遲，並且與期望間隔的任何偏差被記錄為抖動。

IPM控制檯控制QoS監控。它通過簡單網路管理協定(SNMP)使用相關資訊對RTR探測進行程式設計。它還通過SNMP收集結果。RTR探測功能不需要命令列介面Cisco IOS配置。

發出rtr responder全域性配置命令，手動配置RTR響應器。

RTR探測和響應程式必須運行Cisco IOS軟體版本12.0(5)T或更高版本。建議使用最新版本的12.1主流維護。本文檔示例中的RTR探測和響應程式運行版本12.1(4)。使用的IPM版本是IPM 2.5 for Windows NT。Cisco.com上有適用於此版本的修補程式。此修補程式很重要，因為它修復了IPM使用錯誤的IP優先順序設定配置RTR探測器的問題。

設計

在部署思科SAA和IPM解決方案之前，必須考慮以下事項：

RTR探測器和響應器的放置
從探測傳送到響應方的流量型別

在決定探測和響應器的位置時，需要考慮許多事項。首先，您希望QoS測量覆蓋每個站點，而不僅僅是問題站點。這是因為，與同一網路中的其他站點相比，IPM報告的給定站點的延遲和抖動數最有用。因此，您想要測量具有良好QoS和較差QoS的站點。此外，由於流量模式的變化或網路變化，效能良好的站點明天可能會成為效能較差的站點。您需在它影響語音品質且由使用者報告之前檢測到它。

其次，CPU利用率非常重要。已經繁忙的路由器可能無法及時為RTR元件提供服務，從而可能會使結果產生偏差。此外，如果在任何一台路由器上放置了過多的探測例項，則可能會產生較高的CPU使用率問題，即使以前不存在這種情況。本文檔中為示例網路選擇的方法（在大多數網路中應該適用）是在遠端/分支路由器上放置RTR探測器。這些路由器通常將單個LAN連線到相對較慢的WAN服務。因此，分支路由器的CPU利用率通常很低，而且可以輕鬆應對RTR。此設計的另一個優點是可以在儘可能多的路由器間分配負載。請記住，作為探測比作為響應者更費力，因為探測需要一定數量的SNMP輪詢。

在此設計中，RTR響應器必須放置在核心中。響應器將比探測器更繁忙，因為它們將響應許多探測器。因此，強大的設計部署專用的路由器，這些路由器僅充當響應者。大多陣列織都有可以執行此功能的已停用的路由器。帶有乙太網介面的任何路由器都滿足要求。或者，核心層/分佈層路由器可以兼做響應者。本節中的網路圖說明這兩種情況。

將負載分散到儘可能多的路由器，並使用以下命令監控RTR CPU使用情況：

Router# show processes cpu | i Rtt|PID

PID  Runtime(ms)  Invoked  uSecs  5Sec   1Min   5Min    TTY Process
67           0         7      0   0.00%  0.00%  0.00%   0 Rtt Responder

將探測與響應器匹配時，建議在探測和響應器之間保持一致的拓撲。例如，所有探測器和響應器之間應該用相同數量的路由器、交換機和WAN鏈路分隔。只有這樣，IPM結果才能在站點之間直接比較。

在此示例中，有200個遠端站點和4個核心/分佈站點。每個分佈站點的Catalyst 4500充當專用RTR響應器。200台遠端路由器中的每台都充當RTR探測器。每個探測器針對位於直連分發站點的響應方。

網路必須為探針傳送到響應者的突發流量提供與語音相同的QoS級別。這可能表示您必須調整路由器上的低延遲佇列(LLQ)或路由表通訊協定(RTP)優先順序組態，才能使來自RTR探查的流量接受嚴格的優先順序佇列。當您配置RTP資料包的探測功能時，只能控制目標使用者資料包協定(UDP)埠，不能控制源埠。本示例網路中的典型LLQ路由器配置具有訪問清單，這些清單專門將RTR資料包分類到與語音相同的隊列中：

class-map VoiceRTP
  match access-group name IP-RTP

policy-map 192Kbps_site
  class VoiceRTP
    priority 110

ip access-list extended IP-RTP
  deny   ip any any fragments
  permit udp 10.0.16.0 0.255.239.255
             range 16384 32768 10.0.16.0 0.255.239.255
             range 16384 32768 precedence critical
  permit udp any any eq 20000 precedence critical
  permit udp any eq 20000 any precedence critical

IP-RTP訪問清單包含以下分類行：

deny ip any any片段

拒絕任何IP分段，因為第4層存取清單會隱式允許這些分段。
permit udp 10.0.16.0 0.255.239.255 range 16384 32768 10.0.16.0 0.255.239.255 range 16384 32768 precedence critical

允許IP優先順序設定為5的語音子網的RTP資料包。
permit udp any any eq 20000 precedence critical

允許來自RTR探測的RTP資料包進入RTR響應程式。
permit udp any eq 20000 any precedence critical

允許來自RTR響應器的RTP資料包返回到RTR探測。

請注意，新增RTR流量不會導致LLQ隊列超訂用並導致實際語音資料包被丟棄。標準Default60ByteVoice IPM操作會傳送具有以下引數的RTP資料包猝發：

請求負載：60 位元組

注意：這是RTP報頭和語音。新增28位元組(IP/UDP)以取得第3層資料包大小。
間隔：20毫秒
封包數量：10

這意味著在突發期間，RTR消耗35.2 Kb LLQ頻寬。如果沒有足夠的LLQ頻寬，則建立新的IPM操作並增加資料包間隔。使用此IPM配置視窗中顯示的引數，突發僅消耗1 Kbps的頻寬：

結果

本節中的表是IPM報告的示例。此報表包含三個RTR探測例項。請記住，一個物理探測器可以配置多個RTR探測器例項，這些例項針對不同的響應者或使用不同的負載。

以下是每欄的含義：

平均值：

IPM計算每個取樣小時的平均值。然後這些小時平均值在更長的時間段內取平均值，以獲得每日、每週或每月平均值。換句話說，對於每日報告，IPM計算過去24小時內每個小時的平均值。然後，它將這24個平均值的平均值計算日平均值。

平均最大值：

此值是圖表中每天、每週和每月的所有每小時最大值的平均值。換句話說，對於每日報告，IPM取的是過去24小時內報告的最大樣本。然後，計算這24個樣本的平均值的每日最大平均值。

超過%:

這是超過為收集器配置的閾值的樣本百分比。

錯誤%:

這是遇到錯誤的資料包的百分比。抖動探測報告多種型別的錯誤：

SD Packet Loss — 源與目的地之間丟失的資料包
DS Packet Loss — 目的地和來源之間丟失的資料包
Busies — 由於前一個RTT操作未完成而無法啟動來回時間(RTT)操作的次數
Sequence — 使用意外序列識別符號接收的RTT操作完成數。以下是可能發生此情況的一些可能原因：
- 收到重複的資料包。
- 在超時後收到響應。
- 收到損壞的資料包，但未檢測到。
Drops — 發生以下任一情況的次數：
- 無法啟動RTT操作，因為某些必要的內部資源不可用（例如記憶體或系統網路架構[SNA]子系統）
- 無法識別操作完成。
MIA(Missing in Action) — 無法確定方向的丟失資料包數。
延遲 — 超時後到達的資料包數。

此資訊引起的問題是VoIP網路中哪些延遲、抖動和錯誤值是可接受的。不幸的是，這個問題沒有簡單的答案。可接受值取決於編解碼器型別、抖動緩衝區大小和其他因素。此外，這些變數之間也存在相互依賴性。較高的資料包丟失可能意味著可以容忍更小的抖動。

獲得有效延遲和抖動圖的最佳方法是比較同一網路中的類似站點。如果所有192 Kbps連線的站點都報告抖動值約為50 ms，而其餘站點報告抖動值為100 ms，則無論標稱值如何，都存在問題。IPM可以為整個網路提供不間斷的24x7延遲和抖動測量，並且可以提供基準作為延遲和抖動比較的基準。

但錯誤是不同的。原則上，除零以外的任何錯誤百分比都是紅色標誌。RTR分組被給予與語音分組相同的QoS處理。如果網路QoS和呼叫准入控制是穩健的，則任何級別的擁塞都不會導致語音或RTR資料包丟失或過度延遲。因此，可以預期IPM錯誤計數為零。唯一可以視為「正常」的錯誤是循環冗餘校驗(CRC)錯誤，但這些錯誤在品質基礎設施中應該很少見。如果頻率很高，則會對語音品質構成風險。