Supponiamo di avere un ambiente dual ISP. ed avere configurato due rotte statiche di default sull’interfaccia esterna del firewall, che puntino a due router differenti (come in figura).

Se le due connessioni hanno velocità molto diverse, si può usare la più veloce come primaria, e l’altra come linea di backup.

Ma se le due connessioni hanno prestazioni simili, preferiremo avere uno sfruttamento completo delle due linee, con il failover sulla linea superstite in caso di guasto di una delle due connessioni.

In questo caso il firewall esegue un ragionevole bilanciamento di carico sulle due rotte.

In sostanza abbiamo una configurazione di default route di questo tipo:

S* 0.0.0.0 0.0.0.0 [1/0] via 192.168.30.2, outside
[1/0] via 192.168.30.1, outside

Se non facciamo altro, il bilanciamento funziona, ma non c’è failover. Il firewall non ha alcun modo di verificare se le due linee esterne sono attive o no, continua a vedere l’interfaccia interna del router come up, inviando perciò pacchetti su un router che in realtà non ha più connessione esterna.

Ad evitare questo problema, possiamo configurare lo Static Route Tracking, vale a dire il monitoraggio delle rotte statiche.

Static Route Tracking

In sostanza ill firewall invia ad intervalli regolari un pacchetto, ad esempio un ping, verso un host che sappiamo essere costantemente up (al meglio delle nostre conoscenze) e ne osserva la risposta. Se ad un certo punto non ottene più ping reply, elimina la rotta, e ridirigere il traffico sull’altra.

Configurazione

Lo Static Route Tracking si configura così:

innanzi tutto scegliamo un target affidabile per il monitoraggio; può essere un dns fornito dal provider, o comunque l’indirizzo di un host che sappiamo essere costantemente up e che risponda al ping. Useremo nell’esempio l’host 1.1.1.1

definiamo un processo di monitor (indicato da sla_id, è un numero a nostra scelta)

sla monitor sla_id

con questo comando entriamo in modalità di configurazione dello sla-monitor (vale a dire di configurazione dello Static Route Tracking SRT).

Configuriamo adesso il tipo di protocollo di monitoring, l’host da usare e l’interfaccia attraverso cui il monitoraggio sarà effettuato (sarà la stessa su cui sono configurate le rotte statiche, naturalmente)

type echo protocol ipIcmpEcho 1.1.1.1 interface outside
(il protocollo è icmp Echo, l’host target è 1.1.1.1, l’interfaccia di uscita è outside)

per ogni invio di test, stabiliamo quanti pacchetti inviamo (3 in questo caso)

num-packets 3

ogni quanto inviamo i pacchetti con il comando frequency (300 secondi)

frequency 300

e con il comando threshold per quanto tempo (in msec. attendiamo la risposta prima di considerare in fail il link)

threshold 150

Una configurazione dello SRT ha quindi un aspetto come quello qui di seguito:

sla monitor 1
type echo protocol ipIcmpEcho 8.8.8.8 interface outside
num-packets 3
threshold 150
frequency 300

 

Stabilito che questo è un processo di monitoraggio, dobbiamo decidere quando avviarlo; per questo usiamo il comando sla monitor schedule:

sla monitor schedule 1 life forever start-time now

in questo caso: 1 è lo sla_id, life forever inica che il task deve essere eseguito per sempre, start-time now significa che deve essere avviato subito.

La stessa cosa facciamo per definire un secondo task di monitoraggio, che può usare gli stessi parametri, in termini di frequenza, numero di pacchetti etc.) o parametri diversi.

Associare il monitoraggio ad una route

Non abbiamo ancora associato il task ad una rotta specifica; per fare questo le rotte di default debbono essere configurate con una tracking id, un identificatore numerico che le contrassegna, in questo modo:

route outside 0.0.0.0 0.0.0.0 192.168.30.1 64 track 1
route outside 0.0.0.0 0.0.0.0 192.168.30.2 64 track 2

Notiamo la distanza amministrativa, che è uguale (64) e maggiore di 1. A questo punto possiamo associare le due route al processo di monitoraggi:
!
track 1 rtr 1 reachability
!
track 2 rtr2 reachability

Ora il problema è che la configurazione, fatta in questo modo, non funziona. Il monitoraggio è un processo associato all’interfaccia, per cui il pacchetto viene instradato verso outside, e sottoposto a bilanciamento. Il risultato è che NON SAPPIAMO se il processo di tracking 1, ad esempio, passerà dal gateway 1 o 2, per cui se anche un link va giù il processo di monitoring non lo riconosce.

Per forzare ASA ad usare la rotta per il gateway 1 per verificare il target 1 dobbiamo aggiungere due rotte statiche verso i due target:

route outside 1.1.1.1 255.255.255.255 192.168.30.1 1
route outside 2.2.2.2 255.255.255.255 192.168.30.2 1

La distanza amministrativa delle due static (1) è inferiore a quella delle rotte di default, per cui verranno usate per prime, ed i pacchetti di monitoraggio saranno indirizzati attraverso le rotte corrette.

Di seguito un tracciato del comando sh sla monitor operational-state che ci fornisce informazioni sui processi di moniotarggio, sulle perdite di conessione e sullo stato dei link.

ciscoasa# sh sla monitor  operational-state 1
Entry number: 1
Modification time: 13:15:32.721 CEST Sat Jan 14 2017
Number of Octets Used by this Entry: 1480
Number of operations attempted: 17
Number of operations skipped: 0
Current seconds left in Life: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Connection loss occurred: FALSE
Timeout occurred: TRUE
Over thresholds occurred: FALSE