Red CapsMan + Caps hAP ac2 en oficinas

Jejeje, hubieras preguntado coño, que había una manera muchísimo más sencilla de probar todo esto en el 3011. Simplemente, sacas un puerto del bridge principal, le creas a capón todas las VLANs encima de ese puerto físico (VLANs por software, de las de Interface -> Vlan). Creas las direcciones en IP -> Address para todas esas VLANs y con el botón DHCP Setup, seleccionas la interfaz vlan y siguiente siguiente siguiente... y por lo menos para probar que las VLANs se entregan en modo acceso, te vale. Conectarías ese puerto X que sería el "trunk" al ether1 del CCR y listo.

Para el tema de probar el puerto híbrido, si tienes por ahí a mano un linux, simplemente créale la VLAN 99 encima de la interfaz ethernet (vía network manager creo que se podía crear), y le pones a funcionar un cliente DHCP, y pillará una IP del rango 192.168.99.X, además de una de tipo 192.168.106.X en la interfaz física. Es decir, en un mismo puerto, te va a dar dos IPs.

Saludos!
 
Jejeje, hubieras preguntado coño, que había una manera muchísimo más sencilla de probar todo esto en el 3011. Simplemente, sacas un puerto del bridge principal, le creas a capón todas las VLANs encima de ese puerto físico (VLANs por software, de las de Interface -> Vlan). Creas las direcciones en IP -> Address para todas esas VLANs y con el botón DHCP Setup, seleccionas la interfaz vlan y siguiente siguiente siguiente... y por lo menos para probar que las VLANs se entregan en modo acceso, te vale. Conectarías ese puerto X que sería el "trunk" al ether1 del CCR y listo.
Mas info para la mochila, juer es que soy un neófito total a estos niveles. Pero me lo anoto.

Para el tema de probar el puerto híbrido, si tienes por ahí a mano un linux, simplemente créale la VLAN 99 encima de la interfaz ethernet (vía network manager creo que se podía crear), y le pones a funcionar un cliente DHCP, y pillará una IP del rango 192.168.99.X, además de una de tipo 192.168.106.X en la interfaz física. Es decir, en un mismo puerto, te va a dar dos IPs.
Ubuntu 20.04 cargado modulo 8021q es instalado el paquete vlan. La config ahora ha cambiado me gustaba mas antes con el /etc/network/interfaces ahora se hace desde el /etc/netplan/01-network-manager-all.yaml pero vamos que funcionar, funciona.
Código:
sudo ip link add link enp0s25 name enp0s25.99 type vlan id 99
y efectivamente con un ifconfig se puede ver como por el mismo cable físico entran la red V106 y entrega una IP así como la V99 y se puede hacer pines al 192.168.99.1. Todo OK

Gracias. Seguramente me lleve el CRS326 para instalar definitivo en las instalaciones el lunes después de semana santa. Y si te parece bien la semana que viene empezamos con las colas y espero tener (que aún no lo tengo) los datos de conexión pppoe para la fibra 2 y separar la salida del tráfico a internet.
Un saludo
 
Buenos días compi!

Hubiera jurado haber respondido este mensaje, pero ya veo que no. Me alegro de que el switch esté prácticamente listo para instalar, incluso probado el puerto híbrido. ¿Tiene buena pinta, no? A ver si no te da la lata al instalarlo y va todo rodado.

Tema colas: ves pensando los límites que quieres establecer par los distintos segmentos de red. De momento, empezamos por lo más simple: los externos. Considera primero que están dentro de tu red con un único proveedor, (cola total) y luego subiremos ese máximo permitido acorde. Piensa, si tuvieras que repartir 300Mbps, que es lo que tienes ahora mismo, piensa en qué máximo ancho de banda querrías para seguridad, coworking e invitados.

Saludos!
 
Te paso una primera propuesta para el tema de las colas. Es un mundo muy muy complejo y tremendamente farragoso, y del que sólo vas a salir airoso después de mucho probar. Llevo mucho tiempo queriendo hacer un buen manual al respecto, pero cada vez que me pongo, alguna duda más me surge, y no me atrevo a ello, sobre todo por que no es lo mismo limitar el ancho de banda que hacer calidad de servicio, son conceptos complementarios, pero que cada uno tiene su miga.

Así que, vamos a empezar por lo más simple: una cola padre para "externos" y tres colas hijas para los las tres subredes que sólo acceden a internet, que son las que te pueden complicar la vida. Vamos a pasar de los árboles de colas y lo vamos a usar todo con colas simples, tal que puedas aprovechar el rendimiento multi-core de ese equipo. Te quedaría, algo así (súmale un cero a las velocidades, y te puedes hacer una aproximación a lo que podrías considerar en la vida real).

1650022701255.png


Tipos de cola y su implementación:

Cola Padre: externos
Target: las tres redes de exernos
Tipo: default-small
Parent: none
Subida / Bajada máxima: 10M / 10M
Garantizado: nada
Prioridad: 8

Cola hija: seguridad
target: subred seguridad completa [192.168.108.0/29]
Tipo: default-small
Parent: externos
Subida / Bajada máxima: 5M / 5M
Garantizado: 2M / 2M
Prioridad: 8

Cola hija: coworking
target: subred seguridad completa [192.168.107.0/24]
Tipo: pcq
Parent: externos
Subida / Bajada máxima: 9M / 9M
Garantizado: 5M / 5M
Prioridad: 7

Cola hija: invitados
target: subred seguridad completa [192.168.200.0/23]
Tipo: pcq
Parent: externos
Subida / Bajada máxima: 9M / 9M
Garantizado: 3M / 3M
Prioridad: 8

Conceptos:
  • Target: a quién aplica esta cola, ya sea como origen o destino. Como estas subredes sólo acceden a internet no hay problema, pero si esto lo quisieras implementar también el la red interna, tendríamos un problema añadido: si bien el target no limita la comunicación dentro de la misma VLAN (ahí no hay límite de tráfico), sí que lo hace en el tráfico inter-vlan, puesto que el tráfico sube al router. Así que, si por ejemplo limitas la red de empleados a 100M, la comunicación entre empleados y los servidores estaría igualmente limitada. Habría que identifica el tráfico con origen o destino internet, y limitar sólo ese, o hacer un fasttrack de las conexiones con origen empleados y destino servidores, tal que se salte las colas.
  • Tipo: hay muchos tipos de colas, dependiendo de cómo tratan el tráfico y de la capacidad de las mismas. Vamos a trabajar con dos principalmente: default-small (la cola por defecto) y pcq (la cola que reparte el tráfico por igual entre todos los clientes de esa cola). Cada cola tiene sus caracterísiticas predefinidas, pero se pueden cambiar. Por ejemplo, la cola PCQ, tal cual viene configurada, está pensada para manejar unos 40 clientes simultáneos. Quizá en coworking haga su trabajo perfectamente, pero no en invitados, ante un evento con 150 personas todas demando internet a la vez y superando el límite de la cola.
  • Parent: cola de la que heredan. Si la cola padre tiene 10M y la suma de las colas hija lo supera, no hay problema, limitará a 10M. Es la manera de hacer reuso de ancho de banda (lo que hacen los operadores con nosotros todos los días cuando a todos nos venden 300Mbps, y por un enlace de 2.5Gbps sacan 50 clientes de 300Mbps).
  • Upload Max Limit / Download Max Limit: límite máximo de carga/descarga por cada cola. Es decir, cuando esté disponible, hasta dónde le vas a dar a un cliente o grupo de clientes que consuma del total. Para las colas hijas, se recomienda tener siempre un pelín menos de capacidad total de la cola padre, tal que si llega una avalancha de peticiones de tráfico de los hijos, no se produzca pérdida de paquetes por saturación de la cola padre. Un pelín menos es suficiente, en este caso es muy grande la diferencia porque trabajamos con unidades muy pequeñas, pero no es necesario darle un 10% de margen.
  • Upload Limit At / Donwload Limit At: el que le puso el nombre al campo, se lució, en lugar de llamarle CIR, que es como normalmente se lo conoce (Committed Information Rate). Son las tasas garantizadas de tráfico. La suma de dichas tasas no puede superar nunca el límite máximo de carga/descarga de la cola padre. Es lo mínimo que SIEMPRE le garantizas tener a un cliente o segmento de red (como es tu caso), lo pida cuando lo pida. Un ejemplo: si a un cliente le vendes 10M con un CIR del 80%, le estás vendiendo un enlace dedicado. con un 50% semi-dedicado, y lo normal es que el CIR ronde entre 15% - 25%. Mucho ojo con este campo, que nos puede doler mucho la cabeza con él. Como ves en el ejemplo, la suma de los CIR se ajusta a la capacidad máxima de la cola padre.
  • Prioridad: valores del 1 al 8, siendo el 1 la mayor prioridad, y el 8 la menor de todas. A igual prioridad, las colas se comportarán tal y como las ves definidas, ordenadas por prioridad numeral (seguridad -> coworking -> invitados), si no tuvieran cola padre. Si, por ejemplo, tuviéramos la prioridad de cualquiera de las tres colas menor, como hemos hecho con coworking, primero se atenderían los límites de tráfico garantizado de esa cola, luego el garantizado de las demás, y luego el max limit de la cola con más prioridad (número del 1 al 8, siendo 1 la mayor prioridad, y 8 la menor)..., y lo que sobre, para las demás. Ejemplo: coworking la hemos definido con más prioridad que las demás, dándole un 7. Si las otras dos no manejan tráfico, se llevará 9M. Si seguridad empieza a demandar tráfico como loca, no llegará nunca a su max limit de 5M, sino que sólo se le darán 2, su garantía, y el resto se lo quedaría coworking (9 total - 2 garantizado seguridad = 7M), dejando a invitados casi seco, a menos que este empiece a demandar también tráfico, donde se atenderán los garantizados de cada cola (5 coworking, con más prioridad, y luego 2 y 3 para seguridad e invitados, respectivamente)

Lo dicho, dale una pensada y empezamos a montar el tema. Que, como ves, tiene muchísima miga.

Para este pequeño ejemplo, tendríamos el siguiente código:
Código:
/queue simple
add max-limit=10M/10M name=externos target=192.168.107.0/24,192.168.108.0/29,192.168.200.0/23
add limit-at=2M/2M max-limit=5M/5M name=seguridad parent=externos target=192.168.108.0/29
add limit-at=5M/5M max-limit=9M/9M name=coworking parent=externos priority=7/7 queue=pcq-upload-default/pcq-download-default \
    target=192.168.107.0/24
add limit-at=3M/3M max-limit=9M/9M name=invitados parent=externos queue=pcq-upload-default/pcq-download-default target=\
    192.168.200.0/23

Saludos!
 
Buenos días compi!

Hubiera jurado haber respondido este mensaje, pero ya veo que no. Me alegro de que el switch esté prácticamente listo para instalar, incluso probado el puerto híbrido. ¿Tiene buena pinta, no? A ver si no te da la lata al instalarlo y va todo rodado.

Tema colas: ves pensando los límites que quieres establecer par los distintos segmentos de red. De momento, empezamos por lo más simple: los externos. Considera primero que están dentro de tu red con un único proveedor, (cola total) y luego subiremos ese máximo permitido acorde. Piensa, si tuvieras que repartir 300Mbps, que es lo que tienes ahora mismo, piensa en qué máximo ancho de banda querrías para seguridad, coworking e invitados.

Saludos!
@pokoyo tal y como lo he pensado creo que partiendo de 300Mb repartiría mas o menos así. A ver como lo ves.
Porcentaje de ancho de banda disponible de Internet repartido.

Vlan​
Denominación​
Ancho banda %​
Ancho banda absoluto​
105​
Servidores​
0,1​
30Mbps​
106​
Empleados​
0,40​
120Mbps​
107​
Coworking​
0,30​
90Mbps​
108​
Seguridad​
0,10​
30Mbps​
200​
Invitados​
0,10​
30Mbps​

No sé si es correcto meter la Vlan 105 de servidores, pero entiendo que al prestar alguno de ellos servicios hacía el exterior, si se tendría que tener en cuenta el ancho de banda mínimo que tendría disponible.

Un saludo señor.
 
@pokoyo tal y como lo he pensado creo que partiendo de 300Mb repartiría mas o menos así. A ver como lo ves.
Porcentaje de ancho de banda disponible de Internet repartido.

Vlan​
Denominación​
Ancho banda %​
Ancho banda absoluto​
105​
Servidores​
0,1​
30Mbps​
106​
Empleados​
0,40​
120Mbps​
107​
Coworking​
0,30​
90Mbps​
108​
Seguridad​
0,10​
30Mbps​
200​
Invitados​
0,10​
30Mbps​

No sé si es correcto meter la Vlan 105 de servidores, pero entiendo que al prestar alguno de ellos servicios hacía el exterior, si se tendría que tener en cuenta el ancho de banda mínimo que tendría disponible.

Un saludo señor.
Vale, te lo planteo de otra forma. De los 300Mbps, necesito que pienses, para cada subgrupo, e imaginando que tienen los 300Mbps para ellos sólos (de la manera que lo pintas no haríamos rehuso de ancho de banda ninguno)

- Velocidad máxima total del grupo en el mejor escenario (MIR)
- Velocidad mínima del grupo en el peor escenario (CIR)

Considero lo que me mandas el CIR, piensa en el MIR por cada grupo. Es decir, si la red no la usa nadie, cuánto quieres que se chupe cada grupo, si en ese momento estuviera sólo en la red, y nadie más lo estuviera usando. El número máximo ha de ser un pelín menor que los 300Mbps de lo que dispones (por ejemplo, 280Mbps)

Saludos!
 
Quédate con esta foto, mañana la comentamos.

1650234613410.png


Cuando puedas, dime el número de usuarios que tendrá cada red, para adaptar el tamaño de las colas. Especialmente para VPN, Empleados y Coworking. Las pcq-default vienen preparadas para manejar 40 clientes, pero sospecho que en esas nos vamos a ir (en invitados, por descontado)

Saludos!
 
Vale, te lo planteo de otra forma. De los 300Mbps, necesito que pienses, para cada subgrupo, e imaginando que tienen los 300Mbps para ellos sólos (de la manera que lo pintas no haríamos rehuso de ancho de banda ninguno)

- Velocidad máxima total del grupo en el mejor escenario (MIR)
- Velocidad mínima del grupo en el peor escenario (CIR)

Considero lo que me mandas el CIR, piensa en el MIR por cada grupo. Es decir, si la red no la usa nadie, cuánto quieres que se chupe cada grupo, si en ese momento estuviera sólo en la red, y nadie más lo estuviera usando. El número máximo ha de ser un pelín menor que los 300Mbps de lo que dispones (por ejemplo, 280Mbps)

Saludos!
Muy buenas, al grupo, he estado un poco ausente por temas de curro pero retomamos el trabajo.
@pokoyo me he mirado este mensaje y creo que sería algo así. A ver como lo ves. el tema de reparto (MIR) (CIR)
Configuración Colas CIR MIR Ancho de banda red Uninoovo.jpg

Sobre todo me interesa si habré captado bien el concepto porque en (MIR) se piensa como si todo el ancho de banda lo dispusiera en un momento cada uno de los grupos. Entonces mi reparto ha sido por grupo pensando "Si tengo 280Mb disponibles, ¿Con cuanto voy sobrado aunque esté yo solo?" creo que era eso.
Un Saludo.
 
Quédate con esta foto, mañana la comentamos.

Ver el adjunto 94230

Cuando puedas, dime el número de usuarios que tendrá cada red, para adaptar el tamaño de las colas. Especialmente para VPN, Empleados y Coworking. Las pcq-default vienen preparadas para manejar 40 clientes, pero sospecho que en esas nos vamos a ir (en invitados, por descontado)

Saludos!
Entiendo que mas o menos sería esto que te envío, aunque en particular Servidores y Seguridad no entiendo bien el tratamiento que se le debe dar. a la red seguridad no conecta prácticamente ningún usuario solo desde fuera y con su programa y a servidores entiendo que son los empleados que hayan entrado por la VPN, corrígeme sino lo estoy entendiendo bien.
Configuración Colas CIR MIR reparto de usuarios.jpg

Si en invitados un día normal sin cursos ni charlas ni nada viene un repartidor ó algún invitado de un empleado ó de un coworker, sería mínimo, pero es esa red la que se usaría para algún evento (charla, conferencia, etc...) y se pondría cartelito para que todos los asistentes pudieran conectarse a la misma. Creo que ese es el funcionamiento básico de ese grupo.
Nuevamente un saludo, a todos.
 
Vale, con las cifras de usuarios que manejas, la única cola PCQ que hay que crear "extra" es la de invitados, todos los demás se pueden apañar con la pcq-default, que está pensada para unos 40 usuarios (2000KB de tamaño total de cola, y 50K por cada usuario). La de usuarios la vamos a dimensionar para unos 500 usuarios, subiendo el tamaño total de la cola a 25.000KB. Así la dejas preparadas para eventos o para lo que necesites. Consumirá un pelín más de RAM, pero como prácticamente no se va a usar, eso no se usará hasta que esa red tenga ese número elevado de usuarios. Otra cosa que se puede hacer en esa cola es limitar el máximo por usuario: es decir, incluso cuando esa cola tendría 30Mbps de ancho de banda garantizado, no entregárselos de golpe al primer usuario, sino que se puede decir: dale como mucho X a cada usuario del reparto PCQ.

Con respecto a las velocidades, me gustaría que hicieras una prueba con la tabla que te pasé hace unos días. Básicamente lo que hice en ella es desechar la idea de "conexiones simétricas", que no lo son (la que te venden lo es, pero el uso de tus usuarios no lo va a ser), e intentar ponderar el uso de la conexión.
Así, por ejemplo, considero que VPN y Servidores van a tener más tráfico de subida que de bajada, y empleados es justo lo contrario. De igual manera, servidores tendrá mucho más tráfico de subida que de bajada (si algún día hay que "sacar" un video fuera), al contrario que invitados, que prácticamente sólo necesita descarga.

De igual forma, ponderé las prioridades, dándole más prioridad (5 y 6) a los grupos de IP's internos (VPN, Servidores, Empleados), y menos (7 y :cool: al grupo de cosas externas.

Quizá lo he complicado en exceso, pero si quieres podemos probar con eso y ver qué tal se comporta. Y, en función de eso, ir probando y cambiándolo. Probablemente, y a menos que metamos la pata, no vas a ver funcionar las colas prácticamente nunca. Pero, si lo haces, que lo hagan bien.

A nivel interno, habría un cambio más que hacer dentro del firewall filter: hacer fasttrack de la comunicación empleados -> servidores, tal que eso se salte las colas. Esas dos VLANs han de ir comunicadas entre sí sin que les aplique los límites que se definen en las colas, que aplicarían únicamente para tráfico que se origine en ellas y vaya con otro destino (internet).

Si te animas dime, y te paso los comandos para ejecutarlo.

Saludos!
 
Vale, con las cifras de usuarios que manejas, la única cola PCQ que hay que crear "extra" es la de invitados, todos los demás se pueden apañar con la pcq-default, que está pensada para unos 40 usuarios (2000KB de tamaño total de cola, y 50K por cada usuario). La de usuarios la vamos a dimensionar para unos 500 usuarios, subiendo el tamaño total de la cola a 25.000KB. Así la dejas preparadas para eventos o para lo que necesites. Consumirá un pelín más de RAM, pero como prácticamente no se va a usar, eso no se usará hasta que esa red tenga ese número elevado de usuarios. Otra cosa que se puede hacer en esa cola es limitar el máximo por usuario: es decir, incluso cuando esa cola tendría 30Mbps de ancho de banda garantizado, no entregárselos de golpe al primer usuario, sino que se puede decir: dale como mucho X a cada usuario del reparto PCQ.

Con respecto a las velocidades, me gustaría que hicieras una prueba con la tabla que te pasé hace unos días. Básicamente lo que hice en ella es desechar la idea de "conexiones simétricas", que no lo son (la que te venden lo es, pero el uso de tus usuarios no lo va a ser), e intentar ponderar el uso de la conexión.
Así, por ejemplo, considero que VPN y Servidores van a tener más tráfico de subida que de bajada, y empleados es justo lo contrario. De igual manera, servidores tendrá mucho más tráfico de subida que de bajada (si algún día hay que "sacar" un video fuera), al contrario que invitados, que prácticamente sólo necesita descarga.

De igual forma, ponderé las prioridades, dándole más prioridad (5 y 6) a los grupos de IP's internos (VPN, Servidores, Empleados), y menos (7 y :cool: al grupo de cosas externas.

Quizá lo he complicado en exceso, pero si quieres podemos probar con eso y ver qué tal se comporta. Y, en función de eso, ir probando y cambiándolo. Probablemente, y a menos que metamos la pata, no vas a ver funcionar las colas prácticamente nunca. Pero, si lo haces, que lo hagan bien.

A nivel interno, habría un cambio más que hacer dentro del firewall filter: hacer fasttrack de la comunicación empleados -> servidores, tal que eso se salte las colas. Esas dos VLANs han de ir comunicadas entre sí sin que les aplique los límites que se definen en las colas, que aplicarían únicamente para tráfico que se origine en ellas y vaya con otro destino (internet).

Si te animas dime, y te paso los comandos para ejecutarlo.

Saludos!
Si, vamos a empezar con este tema, una pregunta dentro de Queue List => Simple Queues uso el winbox para crear las reglas que me mandaste en esta imagen ¿? ó lo hago con los comandos que me vayas a pasar ¿? y otro tema, la conexión de fibra es en realidad a 600Mb en los test de velocidad entrega 595 mas o menos.
queue_list_simple_queues.png
Si te digo que la configuración del router está intacta sin tocar nada desde que metimos la última regla de firewall para que accedieran por VPN los del grupo empleados que tenían acceso solamente a uno de los servidores.
No he vuelto a tocar absolutamente nada y no pienso hacerlo sin supervisión tuya :) Esto funciona ahora mismo a las mil maravillas y siempre voy a tener una copia hecha para restaurar si algún cambio nos diera problemas.

Aprovecho para comentarte otra cosa, las conexiónes VPN de empleados usan la puerta de salida por defecto y por ende cuando conectamos por VPN el internet que usa el equipo "remoto" que se ha conectado, pasa a ser el del router, entiendo que el ancho de banda que se le puede dar en ese momento para Internet es el máximo que pueda usar el tunel creado con la conexión encriptada l2tp. ¿Se puede hacer que un empleado conectado por VPN a la central tenga acceso a la red correspondiente 106 para empleados y 105 para acceder al servidor pero las salidas de ese equipo a internet las realice desde su conexión local a internet ¿? vamos que no pase todo el tráfico de su PC remoto por el tunel VPN hacia la central, sino solamente la parte que necesita de esa conexión. No sé si me he explicado.

Un Saludo
 
Te paso yo los comandos. Pásame un export de cómo lo tenes ahora mismo, tal que no metamos la pata con ninguna modificación del firewall (puedes quitar los usuarios PPP, que como sabes no nos interesan para nada)

Lo que comentas de la VPN se llama split tunneling. Con otro tipo de VPN's como IKEv2, es posible decirle al router "dile al remoto cuando se conecte que sólo le das acceso a tal o cual subred", y las rutas correspondientes se crean solas, pero con L2TP no puedes hacer eso. Tendría que ser cada cliente el que cree rutas estáticas en su equipo para chutar la 106 y la 105 vía el túnel. Se puede hacer un script para windows, si todos son clientes de ese SO, y que lo distribuyas para que lo corran cuando se conecten al a VPN. Pero, como ves, es un poco manual el tema.

La única opción que se me ocurre de automatizarlo en L2TP es que los metamos servidores y empleados en el mismo pool, y que los usuarios remotos también formen parte de ese pool. De esa manera, si juntamos todo por ejemplo en el la 106, todos verían todo, y esa ruta sí es automática en el equipo del cliente. Es un poco guarro, pero es todo lo que puedes hacer con L2TP.

Lo que sí le puedes hacer a cada usuario L2TP es restringirle el ancho de banda que va a consumir de tu remoto, tal que no lo sature. Pero claro, ahí te comes tú sí o sí su tráfico local, y no es muy recomendable.

En cuanto me mandes el export actual te paso el tema de las colas.

Saludos!
 
Es un poco guarro, pero es todo lo que puedes hacer con L2TP.
Nada de nada, si a ti te parece un poco "guarro" a mi no me vale. jajaja
Te pregunto que supondría configurar IKEv2 para esas conexiones ¿? se podría configurar manteniendo el L2TP y pasar algún usuario a un acceso por VPN mediante IKEv2 y una vez realizadas las pruebas con dicho usuario implantarlo en el resto de la organización ¿? es que esto que has dicho aqui.
Con otro tipo de VPN's como IKEv2, es posible decirle al router "dile al remoto cuando se conecte que sólo le das acceso a tal o cual subred", y las rutas correspondientes se crean solas
esto si que me mola. Y además aseguraríamos aún mas las conexiones remotas de los usuarios. No se... Tenemos tiempo para verlo mas adelante.

En cuanto me mandes el export actual te paso el tema de las colas.
Ya lo tiene usted enviado por priv.
Un Saludo
 
Buenas!

El tema del L2TP, como te digo, si preparas un script con las rutas y se lo pasas a los empleados, y les dices que desmarquen el "use default gateway" de la conexión L2TP, ya lo tienes. Chutarían por el túnel únicamente lo enrutado y listo; el resto de su trafico se queda en local. Además, se les puede preparar un .bat que ejecuten cuando se conecten, o simplemente asegurarte de que ninguno usa esos segmentos de red en casa y añadir las rutas como persistentes, si los equipos que manejan son equipos de trabajo, propiedad de la empresa. Te dejo información al respecto, como ves no es complejo: https://webhostinggeeks.com/howto/how-to-add-persistent-static-routes-in-windows/

En tu caso las rutas (persistentes o no, con el "-p") vendrían a ser algo así:
Código:
route add 192.168.105.0 mask 255.255.255.0 192.168.6.1
route add 192.168.106.0 mask 255.255.255.0 192.168.6.1

Te lo digo porque migrar a IKEv2 es tedioso, especialmente en windows, porque no soporta autenticación más que con certificados cliente, y no puedes hacer un identity que autentique sólo con una password y el certificado del servidor (en Mac, por ejemplo, sí se puede). Y, puestos a migrar, los pasamos a WireGuard en cuanto subas a la v7. Me gusta mucho IKEv2, pero sinceramente es para pensárselo dos veces, mírate los manuales al respecto, y verás por qué lo digo. Lo comparas con cómo montas WireGuard y me voy de cabeza a por el segundo.

Vale, tema router: lo tienes bastante fino, aunque se puede ir limpiando config. Cuando tengas el switch instalado dime, que le damos una vuelta.

Con respecto a las colas, revisando todo lo pasa por el router, excluyendo usuarios de admin y vlan-base, que entendemos no van a tener prácticamente tráfico, me sale todo esto a encolar:

Subredes
192.168.6.0/24 - vpn-empleados
192.168.7.0/24 - vpn-juncaril
192.168.100.0/24 - tunel-simotril
192.168.105.0/28 - servidores
192.168.106.0/24 - empleados
192.168.107.0/24 - coworking
192.168.108.0/29 - seguridad
192.168.200.0/23 - invitados

Como ves, hay que considerar también las VPN y los que vienen del otro lado del IPIP, puesto que estos también consumen ancho de banda de la conexión a internet.

Lo primero que vamos a hacer es volver a activar el fasttrack en el firewall, pero esta vez hacerlo únicamente entre las redes de empleados servidores, esa conexión no queremos que pase por las colas, puesto que es local y no consume ancho de banda externo. Modificaríamos esta regla que ahora mismo tienes comentada:
Código:
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related disabled=yes
Por esta otra
Código:
add action=fasttrack-connection chain=forward comment="fasttrack: empleados - servers" \
    connection-state=established,related src-address=192.168.106.0/24 dst-address=192.168.105.0/24

Hecho esto, estarías en disposición de armar las colas. La primera que tendríamos que definir es la cola padre, que contiene los límites de velocidad de la conexión. Si la conexión que tenéis es de 600 en lugar de 300, y te da 595 de velocidad en los tests, vayámonos a esa cifra o muy cercana para montar la cola padre: 590Mbps de subida/bajada. Además, cuando montes la segunda conexión, si tiene la misma velocidad (ojo con esto, que sino hay que redefinir esto), vais a ir muchísimo más sobrado, puesto que vamos a montar un failover que cubriría todo el tráfico si ambas conexiones son iguales, pero además va a partir el tráfico de los externos que, mientras pueda, lo sacará por la segunda conexión. Los míminos garantizados no cambiarán, pero sí que lo harán los máximos alcanzables, puesto que habrá el doble de ancho de banda disponible. Con todo y con eso, la cola general quedaría así:
Código:
/queue simple
add max-limit=590M/590M name=Total target=192.168.0.0/16
Como ves, hemos sumarizado todas las redes de un plumazo, utilizando un /16 para ello. Todo tráfico que caiga dentro de ese macro-grupo, se pasará a cada una de las colas hijas, las que irán filtrando ya por la subred correspondiente, aplicando los límites máximos y garantizados para subida y bajada.

Luego, después de darle muchas vueltas, voy a simplificar esto al máximo, porque como te digo, cuando te lías a tocar colas, la cosa la puedes complicar lo que te de la gana. Tiempo tendremos después de irlo afinando hasta dónde queramos. Siguiendo tu ejemplo, he montado esta tabla, a ver qué te parece:

SubredDescripciónMIR UploadMIR DownloadCIR UploadCIR DownloadPrioridad
192.168.6.0/24VPN empleados200Mbps100Mbps80Mbps25Mbps7
192.168.7.0/24VPN juncaril100Mbps50Mbps40Mbps15Mbps7
192.168.100.0/24Túnel simotril300Mbps300Mbps50Mbps50Mbps7
192.168.105.0/28Servidores300Mbps200Mbps80Mbps50Mbps6
192.168.106.0/24Empleados250Mbps500Mbps50Mbps100Mbps6
192.168.107.0/24Coworking200Mbps400Mbps30Mbps80Mbps8
192.168.108.0/29Seguridad100Mbps50Mbps50Mbps30Mbps8
192.168.200.0/23Invitados100Mbps300Mbps20Mbps50Mbps8

Las prioridades (8 la menor, y subiendo hasta el 1 que es la más prioritaria), significan que, una vez satisfechos los CIR de todas las subredes, las subredes de empleados y servidores tendrán prioridad en alcanzar sus MIR's, por delante de las VPN's y el túnel simotril, a su vez por delante de coworking, seguridad e invitados. Si sumas los CIR's, verás que nos quedamos en 400Mpbs. Lo hice así pensando en dejar hueco para crecer, o modificar esas colas a posteriori. Pero, sinceramente, si ahora te funciona como un tiro, cuando implementes esto, vas a funcionar como tiro y medio. No creo que tengas ni que tocarlo. Pero, por si acaso, ahí está.

Como te comenté, dado tu pequeño volumen de usuarios, las colas de prioridad PCQ por defecto (pcq-upload-default/pcq-download-default), nos bastan para manejar los clientes que va a tener cada subred, salvo al red de invitados. Esas colas vienen con un buffer de 2000KB y 50KB por cada substream o cola fifo (info: https://help.mikrotik.com/docs/display/ROS/Queues#Queues-PCQ), es decir, pueden manejar con soltura hasta 40 usuarios (divide el tamaño total del buffer de cola general entre el tamaño de cada cola fifo; 2000/50 = 40 usuarios). A partir de los cuarenta, te quearías sin buffer total para repartir, y los clientes del cuarenta en adelante empezarían a tener problemas para recibir lo que les toca del pastel. Como te dije estas colas son inteligentes, quiere decir que si hay un cliente conectado, tendrá el CIR/MIR para él solito. Si hay 10, cada uno tendrá la décima parte del CIR/MIR...y así. Además, no cuentan al usuario por conexión, sino cuando efectivamente está demandando tráfico, cosa que hace el reparto mucho más equitativo.

Con estos requisitos, lo primero que tendríamos que hacer es crear la cola pcq-upload-invitados y pcq-download-invitados, con los valores apropiados. Para no tener que hacer la cola total tan grande, reduciré el tamaño de las sub-colas fifo a 25KB. Considerando albergar unos 500 usuarios, nos saldría un tamaño total de la cola PQC de 12500KB. Esa cola se va a tragar, cuando esté a full, casi 27MB de RAM del cacharro, mientras que el resto de colas pqc-default se tragarán 4,3MB cada una. Considerando que tenemos 7 colas por defecto más la grande, tendríamos que nos vamos a zampar (4,3 * 7) + 27 ~ 57 MB de RAM cuando esto esté demandando tráfico a tope. Como ves, es importante tender esto en cuenta con respecto a los equipos a usar. En tu caso, con un equipo que tine 2GB de RAM y es multicore... cosquillas.

Al lío, cremos la cola pcq para invitados:
Código:
/queue type
add name=pcq-upload-invitados copy-from=pcq-upload-default pcq-limit=25 pcq-total-limit=12500
add name=pcq-download-invitados copy-from=pcq-download-default pcq-limit=25 pcq-total-limit=12500

Y daríamos de alta todas las colas, asociadas a la cola padre "Total"
Código:
/queue simple
add target=192.168.6.0/24 name=vpn-empleados parent=Total priority=7/7 \
max-limit=200M/100M limit-at=80M/25M queue=pcq-upload-default/pcq-download-default
add target=192.168.7.0/24 name=vpn-juncaril parent=Total priority=7/7 \
max-limit=100M/50M limit-at=40M/15M queue=pcq-upload-default/pcq-download-default
add target=192.168.100.0/24 name=tunel-simotril parent=Total priority=7/7 \
max-limit=300M/300M limit-at=50M/50M queue=pcq-upload-default/pcq-download-default
add target=192.168.105.0/28 name=servidores parent=Total priority=6/6 \
max-limit=300M/200M limit-at=80M/50M queue=pcq-upload-default/pcq-download-default
add target=192.168.106.0/24 name=empleados parent=Total priority=6/6 \
max-limit=250M/500M limit-at=50M/100M queue=pcq-upload-default/pcq-download-default
add target=192.168.107.0/24 name=coworking parent=Total priority=8/8 \
max-limit=200M/400M limit-at=30M/80M queue=pcq-upload-default/pcq-download-default
add target=192.168.108.0/29 name=seguridad parent=Total priority=8/8 \
max-limit=100M/50M limit-at=50M/30M queue=pcq-upload-default/pcq-download-default
add target=192.168.200.0/23 name=invitados parent=Total priority=8/8 \
max-limit=100M/300M limit-at=20M/50M queue=pcq-upload-invitados/pcq-download-invitados

Y poco más, a la espera de tus comentarios, a ver qué tal funciona. Ya me contarás qué tal pinta el tema.

Saludos!
 
Buenas!

El tema del L2TP, como te digo, si preparas un script con las rutas y se lo pasas a los empleados, y les dices que desmarquen el "use default gateway" de la conexión L2TP, ya lo tienes. Chutarían por el túnel únicamente lo enrutado y listo; el resto de su trafico se queda en local. Además, se les puede preparar un .bat que ejecuten cuando se conecten, o simplemente asegurarte de que ninguno usa esos segmentos de red en casa y añadir las rutas como persistentes, si los equipos que manejan son equipos de trabajo, propiedad de la empresa.
Esto es perfecto. Lo he probado con un .bat que crea las rutas y también añadiéndolas como persistentes, pero como persistentes no funciona bien porque al arrancar el equipo como se quedan almacenadas las rutas pero aún no está hecha la conexión VPN, la puerta de enlace es correcta pero al establecer "la interface" coge el solito la ip local y no la enruta bien se ver perfecto usando el comando "route print". Algo no estaré haciendo bien, pero no pasa nada porque con el archivo .bat que si se ejecuta después de haber realizado la conexión VPN (a la que previamente en protocolo ipv4 -> avanzado se le desactiva el "use default gateway" y va como las balas. Funciona así a la perfección.
Me quedo con esta solución que tira muy bien y paso de la solución de rutas persistentes.
---

puestos a migrar, los pasamos a WireGuard en cuanto subas a la v7
En cuanto desaparezcan los problemas que tiene el Cloud Core Router con esa versión, upgradeamos y le metemos mano, he leido un poquito sobre WireGuard y lo ponen como la solución definitiva al menos por ahora a tuneles vpn seguros y rápidos de configurar.

Me gusta mucho IKEv2, pero sinceramente es para pensárselo dos veces, mírate los manuales al respecto, y verás por qué lo digo.
Me he estado leyendo este manual tuyo MANUAL: Mikrotik, IKEv2 VPN a fondo y uffff. el tema de certificados y no poder hacer un identity que autentique sólo con una password y el certificado del servidor usando los "gurrindows" de los clientes no me anima a meterle mano.

Me pongo con el tema de las colas y lo hago en domingo que no hago mucho estropicio, y ya te cuento.
Un Saludo y gracias como siempre por todo.
 
Lo primero que vamos a hacer es volver a activar el fasttrack en el firewall, pero esta vez hacerlo únicamente entre las redes de empleados servidores, esa conexión no queremos que pase por las colas, puesto que es local y no consume ancho de banda externo. Modificaríamos esta regla que ahora mismo tienes comentada:
Hecho
Enriquecido (Código BB):
add action=fasttrack-connection chain=forward comment="fasttrack: empleados - servers" connection-state=established,related \
    dst-address=192.168.105.0/24 src-address=192.168.106.0/24 src-address-list=""

Estoy intentando entender todo lo que me has explicado.
las colas de prioridad PCQ por defecto (pcq-upload-default/pcq-download-default)
este es el tipo de cola que se usará en todas las subredes a excepción de la de invitados 192.168.200.0/23 puesto que ésta superaría puntualmente los 40 usuarios.
Me he leído un poquito por encima la info que me enlazas aquí: (info: https://help.mikrotik.com/docs/display/ROS/Queues#Queues-PCQ) aunque no me queda clara una cosilla que pone al final con respecto al /queue interface. Luego te pongo imagen.
Como la red invitados necesitará una cola mayor, lo primero que hacemos es dimensionarla verdad ¿? que son estas dos líneas.

/queue type add name=pcq-upload-invitados copy-from=pcq-upload-default pcq-limit=25 pcq-total-limit=12500 add name=pcq-download-invitados copy-from=pcq-download-default pcq-limit=25 pcq-total-limit=12500
Con esto lo que hacemos es tenerlas definidas para que sean usadas solamente por la regla simple queue de la red de invitados, y todas las demás usaría las pcq-default que están dimensionadas a 50Kb/2000Kb mientras que esta se dimensiona a 25Kb/12500Kb
Juer empiezo a entender algo, pero es un follón. jajaja :) si me quedo con que es importante tener este tema del consumo de memoria en cuenta porque según se dimensiones podemos quedarnos sin memoria en función de que equipo mikrotik estemos usando.

Los tipos de cola definidos, en particular los dimensionados para invitados con los parámetros de tamaño y total indicados.
Queue Types.png


La lista de colas configuradas
Simple Queues.png


Y por ultimo este tema de Interfaces Queues sobre el que quería preguntarte, algunas interfaces (cAPac1 a 3) no tienen tipo de cola asignado dentro de mi ignorancia, eso no tiene nada que ver verdad ¿?
Interface Queues.png


Gracias por todo, ahora mismo funciona y voy a dejarlo así un tiempo a ver como responde.
Un Saludo señor.
 
Ojo con la regla de fasttrack, que se te que quedado por ahí de pico un src-address-list="" vacío. Ve a ese campo y pulsa en la flechita que cierra el desplegable, tal que en el export no salga ese parámetro.

Con respecto a las colas, hemos usado las que vienen por defecto, salvo para invitados, que como sabemos que vamos a tener potencialmente más de 40 clientes, hemos creado dos tipos de colas nuevas, copias de las colas por defecto, pero con un tamaño diferente. A más tamaño, más RAM consume la cola cuando se demanda el 100% del uso sobre ella, por eso hay que tenerlo en cuenta.
De lo del queue interface pasa, que eso no lo vamos a tocar.

Tiene todo muy buena pinta, ahora sólo hay que ver cómo se comporta en producción.

Saludos!
 
Ojo con la regla de fasttrack, que se te que quedado por ahí de pico un src-address-list="" vacío. Ve a ese campo y pulsa en la flechita que cierra el desplegable, tal que en el export no salga ese parámetro.
lo vi antes, pero es que no sé porque, intenté meter la regla por terminal y me daba un error en file 11 y entonces lo hice desde winbox editando la que teníamos deshabilitada. Voy a cambiarlo ahora mismo, le hago copia de seguridad y lo dejamos sin tocar toda esta semana, y así vamos probando, además ya han llevado 3 equipos a la oficina y empiezan a trabajar desde ya (irán incorporando mas máquinas) le voy haciendo seguimiento a lo largo de la semana, mirando conexiones wifi (ya hemos dejado una impresora de red también fijándole una MAC) teléfonos de estos primeros empleados que se han trasladado, ordenadores portátiles, etc...

Mientras voy terminando la documentación que les estoy realizando para dejarlo todo bien escrito, que luego falta uno y el que llega no se entera y creo que es importante que se hagan las cosas pero sin dejarlas "cripticas" sino se convierten en "cajas negras" que nadie se atreve a tocar.

Por ahora va fenómeno. Están ya dándole las vueltas a contratar un 4G de Movist (alcanza 100Mb en pruebas previas dentro del recinto) ó un operador wifi que tenemos por la zona para todo el tema del FAILOVER.

Una vez que lo terminemos, no te voy a soltar :) te plantearé otro escenario, en este caso mío personal que lo tengo hecho un desastre y habiendo visto lo bien que esto funciona (segmentación con vlan y capsman), me he decidido a cambiarlo todo totalmente, ya te contaré.

Un Saludo a todos los foreros y sobre todo gracias @pokoyo
 
Cuando dices que has fijado la MAC de la impresora, entiendo que te refieres a que le has asignado una IP estática, usando para ello un lease estático del DHCP, ¿no? Lo digo porque cuidado con jugar con las direcciones MAC en la tabla ARP, porque la puedes liar.

Con respecto a los móviles, intenta que, aunque sean empleados, usen la wifi de invitados, que para eso está (a menos que los terminales sean de empresa y estén gestionados). Lo digo porque me fío lo justo de terminales móviles metidos dentro de la red de empleados, con acceso a servidores.

Lo del failover, intenta que sea fibra, y que sea de la misma velocidad que la línea principal, porque sino tenemos que montar varias jerarquías de colas, acorde a la velocidad de salida, y tendríamos que montar algo para que se apliquen de manera automática cuando eso pase.

Y, lo del proyecto tuyo personal, sin problema. Mi último proyecto fue montar la red de un familiar en una reforma, y la verdad que quedó de vicio. Ya te pasaré unas fotos.

Saludos!
 
usando para ello un lease estático del DHCP, ¿no? Lo digo porque cuidado con jugar con las direcciones MAC en la tabla ARP, porque la puedes liar.
Me interesa que me confirmes si esta es la manera, porque no quiero meter la pata.

Lo que hago es que todos los dispositivos finales, impresoras, ordenadores, teléfonos, etc... tienen que solicitar dirección IP (ya he pedido cita con el tatuador jajaja).
Luego me voy a través de Winbox al apartado IP =>DHCP Server a la solapa Leases ahí veo que dirección ha sido concedida a tal o cual dispositivo y veo que aparece con la "D" a la izquierda porque ha sido concedida de forma dinámica, pues por ejemplo en los servidores (105), los dos equipos de seguridad (10:cool:, los 3 cap's + switch css326 + una conexión ILO de uno de los servidores HP proliant (99) los he marcado en ese mismo listado como "Make static" en particular hay dos impresoras de red que he hecho eso mismo pero dentro de la red de empleados (106) te mando pantallazo.
dhcp leases.png

Como la primera vez que las quiero hacer estáticas habrán cogido direcciones del servidor DHCP arbitrarias y yo quiero establecerlas específicamente siempre dentro de su red, lo que hago es pulsar doble click, se abre la pantalla de esa concesión que he seleccionado y le indico manualmente que dirección IP quiero que le asigne siempre el servidor DHCP a ese dispositivo.
establecer ip.png

Si esta no es la forma correcta dímelo porque yo en IP => ARPLIST no he tocado nada y como no lo entiendo NI LO PIENSO TOCAR.
arp list.png


Con respecto a los móviles, intenta que, aunque sean empleados, usen la wifi de invitados, que para eso está (a menos que los terminales sean de empresa y estén gestionados). Lo digo porque me fío lo justo de terminales móviles metidos dentro de la red de empleados, con acceso a servidores.
Pues lo cierto es que prácticamente todos los móviles de los empleados son de empresa y gestionados, pero también es cierto que en esos móviles no hay necesidad de conectar a la red de empleados (106) porque no usan aplicaciones que tengan que tener acceso a tal o cual servidor, por lo que hablaré con la empresa para recomendar que se conecten a la red de invitados.

Lo del failover, intenta que sea fibra, y que sea de la misma velocidad que la línea principal, porque sino tenemos que montar varias jerarquías de colas, acorde a la velocidad de salida, y tendríamos que montar algo para que se apliquen de manera automática cuando eso pase.
Aquí si la vamos a "cagar" nuevamente, no podemos contratar otra fibra porque localmente en esa población solo hay un proveedor de fibra desde hace un año y es uno local de la zona y precisamente las dos conexiones que ya hay allí funcionando aunque están contratadas con diferentes empresas, terminan en el mismo proveedor, vamos que "los dos pelos de fibra" que llegan allí están conectados al otro extremo en el mismo "OLT" así que no me sirve.
Tenemos que decantarnos por otra tecnología distinta porque si cae ese proveedor de fibra, se me caen todas las conexiones. No se si mi razonamiento es el correcto, pero creo que si.
Sé que es un peñazo, pero hasta que otro operador no despliegue su red de fibra, es lo que hay. Así que lo mas rápido que hemos visto por la zona siendo otra tecnología distinta, ha sido "4G" de movis. Sé que esto ante una caída de la fibra principal, puede afectarnos al reparto con el tema de colas y seguramente será un peñazo tener que reconfigurar de forma automática las colas.
Entiendo que habría que generar un script que borraría las colas actualmente establecidas y generara otras teniendo en cuenta el ancho de banda de la conexión Failover (diferente reparto y minimizar invitados y coworking). y otro script que vuelva a borrar las colas establecidas cuando estaba el FAILOVER y ponga las "normales de fibra" cuando ésta esté disponible.

Aún no tenemos el failover funcionando, a mi se me ocurre que por lo pronto cuando lo tengamos, y aunque sea manualmente, ¿puedo deshabilitar las colas actualmente establecidas sin mas, y ya se metería mano al script posteriormente que automatice el cambio de las mismas. Siento complicar la instalación pero es lo que hay.

Y, lo del proyecto tuyo personal, sin problema. Mi último proyecto fue montar la red de un familiar en una reforma, y la verdad que quedó de vicio. Ya te pasaré unas fotos.
Gracias por el ofrecimiento, de verdad, es lo que te dije antes, es que habiendo visto todo lo que hemos hecho, ahora me doy cuenta de "la mierda" que tengo yo personalmente montada en mis instalaciones (el bajo de mi casa es mi taller ó Techlab donde trabajo y el resto son dos plantas de vivienda) ya te mandaré fotos y algún plano para tener clara la instalación. Pero por priv. porque de verdad que me averguenzo de ella. :) además como es un tema personal mío, no tengo prisa ninguna.

Un Saludo
 
Arriba