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

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

Первый источник подразумевает, что мы уже установили новое оборудование и настроили его на посылку 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, который должен включать в себя:

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

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

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