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

    Добрый день, коллеги.

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

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

    Есть два канала между точками А и Б, чаще всего от разных провайдеров. Необходимо обеспечить учет качества обслуживания на данных каналах, а именно:
    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.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 37

      0
      Спасибо. Пригодится.
    • UFO just landed and posted this here
        0
        рад, что понравилось :)
          0
          Полезная, но уж больно консервативная. И конфигурование у нее на уровне 70-х годов.
            0
            :))) просветите, а что в плане конфигурирования было сделано существенно лучшее за минувшие 40 лет :) ???
              0
              Я не говорю что это плохо. )) Но есть и другие подходы. Как говориться, каждому свое, кому что нравится.
                0
                так я и прошу привести пример других подходов
                  0
                  например, *nix — подобные системы (текстовые файлы). на каждую задачу свой конфиг. или группа конфигов.
                    0
                    простите, а что это было сделано существенно позже 70х годов?
                      0
                      cдаюсь :)))
                      компания циско создана в 1984 году.
                      юниксы к тому времени уже были…
                      вообщем мы уже ни о чем :)
            • UFO just landed and posted this here
            –3
            Уже было на хабре и не раз.
              0
              пруф?
                –2
                поиск по sla cisco
                  +2
                  прочитайте пожалуйста внимательно, что там предлагается, а что здесь.
              +1
              за идею стабового трекера спасибо.
                0
                идея не моя :) но пожалуйста
                  0
                  объясните мне кто-нибудь что такое этот «стабовый трекер», дословно, с цитатами из словаря, а то джиттер знаю, g.729 знаю,
                  а stub [stʌb] для меня — это суррогат, заглушка

                  или ссылку дайте на страницу просто и ясно описывающую идею и функционал

                  а то какой-то «птичий язык» получается внутри технического ресурса
                    0
                    с цитатами из какого словаря? Вам смысл нужен или терминологическая полемика?

                    track object обычно цепляется напрямую к sla монитору, изменяя свое состояние в зависимости от результата СЛА-операции.

                    stub track-object — не цепляется автоматически ни к чему, его состояние меняется вручную.

                    по поводу, почему так назвали — welcome to cisco online help
                0
                Полезно.
                Пока пользуем первый вариант везде, но пока нет голоса на все сайтах.
                Скоро будет голос и видео, похоже придется задуматься о дельте задержки и потерях.

                  0
                  если каналы короткие, может и особо нет смысла. Но у меня они связывали разные города…
                    0
                    да тоже самое, от Москвы до Новосибирска.
                    и каналы… паршивые :-)
                +1
                А какие циски минимум нужны для поднятия такого решения и на что обращать внимание при покупке чтобы прошивка всё это поддерживала?
                Я делал нечто подобное на роутерах Huawei, с использованием протокола BFD (Bidirectional Forwarding Detection) и технологии FRR (Fast ReRouting).
                  0
                  любой ISR фактически. На ASR не пробовал. на L3-свичах нет стабовых треков, но там можно делать просто добавляя/убавляя строчку в рут-мап или статический маршрут.
                    0
                    Любые, даже на 8хх поддерживается.
                    См. cisco.com/go/fn, Technology, поиск по списку фичи «IP SLA: Udp Voice что-то там».
                    0
                    интересный инстумент для истории — smokeping
                      0
                      безусловно, да в принципе их полно. Только тут это все средствами кошки… я к кошке цепляю PRTG и радуюсь :)
                        0
                        PRTG какой именно? нетворк монитор или графер?
                        т.е. каким продуктом пользуетесь старым или новым?
                          0
                          monitor. У него есть поддержка в т.ч. и Cisco IP SLA, очень удобно вынимает все значения (джиттер, потери, MOS, rtt и т.п.)
                            0
                            я в курсе. я работал с 2-я продуктами. и еще был у них ipcheck который похоронен так же как и графер.
                      0
                      Спасибо, полезная статья.
                        0
                        спасибо за отзыв
                          0
                          илья, добавьте значения загрузки цпу на роутере, по возможности.

                            0
                            Ок, постараюсь сегодня добавить.
                        0
                        EEM – это, конечно, классно, только для проверки нескольких track'ов одновременно, есть решение проще и удобнее:

                        track 1 list boolean {and | or}
                         object 2
                         object 3 [not]

                        Или в 2010-ом IOS ещё не поддерживал?

                        Only users with full accounts can post comments. Log in, please.