Mikrotik failover LTE

Internet estable se está volviendo cada vez más importante, especialmente durante COVID19, cuando una gran parte de la sociedad tiene que trabajar a distancia. Una de las actividades que proporcionan acceso a Internet es la compra de un enlace a un segundo operador, muchas personas deciden elegir aquí el acceso en forma de LTE.

En busca de inspiración encontré un artículo publicado en Server Management por Timo Puistay de 2017. El método descrito de detección de enlaces mediante el alargamiento y la manipulación del encaminamiento demostró ser bastante eficiente, sin embargo, no pudo detectar los fallos del enlace cuando se produce una pérdida de paquetes o un aumento drástico del tiempo de transmisión de los paquetes a través del enlace principal. He decidido extender esta idea con todas mis necesidades.

Las pautas son las siguientes:

• Detectar rápidamente una pérdida con la conexión principal;
• Detectar un aumento de los tiempos de demora en la conexión principal e interpretarlos como un problema;
• Detectar un fallo en la conexión de Internet más allá de mi puerta de enlace local en mi ISP;
• Detectar una reparación de la conexión del enlace principal;
• MikroTik
• Completa automatización;
• Utilizar su router MikroTik

El principio se basa en el uso de la herramienta Netwatch implementada en MikroTik RouterOS con soporte de scripts y verificación adicional al extender la ruta de enrutamiento y comprobar la disponibilidad de la pasarela por defecto.

/system script add dont-require-permissions=no name=NetWatch-check owner=admin policy=\ reboot,read,write,policy,test source="#Tutaj mozesz zmienic wartosc\r\ \n# ilosc czasu w minutach jak dlugo lacze BACKUP bedzie preferowane\r\ \n# zanim sprawdzimy czy lacze glowne dziala prawidlowo\r\ \n#\r\ \n:global nwwait 15;\r\ \n# pozostaw bez zmian\r\ \n:global nwgw2;\r\ \n:tonum nwgw2;\r\ \n:local nwstatus;\r\ \n:local nwgwstatus;\r\ \nset nwgwstatus ([/tool netwatch get value-name=status [find comment=\ \"NetWatch\"]]);\r\ \nset nwstatus ([/ip route get value-name=distance number=[/ip route f\ ind comment=\"BACKUP\"]]);\r\ \n:if (\$nwstatus = \"6\") do={\r\ \nset nwgw2 (nwgw2 + 1)\r\ \n}\r\ \n:if ((\$nwgw2 > \$nwwait) and (\$nwgwstatus = \"up\")) do={ :log err\ or \"Master GW: OK\"\r\ \n/ip route set [find comment=\"BACKUP\"] distance=66;\r\ \nset nwgw2 (0)\r\ \n}\r\ \n" add dont-require-permissions=no name=NetWatch owner=admin policy=\ reboot,read,write,test source="/log error \"Master GW: PROBLEM\"\r\ \n/ip route set [find comment=\"BACKUP\"] distance=6\r\ \n\r\ \n" add dont-require-permissions=no name=NetWatch-init owner=admin policy=\ ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \ source="#ilosc sprawdzen zanim lacze sie przelaczy\r\ \n:global nwwait 20;\r\ \n"

Guiones utilizados: NetWatch - guión lanzado en caso de fallo del enlace principal NetWatch-check - un script que se ejecuta temporalmente para verificar el cambio de vuelta al enlace principal, en este script podemos definir cuánto tiempo el BACKUP enlace desde el momento del cambio seguirá siendo el enlace principal antes de comprobar si el enlace principal funciona correctamente. En la situación predeterminada es de 15 minutos.

El siguiente paso es definir el tiempo de los guiones. /system scheduler add interval=1m name=NetWatch on-event=\ "/system script run NetWatch-check\r\ \n" policy=\ ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \ start-date=apr/11/2020 start-time=17:31:44 Es hora de configurar la herramienta Netwatch Mikrotik. En lugar de A.B.C.D, se debe dar la dirección por defecto de la puerta principal del enlace. El valor timeout puede especificar cuán sensible será la detección de la falla del enlace principal. /tool netwatch add comment=NetWatch down-script="/system script run NetWatch\r\ \n" host=A.B.C.D interval=5s timeout=100ms

Por último, configurar el enrutamiento, utilizando el truco con ruta de enrutamiento extendida y comprobando la disponibilidad de la puerta de enlace por defecto. En lugar de A.B.C.D, proporcione la dirección de la puerta de enlace por defecto para el enlace principal, y en lugar de E.F.G.H, proporcione la dirección de la puerta de enlace por defecto para el enlace de reserva BACKUP. /ip route add comment=MASTER distance=10 gateway=10.255.66.1 add comment=BACKUP distance=66 gateway=10.255.67.1 add check-gateway=ping distance=1 dst-address=10.255.66.1/32 gateway=\ 208.67.220.220 scope=10 add check-gateway=ping distance=1 dst-address=10.255.66.1/32 gateway=\ 8.8.8.8 scope=10 add check-gateway=ping distance=1 dst-address=10.255.67.1/32 gateway=\ 208.67.222.222 scope=10 add check-gateway=ping distance=1 dst-address=10.255.67.1/32 gateway=\ 8.8.4.4 scope=10 add distance=1 dst-address=8.8.4.4/32 gateway=E.F.G.H scope=10 add distance=1 dst-address=8.8.8.8/32 gateway=A.B.C.D scope=10 add distance=1 dst-address=208.67.220.220/32 gateway=A.B.C.D scope=10 add distance=1 dst-address=208.67.222.222/32 gateway=E.F.G.H scope=10 Utilizamos la popular dirección ip de los servicios dns Google (8.8.8.8, 8.8.4.4) y OpenDNS (208.67.220.220, 208.67.222.222), que comprobamos si son accesibles a través del enlace de un operador determinado. Si está disponible, la puerta de enlace por defecto está activada.

En la solución anterior, se utilizó una doble verificación del correcto funcionamiento del enlace de Internet, una vez comprobando la pasarela por defecto del enlace principal, y adicionalmente comprobando la disponibilidad de los hosts "lejanos en la Internet" a los que se llega desde enlaces específicos. Esta solución tiene una cierta restricción, en caso de que uno de los operadores cambie el parámetro por defecto de la pasarela al renegociar la conexión no podremos configurarla directamente.

Estoy convencido de que la solución puede ser mejorada y desarrollada, los guiones que he preparado pueden ser escritos de manera diferente manteniendo el principio principal de la solución.

Autor: Wojciech Repiński