Cómo solucionar cambios de configuración en una unidad secundaria del clúster HA de FortiGate

En este artículo se aborda un aspecto crítico de la configuración del clúster de Alta Disponibilidad (HA) de FortiGate, específicamente el comportamiento al realizar cambios en la unidad secundaria. Comprender cómo se llevan a cabo estas configuraciones es esencial para mantener la redundancia y asegurar un funcionamiento óptimo de la red. A lo largo del artículo, se proporcionarán pasos de diagnóstico, soluciones recomendadas y buenas prácticas para manejar configuraciones en unidades secundarias sin comprometer la integridad del sistema.

Descripción del problema

Se observa un comportamiento peculiar cuando se realizan cambios de configuración en la unidad secundaria de un clúster HA de FortiGate. Aunque técnicamente es posible realizar configuraciones en la unidad secundaria, esta acción puede llevar a inconsistencias y problemas en la sincronización con la unidad primaria.

Alcance

Este artículo se centra en dispositivos FortiGate que forman parte de un clúster de Alta Disponibilidad (HA).

Diagnóstico paso a paso

Un escenario típico de un clúster HA consiste en dos unidades: una unidad primaria que maneja la mayoría del tráfico y una unidad secundaria que está en espera para tomar el control si la primaria falla. Cuando se realiza un cambio en la configuración de la unidad secundaria, este se sincroniza automáticamente con la unidad primaria. A continuación se presentan los pasos que se siguen durante esta sincronización:

• La unidad secundaria se actualiza con los comandos ejecutados.
• La unidad primaria refleja los cambios realizados en la secundaria.

Solución recomendada

Se recomienda encarecidamente que todos los cambios de configuración se hagan en la unidad primaria. Mientras que los cambios en la unidad secundaria son posibles, pueden ocasionar consecuencias imprevistas. Sin embargo, si se necesita hacer una configuración en la secundaria, asegúrese de que no afectará el funcionamiento del clúster HA. Los cambios en la unidad secundaria se reflejarán en la primaria, como se ilustra a continuación:

Cambio de configuración en la unidad secundaria:

                FGT-02 # 2024-12-08 19:25:18 <hatalk> vcluster_1: ha_prio=1(secondary), state/chg_time/now=3(standby)/1733714416/1733714718
                2024-12-09 10:25:48 0: config system interface
                2024-12-09 10:25:48 0: edit "port3"
                2024-12-09 10:25:48 0: set ip 1.1.1.1 255.255.255.0
                2024-12-09 10:25:48 cmd=config system interface
                edit port3
                set ip 1.1.1.1 255.255.255.0
                end
                

Al mismo tiempo, el cambio se refleja en la unidad primaria:

                FGT-01 # 2024-12-09 10:25:07 <hatalk> vcluster_1: ha_prio=0(primary), state/chg_time/now=2(work)/1733714394/1733714707
                2024-12-09 10:25:48 <hasync:WARN> conn=0x55c1bd341700, peer closed the connection: dst=169.254.0.2, sync_type=10(cli-command)
                2024-12-09 10:25:49 0: config system interface
                2024-12-09 10:25:49 0: edit port3
                2024-12-09 10:25:49 0: set ip 1.1.1.1 255.255.255.0
                2024-12-09 10:25:49 0: end
                

Comandos CLI utilizados

Aquí se presentan algunos de los comandos CLI utilizados para ver el estado del puerto y la configuración en el clúster HA:

                FGT-01 # sh sys int port3
                config system interface
                    edit "port3"
                    set vdom "root"
                    set ip 1.1.1.1 255.255.255.0
                    set type physical
                    set snmp-index 3
                next
                end
                

Buenas prácticas y recomendaciones

Para garantizar la consistencia en la configuración, es altamente recomendable realizar siempre los cambios en la unidad primaria. Hacer cambios desde la unidad secundaria puede provocar problemas inesperados.

Por ejemplo, si se desactiva una interfaz monitorizada por HA en la unidad secundaria, esto podría causar un failover de HA. Además, las unidades HA independientes no deberían manejar ningún tráfico de usuarios más allá del tráfico de latido y monitoreo. Cualquier tráfico enviado desde el lado del usuario será descartado localmente a nivel de interfaz, lo que podría resultar en un escenario de «split-brain» y causar interrupciones en los servicios de red.

Notas adicionales

Nota importante: Es fundamental confirmar que los cambios realizados en la unidad secundaria no afecten la sincronización en el clúster HA. En particular, es aconsejable realizar todos los cambios en la unidad primaria para evitar problemas de configuración.