2.3. Configuración de Traps SNMP en Equipos Industriales

UF1795 | Notificaciones de alarma en tiempo real (Push)

sequenceDiagram participant Manager as Servidor NMS (Zabbix) participant Agent as Switch SCALANCE (Agente) Note over Manager, Agent: Escenario 1: Polling (Síncrono) Manager->>Agent: SNMP GET (Cada 5 min) Agent-->>Manager: SNMP RESPONSE (Todo OK) Note over Agent: Un cable se corta accidentalmente Note over Manager, Agent: Escenario 2: TRAP (Asíncrono) Agent->>Manager: SNMP TRAP (Alerta: Puerto 3 LinkDown!) Note left of Manager: El NMS recibe el Trap en el
puerto UDP 162 instantáneamente Manager->>Manager: Dispara Alarma Visual y Email

1. El Límite del Polling

En las lecciones anteriores vimos que el Servidor NMS interroga a los equipos (Polling) enviando comandos `SNMP GET`. Imagina que configuras el servidor para que pregunte el estado de los puertos de un switch cada 5 minutos. Si un cable vital se corta en el minuto 1, el servidor no se enterará hasta el minuto 5. En el entorno OT, 4 minutos de ceguera pueden resultar en un desastre logístico. Para evitar esto, SNMP diseñó los TRAPS.

Un SNMP TRAP es un mensaje que el Agente (el switch o PLC) envía por iniciativa propia al Manager en el instante exacto en el que ocurre un evento anormal. Cambia el paradigma de "tirar" (Pull) a "empujar" (Push).



2. Tipos de Traps: Genéricos vs. Específicos

Existen dos grandes familias de notificaciones Trap:

  • Traps Genéricos (Estándar): Todos los dispositivos de red los soportan. Los más importantes son ColdStart (el equipo se ha encendido y reiniciado), WarmStart (reinicio por software), LinkDown (un cable se ha desconectado o roto) y LinkUp (el cable se ha vuelto a conectar).
  • Traps Específicos (Enterprises): Están definidos por el fabricante en su archivo MIB. Por ejemplo, un switch industrial puede enviar un Trap específico si "La alimentación redundante de 24V de la Fuente 2 se ha perdido" o si "La temperatura interna supera los 70ºC".


3. Configuración en el Agente (Equipo de Planta)

A diferencia del polling, donde el servidor busca al switch, para que los Traps funcionen el switch tiene que saber dónde está el servidor. En la interfaz web de cualquier switch gestionable (Cisco, Siemens, Hirschmann), un técnico de UF1795 debe configurar los siguientes parámetros en la sección "SNMP Trap":

  1. Trap Receiver IP: La dirección IP del Servidor NMS (Zabbix/PRTG).
  2. Trap Community String (o Credenciales v3): Una contraseña para que el servidor NMS acepte el Trap y no piense que es spam.
  3. Eventos a Notificar: Muchos switches te permiten marcar con un "Check" qué eventos quieres que disparen un Trap (ej. Fallos de puerto, Cambio de topología STP, Fallos de Login). Si marcas demasiados, puedes saturar el servidor NMS.


4. Recepción en el Manager (El Trap Receiver)

En el lado del servidor NMS, debe haber un servicio escuchando activamente en el puerto UDP 162 (el puerto 161 se usa para el polling normal). Cuando llega un Trap, el servidor recibe un OID puro (ej. 1.3.6.1.4.1.9.9.43.2.0.1). Si el ingeniero no ha importado previamente el archivo MIB del fabricante en el servidor NMS, este no sabrá interpretar el mensaje y lo mostrará como un "Trap Desconocido". Con la MIB cargada, el servidor traduce ese número al instante y muestra: "ALARMA: Fallo de alimentación en la Fuente 2 del Switch Core", pudiendo enviar un email o un SMS al técnico de guardia de forma automática.

Infografía explicando el funcionamiento de los Traps SNMP, con un switch enviando una alerta a un servidor NMS.
Figura 1: El mecanismo de alerta proactiva. En lugar de esperar a que el servidor NMS pregunte (Polling), el agente SNMP del switch detecta un evento crítico (un cable desconectado) y envía un mensaje TRAP de forma inmediata. Esto reduce el tiempo de detección de fallos de minutos a milisegundos.
Fuente: Elaboración propia / Licencia: CC BY-NC 4.0.

📝 Evaluación Técnica: Configuración de Traps

1. ¿Cuál es la principal ventaja de utilizar SNMP Traps en lugar de depender exclusivamente del "polling" (comandos GET) para la monitorización de una red industrial?

2. Para que un switch industrial pueda enviar Traps a tu servidor de monitorización (NMS), ¿qué información crítica debes configurar en la interfaz web del propio switch?

3. Tu servidor NMS recibe un Trap, pero lo muestra como "Trap Desconocido" con un OID numérico largo (ej. 1.3.6.1.4.1.4329.). ¿Qué te has olvidado de hacer en el servidor NMS?

🤖 Ejercicio Práctico 2: Receptor de Traps (Trap Sink)

Objetivo: Programar un "receptor" de alarmas SNMP para entender cómo los sistemas NMS escuchan y reaccionan a los eventos de la red.

Copia el siguiente *prompt* y pégalo en un modelo de IA (como ChatGPT, Gemini o Claude).

Actúa como un desarrollador de software para un Centro de Operaciones de Red (NOC). Escribe un script en Python utilizando la librería `pysnmp` que actúe como un "Trap Receiver" o "Trap Sink". El script debe: 1. Configurar un motor SNMP para escuchar en la dirección `0.0.0.0` y el puerto estándar para Traps (UDP 162). 2. Configurar la seguridad para aceptar Traps de SNMPv2c con la "community string" 'public'. 3. Definir una función de callback que se ejecute cada vez que llegue un Trap. 4. Dentro del callback, el script debe extraer e imprimir la dirección IP del dispositivo que envió el Trap y los "varBinds" (los OIDs y valores que contiene la alarma). 5. Iniciar el receptor y mostrar un mensaje indicando que está "Escuchando Traps SNMP en el puerto 162.". Comenta el código explicando que, en un sistema real, en lugar de imprimir en consola, esta función de callback dispararía una alarma en un dashboard, enviaría un email o crearía un ticket en un sistema de incidencias.