Child pages
  • Discovery Managed Objects

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

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

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

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

Code Block
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.

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

Image Added

После проверки адреса из списка кандидатов 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.

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