Topolograph builds a model of the network from what its routing protocols report. Each new source adds its own independent layer to that model. Everything else is computed on it: primary and backup paths, links with no backup, search over network elements (prefixes, MAC addresses and more), and link or node failures simulated before maintenance starts. Analysis works from a single LSDB snapshot; a collector adds the stream of changes, and an AI agent answers questions from the same data.
What does a single snapshot give you?
The output of show ip ospf database router from one router becomes a static snapshot of the network: 13 routers, 26 links. You work with it offline, without access to the routers: path calculation, search over network elements, maintenance planning. The diagram shows the pe15 → pe30 path: cost 41, four equal-cost paths.
Can a link or a device be taken out of service?
The core10 ↔ core30 link is switched off on the model: SPF is recalculated, traffic moves to core11 ↔ core31, the cost goes from 41 to 50, and there are still four paths. The real network is not touched.
What is changing in the network right now?
The Topolograph collector (watcher) receives routing protocol updates and passes on events about topology changes. It joins the network in one of three ways: a plain IGP adjacency, an IGP adjacency over GRE, or BGP-LS; in the demo it is a GRE adjacency with rr1. When the pe15 ↔ core110 link goes down, both of its ends flood new Router LSAs, the update reaches the collector, and a timestamped event arrives in Topolograph. Of the four pe15 → pe30 paths, two remain.
What did the network look like at the time of the incident?
The timeline replays the collector events: the pe14 → core110 metric, the pe15 ↔ core110 link going down and coming back, a new network on core31, a TE metric. The cursor then moves between T+3 s and T+5 s: four paths before the failure, two after it. The T0 snapshot and any later state can be compared.
What happened in the network in the last 15 minutes?
The engineer asks the question. The agent calls the Topolograph MCP server tools for events and failure calculation, and answers with a reference to the data. Agent 2.0 already diagnoses incidents with a runbook agreed in advance: on an engineer's request, or automatically when an event opens a ticket. Read-only access, authorization and the explicit runbook steps make the diagnosis safe and several times faster.
Five changes in 15 minutes:
The protocol data does not show why the link went down. Check the pe15 and core110 logs for the time of the incident? Agent 2.0
Zabbix, Prometheus and Cacti watch devices and interfaces. Topolograph shows how the network routes traffic and works alongside them.
| Classic monitoring | Topolograph | |
|---|---|---|
| Interface and device state | ✓The main task | ✕Outside the scope of Topolograph: the data stays in the existing monitoring |
| OSPF / BGP neighbor status | ~Through SNMP or exporters, device by device | ✓From the protocol, for the whole network at once (Enterprise, collector) |
| Topology from the routing protocol | ~Needs integration or extra development | ✓From the LSDB or the collector (Community / Enterprise) |
| SPF and ECMP paths | ~Needs separate development | ✓Built in (Community) |
| What-if failures and links with no backup | ✕Usually not available | ✓Built in, on the model (Community) |
| Routing changes over time | ~Logs and traps of single devices | ✓Events and the topology at the time of the event (Enterprise) |
Topolograph and the routing protocol collectors run in your infrastructure; the routing data and the history of network states stay under your control.
A physical collector on your site receives the routing data locally and passes the agreed data to the hosted Topolograph over a protected channel.
Community: offline analysis of snapshots, free and in your own infrastructure. Enterprise: continuous protocol monitoring and teamwork.
| Feature | Community | Enterprise |
|---|---|---|
| LSDB upload, graph, path calculation, failure scenarios | ✅ | ✅ |
| API, SDK, MCP server | ✅ | ✅ |
| Watcher (OSPF / IS-IS) | ❌ (static topology from the LSDB only) | many watchers, unified monitoring |
| Network event monitoring | ❌ | fast queries over a long period |
| Users | one or shared | teams, RBAC |
| Sign-in | login / password | SSO (OIDC / SAML / LDAP) |
| Action audit log | ❌ | ✅ |
| Alerts (webhook, Zabbix, e-mail) | event export: Logstash → ELK, Zabbix, webhook; Fluent Bit → webhook | alert rules and routing * |
| NetFlow: traffic graph | ❌ | ✅ |
| Hardware watcher | ❌ | a physical device with the watchers installed: plugs into the LAN, SSH access |
| Stack | Flask, MongoDB | reworked for heavy load |
| Support | GitHub issues | priority support |
Re-uploading the LSDB through the API is also available in Community, but these are snapshots on demand, not a stream of watcher events.
Understand your network in an evening: upload an LSDB and look at paths and failures.
InstallContinuous monitoring of all domains, SSO sign-in and years of event history.
Contact us