{"id":1765,"date":"2025-09-09T17:49:20","date_gmt":"2025-09-09T20:49:20","guid":{"rendered":"https:\/\/www.nerdadas.com\/blog\/?p=1765"},"modified":"2025-09-09T17:49:20","modified_gmt":"2025-09-09T20:49:20","slug":"failover-con-ruteos-recursivos-y-sla","status":"publish","type":"post","link":"https:\/\/www.nerdadas.com\/blog\/failover-con-ruteos-recursivos-y-sla\/","title":{"rendered":"FailOver con Ruteos Recursivos y SLA"},"content":{"rendered":"\n<p>Muchas veces, cuando implementamos un <strong>enlace de failover<\/strong>, c<strong>hequeamos contra la puerta de enlace del proveedor<\/strong> para detectar si se cae o no el servicio para activar el failover; y muchas veces esto es un <strong>ERROR<\/strong>!. Porqu\u00e9?. <strong>No siempre se cae el equipo que actua de puerta de enlace pero siempre el servicio de internet<\/strong>.<\/p>\n\n\n\n<p>C\u00f3mo lo solucionamos?. Hay varias maneras pero hoy quiero documentar una en Mikrotik. En Mikrotik se llama <strong>Failover Recursive Routing<\/strong> y en <strong>Cisco es Reliable Static Routing<\/strong>.<\/p>\n\n\n\n<p>El esquema es el siguiente:<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><a href=\"https:\/\/www.nerdadas.com\/blog\/wp-content\/uploads\/2025\/07\/image-26.png\"><img loading=\"lazy\" decoding=\"async\" width=\"978\" height=\"388\" src=\"https:\/\/www.nerdadas.com\/blog\/wp-content\/uploads\/2025\/07\/image-26.png\" alt=\"\" class=\"wp-image-1767\" srcset=\"https:\/\/www.nerdadas.com\/blog\/wp-content\/uploads\/2025\/07\/image-26.png 978w, https:\/\/www.nerdadas.com\/blog\/wp-content\/uploads\/2025\/07\/image-26-300x119.png 300w, https:\/\/www.nerdadas.com\/blog\/wp-content\/uploads\/2025\/07\/image-26-768x305.png 768w\" sizes=\"auto, (max-width: 978px) 100vw, 978px\" \/><\/a><\/figure>\n\n\n\n<p>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\u00e9rdida m\u00ednima.<\/p>\n\n\n\n<p>Ruteos Recursivos<\/p>\n\n\n\n<p>Preparamos el router con las configuraciones b\u00e1sicas.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>#Nombramos\n\/system identity\nset name=R1\n\n#Agregamosl as ips en las interfaces WAN\n\/ip address\nadd address=192.168.122.208\/24 comment=WAN1 interface=ether1 network=192.168.122.0\nadd address=200.200.200.254\/24 comment=WAN2 interface=ether2 network=200.200.200.0\nadd address=192.168.0.1\/24 comment=LAN interface=ether3 network=192.168.0.0\n\n\/ip dhcp-server\/setup #Y configuramos\n\n#Nat en cada interface\n\/ip firewall nat\nadd action=masquerade chain=srcnat comment=\"NAT WAN1\" out-interface=ether1\nadd action=masquerade chain=srcnat comment=\"NAT WAN2\" out-interface=ether2\n<\/code><\/pre>\n\n\n\n<p>Una vez lista configuraci\u00f3n correcta del Router pasemos a la t\u00e9cnica en cuesti\u00f3n:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>#Vamos a crear rutas con scope 10 para darle prioridad en el router\n\/ip route\nadd comment=\"Ruta recursiva WAN1\" dst-address=8.8.8.8 gateway=192.168.122.1 scope=10\nadd comment=\"Ruta recursiva WAN2\" dst-address=1.1.1.1 gateway=200.200.200.1 scope=10<\/code><\/pre>\n\n\n\n<p>Con estas rutas le decimos al router que esas ips son accesibles solo a trav\u00e9s de esa puerta de enlace.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>#Y ac\u00e1 viene lo \"raro\". \nadd check-gateway=ping comment=\"Default por WAN1\" distance=1 dst-address=0.0.0.0\/0 gateway=8.8.8.8 target-scope=11\nadd check-gateway=ping comment=\"Backup por WAN2\" distance=2 dst-address=0.0.0.0\/0 gateway=1.1.1.1 target-scope=11<\/code><\/pre>\n\n\n\n<p>Le decimos que la puerta de enlace es esa ip de destino, as\u00ed que har\u00e1 el chequeo (check_gateway) contra esas ips de servidores remotos. <\/p>\n\n\n\n<p>Le daremos un scope 11 para que sepa que no est\u00e1n accesibles en el primer salto sino un poco m\u00e1s lejos y ahora probamos<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><a href=\"https:\/\/www.nerdadas.com\/blog\/wp-content\/uploads\/2025\/07\/image-27.png\"><img loading=\"lazy\" decoding=\"async\" width=\"978\" height=\"438\" src=\"https:\/\/www.nerdadas.com\/blog\/wp-content\/uploads\/2025\/07\/image-27.png\" alt=\"\" class=\"wp-image-1768\" srcset=\"https:\/\/www.nerdadas.com\/blog\/wp-content\/uploads\/2025\/07\/image-27.png 978w, https:\/\/www.nerdadas.com\/blog\/wp-content\/uploads\/2025\/07\/image-27-300x134.png 300w, https:\/\/www.nerdadas.com\/blog\/wp-content\/uploads\/2025\/07\/image-27-768x344.png 768w\" sizes=\"auto, (max-width: 978px) 100vw, 978px\" \/><\/a><\/figure>\n\n\n\n<p>Probamos con un ping a un lugar en internet y <strong>desconectamos el cable de \u00abTelecom\u00bb<\/strong> en este caso. Perdimos 2 paquetes antes que cambie la conexi\u00f3n. Podemos notar que cambi\u00f3 la conexi\u00f3n por el aumento del TTL en la conexi\u00f3n alternativa.<\/p>\n\n\n\n<p>Si quieren profundizar un poco m\u00e1s eso est\u00e1 en la documentaci\u00f3n oficial de Mikrotik <a href=\"https:\/\/help.mikrotik.com\/docs\/spaces\/ROS\/pages\/26476608\/Failover+WAN+Backup\">aqu\u00ed<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Cisco Reliable Static Routing<\/strong><\/h2>\n\n\n\n<p>En <strong>Cisco<\/strong> ya la cosa cambia. Para lograr testear si es alcanzable o no la ip en Internet usamos <strong>SLA<\/strong>. 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.<\/p>\n\n\n\n<p><strong>to be continued!<\/strong><\/p>\n\n\n\n<p><\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>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\u00e9?. No siempre se cae el equipo que actua de puerta de enlace pero siempre el servicio de internet. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":1767,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1243,1223,161,17,804],"tags":[1148,10,37,1230,242,1381,569,1382,1383,1064,1380,1384],"class_list":["post-1765","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-montando-tu-red-corporativa-de-0","category-redes","category-seguridad","category-tecnologia","category-ti","tag-cisco","tag-jeremias-palazzesi","tag-linux","tag-mikrotik","tag-network","tag-recursivo","tag-redes","tag-reflexive","tag-reflexivo","tag-router","tag-ruteos","tag-sla"],"_links":{"self":[{"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/posts\/1765","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/comments?post=1765"}],"version-history":[{"count":3,"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/posts\/1765\/revisions"}],"predecessor-version":[{"id":1775,"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/posts\/1765\/revisions\/1775"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/media\/1767"}],"wp:attachment":[{"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/media?parent=1765"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/categories?post=1765"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.nerdadas.com\/blog\/wp-json\/wp\/v2\/tags?post=1765"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}