I seguenti test sono stati effettuati sulla base della topologia SD-WAN enterprise costruita e configurata nel precedente articolo.
Traffico Internet – Fail di un link
Come primo test simuliamo il fail di un link e vediamo come si comporta il traffico verso Internet. Da un Virtual PC collegato in LAN del Branch1 lanciamo un ping continuo verso l’ip del DNS Google 8.8.4.4:
È possibile constatare nella sezione relativa alle SD-WAN Rules che l’interfaccia di uscita selezionata è Port1 per via delle migliori performance misurate rispetto a Port2:
Impostando uno sniffer sul firewall possiamo vedere nel dettaglio i pacchetti icmp echo request diretti all’host 8.8.4.4 che arrivano in ingresso sulla port3 e, una volta processati, vengono fatti uscire dalla port1 con nat di sorgente sull’ip 100.10.10.1. Le risposte naturalmente seguono il path inverso: i pacchetti icmp echo reply entrano da port1 e vengono inviati dalla port3 all’host 172.16.10.1
A questo punto simuliamo il fail della connettività spegnendo il router collegato alla port1. Dal VPC in LAN del Branch1 stiamo continuando a pingare l’ip 8.8.4.4, non appena viene spento il router due richieste icmp vanno in timeout e subito dopo ritorna a pingare.
Quando si verifica l’interruzione di connettività i performance sla la rilevano e dichiarano la port1 e le interfacce vpn annesse come “dead” mentre le altre interfacce rimangono in stato “alive”.
La tabella di routing viene dunque aggiornata rimuovendo le interfacce in stato “dead”.
Nella sezione relativa alle SD-WAN rules possiamo vedere che ora l’interfaccia designata per il traffico internet è port2:
Per controprova lo sniffer impostato sul firewall mostra i pacchetti icmp echo request diretti all’host 8.8.4.4 che arrivano in ingresso sulla port3 e vengono fatti uscire dalla port2 con nat di sorgente sull’ip 200.10.10.1. Le risposte seguono il path inverso: i pacchetti icmp echo reply entrano da port2 e vengono inviati dalla port3 all’host 172.16.10.1.
Ripristinando il router connesso alla port1 dopo un breve periodo di tempo il traffico torna ad essere rediretto verso tale interfaccia di uscita senza nessuna perdita di pacchetti.
Traffico verso HUB – Interface Preference
Come secondo test andiamo a modificare la rule SD-WAN per il traffico diretto al DC, impostando che venga utilizzato preferenzialmente il link attestato sulla port2 e dunque la VPN “WAN2-DC”. Attualmente la rule specifica è configurata con criterio latency e l’intefaccia scelta è “WAN1-DC”.
Se dal VPC in LAN sul Branch1 proviamo a pingare l’ip dell’interfaccia LAN del FortiGate DC vediamo come il traffico venga instradato attraverso quest’ultimo tunnel VPN.
A questo punto editiamo il Performance SLA “pingDC” definito in precedenza ed andiamo ad impostare uno SLA target:
Andando in edit sulla SD-WAN rule ora modifichiamo la strategia in Lowest Cost (SLA) e modifichiamo l’ordine delle interfacce inserendo come preferenziale WAN2-DC. Come SLA target selezioniamo “PingDC”.
A questo punto i pacchetti che prima venivano instradati attraverso il tunnel VPN “WAN1-DC” cominciano ad essere inviati al DC attraverso il nuovo tunnel preferenziale:
Dallo Sniffer si può vedere esattamente il cambio di instradamento che per l’utente (in questo caso il VPC) risulta del tutto trasparente.
A questo punto se si verifica un fail della connettività attestata sulla port2 notiamo come senza nessuna perdita di pacchetti il traffico sia rediretto sull’altro tunnel:
Traffico Branch 2 Branch – Ridondanza e Business Continuity
Come terzo Test verifichiamo la comunicazione tra Branch la quale avviene attraverso i due HUB. Nello specifico la rule SD-WAN che permette questo traffico utilizza il link con minor latenza che attualmente è WAN1-HQ per via delle migliori performance.
Cosa succederebbe se HQ avesse un disservizio infrastrutturale tale da determinare la non raggiungibilità del Firewall? Per provarlo spegniamo l’appliance HQ lasciando un ping continuo verso il Branch2 172.16.20.254:
Possiamo notare che vengono persi due pacchetti dovuti all’aggiornamento delle tabelle arp dei dispositivi, dopodiché il traffico torna a fluire senza problemi. Dallo sniffer sul Fortigate Branch1 possiamo apprezzare il cambio di interfaccia di uscita per le richieste icmp (da WAN1-HQ a WAN1-DC).
Nella SD-WAN rule possiamo poi notare che l’interfaccia selezionata ora è proprio WAN1-DC.
