Меню

Как подключить cisco к zabbix

Zabbix + Cisco ISR: мониторим загрузку VPN-туннелей посредством SNMP + Perl script + LLD

Задача: Имеется роутер Cisco с кучей настроенных site-to-site IPsec-VPN-туннелей. Нужно настроить мониторинг загрузки туннелей в Zabbix 2.0.x
Предполагается, что SNMP на циске и в Zabbix’е уже настроен.

Основная проблема заключается в том, что нужные нам для мониторинга номера SNMP OIDs с отсчётами трафика формируются динамически. Мало того, списки этих номеров — также формируются динамически.

Это является следствием того, что сам алгоритм построения туннеля довольно сложен. Сперва формируется служебный ISAKMP туннель, затем основной IPSEC-туннель для данных. Подробнее об этом можно почитать тут: linkmeup.ru/blog/50.html (кстати, отличный обучающий цикл статей этого автора по основам настройки оборудования Cisco уже был на Хабре).

Конкретный алгоритм извлечения заветных отсчётов трафика настолько мутный, что реализовать его чисто встроенными средствами Zabbix, по-видимому, невозможно. Да что там, даже художественно перевести у меня не получилось. Позволю себе описание с форума www.networking-forum.com:

those OIDs refer to bytes used solely over the phase 1 tunnel. In order to get actual user traffic over the phase 2 tunnels you must get the phase 1 index ID using the endpoint address from SNMPv2-SMI::enterprises.9.9.171.1.2.3.1.7, then map that to the phase 2 index ID(s) from SNMPv2-SMI::enterprises.9.9.171.1.3.2.1.2, then you can use SNMPv2SMI::enterprises.9.9.171.1.3.2.1.26 and SNMPv2-SMI::enterprises.9.9.171.1.3.2.1.39 with the phase 2 index ID appended for the actual phase 2 traffic.

К счастью, добрые люди с форума Cacti написали перловый скрипт, который всю чёрную работу делает сам.

Скачаем скрипт и закинем в папку ExternalScripts (/usr/local/share/zabbix/externalscripts по умолчанию).

Поскольку туннелей много и иногда они меняются, применим LLD (правила низкоуровнего обнаружения) в Zabbix, чтобы туннели все сами обнаруживались и прописывались у нас в системе.
Делаем новый шаблон, а в нём — правило обнаружения и прототипы элементов данных на incoming и outgoing traffic:


Ключ полностью: query_asa_lan2lan.pl[«<$SNMP_COMMUNITY>«, ««, «ASA», «get», «RX», «<#SNMPVALUE>«]
Ссылка в описании OID: tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.4.1.9.9.171.1.2.3.1.35#oidContent


Ключ полностью: query_asa_lan2lan.pl[«<$SNMP_COMMUNITY>«, ««, «ASA», «get», «TX», «<#SNMPVALUE>«]
Ссылка в описании OID: tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.4.1.9.9.171.1.2.3.1.35#oidContent

Применяем шаблон к нужным хостам, ждём автообнаружения и созерцаем наши туннельчики.

Осталось сделать графики для туннелей. К сожалению, LLD не позволяет автоматически делать консолидированные графики из нескольких прототипов данных, придётся добавить обнаруженные элементы данных вручную:

Ура! Можно хвастаться живыми картинками боссу.

Источник

Разблокируем порты коммутатора Cisco с помощью Zabbix, Ansible и Napalm

День добрый. Это вторая часть цикла из двух статей. В первой части мы ловили Zabbix-ом трапы PortSecurity от коммутаторов, а здесь мы, можно сказать, решаем обратную задачу — снимаем блокировку порта коммутатора щелчком мыши в фронтенде Zabbix-а.

Так получилось, что эта задача решалась два раза, двумя разными инструментами и с разницей в несколько месяцев. Сначала использовался Ansible, который вполне успешно справлялся. Но в один прекрасный момент он сломался (опять) и та же самая задача была решена простым Python-ом с использованием широко известной в узких кругах сетевой библиотекой Napalm.

Начнем с того зачем это надо.

Часто блокировка порта коммутатора — это не чье-то злонамеренное действие, а вполне ожидаемое событие. Наиболее часто порты блокируются при переезде компьютеров и/или IP телефонов из одного помещения в другое. Но это как правило контролируемый процесс, который обеспечивается техподдержкой. И хорошо бы дать инструмент техподдержке по разблокировке портов, которые ими же и были заблокированы.

Читайте также:  Как подключить интернет на телефон билайн дома

Воспользуемся встроенной в Zabbix функциональностью по запуску внешних скриптов. А именно — запуск скриптов по факту подтверждения проблемы (Acknowledgement). Таким образом, если сотрудник техподдержки заблокировал порт своими действиями, то он собственными силами может порт разблокировать просто подтвердив проблему. То есть достаточно просто нажать Ack и заполнить форму подтверждения (Форму можно не заполнять, но мы им об этом конечно не скажем).

Теперь про реализацию. Как я уже говорил реализации целых две штуки. Начнем с первой. с Ansible.

На самом деле все работает очень просто: Zabbix вызывает bash скрипт, скрипт формирует параметры вызова сценария ansible, ansible заходит на нужный коммутатор и выполняет команду

Для выполнения команд на коммутаторе использован ansible модуль ios_command
Сценарий ansiblе предельно лаконичен так что приведу его здесь целиком:

Тут есть один очень важный момент: при стандартной установке Zabbix пользователь zabbix создается системным и без домашней директории. Но чтобы ansible смог отработать сценарий от имени пользователя zabbix, у этого пользователя обязана быть в системе HOME_DIR. Без домашней директории не работает connection plugin paramico, который в ansible обеспечивает соединение по ssh с коммутаторами.

Еще один момент: в целях безопасности параметры login/password для доступа к коммутаторам зашифрованы с помощью ansible-vault.
Делается это командой ansible-vault create

Команда попросит придумать, ввести и подтвердить новый пароль и далее запустит текстовый редактор по умолчанию.

Там прописываем нужные значения, сохраняемся и выходим.

Теперь наш файл с паролями выглядит как то так:

Посмотреть содержимое файла можно командой ansible-vault view creds.yml

Едем дальше. В нашем сценарии есть такие параметры как ansible_host, interface и mac, но если первый параметр просто соответствует макросу , то последние два параметра Zabbix не различает. Они для него выглядят как единственный параметр . Ну т.е. в может содержаться либо catalyst100 либо 00:08:5D:51:DA catalyst100 в зависимости от типа трапа.

Для решения задачи передачи правильных параметров из Zabbix в сценарий я накропал простенький bash-скриптик. Вот такой:

Таким интересным образом в ansible можно передать единственный хост.

Вызов скрипта из Zabbix задается командой:
/etc/zabbix/alertscripts/zabbix-errdisable-recovery.sh

Там еще несколько мутных параметров. поэтому лучше картинкой. В моем Zabbix настроено таким образом:

sudo, который есть на картинке, использовать не нужно. Просто картинка старая, а я ленивый.

На этом с настройкой все.

Теперь показываю как это должно работать:

Итак прилетает к нам в Zabbix вот такое событие PortSecutity

Далее нажимаем Ok и ждем пока отработает ansible.

Когда скрипт отработает, при наведении мыши на поле с нашим событием в колонке Actions отбразится состояние Executed.

Затем, через время указанное в функции nodata() в условии тригера, тригер дожен позеленеть.

Детальная информация по событию в итоге будет выглядеть как то так

Кстати, на этой картинке удобно показано множество информации и в том числе то самое время nodata(150).

Это время должно быть чуть больше чем время errdisable autorecovery в настройках коммутаторов.

Часть 2: python + napalm

Итак задача была реализована и все прекрасно работало. Более того, даже эта статья уже была написана и готова к публикации. Но в один прекрасный момент я настроил мониторинг оракловых баз в Zabbix через ODBC и мой ansible сценарий выполняться перестал.
Дело в том, что ansible сильно зависим от переменных окружения. И так получилось, что когда я добавил в HOMEDIR пользователя zabbix файл .bashrc с переменными окружения ORACLE_HOME, процесс zabbix при запуске стал получать какие то другие переменные окружения и ansible-сценарий запущенный от его имени, а точнее network-module, потерял способность цепляться к коммутаторам по ssh.

При этом если запускать сценарий руками из под пользователя zabbix то скрипт выполняется, а если из фронтенда то падает с ошибкой от network-module.

В тот момент я собирался в отпуск, дел было много и я просто забил на скрипт этот. А вернувшись из отпуска увлекся чем то еще, потом заработался, опять в отпуск итп.
И вот долгими зимнимим вечерами маясь от безделья я про эту задачу вспомнил. Но ковыряться с ansible очень не хотелось. Особенно учитывая, что не так давно с одним из последних апдейтов Убунты ansible обновился на новую версию и поломался добрый десяток моих старых ansible-сценариев. В частности там sudo превратился в become. Ерунда конечно и в общем давно было известно, что sudo deprecated и когда то оно обязательно превратится в тыкву. Но все равно было неприятно.

Как то разочаровался я в этом инструменте. Починю я его сейчас, а через пару апдейтов опять все накроется?!

Да и изначально применения ansible для единственного хоста — это такое себе решение.
В то же время с питоном у меня сложились неплохие отношения. Да и просто с ним удобней. Куча инструментов в распоряжении. Да хоть тот же дебаггер.

Скрипт был написан за один присест. Он получился абсолютно линейным и поэтому предельно понятным. При этом сохранилась функциональность ansible-vault и плюс добавился вызов ZabbixAPI, который при успешном выполнении команд на коммутаторе гасит событие PortSecurity в фронтенд Zabbix. Тут надо отметить, что для закрытия событий в Zabbix необходимо в соответствующем триггере поставить галочку Allow manual close. Впрочем в шаблоне она уже проставлена.

В качестве драйвера взаимодействия с коммутаторами используется библиотека NAPALM.

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

Единственное о чем стоит рассказать: библиотека прекрасно встает на стандартный для Ubuntu 16.04 python версии 3.5. Но при этом внутри NAPALM используются конструкции fstrings от питона 3.6. И так все вроде работает, но в консоль валятся левые трейсы. Не очень аккуратно получается. Впрочем, при запуске скрипта Заббиксом консоль не видно, а на результат не влияет.

Заббикс настраивается почти точно так как вариант с ansible-сценарием, но вместо 2/3 параметров тут уже передается 4/5 параметров. Добавились параметры и для очистки событий в Zabbix.

Соответственно изменилась и строка вызова скрипта из Zabbix. Теперь она выглядит следующим образом:

Похоже на этом все. Спасибо за внимание.

Все вышеперечисленное безобразие лежит на github.

И первое решение на ansible вполне рабочее в стандартном ENVIRONMENT. Поэтому убирать я его конечно не буду. Ни сам сценарий ни информацию про него. Тем более там же про использование vault написано.

Источник

Мониторинг коммутаторов Cisco, D-Link, 3Com, Zyxel в системе Zabbix

Мониторинг — это один из столпов обеспечения высокой доступности ИТ-систем.
Как правило, системные администраторы при установке системы мониторинга в первую очередь настраивают ее на проверку параметров серверов и обнаружение недоступности сервисов, запущенных на этих серверах. Безусловно это приоритетная задача, но не стоит забывать и о другом оборудовании: ИБП, системах кондиционирования, сетевом оборудовании.

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

Включаем мониторинг

Думаю, я не ошибусь, если скажу, что большинству системных администраторов приходится работать с унаследованным «зоопарком» оборудования различных моделей и вендоров. К счастью, большинство моделей поддерживает открытый протокол SNMP. Именно по нему мы и будем получать информацию о состоянии сетевых интерфейсов.

Для облегчения задачи необходимо использовать шаблоны (templates). Шаблон содержит в себе все необходимые item’ы, триггеры и графики — остается только завести хост и подключить к нему шаблон.
Для Zabbix уже есть много готовых шаблонов, которые можно или нагуглить или посмотреть в мануале.
Если вы не нашли нужный шаблон, не расстраивайтесь: как правило, производители используют стандартные OID’ы из RFC1213 и RFC2233:

sysName.0 имя узла
.1.3.6.1.2.1.1.3.0 uptime
.1.3.6.1.2.1.2.2.1.8.X статус порта: 1(up) / 2(down) X — номер порта;
у Cisco номер порта пятизначный:
100XX для 100 Мбитных портов,
101XX для 1 Гбит/c
.1.3.6.1.2.1.2.2.1.16.X отправлено байт
.1.3.6.1.2.1.2.2.1.10.X принято байт
.1.3.6.1.2.1.31.1.1.1.5.X отправлено broadcast пакетов
.1.3.6.1.2.1.31.1.1.1.3.X принято broadcast пакетов
.1.3.6.1.2.1.31.1.1.1.4.X отправлено multicast пакетов
.1.3.6.1.2.1.31.1.1.1.2.X принято multicast пакетов
.1.3.6.1.2.1.2.2.1.17.X отправлено unicast пакетов
.1.3.6.1.2.1.2.2.1.11.X принято unicast пакетов
.1.3.6.1.2.1.2.2.1.20.X ошибок при отправке
.1.3.6.1.2.1.2.2.1.14.X ошибок при получении

Помимо этого можно считать имя интерфейса, MTU, скорость и другие параметры. Полный список смотрите на сайте Cisco.

Cisco Catalyst, как правило, поддерживают дополнительно:
.1.3.6.1.4.1.9.9.109.1.1.1.1.5.1 — процент загрузки CPU
.1.3.6.1.4.1.9.9.48.1.1.1.5.1 — занятая память (в байтах)
.1.3.6.1.4.1.9.5.1.2.13.0 — статус температуры (1 — нормальная, 2 — повышенная, 3 — критическая)

Генератор шаблонов

В результате вы получите симпатичные графики:

Отладка

Любители GUI для чтения SNMP-данных с устройства могут воспользоваться программами типа MIB Browser.

Карта сети

Карту придется кропотливо составлять вручную. Тут надо знать пару трюков. Чтобы над соединительными линиями между оборудованием показывать скорость, добавьте в подпись вызов соответствующего item в фигурных скобках. Например:
↑ <02-CS-42-3750:ifOutOctets.10112.last(0)>
<02-CS-42-3750:ifInOctets.10112.last(0)>↓

Запись 02-CS-42-3750:ifOutOctets.10112.last(0) означает получить у хоста 02-CS-42-3750 последнее по времени значение параметра ifOutOctets (отправлено байт). ↑ и ↓ это просто коды стрелочек ↑ и ↓ для красоты.

Также в свойствах Link вы можете настроить отображении линии красным в случае падения порта в down.

Мониторинг состояния портов

К сожалению, в Zabbix нет удобного инструмента для просмотра состояния отдельных портов устройств, поэтому его пришлось написать. Информация импортируется из Zabbix и выводится администратору в удобном виде:

Серый цвет порта обозначает, то что он находится в down. Цвет от зеленого до красного меняется в зависимости от загрузки порта. Гигабитные порты выделены рамочкой.

Минус скрипта в том, что он писался «для себя», поэтому установка достаточно корявая (-:. Скачайте исходники и прочитайте readme. UPD 13.03.13 (Версия для Zabbix 2.0)

Производительность

Нельзя не упомянуть о возможной проблеме с производительностью zabbix-сервера. Предположим, что вы раз в минуту получаете информацию об 11 параметрах каждого порта 50-ти 24-портовых свитчей. На базу данных zabbix-сервера ляжет нагрузка в среднем 220 записей в секунду. Для слабой машины она может оказаться непосильной. Поэтому рекомендуется ограничивать количество item’ов или увеличивать интервал проверки. Мы считаем достаточным запрашивать статус порта, трафик, количество ошибок и широковещательных пакетов раз в 60 секунд.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *