Differences

This shows you the differences between two versions of the page.

--- mikrotik:multiwan:netwatch [2025/09/20 12:51] – created - external edit 127.0.0.1
+++ mikrotik:multiwan:netwatch [2025/09/21 18:20] (current) – kurgan
@@ Line 7: / Line 7: @@
 ===== Principio di funzionamento =====
-Il sistema è simile a quello usato per causare il failover. Prendendo come esempio la configurazione che trovate qui [[../Failover]], quello che facciamo è pingare ogni tot secondi un host (9.9.9.9 nel caso in esempio) per il quale abbiamo definito una rotta che funziona solo attraverso una delle due connessioni WAN e non attraverso l'altra. Se il ping non funziona, supponiamo che la connessione WAN in questione sia morta, e mandiamo una mail (attraverso l'altra connessione, ovviamente) per avvisare. Quando torna a funzionare, con lo stesso meccanismo mandiamo una mail che dice che la nostra WAN è tornata viva.
+Il sistema è simile a quello usato per causare il failover. Prendendo come esempio la configurazione che trovate qui [[Failover]], quello che facciamo è pingare ogni tot secondi un host (9.9.9.9 nel caso in esempio) per il quale abbiamo definito una rotta che funziona solo attraverso una delle due connessioni WAN e non attraverso l'altra. Se il ping non funziona, supponiamo che la connessione WAN in questione sia morta, e mandiamo una mail (attraverso l'altra connessione, ovviamente) per avvisare. Quando torna a funzionare, con lo stesso meccanismo mandiamo una mail che dice che la nostra WAN è tornata viva.
 Dal momento che la funzione "netwatch" non è sincrona con la funzione di check-gateway che viene usata per il failover, è possibile (anzi, è sicuro) che nel momento del guasto i due meccanismi scatteranno non nello stesso momento. Questo non è un problema enorme di per sé ma lo diventa se il netwatch cerca di mandare la mail prima che il failover avvenga, in quanto in questo caso fallirà, essendo il routing verso internet ancora configurato verso la connessione WAN che non sta funzionando. Per ovviare a questo problema basta introdurre nello script un ritardo di abbastanza secondi da essere sicuri che il check-gateway abbia avuto il tempo di intervenire e causare il failover.
@@ Line 15: / Line 15: @@
 La configurazione richiede due passaggi, ovvero configurare il sistema per inviare email e poi configurare netwatch per lanciare lo script che invia la mail.
-  * Prima di tutto configuriamo il sistema per inviare email, usando la funzione ''tool/email''. Qui definiamo il server SMTP da usare ed eventualmente il metodo di autenticazione che dobbiamo usare. In questo esempio faccio uso di un server che non richiede autenticazione e quindi la configurazione è semplicissima. Il "from" è un indirizzo arbitrario che viene usato come mittente delle email, non è necessario che esista. Qui non definisco il destinatario, lo farò dopo.
+  * Prima di tutto configuriamo il sistema per inviare email, usando la funzione ''tool/email''. Qui definiamo il server SMTP da usare ed eventualmente il metodo di autenticazione che dobbiamo usare. In questo esempio faccio uso di un server che non richiede autenticazione e quindi la configurazione è semplicissima. Il "from" è un indirizzo arbitrario che viene usato come mittente delle email, non è necessario che esista. Qui non definisco il destinatario, lo farò dopo.<code>
-<code>
 /tool/e-mail
 set from=<mikrotik-alerts@ILTUODOMINIO.TLD> server=mail.iltuodominio.tld
 </code>
-  * Poi configuriamo una istanza di netwatch per controllare la connettività di una delle due WAN. In questo esempio è la primaria che voglio controllare, e non mi interesso (e faccio male, sarebbe utile) dello stato della secondaria. Ribadisco che questa configurazione, che usa 9.9.9.9 come host di riferimento per il ping, funziona solo se ho configurato una rotta statica tale per cui 9.9.9.9 può essere raggiunto solo sulla connettività che voglio tenere sotto controllo e non sull'altra. Chiaramente se voglio controllare più di una connettività, dovrò duplicare la configurazione per le altre, usando come host di riferimento altri host remoti.
+  * Poi configuriamo una istanza di netwatch per controllare la connettività di una delle due WAN. In questo esempio è la primaria che voglio controllare, e non mi interesso (e faccio male, sarebbe utile) dello stato della secondaria. Ribadisco che questa configurazione, che usa 9.9.9.9 come host di riferimento per il ping, funziona solo se ho configurato una rotta statica tale per cui 9.9.9.9 può essere raggiunto solo sulla connettività che voglio tenere sotto controllo e non sull'altra. Chiaramente se voglio controllare più di una connettività, dovrò duplicare la configurazione per le altre, usando come host di riferimento altri host remoti.<code>
-<code>
 /tool/netwatch
 add host=9.9.9.9 interval=1m name=Quad9 timeout=2s type=simple comment="Check connessione" disabled=no down-script="delay 20s; tool e-mail send to=LATUAEMAIL@ILTUODOMINIO.TLD subject=([/system identity get name].\" Internet DOWN\") body=(\"Since \$since \\r\\n Host \$host\")" up-script="delay 10s; tool e-mail send to=LATUAEMAIL@ILTUODOMINIO.TLD subject=([/system identity get name].\" Internet UP\") body=(\"Since \$since \\r\\n Host \$host\")"
 </code>
 ----
@@ Line 38: / Line 36: @@
 La configurazione richiede due passaggi, ovvero configurare il sistema per inviare email e poi configurare uno o due (o enne) profili PPP per lanciare lo script che invia la mail.
-  * Prima di tutto configuriamo il sistema per inviare email, usando la funzione ''tool/email''. Qui definiamo il server SMTP da usare ed eventualmente il metodo di autenticazione che dobbiamo usare. In questo esempio faccio uso di un server che non richiede autenticazione e quindi la configurazione è semplicissima. Il "from" è un indirizzo arbitrario che viene usato come mittente delle email, non è necessario che esista. Qui non definisco il destinatario, lo farò dopo.
+  * Prima di tutto configuriamo il sistema per inviare email, usando la funzione ''tool/email''. Qui definiamo il server SMTP da usare ed eventualmente il metodo di autenticazione che dobbiamo usare. In questo esempio faccio uso di un server che non richiede autenticazione e quindi la configurazione è semplicissima. Il "from" è un indirizzo arbitrario che viene usato come mittente delle email, non è necessario che esista. Qui non definisco il destinatario, lo farò dopo.<code>
-<code>
 /tool/e-mail
 set from=<mikrotik-alerts@ILTUODOMINIO.TLD> server=mail.iltuodominio.tld
 </code>
-  * Poi per ogni connessione PPPoE che vogliamo monitorare dobbiamo creare un profilo contenente gli script per inviare le mail di allarme. Questo è un esempio, chiaramente il profilo conterrà oltre allo script anche le impostazioni che vi servono, quindi non è detto che questo vada bene così come è. Questo è di fatto il profilo di default con aggiunti gli script.
+  * Poi per ogni connessione PPPoE che vogliamo monitorare dobbiamo creare un profilo contenente gli script per inviare le mail di allarme. Questo è un esempio, chiaramente il profilo conterrà oltre allo script anche le impostazioni che vi servono, quindi non è detto che questo vada bene così come è. Questo è di fatto il profilo di default con aggiunti gli script.<code>
-<code>
 /ppp profile
 add change-tcp-mss=yes name=Profile-WAN on-down="delay 20s; tool e-mail send to=LATUAEMAIL@ILTUODOMINIO.TLD subject=([/system identity get name].\" Internet DOWN\") body=(\"Since \$since \\r\\n Host \$host\")" on-up="delay 20s; tool e-mail send to=LATUAEMAIL@ILTUODOMINIO.TLD subject=([/system identity get name].\" Internet UP\") body=(\"Since \$since \\r\\n Host \$host\")"
 </code>