Operação prática de OSPF

Manual prático do OSPF Watcher

Faça uma única mudança controlada de cada vez, preveja o efeito e depois verifique o mesmo fato desde o evento do Watcher até o Topolograph.

Começar o manual

Links úteis: OSPF Watcher - repositório e guia de implantação · Topolograph

1. Como este manual funciona

Em cada exercício: faça uma mudança, preveja o resultado no OSPF, observe o evento do Watcher e então encontre o mesmo fato no Topolograph Monitoring, no SDK e - nos exercícios de correlação - na resposta do agente. Restaure o laboratório antes do próximo exercício independente.

  1. A linha CSV do Watcher é o evento de origem determinístico.
  2. O Monitoring e o SDK provam que o evento foi ingerido e pode ser consultado.
  3. O agente é usado apenas para correlacionar vários eventos em um incidente, nunca como substituto da linha de origem.

2. Subida e validação do laboratório de seis roteadores

Execute a topologia pública ospf01 baseada em GRE do repositório do OSPF Watcher.

Comando

cd containerlab/ospf01
sudo clab inspect --all
sudo clab destroy --topo ospf01.clab.yml --cleanup   # only if a stale ospf01 is listed
sudo ./prepare.sh
sudo clab deploy --topo ospf01.clab.yml
sudo docker logs clab-ospf01-ospf-watcher
sudo tail -f watcher/logs/watcher1.ospf.log
Verificações obrigatórias Fatos a confirmar antes de continuar
  • Os seis contêineres de roteador e o watcher estão ativos: docker ps --filter name=clab-ospf01 lista clab-ospf01-router1..6 e clab-ospf01-ospf-watcher, todos com State=Up.
  • O watcher tem a LSDB e está capturando: docker logs clab-ospf01-ospf-watcher mostra uma linha "OSPF LSDB received" e "Start sniffing on interface: eth1".
  • As adjacências estão em Full: docker exec clab-ospf01-router1 vtysh -c 'show ip ospf neighbor' lista cada vizinho no estado Full; o primeiro grafo do Topolograph contém então seis roteadores.

Reversão: Ao terminar o manual, remova o laboratorio com sudo clab destroy --topo ospf01.clab.yml --cleanup a partir de containerlab/ospf01/.

3. Formato do registro de evento de rede

O manual usa três famílias de eventos: host, metric e network. Leia event_object como o objeto que mudou, event_status como a transição e event_detected_by como o roteador que anuncia ou detecta. graph_time é o rótulo do próprio watcher para a execução e seleciona o grafo do Topolograph.

Leia a linha metric acima como uma única frase: em 2026-09-06T13:11:04Z o watcher ospfwatcher-demo viu o roteador 10.10.10.2 reanunciar seu enlace para 10.10.10.3 com o custo alterado de 10 para 222, na interface local 192.168.23.1, na área 0.0.0.0 / AS 12345. A linha network logo depois carrega a mesma mudança 10 -> 222 para a sub-rede 192.168.23.0/24 nesse enlace.

  1. Campos na ordem: watcher_time, watcher_name, event_name, event_object, event_status, [campos de custo], event_detected_by, graph_time, area_num, asn, [campos de tipo], sesid, srcid.
  2. area_num 0.0.0.0 e asn 12345 identificam o domínio de roteamento; sesid é a sessão do watcher, srcid o id do roteador de origem.

CSV do Watcher

host: 2026-09-06T13:04:25.256Z,ospfwatcher-demo,host,10.10.10.2,down,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
metric: 2026-09-06T13:11:04.205Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:10,new_cost:222,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.1,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
network: 2026-09-06T13:11:04.207Z,ospfwatcher-demo,network,192.168.23.0/24,changed,old_cost:10,new_cost:222,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,internal,0,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1

4. De onde vêm os eventos

Uma mudança de OSPF produz uma linha CSV do Watcher. O Fluent Bit a encaminha ao Topolograph, que a armazena e a expõe pela página de Monitoring, pela API de eventos e pelo SDK. Cada exercício abaixo confere o mesmo fato em todos os níveis disponíveis para você.

  1. Log do Watcher do ospf01 -> analisador CSV do Fluent Bit -> ingestão do Topolograph -> página de Monitoring + API de eventos -> SDK do Topolograph
  2. Página de Monitoring: OSPF/IS-IS Real-Time Monitoring. Escolha o grafo pelo carimbo de tempo, defina uma janela de tempo, clique em Find logs; os alternadores filtram eventos de sub-rede / enlace / métrica.
  3. O seletor de grafos dessa página lista cada instantâneo de topologia que o watcher reportou, do mais recente primeiro - essa é a topologia que o watcher enviou.
Página do Topolograph OSPF/IS-IS Real-Time Monitoring para o grafo 06Sep2026_12h31m41s: seletor de grafos e Find logs, o fluxo de eventos mostrando os rótulos de métrica 10 -> 222 e 222 -> 10 e 192.168.23.0/24, e abaixo o grafo de topologia com os seis roteadores e os pesos dos enlaces.

Requisição do SDK

from topolograph import Topolograph

topo = Topolograph(url="http://<your-topolograph>:8080",
                   username="<email>", password="<password>")
graph = topo.graphs.get(latest=True)
print(graph.graph_time, graph.protocol, graph.hosts)

Saída do SDK

06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo ospf {'count': 6}

5. Mudança de custo em um enlace ponto a ponto

Altere router2 eth1 em direção a router3. Os custos do OSPF são dirigidos, então o custo inverso de router3 para router2 não deve ser descrito como o mesmo escalar.

Comando

sudo docker exec clab-ospf01-router2 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'ip ospf cost 222'

Verifique a mudança. Abra cada fonte disponível no seu ambiente e confira com os exemplos abaixo.

Log do Watcher As linhas metric e network da mudança e de sua reversão 4 linhas

CSV do Watcher

2026-09-06T13:11:04.205Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:10,new_cost:222,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.1,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:11:04.207Z,ospfwatcher-demo,network,192.168.23.0/24,changed,old_cost:10,new_cost:222,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,internal,0,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# rollback (no ip ospf cost 222):
2026-09-06T13:11:18.365Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:222,new_cost:10,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.1,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:11:18.367Z,ospfwatcher-demo,network,192.168.23.0/24,changed,old_cost:222,new_cost:10,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,internal,0,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
Monitoramento A mudança de métrica 10 -> 222 no fluxo de eventos

No OSPF/IS-IS Real-Time Monitoring, escolha este grafo em Choose the graph, defina a janela From/To por volta das 13:11 UTC e clique em Find logs. Com Changed metric ativado, o fluxo mostra uma linha: object 10.10.10.3, detected by 10.10.10.2, 10 -> 222 - apenas o sentido router2 -> router3. O sentido inverso não é listado. O grafo de topologia abaixo do fluxo redesenha o enlace router2-router3 com o novo peso.

Verificação via SDK get_adjacency_events e get_network_events retornam o mesmo objeto e os mesmos custos 2 eventos

Requisição do SDK

adj = graph.events.get_adjacency_events(
    start_time="2026-09-06T13:11:00Z", end_time="2026-09-06T13:11:10Z")
net = graph.events.get_network_events(
    start_time="2026-09-06T13:11:00Z", end_time="2026-09-06T13:11:10Z")
print(adj["adjacency_cost_change_events"])
print(net["network_cost_change_events"])
e = adj["adjacency_cost_change_events"][0]
print(e.event_object, e.event_detected_by, e.old_cost, e.new_cost, e.local_ip_address)

Saída do SDK

[Event(name=metric, status=changed, object=10.10.10.3)]
[Event(name=network, status=changed, object=192.168.23.0/24)]
10.10.10.3 10.10.10.2 10 222 192.168.23.1

O evento metric nomeia o sentido router2 -> router3 (event_object 10.10.10.3, event_detected_by 10.10.10.2), custo 10 -> 222; 192.168.23.0/24 carrega a mesma mudança. O sentido inverso está ausente das duas listas.

Perguntar ao agente Uma pergunta genérica de incidente sobre router2

Pergunta: What happened with router2 in the last 10 minutes?

Resposta capturada (Qwen; a redação varia entre execuções)

In the 06Sep2026_12h31m41s snapshot, router2 (10.10.10.2) had one change in this window - an OSPF metric change on its link to 10.10.10.3, detected by router2 itself. No prefix, link, or node went down.

13:11:04 - router2 raised the cost of its link to 10.10.10.3 from 10 to 222 (192.168.23.0/24, area 0).

13:11:19 - router2 restored that cost from 222 back to 10.

Only the router2 -> 10.10.10.3 direction produced an event; the reverse 10.10.10.3 -> router2 direction did not change.

Observado nesta execução: router2 reanunciou seu enlace para router3 com custo 222 (era 10); o sentido inverso router3 -> router2 não mudou.

Reversão: Execute no ip ospf cost 222 e confirme os eventos inversos metric e network 222 -> 10.

6. Detecção de eventos de prefixos internos e externos

Execute cada experimento de prefixo de forma independente. Um loopback OSPF configurado com máscara /24 é anunciado como rota de host /32 por este laboratório.

  1. 6a. Adicione 192.168.123.1/24 ao loopback de router2; observe 192.168.123.1/32 up e custo -1 -> 0 (internal).
  2. 6b. Adicione 10.10.136.6/24 ao loopback de router6; observe 10.10.136.6/32 up e custo -1 -> 0 (internal).
  3. 6c. Remova a rota estática 6.6.6.6/32 no router6; observe 6.6.6.6/32 down e custo 11 -> -1 (external, tipo 2).

Comando

sudo docker exec clab-ospf01-router2 vtysh \
  -c 'conf t' -c 'interface lo' -c 'ip address 192.168.123.1/24'

Verifique a mudança. Abra cada fonte disponível no seu ambiente e confira com os exemplos abaixo.

Log do Watcher Uma linha up/down e uma linha changed por subexercício 6 linhas

CSV do Watcher

# 6a router2: ip address 192.168.123.1/24 on interface lo
2026-09-06T13:12:06.600Z,ospfwatcher-demo,network,192.168.123.1/32,up,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:12:06.601Z,ospfwatcher-demo,network,192.168.123.1/32,changed,old_cost:-1,new_cost:0,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,internal,0,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# 6b router6: ip address 10.10.136.6/24 on interface lo
2026-09-06T13:12:28.916Z,ospfwatcher-demo,network,10.10.136.6/32,up,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:12:28.917Z,ospfwatcher-demo,network,10.10.136.6/32,changed,old_cost:-1,new_cost:0,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,internal,0,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# 6c router6: no ip route 6.6.6.6/32 192.168.36.3
2026-09-06T13:12:51.315Z,ospfwatcher-demo,network,6.6.6.6/32,down,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:12:51.315Z,ospfwatcher-demo,network,6.6.6.6/32,changed,old_cost:11,new_cost:-1,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,external,2,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
Monitoramento Os prefixos novos e retirados no fluxo

No OSPF/IS-IS Real-Time Monitoring, escolha este grafo, defina a janela From/To por volta das 13:12 UTC e clique em Find logs. Com New/Old Subnets ativado, 192.168.123.1/32 e 10.10.136.6/32 aparecem como adicionados e 6.6.6.6/32 como retirado; o grafo de topologia abaixo do fluxo adiciona as duas rotas de host e remove a retirada.

Verificação via SDK get_network_events, um evento changed por subexercício 3 eventos

Requisição do SDK

for window in [("2026-09-06T13:12:05Z", "2026-09-06T13:12:08Z"),
               ("2026-09-06T13:12:27Z", "2026-09-06T13:12:30Z"),
               ("2026-09-06T13:12:50Z", "2026-09-06T13:12:53Z")]:
    net = graph.events.get_network_events(start_time=window[0], end_time=window[1])
    for e in net["network_up_down_events"]:
        print(e.event_object, e.event_status, e.event_detected_by,
              f"{e.old_cost} -> {e.new_cost}", e.subnet_type, e.int_ext_subtype)

Saída do SDK

192.168.123.1/32 changed 10.10.10.2 -1 -> 0 internal 0
10.10.136.6/32 changed 10.10.10.6 -1 -> 0 internal 0
6.6.6.6/32 changed 10.10.10.6 11 -> -1 external 2

Um /24 no loopback é anunciado como /32. A disponibilidade é um evento up/down; a mudança de custo é um evento changed. A rota retirada é external / tipo 2, os dois loopbacks internal / 0.

Perguntar ao agente Uma pergunta genérica sobre mudanças de prefixos

Pergunta: Which prefixes changed in the last 15 minutes, and were they internal or external?

Resposta capturada (Qwen; a redação varia entre execuções)

In the 06Sep2026_12h31m41s snapshot, three prefixes changed between 13:12 and 13:13 UTC - each advertised and then withdrawn within about ten seconds.

192.168.123.1/32 - internal, seen from 10.10.10.2 at 13:12:07 (cost 0), gone by 13:12:18.

10.10.136.6/32 - internal, seen from 10.10.10.6 at 13:12:29 (cost 0), gone by 13:12:40.

6.6.6.6/32 - external, withdrawn by 10.10.10.6 at 13:12:51 (was cost 11), back by 13:13:03.

192.168.123.1/32 and 10.10.136.6/32 are internal; 6.6.6.6/32 is the only external prefix.

Observado nesta execução: 192.168.123.1/32 e 10.10.136.6/32 foram adicionados como rotas de host internas; 6.6.6.6/32 (external, tipo 2) foi retirado.

Reversão: 6a: no ip address 192.168.123.1/24 em router2 interface lo. 6b: no ip address 10.10.136.6/24 em router6 interface lo. 6c: ip route 6.6.6.6/32 192.168.36.3 em router6. Confirme o evento inverso apos cada um.

7. Detecção de uma perda de conectividade e sua recuperação

Desative router2 eth1, inspecione o conjunto de eventos correlacionados e então restaure a interface com no shutdown.

Comando

# down
sudo docker exec clab-ospf01-router2 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'shutdown'
# recovery
sudo docker exec clab-ospf01-router2 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'no shutdown'

Verifique a mudança. Abra cada fonte disponível no seu ambiente e confira com os exemplos abaixo.

Log do Watcher O conjunto de queda e o conjunto de recuperação do enlace router2-router3 down + up

CSV do Watcher

# router2: interface eth1 / shutdown
2026-09-06T13:04:25.256Z,ospfwatcher-demo,host,10.10.10.2,down,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:25.256Z,ospfwatcher-demo,metric,10.10.10.2,changed,old_cost:10,new_cost:-1,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.2,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:25.257Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:10,new_cost:-1,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.1,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:25.259Z,ospfwatcher-demo,network,192.168.23.0/24,down,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# router2: interface eth1 / no shutdown
2026-09-06T13:04:40.438Z,ospfwatcher-demo,network,192.168.23.0/24,up,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:40.458Z,ospfwatcher-demo,host,10.10.10.2,up,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:40.459Z,ospfwatcher-demo,metric,10.10.10.2,changed,old_cost:-1,new_cost:10,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.23.2,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:04:45.557Z,ospfwatcher-demo,host,10.10.10.3,up,10.10.10.2,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
Monitoramento A queda como uma única onda no fluxo

No OSPF/IS-IS Real-Time Monitoring, escolha este grafo, defina a janela From/To por volta das 13:04 UTC e clique em Find logs. Com Up/Down Links ativado, 10.10.10.2 mostra down e depois up, as duas métricas dirigidas vão para -1 e voltam, e 192.168.23.0/24 fica inacessível e retorna; o grafo de topologia abaixo do fluxo remove o enlace router2-router3 e o restaura.

Verificação via SDK get_adjacency_events retorna os movimentos emparelhados down/up 4 movimentos

Requisição do SDK

adj = graph.events.get_adjacency_events(
    start_time="2026-09-06T13:04:20Z", end_time="2026-09-06T13:04:50Z")
for e in adj["all_host_up_down_events"]:
    print(e.event_name, e.event_object, "detected_by", e.event_detected_by,
          f"{e.old_cost} -> {e.new_cost}", e.watcher_time[11:19])

Saída do SDK

metric 10.10.10.2 detected_by 10.10.10.3 10 -> -1 13:04:25
metric 10.10.10.3 detected_by 10.10.10.2 10 -> -1 13:04:25
metric 10.10.10.2 detected_by 10.10.10.3 -1 -> 10 13:04:40
metric 10.10.10.3 detected_by 10.10.10.2 -1 -> 10 13:04:45

host 10.10.10.2 down detectado por 10.10.10.3, as duas métricas dirigidas a -1, 192.168.23.0/24 down; depois a recuperação em espelho.

Perguntar ao agente Uma pergunta genérica de incidente sobre a rede

Pergunta: What happened in the network in the last 30 minutes?

Resposta capturada (Qwen; a redação varia entre execuções)

There was 1 wave of activity, starting at 13:04:25 UTC and involving 2 devices - a brief link flap between 10.10.10.2 and 10.10.10.3 that fully recovered (converged) within ~21 seconds.

13:04:25 - device 10.10.10.2 lost adjacency (link down, cost 10 -> -1).

13:04:25 - device 10.10.10.3 lost adjacency (link down, cost 10 -> -1).

13:04:41 - device 10.10.10.2 restored adjacency (link up, cost -1 -> 10).

13:04:46 - device 10.10.10.3 restored adjacency (link up, cost -1 -> 10).

Pattern: flap - all devices recovered within the wave, so the network re-converged.

A resposta nomeia a adjacência que falhou (10.10.10.2 - 10.10.10.3) detectada por 10.10.10.3, as duas métricas em -1, e a recuperação - os mesmos fatos das linhas CSV acima, a partir de uma pergunta que nunca diz 'adjacency' nem 'failure'.

Reversão: no shutdown restaura a interface; aguarde os eventos de recuperação host, network e metric.

8. Relato de um segmento de trânsito de difusão

Use router6 eth1 para comparar o relato de um segmento de trânsito com o caso point-to-point.

Comando

# cost
sudo docker exec clab-ospf01-router6 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'ip ospf cost 66'
# then, separately: shutdown, then no shutdown
sudo docker exec clab-ospf01-router6 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'shutdown'
sudo docker exec clab-ospf01-router6 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'no shutdown'

Verifique a mudança. Abra cada fonte disponível no seu ambiente e confira com os exemplos abaixo.

Log do Watcher A mudança de custo nomeia o id do roteador distante, e o par desligamento/recuperação cost + up/down

CSV do Watcher

# router6: interface eth1 / ip ospf cost 66   (and rollback ip ospf cost 6)
2026-09-06T13:13:13.841Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:6,new_cost:66,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.36.6,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:13:25.028Z,ospfwatcher-demo,metric,10.10.10.3,changed,old_cost:66,new_cost:6,10.10.10.6,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.36.6,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# router6: interface eth1 / shutdown
2026-09-06T13:13:36.241Z,ospfwatcher-demo,host,10.10.10.6,down,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:13:36.241Z,ospfwatcher-demo,metric,10.10.10.6,changed,old_cost:10,new_cost:-1,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.36.3,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
# router6: interface eth1 / no shutdown
2026-09-06T13:14:30.447Z,ospfwatcher-demo,host,10.10.10.6,up,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
2026-09-06T13:14:30.447Z,ospfwatcher-demo,metric,10.10.10.6,changed,old_cost:-1,new_cost:10,10.10.10.3,06Sep2026_12h31m41s_6_hosts_bgpls_ospfwatcher-demo,0.0.0.0,12345,192.168.36.3,,e9a31bb2-a9ee-11f1-85b5-1e1be0e3c37d,10.10.10.1
Monitoramento A mudança de custo de trânsito e a queda de router6

No OSPF/IS-IS Real-Time Monitoring, escolha este grafo, defina a janela From/To por volta das 13:13-13:14 UTC e clique em Find logs. O object do evento metric é 10.10.10.3 (o id do roteador distante) com event_detected_by 10.10.10.6 - diferente de um enlace point-to-point, onde o object é o vizinho. O grafo de topologia abaixo do fluxo recalcula os pesos e então remove e restaura a conexão de router6.

Verificação via SDK get_adjacency_events para o custo de trânsito e o desligamento/recuperação 4 movimentos

Requisição do SDK

cost = graph.events.get_adjacency_events(
    start_time="2026-09-06T13:13:10Z", end_time="2026-09-06T13:13:30Z")
for e in cost["adjacency_cost_change_events"]:
    print("cost", e.event_object, e.event_detected_by, f"{e.old_cost} -> {e.new_cost}", e.watcher_time[11:19])
flap = graph.events.get_adjacency_events(
    start_time="2026-09-06T13:13:30Z", end_time="2026-09-06T13:14:35Z")
for e in flap["all_host_up_down_events"]:
    print("updown", e.event_object, e.event_detected_by, f"{e.old_cost} -> {e.new_cost}", e.watcher_time[11:19])

Saída do SDK

cost 10.10.10.3 10.10.10.6 6 -> 66 13:13:13
cost 10.10.10.3 10.10.10.6 66 -> 6 13:13:25
updown 10.10.10.6 10.10.10.3 10 -> -1 13:13:36
updown 10.10.10.6 10.10.10.3 -1 -> 10 13:14:30

Em um segmento de trânsito o evento metric nomeia o id do roteador distante (10.10.10.3), detectado por router6; o desligamento é host 10.10.10.6 down, depois a recuperação.

Perguntar ao agente Uma pergunta genérica de incidente sobre router6

Pergunta: What happened on router6 in the last 20 minutes?

Resposta capturada (Qwen; a redação varia entre execuções)

In the 06Sep2026_12h31m41s snapshot, router6 (10.10.10.6) first flapped the cost of its link to 10.10.10.3, then lost that adjacency and recovered - about a 55 second outage.

13:13:14 - router6 changed the cost of its link to 10.10.10.3 from 6 to 66.

13:13:25 - router6 restored that cost from 66 back to 6.

13:13:36 - neighbor 10.10.10.3 reported its adjacency to router6 down (metric 10 -> -1).

13:14:31 - 10.10.10.3 reported the adjacency back up (metric -1 -> 10); router6 re-advertised its side at cost 6 by 13:14:36.

Pattern: a brief metric flap on the router6 - 10.10.10.3 link, then a short outage that fully recovered.

Observado nesta execução: o custo de trânsito router6 -> router3 foi de 6 -> 66 e voltou, depois a conexão de router6 caiu (metric -1) e se recuperou.

Reversão: ip ospf cost 6 restaura a linha de base; no shutdown restaura a adjacência. Confirme os eventos metric inversos.

Topolograph 2.69.4 📣 Junte-se à comunidade!