Separando los Estados de Tráfico Actual y Tráfico Puesto en Fila

Durante mucho tiempo, LibreQoS solo ha recopilado datos de tráfico en el momento en que los paquetes entran al Controlador de Tráfico (TC). Esto ha provocado que el monitoreo de LibreQoS ocasionalmente parezca inexacto y no resalte qué tan preciso es realmente el control de tráfico con CAKE/fq_codel + HTB. Una actualización reciente cambió esto.

Comencemos entendiendo el camino que siguen los paquetes a través del kernel de Linux y cómo LibreQoS interactúa con ellos.

1. Un paquete llega a un puerto de interfaz de red.
2. El paquete es inmediatamente (antes de cualquier procesamiento del kernel) redirigido a XDP.
3. El sistema XDP de LibreQoS analiza el tráfico y asegura que se procese en la CPU correcta. También recopilamos datos en el momento que entra a la fila (enqueue-time): tipo de paquete, a que flujo pertenece y el dispositivo del lado del ISP con el que está asociado.
4. Se realiza el cambio de CPU del paquete (si es necesario), y ya sea el puente XDP o el puente de Linux redirige el paquete hacia la interfaz de salida.
5. TC-Classify, otro programa eBPF, se ejecuta. Generalmente reutiliza metadatos del primer paso para evitar buscar los mismos datos de nuevo, y el paquete es asignado a un punto de entrada de TC adecuado.
6. TC — el sistema de control de tráfico de Linux — asigna el paquete a la fila y en el qdisc correspondiente. Esta será una fila CAKE o fq_codel, dentro del gran árbol HTB que representa toda la red.
7. HTB — el sistema “Hierarchical Token Bucket” que representa la estructura completa de la red — asigna ancho de banda a diferentes partes de la red. Lo hace “gastando” tokens (que se recargan en cada ciclo), primero hasta la tasa mínima de los circuitos y luego hasta su límite máximo (ceiling), asegurando que todos reciban una porción justa.
8. Una vez que HTB ha asignado tokens, los qdiscs (disciplinas de fila) que representan a los clientes individuales del ISP pueden “retirar de la fila” el tráfico. CAKE y fq_codel utilizan diferentes estrategias para esto, ambas enfocadas en reducir el bufferbloat y mejorar la equidad. Los paquetes que han esperado demasiado tiempo son descartados.
9. TC transfiere el paquete al controlador de la interfaz para su transmisión. Aquí es donde un kprobe puede ayudar, permitiendo inspeccionar el paquete justo antes de salir.

Entonces, en la interfaz del kernel de LibreQoS, podemos definir otra función:

SEC("kprobe/dev_hard_start_xmit")
int kprobe_xmit(struct pt_regs *ctx) {
    ...
}

En esta función, rápidamente asociamos el paquete con el remitente e incrementamos los contadores de tráfico “real”. Ahora podemos incluir el “rendimiento real” junto con el “tráfico puesto en las filas” en las vistas de circuitos:

Esta mejora se refleja en gran parte de las visualizaciones de LibreQoS. Ahora podemos mostrar todos los elementos del panel con niveles de tráfico reales, enviar datos más precisos a Insight y finalmente demostrar cuánto ancho de banda CAKE te está ahorrando diariamente.

Gracias a NLnet por patrocinar este proyecto.