Motor de conexión concurrente a más de 10.000 dispositivos de red
Una herramienta que abre miles de sesiones SSH en paralelo, extrae información de cada equipo y aplica configuración de forma reproducible.
- Python
- SSH
- Concurrencia
- Parseo de texto
- Plantillas de configuración
El problema
Consultar el estado de un parque de red grande significaba entrar equipo por equipo. Cualquier pregunta sencilla — qué versión de firmware corre cada router, qué interfaces están caídas, qué equipos siguen con una configuración vieja — se convertía en días de trabajo manual de varias personas. Y cuando la respuesta llegaba, ya estaba desactualizada.
Qué construí
Construí un motor en Python que abre sesiones SSH concurrentes contra todo el parque en una sola ejecución. El núcleo es un pool de conexiones con un límite de concurrencia configurable: sin ese techo, lanzar diez mil conexiones simultáneas tumba tanto la máquina que ejecuta como los equipos que reciben, así que el paralelismo se ajusta a lo que la red aguanta en vez de a lo que la máquina permite.
La parte que más trabajo dio no fue conectarse, sino fallar bien. En un parque de ese tamaño siempre hay equipos apagados, con credenciales rotadas, detrás de un enlace saturado o que simplemente tardan en responder. Cada conexión tiene su propio timeout y su política de reintentos, y un fallo individual nunca aborta la ejecución completa: el resultado final distingue entre lo que se ejecutó bien, lo que falló y por qué motivo falló cada caso.
Sobre esa capa de transporte monté la extracción de información. La salida de un comando en un equipo de red es texto pensado para que lo lea una persona, no un programa, así que hay una etapa de parseo que la convierte en estructuras de datos consistentes, independientemente del fabricante o de la versión del sistema operativo del equipo.
La misma base sirve para el camino inverso: aplicar configuración. Los scripts de configuración masiva reutilizan el motor para empujar cambios sobre parques completos con plantillas, de forma que el mismo cambio se aplica igual en todas partes y queda registro de dónde se aplicó y dónde no.
Resultado
- Consultas que tomaban días de trabajo manual pasaron a resolverse en una sola ejecución desatendida.
- Un mismo cambio de configuración se aplica de forma idéntica y reproducible sobre todo el parque.
- Cada ejecución deja un informe de éxitos y fallos con la causa, en vez de un «no sé qué pasó con esos equipos».
- Se convirtió en la capa base sobre la que se construyeron el inventario y el mapeo de topología.