Pregunta Linux TC clase / filtro de numeración


Actualmente estoy trabajando en una solución de modelado de tráfico para compañías de nivel ISP y llegué a un problema interesante (un poco filosófico).

Mirando la cantidad de puntos finales que debe manejar el sistema (que es de alrededor de ~ 20k), me preocupé un poco por lo que sucedería cuando tuviera que configurar el tráfico de más usuarios. Como actualmente estoy usando el árbol de conformación HFSC (vea tc-hfsc, en su mayoría lo mismo que el HTB más conocido) para toda la red, necesitaría usar más ClassID (obviamente, al menos uno para cada usuario en el red). El problema que encontré fue que los TC ClassID son algo limitados: son números de 16 bits, lo que me da un posible máximo de 64k usuarios configurados por esta solución.

De manera similar, si quiero administrar los filtros de TC de manera eficiente (por ejemplo, no usar la "técnica de eliminación de todo"), debo poder eliminar o modificar las entradas de filtros individuales. (Estoy usando algo similar a la tabla hash de LARTC [1]). Nuevamente, el único método que parece estar funcionando con esto es numerar todos los filtros usando prioridades individuales (tc filter add dev ... prio 1). No hay otro parámetro que pueda usarse para este propósito y, lamentablemente, prio también es de 16 bits solamente.

Mi pregunta es la siguiente: ¿Existe algún buen método para ampliar el "espacio de identificador" disponible, como clsid de 32 bits para el comando 'tc class', y prioridades de 32 bits (o cualquier otro control de modificación) para 'tc filter' ¿mando?

Muchas gracias,

-mk

(Por cierto, espero que esto no vaya a "64k usuarios debería ser suficiente para todos" escenario ...)


12
2017-08-21 14:55


origen


Todos esos valores se almacenan en el espacio del kernel, para hacerlos más grandes, necesitaría volver a compilar las utilidades del kernel y del espacio del usuario. ¿Has probado con el núcleo de 64 bits? Se pueden definir como 32 bits allí. - Hubert Kario
El kernel de 64 bits usa los mismos tamaños. Por ejemplo, el número de filtro es u32-integer que consta de parte superior (protocolo) y parte inferior (prio), obviamente de 16 bits. Los identificadores de clase están codificados como u16. Probablemente intentaré preguntarle a alguien en LKML. - exa
incluso si usa hash para sus filtros, tendrá muchos problemas de E / S si está utilizando tantos filtros (supongo que para upstream y para downstream). He pasado mucho tiempo y tuve que parchear la implementación de colas dentro del kernel para que las cosas funcionaran contigo ksoftirqd. Usé un parche de un tipo llamado Simon Lodal que conocí en LARTC hace 4 años. Echa un vistazo a su parche mail-archive.com/lartc@mailman.ds9a.nl/msg16279.html . Puede intentar enviarle un correo electrónico porque él siempre tiene una versión muy actualizada (contra el último kernel) con él. - Pabluez
@Pabluez Muchas gracias, intentaré sacar lo mejor de esto. - exa
Creo que su requerimiento es válido pero, como Pabluez escribió, esto ciertamente involucra muchos cambios en el núcleo. No quiero decir "lo estás haciendo mal", pero te recomendaría que compruebes Openflow, donde las partes inferiores de la gestión de paquetes se realizan en el nivel del conmutador y la vigilancia se realiza en un software personalizado, probablemente ejecutándose en espacio de usuario. No sé si se ajusta a sus necesidades, pero ciertamente vale la pena investigar. - AndreasM


Respuestas:


Creo que no deberías poner 64k usuarios con clases y filtros en sentido ascendente y descendente para cada uno de ellos en la misma interfaz. Puede repetir los controladores para cada interfaz que tenga, así que agregue más interfaces. Necesitará un trabajo / servidor / NIC increíble para tener estas cosas. Si el servidor falla, tendrá 64.000 usuarios sin conexión (y se bloqueará fácilmente con esa cantidad de tráfico). No olvide que CADA paquete que pasa por su tarjeta de red será revisado y clasificado por un filtro y enviado a una clase para ser puesto en cola. Esto es mucho trabajo para una NIC de una puerta de enlace ISP con 64k clientes. Principalmente con todo el flujo de video que tenemos hoy en día (lo cual es difícil de poner en cola correctamente).


2
2017-12-30 14:11



Estoy asegurando la disponibilidad del servicio en algún otro nivel, pero gracias por la preocupación. En realidad, con una buena NIC, no es tan difícil tener un enrutador de Linux que pueda reenviar 10 Gbits. - exa
En cuanto a la pregunta original, me interesaban más cosas como agregar 5 clases diferentes para cada usuario, lo que me permitiría realizar un trabajo de QOS realmente bueno (como manejar flujos y tráfico en tiempo real por separado), pero es casi impensable en las condiciones actuales (con mi caso de uso actual de ~ 20k puntos finales ya estaría detrás del límite). - exa
De acuerdo, reenviar 10 Gbits no es ningún problema, el problema es tener muchos filtros y clases de 64k * 2 (subidas de bajadas). Buena suerte aunque: D - Pabluez


Puede dividir la gestión del tráfico en dos máquinas (utilizando una tercera) en lugar de manejar todo el tráfico en una máquina. El tráfico se puede enrutar simplemente en función de la dirección IP de origen. Por lo tanto, tendrá usuarios de 10k óptimamente si puede dividir el (los) rango (s) de IP de manera uniforme.

Por supuesto, puede usar más de dos máquinas si es necesario. Creo que esto puede ser mejor que parchear el kernel de Linux y hacer otros hacks. En resumen, la conformación del tráfico se distribuirá en varias máquinas. El nodo central simplemente reenviará el tráfico al nodo de procesamiento correcto.


0
2018-01-02 11:15