Après redémarrage ça serait étonnant que le problème persiste par
souvenir.
Sinon une autre idée: snmp. Peut-être as-tu beaucoup de requêtes snmp ?
Même si le process snmpd consomme peu de CPU, ça ne veut pas dire que le
sous-sytème (tfeb) qu'il interroge lui n'est pas à fond, voir même des
requêtes type walk de tables mac et de neighbors.
Essaye de désactiver snmpd pour voir si ça améliore les choses.
Parenthèse mise à part, un des inconvénients d'OSPF est que si la
topologie change même au fond de l'arbre bah tous les équipements
recalculent toute l'arborescence.
Par exemple lorsqu'une interface tombe chez un de tes clients, ton MX80
et tous les routeurs qui partagent la même area vont tout recalculer,
alors que cette interface est côté LAN de ce client et ne concerne en
rien ton réseau et le service que tu fournis.
Et si cette interface bagotte toute la journée, ton OSPF va travailler
toute la journée :/
Jérôme
Le 13/02/2026 à 13:36, Aurelien Dieval via frnog a écrit :
Merci pour la piste, mon avis est mitigé sur le sujet car au niveau transit, on
communique en effet en BGP mais on ne reçoit qu'une default.
Par contre, niveau collecte, les routeurs sont en OSPF. Lors d'une modification
de la configuration OSPF sur un routeur collecté j'ai constaté à peu près au
même moment un pic de latence mais je pris ça pour une coincidence.
D'autant que lors de la grosse crise de jeudi dernier, nous avons à un moment
donné tout débranché du MX80, redémarré, rebranché uniquement le management et
le transit et les ping vers et depuis internet étaient toujours perturbés, de
la même façon faisant le yoyo jusqu'à 2000ms.
Ce pourrait-il que ce soit un reliquat de perturbation même après redémarrage,
se pourrait-il qu'il ait gardé en mémoire un état des tables de routage et les
mette à jour n'ayant plus de communication ospf.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
