IP : Service Assurance Agent (SAA)

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

2016 年 10 月 24 日 - 机器翻译
其他版本: PDFpdf | 英语 (2016 年 2 月 29 日) | 反馈


目录


简介

本文描述使用Cisco Service Assurance Agent (SAA)和互联网性能监控(IPM)测量在VoIP网络的服务质量(QoS)。此信息根据一个真实世界的IP电话项目。本文着重在产品的应用程序,不产品。您应该已经熟悉Cisco SAA和IPM和访问需要的产品文档。请参阅相关信息关于对其他文档的参考。

注意: Cisco SAA功能在思科IOSï ¿  ½软件方面以前叫作响应时间报告(RTR)。

当您管理一个大规模VoIP网络时,您必须有必要的工具客观监控并且报告关于在网络的语音质量。因为它经常主观和不完整,不可行取决于在单独用户反馈。语音质量问题典型地源于网络QoS问题。因此,当您识别语音质量问题时,您需要第二个工具管理和监控网络QoS。在本文的示例为此使用Cisco SAA和IPM。

Cisco语音管理器(CVM)与Telemate.net一起使用管理语音质量。它报告关于由每呼叫的Cisco IOS网关计算呼叫的语音质量通过损坏/适当的计划损伤因素(ICPIF)。这允许网络管理器识别遭受拙劣语音质量的站点。参考的管理与Cisco语音管理器(CVM)的语音质量和Telemate欲知更多信息。

先决条件

要求

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

使用的组件

本文没有限制对特定软件或硬件版本,但是在本文的示例使用这些软件和硬件版本:

  • Cisco IOS软件版本12.1(4)

  • Windows NT的IPM 2.5

  • Catalyst 4500系列交换机

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

规则

有关文档规则的详细信息,请参阅 Cisco 技术提示规则

VOIP 网络中的 QoS 问题

几个要素能降低在分组的语音网络的语音质量:

  • 包丢失

  • 额外延迟

  • 过度抖动

重要的是特别您持续地监控这些图,如果包交换服务用于广域网(例如, ATM、帧中继或者IP虚拟专用网络)。有在运营商网络的拥塞,在边缘设备的不正确的配置的流量整形或者在运营商侧的不正确的配置的管制能导致包丢失或额外的缓冲的许多方案。当载波丢弃数据包时,没有在边缘设备的明显的证据。所以,您需要一个端到端工具类似能注入在入口的流量的Cisco SAA并且验证其成功的到达在出口。

管理与Cisco SAA和IPM的QoS

有三Cisco SAA和IPM组件:

  • RTR探测器

  • Rtr responder

  • IPM控制台

RTR探测器发送数据包突发流量对Rtr responder。Rtr responder转过来他们并且送回他们到探测器。此简单操作允许探测器测量包丢失和往返时延。在启动信息包突发前,要测量抖动,探测器发送控制数据包到响应方。控制数据包通知响应方预计的多少毫秒(毫秒)在突发流量的每数据包之间。在突发流量期间,响应方然后测量信息包间延迟,并且从预计间隔的所有偏差被记录作为抖动。

IPM控制台控制QoS监听。它通过简单网络管理协议(SNMP)编程有相关信息的RTR探测器。它通过SNMP也收集结果。命令行界面Cisco IOS配置在RTR探测器没有要求。

发出rtr responder全局配置命令,手工配置RTR响应方。

RTR探测器和响应方必须运行Cisco IOS软件版本12.0(5)T或以后。推荐12.1主流最新的维护版。RTR探测器和响应方在示例在本文运行版本12.1(4)。IPM版本在使用中是Windows NT的IPM 2.5。补丁程序是可用的在Cisco.com为此版本。此补丁程序是重要,因为解决IPM配置有一个不正确IP优先设定的问题(Cisco Bug ID CSCds02402 (仅限注册用户)) RTR探测器。

设计

在您部署Cisco SAA和IPM解决方案前,您在头脑里必须执行若干设计与这些考虑事项一起使用:

  • RTR探测器和响应方的放置

  • 从探测器发送到响应方的流量类型

当您决定关于探测器和响应方的放置时,有考虑到的一定数量的事。首先,您希望QoS测量覆盖每个站点,不仅问题站点。这是因为IPM为一个给的站点报告的延迟和抖动编号是最有用的,当与其他站点比较在同一网络。因此,您要测量有好QoS恶劣的QoS的站点。并且,一个执行好的站点可能明天变为性能较差站点,由于在流量模式或网络更改上的变化。在影响语音质量和由用户前,报告您将要检测此。

其次, CPU利用率是重要。一个繁忙的路由器可能不已经能以适时的方式服务RTR组件,并且这可能偏移结果。并且,如果在任何单个路由器放置许多探测器实例,您也许制造高CPU利用率问题,即使什么都以前没有存在。为在本文(和此的示例网络选择的方法在多数网络应该工作)将放置RTR探测器在远程/分支路由器。这些路由器典型地连接单个LAN对一相对低速广域网服务。因此,分支路由器经常有非常低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

/image/gif/paws/13938/csaaipm1.gif

当您匹配探测器用响应方时,推荐您维护在探测器和响应方之间的一一致拓扑。例如,应该由路由器、交换机和广域网链路同一数量分离所有探测器和响应方。可能IPM结果在站点中直接地那时比较。

在本例中,有200个远程站点和四个核心/分布站点。在每个分布站点的一台Catalyst 4500作为专用的Rtr responder。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层访问列表隐性允许这些。

  • 允许udp 10.0.16.0 0.255.239.255范围16384 32768 10.0.16.0 0.255.239.255关键范围16384 32768的优先

    允许从语音子网的RTP数据包IP优先级设置到5。

  • 允许udp关键所有任何eq 20000的优先

    允许从去Rtr responder的RTR探测器的RTP数据包。

  • 允许udp所有eq 20000关键任何的优先

    允许从Rtr responder去的上一步的RTP数据包到RTR探测器。

小心RTR流量的新增内容不造成LLQ队列过度预定和造成实时语音数据包丢弃。标准的Default60ByteVoice IPM操作发送RTP数据包突发流量有这些参数的:

  • 请求有效负载:60个字节

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

  • 间隔:20 毫秒

  • 数据包编号:10

这意味着在突发流量期间, RTR消耗35.2 Kbs LLQ带宽。如果没有LLQ的充足的带宽,则请创建一新的IPM操作并且增加packet interval。当参数表示在此IPM配置窗口,突发流量消耗only1 Kbps带宽:

/image/gif/paws/13938/csaaipm2.gif

结果

在此部分的表是IPM报告的示例。此报告包含三个RTR探测器实例。记住一台物理探测器可能配置与瞄准不同的响应方或使用不同的有效载荷的多个RTR探测器实例。

/image/gif/paws/13938/csaaipm3.gif

这些是其中每一的含义列:

Avg :

IPM计算一平均值每个小时采样。这些每小时平均数在一个长时间间然后平均获得日报、每星期或者每月平均数。换句话说,对于日报, IPM计算平均值每个小时过去24个小时。它然后计算日平均作为这24个平均数平均值。

Avg麦斯:

此值是所有每小时最大数量平均值为每天、周和月在图表。换句话说,对于日报, IPM采取在过去24个小时中的每一个内报告的最大的示例。它然后计算每天最大数量平均值作为这24示例平均值。

在% :

这是在收集器的配置的阈值示例的百分比。

错误% :

这是遇到错误数据包的百分比。抖动探测器报告错误的几种类型:

  • SD包丢失—在源和目的之间的信息包丢失

  • DS包丢失—在目的地和来源之间的信息包丢失

  • 占线—场合数量,当Round-Trip Time (RTT)操作不可能被发起,因为一上一个RTT操作未完成

  • 顺序— RTT用一个意外的顺序标识符接收的操作完成数量。这些是一些可能的来源这为什么也许发生:

    • 重复的数据包接收。

    • 在暂停了后,答复接收。

    • 损坏的数据包接收和未检测。

  • 丢包—场合数量,当这些之一发生:

    • RTT操作不可能被发起,因为一些必要的内部资源不是可用的(例如,内存或系统网络结构[SNA]子系统)

    • 操作完成不能被认可。

  • MIA (操作时丢失) —丢失方向不可以确定数据包的数量。

  • 后—在超时以后到达数据包的数量。

从此信息出现的问题是什么延迟、抖动和错误值是可接受在VoIP网络。不幸地,没有简单的回答对此问题。可接受值取决于编解码器类型、抖动缓冲区大小和其他要素。另外,有在这些变量之间的相互依赖性。一更高的包丢失可能含义较少抖动可以被容忍。

得到可使用的延迟和抖动形象的最佳方法是比较同一网络的相似的站点。如果全部192个附带192kbps站点,但是一报告抖动值大约50毫秒和剩余的站点报告100毫秒抖动,然后那里是问题,不管标称值。IPM能为整个网络提供持续的24x7延迟和抖动测量,并且能为延迟和抖动比较提供基准使用作为基准。

然而错误不同的。原则上,除零之外的任何错误百分比是红旗。RTR数据包给QoS处理和语音数据包一样。如果网络QoS和呼叫接纳控制是稳健的,级别拥塞不应该导致包丢失或额外延迟语音或RTR数据包的。所以,您能盼望IPM错误计数是零。可能认为“正常”的唯一的错误是循环冗余冗余校验(CRC)错误,但是这些应该是少见的在质量基础设施。如果他们常见,他们构成风险对于语音质量。


相关信息


Document ID: 13938