Con SD-WAN attivo, la domanda «da quale interfaccia esce questo pacchetto» non ha più una risposta sola: decidono in cascata il policy routing, la strategia della regola e la tabella di routing. Quando il traffico non esce da dove ti aspetti, il lavoro è capire a quale di questi livelli si è rotto.

L’ordine di lookup: le regole SD-WAN vengono prima della FIB

Il FortiGate cerca la strada in quest’ordine: prima le policy route, poi la FIB, e se non c’è match il pacchetto viene scartato. Le regole SD-WAN sono policy route a tutti gli effetti: le vedi con diagnose firewall proute list, marcate dal campo vwl_service. Una regola SD-WAN che combacia batte quindi la tabella di routing, e con essa ECMP, che è valutato dopo il policy routing.

Il corollario è la parte che si sbaglia più spesso: la regola non inventa percorsi, sceglie fra i membri che hanno già una rotta valida verso quella destinazione. Prima si costruisce il routing, poi si fa steering. Il lookup avviene di norma due volte per sessione, sul primo pacchetto dell’iniziatore e sul primo di risposta, e l’esito finisce nella session table.

Le strategie di una regola

La strategia decide come cambia l’ordine dei membri al variare della qualità dei link. Manual è il default e non usa health check: i membri si usano nell’ordine in cui li hai messi in priority-members. È una policy route con in più il routing per applicazione e per route tag BGP. Il parametro hold-down-time regola quanto attendere prima di rientrare sul link primario dopo un failover.

Best Quality, mode priority in CLI, confronta una sola metrica scelta con link-cost-factor: latency, jitter, packet-loss, le tre varianti di banda (che leggono i valori di banda stimata configurati sull’interfaccia) o un custom-profile-1 con pesi. Qui sta la trappola più elegante dell’argomento: link-cost-threshold vale 10 per default e concede un vantaggio del 10% al primo membro configurato. Con due link entrambi a 200 ms, il primo viene valutato come 200/1,1, circa 182 ms, e vince pur essendo identico.

Lowest Cost (SLA), mode sla, sceglie fra i membri che soddisfano il target quello con cost più basso; a parità di costo vale l’ordine di configurazione. Se un solo link soddisfa l’SLA viene usato quello, anche se costa di più; se nessuno lo soddisfa si torna al più economico. Il comando minimum-sla-meet-members impone un minimo di link in SLA perché la regola si applichi.

Il load balancing non è più una strategia separata: quella che fino alla 7.4.1 si chiamava maximize bandwidth ora si abilita con set load-balance enable dentro una regola manual (senza target SLA) o dentro una sla (con i target). L’hash method di default è round-robin, l’unico disponibile in GUI. Esiste infine mode auto, legacy e solo da CLI: se apri quella regola in GUI l’impostazione viene sovrascritta.

La regola implicita e ECMP

Quando nessuna regola esplicita combacia si applica la regola implicita, che è l’ECMP di SD-WAN. Gli algoritmi sono cinque: Source IP (il default), Sessions, Spillover, Source-Destination IP e Volume, quest’ultimo esclusivo di SD-WAN. Non puoi escludere un’interfaccia dal bilanciamento implicito: un peso o un volume a zero vengono trattati come uno.

Perché due rotte finiscano in ECMP devono avere stessa destinazione, stessi costi e stessa origine. Per le statiche «stessi costi» significa stessa distanza e stessa priorità: alzare la priorità di una rotta è il modo corretto per tirarla fuori dal bilanciamento. Nota infine che con SD-WAN abilitato v4-ecmp-mode non è più disponibile sotto config system settings: l’algoritmo si imposta con load-balance-mode dentro config system sdwan.

Leggere lo stato

Tre comandi coprono quasi tutto.

diagnose sys sdwan health-check
diagnose sys sdwan member
diagnose sys sdwan service4 1

Il primo mostra per ogni membro state(alive) o state(dead), packet-loss, latency, jitter e sla_map, che è una maschera di bit sui target SLA: 0x0 nessun target superato, 0x1 il primo superato.

Il secondo cambia forma con l’algoritmo: in weight-based aggiunge il session count, in measured-volume-based mostra volume room oppure overload volume, in usage-based le soglie di spillover con i flag egress-overbps e ingress-overbps.

Il terzo è il più informativo. La riga Mode() dichiara la strategia realmente in uso, i membri compaiono nell’ordine in cui verranno provati e selected marca quelli eleggibili. In mode sla trovi anche cfg_order e cost, cioè i due criteri con cui la scelta è stata fatta.

Un dettaglio da non confondere: nella pagina Performance SLAs la freccia verde dice che il server sta rispondendo, non che l’SLA sia rispettato. Per lo storico, diagnose sys sdwan sla-log tiene dieci minuti di misure e diagnose sys sdwan intf-sla-log quindici minuti di banda usata; oltre serve FortiAnalyzer, con la frequenza dei log regolata da sla-fail-log-period e sla-pass-log-period.

failtime (in GUI Failures before inactive) e recoverytime (Restore link after) valgono 5 per default ed esistono per evitare il flapping. Con update-static-route abilitato, quando un membro diventa inattivo vengono ritirate tutte le rotte statiche su quell’interfaccia, non solo quella verso il server sondato. E se sul membro insistono più health check, devono fallire tutti perché le rotte spariscano.

Quando più membri di una zona soddisfano l’SLA, il pareggio lo rompe service-sla-tie-break: cfg-order (ordine di configurazione) è il default, fib-best-match sceglie fra i membri che corrispondono al prefisso più lungo in tabella, input-device usa l’interfaccia di ingresso.