Due FortiGate in FGCP non sono «due firewall con uno di riserva»: sono un unico apparato logico che la rete vede attraverso un solo set di indirizzi MAC. Saper operare un cluster vuol dire sapere cosa viaggia sul heartbeat e cosa no, e cosa sopravvive quando il primario sparisce.

Heartbeat, sincronizzazione e MAC virtuali

Il heartbeat FGCP è traffico Ethernet di livello 2 con EtherType 0x8890 e 0x8891, non pacchetti IP: non lo instradi e non lo filtri con una policy. L’intervallo predefinito fra un hello e il successivo è 200 ms. La sincronizzazione della configurazione viaggia sullo stesso link, ma su TCP/703 e UDP/703, con un meccanismo misto incrementale e periodico.

Non tutto si sincronizza, e l’elenco delle eccezioni è materia d’esame: hostname, widget della dashboard, HA override, priorità del dispositivo, priorità del virtual cluster, impostazioni dell’interfaccia di management riservata e la sua default route. Licenze e sottoscrizioni sono per dispositivo; l’eccezione documentata è FortiToken Mobile, registrato sul primario e propagato ai secondari.

Verso la rete, ogni interfaccia del primario espone un MAC virtuale. Al failover il nuovo primario eredita gli stessi VMAC e gli stessi IP, quindi per gli switch a valle non è cambiato nulla: manda dei gratuitous ARP (cinque per impostazione predefinita) per aggiornare le loro tabelle di forwarding. I MAC dei subordinati restano invece quelli originali. Trappola classica: due cluster distinti con lo stesso group ID nello stesso dominio di broadcast generano un conflitto di MAC.

Sulle interfacce di heartbeat vale una regola secca: solo porte fisiche, mai VLAN, aggregate 802.3ad, redundant, switch port o interfacce IPsec. Priorità predefinita 50 su un intervallo 0-512, fino a otto interfacce, cablate simmetricamente port1 con port1 e port2 con port2.

Chi diventa primario: MUPS contro MPUS

La selezione riparte quando si forma un cluster, quando un membro si aggiunge, quando il primario cade e a ogni cambio di stato di un’interfaccia monitorata.

Con override disabilitato l’ordine è MUPS: interfacce monitorate, uptime, priorità, numero di serie. Con override abilitato diventa MPUS, cioè la priorità scavalca l’uptime. Sono gli acronimi che usa la documentazione stessa. Ogni criterio che dà pari merito passa la mano al successivo.

Sull’uptime c’è una soglia da ricordare: una differenza superiore a cinque minuti (300 secondi) fa vincere l’unità accesa da più tempo, sotto i cinque minuti è parità. Il guasto di un’interfaccia monitorata azzera l’uptime HA dell’unità, e lo azzera anche un riavvio.

Attenzione: la priorità non si sincronizza, va impostata su ogni unità. Per un primario deterministico abilita override e alza la priorità sull’unità preferita, accettando un failover in più quando quella rientra.

config system ha
    set mode a-p
    set group-id 1
    set group-name Example_cluster
    set hbdev ha1 10 ha2 20
    set priority 200
    set override enable
    set monitor "port1" "port2"
end

Session pickup: cosa sopravvive e cosa no

Per impostazione predefinita il cluster non tiene traccia delle sessioni: dopo un failover vanno riavviate o riprese dal livello TCP/IP. Con session pickup attivo la tabella delle sessioni TCP del primario è sincronizzata su tutti i membri appena una sessione nasce. La documentazione è onesta: in condizioni ideali tutte le sessioni TCP riprendono, ma non è garantito.

Il punto che sfugge quasi sempre è che riguarda solo il TCP. UDP e ICMP richiedono in aggiunta session-pickup-connectionless, che presuppone il session pickup già abilitato. E qui la 7.6 aggiunge una nota che vale la domanda d’esame: nonostante il nome, quell’impostazione serve anche al failover di QUIC e HTTP/3, orientati alla connessione pur viaggiando su UDP. Senza, le sessioni QUIC cadono e vanno ristabilite: è la spiegazione più frequente del «failover riuscito ma la navigazione si blocca».

Per il multicast si abbassa il TTL delle rotte sincronizzate da 600 a 120 secondi. Le sessioni terminate dal cluster stesso non sono coperte. Disabilitare il session pickup resta legittimo se il cluster passa soprattutto traffico non sincronizzato: si risparmia CPU e banda.

config system ha
    set session-pickup enable
    set session-pickup-connectionless enable
    set multicast-ttl 120
end

Verificare che il cluster sia allineato

Il comando get system ha status risponde a due domande in una schermata. Sotto Configuration Status ogni membro è marcato in-sync oppure out-of-sync, con il dump del checksum; sotto Primary selected using c’è la frase che dice letteralmente perché quell’unità è primaria. In GUI, System > HA e il widget HA Status marcano in rosso il membro non allineato e nel tooltip elencano le tabelle divergenti. Un cluster out-of-sync compromette l’integrità della configurazione: va sistemato subito.

Aggiornare il firmware del cluster

L’aggiornamento senza interruzione è il comportamento predefinito e segue un ordine preciso: si carica l’immagine, si aggiornano tutti i subordinati, si elegge un nuovo primario fra i subordinati già aggiornati, si aggiorna l’ex primario e infine riparte la normale selezione. Aspettati quindi un cambio di ruolo: senza override l’unità di partenza non torna necessariamente primaria. Se durante la procedura tutti i subordinati smettono di rispondere, il primario continua a lavorare e non si aggiorna finché almeno un subordinato non rientra.

L’alternativa aggiorna tutti i membri insieme: più rapida, ma interrompe la comunicazione, ed è disabilitata per impostazione predefinita.

Prima di partire servono backup, finestra di manutenzione e verifica del percorso di upgrade supportato. La trappola documentata: la modalità senza interruzione non garantisce riavvii scaglionati se hai toccato impostazioni CLI che richiedono un reboot, e le unità possono riavviarsi tutte insieme.

config system ha
    set upgrade-mode simultaneous
end