Operacion practica de IS-IS

Manual practico de IS-IS Watcher

Haz un solo cambio controlado cada vez, predice su efecto y verifica el mismo hecho desde el evento del Watcher hasta Topolograph.

Iniciar el manual

Enlaces utiles: IS-IS Watcher - repositorio y guia de despliegue · Topolograph

1. Cómo funciona este manual

Para cada ejercicio: haz un cambio, predice el resultado IS-IS, observa el evento del Watcher y luego encuentra el mismo hecho en Topolograph Monitoring, en el SDK y - en el ejercicio de correlacion - en la respuesta del agente. Restaura el laboratorio antes del siguiente ejercicio independiente.

isis01 es un dominio FRR de seis routers en un area (49.0001, AS 65100). router2-router3 usa Level-1-2; router3 hacia router6 y el tramo de router3 hacia la LAN router4/router5 son solo Level-2. El Watcher usa una adyacencia Level-2 en router1 y resuelve cada System ID a su hostname mediante el TLV de hostname dinamico de IS-IS, por lo que los eventos nombran router2, router3, router6 en vez de 0100.1001.000x.

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

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

Ejecuta la topologia publica isis01 basada en GRE del repositorio de IS-IS Watcher. prepare.sh tambien crea el puente isis-br-dr y carga los modulos de kernel MPLS que IS-IS TE necesita.

Primero comprueba si ya hay un laboratorio en marcha con sudo clab inspect --all. Si aparece un isis01 obsoleto, desmontalo con sudo clab destroy --topo isis01.clab.yml --cleanup desde containerlab/isis01/ antes de volver a desplegar; nombra el archivo de topologia para no tocar ningun otro laboratorio.

Comando

cd containerlab/isis01
sudo clab inspect --all
sudo clab destroy --topo isis01.clab.yml --cleanup   # only if a stale isis01 is listed
sudo ./prepare.sh
sudo clab deploy --topo isis01.clab.yml
sudo docker logs clab-isis01-isis-watcher
sudo tail -f watcher/logs/watcher1.isis.log
Observaciones requeridas Hechos a confirmar antes de continuar
  • Seis contenedores de router mas el watcher estan activos: docker ps --filter name=clab-isis01 lista clab-isis01-router1..6 y clab-isis01-isis-watcher, todos con State=Up.
  • El watcher tiene la LSDB y esta capturando: docker logs clab-isis01-isis-watcher muestra ISIS LSDB has been received y Sniffing packets on interface: eth1.
  • Las adyacencias estan Up: docker exec clab-isis01-router1 vtysh -c 'show isis neighbor' lista router3 en estado Up; el primer grafo de Topolograph contiene entonces seis routers.

Reversion: Cuando termines el manual, elimina el laboratorio con sudo clab destroy --topo isis01.clab.yml --cleanup desde containerlab/isis01/.

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 modificado, event_status como la transicion y event_detected_by como el router que anuncia o detecta. graph_time es la etiqueta propia del watcher para la ejecucion y selecciona el grafo de Topolograph.

Las lineas IS-IS llevan un campo level (1 o 2) que las lineas OSPF no tienen: es el tercer campo, justo despues de watcher_name. Lee la linea metric de arriba como una frase: a las 2026-09-07T06:55:14Z el watcher lab-isis01 vio a router3 reanunciar su enlace Level-1 hacia router2 con la metrica cambiada de 10 a -1 (adyacencia perdida), en la interfaz con direccion 192.168.23.2 en el area 49.0001 / AS 65100. La identidad detras de router2 es su NET / System ID 49.0001.0100.1001.0002.00; el watcher imprime el hostname porque cada router anuncia el TLV de hostname dinamico.

Una linea host o network up/down simple no lleva campos de coste, asi que Fluent Bit reenvia solo la linea changed emparejada. Topolograph deduce que una adyacencia cae por la linea metric cuyo new_cost es -1, y que vuelve por aquella cuyo old_cost es -1.

  1. Campos en orden: watcher_time, watcher_name, level, event_name, event_object, event_status, [campos de coste], event_detected_by, graph_time, area_num, asn, [local_ip, remote_ip | subnet_type, int_ext_subtype], sesid, srcid.
  2. area_num 49.0001 y asn 65100 identifican el dominio de enrutamiento; sesid es la sesion del watcher, srcid el System ID del router de origen (router1, 0100.1001.0001).

CSV de Watcher

host:    2026-09-07T06:55:14.754Z,lab-isis01,1,host,router2,down,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,192.168.23.2,192.168.23.1,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
metric:  2026-09-07T06:55:14.756Z,lab-isis01,1,metric,router2,changed,old_cost:10,new_cost:-1,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,192.168.23.2,192.168.23.1,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
network: 2026-09-07T06:55:14.761Z,lab-isis01,1,network,192.168.23.0/24,changed,old_cost:10,new_cost:-1,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,internal,0,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001

4. De dónde vienen los eventos

Un cambio IS-IS produce una linea CSV del Watcher por nivel. Fluent Bit la reenvia a Topolograph, que la almacena y la expone en la pagina de Monitoring, la API de eventos y el SDK. Cada ejercicio de abajo comprueba el mismo hecho en cada nivel disponible para ti.

  1. Registro del Watcher isis01 -> parser CSV de Fluent Bit -> ingesta de Topolograph -> pagina de Monitoring + API de eventos -> SDK de Topolograph
  2. Pagina de Monitoring: OSPF/IS-IS Real-Time Monitoring. Elige el grafo por su marca de tiempo en Choose the graph, define la ventana From/To en UTC, activa los interruptores L1 y L2, pulsa Find logs; los interruptores New/Old Subnets, Up/Down Links y Changed metric filtran lo que se lista.
  3. El selector de grafo lista cada instantánea de topología que el watcher reportó: esa es la topología que el watcher envió.
Controles de Topolograph OSPF/IS-IS Real-Time Monitoring para el grafo 07Sep2026_06h49m43s_6_hosts: el selector de grafo, la ventana de tiempo From/To, los interruptores de nivel L1 y L2 ambos activados, los interruptores New/Old Subnets, Up/Down Links y Changed metric, y Find logs. El panel Watchers Status muestra "No watchers registered yet" porque el watcher de containerlab envia topologia pero no heartbeats.

Peticion 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

07Sep2026_06h49m43s_6_hosts isis {'count': 6}

5. Cambio de coste en un enlace punto a punto

Cambia router2 eth1 hacia router3. Las metricas IS-IS son dirigidas, asi que la metrica inversa de router3 a router2 no debe describirse como el mismo escalar. router2 eth1 no tiene un isis metric explicito, asi que parte del valor por defecto de wide-metric, 10. router2-router3 es un circuito Level-1-2, asi que el cambio se anuncia en ambos niveles.

Comando

sudo docker exec clab-isis01-router2 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'isis metric 222'

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

Registro del Watcher Las lineas metric y network del cambio y su reversion, en L1 y L2 L1 + L2

CSV de Watcher

# router2: interface eth1 / isis metric 222
2026-09-07T06:52:15.035Z,lab-isis01,1,metric,router3,changed,old_cost:10,new_cost:222,router2,07Sep2026_06h49m43s_6_hosts,49.0001,65100,,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:52:15.037Z,lab-isis01,1,network,192.168.23.0/24,changed,old_cost:10,new_cost:222,router2,07Sep2026_06h49m43s_6_hosts,49.0001,65100,internal,0,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:52:15.045Z,lab-isis01,2,metric,router3,changed,old_cost:10,new_cost:222,router2,07Sep2026_06h49m43s_6_hosts,49.0001,65100,,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
# rollback (isis metric 10):
2026-09-07T06:52:37.514Z,lab-isis01,1,metric,router3,changed,old_cost:222,new_cost:10,router2,07Sep2026_06h49m43s_6_hosts,49.0001,65100,,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:52:37.526Z,lab-isis01,2,metric,router3,changed,old_cost:222,new_cost:10,router2,07Sep2026_06h49m43s_6_hosts,49.0001,65100,,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
Monitoreo El cambio de metrica 10 -> 222 en el flujo de eventos

En OSPF/IS-IS Real-Time Monitoring, elige 07Sep2026_06h49m43s_6_hosts en Choose the graph, define la ventana From/To en torno a las 06:52 UTC, activa L1 y L2 y pulsa Find logs. Con Changed metric activado, el flujo muestra object router3, detected by router2, 10 -> 222 - solo la direccion router2 -> router3, una vez para L1 y otra para L2. La direccion inversa no aparece.

Verificacion con SDK get_adjacency_events y get_network_events devuelven el mismo objeto y los mismos costes 2 eventos

Peticion del SDK

adj = graph.events.get_adjacency_events(
    start_time="2026-09-07T06:52:14Z", end_time="2026-09-07T06:52:20Z")
net = graph.events.get_network_events(
    start_time="2026-09-07T06:52:14Z", end_time="2026-09-07T06:52:20Z")
for e in adj["adjacency_cost_change_events"]:
    print(e.event_object, e.event_detected_by, e.old_cost, "->", e.new_cost, "L" + str(e.level_number))
for e in net["network_cost_change_events"]:
    print(e.event_object, e.old_cost, "->", e.new_cost, "L" + str(e.level_number))

Salida del SDK

router3 router2 10 -> 222 L1
router3 router2 10 -> 222 L2
3ffe::192:168:23:2/127 10 -> 222 L1
192.168.23.0/24 10 -> 222 L1
3ffe::192:168:23:2/127 10 -> 222 L2
192.168.23.0/24 10 -> 222 L2

El evento metric nombra la direccion router2 -> router3 (event_object router3, event_detected_by router2), 10 -> 222, en ambos niveles; las subredes conectadas IPv4 e IPv6 llevan el mismo cambio. La direccion inversa no aparece.

Pregunta al agente Una pregunta generica de incidente sobre router2

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

Una respuesta valida nombra la direccion router2 -> router3 y ambos valores de metrica (10 y 222) sin que la pregunta mencione coste o metrica, y no afirma que la direccion inversa router3 -> router2 cambio.

Reversion: Ejecuta isis metric 10 (o no isis metric) en router2 eth1 y confirma los eventos inversos 222 -> 10 metric y network.

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

Ejecuta cada experimento de prefijo por separado. A diferencia de OSPF, IS-IS anuncia un loopback con la mascara con que esta configurado y lo cuesta con la metrica de la interfaz: un /24 sigue siendo /24 con coste 10, no se colapsa a una ruta host /32. router6 es solo Level-2, asi que sus prefijos aparecen solo en L2.

  1. 6a. En router2, interface lo / ip address 192.168.123.1/24; observa 192.168.123.0/24 up y coste -1 -> 10 en L1 y L2.
  2. 6b. En router6, interface lo / ip address 10.10.36.6/24; observa 10.10.36.0/24 up y coste -1 -> 10 en L2.
  3. 6c. En router6, no ip route 6.6.6.6/32 192.168.36.3; observa 6.6.6.6/32 down y coste 11 -> -1 en L2. FRR la redistribuye en IS-IS sin el bit external, asi que el watcher la marca como internal.

Comando

sudo docker exec clab-isis01-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 del Watcher Una linea up/down y una changed por sub-ejercicio 3 prefijos

CSV de Watcher

# 6a router2: interface lo / ip address 192.168.123.1/24
2026-09-07T06:52:52.074Z,lab-isis01,1,network,192.168.123.0/24,up,router2,07Sep2026_06h49m43s_6_hosts,49.0001,65100,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:52:52.075Z,lab-isis01,1,network,192.168.123.0/24,changed,old_cost:-1,new_cost:10,router2,07Sep2026_06h49m43s_6_hosts,49.0001,65100,internal,0,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
# 6b router6: interface lo / ip address 10.10.36.6/24
2026-09-07T06:53:39.099Z,lab-isis01,2,network,10.10.36.0/24,up,router6,07Sep2026_06h49m43s_6_hosts,49.0001,65100,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:53:39.099Z,lab-isis01,2,network,10.10.36.0/24,changed,old_cost:-1,new_cost:10,router6,07Sep2026_06h49m43s_6_hosts,49.0001,65100,internal,0,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
# 6c router6: no ip route 6.6.6.6/32 192.168.36.3
2026-09-07T06:54:14.533Z,lab-isis01,2,network,6.6.6.6/32,down,router6,07Sep2026_06h49m43s_6_hosts,49.0001,65100,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:54:14.533Z,lab-isis01,2,network,6.6.6.6/32,changed,old_cost:11,new_cost:-1,router6,07Sep2026_06h49m43s_6_hosts,49.0001,65100,internal,0,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
Monitoreo Los prefijos nuevos y retirados en el flujo

En OSPF/IS-IS Real-Time Monitoring, elige este grafo, define la ventana en torno a 06:52-06:55 UTC, activa L1 y L2 y pulsa Find logs. Con New/Old Subnets activado, 192.168.123.0/24 y 10.10.36.0/24 aparecen como anadidos y 6.6.6.6/32 como retirado.

Verificacion con SDK get_network_events, un evento changed por sub-ejercicio 3 eventos

Peticion del SDK

for start, end in [("2026-09-07T06:52:50Z", "2026-09-07T06:52:55Z"),
                   ("2026-09-07T06:53:37Z", "2026-09-07T06:53:42Z"),
                   ("2026-09-07T06:54:12Z", "2026-09-07T06:54:17Z")]:
    net = graph.events.get_network_events(start_time=start, end_time=end)
    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}", "L" + str(e.level_number), e.subnet_type)

Salida del SDK

192.168.123.0/24 changed router2 -1 -> 10 L1 internal
192.168.123.0/24 changed router2 -1 -> 10 L2 internal
10.10.36.0/24 changed router6 -1 -> 10 L2 internal
6.6.6.6/32 changed router6 11 -> -1 L2 internal

El /24 conserva su mascara: no hay colapso a /32. La disponibilidad es una linea up/down que el forwarder descarta; el cambio de coste es el evento changed que devuelve el SDK. El loopback de router2 se ve en L1 y L2, el de router6 solo en L2, y el 6.6.6.6/32 redistribuido se marca como internal.

Reversion: 6a: no ip address 192.168.123.1/24 en router2 interface lo. 6b: no ip address 10.10.36.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

Deshabilita router2 eth1, inspecciona el conjunto de eventos correlacionados y luego restaura la interfaz con no shutdown. Como router2-router3 es Level-1-2, cada linea aparece una vez para L1 y otra para L2.

Comando

# down
sudo docker exec clab-isis01-router2 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'shutdown'
# recovery
sudo docker exec clab-isis01-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 del Watcher El conjunto down de L1 y el conjunto de recuperacion de L1 para el enlace router2-router3 down + up

CSV de Watcher

# router2: interface eth1 / shutdown
2026-09-07T06:55:14.754Z,lab-isis01,1,host,router2,down,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,192.168.23.2,192.168.23.1,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:55:14.756Z,lab-isis01,1,metric,router2,changed,old_cost:10,new_cost:-1,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,192.168.23.2,192.168.23.1,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:55:14.760Z,lab-isis01,1,metric,router3,changed,old_cost:10,new_cost:-1,router2,07Sep2026_06h49m43s_6_hosts,49.0001,65100,,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:55:14.761Z,lab-isis01,1,network,192.168.23.0/24,changed,old_cost:10,new_cost:-1,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,internal,0,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
# router2: interface eth1 / no shutdown
2026-09-07T06:55:39.545Z,lab-isis01,1,metric,router3,changed,old_cost:-1,new_cost:10,router2,07Sep2026_06h49m43s_6_hosts,49.0001,65100,,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:55:39.607Z,lab-isis01,1,metric,router2,changed,old_cost:-1,new_cost:10,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,192.168.23.2,192.168.23.1,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
Monitoreo La caida como una sola oleada en el flujo

En OSPF/IS-IS Real-Time Monitoring, elige este grafo, define la ventana en torno a 06:55 UTC, activa L1 y L2 y pulsa Find logs. Con Up/Down Links activado, router2 y router3 muestran cada uno su lado del enlace yendo a -1 y volviendo, y 192.168.23.0/24 queda inalcanzable y regresa - dos veces, una por nivel.

Verificacion con SDK get_adjacency_events devuelve los movimientos down/up emparejados 4 movimientos

Peticion del SDK

down = graph.events.get_adjacency_events(
    start_time="2026-09-07T06:55:14Z", end_time="2026-09-07T06:55:16Z")
for e in down["all_host_up_down_events"]:
    print(e.event_object, "detected_by", e.event_detected_by,
          f"{e.old_cost} -> {e.new_cost}", "L" + str(e.level_number))

Salida del SDK

router2 detected_by router3 10 -> -1 L1
router3 detected_by router2 10 -> -1 L1
router2 detected_by router3 10 -> -1 L2
router3 detected_by router2 10 -> -1 L2

host router2 down detectado por router3, ambas metricas dirigidas a -1, 192.168.23.0/24 down - en L1 y L2; luego la recuperacion espejo. En la recuperacion el watcher tambien registra un flap node attr:attached en router2, que Topolograph aun no ingiere.

Pregunta al agente Una pregunta generica de incidente sobre la red

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

Respuesta capturada (Qwen; la redaccion varia entre ejecuciones)

In the last 30 minutes the IS-IS domain (area 49.0001, AS 65100) had 7 event waves detected by watcher lab-isis01, starting at 06:55:15 UTC. Every device that went down recovered within the window.

06:55:15 - router2 and router3 each lost the adjacency between them, at L1 and L2 (router2 detected by router3, router3 detected by router2).

06:55:40 - both routers restored that adjacency at L1 and L2, followed by a few repeated up notifications through 06:56:33.

06:57:23 - router6 lost its L2 adjacency to router3; 06:57:56 - router6 and router3 restored it.

In short: the router2-router3 link dropped at 06:55:15 and came back at 06:55:40; the router3-router6 link dropped at 06:57:23 and recovered at 06:57:56 - both fully converged.

La respuesta nombra la adyacencia caida (router2 - router3), que router3 detecto la perdida de router2 y viceversa, ambas metricas en -1 y la recuperacion - los mismos hechos que las lineas CSV de arriba, a partir de una pregunta que nunca dice "adjacency" ni "failure". Las lineas de router6 son el ejercicio de transito de mas abajo, capturado por la misma ventana de 30 minutos.

Reversion: no shutdown en router2 eth1 restaura la interfaz; espera los eventos de recuperacion host, network y metric en ambos niveles.

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

router6 eth1 se enfrenta a router3 en un circuito de difusion (LAN). router6 lleva isis priority 100 frente a 64 de router3, asi que router6 es el DIS y origina el LSP de pseudonodo. El circuito es solo Level-2, asi que cada linea es L2. router6 eth1 no tiene un isis metric explicito, asi que la base es el valor por defecto 10.

Comando

# cost
sudo docker exec clab-isis01-router6 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'isis metric 66'
# then, separately: shutdown, then no shutdown
sudo docker exec clab-isis01-router6 vtysh \
  -c 'conf t' -c 'interface eth1' -c 'shutdown'
sudo docker exec clab-isis01-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 del Watcher El cambio de coste L2 con sus efectos secundarios en network, mas el par shutdown/recuperacion coste + up/down

CSV de Watcher

# router6: interface eth1 / isis metric 66   (rollback: isis metric 10)
2026-09-07T06:56:47.139Z,lab-isis01,2,network,192.168.36.0/24,changed,old_cost:10,new_cost:66,router6,07Sep2026_06h49m43s_6_hosts,49.0001,65100,internal,0,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:56:47.140Z,lab-isis01,2,metric,router3,changed,old_cost:10,new_cost:66,router6,07Sep2026_06h49m43s_6_hosts,49.0001,65100,,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:57:04.561Z,lab-isis01,2,metric,router3,changed,old_cost:66,new_cost:10,router6,07Sep2026_06h49m43s_6_hosts,49.0001,65100,,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
# router6: interface eth1 / shutdown
2026-09-07T06:57:22.037Z,lab-isis01,2,network,192.168.36.0/24,changed,old_cost:10,new_cost:-1,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,internal,0,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:57:22.055Z,lab-isis01,2,host,router6,down,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,192.168.36.3,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:57:22.055Z,lab-isis01,2,metric,router6,changed,old_cost:10,new_cost:-1,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,192.168.36.3,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
# router6: interface eth1 / no shutdown
2026-09-07T06:57:55.962Z,lab-isis01,2,host,router6,up,router3,07Sep2026_06h49m43s_6_hosts,49.0001,65100,192.168.36.3,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
2026-09-07T06:57:55.973Z,lab-isis01,2,metric,router3,changed,old_cost:-1,new_cost:66,router6,07Sep2026_06h49m43s_6_hosts,49.0001,65100,,,e50b9d98-aa86-11f1-92b0-46ed252a638b,0100.1001.0001
Monitoreo El cambio de coste de transito y la caida de router6, solo L2

En OSPF/IS-IS Real-Time Monitoring, elige este grafo, define la ventana en torno a 06:56-06:58 UTC, activa L2 y pulsa Find logs. El object del evento metric es router3 con event_detected_by router6, y el cambio es solo L2 - el circuito es level-2-only. En el shutdown el flujo muestra host router6 down y 192.168.36.0/24 inalcanzable, luego la recuperacion.

Verificacion con SDK get_adjacency_events para el coste de transito y el shutdown/recuperacion solo L2

Peticion del SDK

cost = graph.events.get_adjacency_events(
    start_time="2026-09-07T06:56:46Z", end_time="2026-09-07T06:56:49Z")
for e in cost["adjacency_cost_change_events"]:
    print("cost", e.event_object, e.event_detected_by, f"{e.old_cost} -> {e.new_cost}", "L" + str(e.level_number))
flap = graph.events.get_adjacency_events(
    start_time="2026-09-07T06:57:21Z", end_time="2026-09-07T06:58:00Z")
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}", "L" + str(e.level_number))

Salida del SDK

cost router3 router6 10 -> 66 L2
updown router6 router3 10 -> -1 L2
updown router6 router3 -1 -> 10 L2
updown router3 router6 -1 -> 10 L2

En el segmento de difusion el evento metric sigue nombrando al vecino (router3), detectado por router6, y solo en L2; el cambio de metrica tambien mueve 192.168.36.0/24 y las dos /127 IPv6. El shutdown es host router6 down en L2, luego la recuperacion.

Pregunta al agente Una pregunta generica de incidente sobre router6

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

Una respuesta valida nombra la metrica de transito router6 -> router3 moviendose 10 -> 66 y de vuelta, luego la conexion de router6 cayendo (metrica -1 en L2) y recuperandose, sin que la pregunta mencione coste, DIS ni shutdown.

Reversion: isis metric 10 (o no isis metric) en router6 eth1 restaura la base 10; no shutdown restaura la adyacencia. Confirma los eventos metric inversos.

Topolograph 2.69.4 📣 ¡Únete a la comunidad!