Pull to refresh

Мониторинг состояния канала по jitter / packet loss

Reading time 4 min
Views 42K
Добрый день, коллеги.

Собравшись с мыслями, решил нормально оформить родившееся у меня решение.

Итак, постановка задачи:

Есть два канала между точками А и Б, чаще всего от разных провайдеров. Необходимо обеспечить учет качества обслуживания на данных каналах, а именно:
1. При потерях >0.5% на канале, канал не должен использоваться.
2. При jitter > 10мс, канал не должен использоваться.

Такая задача возникла у меня на работе, поскольку два города соединены двумя каналами, по которым бегает в большом количестве голос, который, как известно, весьма капризен в отношении вышеописанных показателей. Кому интересно — милости прошу под кат.

Первоначальное решение.

Изначально было даже два корявых варианта. Первый заключался в поднятии на циске пинговалки, проверяющей живучесть канала и переключение по его смерти. Решение справлялось до тех пор, пока у нас не появились проблемы с джиттером при отсутствии потерь.

Второе решение заключалось в создании монитора на основе udp пакетов, имитирующих G729 кодек. Монитор показывал потери и джиттер, в случае проблем со связью, админ лез на кошку, наблюдал на ней текущие значения джиттера и потерь, и по обстоятельствам принимал решение об отключении канала. Работало, конечно. Но это какая-то полуавтоматическая система получилась. Поэтому я взял себя в руки и довел-таки данную ситуацию до некоторого конечного решения.

Текущее решение.
Итак, как и во втором случае, создаем udp-монитор качества канала, имитирующий G729a кодек (так называемый SLA-монитор).
ip sla 33
udp-jitter 172.16.1.66 49333 source-ip 172.16.1.65 codec g729a codec-size 20
tos 70
threshold 10

Данный монитор будет отправлять 1000 пакетов с интервалом в минуту на порт 49333 у точки назначения, маркировка tos= 70=0x46=EF. На точке назначения должен быть включен
ip sla responder
Далее создаем стабовый трек (создается специально для того, чтобы управлять им с помощью апплетов, а не привязывать жестко к SLA-монитору):
track 20 stub-object
default-state up


Теперь наша задача вынуть результаты из SLA-монитора и по их значениям оставить track 20 в состоянии UP или же положить его. Это можно сделать например с помощью Cisco EEM (Embedded Event Manager), который позволяет отслеживать текущее состояние Вашей железки и выполнять определенные действия.
Для этого создадим два апплета. Один будет класть track в состояние Down, если хотя бы один из параметров (джиттер или число потерь) нас не устраивает. Второй будет поднимать его обратно, если ОБА параметра в норме.

Конфигурация
1. Создаем первый апплет:
event manager applet LB trap
Создаем два события на основе SNMP OID для RTT и jitter От нашего SLA-монитора:
event tag jitter snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.46.33 get-type exact entry-op ge entry-val "10" entry-type value poll-interval 4
event tag loss snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.1.33 get-type exact entry-op le entry-val "994" entry-type value poll-interval 4

Здесь последняя цифра 33 в SNMP OID — номер SLA-инстанции. 10 — порог для джиттера (в мс), 994 — минимально допустимое число вернувшихся пакетов из тысячи посланных (1000 — packet_loss). poll-interval — интервал с которым кошка опрашивает состояние значений. Здесь 4с.
Указываем, что наш апплет должен сработать при ЛЮБОМ из событий, т.е. используется логическое ИЛИ.
trigger
correlate event loss or event jitter

Далее действие:
action 20 track set 20 state down
Т.е. наш трек укладывается в состояние Down.

Второй апплет аналогично:

event manager applet LB2 trap
event tag jitter snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.46.33 get-type exact entry-op lt entry-val "10" entry-type value poll-interval 4
event tag loss snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.1.33 get-type exact entry-op gt entry-val "994" entry-type value poll-interval 4
trigger
correlate event loss and event jitter
action 20 track set 20 state up

Только апплет срабатывает по логическому И между событиями. И трек взводится в состояние Up.

Видно, что опрос происходит с интервалом 4с и текущее состояние трека не учитывается, т.е. трапы срабатывают постоянно, раз в 4с. Я пытался прикрутить еще мониторинг состояния самого трека, но работало очень глючно, срабатывало не всегда. Так что я пожертвовал парой процентов проца и оставил так.

Дополнительно есть еще апплеты, информирующие меня о проблемах на канале и их исчезновении:

event manager applet LB_info
event syslog pattern "20 stub Up->Down"
action 10 syslog msg "applet works!"
action 11 cli command "enable"
action 12 cli command "show ip sla stat 33"
action 13 mail server "192.168.6.20" to "ilya@tut_domen.ru" from "alert@tut_domen.ru" subject "Frame loss or high jitter on NiS channel" body "$_cli_result"

и
в переменной $_cli_result содержится результат вывода последней команды, т.е. в нашем случае — show ip sla stat 33.

event manager applet LB2_info
event syslog pattern "20 stub Down->Up"
action 10 syslog msg "applet 2 works!"
action 11 cli command "enable"
action 12 cli command "show ip sla stat 33"
action 13 mail server "192.168.6.20" to "ilya@tut_domen.ru" from "alert@tut_domen.ru" subject "NiS channel is correct" body "$_cli_result"


Другими словами, мы шлем себе письмо, в теле которо – результат последнего запуска SLA-монитора, собственно и вызвавшего переключение трека.

Так, теперь собственно как это учитывать. Я вижу два способа:

1. строчка в route-map (как и работает у меня, собственно, но там просто схема хитрая)
set ip next-hop verify-availability 172.16.1.66 1 track 20
2. трекинг статики, когда у нас есть маршрут вида
ip route 172.16.0.0 255.255.255.0 192.168.1.1 track 20
При потерях или джиттере на канале данный маршрут просто уберется из таблицы маршрутизации и трафик пойдет по альтернативному пути.

Может и коряво, но я промучившись неделю лучше ничего не придумал. Чем богаты, как говорится.

P.S. Я подразумеваю, что читатель немного знаком с основами консоли Cisco
P.P.S. Синтаксис ip sla команд разнится на 12.4Т и 12.4, но смысл такой же.
P.P.S. Если требуется пояснения, не выходящие за границу нескольких строк — пишите, добавлю.

С уважением,
Подкопаев Илья

_________
UPD: по поводу CPU. в общем под нагрузкой без апплетов у меня загрузка роутера (ISR 3845) порядка 42% в среднем, с апплетом — 43-44.
Tags:
Hubs:
+42
Comments 37
Comments Comments 37

Articles