Problema

Los equipos de infraestructura suelen necesitar una visión periódica del estado de sus dispositivos de red: interfaces operativas, protocolos de enrutamiento, sincronización de tiempo, etc. Las herramientas tradicionales (ping, nmap, scripts ad‑hoc) devuelven texto libre, lo que obliga a parsear salida con expresiones regulares frágiles. Además, la falta de un formato estructurado complica la integración con pipelines CI/CD, sistemas de monitorización y procesos de gestión de cambios. Cuando varios dispositivos de diferentes vendors están involucrados, la heterogeneidad de comandos y la ausencia de un mecanismo de “snapshot → diff” hacen que la detección de desviaciones sea manual y propensa a errores.

Causa

  1. Salida no estructurada – La mayoría de los scanners imprimen tablas ASCII; los logs se mezclan con los datos, lo que dificulta su consumo por máquinas.
  2. Falta de estándar de exit‑code – Un script que devuelve siempre 0 no permite a los orquestadores detectar fallos.
  3. Configuración dispersa – Credenciales, parámetros de tiempo de espera y filtros suelen estar codificados en scripts individuales, lo que genera inconsistencias entre entornos.
  4. Vendor lock‑in – Herramientas específicas de un fabricante no cubren otros equipos, obligando a mantener varios binarios.
  5. Ausencia de snapshots – Sin una referencia histórica, cualquier cambio pasa desapercibido hasta que se produce una interrupción visible.

En estos setups suele pasar que el equipo de operaciones crea scripts rápidos para “chequear una interfaz”, pero al escalar el número de dispositivos el mantenimiento se vuelve costoso y los resultados pierden confiabilidad.

Solución

Adoptar una herramienta de auditoría de red basada en CLI que genere salida estructurada (JSON/CSV) y siga buenas prácticas de línea de comandos permite resolver todos los puntos anteriores de forma coherente. Los componentes clave de la solución son:

  1. Salida estructurada y separación de flujos – Los datos de auditoría se envían a stdout en JSON/CSV, mientras que los logs y mensajes de depuración van a stderr. Esto permite redirigir fácilmente la información a archivos, bases de datos o sistemas de monitorización sin mezclar logs.
  2. Códigos de salida semánticos – Un código 0 indica éxito total, 1 falla de conectividad, 2 hallazgos críticos, etc. Los pipelines pueden actuar en base a estos valores (if [ $? -ne 0 ]; then alert; fi).
  3. Configuración centralizada – Un archivo YAML define hosts, credenciales, variables de tiempo de espera y filtros. Las variables de entorno con prefijo NETAUDIT_ pueden sobrescribir valores, lo que facilita su uso en contenedores o agentes de CI.
  4. Soporte multi‑vendor a través de módulos – Un motor de abstracción de SSH carga un plugin por tipo de dispositivo (Cisco IOS, Juniper Junos, Arista EOS). Cada plugin implementa solo lecturas (show commands) en modo read‑only, lo que elimina riesgos de cambios accidentales.
  5. Snapshots y diff – Cada ejecución genera un snapshot con timestamp. Un comando diff compara dos snapshots y muestra solo los cambios (nuevas interfaces, variaciones de BGP, errores de OSPF). Este flujo se integra con sistemas de gestión de cambios para crear tickets automáticos.
  6. Health checks integrados – Un sub‑comando doctor realiza pruebas de conectividad, verifica errores de interfaz, estado de protocolos y sincronización NTP. Los resultados pueden exportarse a JSON y consumirse por Prometheus, Grafana o cualquier agente de alertas.

Con estos principios, la integración en CI/CD y monitorización se vuelve trivial:

  • En Jenkins, GitLab CI o GitHub Actions, basta ejecutar el comando y fallar la etapa si el código de salida no es cero.
  • En Prometheus, el JSON se expone mediante un exporter o se escribe en un archivo que el node‑exporter lee.
  • En sistemas de tickets, el diff se adjunta al crear una incidencia automática.

Cuándo aplicar esta solución

Señales de que la solución es adecuada

  • Necesitas auditorías programadas (diarias, semanales) de varios dispositivos de distintos vendors.
  • Los resultados deben consumirse por herramientas automáticas (CI, alertas, dashboards).
  • Requieres un historial de estado para comparar cambios y detectar desviaciones antes de que causen interrupciones.
  • Quieres evitar scripts ad‑hoc que mezclan lógica de negocio con parsing de salida.

Casos donde no aplica

  • Auditar un único dispositivo de forma puntual y sin requerir integración con pipelines. Un simple show run puede ser suficiente.
  • Entornos donde la política de seguridad prohíbe cualquier acceso SSH a los equipos de producción; la solución depende de conexiones read‑only.

Código

# Ejecutar una auditoría completa a un router Cisco y guardar JSON
netaudit doctor 10.0.0.1 --device --device-type cisco_ios --json > daily_health.json

# Generar un reporte HTML a partir del JSON
netaudit report daily_health.json --format html --output /var/www/audit_report.html

# Comparar auditoría de hoy con la de hace una semana
netaudit diff --base /snapshots/2024-08-08.json --new /snapshots/2024-08-15.json > diff_report.txt

Verificación

  1. Salida JSON válida – Ejecuta jq . daily_health.json. Si jq devuelve un objeto sin errores, la salida está bien estructurada.
  2. Código de salida – Después de netaudit doctor … verifica $?. Un valor distinto de 0 indica problemas de conectividad o hallazgos críticos.
  3. Diff significativo – Abre diff_report.txt. Debe listar solo los campos que cambiaron (p.ej., “interface Gig0/1 status: up → down”). Si el archivo está vacío, los snapshots son idénticos.
  4. Integración CI – En tu pipeline, agrega una etapa que falle si netaudit doctor … devuelve código >0. Ejecuta la pipeline y confirma que la fase se detiene cuando hay errores de BGP o interfaces caídas.

Notas adicionales

  • Credenciales seguras: Usa un vault (HashiCorp, Azure Key Vault) para inyectar variables NETAUDIT_USERNAME y NETAUDIT_PASSWORD en tiempo de ejecución; evita guardarlas en el YAML.
  • Tiempo de espera: En entornos con alta latencia, ajusta --timeout o la variable NETAUDIT_TIMEOUT para prevenir falsos negativos por time‑outs.
  • Módulos de vendor: Si trabajas con un vendor no soportado, crear un plugin es tan simple como escribir una función que devuelva un diccionario con los comandos show deseados. La arquitectura basada en Python permite cargar el módulo dinámicamente.
  • Escalado: Para auditorías de cientos de dispositivos, lanza netaudit en paralelo usando GNU parallel o un job‑queue (Celery). Cada proceso escribe su snapshot en un directorio común, y luego un script de agregación genera el diff global.
  • Alertas proactivas: Configura un cron que ejecute netaudit doctor … y envíe el JSON a un endpoint de webhook de Slack o Teams. Un filtro que detecte cambios críticos (jq 'select(.bgp.neighbor_state=="idle")') puede disparar una notificación inmediata.

Con una CLI que siga estas prácticas, la auditoría de red pasa de ser una tarea manual y frágil a un componente fiable de la cadena de entrega y de la observabilidad de la infraestructura.