Operación práctica de OSPF

Manual práctico de OSPF Watcher

Aplica un solo cambio controlado a la vez, predice su efecto y luego verifica el mismo hecho desde el evento de Watcher hasta Topolograph.

Empezar el manual

Enlaces útiles: OSPF Watcher - repositorio y guía de despliegue · Topolograph

1. Cómo funciona este manual

En cada ejercicio: haz un cambio, predice el resultado en OSPF, observa el evento de Watcher y luego encuentra el mismo hecho en Topolograph Monitoring, en el SDK y - en los ejercicios de correlación - en la respuesta del agente. Restaura el laboratorio antes del siguiente ejercicio independiente.

  1. La línea CSV de Watcher es el evento de origen determinista.
  2. Monitoring y el SDK demuestran que el evento se ingirió y se puede consultar.
  3. El agente solo se usa para correlacionar varios eventos en un incidente, nunca como sustituto de la línea de origen.

2. Puesta en marcha y validación del laboratorio de seis routers

Ejecuta la topología pública ospf01 basada en GRE del repositorio de 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
Comprobaciones necesarias Hechos que confirmar antes de continuar
  • Los seis contenedores de router y el watcher están activos: docker ps --filter name=clab-ospf01 lista clab-ospf01-router1..6 y clab-ospf01-ospf-watcher, todos con State=Up.
  • El watcher tiene la LSDB y está capturando: docker logs clab-ospf01-ospf-watcher muestra una línea "OSPF LSDB received" y "Start sniffing on interface: eth1".
  • Las adyacencias están en Full: docker exec clab-ospf01-router1 vtysh -c 'show ip ospf neighbor' lista cada vecino en estado Full; el primer grafo de Topolograph contiene entonces seis routers.

Reversión: Cuando termines el manual, elimina el laboratorio con sudo clab destroy --topo ospf01.clab.yml --cleanup desde containerlab/ospf01/.

3. Formato del registro de evento de red

El manual usa tres familias de eventos: host, metric y network. Lee event_object como el objeto que cambió, event_status como la transición y event_detected_by como el router que anuncia o detecta. graph_time es la etiqueta propia del watcher para la ejecución y selecciona el grafo de Topolograph.

Lee la línea metric de arriba como una sola frase: a las 2026-09-06T13:11:04Z el watcher ospfwatcher-demo vio al router 10.10.10.2 volver a anunciar su enlace hacia 10.10.10.3 con el coste cambiado de 10 a 222, en la interfaz local 192.168.23.1, en el área 0.0.0.0 / AS 12345. La línea network justo después lleva el mismo cambio 10 -> 222 para la subred 192.168.23.0/24 en ese enlace.

  1. Campos en orden: watcher_time, watcher_name, event_name, event_object, event_status, [campos de coste], event_detected_by, graph_time, area_num, asn, [campos de tipo], sesid, srcid.
  2. area_num 0.0.0.0 y asn 12345 identifican el dominio de enrutamiento; sesid es la sesión del watcher, srcid el id del router de origen.

CSV de 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 dónde vienen los eventos

Un cambio de OSPF produce una línea CSV de Watcher. Fluent Bit la reenvía a Topolograph, que la almacena y la expone a través de la página de Monitoring, la API de eventos y el SDK. Cada ejercicio de abajo comprueba el mismo hecho en todos los niveles disponibles.

  1. Registro de Watcher de ospf01 -> analizador CSV de Fluent Bit -> ingesta de Topolograph -> página de Monitoring + API de eventos -> SDK de Topolograph
  2. Página de Monitoring: OSPF/IS-IS Real-Time Monitoring. Elige el grafo por su marca de tiempo, define una ventana temporal y pulsa Find logs; los conmutadores filtran eventos de subred / enlace / métrica.
  3. El selector de grafos de esa página lista cada instantánea de topología que reportó el watcher, la más reciente primero - esa es la topología que envió el watcher.
Página de Topolograph OSPF/IS-IS Real-Time Monitoring para el grafo 06Sep2026_12h31m41s: selector de grafos y Find logs, el flujo de eventos mostrando las etiquetas de métrica 10 -> 222 y 222 -> 10 y 192.168.23.0/24, y debajo el grafo de topología con los seis routers y los pesos de los enlaces.

Petición del 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)

Salida del SDK

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

5. Cambio de coste en un enlace punto a punto

Cambia router2 eth1 hacia router3. Los costes de OSPF son dirigidos, así que el coste inverso de router3 a router2 no debe describirse como el mismo escalar.

Comando

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

Verifica el cambio. Abre cada fuente disponible en tu entorno y contrástala con los ejemplos de abajo.

Registro de Watcher Las líneas metric y network del cambio y de su reversión 4 líneas

CSV de 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
Monitorización El cambio de métrica 10 -> 222 en el flujo de eventos

En OSPF/IS-IS Real-Time Monitoring, elige este grafo en Choose the graph, define la ventana From/To en torno a las 13:11 UTC y pulsa Find logs. Con Changed metric activado, el flujo muestra una fila: object 10.10.10.3, detected by 10.10.10.2, 10 -> 222 - solo la dirección router2 -> router3. La dirección inversa no aparece. El grafo de topología bajo el flujo redibuja el enlace router2-router3 con el nuevo peso.

Verificación con el SDK get_adjacency_events y get_network_events devuelven el mismo objeto y los mismos costes 2 eventos

Petición del 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)

Salida del 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

El evento metric nombra la dirección router2 -> router3 (event_object 10.10.10.3, event_detected_by 10.10.10.2), coste 10 -> 222; 192.168.23.0/24 lleva el mismo cambio. La dirección inversa no está en ninguna de las dos listas.

Preguntar al agente Una pregunta genérica de incidente sobre router2

Petición: What happened with router2 in the last 10 minutes?

Respuesta capturada (Qwen; la redacción varía entre ejecuciones)

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 en esta ejecución: router2 volvió a anunciar su enlace a router3 con coste 222 (antes 10); la dirección inversa router3 -> router2 no cambió.

Reversión: Ejecuta no ip ospf cost 222 y confirma los eventos inversos metric y network 222 -> 10.

6. Detección de eventos de prefijos internos y externos

Ejecuta cada experimento de prefijo de forma independiente. Un loopback de OSPF configurado con máscara /24 se anuncia como ruta de host /32 en este laboratorio.

  1. 6a. Añade 192.168.123.1/24 al loopback de router2; observa 192.168.123.1/32 up y coste -1 -> 0 (internal).
  2. 6b. Añade 10.10.136.6/24 al loopback de router6; observa 10.10.136.6/32 up y coste -1 -> 0 (internal).
  3. 6c. Elimina la ruta estática 6.6.6.6/32 en router6; observa 6.6.6.6/32 down y coste 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'

Verifica el cambio. Abre cada fuente disponible en tu entorno y contrástala con los ejemplos de abajo.

Registro de Watcher Una línea up/down y una changed por subejercicio 6 líneas

CSV de 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
Monitorización Los prefijos nuevos y retirados en el flujo

En OSPF/IS-IS Real-Time Monitoring, elige este grafo, define la ventana From/To en torno a las 13:12 UTC y pulsa Find logs. Con New/Old Subnets activado, 192.168.123.1/32 y 10.10.136.6/32 aparecen como añadidos y 6.6.6.6/32 como retirado; el grafo de topología bajo el flujo añade las dos rutas de host y elimina la retirada.

Verificación con el SDK get_network_events, un evento changed por subejercicio 3 eventos

Petición del 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)

Salida del 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

Un /24 en el loopback se anuncia como /32. La disponibilidad es un evento up/down; el cambio de coste es un evento changed. La ruta retirada es external / tipo 2, los dos loopbacks internal / 0.

Preguntar al agente Una pregunta genérica sobre cambios de prefijos

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

Respuesta capturada (Qwen; la redacción varía entre ejecuciones)

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 en esta ejecución: 192.168.123.1/32 y 10.10.136.6/32 se añadieron como rutas de host internas; 6.6.6.6/32 (external, tipo 2) se retiró.

Reversión: 6a: no ip address 192.168.123.1/24 en router2 interface lo. 6b: no ip address 10.10.136.6/24 en router6 interface lo. 6c: ip route 6.6.6.6/32 192.168.36.3 en router6. Confirma el evento inverso despues de cada uno.

7. Detección de una pérdida de conectividad y su recuperación

Apaga router2 eth1, inspecciona el conjunto de eventos correlacionados y luego restaura la interfaz con 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'

Verifica el cambio. Abre cada fuente disponible en tu entorno y contrástala con los ejemplos de abajo.

Registro de Watcher El conjunto de caída y el conjunto de recuperación del enlace router2-router3 down + up

CSV de 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
Monitorización La caída como una sola oleada en el flujo

En OSPF/IS-IS Real-Time Monitoring, elige este grafo, define la ventana From/To en torno a las 13:04 UTC y pulsa Find logs. Con Up/Down Links activado, 10.10.10.2 muestra down y luego up, ambas métricas dirigidas pasan a -1 y vuelven, y 192.168.23.0/24 queda inalcanzable y regresa; el grafo de topología bajo el flujo elimina el enlace router2-router3 y lo restaura.

Verificación con el SDK get_adjacency_events devuelve los movimientos emparejados down/up 4 movimientos

Petición del 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])

Salida del 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, ambas métricas dirigidas a -1, 192.168.23.0/24 down; luego la recuperación en espejo.

Preguntar al agente Una pregunta genérica de incidente sobre la red

Petición: What happened in the network in the last 30 minutes?

Respuesta capturada (Qwen; la redacción varía entre ejecuciones)

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.

La respuesta nombra la adyacencia caída (10.10.10.2 - 10.10.10.3) detectada por 10.10.10.3, ambas métricas en -1 y la recuperación - los mismos hechos que las líneas CSV de arriba, a partir de una pregunta que nunca dice 'adjacency' ni 'failure'.

Reversión: no shutdown restaura la interfaz; espera los eventos de recuperación host, network y metric.

8. Informe de un segmento de tránsito de difusión

Usa router6 eth1 para comparar el reporte de un segmento de tránsito con el 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'

Verifica el cambio. Abre cada fuente disponible en tu entorno y contrástala con los ejemplos de abajo.

Registro de Watcher El cambio de coste nombra el id del router lejano, y el par apagado/recuperación cost + up/down

CSV de 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
Monitorización El cambio de coste de tránsito y la caída de router6

En OSPF/IS-IS Real-Time Monitoring, elige este grafo, define la ventana From/To en torno a las 13:13-13:14 UTC y pulsa Find logs. El object del evento metric es 10.10.10.3 (el id del router lejano) con event_detected_by 10.10.10.6 - a diferencia de un enlace point-to-point, donde el object es el vecino. El grafo de topología bajo el flujo recalcula los pesos y luego elimina y restaura la conexión de router6.

Verificación con el SDK get_adjacency_events para el coste de tránsito y el apagado/recuperación 4 movimientos

Petición del 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])

Salida del 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

En un segmento de tránsito el evento metric nombra el id del router lejano (10.10.10.3), detectado por router6; el apagado es host 10.10.10.6 down, luego la recuperación.

Preguntar al agente Una pregunta genérica de incidente sobre router6

Petición: What happened on router6 in the last 20 minutes?

Respuesta capturada (Qwen; la redacción varía entre ejecuciones)

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 en esta ejecución: el coste de tránsito router6 -> router3 pasó de 6 -> 66 y volvió, luego la conexión de router6 cayó (metric -1) y se recuperó.

Reversión: ip ospf cost 6 restaura la línea base; no shutdown restaura la adyacencia. Confirma los eventos metric inversos.

Topolograph 2.69.4 📣 ¡Únete a la comunidad!