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 22Las 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 1599bLa 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
... ## 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
