Donnerstag, 31. März 2016

Тест IP-канала на основе Cisco IP SLA и триггер доступности канала в Zabbix.

(Текст не мой, источник его возникновения установить уже трудно)
Тест используется для оценки пригодности IP-канала, построенного на базе оборудования компании Cisco Systems, к передаче голосового трафика с кодеком G.711u (либо другим используемым на предприятии кодеком )
Пороговые значения основаны на рекомендациях EIA/TIA.
Тест основан на технологии Cisco IP SLA компании Cisco Systems.

Измеряемые характеристики и пороговые значения:


SNMP Device Availability (%) − процентное отношение числа успешных транзакций получения статистической информации с активного маршрутизатора к общему числу выполненных транзакций.

JitterPositiveSD (usec) − средний положительный разброс времени прихода пакетов от Источника к Ответчику. Измеряется в микросекундах.

JitterNegativeSD (usec) − средний отрицательный разброс времени прихода пакетов от Источника к Ответчику. Измеряется в микросекундах.

JitterPositiveDS (usec) − средний положительный разброс времени прихода пакетов от Ответчика к Источнику. Измеряется в микросекундах.

JitterNegativeDS (usec)
− средний отрицательный разброс времени прихода пакетов от Ответчика к Источнику. Измеряется в микросекундах.

PacketLossSD
− число потерянных пакетов от Источника к Ответчику.

PacketLossDS
− число потерянных пакетов от Ответчика к Источнику.

PacketOutOfSequence − число пакетов, пришедших с нарушением последовательности.

PacketMIA
− число пакетов, потерянных на неизвестном направлении (на направлении от Источника к Ответчику или от Ответчика к Источнику).

PacketLateArrival − число пакетов, пришедших с превышением тайм-аута.

NumOfOW
− число успешных измерений времени доставки пакетов в одну сторону.

OWLatencySD (usec)
− среднее время доставки пакета от Источника к Ответчику. Измеряется в микросекундах.

OWLatencyDS (usec)
− среднее время доставки пакета от Ответчика к Источнику. Измеряется в микросекундах.

Характеристики OWLatencySD и OWLatencyDS измеряются только в том случае, если у Источника и Ответчика синхронизированы внутренние таймеры. Если значения этих характеристик равны нулю, то это означает, что по каким-то причинам синхронизация не произошла.

Delay (usec) – это суммарное время, требуемое для передачи IP-пакета от Источника к Ответчику и обратно (круговая задержка). В общем случае это время включает в себя три вида задержек. Задержку распространения сигнала по каналам связи (propagation delay).
Задержку, вносимую активным сетевым оборудованием (transport delay). Задержку, вносимую входным буфером, компенсирующим разброс времени прихода пакетов (jitter buffer delay). Суммарное значение первых двух задержек обычно называют сетевой задержкой (network delay). Технология измерения круговой задержки такова, что последний тип задержки (jitter buffer delay) автоматически вычитается из суммарного времени, поэтому можно считать, что круговая задержка - это двойная сетевая задержка.

Jitter (usec) − это разброс времени прихода IP-пакетов. Данный параметр вычисляется следующим образом. Источник, отправляя пакет Ответчику, присваивает ему временную метку. Ответчик, принимая пакет, присваивает ему вторую временную метку. На основе этих меток Ответчик вычисляет время передачи IP-пакета по сети. В тесте передача пакетов между Источником и Ответчиком производится пачками. Например, каждую минуту в каждом направлении передается пачка из 100 пакетов. Для каждой пачки вычисляется среднее арифметическое значение разброса времени прихода пакетов. Вычисляется разброс в одну и другую сторону, после чего из этих значений выбирается наибольшее. Это значение присваивается характеристике «Jitter (usec)» для пары IP-адресов (Источник, Ответчик).

Packet Loss (%)
− процент потерянных пакетов. Это процент IP-пакетов (UDP-пакетов), потерянных при передаче от Источника к Ответчику или в обратном направлении (выбирается наибольшее значение) за определенный период времени (по умолчанию – 1 минута).

The Number of Round Trip Operations − число удачных измерений. Это вспомогательный параметр, позволяющий удостовериться, что Отвечик (устройство Cisco Systems) сконфигурирован правильно, и что процесс измерения качества IP-канала проходит успешно. Данный параметр вычисляется следующим образом. Источник периодически (по умолчанию – каждую минуту) посылает Ответчику пачку UDP-пакетов. По умолчанию в каждой пачке посылается 100 пакетов. Ответчик принимает эти пакеты и посылает такие же пакеты Источнику. Если пакеты, отосланные Источником, возвращаются к нему, то это означает, что тест проходит успешно. Если к Источнику возвращается все 100 пакетов, то значение параметра «SAA NumRTT’s» будет 100. Поскольку какие-то пакеты могут искажаться или теряться, число полученных пакетов может быть меньше числа отосланных пакетов (меньше 100). Если значение параметра «SAA NumRTT’s» равно 0, то это означает, что ни один пакет не вернулся к Источнику, т.е. тест не работает. (UPD: этот параметр удобно использовать в Zabbix для мониторинга доступности канала. Ниже описано как)

MOS (Mean Opinion Score)
− субъективная оценка качества голосовых данных, вычисляемая на основе Метода Экспертных Оценок. Принимает значения от 1 (наихудшее) до 5 (наилучшее).

ICPIF (Impairment/Calculated Planning Impairment Factor)
– оценка ухудшения качества связи.

Рассчитывается по формуле:

ICPIF = Idd + Ie - A , где

Idd – ухудшение, вносимое сквозной (end-to-end) задержкой;

Ie
– ухудшение, вносимое потерей пакетов, дополнительно зависит от используемого кодека;

A (Advantage Factor) – коэффициент ожидаемого ухудшения качества связи. Задается в параметрах теста, зависит от типа используемого канала связи, например:
  •  0 − Обычная проводная линия связи;
  •  5 − Mобильный доступ внутри зданий;
  • 10 − Мобильный доступ внутри географической области;
  • 20 − Доступ в труднодоступное место.

Чем меньше значение оценки ICPIF, тем лучше качество связи.

Наиболее показательные значения это MOS и ICPIF. Вот какие пороговые значения существуют для этих методов оценки:

ICPIF
5 Very Good
10 Good
20 Adequate
30 Limiting case
45 Exceptional limiting case
55 Customers likely to react strongly

MOS
5 Excelent
4 Good
3 Fair
2 Poor
1 Bad

Как это настраивается на Cisco:

R3#do sh run | sec ip sla 21
track 21 ip sla 21 reachability
ip sla 21
udp-jitter 10.100.32.85 49333 source-ip 10.100.32.86 codec g729a codec-size 20
tos 46
threshold 50
tag R3-SWG15_20Mb
Сначала вносим ip-destination и порт  которые будут использоваться для проверки, потом ip-source с которого будет осуществляться проверка. Тут, я думаю, вопросов нет.

Далее таблица с сайта Cisco которая содержит дефолтные значения настроек:
Table  UDP Jitter Operation Parameters
UDP Jitter Operation Parameter
Default
Configuration Commands
Number of packets (N)
10 packets
udp-jitter num-packets
Payload size per request packet (S)
10 bytes
request-data-size
Payload size per response packet (P)
The default response data size varies depending on the type of IP SLAs operation configured.
Note   If the response-data-size command is not configured, then the response data size value is the same as the request data size value.
response-data-size
Time between packets, in milliseconds (T)
10 ms
udp-jitter interval
Elapsed time before the operation repeats, in seconds (F)
60 seconds
frequency (IP SLA)
Теперь логика работы настроенного IP SLA:
Каждые 60 секунд (frequency default) посылается 10 пакетов (udp-jitter num-packets default), с интервалом между пакетами 10 мс (udp-jitter interval default) и размером 10 байт. IP SLA имитирует пакеты голосового кодека g729a, маркировка tos= 70=0x46=EF.
На обратной стороне канала (на втором маршрутизаторе) должен быть настроен 
ip sla responder.
Собственно вся настройка. Теперь можно настроить treck и как-то реагировать на изменения параметров, например убирая этот канал из маршрутизации. У меня стояла задача вывести данные в мониторинг.

Настройки в Zabbix

В Zabbix-е будем считывать 4 параметра:
  • Изменение Jitter-а OID .1.3.6.1.4.1.9.9.42.1.5.2.1.46.21
  • ICPIF OID .1.3.6.1.4.1.9.9.42.1.5.2.1.43.21
  • MOS OID .1.3.6.1.4.1.9.9.42.1.5.2.1.42.21
  • NumRTT OID .1.3.6.1.4.1.9.9.42.1.5.2.1.1.21
При считывании этих данных с устройства получаем:
  • Изменение Jitter-а: 1
  • ICPIF: 11
  • MOS: 406
  • NumRTT: 1000
То есть немного не то, что написано в теории. Наверное у Cisco немного свой взгляд на некоторые вещи. Теперь нам необходимо, чтобы дынные всех четырех параметров отображались на одном графике. Для этого необходимо выставить правильные поля "Тип информации" и "Пользовательский множитель" в настройке Элемента данных в Zabbix.
Итак выбираем:
  • Изменение Jitter-а: Числовой (плавающая точка), Множителя нет
  • ICPIF: Числовой (целое положительное), Множителя нет
  • MOS: Числовой (плавающая точка), Множитель 0,01
  • NumRTT: Числовой (плавающая точка), Множитель 0,01
В итоге получаем следующие значения в Zabbix-е:
  • Изменение Jitter-а: 1
  • ICPIF: 11
  • MOS: 4,06
  • NumRTT: 10
Пример настройки элемента данных для Jitter-a, остальные настраиваются аналогично, но параметр "Пользовательский множитель" и "Тип информации" надо менять.

Теперь мы получаем необходимые данные, необходимо их визуализировать. Делаем в Zabbix-е графики. График привязывается к узлу сети (устройству). То есть в Zabbix-е заходим в "Узлы" и выбираем "Графики"->"Создать график"
Далее эти графики можно собирать в комплексные экраны. Комплексные экраны можно делать например по-филиально, либо  по определенному оператору связи, это как удобней будет последствии просматривать.

Этот же IP SLA можно отслеживать через триггер в Zabbix, чтобы знать о падении канала как описано здесь  http://steinkafer.blogspot.ru/2015/12/zabbix-cisco-ip-sla.html

UPD: более логично отслеживать параметр NumRTT. Правда это применимо только при отслеживании канала между двумя устройствами Cisco. Т.к. для такого IP SLA нужен ip sla responder.
Как это выглядет в Zabbix:


Логика триггера на это событие очень проста. Если данный параметр равен 0, то канал считается упавшим. Так как параметр NumRTT работает с задержкой, то исключаются ложные сработки триггера.



Keine Kommentare:

Kommentar veröffentlichen