Протокол IP : Service Assurance Agent (SAA)

Использование агента гарантированного обслуживания Cisco Service Assurance Agent и монитора производительности объединенной сети Internetwork Performance Monitor для управления качеством обслуживания в сетях VoIP

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (29 февраля 2016) | Отзыв


Содержание


Введение

Этот документ описывает использование Агента гарантированного сервиса Cisco (SAA) и Internetwork Performance Monitor (IPM) для измерения качества обслуживания (QoS) в сетях Voice over IP (VoIP). Эти сведения основаны на результатах реального проекта IP-телефонии. Этот документ фокусируется на приложении продуктов, не на самих продуктах. Необходимо уже быть знакомы с Cisco SAA и IPM и иметь доступ к требуемой документации по продукту. Посмотрите Дополнительные сведения для ссылок на другую документацию.

Примечание: Функция Cisco SAA в программном обеспечении Cisco IOS₩½ была раньше известна как генератор отчетов о времени реагирования (RTR).

При управлении крупномасштабной сетью VoIP у вас должны быть необходимые программные средства для объективного отслеживания и сообщения на качестве голосовой связи в сети. Не выполнимо полагаться на одну только обратную связь с пользователями, потому что это часто субъективно и неполно. Проблемы качества звука, как правило, вызваны проблемами QoS в сети. Таким образом, при выявлении проблем с качеством голосового соединения необходимо второе средство для управления и отслеживания QoS сети. Пример в этом документе использует Cisco SAA и IPM для этой цели.

Cisco Voice Manager (CVM) используется с Telemate.net для управления качеством голосовой связи. Это сообщает относительно качества голосовой связи вызовов через Коэффициент ухудшения Планирования Ухудшения (ICPIF) / Расчетный Коэффициент ухудшения Планирования (ICPIF), который вычислен шлюзом Cisco IOS для каждого вызова. Это позволяет менеджеру сети определять узлы, которые страдают от низкого качества голосовой связи. См. Управление качеством голосовой связи с Cisco Voice Manager (CVM) и Telemate для получения дополнительной информации.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Этот документ не ограничен определенным программным обеспечением или версиями аппаратного обеспечения, но примеры в этом документе используют эти версии программного и аппаратного обеспечения:

  • Программное обеспечение Cisco IOS версии 12.1(4)

  • IPM 2.5 для Windows NT

  • Коммутатор серии Catalyst 4500

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.

Проблемы системы QoS в сети VoIP

Несколько факторов могут ухудшить качество голосовой связи в сети речевых пакетов:

  • Потеря пакета

  • Чрезмерная задержка

  • Избыточные колебания задержки

Особенно важно, чтобы вы контролировали, они рассчитывают на постоянную основу, если сервисы с коммутацией пакетов используются в глобальной сети (WAN) (например, ATM, Frame Relay или Виртуальная частная сеть IP). Существуют множества сценариев, где перегрузка в коммуникационной сети, формировании трафика неверна настроенного на периферийных устройствах или применении политик неверна настроенного на стороне поставщика услуг может вызвать потерю пакета или избыточную буферизацию. Когда носитель отбрасывает пакеты, на периферийных устройствах нет никакого очевидного признака. Поэтому вам нужно сквозное программное средство как Cisco SAA, который может ввести трафик на входе и проверить его успешное прибытие в выходе.

Управление QoS с Cisco SAA и IPM

Существует три Cisco SAA и компоненты IPM:

  • Проба RTR

  • RTR реагирующий элемент

  • Консоль IPM

Пробный RTR передает несколько пакетов отвечающему RTR. Ответчик RTR возвращает их обратно на зонд. Эта простая операция позволяет зонду измерять потерю пакета и задержку приема-передачи. Для измерения дрожания зонд передает управляющий пакет респонденту, прежде чем это будет инициировать блок пакетов. Управляющий пакет сообщает респонденту сколько миллисекунд (мс) для ожидания между каждым пакетом в пакете. Затем отвечающая сторона измеряет задержку между пакетами во время передачи блока, и любое отклонение от ожидаемого интервала записывается как задержка прихода пакетов.

IPM консоль управляет контролем качества сервиса QoS. Это программирует зонды RTR со связанными сведениями через Протокол SNMP. Консоль также собирает результаты при помощи протокола SNMP. Никакая Конфигурация Cisco IOS интерфейса командной строки не требуется на зондах RTR.

Выполните команду глобальной кофигурации rtr responder, для ручной настройки отвечающих устройств RTR.

Зонды RTR и респонденты должны выполнить программное обеспечение Cisco IOS версии 12.0(5)T или позже. Рекомендовано использовать последнюю служебную версию 12.1 mainstream. Зонды RTR и респонденты в примерах в этом документе выполняют выпуск 12.1 (4). Версия IPM в использовании является IPM 2.5 для Windows NT. Исправление доступно на Cisco.com для этой версии. Это исправление важно, поскольку оно решает проблему, где IPM настраивает зонды RTR с неправильным Параметром приоритета IP (идентификатор ошибки Cisco CSCds02402 (только зарегистрированные клиенты)).

Дизайн

Перед развертыванием Cisco SAA и решения IPM необходимо сделать некоторую дизайнерскую работу с этими факторами в памяти:

  • Размещение зондов RTR и респондентов

  • Тип трафика, который передается от зонда до респондента

Когда вы решаете о размещении зондов и респондентов, существует много вещей учесть. Сначала потребуется, чтобы измерение QoS охватывало каждый узел, а не только проблемные узлы. Это вызвано тем, что номера задержки и дрожания, что отчёты о IPM для данного узла являются самыми полезными когда по сравнению с другими узлами в той же сети. Таким образом вы хотите измерить узлы с хорошим QoS и плохим QoS. Кроме того, хорошо выполняющий узел может стать плохо выполняющим узлом завтра, из-за изменений в структурах трафика или изменениях сети. Вы захотите обнаружить это, прежде чем это будет влиять на качество голосовой связи и будет сообщено пользователями.

Во-вторых, очень важную роль играет уровень загрузки CPU. Возможно, маршрутизатор, уже находящийся в состоянии "занято", будет не в состоянии вовремя обслужить компонент RTR, вызвав тем самым искажение результатов. Кроме того, при размещении слишком многих тестовых экземпляров в какой-либо одиночный маршрутизатор вы могли бы создать проблемы высокой загрузки ЦП даже при том, что ни один не существовал прежде. Подход, выбранный для примера сети в этом документе (и это должно работать в большинстве сетей), должен разместить зонды RTR в удаленное / маршрутизаторы для филиалов. Эти маршрутизаторы, как правило, подключают одиночную LAN с относительно низкоскоростным WAN сервисом. Поэтому вспомогательные маршрутизаторы обычно слабо используют CPU и легко справляются с RTR. Другое преимущество этого дизайна - то, что вы распределяете загрузку через как можно больше маршрутизаторов. Следует иметь в виду, что это, больше работают, чтобы быть зондом, чем быть респондентом, поскольку зонды берут определенную величину Последовательного опроса SNMP.

С этим дизайном отвечающие устройства RTR должны быть размещены в ядро. Респонденты будут более занятыми, чем зонды, потому что они будут отвечать на многие зонды. Таким образом устойчивый дизайн развертывает специализированные маршрутизаторы, которые действуют исключительно как респонденты. Большинство организаций исключило маршрутизаторы на полке, которая может выполнить эту функцию. Подойдет любой маршрутизатор с интерфейсом Ethernet. Также ядро/маршрутизаторы распределения может удвоиться как респонденты. Схема сети в этом разделе изображает оба сценария.

Распределите нагрузку через как можно больше маршрутизаторов и контролируйте использование ЦПУ RTR с этой командой:

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

При соответствии с зондами с респондентами рекомендуется поддержать согласованную топологию между зондом и респондентом. Например, все тесты и все отвечающие устройства должны быть разделены одинаковым числом маршрутизаторов, коммутаторов и каналов 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-RTR - доступ имеет эти линии классификации:

  • 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

    Пакеты RTP разрешения от речевых подсетей с набором приоритета IP-трафика к 5.

  • permit udp any any eq 20000 precedence critical

    Пакеты RTP разрешения от зонда RTR переходить к отвечающему устройству RTR.

  • permit udp any eq 20000 any precedence critical

    Пакеты RTP разрешения от отвечающего устройства RTR, возвращающегося к зонду RTR.

Будьте осторожны, что добавление трафика RTR не заставляет очереди LLQ быть превышенными и заставляет реальные голосовые пакеты быть отброшенными. Стандартная операция IPM Default60ByteVoice передает пакеты пакетов RTP с этими параметрами:

  • Информационное наполнение запроса: 60 байтов

    Примечание: Это - заголовок RTP и голос. Добавьте 28 байтов (IP/UDP) для получения размера дэйтаграммы L3.

  • Интервал: 20 мс

  • Количество пакетов: 10

Это означает, что во время пакета RTR использует 35.2 Кбит пропускной способности LLQ. В случае недостаточной пропускной способности LLQ необходимо создать новую операцию IPM и увеличить интервал пакета. С параметрами, показанными в этом окне конфигурации IPM, пакет использует только 1 кбит/с пропускной способности:

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

Результаты

Таблица в этом разделе является примером отчёта о IPM. В этом отчете содержатся три экземпляра RTR-тестов. Следует иметь в виду, что один физический зонд может быть настроен со множественными экземплярами зонда RTR, которые предназначаются для других респондентов или используют другие информационные наполнения.

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

Это значения каждого из столбцов:

Avg:

IPM рассчитывает среднее значение для каждого часа сбора образцов. Эти почасовые средние значения усредняются по более длительному периоду для получения средних значений за день, неделю или месяц. Другими словами, для ежедневных отчетов IPM вычисляет среднее значение для каждого часа за последние 24 часа. Это тогда вычисляет ежедневное среднее число как среднее число этих 24 средних чисел.

Максимальный из средних показателей:

Это значение является средним числом всех почасовых максимумов в течение каждого дня, недели и месяца в диаграмме. Другими словами, для ежедневного отчета IPM берет самую большую выборку в рамках каждого периода в 24 часа. Это тогда вычисляет ежедневное максимальное среднее число как среднее число этих 24 выборок.

По %:

Это - процент от выборок, которые были по настроенному порогу для коллектора.

Ошибочный %:

Это процент пакетов с ошибкой. Проверка дрожания сообщает о нескольких типах ошибок:

  • Потеря пакета SD — Пакеты проиграли между источником и назначением

  • Потеря пакета DS — Пакеты проиграли между назначением и источником

  • Занятость — количество случаев, когда операция круговой задержки (RTT) не могла инициироваться, потому что не была завершена предыдущая операция RTT

  • Последовательность — количество завершений операции RTT получено с неожиданным идентификатором последовательности. Это некоторые возможные причины, почему это могло бы произойти:

    • Получен дубликат пакета.

    • Отклик был получен после превышения времени ожидания.

    • Поврежденный пакет был получен и не был обнаружен.

  • Отбрасывания — количество случаев, когда произошел любой из них:

    • Операция RTT не могла инициироваться, потому что некоторый необходимый внутренний ресурс не был доступен (например, память или подсистема Сетевой архитектуры систем [SNA])

    • Завершение операции не могло быть распознано.

  • (Пропавший без вести) MIA — количество пакетов, которые потеряны, для которого не может быть определено никакое направление.

  • Поздно — количество пакетов, которые поступили после таймаута.

При просмотре этих сведений возникает вопрос, какие значения задержки, дрожания и ошибок приемлемы в сети VoIP. К сожалению, нет никакого простого ответа к этому вопросу. Допустимые значения зависят от типа кодека, размера буфера отклонения и других факторов. Кроме того, между этими переменными существуют взаимозависимости. Более высокий показатель потери пакетов может означать, что допустим более низкий показатель дрожания.

Лучшим способом получения возможных значений задержки и дрожания является сравнение подобных сайтов в одной сети. Если все 192 подключенных Кбит/с узла, но одно дрожание отчёта оценивают приблизительно 50 мс, и остающийся узел сообщает о дрожании на 100 мс, то существует проблема, независимо от номинальных значений. IPM может предоставить продолжающийся 24x7 измерение задержки и дрожания для всей сети, и это может предоставить срок для использования в качестве сравнительного теста для сравнений задержки и дрожания.

Ошибки являются другим, как бы то ни было. В принципе любой процент ошибок кроме нуля является сигналом тревоги. Пакеты RTR подвергаются такой же обработке QoS, как и голосовые пакеты. Если качество обслуживания (QoS) сети и контроль приема вызовов надежны, ни один уровень перегрузки не вызовет потерю пакетов или избыточную задержку для голосовых пакетов или пакетов RTR. Поэтому можно ожидать, что числа ошибок IPM будут нулем. Единственные ошибки, которые можно было считать “обычными”, являются ошибками Cyclic Redundancy Checks (CRC), но они должны быть редкими в качественной инфраструктуре. Если они являются частыми, они составляют риск для качества голосовой связи.


Дополнительные сведения


Document ID: 13938