Cuando aparece una incidencia de red, lo primero que intento averiguar es dónde deja de funcionar la comunicación. Parece una pregunta sencilla, pero entre el equipo del usuario, el switch, las VLAN, el firewall, las rutas y los enlaces WAN pueden intervenir bastantes elementos.

La interfaz gráfica de Fortinet es útil, pero para comprobar sesiones, interfaces o rutas suelo recurrir a la CLI. El objetivo de esta guía no es memorizar comandos: es saber qué información buscar, cuándo utilizar cada herramienta y cómo relacionar los resultados.

Luego de las tablas de comandos, añado los criterios prácticos que utilizo en troubleshooting N2/N3. Los ejemplos muestran posibles comprobaciones, no resultados obtenidos en una instalación concreta.

Compatibilidad: la disponibilidad, sintaxis y salida de algunos comandos depende de la versión de FortiOS o FortiSwitchOS, del hardware y de si el switch trabaja en modo independiente o administrado por FortiGate. Si un comando no aparece, compruebo la ayuda contextual con ? y la referencia CLI de la versión instalada. En los ejemplos, las direcciones IP son ilustrativas.

1. FortiGate: chuleta completa

Chuleta FortiGate / FortiSwitch - Comandos de Troubleshooting

Comando ¿Qué hace?
get system status Muestra versión de FortiOS, número de serie, uptime y datos generales del equipo.
get hardware status Muestra información del hardware y estado general del dispositivo.
get system performance status Verifica uso de CPU, memoria y sesiones activas.
diagnose sys top Monitor en tiempo real de procesos y consumo de recursos.
get system interface physical Muestra estado físico de todas las interfaces.
diagnose netlink interface list Muestra información detallada de interfaces (estado, velocidad, errores, duplex).
show system interface Muestra la configuración de todas las interfaces.
show system interface <INTERFAZ> Muestra la configuración de una interfaz específica.
get router info routing-table all Muestra la tabla de routing completa.
get router info routing-table details <IP> Muestra la ruta exacta que utilizará un destino concreto.
show router static Muestra las rutas estáticas configuradas.
get router info bgp summary Resumen de vecinos BGP y estado de las sesiones.
get router info bgp neighbors Información detallada de los vecinos BGP.
execute ping <IP> Comprueba conectividad hacia una IP o dominio.
execute ping-options source <IP> Define IP origen para las pruebas de ping.
execute ping-options repeat-count 20 Define cantidad de paquetes enviados durante el ping.
execute traceroute <IP> Muestra los saltos hasta un destino.
show system dns Muestra la configuración DNS del FortiGate.
diagnose test application dnsproxy 6 Prueba y verifica el funcionamiento del DNS Proxy.
diagnose sys session stat Estadísticas generales de sesiones activas.
diagnose sys session filter dst <IP> Filtra sesiones por IP destino.
diagnose sys session list Muestra sesiones que cumplen el filtro configurado.
diagnose sys session filter clear Limpia filtros de sesiones.
show firewall policy Muestra todas las políticas firewall.
show firewall policy <ID> Muestra una política específica.
diagnose debug flow filter addr <IP> Filtra el debug de tráfico por IP.
diagnose debug flow trace start 100 Inicia la captura de flujos de tráfico.
diagnose debug enable Activa el debug.
diagnose debug disable Desactiva el debug.
diagnose debug flow trace stop Finaliza el debug de flujo.
diagnose sniffer packet any "host <IP>" 4 Captura tráfico de una IP concreta.
diagnose sniffer packet any "port 53" 4 Captura tráfico DNS.
get system sdwan Muestra configuración y estado SD-WAN.
diagnose sys sdwan health-check Verifica estado de los enlaces SD-WAN.
diagnose sys sdwan service Muestra qué enlace está utilizando cada servicio.
get vpn ipsec tunnel summary Estado resumido de túneles IPSec.
diagnose vpn tunnel list Información detallada de los túneles VPN.
diagnose debug application ike -1 Debug completo de negociación IPSec/IKE.
show system dhcp server Muestra configuración de servidores DHCP.
diagnose ip dhcp server list Muestra leases DHCP y estadísticas.
execute dhcp lease-list Lista dispositivos con concesión DHCP activa.
get system arp Muestra la tabla ARP.
get system arp \| grep <IP> Busca una IP concreta en la tabla ARP.
execute log display Muestra los logs almacenados localmente.
execute log filter category 0 Filtra logs antes de mostrarlos.
get system ha status Estado del cluster HA.
diagnose sys ha checksum cluster Comprueba sincronización entre nodos HA.

FortiSwitch

Comando ¿Qué hace?
get switch status Información general del switch.
get system status Estado general y versión del sistema.
get switch interface Estado operativo de todos los puertos.
diagnose switch physical-ports list Muestra velocidad, duplex y errores físicos de los puertos.
get switch mac-address Tabla MAC completa.
get switch mac-address \| grep <MAC> Busca una MAC específica.
show switch vlan Muestra la configuración de VLANs.
get switch vlan Muestra VLANs y puertos asociados.
get switch poe inline Estado PoE de todos los puertos.
diagnose switch poe status Consumo PoE y potencia utilizada.
get switch lldp neighbors Muestra vecinos LLDP conectados.
get switch stp instance Estado del protocolo STP.
diagnose stp instance list Información detallada de STP y puertos bloqueados.
execute log display Consulta los logs del FortiSwitch.

Comandos que más uso en soporte N2/N3

Esta tabla la suelo considerar la chuleta imprescindible para un técnico de redes que administra FortiGate y FortiSwitch, especialmente para incidencias de tiendas, SD-WAN, APs, VLANs, VPNs y problemas de navegación.

Comando Uso típico
get system performance status Ver si el firewall está saturado.
diagnose netlink interface list Detectar problemas físicos o errores WAN/LAN.
get router info routing-table all Validar rutas y gateways.
execute ping 8.8.8.8 Verificar salida a Internet.
execute ping www.google.com Verificar DNS.
diagnose sys sdwan health-check Revisar estado real de los enlaces SD-WAN.
diagnose sniffer packet any "host X.X.X.X" 4 Confirmar que el tráfico entra y sale.
diagnose debug flow filter addr X.X.X.X Seguir el tráfico de un cliente.
diagnose debug flow trace start 100 Ver políticas, NAT y rutas aplicadas.
get switch mac-address Localizar equipos en el switch.
get switch lldp neighbors Identificar qué hay conectado en cada puerto.
diagnose switch physical-ports list Detectar puertos con errores o negociación incorrecta.

2. Cómo utilizo los comandos de FortiGate

Estado del equipo: ¿hay algún problema de recursos?

Cuando varias personas se quejan a la vez de lentitud, cortes o comportamientos extraños, antes de revisar políticas empiezo por get system status, get hardware status y get system performance status. Me permiten identificar la versión del sistema, el modelo y si hay presión de CPU, memoria o sesiones.

Si encuentro consumo elevado, diagnose sys top me permite observar los procesos en tiempo real e identificar cuál está trabajando más. No doy por hecho que una CPU alta sea la causa: compruebo si coincide con la hora de la incidencia y si el consumo es sostenido. El monitor interactivo se detiene con q.

Cuándo lo uso: lentitud general, cortes intermitentes, alta carga tras un cambio de configuración o sospechas de que el firewall está entrando en modo de conservación de memoria.

Interfaces físicas: ¿el enlace está realmente bien?

get system interface physical me sirve para un primer repaso del estado de los puertos. Cuando sospecho de una WAN o de un enlace hacia un switch, paso a diagnose netlink interface list, donde busco contadores de errores, drops, velocidad negociada y estado del enlace. Con show system interface reviso después la configuración lógica; si solo me interesa un puerto, utilizo show system interface <INTERFAZ>.

Una interfaz puede aparecer levantada y, aun así, perder paquetes por un cable deteriorado, un transceptor defectuoso o una negociación incorrecta. Los errores que aumentan mientras reproduzco el problema son más útiles que una cifra acumulada desde hace semanas.

Cuándo lo uso: enlace WAN inestable, puerto que negocia a una velocidad inesperada, pérdida de paquetes y cortes de acceso a una VLAN.

Routing y BGP: ¿por dónde va a salir el tráfico?

Con get router info routing-table all reviso las rutas instaladas en la tabla de enrutamiento. Si busco un destino particular, utilizo get router info routing-table details <IP> como comprobación adicional y comparo la información con la ruta estática configurada en show router static.

Hay una distinción importante: una ruta configurada no tiene por qué ser la ruta activa. Puede competir con otra de distinta distancia administrativa o no instalarse por problemas de reachability. Además, en entornos con policy routes o SD-WAN, la ruta convencional por sí sola no siempre explica el enlace elegido para una sesión.

En entornos BGP, get router info bgp summary es mi primera vista de las sesiones: busco vecinos establecidos y compruebo si están recibiéndose prefijos. get router info bgp neighbors aporta más información sobre cada vecino, contadores y estado de la relación.

Cuándo lo uso: una subred remota que deja de alcanzarse, una ruta que apunta a una WAN equivocada, un enlace MPLS o VPN que pierde prefijos, o una sesión BGP que no llega a establecerse.

Ping, traceroute y DNS: separar conectividad de resolución de nombres

execute ping <IP> es una prueba rápida de conectividad desde el propio FortiGate, que no equivale necesariamente a probar el tráfico de un cliente que atraviesa sus políticas. Con execute ping-options source <IP> selecciono la IP de origen adecuada, por ejemplo la de la interfaz de una VLAN o de una WAN. execute ping-options repeat-count 20 permite ampliar una prueba para observar pérdidas puntuales.

Si un destino no responde, execute traceroute <IP> puede mostrar hasta dónde llega el tráfico, aunque un salto que no responde a traceroute no demuestra necesariamente que esté caído: algunos routers filtran ese tipo de mensajes.

Cuando funcionan las pruebas a IP pero fallan los nombres, reviso show system dns. diagnose test application dnsproxy 6 proporciona información diagnóstica de dnsproxy según la versión; no es una prueba universal de que un nombre resuelva correctamente. Para comprobar DNS de verdad comparo una consulta real desde el cliente o equipo afectado con el tráfico observado en el firewall.

Cuándo lo uso: el usuario dice que «no hay Internet», una aplicación funciona por IP pero no por nombre, o necesito comprobar qué origen utiliza una prueba de conectividad.

Sesiones, políticas y debug flow: ¿el firewall permite ese tráfico?

Antes de empezar un debug, miro diagnose sys session stat para conocer el estado general de la tabla de sesiones. Después filtro el destino con diagnose sys session filter dst <IP> y ejecuto diagnose sys session list. Al finalizar, siempre uso diagnose sys session filter clear para que un filtro antiguo no contamine la siguiente comprobación.

Con show firewall policy y show firewall policy <ID> reviso interfaces, direcciones, servicios, horarios y NAT de las políticas configuradas. Pero ver una política que parece permitir el tráfico no significa que sea la que está aplicándose a una sesión.

Cuando necesito seguir un flujo concreto recurro a diagnose debug flow filter addr <IP>, diagnose debug flow trace start 100 y diagnose debug enable. En la salida busco la política aplicada, el siguiente salto, posibles traducciones NAT y motivos de descarte. Detengo el diagnóstico con diagnose debug disable y diagnose debug flow trace stop.

Ejemplo de secuencia acotada para una incidencia de un cliente:

diagnose debug flow filter clear
diagnose debug flow filter addr 192.0.2.20
diagnose debug flow trace start 100
diagnose debug enable

Reproduzco entonces el fallo desde ese cliente y cierro la captura:

diagnose debug disable
diagnose debug flow trace stop
diagnose debug flow filter clear

El orden de activación y arranque puede variar entre ejemplos de Fortinet, pero los dos pasos son necesarios para observar la traza. No dejo este debug habilitado sin supervisión: puede generar numerosos mensajes. Además, el tráfico acelerado mediante NP6/NP7 puede no aparecer en el debug flow convencional. Una traza vacía no demuestra por sí sola que no haya tráfico.

Cuándo lo uso: usuarios bloqueados por una política, problemas de NAT, accesos intermitentes a una aplicación o discrepancias entre la ruta esperada y la aplicada.

Sniffer: ¿los paquetes llegan y salen?

diagnose sniffer packet any "host <IP>" 4 me permite observar paquetes relacionados con una IP; diagnose sniffer packet any "port 53" 4 acota la captura al tráfico DNS tradicional por el puerto 53. En ambos casos, el 4 indica un nivel de detalle de salida, no cuatro paquetes. Interrumpo la captura con Ctrl+C.

Esta herramienta responde a una pregunta distinta del debug flow: ¿estoy viendo paquetes en las interfaces observadas? Si veo peticiones pero ninguna respuesta, no concluyo de inmediato que el firewall las esté bloqueando; también podrían perderse en la red de destino o regresar por otro camino. Y no todo el DNS utiliza el puerto 53: DNS cifrado puede utilizar otros transportes.

Cuándo lo uso: sospecha de pérdida de paquetes, tráfico que no llega a un servicio, respuestas que no regresan o consultas DNS que parecen quedarse sin contestación.

SD-WAN: el enlace activo no siempre es el enlace elegido

get system sdwan ofrece información general de SD-WAN. Si una tienda tiene dos accesos a Internet y una aplicación empieza a fallar, miro diagnose sys sdwan health-check para comprobar el estado de las mediciones de calidad de los enlaces. Con diagnose sys sdwan service reviso las reglas y la selección de miembros que reporta el equipo.

Un puerto WAN puede estar físicamente up y presentar pérdida, latencia elevada o jitter que lo hagan inadecuado para un servicio concreto. Por eso no me conformo con comprobar que el enlace responde a ping: relaciono el SLA, la regla de SD-WAN y la sesión afectada.

Cuándo lo uso: failover que no se comporta como esperaba, aplicaciones que funcionan por una WAN y por otra no, lentitud en sucursales y decisiones inesperadas de balanceo.

VPN IPsec: ¿está negociado el túnel y pasa tráfico?

Con get vpn ipsec tunnel summary obtengo una visión rápida del estado de los túneles. diagnose vpn tunnel list muestra detalles para comprobar asociaciones de seguridad, selectores y contadores, dependiendo de la versión.

Si la negociación falla, diagnose debug application ike -1 configura un nivel muy detallado de depuración del proceso IKE; para que aparezcan mensajes, debo habilitar también el debug general. Cuando termino lo desactivo y restablezco la depuración. Como en cualquier debug de producción, intento limitar su duración y recopilar solo lo necesario.

Cuándo lo uso: VPN site-to-site caída, Phase 1 o Phase 2 que no establece, túnel levantado sin paso de datos, o renegociaciones frecuentes.

DHCP y ARP: ¿el cliente ha obtenido red correctamente?

show system dhcp server me ayuda a revisar los servidores DHCP configurados; diagnose ip dhcp server list y execute dhcp lease-list permiten consultar información del servicio y concesiones según la versión. No confundo una concesión con una conectividad correcta: un dispositivo puede recibir IP y tener mal la VLAN, el gateway o las políticas posteriores.

Con get system arp veo las asociaciones IP-MAC conocidas por el firewall, y con get system arp | grep <IP> busco una dirección concreta. Una ausencia en ARP debe interpretarse teniendo en cuenta si ese destino es adyacente y si ha habido comunicación reciente: los equipos remotos a través de routers no tienen por qué aparecer en la tabla local.

Cuándo lo uso: terminales sin conexión, equipos que no reciben dirección IP, sospechas de conflicto IP, o clientes presentes en el switch pero sin comunicación con el gateway.

Logs y alta disponibilidad

execute log display consulta los registros disponibles en el equipo; execute log filter category 0 permite seleccionar una categoría de logs antes de mostrarlos, de acuerdo con la clasificación de la versión. Que no aparezca un evento no significa que no haya sucedido: depende de qué se registra y de dónde se almacenan los logs.

En un clúster, get system ha status me ayuda a identificar miembros, roles y estado HA. diagnose sys ha checksum cluster sirve para investigar diferencias de sincronización de configuración entre nodos, pero no sustituye la revisión completa del funcionamiento de las interfaces y del tráfico tras un failover.

Cuándo lo uso: incidencias posteriores a cambios de configuración, conmutaciones HA inesperadas y diagnósticos que requieren correlacionar eventos con la hora exacta del fallo.

3. Cómo utilizo los comandos de FortiSwitch

Diagnóstico físico de puertos

Cuando un dispositivo aparece desconectado, empiezo por get switch status, get system status y get switch interface para situarme. Después utilizo diagnose switch physical-ports list para comprobar un puerto concreto o repasar todos: estado administrativo, estado del enlace, velocidad, dúplex y contadores físicos si el modelo los expone.

Un puerto en estado up no garantiza que esté funcionando bien. Si los contadores de errores crecen cuando se reproduce una incidencia, investigo cableado, transceptor, dispositivo conectado y negociación. Si el puerto está down, compruebo antes la conexión física y si está administrativamente deshabilitado.

Tabla MAC y VLAN: localizar el dispositivo

get switch mac-address permite consultar las MAC aprendidas; el filtro con grep <MAC> ayuda a localizar una concreta cuando esa sintaxis está disponible. Busco el puerto en el que se aprende y compruebo si es un puerto de acceso, un troncal o un enlace hacia otro switch.

Con show switch vlan y get switch vlan contrasto la configuración de las VLAN con la información operativa que ofrece la versión. No basta con que una VLAN exista: verifico su pertenencia al puerto, el etiquetado esperado y los enlaces ascendentes por los que debe pasar.

Cuándo lo uso: un usuario conectado a la VLAN incorrecta, una impresora no localizable, una MAC que aparece en un uplink inesperado o un equipo que ha sido conectado en otro armario.

PoE: teléfonos, AP y dispositivos que se reinician

get switch poe inline y diagnose switch poe status me orientan sobre el suministro de potencia. Si un punto de acceso se reinicia o un teléfono IP no enciende, compruebo si el puerto entrega energía y si existe margen suficiente en el presupuesto PoE del switch.

No atribuyo automáticamente un reinicio al PoE. Correlaciono la hora del evento con los logs del switch y compruebo cableado, alimentación y estado del dispositivo.

LLDP y STP: entender vecinos y topología

Con get switch lldp neighbors identifico los vecinos que anuncian información LLDP: por ejemplo, otro switch o un teléfono compatible. Es útil para localizar enlaces y entender qué hay conectado sin acudir físicamente a cada armario. La ausencia de vecino LLDP no implica que el puerto esté vacío; el dispositivo remoto puede no anunciar LLDP.

get switch stp instance y diagnose stp instance list ayudan a analizar STP y puertos bloqueados. Un puerto bloqueado por STP no siempre es un fallo: puede ser precisamente el comportamiento correcto para evitar un bucle de capa 2. Investigo los cambios inesperados de topología y si existe un camino redundante funcional.

Por último, execute log display aporta contexto temporal: cambios de estado, eventos de PoE o incidencias registradas, siempre que el equipo tenga esos logs disponibles.

4. Tres incidencias reales en forma de procedimiento

Los siguientes escenarios son ejemplos de diagnóstico, no registros de incidencias reales. La idea es evitar empezar por el comando más complejo cuando otro más sencillo puede resolver la duda.

Caso A: «La tienda no tiene Internet»

Primero compruebo si falla un terminal o toda la sede. Si afecta a todos, reviso rendimiento, interfaces y rutas:

get system performance status
diagnose netlink interface list
get router info routing-table all
diagnose sys sdwan health-check

Después pruebo conectividad desde el firewall, escogiendo el origen correcto si hay varias interfaces:

execute ping-options repeat-count 20
execute ping 8.8.8.8
execute ping www.google.com

Si responde una IP pública pero falla el nombre, investigo DNS. Si no responde ninguna, no doy por hecho que sea la operadora: compruebo la ruta, la SD-WAN y el origen del ping. Por último, si el problema solo afecta a los clientes, reviso sesiones, políticas y tráfico que atraviesa el firewall.

Caso B: «El dispositivo tiene IP, pero no conecta con el servidor»

Compruebo la concesión DHCP, la presencia de la MAC en el switch, la VLAN y la ruta hacia el servidor:

execute dhcp lease-list
get system arp
get router info routing-table all

A continuación busco el flujo hacia el destino, por ejemplo 198.51.100.25:

diagnose sys session filter clear
diagnose sys session filter dst 198.51.100.25
diagnose sys session list
diagnose sys session filter clear

Si sigo sin encontrar la causa, realizo un sniffer filtrado o un debug flow breve. Distingo entre «la petición no sale del cliente», «llega al firewall y se deniega» y «sale, pero no vuelve la respuesta». Son problemas distintos y requieren actuaciones distintas.

Caso C: «El punto de acceso se desconecta varias veces al día»

En el FortiSwitch compruebo el estado del puerto, sus errores y el suministro PoE:

get switch interface
diagnose switch physical-ports list
get switch poe inline
diagnose switch poe status
get switch lldp neighbors
execute log display

Si el enlace flapea, reviso cableado y negociación; si la alimentación cae, investigo el presupuesto PoE y el consumo. Si ambos parecen estables, continúo por el plano de gestión, las VLAN y la conectividad hacia el controlador o gateway.

5. Cómo evito perder tiempo durante el troubleshooting

Mi orden de trabajo suele ser alcance del fallo → estado físico → direccionamiento y VLAN → rutas → políticas y sesiones → captura o debug. No es una regla rígida, pero ayuda a separar causas y a no modificar configuraciones sin pruebas.

También procuro no confundir tres niveles de evidencia: que exista una configuración, que esa configuración esté operativa y que una sesión concreta esté utilizándola. Una política puede existir y no coincidir con el tráfico; una ruta puede estar configurada y no instalarse; y un enlace puede estar activo físicamente y resultar inadecuado para un servicio SD-WAN.

Antes de cerrar una incidencia, repito la prueba que fallaba, compruebo que el resultado sea estable y desactivo cualquier depuración o filtro que haya dejado preparado. El objetivo no es ejecutar muchos comandos, sino encontrar el punto exacto en el que deja de cumplirse lo esperado.

Referencias técnicas