Guida MikroTik
RoutingIntermedio

Failover che testa Internet davvero: recursive next-hop e Netwatch

Supera il limite di check-gateway implementando un failover dual-WAN che verifica la raggiungibilità reale di Internet con recursive next-hop (target-scope) e con script Netwatch.

Il problema: 'il link è su ma Internet è giù'

check-gateway=ping verifica solo il primo hop (il gateway dell'ISP). Ma il guasto più frequente per un WISP non è il gateway locale: è l'upstream dell'ISP che cade, il peering che si interrompe, il DNS dell'operatore che muore. In tutti questi casi il gateway risponde ancora al ping, check-gateway resta soddisfatto, la rotta primaria resta attiva e i clienti non navigano. Servono tecniche che testino un host oltre l'ISP.

Soluzione 1: recursive next-hop (solo routing, nessuno script)

L'idea è elegante: invece di puntare la default route direttamente al gateway ISP, la si punta a un IP pubblico ben raggiungibile (es. 1.1.1.1) e si forza RouterOS a risolvere quel next-hop in modo ricorsivo solo attraverso quel link. Poi si applica check-gateway=ping a questa rotta ricorsiva: se 1.1.1.1 smette di rispondere via ISP1, l'intera default route ISP1 si disattiva e subentra ISP2. Si testa così la raggiungibilità reale di un host su Internet, non solo il gateway.

Failover con recursive next-hop (target-scope)
# 1. Rotta 'scout' /32: per raggiungere 1.1.1.1 passa OBBLIGATORIAMENTE dal gateway ISP1.
#    scope=10 così potrà risolvere il next-hop ricorsivo qui sotto.
/ip/route/add dst-address=1.1.1.1/32 gateway=203.0.113.1 scope=10 \
  check-gateway=ping comment="Scout ISP1 -> 1.1.1.1"

# 2. Default ISP1 ricorsiva: il gateway NON è il router ISP ma 1.1.1.1.
#    target-scope=11 (> scope della scout) abilita la risoluzione ricorsiva.
/ip/route/add dst-address=0.0.0.0/0 gateway=1.1.1.1 target-scope=11 \
  distance=1 comment="Default ISP1 (recursive)"

# 3. Stessa logica per ISP2, con un IP scout DIVERSO (8.8.8.8) per non sovrapporsi
/ip/route/add dst-address=8.8.8.8/32 gateway=198.51.100.1 scope=10 \
  check-gateway=ping comment="Scout ISP2 -> 8.8.8.8"
/ip/route/add dst-address=0.0.0.0/0 gateway=8.8.8.8 target-scope=11 \
  distance=2 comment="Default ISP2 (recursive)"
Usa un IP scout DIVERSO per ogni WAN (1.1.1.1 per ISP1, 8.8.8.8 per ISP2). Se usassi lo stesso IP per entrambe, le due rotte scout entrerebbero in conflitto sulla risoluzione. Scegli host molto stabili e che NON filtrino l'ICMP (1.1.1.1, 8.8.8.8, 9.9.9.9 sono buoni candidati).
Effetto collaterale: il traffico verso quei /32 scout esce SEMPRE dal link assegnato. Trascurabile (è solo 1.1.1.1 e 8.8.8.8), ma se quei DNS sono usati dai clienti tienine conto. In alternativa puoi usare IP scout 'neutri' non destinati ai client.

Soluzione 2: Netwatch con script (controllo totale, anche azioni custom)

Netwatch (/tool/netwatch) effettua ping periodici verso un host e lancia uno script on-up/on-down. È più flessibile del recursive: puoi cambiare rotte, mandare notifiche, svuotare il connection tracking, loggare. Il trucco per il multi-WAN è creare una entry Netwatch che pinga un host esterno forzando l'uscita dall'ISP1 (tramite la rotta scout /32 vista sopra), e negli script abilitare/disabilitare la default ISP2.

Netwatch: failover con commenti per individuare le rotte
# Pre-requisito: la default ISP2 ha comment="ISP2-backup" e parte DISABILITATA
/ip/route/set [find comment="ISP2-backup"] disabled=yes

# Rotta scout /32 per testare Internet attraverso ISP1
/ip/route/add dst-address=1.1.1.1/32 gateway=203.0.113.1 comment="scout-isp1"

# Netwatch verso 1.1.1.1 (che, grazie alla scout, esce solo da ISP1)
/tool/netwatch/add host=1.1.1.1 interval=10s timeout=2s type=icmp \
  down-script="/ip/route/enable [find comment=\"ISP2-backup\"]; /log/warning \"ISP1 DOWN: attivo ISP2\"; /ip/firewall/connection/remove [find]" \
  up-script="/ip/route/disable [find comment=\"ISP2-backup\"]; /log/info \"ISP1 UP: torno su ISP1\"; /ip/firewall/connection/remove [find]"

# Verifica stato
/tool/netwatch/print
Lo svuotamento di /ip/firewall/connection nello script forza le sessioni TCP a re-instradarsi sul nuovo link subito dopo lo switch. È quasi sempre desiderabile in un failover, ma interrompe tutte le connessioni attive (download, chiamate VoIP) per un istante.

Quale scegliere

AspettoRecursive next-hopNetwatch + script
ComplessitàBassa (solo rotte)Media (richiede script)
Testa Internet reale
Azioni extra (log, flush, notifiche)No
Velocità di reazione~10-30 s (check-gateway)Configurabile (interval/timeout)
Consigliato perFailover semplice e robustoLogiche custom / notifiche
Recursive next-hop vs Netwatch
Per la maggior parte dei WISP il recursive next-hop è la scelta migliore: è dichiarativo, non ha script da manutenere e sopravvive ai reboot senza sorprese. Passa a Netwatch quando ti servono azioni collaterali (notifica Telegram, flush mirato, switch di più rotte insieme).
recursive next-hoprecursive routingnetwatchfailovermulti-wantarget-scopecheck-gateway1.1.1.18.8.8.8dual-waninternet up detection

Configura senza fatica con l'AI

In WispOS l'agente AI genera la configurazione RouterOS dalle tue parole e un tutor ti guida passo passo.

Prova WispOS