Numeración de clase / filtro de Linux TC

Actualmente estoy trabajando en una solución de configuración de tráfico para empresas de nivel ISP, y llegué a un problema interesante (algo filosófico).

Mirando sobre el número de puntos finales que el sistema debería manejar (que es alrededor de ~ 20k), me preocupé un poco por lo que sucedería cuando tuviera que crear políticas / dar forma al tráfico de más usuarios. Como actualmente estoy usando el árbol de configuración HFSC (vea tc-hfsc, principalmente lo mismo pero más genial que HTB mejor 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 máximo posible de 64k usuarios configurados por esta solución.

Del mismo modo, si deseo administrar los filtros TC de manera eficiente (por ejemplo, no usar la técnica de "vaciar todo"), necesito poder eliminar o modificar entradas de filtro 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.

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

Muchas gracias,

-mk

(por cierto, espero que esto no vaya al escenario "64k usuarios deberían ser suficientes para todos" ...)

— exa
fuente

Todos esos valores se almacenan en el espacio del kernel, para hacerlos más grandes necesitaría recompilar las utilidades del kernel y del espacio del usuario. ¿Has intentado usar el kernel de 64 bits? Pueden definirse como 32 bits allí.

— Hubert Kario el

El kernel de 64 bits usa los mismos tamaños. Por ejemplo, el número de filtro es u32-integer que consiste en la parte superior (protocolo) y la parte inferior (prio), ambos obviamente de 16 bits. Los ID de clase están codificados como u16. Probablemente intente preguntarle a alguien en LKML.

— exa

Incluso usando hash para tus filtros, tendrás muchos problemas de E / S si estás usando tantos filtros (supongo que para aguas arriba y aguas abajo). He pasado mucho tiempo y tuve que parchear la implementación de colas dentro del kernel para que las cosas funcionen sin ksoftirqd. Usé un parche de un tipo llamado Simon Lodal que conocí en LARTC hace 4 años. Eche un vistazo a su parche mail-archive.com/lartc@mailman.ds9a.nl/msg16279.html . Puede intentar enviarle un correo electrónico porque siempre tiene una versión muy actualizada (contra el último núcleo) con él.

— Pabluez

@Pabluez Muchas gracias, intentaré sacar lo mejor de ello.

— exa

Creo que su requisito es válido, pero como Pabluez escribió, esto ciertamente implica muchos cambios en el núcleo. No quiero decir "lo estás haciendo mal", pero te animo a que revises el flujo abierto, donde las partes inferiores del manejo de paquetes se realizan en el nivel del conmutador y la vigilancia se realiza en un software personalizado, presumiblemente corriendo en espacio de usuario. No sé si cumple con sus requisitos, pero ciertamente vale la pena investigarlo.

— AndreasM

Respuestas:

Creo que no debe poner a 64k usuarios con clases y filtros ascendentes y descendentes 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á 64k usuarios sin conexión (y se bloqueará fácilmente con esa cantidad de tráfico). No olvide que CADA paquete que pasa a través de 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 (que es difícil poner en cola correctamente).

— Pabluez
fuente

Estoy asegurando la disponibilidad del servicio en otro nivel, pero gracias por la preocupación. En realidad, con buenas NIC, no es tan difícil tener un enrutador Linux que pueda reenviar 10 Gbits.

— exa

Para la pregunta original, estaba más interesado en cosas como agregar 5 clases diferentes para cada usuario, lo que me permitiría hacer un trabajo QOS realmente bueno (como manejar transmisiones y tráfico en tiempo real por separado), pero es impensable en las condiciones actuales (con mi caso de uso actual de ~ 20k puntos finales ya estaría detrás del límite).

— exa

bien, reenviar 10Gbits no es ningún problema, el problema es tener muchos filtros y clases de 64k * 2 (subidas y bajadas). Buena suerte: D

— Pabluez

Puede dividir el manejo del tráfico en dos máquinas (usando 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á óptimamente 10k usuarios si puede dividir los rangos 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 configuración del tráfico se distribuirá en varias máquinas. El nodo central solo reenviará el tráfico al nodo de procesamiento correcto.

— Khaled
fuente