Topolograph construit un modèle du réseau à partir de ce que rapportent ses protocoles de routage. Chaque nouvelle source ajoute sa propre couche indépendante à ce modèle. Tout le reste est calculé dessus : chemins principaux et de secours, liens sans secours, recherche sur les éléments du réseau (préfixes, adresses MAC et plus), pannes de liens ou de nœuds simulées avant le début d'une maintenance. L'analyse fonctionne à partir d'un seul instantané LSDB ; un collecteur ajoute le flux des changements, et un agent AI répond aux questions à partir des mêmes données.
Que donne un seul instantané ?
La sortie de show ip ospf database router d'un seul routeur devient un instantané statique du réseau : 13 routeurs, 26 liens. Vous travaillez hors ligne, sans accès aux routeurs : calcul de chemins, recherche sur les éléments du réseau, planification de maintenance. Le schéma montre le chemin pe15 → pe30 : coût 41, quatre chemins de coût égal.
Peut-on mettre un lien ou un équipement hors service ?
Le lien core10 ↔ core30 est coupé sur le modèle : le SPF est recalculé, le trafic passe par core11 ↔ core31, le coût passe de 41 à 50, et il reste quatre chemins. Le réseau réel n'est pas touché.
Qu'est-ce qui change dans le réseau en ce moment ?
Le collecteur Topolograph (watcher) reçoit les mises à jour du protocole de routage et transmet des événements sur les changements de topologie. Il rejoint le réseau de trois façons : une adjacence IGP simple, une adjacence IGP sur GRE ou BGP-LS ; dans la démo, c'est une adjacence GRE avec rr1. Quand le lien pe15 ↔ core110 tombe, ses deux extrémités diffusent de nouvelles Router LSA, la mise à jour atteint le collecteur, et un événement horodaté arrive dans Topolograph. Des quatre chemins pe15 → pe30, il en reste deux.
À quoi ressemblait le réseau au moment de l'incident ?
La chronologie rejoue les événements du collecteur : la métrique pe14 → core110, le lien pe15 ↔ core110 qui tombe puis revient, un nouveau réseau sur core31, une métrique TE. Le curseur se déplace ensuite entre T+3 s et T+5 s : quatre chemins avant la panne, deux après. L'instantané T0 et tout état ultérieur peuvent être comparés.
Que s'est-il passé dans le réseau durant les 15 dernières minutes ?
L'ingénieur pose la question. L'agent appelle les outils du serveur MCP Topolograph pour les événements et le calcul de panne, et répond en citant les données. Agent 2.0 diagnostique déjà des incidents avec un runbook convenu à l'avance : à la demande d'un ingénieur, ou automatiquement quand un événement ouvre un ticket. L'accès en lecture seule, l'autorisation et les étapes explicites du runbook rendent le diagnostic sûr et plusieurs fois plus rapide.
Cinq changements en 15 minutes :
Les données du protocole n'indiquent pas pourquoi le lien est tombé. Vérifier les logs de pe15 et core110 au moment de l'incident ? Agent 2.0
Zabbix, Prometheus et Cacti surveillent les équipements et les interfaces. Topolograph montre comment le réseau route le trafic et fonctionne à leurs côtés.
| Supervision classique | Topolograph | |
|---|---|---|
| État des interfaces et des équipements | ✓La tâche principale | ✕Hors du périmètre de Topolograph : les données restent dans la supervision existante |
| État des voisins OSPF / BGP | ~Via SNMP ou des exporters, équipement par équipement | ✓Depuis le protocole, pour tout le réseau à la fois (Enterprise, collecteur) |
| Topologie issue du protocole de routage | ~Demande une intégration ou un développement supplémentaire | ✓Depuis la LSDB ou le collecteur (Community / Enterprise) |
| Chemins SPF et ECMP | ~Demande un développement distinct | ✓Intégré (Community) |
| Pannes what-if et liens sans secours | ✕En général indisponible | ✓Intégré, sur le modèle (Community) |
| Changements de routage dans le temps | ~Logs et traps d'équipements isolés | ✓Événements et topologie au moment de l'événement (Enterprise) |
Topolograph et les collecteurs de protocoles de routage s'exécutent dans votre infrastructure ; les données de routage et l'historique des états du réseau restent sous votre contrôle.
Un collecteur physique sur votre site reçoit les données de routage localement et transmet les données convenues au Topolograph hébergé via un canal protégé.
Community : analyse hors ligne d'instantanés, gratuite et dans votre propre infrastructure. Enterprise : supervision continue des protocoles et travail en équipe.
| Fonctionnalité | Community | Enterprise |
|---|---|---|
| Chargement LSDB, graphe, calcul de chemins, scénarios de panne | ✅ | ✅ |
| API, SDK, serveur MCP | ✅ | ✅ |
| Watcher (OSPF / IS-IS) | ❌ (topologie statique issue de la LSDB uniquement) | plusieurs watchers, supervision unifiée |
| Supervision des événements réseau | ❌ | requêtes rapides sur une longue période |
| Utilisateurs | un seul ou partagé | équipes, RBAC |
| Connexion | identifiant / mot de passe | authentification unique (SSO : OIDC / SAML / LDAP) |
| Journal d'audit des actions | ❌ | ✅ |
| Alertes (webhook, Zabbix, e-mail) | export d'événements : Logstash → ELK, Zabbix, webhook ; Fluent Bit → webhook | règles d'alerte et routage * |
| NetFlow : graphe du trafic | ❌ | ✅ |
| Watcher matériel | ❌ | un équipement physique avec les watchers installés : se branche sur le LAN, accès SSH |
| Pile technique | Flask, MongoDB | retravaillée pour les fortes charges |
| Support | Issues GitHub | support prioritaire |
Le rechargement de la LSDB via l'API est aussi disponible dans Community, mais il s'agit d'instantanés à la demande, pas d'un flux d'événements du watcher.
Comprendre son réseau en une soirée : importez un LSDB et regardez les chemins et les pannes.
InstallerSupervision continue de tous les domaines, connexion SSO et historique d'événements sur des années.
Nous contacter