Child pages
  • Discovery Managed Objects
Skip to end of metadata
Go to start of metadata

Задача: Поиск объектов и добавление их в NOC.

Для начала, определимся с источниками информации о возможно существующих MO. В NOC, готовыми на сегодняшний момент источниками являются как минимум 2 модуля:

  • FM (SNMP traps / SYSLOG messages)
  • IPAM (discovery IP job)

Первый источник подразумевает, что мы уже установили новое оборудование и настроили его на посылку snmp trap-ов в сторону NOC(обычное дело к примеру в нашей компании -  в свитч заливается типовая конфигурация, меняется только fqdn/managment_ip/gw/vlans). В этом случае, в модуле FM мы получаем Event-ы вида:

Unknown Event Source: 172.19.157.251 [Active]
SAE (0.0.0.0, NOC.SAE, NOC NOC, 0.8dev9339)
NOC | Unknown Event Source

Unknown Event Source: 172.19.157.251
Event has been received from unknown source 172.19.157.251 by collector  (Activator pool default)

Таким образом, сделав выборку по коллекции ивентов мы получим список IP адресов кандидатов.

Второй источник подразумевает, что уже добавленное в NOC оборудование поддерживает работу discovery_ip job-a, и в IPAM определен формальный признак сетей, используемых для управления MO. То есть в арп-таблице роутеров, пристутствующих в NOC есть записи, они снимаются discovery_ip job'ом и записываются в БД, а в IPAM для management-сетей, например, выделен или отдельный VRF или эти сети помечены определенным тегом, или адреса принадлежат определенному Address Range.

Обобщеный процесс поиска объектов МО:

После проверки адреса из списка кандидатов check_alive пробуем достучатся до потенциального MO используя snmp default access profile и получить с него информацию о вендоре и платформе оборудования. Имея эти данные мы уже знаем с каким профилем можно работать с железкой (к примеру получив SNMPv2-MIB::sysDescr.0 = STRING: Edge-Core FE L2 Switch ES3528M присвоим профиль Edgecore.ES). На этом этапе можно детектить параметры доступа не только по результатам snmp-запроса, но и например, посмотрев, какие соседи по ip(принадлежащие одному префиксу и формальному признаку IPAM) есть у найденного объекта - уже заведенные в NOC и попробовать использовать их (сделать отключаемый способ).

Далее, в соответствии с Rule назначаем кандидату прототип МО и пробуем достать все нужные данные с помощью штатных процедур discovery job. Получив хост-нейм, адрес, конфигурацию, VRF кандидата мы заполняем необходимые поля в прототипе объекта и кладем в список для подтверждения администратором.

Для реализации задачи необходимо введение дополнительной структуры - шаблона managed object prototype, который должен включать в себя:

  • name_template (шаблон формирования имени из исходных данных - подробнее ниже)
  • access_profile (SA_profile, scheme, auth_profile, snmp_ro/rw_community)
  • managed_object_profile
  • location_template (admin_domain, activator, VRF, VC_Domain)
  • ...

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

  • enable candidate ip sources (FM-snmp/syslog traps | IPAM)
  • default access profile (snmp ro community)
  • IPAM context (определение формального признака сетей управления MO - IP Address Range | tag | ip prefix | VRF | e.t.c)
  • Rule сопоставления managed object prototype <=> discovered parameters( IP | platform | vendor | hostname | e.t.c)

Демонa(или job worker-a), который будет заниматься периодической генерацией списка адресов кандидатов, их препроцессингом, обработкой pending MO и складыванием кандидатов в БД для approve.

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

  • No labels

4 Comments

  1.  

    _4ePTeHok, мне тут еще подсказали что кроме snmp дискавери нужен метод zabbix agent дискавери,тоесть на сервере где есть заббикс надо пускать активтор,и здавать вопросы с него

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

     

  2. а еще не все сети можно дискаверить. быть может кандидатов надо вносить в виртуальный Vrf. И группировать при помощи префиксов с спец атрибутами. типа камунити, активтора с которого эту сеть дискаверить

    1. Unknown User (alexm)

      это все подходит под понятие "формальный признак" для диапазона адресов.

  3. Unknown User (zi)

    определять по  SNMPv2-MIB::sysDescr.0 профиль - гиблое дело, у вендоров где больше двух разных ОС используется заколебешься угадывать, типичный пример Dlink, с остальными легче, но тоже не все шоколадно. Лучше дать возможность выбрать несколько профилей которое соответствует используемому оборудованию и попробовать перебором угадать подходящий, но нужны критерии, что профиль сработал, например попробовать выполнить get_version, если результат получен, то ок