Avere due WAN non è ridondanza. La ridondanza esiste solo se il FortiGate si accorge che un link è morto e ritira la rotta corrispondente; il bilanciamento esiste solo se le rotte sono equivalenti nei numeri giusti. Qui mettiamo in fila i tre pezzi — distanza, priorità, link health monitor — e le combinazioni che l’esame ti chiede di riconoscere in un estratto di configurazione. Oggi lo strumento di elezione è SD-WAN, ma questo impianto classico resta il fondamento.

Con due default route, una per WAN, hai due strategie e non sono intercambiabili.

Distanze diverse, per esempio 10 e 20: solo la rotta con distanza più bassa entra nella routing table. La seconda esiste in configurazione ma non in tabella finché la prima non viene ritirata. Nessun bilanciamento possibile, è pura ridondanza.

Stessa distanza e priorità diverse: entrambe entrano in tabella e viene scelta come migliore quella con il valore di priorità più basso. Restano tutte e due attive, quindi puoi comunque spostare traffico specifico con una policy route.

config router static
    edit 1
        set dst 0.0.0.0 0.0.0.0
        set device "wan1"
        set gateway 10.10.10.1
        set distance 10
        set priority 1
    next
    edit 2
        set dst 0.0.0.0 0.0.0.0
        set device "wan2"
        set gateway 10.20.20.1
        set distance 10
        set priority 10
    next
end

Se il link cade fisicamente, il FortiGate rimuove da solo le rotte associate all’interfaccia. Il caso reale più frequente però è un altro: il gateway remoto o la rete a monte dell’ISP sono irraggiungibili mentre la porta è ancora up. Senza health monitor il FortiGate continua a instradare verso la WAN primaria e il traffico muore in silenzio.

Il monitor sonda un detect server, che conviene scegliere a qualche hop di distanza e non coincidente col gateway locale, con ping (default), tcp-echo, udp-echo, http, https o twamp.

config system link-monitor
    edit "wan1-mon"
        set srcintf "wan1"
        set server "208.91.112.53"
        set gateway-ip 10.10.10.1
        set protocol ping
        set interval 500
        set failtime 5
        set recoverytime 5
    next
end

interval è in millisecondi con default 500, failtime è il numero di sonde perse che dichiarano morto il server (default 5) e recoverytime quante risposte servono per dichiararlo recuperato (anch’esso 5). Abbassarli accelera il rilevamento e aumenta il traffico di controllo: è il compromesso che devi saper motivare.

Le opzioni che cambiano l’effetto della caduta sono cinque e vanno sapute a memoria. update-static-route, attivo di default, rimuove le rotte statiche associate. set route seguito da una o più subnet limita la rimozione a quelle destinazioni: se non ne elenchi nessuna cadono tutte le rotte con quell’interfaccia e quel gateway. update-policy-route decide se ritirare anche le policy route. update-cascade-interface, insieme a fail-detect sull’interfaccia, propaga il guasto ad altre interfacce. E service-detection fa l’opposto di tutti: usa il monitor solo per leggere i valori di qualità, senza toccare rotte né interfacce.

Lo stato si verifica con diagnose sys link-monitor status, che riporta alive o die, latenza, jitter, perdita e contatore dei fallimenti. Sulla singola rotta esiste infine link-monitor-exempt: abilitandolo la rotta resta in tabella anche a monitor caduto. Di default è disabilitato, cioè la rotta viene ritirata.

ECMP: quando due rotte restano entrambe attive

Se due rotte hanno la stessa destinazione e lo stesso costo — per le statiche significa stessa distanza e stessa priorità — e provengono dallo stesso protocollo, cioè statico, OSPF o BGP, entrano entrambe in tabella e il traffico viene bilanciato in ECMP. L’ECMP viene valutato dopo le policy route: una policy route che corrisponde vince comunque.

Gli algoritmi sono source-ip-based, il default, dove le sessioni della stessa sorgente seguono sempre la stessa strada; weight-based, che ripartisce le sessioni in proporzione al peso; usage-based, cioè spillover, che riempie un link fino alla soglia di banda e poi passa al successivo; e source-dest-ip-based.

config system settings
    set v4-ecmp-mode source-ip-based
    set ecmp-max-paths 255
end

ecmp-max-paths va da 1 a 255 con default 255, e portarlo a 1 equivale a disabilitare l’ECMP. Se SD-WAN è abilitato quell’opzione non è più disponibile e l’algoritmo si imposta con load-balance-mode dentro SD-WAN. Il peso invece si mette sulla singola rotta: con pesi 80 e 20 verso la stessa destinazione, l’80% delle sessioni prende la prima. Per bilanciare rotte BGP serve in più ebgp-multipath o ibgp-multipath, disabilitati di default.

Gli errori che si pagano in produzione

Il primo è la policy route con gateway esplicito. In un impianto con ridondanza e load sharing, la policy route che dirotta traffico sulla WAN secondaria non deve specificare il gateway: senza, il FortiGate lo cerca nella routing table, e quando il link monitor ritira quella rotta la policy route smette di corrispondere e il traffico torna sulla primaria. Col gateway scritto a mano, invece, la policy route resta valida e continua a spedire pacchetti in un buco nero.

Il secondo sono le firewall policy dimenticate: le rotte falliscono correttamente, ma il traffico resta fermo perché nessuna policy autorizza l’uscita dalla seconda WAN. Vanno duplicate.

Il terzo è il test fatto dall’interfaccia di backup. Con distanze diverse la rotta della WAN secondaria non è in tabella, quindi il traffico entrante da lì viene scartato dal reverse path look-up. Non è un guasto: è il controllo anti-spoofing che fa il suo lavoro.