NOC/SOC OPERATIVO · MONITOREO CONTINUO
IT Experts de México
Contáctanos
Inicio/ Blog/ El FortiGate está lento: 5 comandos de triage antes de reini...
Ciberseguridad

El FortiGate está lento: 5 comandos de triage antes de reiniciar

RERubén Espinoza calendar_today02/09/2026 schedule6 min de lectura

"El internet está lentísimo, seguro es el firewall." Lo has escuchado. A veces es cierto, a veces el firewall es el chivo expiatorio de un enlace saturado o un switch muriéndose. El problema es que casi nadie verifica antes de actuar: reinician el FortiGate a ciegas, el problema desaparece un rato, y vuelve — porque nunca supieron qué lo causaba.

Reiniciar sin diagnóstico es tirar la evidencia. Antes de tocar el botón, cinco comandos de CLI te dicen en menos de un minuto dónde duele: si es CPU, si es memoria, si son demasiadas sesiones, o si el equipo entró en conserve mode y está en modo pánico. Vamos uno por uno.

1. La foto general: get system performance status

Es el primer comando, siempre. Te da la instantánea de salud en una sola pantalla: CPU, memoria, sesiones y uptime.

[LAB] Salida de get system performance status
CPU states: 3% user 8% system 0% nice 88% idle 0% iowait 0% irq 1% softirq
CPU0 states: 4% user 9% system 0% nice 87% idle 0% iowait 0% irq 0% softirq
Memory: 4019184k total, 2451020k used (61.0%), 1568164k free (39.0%)
Average network usage: 24 / 31 kbps in 1 minute, 18 / 26 kbps in 10 minutes
Average sessions: 3421 sessions in 1 minute, 3388 sessions in 10 minutes
Average session setup rate: 42 sessions per second in last 1 minute
Uptime: 47 days, 6 hours, 12 minutes

Qué mirar, en orden:

  • CPU idle — el número que importa no es "cuánto usa" sino cuánto le queda. Un 88% idle es un equipo tranquilo. Si ves idle por debajo de 20% de forma sostenida, hay saturación de CPU y toca el comando 2.
  • Memory used — 61% es sano. Arriba de 80% empieza a ser tema (ver conserve mode más abajo).
  • Average sessions y setup rate — te dan el pulso de tráfico. Un setup rate disparado (miles de sesiones nuevas por segundo) suele delatar un equipo infectado en la red o un escaneo, no un firewall débil.
  • Uptime — 47 días te confirma que no se reinició solo (si esperabas que sí, hay otra historia).

2. ¿Quién se está comiendo la CPU? diagnose sys top

Si el comando anterior mostró poca CPU libre, este te dice qué proceso la consume. Es el equivalente al top de Linux, pero de FortiOS.

[LAB] Salida de diagnose sys top (refresca cada pocos segundos; sales con q)
Run Time:  47 days, 6 hours and 12 minutes
0U, 8S, 92I; 3925T, 1531F
      ipsengine       142      S       6.4     3.1
      scanunitd        88      S       2.1     4.7
      httpsd          201      R       1.8     1.9
      newcli          445      R       0.9     0.4
      forticron       120      S       0.2     0.8

La primera línea de números es el resumen: 0U, 8S, 92I = 0% usuario, 8% sistema, 92% idle. Debajo, cada proceso con su PID, estado (R corriendo, S dormido), % de CPU (penúltima columna) y % de memoria (última). Aquí es donde descubres, por ejemplo, que el ipsengine está al tope porque alguien activó inspección profunda en una política de alto tráfico — un dato que cambia por completo la conversación, y que conecta directo con el costo de inspección que explicamos en NGFW vs firewall tradicional (y el verdadero costo de la inspección TLS).

3. La cuenta de sesiones: diagnose sys session stat

Un FortiGate no muere solo por CPU; también por tabla de sesiones llena. Cada equipo tiene un tope, y cuando se acerca, empieza a tirar conexiones nuevas.

[LAB] Salida de diagnose sys session stat
misc info:  session_count=3421 setup_rate=42 exp_count=0 clash=0
    memory_tension_drop=0 ephemeral=0/2097152 removeable=0
npu_session_count=2980
firewall error stat:
misc info:      session_count=3421 ...

Lo que importa: session_count contra el máximo de tu modelo, y sobre todo memory_tension_drop. Si ese contador es distinto de cero, el firewall está tirando sesiones por falta de memoria — señal directa de que vas camino a conserve mode. Un clash alto, por su parte, suele apuntar a ruteo asimétrico, el mismo culpable del reverse path check fail que vimos en el artículo de debug flow.

4. El modo pánico: conserve mode

Este es el estado que más gente diagnostica mal. Cuando la memoria del FortiGate cruza cierto umbral, el equipo entra en conserve mode: una medida de autoprotección donde deja de aceptar tráfico nuevo por el antivirus para no quedarse sin RAM. Desde afuera se siente como "el firewall dejó de pasar tráfico", pero no está caído — está racionando.

[LAB] Salida de diagnose hardware sysinfo conserve
memory conserve mode:    off
total RAM:               4019 MB
memory used:             2451 MB   61% of total RAM
memory freeable:          128 MB    3% of total RAM
memory used + freeable threshold extreme:   3817 MB   95% of total RAM
memory used threshold red:                  3536 MB   88% of total RAM
memory used threshold green:                3295 MB   82% of total RAM

Los tres umbrales son la clave para leer esto:

  • Red (88%): el equipo entra en conserve mode. Empieza a rechazar sesiones nuevas que requieren inspección de contenido.
  • Green (82%): el equipo sale de conserve mode. Nota que el umbral de salida es más bajo que el de entrada — es histéresis deliberada, para que no esté entrando y saliendo en el borde.
  • Extreme (95%): zona crítica; empieza a matar procesos para sobrevivir.

Si memory conserve mode: on, ya tienes tu respuesta: el equipo no está "lento", está en autoprotección por memoria. La causa suele ser subdimensionamiento (un modelo chico para el tráfico que mueve), demasiados perfiles UTM pesados activos, o una fuga en alguna función. Reiniciar lo cura por horas; dimensionar bien lo cura de verdad.

5. El histórico: get system performance status (otra vez, pero con memoria)

El quinto no es un comando nuevo, es un hábito: captura la salida del comando 1 cuando todo está bien, guárdala, y compárala cuando llegue la queja. "El firewall está lento" es una afirmación sin línea base. "El idle bajó de 88% a 22% y las sesiones se triplicaron desde el martes" es un diagnóstico. La diferencia entre las dos frases es lo que separa apagar incendios de operar en serio — la misma lógica que aplicamos a los logs en SIEM, FortiAnalyzer y syslog: registrar no es lo mismo que vigilar.

El reflejo que queremos dejarte

Cuando alguien te diga "el firewall está lento", no reinicies. Corre los cinco comandos en orden —foto general, CPU por proceso, sesiones, conserve mode, comparación con la línea base— y en un minuto sabrás si el problema es el FortiGate o si el FortiGate es el mensajero de un problema que está en otro lado. Reiniciar borra la evidencia; medir la conserva.

#fortinet #fortigate #cli #troubleshooting #conserve-mode #rendimiento

Preguntas frecuentes

help ¿Qué es conserve mode en un FortiGate?

Es un mecanismo de autoprotección: cuando la memoria usada cruza el umbral rojo (88% por defecto), el equipo deja de aceptar sesiones nuevas que requieren inspección de contenido para no agotar la RAM. Sale del modo cuando la memoria baja al umbral verde (82%). No es una falla, es el firewall racionando recursos para no caerse.

help ¿Cómo sé si mi FortiGate está saturado de CPU o de memoria?

Con get system performance status ves ambos de un vistazo: el CPU idle te dice cuánto procesador queda libre y Memory used el porcentaje de RAM en uso. Si la CPU es el problema, diagnose sys top te dice qué proceso la consume; si es memoria, diagnose hardware sysinfo conserve te dice si ya cruzaste los umbrales.

help ¿Reiniciar el FortiGate resuelve la lentitud?

A veces la esconde temporalmente, pero rara vez la resuelve. Si la causa es subdimensionamiento, una fuga de memoria o exceso de sesiones, el problema regresa. Peor aún, reiniciar borra la evidencia que necesitabas para diagnosticar. Mide primero, reinicia después y solo si el diagnóstico lo justifica.

help ¿Estos comandos afectan el rendimiento al ejecutarlos?

No de forma apreciable. Son comandos de lectura de estado; no modifican configuración ni generan carga significativa. A diferencia de diagnose debug flow, que sí conviene filtrar y apagar, estos los puedes correr con tranquilidad en producción cuantas veces necesites.

RE
Sobre el autor

Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.

Ver perfil y todos sus artículos →
Compartir
// Más artículos
// Contacto

Inicia hoy tu transformación digital

Trabajemos juntos. Cuéntanos qué necesita tu operación y te respondemos a la brevedad.

call+52 (614) 400-0013 phone_in_talk+52 (614) 426-2339 mailcontacto@itxperts.com.mx

Al enviar aceptas nuestro Aviso de Privacidad.