MANUAL: Mikrotik, balanceo de carga PCC con failover

Si sólo necesitas un failover, no tienes que tocar para nada la tabla de rutas. con ponerle distinta distancia al cliente dhcp, ya lo tienes hecho. Una ruta te aparecerá con la distancia por defecto (1) y la otra con un 2 en azúl, esperando a que la primera se caiga. Si además quieres monitorear activamente el gateway, métele un check-gateway=ping y andando, creando la ruta manualmente.

Saludos!
buenas @pokoyo ! gracias por tu respuesta. Pues hoy desayuno con que no tienen internet, si ambas están conectadas. Sigo sin poder realizar ping a la IP pública de ambas conexiones, solo me funciona al gateway. Voy a abrir incidencia con el operador, porque me aseguran que están fuera de CGNAT, pero no es la única conexión que tengo con rango 139.x.y.z que me da estos problemas.
 
Ojo, que el error probablemente lo tengas tú, no ellos. Y una 139 es una IP pública... así que revisa tu config.

Saludos!
 
Ojo, que el error probablemente lo tengas tú, no ellos. Y una 139 es una IP pública... así que revisa tu config.

Saludos!
Buenas tardes! pues tras hablar con un técnico de N2, me confirma que tanto si ponemos el router en modo bridge/monopuesto como una ONT (configurada con la contraseña de la fibra), el CPE no se registra en los ACS del operador y por eso no es alcanzable desde Internet. La solución que me ofrecen es configurar DMZ al interfaz ethernet WAN del Mikrotik y levantar con un cliente DHCP, pero sin el interface VLAN. Mañana haré la prueba en la oficina con otro HEX S, cargando la configuración de esta sede, probando con el mismo operador/conexión/modelo de router.

Respecto a revisar la configuración, lo dices porque has visto parámetros fuera de lugar? :ROFLMAO: Es heredada, pero no quiero tocar nada mas allá del acceso a Internet, hasta que decidan cambiar la parte de switching (100MBps y cables cat5), rack, etc... empezar por la capa física e ir subiendo. Por lo que he visto, hay mucha "moralla" que ya no se usa (VOIP), asi que empezaré con un defconf e iré añadiendo lo necesario.

Tus sugerencias son simpre bienvenidas ;)

Según pruebe mañana, reporto.

Gracias de nuevo

Saludos
 
El técnico no se ha querido mojar mucho, no... tengo masmóvil (Pepephone, en este caso) y hace años que prescindí del CPE que me dieron. La IP pública se entrega correctamente en la WAN del mikrotik, sin más trampa ni cartón que configurar una VLAN sobre dicho puerto. Vamos, que el ACS no valida nada de nada (lo hará con sus equipos, pero le pones otro y tan ancho que va). Para muestra, un botón:

1648484074475.png


No obstante, la respuesta es estándar: o usas mis chismes o búscate la vida. Si ves que no hay manera, intentaría clonar la MAC del CPE en el puerto ether1 (o el que uses como WAN). De cualquier forma, si puedes hacer una prueba rápida con otro equipo (sin tocar ese), sería tan sencillo como configurar un defconf y meter la VLAN; prácticamente lo que me has mandado en el otro hilo donde preguntas por la apertura del puerto. Si la IP llega a obtenerse y la ruta por defecto se instala, el resto es poner bien el masquerade y estás navegando.

Me da la sensación de que la config que me mandaste tenía jodidas las rutas, y de ahí todo lo que te pasa.

Si ahora mismo no puedes o no quieres tocar ese equipo por ser "legacy", hazte de otro de respuesto, aunque sea prestado, y haz la prueba que te digo.

Saludos!
 
Hola chic@s.

Estoy intentado simular este escenario para una futura implementación y me he encontrado con alguna cosilla que cambia ya que el manual está escrito para versiones de RouterOS 6.XX (y ahí he comprobado que se puede seguir al pie de la letra) pero a partir de la 7.XX hay que hacer un par de ajustes.

Cito aquí el mensaje original de @pokoyo y, si él da el visto bueno y no hay ninguna metedura de pata por mi parte, supongo que lo modificará en el primer post para que quede a la vista de todos. Lo reduzco un poco para que sea más fácil localizar en qué punto del manual está el cambio.

(...)
A continuación, marcaremos las conexiones. Para ello, trabajaremos simpre sobre el chain de prerouting, y tenemos básicamente dos tipos de tráfico que marcar: el que viene desde fuera con destino dentro, y el que viene de la LAN con destino internet.
(...)
Código:
add action=mark-connection chain=prerouting comment="mark connections" \
    connection-mark=no-mark in-interface=internet-pepephone \
    new-connection-mark=pepephone_conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark \
    in-interface=internet-o2 new-connection-mark=o2_conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark \
    dst-address-type=!local in-interface=bridge new-connection-mark=\
    pepephone_conn passthrough=yes per-connection-classifier=both-addresses:2/0
add action=mark-connection chain=prerouting connection-mark=no-mark \
    dst-address-type=!local in-interface=bridge new-connection-mark=o2_conn \
    passthrough=yes per-connection-classifier=both-addresses:2/1
En las primeras dos reglas estamos marcando la entrada: lo que venga por la interfaz pepephone y no tenga ya marca, le pones la marca de conexión "pepephone_conn", e idéntico para o2. En la segunda, marcamos el tráfico de nuestra LAN que no vaya con destino local, es decir, que salga a internet. Aquí entra en juego el PCC, clasificando la conexión en dos flujos o streams, atendiendo a las direcciones de origen y destino del paquete, como hemos explicado antes. La división obviamente no es perfecta, y puede que una interfaz reciba más tráfico que la otra, pero creedme cuando os digo que el método funciona muy muy bien y las conexiones están más o menos equilibradas.

Marcadas las conexiones, lo que nos queda es, es el empujoncito final: para dichas conexiones marcadas, aplicar una regla de routeo. Para ello, simplemente analizaremos las marcas de conexión y, a las que vengan con "pepephone_conn", las mandamos a la ruta que trabaje con la marca de routing "to_pepephone", y a la que venga con "o2_conn", la mandamos a otra ruta que trabaje sobre la marca de routing "to_o2". Cuando creamos marcas de routing, en verdad lo que estamos haciendo son nuevas tablas de routeo además de la tabla de routeo principal "main" (toda conexión no marcada con una marca de routing, va por defecto a la tabla "main").

En lo que he marcado en negrita del mensaje original es donde está la clave del cambio ya que en la version 7.XX tenemos que dar de alta a mano esas entradas en la tabla porque sino los siguientes comandos del manual darán error. Las versiones 6.XX lo hacían automáticamente:
Código:
/routing table
add name=to_pepephone fib
add name=to_o2 fib

Y nos quedará la siguiente tabla:
1664118294502.png



Ahora podemos continuar:
Al igual que en el punto anterior, tendremos dos casuísiticas, esta vez relacionadas con distintos "chains": dos reglas para prerouting y dos para output. Las dos de prerouting se encargarán del tráfico que viene de la LAN ya clasificado. Las dos de output atenderán el tráfico que sale del propio router. Las reglas, serían estas:
Código:
add action=mark-routing chain=prerouting comment="mark routing" \
    connection-mark=pepephone_conn in-interface=bridge new-routing-mark=\
    to_pepephone passthrough=no
add action=mark-routing chain=prerouting connection-mark=o2_conn in-interface=\
    bridge new-routing-mark=to_o2 passthrough=no
add action=mark-routing chain=output connection-mark=pepephone_conn \
    new-routing-mark=to_pepephone passthrough=no
add action=mark-routing chain=output connection-mark=o2_conn new-routing-mark=\
    to_o2 passthrough=no
Como veis, muy simple: lo que venga con la marca de conexión X, al canuto X, lo que venga con Y, al Y... y así sucesivamente.

(...)

El resultado final de la operación, sería tener algo como esto en mangle (obviad los nombres de mis interfaces)
Ver el adjunto 78940

Y después hay que hacer una pequeña modificación en la sintaxis de los siguientes comandos del manual para añadir las rutas, cambiando routing-mark por routing-table en el código:
(...)
Pasamos a configurar las rutas. Para las rutas, lo único que tenemos que hacer es definir dos nuevas rutas, específicas para las marcas de routeo que hemos hecho. Esas rutas serán las que de verdad trabajen, mientras ambas conexiones estén vivas y balanceando. Las rutas por defecto se quedarán de backup, para el tráfico sin marcar o para cuando algo falle en nuestra configuración. Pasamos a crear las dos rutas nuevas, una para el tráfico marcado como "to_pepephone" y otra para el tráfico marcado como "to_o2", ambas con una sonda de tipo "ping" para comprobar que siguen vivas:
Código:
/ip route
add check-gateway=ping comment=pp-load-balanced distance=1 gateway=212.231.184.1 \
    routing-table=to_pepephone
add check-gateway=ping comment=o2-load-balanced distance=1 gateway=internet-o2 \
    routing-table=to_o2
(...)

Las rutas, quedarían así, una vez creadas las dos nuevas entradas manuales para las marcas de routeo específicas:
Ver el adjunto 78943


Creo que eso es todo. Si me he olvidado de algo pido disculpas de antemano. Y si, tras revisión por parte de los que controláis, veis que la info esta está mal, si es necesario la borramos antes de inducir a error a alguien.

Saludos!


Edito porque sí que me había olvidado de algo: de modificar la sintaxis en el script que cambia automáticamente el Gateway del DHCP. Cambia lo mismo de routing-mark por routing-table:
Llegados a este punto ya tenemos todo el tinglado montado y funcionando.
(...)
pero si tenemos direcciones IP dinámicas en la mayoría de los casos (...) el tinglado se nos va al garete.
(...)
necesitamos corregir eso. Para hacerlo, lo que vamos a montar es un script que añadiremos al cliente DHCP, tal que sea capaz de modificar esa que hemos dado de alta a mano, automáticamente. El script está sacado de la wiki de mikrotik, y adaptado a mis necesidades.
(...)
iremos a IP -> dhcp-client y editaremos el cliente dhcp asocidado a nuestra conexión DHCP, en mi caso "internet-pepephone", y le meteremos el siguiente script en la pestaña "Advanced"
1613595047570.png


Código:
{
:local rmark "to_pepephone"
:local rcomment "pp-load-balanced"
:local rcount [/ip route print count-only where comment=$rcomment]
:if ($bound=1) do={
:if ($rcount = 0) do={
/ip route add gateway=$"gateway-address" comment=$rcomment routing-table=$rmark check-gateway=ping
} else={
:if ($rcount = 1) do={
:local test [/ip route find where comment=$rcomment]
:if ([/ip route get $test gateway] != $"gateway-address") do={
/ip route set $test gateway=$"gateway-address"
}
} else={
:error "Multiple routes found with the same comment!"
}
}
} else={
/ip route remove [find comment=$rcomment]
}
}
El script parece complejo, pero es una chorrada. Define tres variables, la marca de ruta que vamos a aplicar (rmark), el comentario que estamos buscando en la ruta (rcomment) y el número de veces que encuentra ese comentario sobre una ruta en la tabla de rutas (rcount)

(...)
 

Adjuntos

  • 1664118373827.png
    1664118373827.png
    42.4 KB · Visitas: 23
Última edición:
Hola chic@s.

Estoy intentado simular este escenario para una futura implementación y me he encontrado con alguna cosilla que cambia ya que el manual está escrito para versiones de RouterOS 6.XX (y ahí he comprobado que se puede seguir al pie de la letra) pero a partir de la 7.XX hay que hacer un par de ajustes.

Cito aquí el mensaje original de @pokoyo y, si él da el visto bueno y no hay ninguna metedura de pata por mi parte, supongo que lo modificará en el primer post para que quede a la vista de todos. Lo reduzco un poco para que sea más fácil localizar en qué punto del manual está el cambio.



En lo que he marcado en negrita del mensaje original es donde está la clave del cambio ya que en la version 7.XX tenemos que dar de alta a mano esas entradas en la tabla porque sino los siguientes comandos del manual darán error. Las versiones 6.XX lo hacían automáticamente:
Código:
/routing table
add name=to_pepephone fib
add name=to_o2 fib

Y nos quedará la siguiente tabla:
Ver el adjunto 99630


Ahora podemos continuar:


Y después hay que hacer una pequeña modificación en la sintaxis de los siguientes comandos del manual para añadir las rutas, cambiando routing-mark por routing-table en el código:



Creo que eso es todo. Si me he olvidado de algo pido disculpas de antemano. Y si, tras revisión por parte de los que controláis, veis que la info esta está mal, si es necesario la borramos antes de inducir a error a alguien.

Saludos!
Correcto. Las nuevas tablas de rutas hay que crearlas a mano en la v7. Y la sentencia de creación de rutas varía ligeramente. Juraría que, a nivel de mangle, no cambia nada.

Saludos!
 
Prueba si quieres y, cuando lo tengas implementado en la v7, actualizamos el manual con los cambios. Ahora mismo no lo tengo montado, así que me viene bien si alguien lo confirma, antes de tocarlo.

Saludos!
 
Efectivamente, el mangle es exactamente igual. Sólo varía el tema de las tablas de rutas y la sintaxis, que en vez de routing-mark de la v6, en la v7 es routing-table.

Con esos pequeños cambios lo tengo funcionando todo perfectamente. Al menos a nivel escenario de pruebas.

Ahora aprovecho para hacerte la pregunta del millón jejeje: Una vez montado y funcionando, es viable meter la parte del failover con rutas recursivas de tu otro manual?? Es decir, que mantenga el balanceo PCC y a mayores detecte la caída de servicio a nivel ISP con las rutas recursivas?

Entiendo que no debería haber problema pero aún no me he puesto a estudiar ese segundo manual jaja, sólo lo que leí cuando lo subiste.
 
Última edición:
Efectivamente, el mangle es exactamente igual. Sólo varía el tema de las tablas de rutas y la sintaxis, que en vez de roting-mark de la v6, en la v7 es routing-table.

Con esos pequeños cambios lo tengo funcionando todo perfectamente. Al menos a nivel escenario de pruebas.

Ahora aprovecho para hacerte la pregunta del millón jejeje: Una vez montado y funcionando, es viable meter la parte del failover con rutas recursivas de tu otro manual?? Es decir, que mantenga el balanceo PCC y a mayores detecte la caída de servicio a nivel ISP con las rutas recursivas?

Entiendo que no debería haber problema pero aún no me he puesto a estudiar ese segundo manual jaja, sólo lo que leí cuando lo subiste.
Claro que sí, la unión de los dos es un setup digno de enmarcar.

Saludos!
 
Prueba si quieres y, cuando lo tengas implementado en la v7, actualizamos el manual con los cambios. Ahora mismo no lo tengo montado, así que me viene bien si alguien lo confirma, antes de tocarlo.

Saludos!
Perdona, que nos contestamos a la vez.

Con respecto a esto, mi escenario consiste en un hap lite con la V7 conectado a mi rb3011 haciendo de ISP1 (wan1) y el puerto del IPTV gorrón que me quedó de pruebas anteriores y aún está en uso, haciendo de ISP2 (wan2) saliendo por otro router de Vodafone.

Haciendo pruebas veo tráfico en las dos interfaces así que el balanceo supongo que está ok y probando a modificar el gateway a mano poniendo una ip cualquiera, si fuerzo la renovación coge la correcta del rango del "ISP" (mi router o el del gorrón) respectivamente.

Hasta dentro de una semana o dos no lo pondré en el sitio definitivo y seguramente tampoco sea con este hap lite pero vamos, yo diría que está todo perfectamente configurado, por si te fías y lo quieres actualizar en el manual jajaja
 
Arriba