Автообнаружение со сложными условиями

[Alexey Kovalev]

Добрый день!

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

Конкретно интересует добавление хостов с поддержкой протоколов ssh либо telnet, имеющих к тому же определенные snmp community.

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

[zmdpc]

В каждой проверке можно указать свою комунити. Искал по трем условиям. При совпадении можно указать в действтиях, что нужно делать с найденым оборудованием. Действий для обноружения может быть несколько. Сами для себя логику того что хотите реализовать уже поняли? Озвучте

[Alexey Kovalev]

Задача автообнаружения хостов - добавить в мониторинг все коммутаторы корпоративной сети, у которых задан одинаковый snmp community, например, "snmp-read". Коммутаторов в сети около тысячи. Кроме этих коммутаторов community "snmp-read" другие устройства в сети не используют. Проблема в том, что устройства откликаются на snmp запросы, отправленные не только на собственный ip адрес, но и на адрес подсети и адрес броадкаста, принадлежащие подсети, в которой находится опрашиваемое устройство. С icmp, кстати, проблема аналогичная.
Т.е. если в автообнаружении использовать только snmp проверки, то происходит задваивание/затраивание найденных коммутаторов. К примеру, если у коммутатора из подсети 192.168.1.0/24 адрес 192.168.1.254, то добавляется три хоста: 192.168.1.254, 192.168.1.0, 192.168.1.255, которые представляют из себя один и тот же коммутатор. Можете у себя это проверить, запустив тот же snmpwalk на адрес своей сети или на её броадкаст при наличии в этой сети snmp устройства.

С проверкой по telnet и ssh такой проблемы нет. Зная, что на всех наших коммутаторах поднят либо telnet, либо ssh, я решил помимо проверок snmp использовать проверки TCP для диапазона портов 22-23. Но, как выяснилось опытным путем, в одном сложном условии перечисление нескольких типов сервисов не работает.

Т.е. если я в одном действии в условии указываю (в точности названий могу ошибиться, но смысл должен быть понятен)
<тип сервиса> = snmp and
<возвращаемое значение> >= 1 and // Я в проверке обнаружения проверяю uptime с использованием community "snmp-read".
<тип сервиса> = TCP and
<порт сервиса> = 22-23,

то проверку такое условие никогда не проходит. Соответственно хосты, удовлетворяющие требованиям по snmp и ssh/telnet не добавляются.
Из этого я делаю вывод, что в одном условии:
- использовать несколько раз <тип сервиса> нельзя;
- использовать одновременно <возвращаемое значение> и <порт сервиса> тоже нельзя.

По-другому, используя несколько действий с условиями по проверке отдельно для snmp и telnet/ssh, я не могу добиться того, чтобы добавлялись только те хосты, которые мне нужны.

[zmdpc]

Когда задается параметры поиска задаются и диапазон адресов. Почему нельзя использовать этот механизм?
Snmp запрос может запрашивать мак адрес. Почему такой критерий нельзя использовать?

[Zentarim]

...
Т.е. если в автообнаружении использовать только snmp проверки, то происходит задваивание/затраивание найденных коммутаторов. К примеру, если у коммутатора из подсети 192.168.1.0/24 адрес 192.168.1.254, то добавляется три хоста: 192.168.1.254, 192.168.1.0, 192.168.1.255, которые представляют из себя один и тот же коммутатор.
...

А вот это странно. Я бы попытался обратился на багтрекер, так как мне кажется, это косяк zabbix. Почему мне так кажется:

Вы отправляете запрос на 192.168.0.255 (Броадкаст к 192.168.0.0\24) и zabbix запоминает этот адрес, чтобы впоследствии добавить его, если придет ответ. Поидее он должен ждать ответ с этого же адреса. А ответ при этом приходит от, к примеру, 192.168.0.100.

Налицо некая нестыковка в логике работы, как мне кажется.

[Alexey Kovalev]

А вот это странно. Я бы попытался обратился на багтрекер, так как мне кажется, это косяк zabbix. Почему мне так кажется:

Вы отправляете запрос на 192.168.0.255 (Броадкаст к 192.168.0.0\24) и zabbix запоминает этот адрес, чтобы впоследствии добавить его, если придет ответ. Поидее он должен ждать ответ с этого же адреса. А ответ при этом приходит от, к примеру, 192.168.0.100.

Налицо некая нестыковка в логике работы, как мне кажется.

Согласен с Вашими рассуждениями. Но я не уверен, что разработчик признает это багом и оперативно проблему решит. Он может сослаться на особенности реализации протокола snmp и используемые snmp библиотеки. Хотелось бы решить свою задачу имеющимися средствами.

[Alexey Kovalev]

Когда задается параметры поиска задаются и диапазон адресов. Почему нельзя использовать этот механизм?
Snmp запрос может запрашивать мак адрес. Почему такой критерий нельзя использовать?

Если Вы имеете ввиду возможность исключения из сканируемых диапазонов адресов подсетей и адресов броадкастов (например, для сети 192.168.1.0/24 можно прописать 192.168.1.1-254), то это в моей ситуации не самый подходящий вариант, т.к. сканируемых диапазонов в корпоративной сети более 600.

Не совсем понял идею о запросе MAC-адреса по snmp. Как это поможет в решении моей задачи?

[zmdpc]

По поводу запроса мака - нужно знать модель.
По поводу диапазонов - правильно задавать таким образом 192.168.1-10.1-254
Какая версия zabbix кстати?

[Alexey Kovalev]

Подсети в филиалах имеют разную размерность: /23 - /27.
Поэтому не во всех случаях возможно таким способом исключить адреса броадкастов и сетей.
Я не понял, что в данном контексте даст информация по MAC-у.

Версия Zabbix 2.4.4.

[zmdpc]

Подсети в филиалах имеют разную размерность: /23 - /27.
Поэтому не во всех случаях возможно таким способом исключить адреса броадкастов и сетей.
Я не понял, что в данном контексте даст информация по mac-у.

Версия zabbix 2.4.4.

1. все чудесатее и чудесатее, что значит не можете исключить адреса броадкастов и сетей? возьмите ip калькулятор и исключите.
2. дает возможность помочь - зная модель можно подсказать правильный oid
3. желательно обновить на 2.4.5 - там улучшено обнаружение.

[Alexey Kovalev]

Я и без калькулятора могу посчитать любую подсеть.
Задача по исключению адресов броадкастов и сетей из нескольких диапазонов адресов класса /16, которые подроблены на более чем 600 сегментов разной размерности, сопоставима с ручным добавлением списка коммутаторов в Zabbix. Процесс должен быть полностью автоматизирован.

zmdpc, сначала Вы несколько раз про MAС-адрес упоминали. Теперь дошли до модели и OID'а. Дальше то что? Мне не нужен OID ради OID'а.

[zmdpc]

Нарисую другую связку - модель - оид (уникальный для разных производителей и моделей) - запрос снмп по оиду - мак - уникальный признак фильтрации. Так понятнее ?

Я искал 2500 узлов перебирая сети, поскольку ранее 2.4.5 не было возможности задать 192.168.1-10.1-254, а только 192.168.1.1-254 и ничего добавил обнаружил.

Условия выдаете вы прочитайте свой первый пост и последующие. Задача видоизменяется по мере поступления информации. Что значит "Процесс должен быть полностью автоматизирован." ? На постоянной основе или единоразово?

ПыСы. затраты времени на добавление узлов можно посчитать исходя около 3сек на узел и исправление правила обнаружения около 5 сек на сеть. у меня в сети обычно около 50 узлов. времени ушло особо не напрягаясь под чаек около 8 часов. основная проблема это в дальнейшем переименование узлов к какому то виду.

[Alexey Kovalev]

Нарисую другую связку - модель - оид (уникальный для разных производителей и моделей) - запрос снмп по оиду - мак - уникальный признак фильтрации. Так понятнее ?

Я искал 2500 узлов перебирая сети, поскольку ранее 2.4.5 не было возможности задать 192.168.1-10.1-254, а только 192.168.1.1-254 и ничего добавил обнаружил.

Условия выдаете вы прочитайте свой первый пост и последующие. Задача видоизменяется по мере поступления информации. Что значит "Процесс должен быть полностью автоматизирован." ? На постоянной основе или единоразово?

ПыСы. затраты времени на добавление узлов можно посчитать исходя около 3сек на узел и исправление правила обнаружения около 5 сек на сеть. у меня в сети обычно около 50 узлов. времени ушло особо не напрягаясь под чаек около 8 часов. основная проблема это в дальнейшем переименование узлов к какому то виду.

Задача в моем первом и последующих постах не меняется. Основная цель - автоматическое добавление хостов с одинаковым SNMP community. Поскольку в Zabbix автодобавление по такому принципу работает не совсем так, как хочется, я выбрал свой способ дополнительной фильтрации добавляемых хостов, но столкнулся с определенными сложностями, по поводу которых написал свой пост на форуме. Вы предложили другой вариант решения.

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

По Вашему варианту решения. Идею я понял. Определяемся с OID'ом, возвращающим уникальное значение для каждого коммутатора. Подойдет этот: IF-MIB::ifPhysAddress.1. Критерий уникальности устройства выбираем по возвращаемому SNMP значению. Запускаем сканирование. В терминах тех ip адресов, которые я указывал ранее, первым просканируется 192.168.1.0, а уже после - реальный адрес коммутатора 192.168.1.254. Какой из этих адресов добавится в Zabbix? Скорее всего, 192.168.1.0. Я, конечно, проверю это. zmdpc, я правильно Вашу идею понял и описал?

[zmdpc]

Не совсем.

IF-MIB::ifPhysAddress Вы узнаете маки интерфейсов. Почему спрашивал модель - потому, что бы узнать мак свича нужно это смотреть в MIB файле производителя устройтва. Покажу на аналогии, у меня есть свичи Делл, чтобы узнать мак конкретного устройства использую 1.3.6.1.4.1.674.10895.5000.2.89.2.12.0 (ОИД отличается у разных моделей).

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

https://www.zabbix.com/documentation/2.2/ru/manual/discovery/network_discovery/rule

Собственно именно действие добавляет или удаляет узлы. В качестве условия добавления можно применять "обнаружен" (Состояние обнаружения = Обнаружен)

Тоесть логика примерно такая -
НАСТРОЙКА ПРАВИЛ ОБНАРУЖЕНИЯ - Критерий уникальности устройства - ОИД мака устройства.
НАСТРОЙКА ДЕЙСТВИЙ - собственно указываете то, что планируете сделать с обнаруженными устройствами с уникальными маками.

[Alexey Kovalev]

zmdpc, IF-MIB::ifPhysAddress.1 возвратит именно уникальное значение для каждого найденного коммутатора, т.к. физические адреса портов коммутатора уникальны не только в пределах коммутатора. Более того, я проверял, что этот OID (MAC-адрес первого интерфейса) присутствует на коммутаторах всех вендоров в нашей корпоративной сети (Cisco, Nortel, HP, H3C).
Т.е. идея Ваша реализуема в плане добавления коммутаторов без дублирования. Но проблема с добавлением коммутаторов с некорректными ip адресами не решается. См. мой предыдущий пост.