Cause de la charge CPU élevée sur le moteur de routage du routeur d'appairage Juniper

Récemment, l'utilisation du processeur du moteur de routage sur deux de nos routeurs d'appairage Juniper est passée de ~ 10-20% de charge moyenne à 80 +%. J'essaie de comprendre ce qui cause cela (et comment réduire cette charge élevée).

Quelques informations sur les routeurs: les deux exécutent la même version JunOS, les deux sont connectés aux deux mêmes LAN IXP homologues et ont un grand nombre (plusieurs centaines) de sessions IPv4 et IPv6 (presque identiques). Les deux routeurs ont une connexion à un fournisseur de transit IP différent et sont connectés de la même manière au reste de notre réseau. La charge CPU des moteurs de routage n'est pas plate sur 80 +%, il y a des baisses à des niveaux normaux pendant des minutes à des heures, mais ces baisses ne sont pas si fréquentes.

Choses que j'ai vérifiées:

• aucune modification de configuration n'a été effectuée au moment où l'augmentation a commencé
• il n'y a pas d'augmentation du trafic non monodiffusion dirigé vers le plan de contrôle
• il n'y a pas de changement (substantiel) dans la quantité de trafic acheminé (même si une augmentation ne devrait pas avoir d'importance)
• show system processes summaryindique que le rpdprocessus est à l'origine de la charge élevée du processeur
• il n'y a pas de pairs BGP qui claquent rapidement provoquant une grande quantité de changements BGP

Une explication possible que je peux trouver est un homologue (ou plus d'un) sur l'un des deux routeurs de l'IXP sont connectés pour envoyer un grand nombre de mises à jour BGP. Actuellement, je n'ai que des statistiques sur le nombre de messages BGP pour mes sessions de transit (ne montrant aucune activité anormale) et avec plusieurs centaines de sessions BGP sur les réseaux locaux homologues, il n'est pas si facile de repérer les sessions problématiques si je devais créer des graphiques pour toutes les sessions.

Mes questions sont:

• y a-t-il d'autres choses que je devrais vérifier pour trouver la cause de cette augmentation de la charge CPU sur les moteurs de routage?
• comment savoir facilement quelles sessions sont à l'origine de ces problèmes (si mon hypothèse est juste)? L'activation des options de trace BGP génère d'énormes quantités de données, mais je ne sais pas si cela me donne de véritables informations.

Il peut y avoir des informations utiles pour vous au Centre de connaissances Juniper .

Si RPD consomme beaucoup de CPU, effectuez les vérifications suivantes et vérifiez les paramètres suivants:

• Vérifiez les interfaces: vérifiez si des interfaces claquent sur le routeur. Ceci peut être vérifié en regardant la sortie des messages de show log et des commandes étendues de show interfaces ge-x / y / z. Dépannez pourquoi ils s'agitent; si possible, vous pouvez envisager d'activer le temps d'attente pour la liaison vers le haut et vers le bas.

• Vérifiez s'il y a des messages d'erreur syslog liés aux interfaces ou à tout FPC / PIC, en regardant la sortie des messages du journal d'exposition.

• Vérifiez les routes: vérifiez le nombre total de routes qui sont apprises par le routeur en regardant la sortie du résumé de la route. Vérifiez s'il a atteint la limite maximale.

• Vérifiez les tâches RPD: Identifiez ce qui maintient le processus occupé. Cela peut être vérifié en activant d'abord la définition de la comptabilité des tâches. Important: cela peut augmenter la charge du processeur et son utilisation; n'oubliez donc pas de le désactiver lorsque vous avez terminé avec la collection de sortie requise. Exécutez ensuite show task accounting et recherchez le thread avec le temps CPU élevé:

  user@router> show task accounting
  Task                       Started    User Time  System Time  Longest Run
  Scheduler                   146051        1.085        0.090        0.000
  Memory                           1        0.000            0        0.000  <omit>
  BGP.128.0.0.4+179              268       13.975        0.087        0.328
  BGP.0.0.0.0+179      18375163 1w5d 23:16:57.823    48:52.877        0.142
  BGP RT Background              134        8.826        0.023        0.099
  

Découvrez pourquoi un thread, qui est lié à un préfixe ou à un protocole particulier, utilise un processeur élevé.

• Vous pouvez également vérifier si les routes oscillent (ou les churns de route) en regardant la sortie de la commande shell: %rtsockmon –t

• Vérifiez la mémoire RPD. Parfois, une utilisation élevée de la mémoire peut entraîner indirectement un CPU élevé.

Je sais que ce fil est ancien mais pour être complet:

Si le CPU élevé se produit au hasard et que vous n'êtes pas en mesure de déterminer le processus à l'origine de cela, nous pouvons créer le script ci-dessous.

Avec ce script, nous allons capturer le processus étendu lorsqu'un processus augmente plus que le seuil normal ou attendu, cela ne devrait perturber aucun trafic mais un MW est toujours recommandé. Cependant, je vois que vous l'avez limité à RPD.

snmp {
    health-monitor {
        interval 30;
        rising-threshold 60;
        falling-threshold 50;
    }
}

event-options {
    policy MONITOR-CPU {
        events snmpd_health_mon_thresh_cross;
        attributes-match {
            snmpd_health_mon_thresh_cross.event-name matches "Health Monitor.+CPU.+rising";
        }
        then {
            execute-commands {
                commands {
                    "show system processes extensive";
                }
                output-filename cpu-processes;
                destination local-flash;
                output-format text;
            }
        }                               
    }
    destinations {
        local-flash {
            archive-sites {
                /var/tmp;
            }
        }
    }
}

DISPLAY SET OUTPUT>

set snmp health-monitor interval 30
set snmp health-monitor rising-threshold 60
set snmp health-monitor falling-threshold 50
set event-options policy MONITOR-CPU events snmpd_health_mon_thresh_cross
set event-options policy MONITOR-CPU attributes-match snmpd_health_mon_thresh_cross.event-name matches "Health Monitor.+CPU.+rising"
set event-options policy MONITOR-CPU then execute-commands commands "show system processes extensive"
set event-options policy MONITOR-CPU then execute-commands output-filename cpu-processes
set event-options policy MONITOR-CPU then execute-commands destination local-flash
set event-options policy MONITOR-CPU then execute-commands output-format text
set event-options destinations local-flash archive-sites /var/tmp

Avez-vous également vérifié si des messages ddos ​​ont été signalés? Vous pouvez exécuter les commandes suivantes:

show ddos-protection protocols statistics brief
show ddos-protection statistics
show ddos-protection version

Ensuite, en fonction de ce que vous voyez, il peut être réduit, par exemple:

show ddos-protection protocols ttl statistics
show ddos-protection protocols ttl violations
show ddos-protection protocols ttl flow-detection detail  */*this cm needs prior config*/*

Juniper possède également une liste de collecte pour ce type de problèmes sous KB22637

Commandes CLI CPU élevées

set cli timestamp
show chassis routing-engine (multiple snapshots, atleast 5)
show system processes extensive (multiple snapshots atleast 5)
show system users
show system connections
show system statistics

Activez la comptabilité des tâches et collectez la sortie détaillée de la comptabilité des tâches (trois fois avec un intervalle de 30 secondes). N'oubliez pas de l'éteindre une fois terminé.

set task accounting on 
show task accounting detail
set task accounting off

show task memory detail
show task memeory summary
show task io
show task history
show task statistics
show task job
show task jobs
show krt queue
show krt state

Journaux

Archiver / var / log comme spécifié à l'étape 1 ci-dessus Traceoptions

user@router# show routing-options 
traceoptions { 
file routing-trace size 10m files 20 world-readable; 
flag task; 
flag state; 
flag timer; 
}

De plus, si vous utilisez une ancienne version qui était sujette aux bogues, vous voudrez peut-être vérifier la durée de vie du code:

http://www.juniper.net/support/eol/junos.html

Un autre point à mentionner qui pourrait être une attaque vectorielle n'est pas d'avoir protégé votre RE contre le trafic d'exception indésirable. Assurez-vous d'avoir un filtre pare-feu sous le bouclage.

J'ai vu dans le passé des scripts sur le routeur provoquant un processeur élevé, je ne sais pas si rpd est venu à mon avis, mais c'est quelque chose que vous ne voudrez peut-être pas ignorer.

Si vous voyez dans les journaux de nombreux hits avec RPD_MPLS_PATH_BANDWIDTH_CHANGE, vous utilisez peut-être un intervalle de réglage très agressif

Vérifiez toutes les gouttes sur "afficher la file d'attente du système: il s'agit de la file d'attente du noyau, certains indices peuvent apparaître.