Causa de una alta carga de CPU en el motor de enrutamiento del enrutador de emparejamiento Juniper

Recientemente, la utilización de la CPU del motor de enrutamiento en dos de nuestros enrutadores de emparejamiento Juniper aumentó de ~ 10-20% de carga promedio a 80 +%. Estoy tratando de averiguar qué está causando esto (y cómo volver a bajar esta carga alta).

Alguna información sobre los enrutadores: ambos ejecutan la misma versión de JunOS, ambos están conectados a las mismas dos LAN IXP pares y tienen una gran cantidad (varios cientos) de sesiones (casi idénticas) de IPv4 e IPv6. Ambos enrutadores tienen una conexión a un proveedor de tránsito IP diferente y están conectados de la misma manera al resto de nuestra red. La carga de CPU de los motores de enrutamiento no es plana en más del 80%, hay descensos a niveles normales de minutos a horas, pero estos descensos no son tan frecuentes.

Cosas que he comprobado:

• no se han realizado cambios de configuración en el momento en que comenzó el aumento
• no hay aumento en el tráfico no unidifusión dirigido al plano de control
• no hay un cambio (sustancial) en la cantidad de tráfico que se reenvía (aunque incluso un aumento no debería importar)
• show system processes summaryindica que el rpdproceso está causando una alta carga de CPU
• no hay pares de BGP que agiten rápidamente causando una gran cantidad de cambios de BGP

Una posible explicación que se me ocurre es un par (o más de uno) en uno de los dos enrutadores del IXP conectados para enviar una gran cantidad de actualizaciones de BGP. Actualmente solo tengo estadísticas sobre la cantidad de mensajes BGP para mis sesiones de tránsito (que no muestran actividad anormal) y con varios cientos de sesiones BGP en las LAN de interconexión no es tan fácil detectar las sesiones problemáticas si debo crear gráficos para todas las sesiones

Mis preguntas son:

• ¿Hay alguna otra cosa que deba verificar para encontrar la causa de este aumento en la carga de la CPU en los motores de enrutamiento?
• ¿Cómo puedo averiguar fácilmente qué sesiones están causando estos problemas (si mi suposición es correcta)? Habilitar las opciones de rastreo BGP genera grandes cantidades de datos, pero no estoy seguro de si me da alguna idea real.

Puede haber información útil para usted en el Centro de conocimiento de Juniper .

Si RPD consume CPU alta, realice las siguientes comprobaciones y verifique los siguientes parámetros:

• Compruebe las interfaces: compruebe si hay alguna interfaz aleteando en el enrutador. Esto se puede verificar mirando la salida de los mensajes show log y show interfaces ge-x / y / z comandos extensos. Solucionar problemas por los que están aleteando; si es posible, puede considerar habilitar el tiempo de espera para el enlace hacia arriba y hacia abajo.

• Compruebe si hay mensajes de error de syslog relacionados con interfaces o cualquier FPC / PIC, mirando la salida de los mensajes de registro de show.

• Verifique las rutas: Verifique el número total de rutas que aprende el enrutador mirando la salida del resumen de ruta de la demostración. Verifique si ha alcanzado el límite máximo.

• Verifique las tareas de RPD: identifique qué es lo que mantiene ocupado el proceso. Esto se puede verificar activando primero la contabilidad de tareas establecidas. Importante: Esto en sí mismo podría aumentar la carga en la CPU y su utilización; así que no olvide apagarlo cuando haya terminado con la colección de salida requerida. Luego ejecute show task contabilidad y busque el hilo con el tiempo de CPU alto:

  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
  

Descubra por qué un subproceso, que está relacionado con un prefijo particular o un protocolo, está tomando CPU alta.

• También puede verificar si las rutas están oscilando (o las rutas se anulan) mirando la salida del comando de shell: %rtsockmon –t

• Verifique la memoria RPD. Algunas veces, la alta utilización de la memoria puede conducir indirectamente a una alta CPU.

Sé que este hilo es viejo, pero por completo:

Si la CPU alta ocurre aleatoriamente y no puede determinar el proceso que causa esto, podemos crear el script a continuación.

Con este script vamos a capturar el proceso extensivo cuando un proceso eleva más del umbral normal o esperado, esto no debería interrumpir el tráfico, pero aún se recomienda un MW. Sin embargo, veo que lo has reducido a 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;
            }
        }
    }
}

PANTALLA CONFIGURAR SALIDA>

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

¿También ha verificado si se han reportado mensajes ddos? Puede ejecutar los siguientes comandos:

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

Luego, dependiendo de lo que vea, puede reducirse, por ejemplo:

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 también tiene una lista de colección para este tipo de problemas bajo KB22637

Comandos altos de CPU CLI

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

Active la contabilidad de tareas y recopile la salida de detalles de contabilidad de tareas (tres veces con un espacio de 30 segundos). No olvide apagarlo después de terminar.

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

Registros

Archive / var / log como se especifica en el Paso 1 anterior Traceoptions

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

Además, si está ejecutando una versión anterior que era propensa a errores, puede consultar el soporte vital del código:

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

Otro punto a mencionar que podría ser un ataque vectorial es no haber protegido su RE del tráfico de excepciones no deseadas. Asegúrese de tener un filtro de firewall debajo del loopback.

He visto en los scripts anteriores en el enrutador que causaba una alta CPU, no estoy seguro de si rpd entró en mi punto de vista, pero esto es algo que es posible que no desee pasar por alto.

Si ve en los registros muchos éxitos con RPD_MPLS_PATH_BANDWIDTH_CHANGE, podría estar utilizando un intervalo de ajuste muy agresivo

Verifique cualquier caída en "mostrar la cola del sistema: esta es la cola del núcleo, puede aparecer alguna pista.