"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.
get system performance statusCPU 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% idlees un equipo tranquilo. Si vesidlepor 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.
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.
diagnose sys session statmisc 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.
diagnose hardware sysinfo conservememory 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.
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.
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 →