Exploitation pratique d’OSPF

Manuel pratique OSPF Watcher

Effectuez un seul changement contrôlé à la fois, prédisez son effet, puis vérifiez le même fait depuis l’événement Watcher jusqu’à Topolograph.

Démarrer le manuel

Liens utiles : OSPF Watcher - dépôt et guide de déploiement · Topolograph

1. Comment fonctionne ce manuel

Pour chaque exercice : effectuez un changement, prédisez le résultat OSPF, observez l’événement Watcher, puis retrouvez le même fait dans Topolograph Monitoring, dans le SDK et - pour les exercices de corrélation - dans la réponse de l’agent. Restaurez le laboratoire avant l’exercice indépendant suivant.

  1. La ligne CSV de Watcher est l’événement source déterministe.
  2. Monitoring et le SDK prouvent que l’événement a été ingéré et qu’il est interrogeable.
  3. L’agent sert uniquement à corréler plusieurs événements en un seul incident, jamais à remplacer la ligne source.

2. Mise en route et validation du laboratoire à six routeurs

Lancez la topologie publique ospf01 basée sur GRE du dépôt OSPF Watcher.

Commande

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
Vérifications requises Faits à confirmer avant de continuer
  • Les six conteneurs de routeur et le watcher sont actifs : docker ps --filter name=clab-ospf01 liste clab-ospf01-router1..6 et clab-ospf01-ospf-watcher, tous en State=Up.
  • Le watcher possède la LSDB et capture le trafic : docker logs clab-ospf01-ospf-watcher affiche une ligne "OSPF LSDB received" et "Start sniffing on interface: eth1".
  • Les adjacences sont en Full : docker exec clab-ospf01-router1 vtysh -c 'show ip ospf neighbor' liste chaque voisin à l’état Full ; le premier graphe Topolograph contient alors six routeurs.

Retour arrière : Quand vous avez fini le manuel, supprimez le laboratoire avec sudo clab destroy --topo ospf01.clab.yml --cleanup depuis containerlab/ospf01/.

3. Format de l'enregistrement d'événement réseau

Le manuel utilise trois familles d’événements : host, metric et network. Lisez event_object comme l’objet modifié, event_status comme la transition et event_detected_by comme le routeur qui annonce ou détecte. graph_time est l’étiquette propre du watcher pour l’exécution et sélectionne le graphe Topolograph.

Lisez la ligne metric ci-dessus comme une seule phrase : à 2026-09-06T13:11:04Z, le watcher ospfwatcher-demo a vu le routeur 10.10.10.2 réannoncer son lien vers 10.10.10.3 avec le coût passé de 10 à 222, sur l’interface locale 192.168.23.1, dans l’aire 0.0.0.0 / AS 12345. La ligne network juste après porte le même passage 10 -> 222 pour le sous-réseau 192.168.23.0/24 sur ce lien.

  1. Champs dans l’ordre : watcher_time, watcher_name, event_name, event_object, event_status, [champs de coût], event_detected_by, graph_time, area_num, asn, [champs de type], sesid, srcid.
  2. area_num 0.0.0.0 et asn 12345 identifient le domaine de routage ; sesid est la session du watcher, srcid l’id du routeur source.

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. D'où viennent les événements

Un changement OSPF produit une ligne CSV de Watcher. Fluent Bit la transmet à Topolograph, qui la stocke et l’expose via la page Monitoring, l’API d’événements et le SDK. Chaque exercice ci-dessous vérifie le même fait à tous les niveaux dont vous disposez.

  1. Journal Watcher d’ospf01 -> analyseur CSV Fluent Bit -> ingestion Topolograph -> page Monitoring + API d’événements -> SDK Topolograph
  2. Page Monitoring : OSPF/IS-IS Real-Time Monitoring. Choisissez le graphe par son horodatage, définissez une fenêtre temporelle, cliquez sur Find logs ; les bascules filtrent les événements de sous-réseau / lien / métrique.
  3. Le sélecteur de graphes de cette page liste chaque instantané de topologie rapporté par le watcher, du plus récent au plus ancien - c'est la topologie envoyée par le watcher.
Page Topolograph OSPF/IS-IS Real-Time Monitoring pour le graphe 06Sep2026_12h31m41s : sélecteur de graphes et Find logs, le flux d’événements affichant les étiquettes de métrique 10 -> 222 et 222 -> 10 et 192.168.23.0/24, et en dessous le graphe de topologie avec les six routeurs et les poids des liens.

Requête du 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)

Sortie du SDK

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

5. Changement de coût sur un lien point-to-point

Modifiez router2 eth1 vers router3. Les coûts OSPF sont orientés : le coût inverse de router3 vers router2 ne doit donc pas être décrit comme le même scalaire.

Commande

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

Vérifiez le changement. Ouvrez chaque source disponible dans votre environnement et comparez-la aux exemples ci-dessous.

Journal de Watcher Les lignes metric et network du changement et de son retour arrière 4 lignes

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
Supervision Le changement de métrique 10 -> 222 dans le flux d’événements

Dans OSPF/IS-IS Real-Time Monitoring, choisissez ce graphe dans Choose the graph, réglez la fenêtre From/To autour de 13:11 UTC et cliquez sur Find logs. Avec Changed metric activé, le flux affiche une ligne : object 10.10.10.3, detected by 10.10.10.2, 10 -> 222 - uniquement le sens router2 -> router3. Le sens inverse n’apparaît pas. Le graphe de topologie sous le flux redessine le lien router2-router3 avec le nouveau poids.

Vérification via le SDK get_adjacency_events et get_network_events renvoient le même objet et les mêmes coûts 2 événements

Requête du 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)

Sortie du 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

L’événement metric nomme le sens router2 -> router3 (event_object 10.10.10.3, event_detected_by 10.10.10.2), coût 10 -> 222 ; 192.168.23.0/24 porte le même changement. Le sens inverse est absent des deux listes.

Interroger l’agent Une question d’incident générique sur router2

Requête : What happened with router2 in the last 10 minutes?

Réponse capturée (Qwen ; la formulation varie d’une exécution à l’autre)

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.

Observé lors de cette exécution : router2 a réannoncé son lien vers router3 au coût 222 (auparavant 10) ; le sens inverse router3 -> router2 n’a pas changé.

Retour arrière : Exécutez no ip ospf cost 222 et confirmez les événements inverses metric et network 222 -> 10.

6. Détection des événements de préfixes internes et externes

Exécutez chaque expérience de préfixe indépendamment. Un loopback OSPF configuré avec un masque /24 est annoncé comme route d’hôte /32 par ce laboratoire.

  1. 6a. Ajoutez 192.168.123.1/24 au loopback de router2 ; observez 192.168.123.1/32 up et coût -1 -> 0 (internal).
  2. 6b. Ajoutez 10.10.136.6/24 au loopback de router6 ; observez 10.10.136.6/32 up et coût -1 -> 0 (internal).
  3. 6c. Supprimez la route statique 6.6.6.6/32 sur router6 ; observez 6.6.6.6/32 down et coût 11 -> -1 (external, type 2).

Commande

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

Vérifiez le changement. Ouvrez chaque source disponible dans votre environnement et comparez-la aux exemples ci-dessous.

Journal de Watcher Une ligne up/down et une ligne changed par sous-exercice 6 lignes

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
Supervision Les préfixes nouveaux et retirés dans le flux

Dans OSPF/IS-IS Real-Time Monitoring, choisissez ce graphe, réglez la fenêtre From/To autour de 13:12 UTC et cliquez sur Find logs. Avec New/Old Subnets activé, 192.168.123.1/32 et 10.10.136.6/32 apparaissent comme ajoutés et 6.6.6.6/32 comme retiré ; le graphe de topologie sous le flux ajoute les deux routes d’hôte et retire celle qui est retirée.

Vérification via le SDK get_network_events, un événement changed par sous-exercice 3 événements

Requête du 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)

Sortie du 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 sur le loopback est annoncé comme /32. La disponibilité est un événement up/down ; le changement de coût est un événement changed. La route retirée est external / type 2, les deux loopbacks internal / 0.

Interroger l’agent Une question générique sur les changements de préfixes

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

Réponse capturée (Qwen ; la formulation varie d’une exécution à l’autre)

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.

Observé lors de cette exécution : 192.168.123.1/32 et 10.10.136.6/32 ont été ajoutés comme routes d’hôte internes ; 6.6.6.6/32 (external, type 2) a été retiré.

Retour arrière : 6a : no ip address 192.168.123.1/24 sur router2 interface lo. 6b : no ip address 10.10.136.6/24 sur router6 interface lo. 6c : ip route 6.6.6.6/32 192.168.36.3 sur router6. Confirmez l'evenement inverse apres chacun.

7. Détection d'une perte de connectivité et de son rétablissement

Désactivez router2 eth1, inspectez l’ensemble d’événements corrélés, puis restaurez l’interface avec no shutdown.

Commande

# 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'

Vérifiez le changement. Ouvrez chaque source disponible dans votre environnement et comparez-la aux exemples ci-dessous.

Journal de Watcher L’ensemble de panne et l’ensemble de rétablissement du lien 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
Supervision La panne comme une seule vague dans le flux

Dans OSPF/IS-IS Real-Time Monitoring, choisissez ce graphe, réglez la fenêtre From/To autour de 13:04 UTC et cliquez sur Find logs. Avec Up/Down Links activé, 10.10.10.2 passe down puis up, les deux métriques orientées passent à -1 et reviennent, et 192.168.23.0/24 devient injoignable puis revient ; le graphe de topologie sous le flux retire le lien router2-router3 puis le restaure.

Vérification via le SDK get_adjacency_events renvoie les mouvements appariés down/up 4 mouvements

Requête du 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])

Sortie du 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 détecté par 10.10.10.3, les deux métriques orientées à -1, 192.168.23.0/24 down ; puis le rétablissement en miroir.

Interroger l’agent Une question d’incident générique sur le réseau

Requête : What happened in the network in the last 30 minutes?

Réponse capturée (Qwen ; la formulation varie d’une exécution à l’autre)

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 réponse nomme l’adjacence en panne (10.10.10.2 - 10.10.10.3) détectée par 10.10.10.3, les deux métriques à -1, et le rétablissement - les mêmes faits que les lignes CSV ci-dessus, à partir d’une question qui ne dit jamais 'adjacency' ni 'failure'.

Retour arrière : no shutdown restaure l’interface ; attendez les événements de rétablissement host, network et metric.

8. Compte rendu d'un segment de transit broadcast

Utilisez router6 eth1 pour comparer le rapport d’un segment de transit avec le cas point-to-point.

Commande

# 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'

Vérifiez le changement. Ouvrez chaque source disponible dans votre environnement et comparez-la aux exemples ci-dessous.

Journal de Watcher Le changement de coût nomme l’id du routeur distant, et la paire coupure/rétablissement 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
Supervision Le changement de coût de transit et la panne de router6

Dans OSPF/IS-IS Real-Time Monitoring, choisissez ce graphe, réglez la fenêtre From/To autour de 13:13-13:14 UTC et cliquez sur Find logs. L’object de l’événement metric est 10.10.10.3 (l’id du routeur distant) avec event_detected_by 10.10.10.6 - contrairement à un lien point-to-point, où l’object est le voisin. Le graphe de topologie sous le flux recalcule les poids, puis retire et restaure le rattachement de router6.

Vérification via le SDK get_adjacency_events pour le coût de transit et la coupure/rétablissement 4 mouvements

Requête du 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])

Sortie du 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

Sur un segment de transit, l’événement metric nomme l’id du routeur distant (10.10.10.3), détecté par router6 ; la coupure est host 10.10.10.6 down, puis le rétablissement.

Interroger l’agent Une question d’incident générique sur router6

Requête : What happened on router6 in the last 20 minutes?

Réponse capturée (Qwen ; la formulation varie d’une exécution à l’autre)

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.

Observé lors de cette exécution : le coût de transit router6 -> router3 est passé de 6 -> 66 puis revenu, puis le rattachement de router6 est tombé (metric -1) et s’est rétabli.

Retour arrière : ip ospf cost 6 restaure la référence ; no shutdown restaure l’adjacence. Confirmez les événements metric inverses.

Topolograph 2.69.4 📣 Rejoignez la communauté !