Routing Ricorsivo, proviamo a capirci qualcosa
Questi sono appunti che mi sono preso mentre facevo dei test per capire meglio il concetto di routing ricorsivo in ROS 7. Nel mio particolare caso, lo uso solamente come trucco per vedere se un provider internet è funzionante oppure no, per fare failover con due provider diversi, ma sono sicuro che ci siano altri usi evoluti.
L'idea del routing ricorsivo è che posso indicare una rotta verso un gateway che non è direttamente connesso ad una mia interfaccia, e il Mikrotik capirà da solo che percorso usare per raggiungere questo gateway. La cosa che lo rende utile come metodo per vedere se un provider internet funziona è che in realtà alla fine non usa veramente il gateway che gli specifico per routare il traffico, altrimenti sarebbe molto dura fare funzionare una connessione internet quando cerco di usare 9.9.9.9 (un dns pubblico) come gateway.
Scenario iniziale
- Il router del mio provider e` 192.168.254.1, ed è connesso alla ether1 (WAN) del mio Mikrotik. Il mio Mikrotik è il 192.168.254.2
- Non ho definito una default route verso 192.168.254.1 per cui per il momento su internet proprio non ci vado.
Configurazione
- Creo una rotta con destinazione un singolo ip pubblico (tipo 9.9.9.9) attraverso un gateway (connesso direttamente, quindi per esempio il router del mio provider) e assegno a questa rotta uno scope di 11 (10 è lo scope di default di una rotta verso una rete connessa localmente, 11 è quindi un passo sopra). In queste condizioni io posso pingare 9.9.9.9 (ho la rotta) ma non il resto di internet (non ho la rotta per 0.0.0.0/0). Essendo questa rotta con target-scope 10, questa rotta fa uso, per capire come raggiungere il gateway 192.168.254.1, della rotta (automatica, creata quando configuro l'interfaccia ether1) verso la rete 192.168.254.0/24, che è direttamente connessa, e quindi ha scope 10 di default.
/ip/route add disabled=no distance=1 dst-address=9.9.9.9/32 gateway=192.168.254.1 routing-table=main scope=11 target-scope=10
- A questo punto creo una rotta (insensata, apparentemente) che dice che per andare su internet (0.0.0.0/0) devo usare come gateway 9.9.9.9, con un target-scope di 11 e uno scope di 30 (default per le rotte statiche, ma non importa, basta che sia un numero sensato). Il Mikrotik, in virtù di quello che gli ho detto in precedenza si rende conto che per andare verso 9.9.9.9, che NON è direttamente connesso a ether1 (né ad alcuna interfaccia a dire il vero), deve passare per il nostro vero gateway (192.168.254.1), e quindi invece di mandare il traffico per internet verso 9.9.9.9 (come gli dico di fare) manda il traffico per internet verso il GW connesso localmente (192.168.254.1) e non verso 9.9.9.9, il quale ovviamente non funzionerebbe.
/ip/route add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=9.9.9.9 routing-table=main scope=30 target-scope=11
- Notare che nel comando che ho appena usato ho impostato "check-gateway=ping" il quale pinga il 9.9.9.9 (che e` il gateway che gli ho detto di usare) e non 192.168.254.1 (che e` il vero gateway direttamente connesso). In questo modo ho di fatto creato una rotta che ha un gateway "VERO" che e` 192.168.254.1 che e` connesso direttamente (e che il router "scopre" da solo quando ragiona su come raggiungere il gateway "fasullo" 9.9.9.9), e un gateway "fasullo" che e` 9.9.9.9 il quale viene usato di fatto solo come target del nostro ping. In questo modo il Mikrotik farà un ping a 9.9.9.9 per vedere se la rotta è usabile, e quindi se muore internet la renderà disattiva, il che è lo scopo che volevo raggiungere.
Capiamo meglio cosa succede
Con il comando /routing/route/print che mostra cosa "pensa" il router delle varie rotte, si può capire la logica che il sistema operativo del Mikrotik usa:
/routing/route/print Flags: X - DISABLED, F - FILTERED, A - ACTIVE; c - CONNECT, s - STATIC; H - HW-OFFLOADED DST-ADDRESS GATEWAY AFI DISTANCE SCOPE TARGET-SCOPE IMMEDIATE-GW As 0.0.0.0/0 9.9.9.9 ip4 1 40 11 192.168.254.1%ether1 As 9.9.9.9/32 192.168.254.1 ip4 1 11 10 192.168.254.1%ether1 Ac 192.168.88.0/24 bridge ip4 0 10 5 bridge Ac 192.168.254.0/24 ether1 ip4 0 10 5 ether1 Ac ::1/128 lo ip6 0 10 5 lo Ac fe80::%ether1/64 ether1 ip6 0 10 5 ether1 Ac fe80::%bridge/64 bridge ip6 0 10 5 bridge A H lo link 0 A H ether1 link 0 A H ether4 link 0 A H bridge link 0- Nella riga 1 si vede che pensa che 0.0.0.0/0 debba andare verso l' IMMEDIATE-GW 192.168.254.1 (che si e` scoperto da solo, non l'ho detto io)
- Nella riga 2 si vede che gli ho detto che 9.9.9.9 passa per 192.168.254.1.
- Nella riga 3 si vede la rotta per la nostra LAN (che non ci interessa)
- Nella riga 4 si vede la rotta DIRETTAMENTE CONNESSA per la rete 192.168.254.0/24 dove si trova il gateway "vero" 192.168.254.1
Il sistema fa quindi questo ragionamento: se per andare verso internet (0.0.0.0) devo passare per 9.9.9.9, ma per andare a 9.9.9.9 devo passare per 192.168.254.1, allora per andare verso internet devo passare per 192.168.254.1. In questo modo contorto ottengo quello che voglio, e cioè:
- il router manda il traffico per internet verso 192.168.254.1 che e` il mio VERO gateway
- il router per vedere se il mio gateway e` online pinga 9.9.9.9, che` il mio "canarino della miniera" per vedere se internet è viva.
In questo modo ho una rotta verso il mondo che passa per 192.168.254.1 che però viene resa inattiva se smetto di raggiungere con il ping l' indirizzo 9.9.9.9 (anche se 192.168.254.1 pinga ancora), il che è esattamente ciò che volevo, capire che è morta la linea esterna anche se il router del provider (192.168.254.1) che è fisicamente in casa mia è ancora raggiungibile perché il guasto è FUORI DI CASA MIA.
Quando tutto questo non serve
Vale la pena di notare che tutto questo casino è pressoché inutile se uso il protocollo PPPoE direttamente dal Mikrotik perché in questo caso se muore la linea (fuori casa) il PPPoE va giù e quindi le rotte che passano per la interfaccia vanno giù da sole. L'unico caso in cui avrebbe senso usare questo trucco anche con PPPoE è se il PPPoE rimanesse su ma morisse il backbone del provider, causando così una condizione di guasto equivalente a quella di prima, nella quale pingo il GW direttamente connesso (il BRAS del provider, dove termina il mio PPPoE) ma poi non vado su internet, che si trova dietro il backbone del provider. Questo è un caso talmente remoto che non vale la pena di sbattersi secondo me.