Topolograph construye un modelo de la red a partir de lo que informan sus protocolos de enrutamiento. Cada nueva fuente añade su propia capa independiente a ese modelo. Todo lo demás se calcula sobre él: rutas principales y de respaldo, enlaces sin respaldo, búsqueda de elementos de red (prefijos, direcciones MAC y más) y fallos de enlaces o nodos simulados antes de empezar el mantenimiento. El análisis funciona con una sola instantánea de LSDB; un colector añade el flujo de cambios y un agente de IA responde preguntas con los mismos datos.
¿Qué aporta una sola instantánea?
La salida de show ip ospf database router de un router se convierte en una instantánea estática de la red: 13 routers, 26 enlaces. Se trabaja con ella sin conexión, sin acceso a los routers: cálculo de rutas, búsqueda de elementos de red, planificación de mantenimiento. El diagrama muestra la ruta pe15 → pe30: coste 41, cuatro rutas de igual coste.
¿Se puede sacar de servicio un enlace o un dispositivo?
El enlace core10 ↔ core30 se desactiva en el modelo: se recalcula SPF, el tráfico pasa a core11 ↔ core31, el coste sube de 41 a 50 y siguen existiendo cuatro rutas. La red real no se toca.
¿Qué está cambiando ahora mismo en la red?
El colector de Topolograph (watcher) recibe las actualizaciones de los protocolos de enrutamiento y transmite eventos sobre cambios de topología. Se une a la red de una de tres maneras: una adyacencia IGP simple, una adyacencia IGP sobre GRE o BGP-LS; en la demo es una adyacencia GRE con rr1. Cuando el enlace pe15 ↔ core110 cae, ambos extremos propagan nuevos Router LSA, la actualización llega al colector y a Topolograph llega un evento con marca de tiempo. De las cuatro rutas pe15 → pe30 quedan dos.
¿Cómo era la red en el momento del incidente?
La línea de tiempo reproduce los eventos del colector: la métrica pe14 → core110, el enlace pe15 ↔ core110 que cae y vuelve, una red nueva en core31, una métrica TE. Después el cursor se mueve entre T+3 s y T+5 s: cuatro rutas antes del fallo, dos después. Se puede comparar la instantánea T0 con cualquier estado posterior.
¿Qué pasó en la red en los últimos 15 minutos?
El ingeniero hace la pregunta. El agente llama a las herramientas del servidor MCP de Topolograph para eventos y cálculo de fallos, y responde con una referencia a los datos. Agent 2.0 ya diagnostica incidentes con un runbook acordado de antemano: a petición de un ingeniero o automáticamente cuando un evento abre un ticket. El acceso de solo lectura, la autorización y los pasos explícitos del runbook hacen que el diagnóstico sea seguro y varias veces más rápido.
Cinco cambios en 15 minutos:
Los datos del protocolo no muestran por qué cayó el enlace. ¿Revisar los logs de pe15 y core110 en el momento del incidente? Agent 2.0
Zabbix, Prometheus y Cacti vigilan dispositivos e interfaces. Topolograph muestra cómo la red enruta el tráfico y funciona junto a ellos.
| Monitoreo clásico | Topolograph | |
|---|---|---|
| Estado de interfaces y dispositivos | ✓La tarea principal | ✕Fuera del alcance de Topolograph: los datos permanecen en el monitoreo existente |
| Estado de vecinos OSPF / BGP | ~Mediante SNMP o exporters, dispositivo por dispositivo | ✓Desde el protocolo, para toda la red a la vez (Enterprise, colector) |
| Topología desde el protocolo de enrutamiento | ~Requiere integración o desarrollo adicional | ✓Desde la LSDB o el colector (Community / Enterprise) |
| Rutas SPF y ECMP | ~Requiere desarrollo aparte | ✓Integrado (Community) |
| Fallos hipotéticos y enlaces sin respaldo | ✕Normalmente no disponible | ✓Integrado, sobre el modelo (Community) |
| Cambios de enrutamiento en el tiempo | ~Logs y traps de dispositivos individuales | ✓Eventos y la topología en el momento del evento (Enterprise) |
Topolograph y los colectores de protocolos de enrutamiento se ejecutan en su infraestructura; los datos de enrutamiento y el historial de estados de la red quedan bajo su control.
Un colector físico en su sede recibe los datos de enrutamiento localmente y transmite los datos acordados a Topolograph alojado por un canal protegido.
Community: análisis sin conexión de instantáneas, gratuito y en su propia infraestructura. Enterprise: monitoreo continuo de protocolos y trabajo en equipo.
| Función | Community | Enterprise |
|---|---|---|
| Subida de LSDB, grafo, cálculo de rutas, escenarios de fallo | ✅ | ✅ |
| API, SDK, servidor MCP | ✅ | ✅ |
| Watcher (OSPF / IS-IS) | ❌ (solo topología estática de la LSDB) | varios watchers, monitoreo unificado |
| Monitoreo de eventos de red | ❌ | consultas rápidas en un periodo largo |
| Usuarios | uno o compartido | equipos, RBAC |
| Inicio de sesión | usuario / contraseña | Inicio de sesión único (OIDC / SAML / LDAP) |
| Registro de auditoría de acciones | ❌ | ✅ |
| Alertas (webhook, Zabbix, correo electrónico) | exportación de eventos: Logstash → ELK, Zabbix, webhook; Fluent Bit → webhook | reglas de alerta y enrutamiento * |
| NetFlow: grafo de tráfico | ❌ | ✅ |
| Watcher de hardware | ❌ | un dispositivo físico con los watchers instalados: se conecta a la LAN, acceso por SSH |
| Stack tecnológico | Flask, MongoDB | rediseñado para carga alta |
| Soporte | Issues en GitHub | soporte prioritario |
Volver a subir la LSDB mediante la API también está disponible en Community, pero son instantáneas bajo demanda, no un flujo de eventos del watcher.