WAN Failover per router Mikrotik

La disponibilità della connettività internet è ormai un requisito essenziale nelle aziende, ma anche per i privati che spesso non disdegnano di associare una linea di backup a quella principale di casa.

Nel caso delle routerboard gestire il failover su più linee di uscita è piuttosto semplice. Nel nostro caso per semplificare la comprensione della configurazione immaginiamo di avere questo scenario, con la ether1 sulla WAN Principale ADSL e la ether2 sulla WAN Secondaria, connessa ad un modem LTE e la rete locale sulla LAN ether3.

La configurazione per la nostra routerboard:

• ether1–> WAN1 (IP GW1 192.168.1.254)
• ether2–> WAN2 (IP GW2 192.168.2.254)
• ether3–> LAN (IP 192.168.3.1/24)

[admin@MikroTik-MASTER] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic 
# ADDRESS NETWORK INTERFACE 
0 ;;; defconf 
1 192.168.1.1/24 192.168.1.0 ether1-WAN1
2 192.168.2.1/24 192.168.2.0 ether2-WAN2 
3 192.168.3.1/24 192.168.3.0 ether3-LAN

A questo punto impostare il failover sulla nostra routerbaord è semplicissimo. Come detto, ipotizziamo di disporre di due percorsi per Internet, è possibile impostarne uno come principale e, se si interrompe, eseguire il failover sul secondario.

Simple Failover: la configurazione più semplice

In questo esempio, vediamo che il gateway primario (o preferito) è il 192.168.1.254 e il gateway secondario (di backup) è il 192.168.2.254
Il routing viene impostato utilizzando i comandi:

/ip route
add gateway=192.168.1.254 distance=1 check-gateway=ping comment="Primary WAN1"
add gateway=192.168.2.254 distance=2 comment="Secondary WAN2"

Come si può notare, omettendo il parametro dst-address, questo imposta la route predefinita su 0.0.0.0/0.

Questo funziona perché la distanza fino a 192.168.1.254 è 1 (hop) e la distanza fino a 192.168.2.254 è 2 (hop), quindi finché è possibile eseguire il ping 192.168.1.254, il primario verrà utilizzato poiché la distanza è più breve. Se non è possibile eseguire il ping 192.168.1.254, questo percorso non sarà disponibile e il percorso predefinito diventerà 192.168.2.254. Una volta che 192.168.1.254 inizia a rispondere ai ping, verrà utilizzata nuovamente la route principale, in pratica si ripristina il routing principale automaticamente (WAN1).

Recursive Failover: perfezioniamo la configurazione

Il problema con il metodo semplice è che esegue il ping solo del router adiacente, in pratica si testa la portante del cavo. In questo modo si presume che finché il router può essere raggiunto, il percorso è attivo. Questa crea un problema, infatti se uno dei dispositivi oltre il router adiacente è inattivo, il metodo semplice non lo rileva e la configurazione non effettua lo switch tra le due WAN.
La soluzione è utilizzare un percorso ricorsivo. Il percorso ricorsivo utilizza una destinazione remota per convalidare l’intero percorso. Occorre definire un IP affidabile, che definiremo come obiettivo per il nostro monitoraggio. Un IP molto popolare ed affidabile è il server DNS di Google 8.8.8.8.
Mi raccomando, è importante selezionare una destinazione che sia molto affidabile, perché quando la destinazione non risponde ai ping, il percorso verrà contrassegnato come non disponibile.

Il percorso ricorsivo viene impostato utilizzando i comandi:

/ip route
add dst-address=8.8.8.8 gateway=192.168.1.254 scope=10 comment="Validate Primary"
add gateway=8.8.8.8 distance=1 check-gateway=ping comment="Primary WAN1"
add gateway=192.168.2.254 distance=2 comment="Secondary WAN2"

• La prima riga imposta il percorso del server DNS di Google 8.8.8.8 tramite il gateway principale 192.168.1.254. Questo stabilisce il gateway per questo percorso. Il valore scope=10 imposta l’ambito uguale all’ambito di destinazione (che per impostazione predefinita è 10) in modo che il router utilizzerà questo gateway solo per raggiungere 8.8.8.8.
• La seconda riga imposta la rotta predefinita primaria in modo che sia la stessa della rotta su 8.8.8.8. La distanza 1 lo rende il percorso principale. Il percorso verrà verificato eseguendo un ping verso 8.8.8.8. Questo è il percorso ricorsivo, perché deriva il suo gateway e lo stato da qualcosa di diverso dal router vicino. L’assenza di dst-address implica che questa sia la route predefinita.
• La terza linea è il percorso secondario ed è invariato rispetto al metodo semplice.

Quando 8.8.8.8 non risponde ai ping, il percorso principale verrà contrassegnato come inattivo e verrà utilizzato il percorso secondario. Il router continuerà a provare a eseguire il ping 8.8.8.8 sul gateway principale e quando inizierà a rispondere di nuovo ai ping, verrà nuovamente utilizzata la route principale.

Limitazioni di questa soluzione

Qualunque sia l’IP che scegliamo di utilizzare come destinazione, questo  è raggiungibile solo tramite il percorso principale. Se il percorso principale è inattivo, quell’indirizzo IP non sarà raggiungibile. Ecco perchè se utilizziamo l’IP 8.8.8.8 per risolvere il DNS, il servizio DNS sarà inattivo quando il percorso principale è inattivo. Pertanto, se si utilizza Google per DNS e si utilizza 8.8.8.8 come destinazione di routing, è necessario utilizzare invece un server DNS di Google diverso, come ad esempio il 8.8.4.4.

Prestazione

Quando il percorso principale si interrompe, il router impiega circa 30 secondi per decidere che i ping sono persi e l’obiettivo è irraggiungibile e passa al percorso secondario. Una volta che i ping ricevono nuovamente risposta dal percorso principale, il router tornerà immediatamente al percorso principale, quindi il passaggio al percorso principale avviene in pochi secondi.