antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 12 Октябрь , 2010

Введение:

Не смог пройти мимо.
Нижеприведенная статья — это результат изысканий Ильи Подкопаева ака Ilya.
Как мне кажется, статья грамотная и очень полезная с практической точки зрения, как бы автор не принижал свою умственную работу.

Итак, читайте: настройка мониторинга состояния канала одновременно по задержке и джиттеру с переключением канала по условию и сбросом статистики на почту.


Привожу без сокращений публикацию на форуме (где она рискует затеряться)

_______________________________________________________________________________

Значит у меня работает так. Есть две линии, одна основная, вторая резервная.

Основная мониторится 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

и стабовый трек: (создается специально для того, чтобы им управлял ЕЕМ)

track 20 stub-object
default-state up

В качестве основных параметров мониторю число потерь (точнее число вернувшихся пакетов из 1000 посланных) и средний джиттер. Если число пакетов меньше 994 ИЛИ джиттер больше 10ти — 20й трек укладывается в 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
action 30 track read 20

event manager applet LB 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 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
trigger
   correlate event loss or event jitter
action 20 track set 20 state down
action 30 track read 20

Видно, что опрос происходит с интервалом 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"


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-монитора, собственно и вызвавшего переключение трека.

Ну и учитываю я это с помощью ПБР. Можно и с помощью трекинга static

set ip next-hop verify-availability 172.16.1.66 1 track 20

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

Ссылка на источник

 

Метки: , , ,
Опубликовано: Маршрутизаторы и коммутаторы

 

» Оставить комментарий

Вы должны войти чтобы прокомментировать.