SNMP (Simple Network Management Protocol) es un protocolo ampliamente adoptado desde 1988 que permite la monitorización y gestión de dispositivos de red. Su soporte extendido entre la mayoría de fabricantes lo convierte en el estándar de facto para la observabilidad de hardware de red, permitiendo la consulta y recopilación de información en tiempo real.
¿Por qué usar SNMP para descubrimiento de red?
Desde Datadope, utilizamos SNMP como pilar fundamental para realizar discoveries automáticos sobre dispositivos e interfaces de red. Esto permite:
- Identificar dispositivos conectados que no son detectables mediante otros protocolos.
- Poblar automáticamente la CMDB (Configuration Management Database).
- Obtener datos estructurados y relaciones entre equipos y servicios.
¿Cómo funciona el descubrimiento SNMP en Datadope?
- Escaneos periódicos sobre las redes definidas en CMDB.
- Identificación de IPs con puerto UDP y servicio SNMP activo.
- Ejecución del discovery para extraer información detallada.
- Envío de datos a CMDB Bridge, encargado de procesar, categorizar y establecer relaciones.
- Almacenamiento final en CMDB API Gateway, integrando los datos en la base de configuración.
Módulo de Ansible para SNMP
Se ha desarrollado un módulo específico de Ansible para SNMP, ya disponible públicamente en la Ansible Collection de Datadope, que permite:
- Realizar consultas SNMP automatizadas mediante plantillas.
- Procesar y enriquecer los datos obtenidos.
- Categorizar dispositivos por tipo, marca y modelo.
Componentes del módulo:
- Module (cliente): Ejecuta SNMP en el dispositivo remoto, consultando OIDs definidos.
- Action (servidor): Procesa los datos antes y después de la ejecución SNMP.
- Role: Gestiona plantillas y bases de datos para clasificar los dispositivos
Identificación mediante SysObjectID
Cada fabricante asigna un SysObjectID único para cada tipo de dispositivo SNMP. Este identificador nos permite:
- Detectar la marca, modelo y tipo (router, switch, impresora, etc.).
- Utilizar plantillas específicas para extraer información detallada.
- Enriquecer la CMDB con datos estructurados.
El módulo utiliza un archivo YAML (sysobject_ids.yaml) que actúa como base de datos para mapear estos identificadores a plantillas personalizadas.
A primer nivel identificamos el tipo de plantilla que vamos a utilizar (de la que hablaremos más adelante, por debajo de cada plantilla tenemos un listado de las distintas marcas de dispositivos disponibles, por cada marca a su vez tenemos el listado de los tipos de dispositivos (Networking, Printer, Storage, etc.) para finalmente agrupar los distintos SysObjectIDs disponibles mediante un diccionario cuyo valor es el modelo del dispositivo asignado a su identificativo.
El módulo en su primera iteración recoge información del SysObjectID y la SysDescription, por defecto utiliza una plantilla genérica para obtener datos de sus interfaces, pero a partir de las dos OIDs mencionadas podemos categorizar los dispositivos en nuestro fichero “sysobject_ids.yaml” dentro del role de snmp_discovery y generar una plantilla especifica si fuera necesario.
Templates
Se ha diseñado un sistema de plantillas en formato YAML que nos permite consultar las distintas OIDs de una manera sencilla y aplicar post-procesados sobre los valores obtenidos. Soportamos consultas a objetos escalares (el resultado de la consulta solo puede ser uno) y consultas a objetos tabulares (define varias instancias de objetos relacionados que se agrupan en tablas MIB). Los objetos tabulares o tablas pueden estar relacionadas entre sí, esta relación generalmente se suele hacer a través del índice que nos permite agrupar los valores dentro de una misma tabla, este índice puede coincidir entre varias tablas o que el valor de una tabla sea el índice para relacionar con otra tabla. Esto nos permite agrupar valores para generar una salida customizada.
Los objetos escalares se definen por una key cuyo diccionario será su OID a consultar y un post-procesado si fuera necesario (no obligatorio). El nombre que definamos a la key, será el valor de la key en la salida.
*Definición en plantilla
*Salida Ansible Facts
Los objetos tabulares o tablas se definen por una key con un diccionario de claves: valor. En primer lugar especificamos que es de tipo lista (type: list), dependencias si es que son requeridas, omisión de información (omit: true) si es que esa tabla es dependiente de otra para nutrir su información y queremos omitir su salida, su OID (base) de la tabla a consultar y por último las “entries”.
Las entries (listado) pertenecen a cada campo que vamos a consultar dentro de la tabla a modo de columna en SQL, estas entradas se definen igual que los objetos escalares, pero podemos omitir su salida si el valor es referencial como un índice y solamente es necesario para generar dependencias. Como OID dentro de una entry definimos la terminación de su OID base de la tabla, aunque podemos definirla completa y se omitirá la OID base al generar la consulta (solamente para esa entrada). Como resultado obtenemos una key con un listado de diccionarios con los valores obtenidos.
*Definición en plantilla
*Salida Ansible Facts
Actualmente soportamos dos tipos de dependencias (dependencies) que son agrupaciones de datos en un mismo diccionario ya que hay una relación entre tablas a través de índices.
Dependencia de tipo “index”: Internamente las agrupaciones de valores dentro de una misma tabla está asociada a un índice en común, si definimos una tabla con dependencia a una anterior (previamente consultada) y cuyas agrupaciones de diccionarios tienen el mismo índice, haremos un merge de valores entre las dos tablas para aquella tabla que definimos la dependencia.
*Definición en plantilla
*Estructura interna separada en tablas
*Estructura interna merge en tabla_2
Dependencia de tipo “value”: Este tipo de dependencia se genera para aquellas tablas que internamente tienen un identificador distinto pero que dentro de cada elemento de la tabla podemos consultar un campo cuyo valor es el indice de la tabla anterior y que nos permite generar la dependencia (merge de tablas).
*Definición en plantilla
*Estructura interna separada en tablas
*Estructura interna merge en tabla_2
Por último, con todo lo detallado anteriormente y utilizando la plantilla de ejemplo, definidos objetos escalares y tabulares con distintas dependencias, obtenemos la siguiente salida de un dispositivo de red con sus IPs (ipAddrEntry) y nutrida con los datos de las tablas ifMIB e interfaces.
