Cómo resolver el error de desincronización al reiniciar un dispositivo en un clúster FGSP de Fortinet

En este artículo, abordamos un problema crítico que puede surgir en configuraciones de clúster FGSP de FortiGate. Al reiniciar una de las unidades en un clúster con dos miembros y la sincronización de configuración independiente habilitada, se generan errores de sincronización. Esto puede tener un impacto significativo en la disponibilidad y la operatividad de la red, y aquí proporcionamos una guía para diagnosticar y resolver el problema de manera efectiva.

Descripción del problema

Este artículo describe un problema en el que reiniciar una única unidad en un clúster FGSP con dos miembros y con la sincronización de configuración independiente habilitada causará errores de desincronización. Esto ocurre porque los interfaces de alta disponibilidad (port_ha) en cada unidad no pueden comunicarse entre sí.

Alcance

Este problema afecta a las versiones de FortiGate v7.0, 7.2 y 7.4.

Diagnóstico paso a paso

1. Si un clúster FGSP consiste en dos miembros y ambos tienen la sincronización de configuración independiente habilitada, reiniciar uno de ellos causará errores de desincronización. No hay tal problema en el modo AA o AP con FGSP. Este problema afecta a v7.0.X, v7.2.X, y v7.4.X.

Los comandos a continuación se ejecutaron después de reiniciar la unidad secundaria para reproducir este problema. En esta situación, cuando una FortiGate primaria intenta enviar paquetes, estos se pierden y nunca alcanzan el otro extremo.

D1-CA-DB-FW-1 (global) # get system ha status
HA Health Status: OK
Model: FortiGate-60F
Mode: ConfigSync
Group Name: D1-CA-DB-FW
Group ID: 10
Debug: 0
Cluster Uptime: 0 days 0:17:45
Cluster state change time: 2024-07-26 17:06:50
Primary selected using:
    <2024/07/26 17:06:50> vcluster-1: FGT60FTK22060168 is selected as the primary because its uptime is larger than peer member FGT60FTK2209E0GV.
    <2024/07/26 17:05:18> vcluster-1: FGT60FTK22060168 is selected as the primary because it's the only member in the cluster.
    <2024/07/26 16:55:10> vcluster-1: FGT60FTK22060168 is selected as the primary because its uptime is larger than peer member FGT60FTK2209E0GV.
    <2024/07/26 16:54:57> vcluster-1: FGT60FTK22060168 is selected as the primary because it's the only member in the cluster.
ses_pickup: enable, ses_pickup_delay=disable
override: disable
Configuration Status:
    FGT60FTK22060168(updated 4 seconds ago): in-sync
    FGT60FTK22060168 chksum dump: da bc 6a f8 89 7d ab 93 10 43 83 78 a0 17 a0 a1
    FGT60FTK2209E0GV(updated 431 seconds ago): in-sync
    FGT60FTK2209E0GV chksum dump: da bc 6a f8 89 7d ab 93 10 43 83 78 a0 17 a0 a1

D1-CA-DB-FW-2 (global) # get system ha status
HA Health Status: OK
Model: FortiGate-60F
Mode: ConfigSync
Group Name: D1-CA-DB-FW
Group ID: 10
Debug: 0
Cluster Uptime: 0 days 0:18:13
Cluster state change time: 2024-07-26 17:06:55
Primary selected using:
    <2024/07/26 17:06:55> vcluster-1: FGT60FTK22060168 is selected as the primary because its uptime is larger than peer member FGT60FTK2209E0GV.
ses_pickup: enable, ses_pickup_delay=disable
override: disable
Configuration Status:
    FGT60FTK2209E0GV(updated 4 seconds ago): out-of-sync
    FGT60FTK2209E0GV chksum dump: da bc 6a f8 89 7d ab 93 10 43 83 78 a0 17 a0 a1
    FGT60FTK22060168(updated 1721981575 seconds ago): in-sync
    FGT60FTK22060168 chksum dump: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Solución recomendada

1. La solución para este problema consiste en ejecutar el comando fnsysctl killall hatalk en ambos miembros del clúster.

1. El problema se resuelve en las versiones v7.2.11, v7.4.8 y v7.6.1.

Comandos CLI utilizados

D1-CA-DB-FW-2 (global) # dia debug appli hasync -1
D1-CA-DB-FW-1 (global) # dia debug ena
D1-CA-DB-FW-1 (global) # exe ha sync start
<hatalk> vcluster_1: ha_prio=1(secondary), state/chg_time/now=2(work)/1721981215/1721982100
<hasync> upd_cfg_extract_av_db_version[331]-Failed av db version, obj 32
<hasync:WARN> conn=0x91c7cc0 connect(169.254.0.2) failed: 113(No route to host)
<hasync:WARN> conn=0x91c7cc0 abort: rt=-1, dst=169.254.0.2, sync_type=5(conf)
<hatalk> vcluster_1: ha_prio=1(secondary), state/chg_time/now=2(work)/1721981215/1721982100
<hasync> upd_cfg_extract_av_db_version[331]-Failed av db version, obj 32
<hasync:WARN> conn=0x91c9520 connect(169.254.0.2) failed: 113(No route to host)

Buenas prácticas y recomendaciones

Siempre se recomienda realizar un análisis exhaustivo y pruebas en un entorno controlado antes de implementar cambios en un entorno de producción. Mantenga sus sistemas actualizados y realice controles de configuración regulares para minimizar el riesgo de problemas de sincronización en el futuro. Además, considere el uso de configuraciones de alta disponibilidad que minimicen el tiempo de inactividad tras un reinicio.

Notas adicionales

Para asegurarse de que el clúster funcione sin problemas, es crucial entender cómo las configuraciones de alta disponibilidad y la sincronización de configuración afectan a la red en su conjunto. Recuerde que los problemas de conectividad entre los miembros del clúster pueden llevar a situaciones críticas que afecten la estabilidad de su infraestructura de seguridad de red.