Me gustaría agregar algún tipo de gestión de tráfico a nuestra línea de Internet. Después de leer mucha documentación, creo que HFSC es demasiado complicado para mí (no entiendo todo el tema de las curvas, me temo que nunca lo haré bien), CBQ no se recomienda y, básicamente, HTB es la forma de hacerlo. ir para la mayoría de la gente.
Nuestra red interna tiene tres "segmentos" y me gustaría compartir el ancho de banda más o menos equitativamente entre ellos (al menos al principio). Además, debo priorizar el tráfico según al menos tres tipos de tráfico (tráfico en tiempo real, tráfico estándar y tráfico masivo). Compartir el ancho de banda no es tan importante como el hecho de que el tráfico en tiempo real siempre debe tratarse como tráfico premium siempre que sea posible, pero, por supuesto, ninguna otra clase de tráfico tampoco puede morir de hambre.
La pregunta es qué tiene más sentido y también garantiza un mejor rendimiento en tiempo real:
Creando una clase por segmento, cada una con la misma tarifa (la prioridad no importa para las clases que no tienen licencia según el desarrollador de HTB) y cada una de estas clases tiene tres subclases (licencias) para los 3 niveles de prioridad (con diferentes prioridades). y diferentes tarifas).
Tener una clase por nivel de prioridad en la parte superior, cada una con una tasa diferente (nuevamente, la prioridad no importará) y cada una con 3 subclases, una por segmento, mientras que las 3 en la clase en tiempo real tienen el prio más alto y el prio más bajo en general. clase, etcétera.
Intentaré aclarar esto con la siguiente imagen artística ASCII:
Case 1:
root --+--> Segment A
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment B
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment C
+--> High Prio
+--> Normal Prio
+--> Low Prio
Case 2:
root --+--> High Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Normal Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Low Prio
+--> Segment A
+--> Segment B
+--> Segment C
El caso 1 parece la forma en que la mayoría de la gente lo haría, pero a menos que no lea correctamente los detalles de implementación de HTB, el caso 2 puede ofrecer una mejor priorización.
El manual de HTB dice que si una clase ha alcanzado su tasa, puede pedir prestado a su matriz y, al pedir prestado, las clases con mayor prioridad siempre obtienen el ancho de banda ofrecido primero. Sin embargo, también dice que las clases que tienen ancho de banda disponible en un nivel de árbol inferior siempre son preferidas a aquellas en un nivel de árbol superior.independientemente de la prioridad.
Supongamos la siguiente situación: el segmento C no envía tráfico. El segmento A solo envía tráfico en tiempo real, lo más rápido que puede (lo suficiente para saturar el enlace por sí solo) y el segmento B solo envía tráfico masivo, lo más rápido que puede (de nuevo, lo suficiente como para saturar el enlace completo por sí solo). ¿Lo que sucederá?
Caso 1:
Tanto el segmento A->Prio alto como el segmento B->Prio bajo tienen paquetes para enviar, dado que A->Prio alto tiene la prioridad más alta, siempre se programará primero, hasta que alcance su velocidad. Ahora intenta pedir prestado del segmento A, pero como el segmento A está en un nivel superior y el segmento B->Prio bajo aún no ha alcanzado su tasa, esta clase ahora recibe el servicio primero, hasta que también alcanza la tasa y quiere pedir prestado del Segmento B. Una vez que ambos hayan alcanzado sus tasas, ambos estarán en el mismo nivel nuevamente y ahora el Segmento A->Prio alto va a ganar nuevamente, hasta que alcance la tasa del Segmento A. Ahora intenta pedir prestado a la raíz (que tiene mucho tráfico libre, ya que el segmento C no está utilizando nada de su tráfico garantizado), pero nuevamente, tiene que esperar a que el segmento B->Low Prio también alcance el nivel raíz. Una vez que eso sucede, la prioridad se tiene en cuenta nuevamente y esta vez el Segmento A->Prio alto obtendrá todo el ancho de banda restante del Segmento C.
Caso 2:
Prio alto->Segmento A y Prio bajo->Segmento B tienen paquetes para enviar, nuevamente Prio alto->Segmento A ganará ya que tiene la mayor prioridad. Una vez que alcanza su tasa, intenta pedir prestado a High Prio, que tiene ancho de banda libre, pero al estar en un nivel más alto, tiene que esperar a que Low Prio->Segment B vuelva a alcanzar su tasa. Una vez que ambos hayan alcanzado su tasa y ambos tengan que pedir prestado, High Prio->Segment A ganará nuevamente hasta que alcance la tasa de la clase High Prio. Una vez que eso sucede, intenta pedir prestado a root, al que nuevamente le queda mucho ancho de banda (todo el ancho de banda de Normal Prio no se utiliza en este momento), pero tiene que esperar nuevamente hasta que Low Prio->Segment B alcance el límite de velocidad del Clase Low Prio y también intenta tomar prestado de root. Finalmente, ambas clases intentan tomar prestado de la raíz, se tiene en cuenta la prioridad y High Prio->Segment A obtiene todo el ancho de banda que le queda a la raíz.
Ambos casos parecen subóptimos, ya que en cualquier caso el tráfico en tiempo real a veces tiene que esperar al tráfico masivo, aunque todavía queda mucho ancho de banda que podría tomar prestado. Sin embargo, en el caso 2 parece que el tráfico en tiempo real tiene que esperar menos que en el caso 1, ya que sólo tiene que esperar hasta que se alcance la tasa de tráfico masivo, que probablemente sea menor que la tasa de todo un segmento (y en el caso 1 (esa es la tarifa que tiene que esperar). ¿O estoy totalmente equivocado aquí?
Pensé en configuraciones aún más simples, usando una qdisc prioritaria. Pero las colas prioritarias tienen el gran problema de que causan hambre si no se limitan de alguna manera. El hambre no es aceptable. Por supuesto, se puede colocar un TBF (Token Bucket Filter) en cada clase de prioridad para limitar la tasa y así evitar la inanición, pero al hacerlo, una única clase de prioridad ya no puede saturar el enlace por sí sola, incluso si todas las demás clases de prioridad están vacíos, el TBF evitará que eso suceda. Y esto también es subóptimo, ya que ¿por qué una clase no obtendría el 100% del ancho de banda de la línea si ninguna otra clase lo necesita en este momento?
¿Algún comentario o idea sobre esta configuración? Parece muy difícil de hacer usando qdiscs tc estándar. Como programador, era una tarea muy fácil si pudiera simplemente escribir mi propio programador (cosa que no tengo permitido hacer).
Respuesta1
Si entiendo htb correctamente, entonces la tarifa está "garantizada". Esto significa tutenerideas sobre la tasa del tráfico "en tiempo real". Sólo si se supera esta tasa, se endeudará. Si varias clases quieren pedir prestado, el prio debería entrar en vigor. Las tasas garantizadas deberían sumar el límite físico. De lo contrario, es demasiado complicado.
En mi humilde opinión, el caso A nunca funcionará realmente, ya que es necesario tener prioridad o limitación de velocidad en el nivel raíz. Las prioridades/tarifas en los diferentes segmentos no se conocen entre sí y se manejarán de la misma manera.
Lo que probablemente quieras es: poner la "velocidad" para prio bajo y normal en 0 o cerca de él y agregar "techo" para el resto del ancho de banda, para prio alto garantizas una tasa del 100% del físico.