使用 Cisco Service Assurance Agent 和 Internetwork Performance Monitor管理 VOIP网络的服务质量

简介

本文档介绍使用思科服务保证代理(SAA)和网际网络性能监控器(IPM)来测量IP语音(VoIP)网络中的服务质量(QoS)。此信息基于实际IP电话项目。本文档重点介绍产品的应用，而不是产品本身。您应该已经熟悉思科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)报告呼叫的语音质量。这样，网络管理员便可以识别语音质量较差的站点。有关详细信息，请参阅使用思科语音管理器(CVM)和Telemate管理语音质量。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档不限于特定软件或硬件版本，但本文档中的示例使用以下软件和硬件版本：

• Cisco IOS 软件版本 12.1(4)

• IPM 2.5，用于Windows NT

• Catalyst 4500 系列交换机

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

VOIP 网络中的 QoS 问题

在分组语音网络中，以下几个因素可能降低语音质量：

• 包丢失

• 延迟过大

• 抖动过大

如果WAN中使用分组交换服务（例如ATM、帧中继或IP虚拟专用网络），则务必持续监控这些图。 有很多情况下，运营商网络拥塞、边缘设备上的流量整形配置错误或运营商端策略配置错误都可能导致数据包丢失或过度缓冲。当运营商丢弃数据包时，边缘设备上没有明显的证据。因此，您需要像思科SAA这样的端到端工具，该工具可以在入口注入流量并验证其成功到达出口。

使用思科SAA和IPM管理QoS

思科SAA和IPM有三个组件：

• RTR探测

• RTR响应器

• IPM控制台

RTR探测器向RTR响应器发送数据包突发。RTR响应器将其转动，并将其发送回探测器。此简单操作允许探测器测量丢包和往返延迟。为了测量抖动，探测在响应方启动数据包突发之前向响应方发送控制数据包。控制数据包通知响应方突发中每个数据包之间预期的毫秒数。然后，响应器测量突发期间的分组间延迟，并且与期望间隔的任何偏差记录为抖动。

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个远程站点和四个核心/分布站点。每个分布站点的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 fragments

  拒绝任何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 precedence crital

  允许RTR探测到的RTR响应器的RTP数据包。

• permit udp any eq 20000 precedence critical

  允许来自RTR响应器的RTP数据包返回RTR探测。

请注意，添加RTR流量不会导致LLQ队列超订用并导致实际语音数据包丢弃。标准Default60ByteVoice IPM操作发送RTP数据包突发，其参数如下：

• 请求负载：60 bytes

  注意：这是RTP报头和语音。添加28个字节(IP/UDP)以获取L3数据报大小。

• 间隔:20 毫秒

• 数据包数:10

这意味着，在突发时，RTR消耗35.2 Kbs的LLQ带宽。如果LLQ的带宽不足，则创建新的IPM操作并增加数据包间隔。使用此IPM配置窗口中显示的参数，突发仅消耗1 Kbps的带宽：

结果

本节中的表是IPM报告的示例。此报告包含三个RTR探测实例。请记住，一个物理探测器可能配置了多个RTR探测器实例，这些实例针对不同的响应者或使用不同的负载。

以下是每列的含义：

平均：

IPM计算每小时采样的平均值。然后，这些小时平均值在较长的时间段内平均，以获得每日、每周或每月平均值。换句话说，对于每日报告，IPM计算过去24小时每小时的平均值。然后，它计算日平均值，作为这24个平均值的平均值。

平均最大值：

此值是图表中每天、每周和每月所有每小时最大值的平均值。换句话说，在每日报告中，IPM采集过去24小时内报告的最大样本。然后，它计算这24个样本的平均日最大平均值。

超过%:

这是超出为收集器配置的阈值的样本百分比。

错误%:

这是遇到错误的数据包的百分比。抖动探测功能报告多种错误：

• SD丢包 — 源和目的之间丢包

• DS丢包 — 目的地和源之间丢失的数据包

• 业务 — 因之前的RTT操作尚未完成而无法启动往返时间(RTT)操作的次数

• 序列 — 使用意外序列标识符接收的RTT操作完成数。以下是可能发生的原因：

  • 收到重复的数据包。

  • 在超时后收到响应。

  • 收到损坏的数据包，但未检测到。

• 丢弃 — 发生以下任一情况的次数：

  • 无法启动RTT操作，因为某些必要的内部资源不可用（例如内存或系统网络架构[SNA]子系统）

  • 无法识别操作完成。

• MIA(Missing in Action) — 无法确定任何方向的丢失数据包数。

• 延迟 — 超时后到达的数据包数。

此信息产生的问题是VoIP网络中可接受的延迟、抖动和错误值。不幸的是，这个问题没有简单的答案。可接受的值取决于编解码器类型、抖动缓冲区大小和其他因素。此外，这些变量之间还存在相互依赖关系。丢包率越高，可能意味着可以容忍的抖动越少。

获取可用延迟和抖动数据的最佳方法是比较同一网络中的类似站点。如果所有连接192 Kbps的站点（但一个站点报告抖动值约为50 ms，其余站点报告抖动100 ms），则无论额定值如何，都会出现问题。IPM可以为整个网络提供持续的24x7延迟和抖动测量，并可以提供基准作为延迟和抖动比较的基准。

但是，错误是另一回事。原则上，除零以外的任何错误百分比都是红色标志。RTR数据包与语音数据包的QoS处理相同。如果网络QoS和呼叫准入控制稳健，则任何拥塞程度都不应导致语音或RTR数据包的数据包丢失或过长延迟。因此，您可以预期IPM错误计数为零。唯一可以视为“正常”的错误是循环冗余校验(CRC)错误，但在高质量基础设施中，这些错误应该很少出现。如果频繁出现，则会对语音质量构成风险。

相关信息

• 推荐读物：Cisco IP 电话故障排除
• 技术支持和文档 - Cisco Systems