Muchas veces, cuando implementamos un enlace de failover, chequeamos contra la puerta de enlace del proveedor para detectar si se cae o no el servicio para activar el failover; y muchas veces esto es un ERROR!. Porqué?. No siempre se cae el equipo que actua de puerta de enlace pero siempre el servicio de internet.
Cómo lo solucionamos?. Hay varias maneras pero hoy quiero documentar una en Mikrotik. En Mikrotik se llama Failover Recursive Routing y en Cisco es Reliable Static Routing.
El esquema es el siguiente:

La idea en ambos casos es armar una ruta hacia una ip de un server en la nube que nunca se caiga por cada isp. Cuando ese equipo en la nube deja de responder, esa ruta es inalcanzable y pasamos al otro enlace con pérdida mínima.
Ruteos Recursivos
Preparamos el router con las configuraciones básicas.
#Nombramos
/system identity
set name=R1
#Agregamosl as ips en las interfaces WAN
/ip address
add address=192.168.122.208/24 comment=WAN1 interface=ether1 network=192.168.122.0
add address=200.200.200.254/24 comment=WAN2 interface=ether2 network=200.200.200.0
add address=192.168.0.1/24 comment=LAN interface=ether3 network=192.168.0.0
/ip dhcp-server/setup #Y configuramos
#Nat en cada interface
/ip firewall nat
add action=masquerade chain=srcnat comment="NAT WAN1" out-interface=ether1
add action=masquerade chain=srcnat comment="NAT WAN2" out-interface=ether2
Una vez lista configuración correcta del Router pasemos a la técnica en cuestión:
#Vamos a crear rutas con scope 10 para darle prioridad en el router
/ip route
add comment="Ruta recursiva WAN1" dst-address=8.8.8.8 gateway=192.168.122.1 scope=10
add comment="Ruta recursiva WAN2" dst-address=1.1.1.1 gateway=200.200.200.1 scope=10
Con estas rutas le decimos al router que esas ips son accesibles solo a través de esa puerta de enlace.
#Y acá viene lo "raro".
add check-gateway=ping comment="Default por WAN1" distance=1 dst-address=0.0.0.0/0 gateway=8.8.8.8 target-scope=11
add check-gateway=ping comment="Backup por WAN2" distance=2 dst-address=0.0.0.0/0 gateway=1.1.1.1 target-scope=11
Le decimos que la puerta de enlace es esa ip de destino, así que hará el chequeo (check_gateway) contra esas ips de servidores remotos.
Le daremos un scope 11 para que sepa que no están accesibles en el primer salto sino un poco más lejos y ahora probamos

Probamos con un ping a un lugar en internet y desconectamos el cable de «Telecom» en este caso. Perdimos 2 paquetes antes que cambie la conexión. Podemos notar que cambió la conexión por el aumento del TTL en la conexión alternativa.
Si quieren profundizar un poco más eso está en la documentación oficial de Mikrotik aquí
Cisco Reliable Static Routing
En Cisco ya la cosa cambia. Para lograr testear si es alcanzable o no la ip en Internet usamos SLA. Vamos a activar un track y vamos a chequear la ruta activa de por vida para poder monitorear si se corta a o no internet para cambiar de enlace. Pero esta vez lo vamos a dejar para otro laboratorio.
to be continued!