Otro intento para configurar QoS en Linux: Día 2

Hasta el momento y a grandes rasgos, hemos limitado el uso de ancho de banda a un límite especifíco. Luego, hemos modelado la cola para que esta reparta el uso de ancho de banda de manera casi equitativa entre todas las conexiones: Dicha política se verifica para todo el tráfico en nuestra red.

Lo siguiente será hacer una configuración que planteé precisamente el significado de QoS: Clasificaremos tráfico y vamos a aplicarle políticas específicas a cada tipo de tráfico. Puede pensarse un poco al revés: Estableceremos políticas y luego vamos a especificar a que tráfico le aplicamos cada una.

El primer intento de configuración va de la siguiente forma:

#!/bin/bash

## Borramos la configuración anterior. 
## Cuando se tenga la configuración por defecto, se lanza un mensaje de error "RTNETLINK answers: No such file or directory"
tc qdisc delete dev ens2 root

## Cambiamos qdisc de fast_fifo a htb. 
## Dentro del esquema de HTB, este es llamado ROOT
tc qdisc add dev ens2 root handle 1:0 htb default 10

## Agregamos la primera clase. 
## Dentro del esquema de HTB, este es llamado INNER. No hay shapping en este momento, pero es necesario configurarle para el funcionamiento de los leaf
tc class add dev ens2 parent 1:0 classid 1:1 htb rate 20480 ceil 20480

## Dentro del esquema de HTB, este es llamado LEAF. Este determina la política por defecto 
tc class add dev ens2 parent 1:1 classid 1:10 htb rate 2540 ceil 2540
### Creamos los nuevos LEAF que describen dos nuevas políticas para el tráfico. 
tc class add dev ens2 parent 1:1 classid 1:20 htb rate 7680 ceil 7680
tc class add dev ens2 parent 1:1 classid 1:22 htb rate 10240 ceil 10240

## Dentro de cada clase LEAF, agregamos una QDISC de tipo SFQ. 
## SFQ intentará repartir el ancho de banda de forma más o menos equitivativa
tc qdisc add dev ens2 parent 1:10 handle 130: sfq perturb 5
tc qdisc add dev ens2 parent 1:20 handle 140: sfq perturb 5
tc qdisc add dev ens2 parent 1:22 handle 150: sfq perturb 5

## Filtro en tc
## Se especifica mediante los filtros de tc que tráfico se envía a que política
## Usamos el filtro handle, es bastante simple y económico en términos de procesamiento
tc filter add dev ens2 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev ens2 parent 1:0 prio 0 protocol ip handle 22 fw flowid 1:22

## Pre-filtro en iptables
## Este es precisamente el filtraje del tráfico: Marcamos con iptables que tráfico es cada cosa
iptables -t mangle -F
iptables -t mangle -A POSTROUTING -p tcp -m multiport --sport 22 -j MARK --set-mark 20
iptables -t mangle -A POSTROUTING -p tcp -m multiport --dport 80,443 -j MARK --set-mark 22

Las clases por ahora se ven de la siguiente forma:

tc class show dev ens2
class htb 1:22 parent 1:1 leaf 150: prio 0 rate 10240bit ceil 10240bit burst 1600b cburst 1600b
class htb 1:1 root rate 20480bit ceil 20480bit burst 1600b cburst 1600b
class htb 1:10 parent 1:1 leaf 130: prio 0 rate 2536bit ceil 2536bit burst 1599b cburst 1599b
class htb 1:20 parent 1:1 leaf 140: prio 0 rate 7680bit ceil 7680bit burst 1599b cburst 1599b

La configuración consta de dos políticas implicítas y una por defecto. Limitan el ancho de banda: El tráfico SSH (Por ahora tendremos que servirnos de este) a 750kbps; tráfico web a 1 Mbps y el demás tráfico, todo aquello que no hallamos considerado, a 250kbps. Revisemos como es que funciona una configuración de este tipo

Un ping con alta latencia. Veamos que pasa al agregar un poco de tráfico HTTPS

La latencia del ping no cambia tanto como se espera, por otro lado, la descarga web parece ir bastante bien. Al agregar un poco de tráfico FTP, bastante conocido por saber acaparar el ancho de banda, tenemos lo siguiente

El uso de ancho de banda para FTP esta bastante contenido y apenas hizo mella en la descarga HTTP. Por ahora hemos verificado que los límites para el ancho de banda en realidad funciona. Hay un problema al que no pude sacarle captura de pantalla pero que se adivina en la alta latencia del ping: DNS puede llegar a dar timeout en estas condiciones. Esto es por la naturaleza misma del tráfico DNS. La solución a este problema es establecer prioridades para las políticas. Por defecto, todos tienen prioridad 0, así que en realidad lo que se hace es quitarle prioridad a ciertas reglas con la opción prio

...
## Dentro del esquema de HTB, este es llamado LEAF. Este determina la política por defecto 
tc class add dev ens2 parent 1:1 classid 1:10 htb rate 2540 ceil 2540 prio 1
### Creamos los nuevos LEAF que describen dos nuevas políticas para el tráfico. 
tc class add dev ens2 parent 1:1 classid 1:20 htb rate 7680 ceil 7680 prio 0
tc class add dev ens2 parent 1:1 classid 1:22 htb rate 10240 ceil 10240 prio 1
... 

Y marcar el tráfico ICMP de la siguiente forma

...
iptables -t mangle -A POSTROUTING -p icmp -j MARK --set-mark 20
...

Ahora, la tasa de transferencia para HTTP sigue con el mismo rendimiento: Es el tráfico ICMP el beneficiado, es posible ver como la latencia ha bajado considerablemente

En este punto, las políticas garantizan una máxima tasa de transferencia para el tráfico que así lo necesita, y la menor latencia posible para el tráfico que así lo requiera.