O Topolograph constrói um modelo da rede a partir do que seus protocolos de roteamento informam. Cada nova fonte adiciona ao modelo sua própria camada independente. Todo o resto é calculado sobre ele: caminhos primários e de backup, links sem backup, pesquisa de elementos da rede (prefixos, endereços MAC e outros) e falhas de links ou nós simuladas antes do início da manutenção. A análise funciona a partir de um único snapshot da LSDB; um coletor acrescenta o fluxo de alterações, e um agente de IA responde a perguntas com os mesmos dados.
O que um único snapshot oferece?
A saída de show ip ospf database router de um roteador se torna um snapshot estático da rede: 13 roteadores, 26 links. Você trabalha com ele offline, sem acesso aos roteadores: cálculo de caminhos, pesquisa de elementos da rede, planejamento de manutenção. O diagrama mostra o caminho pe15 → pe30: custo 41, quatro caminhos de custo igual.
Um link ou um dispositivo pode ser retirado de serviço?
O link core10 ↔ core30 é desligado no modelo: o SPF é recalculado, o tráfego passa para core11 ↔ core31, o custo vai de 41 para 50, e ainda há quatro caminhos. A rede real não é afetada.
O que está mudando na rede agora?
O coletor do Topolograph (watcher) recebe atualizações dos protocolos de roteamento e repassa eventos sobre mudanças de topologia. Ele se conecta à rede de uma de três formas: uma adjacência IGP simples, uma adjacência IGP sobre GRE ou BGP-LS; na demonstração é uma adjacência GRE com rr1. Quando o link pe15 ↔ core110 cai, as duas pontas inundam novos Router LSAs, a atualização chega ao coletor e um evento com carimbo de data e hora chega ao Topolograph. Dos quatro caminhos pe15 → pe30, restam dois.
Como era a rede no momento do incidente?
A linha do tempo reproduz os eventos do coletor: a métrica pe14 → core110, o link pe15 ↔ core110 caindo e voltando, uma nova rede em core31, uma métrica TE. O cursor então se move entre T+3 s e T+5 s: quatro caminhos antes da falha, dois depois. O snapshot T0 e qualquer estado posterior podem ser comparados.
O que aconteceu na rede nos últimos 15 minutos?
O engenheiro faz a pergunta. O agente chama as ferramentas do servidor MCP do Topolograph para eventos e cálculo de falhas, e responde com referência aos dados. O Agent 2.0 já diagnostica incidentes com um runbook combinado previamente: a pedido de um engenheiro ou automaticamente quando um evento abre um ticket. Acesso somente leitura, autorização e passos explícitos do runbook tornam o diagnóstico seguro e várias vezes mais rápido.
Cinco alterações em 15 minutos:
Os dados do protocolo não mostram por que o link caiu. Verificar os logs de pe15 e core110 no horário do incidente? Agent 2.0
Zabbix, Prometheus e Cacti observam dispositivos e interfaces. O Topolograph mostra como a rede roteia o tráfego e trabalha em conjunto com eles.
| Monitoramento clássico | Topolograph | |
|---|---|---|
| Estado de interfaces e dispositivos | ✓A tarefa principal | ✕Fora do escopo do Topolograph: os dados permanecem no monitoramento existente |
| Estado dos vizinhos OSPF / BGP | ~Via SNMP ou exportadores, dispositivo por dispositivo | ✓Pelo protocolo, para a rede inteira de uma vez (Enterprise, coletor) |
| Topologia a partir do protocolo de roteamento | ~Exige integração ou desenvolvimento adicional | ✓Da LSDB ou do coletor (Community / Enterprise) |
| Caminhos SPF e ECMP | ~Exige desenvolvimento separado | ✓Integrado (Community) |
| Falhas hipotéticas e links sem backup | ✕Geralmente indisponível | ✓Integrado, sobre o modelo (Community) |
| Alterações de roteamento ao longo do tempo | ~Logs e traps de dispositivos individuais | ✓Eventos e a topologia no momento do evento (Enterprise) |
O Topolograph e os coletores de protocolos de roteamento rodam na sua infraestrutura; os dados de roteamento e o histórico dos estados da rede permanecem sob o seu controle.
Um coletor físico no seu site recebe os dados de roteamento localmente e repassa os dados combinados ao Topolograph hospedado por um canal protegido.
Community: análise offline de snapshots, gratuita e na sua própria infraestrutura. Enterprise: monitoramento contínuo de protocolos e trabalho em equipe.
| Recurso | Community | Enterprise |
|---|---|---|
| Carregamento de LSDB, grafo, cálculo de caminhos, cenários de falha | ✅ | ✅ |
| API, SDK, servidor MCP | ✅ | ✅ |
| Watcher (OSPF / IS-IS) | ❌ (somente topologia estática da LSDB) | vários watchers, monitoramento unificado |
| Monitoramento de eventos de rede | ❌ | consultas rápidas em um longo período |
| Usuários | um ou compartilhado | equipes, RBAC |
| Login | usuário / senha | Login único (OIDC / SAML / LDAP) |
| Log de auditoria de ações | ❌ | ✅ |
| Alertas (webhook, Zabbix, e-mail) | exportação de eventos: Logstash → ELK, Zabbix, webhook; Fluent Bit → webhook | regras e roteamento de alertas * |
| NetFlow: grafo de tráfego | ❌ | ✅ |
| Watcher de hardware | ❌ | um dispositivo físico com os watchers instalados: conecta-se à LAN, acesso por SSH |
| Stack | Flask, MongoDB | reformulada para alta carga |
| Suporte | Issues no GitHub | suporte prioritário |
O novo carregamento da LSDB pela API também está disponível na Community, mas são snapshots sob demanda, não um fluxo de eventos do watcher.
Entenda sua rede em uma noite: carregue um LSDB e veja caminhos e falhas.
InstalarMonitoramento contínuo de todos os domínios, login por SSO e histórico de eventos de anos.
Entrar em contato