Ursache für die hohe CPU-Auslastung der Routing-Engine des Juniper Peering Routers

Kürzlich hat sich die CPU-Auslastung der Routing-Engine auf zwei unserer Juniper-Peering-Router von ~ 10-20% Durchschnittslast auf über 80% erhöht. Ich versuche herauszufinden, was das verursacht (und wie man diese hohe Last wieder runterholt).

Einige Informationen zu den Routern: Beide verwenden dieselbe JunOS-Version, sind mit denselben zwei IXP-Peering-LANs verbunden und haben eine große Anzahl (mehrere Hundert) von (fast identischen) IPv4- und IPv6-Sitzungen. Beide Router haben eine Verbindung zu einem anderen IP-Transitanbieter und sind auf die gleiche Weise mit dem Rest unseres Netzwerks verbunden. Die CPU-Auslastung der Routing-Engines ist bei über 80% nicht gleichbleibend. Minuten bis Stunden lang sind die Werte wieder auf den Normalwert gesunken, aber diese Werte sind selten.

Dinge, die ich überprüft habe:

• Zum Zeitpunkt des Starts der Erhöhung wurden keine Konfigurationsänderungen vorgenommen
• Es gibt keine Zunahme des Nicht-Unicast-Verkehrs, der auf die Steuerebene gerichtet ist
• Es gibt keine (wesentlichen) Änderungen in der Menge des weitergeleiteten Datenverkehrs (auch wenn eine Erhöhung keine Rolle spielen sollte).
• show system processes summaryGibt an, dass der rpdProzess die hohe CPU-Auslastung verursacht
• Es gibt keine schnell flatternden BGP-Peers, die eine große Menge an BGP-Änderungen verursachen

Eine mögliche Erklärung, die ich finden kann, ist ein Peer (oder mehrere) auf einem der beiden Router des IXP, die zum Senden einer großen Anzahl von BGP-Updates verbunden sind. Momentan habe ich nur Statistiken über die Anzahl der BGP-Nachrichten für meine Transitsitzungen (ohne abnormale Aktivität) und bei mehreren Hundert BGP-Sitzungen in Peering-LANs ist es nicht so einfach, die problematischen Sitzungen zu erkennen, wenn ich Diagramme erstellen sollte alle Sitzungen.

Meine Fragen sind:

• Gibt es andere Dinge, die ich überprüfen sollte, um die Ursache für diesen Anstieg der CPU-Auslastung auf den Routing-Engines zu finden?
• Wie kann ich leicht herausfinden, welche Sitzungen diese Probleme verursachen (wenn meine Annahme richtig ist)? Wenn Sie die BGP-Trace-Optionen aktivieren, werden große Datenmengen generiert, aber ich bin mir nicht sicher, ob sie mir echte Erkenntnisse liefern.

Im Juniper Knowledge Center finden Sie möglicherweise hilfreiche Informationen .

Wenn die RPD eine hohe CPU-Auslastung aufweist, führen Sie die folgenden Überprüfungen durch und überprüfen Sie die folgenden Parameter:

• Überprüfen Sie die Schnittstellen: Überprüfen Sie, ob Schnittstellen auf dem Router zu sehen sind. Dies kann überprüft werden, indem die Ausgabe der Befehle show log messages und show interfaces ge-x / y / z überprüft wird. Beheben Sie, warum sie flattern. Wenn möglich, können Sie in Betracht ziehen, die Haltezeit für das Hoch- und Runterkoppeln zu aktivieren.

• Überprüfen Sie, ob Syslog-Fehlermeldungen im Zusammenhang mit Schnittstellen oder FPC / PIC vorliegen, indem Sie sich die Ausgabe der Show-Log-Meldungen ansehen.

• Überprüfen Sie die Routen: Überprüfen Sie die Gesamtzahl der Routen, die der Router gelernt hat, indem Sie die Ausgabe der Routenzusammenfassung anzeigen. Überprüfen Sie, ob es das maximale Limit erreicht hat.

• Überprüfen Sie die RPD-Aufgaben: Ermitteln Sie, was den Prozess beschäftigt. Dies kann überprüft werden, indem zunächst die Funktion zur Abrechnung von festgelegten Aufgaben aktiviert wird. Wichtig: Dies kann die CPU-Last und deren Auslastung erhöhen. Vergessen Sie also nicht, es auszuschalten, wenn Sie mit der erforderlichen Ausgabesammlung fertig sind. Führen Sie dann show task accounting aus und suchen Sie nach dem Thread mit der hohen CPU-Zeit:

  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
  

Finden Sie heraus, warum ein Thread, der sich auf ein bestimmtes Präfix oder ein Protokoll bezieht, eine hohe CPU-Auslastung aufweist.

• Sie können auch überprüfen, ob Routen oszillieren (oder abwandern), indem Sie sich die Ausgabe des Shell-Befehls ansehen: %rtsockmon –t

• Überprüfen Sie den RPD-Speicher. Manchmal kann eine hohe Speichernutzung indirekt zu einer hohen CPU-Auslastung führen.

Ich weiß, dass dieser Thread alt ist, aber der Vollständigkeit halber:

Wenn die hohe CPU zufällig auftritt und Sie nicht in der Lage sind, den Prozess zu bestimmen, der dies verursacht, können wir das folgende Skript erstellen.

Mit diesem Skript werden wir den Prozess umfassend erfassen, wenn ein Prozess mehr als den normalen oder erwarteten Schwellenwert ansteigt. Dies sollte keinen Datenverkehr stören, es wird jedoch weiterhin empfohlen, eine MW zu erstellen. Ich sehe jedoch, dass Sie es auf RPD eingegrenzt haben.

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

Haben Sie auch überprüft, ob ddos-Nachrichten gemeldet wurden? Sie können die folgenden Befehle ausführen:

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

Dann kann je nachdem, was Sie sehen, zum Beispiel eingegrenzt werden:

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 hat auch eine Sammelliste für diese Art von Problemen unter KB22637

Hohe CPU- CLI-Befehle

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

Aktivieren Sie die Aufgabenabrechnung, und erfassen Sie die Detailausgabe der Aufgabenabrechnung (dreimal mit einem Abstand von 30 Sekunden). Vergessen Sie nicht, es auszuschalten, nachdem Sie fertig sind.

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

Protokolle

Archivieren Sie / var / log wie in Schritt 1 oben angegeben

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

Auch wenn Sie eine alte Version verwenden, die für Fehler anfällig war, sollten Sie die Lebenserhaltung des Codes überprüfen:

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

Ein weiterer zu erwähnender Punkt, bei dem es sich um einen Vektorangriff handeln könnte, ist, dass Ihr RE nicht vor unerwünschtem Ausnahmeverkehr geschützt wurde. Stellen Sie sicher, dass sich unter dem Loopback ein Firewall-Filter befindet.

Ich habe in der Vergangenheit gesehen, dass Skripte auf dem Router eine hohe CPU-Auslastung verursachen. Ich bin mir nicht sicher, ob RPD in meine Sicht kam, aber dies ist etwas, das Sie vielleicht nicht übersehen möchten.

Wenn Sie in den Protokollen viele Treffer mit RPD_MPLS_PATH_BANDWIDTH_CHANGE sehen, verwenden Sie möglicherweise ein sehr aggressives Anpassungsintervall

Überprüfen Sie alle Dropdowns auf "Systemwarteschlange anzeigen": Dies ist die Kernelwarteschlange. Möglicherweise wird ein Hinweis angezeigt.