Control de Trafico y Calidad en el Servicio: Traffic

Control de Trafico y Calidad en el Servicio: Traffic Shaping with Hierarchical
Token Bucket
Sebastián Norberto Mussetta
Norberto Gaspar Cena
Alumnos de la Especialización en Ingeniería en Sistemas de Información
Av. universidad 450 - Villa María – Córdoba.
ngcena@frvm.utn.edu.ar
ABSTRACT
Teniendo en cuenta el crecimiento que las redes han tenido a lo largo y lo ancho del mundo,
cada vez mas, los administradores de red, se ven en la necesidad de poder aplicar filtros
para que el ancho de banda asignado a la red de la organización sea utilizado
correctamente. Recientes estudios de tráfico han determinado que el 46% del tráfico que
circulan por las redes es HTTP, por detrás de este se encuentran los programas P2P con un
sorprendente 37%. Una vez que los administradores de la red de la organización tienen
conocimiento de lo que sucede (mediante un exhaustivo análisis de tráfico), están en la
disyuntiva de decidir que hacer con el tráfico no deseado. Es muy importante que esta
decisión se tome en el seno mas interno de la administración de la empresa, porque es
desde ahí donde se deben definir las políticas de buen uso de la red. Debido a que las
aplicaciones fueron evolucionando y actualmente es posible enviar cualquier tipo de tráfico a
través de cualquier puerto, es necesario identificar el trafico que circula por la red. Una
buena alternativa para hacer esto es haciendo uso de las herramientas que se analizaron en
el trabajo Optimizando el Ancho de Banda: Quality of Service con Filtro de Contenido
en Layer7.
Las políticas de red mas duras indican que una vez identificado ese tráfico, se debe
descartar, por no resultar un contenido necesario para la labor de las personas que integran
la organización. Una política mas accesible indica que se podrá hacer uso de todas esas
aplicaciones siempre que estas no perjudiquen a las aplicaciones necesarias para el
correcto funcionamiento de la empresa. Esto es, identificar las aplicaciones, y asignarles un
ancho de banda mínimo predefinido con anterioridad.
El presente trabajo pretende introducir al lector a la técnica de división de ancho de banda
mediante el uso de algoritmos de jerarquías de grupos. Si existe ancho de banda disponible,
es posible asignarlo a las aplicaciones de tipo p2p. De esta manera el administrador puede
configurar políticas de balance de carga según la aplicación y el ancho de banda disponible
en un momento dado.
1. INTRODUCCION
En la actualidad las redes de alta velocidad sin un control de QoS adecuado pueden
volverse lentas a tal punto que el usuario detecte que las aplicaciones necesarias para su
trabajo diario se tornen imposibles de usar.
Técnicamente aseguramos a los usuarios de la red que las aplicaciones que requieran un
tiempo de latencia bajo o un mayor consumo de ancho de banda, realmente dispongan de
los recursos suficientes cuando lo soliciten. Es por lo mencionado que una de las principales
metas de QoS es la priorización. Esto es, el dar mar relevancia a unas conexiones frente a
otras.
Los beneficios que vamos a encontrar inmediatamente al realizar una implementación de
QoS son los siguientes:
•
Control sobre los recursos: mediante el QoS se podrían limitar las conexiones FTP y
dar mas prioridad a las conexiones a un servidor de base de datos al que acceden
múltiples clientes.
•
Uso mas eficientes de los recursos de la red: esto se logra al poder establecer
prioridades dependiendo del tipo de servicio.
•
Menor latencia: en aplicaciones que requieran de tráfico interactivo, que requieran un
tiempo de respuesta corto.
Es por lo mencionado que en el presente trabajo introduciremos al lector en el concepto de
QoS mediante el uso de disciplinas de colas.
2. CASO PRACTICO
Escenario
A continuación se describe el área de implementación de las políticas de QoS en un
entorno de red Lan con conexión a Internet.
La red de la organización utilizada como ejemplo cuenta con una conexión ADSL de
2048kbps de Downstream y 256kbps de Upstream. Este es el total de ancho de banda que
poseen los ordenadores clientes para poder acceder a los recursos de Internet.
La red esta compuesta por 1 Servidor Debian Lenny GNU/Linux 5.03, y alrededor de
70 equipos de escritorio y unos 10 ordenadores móviles.
La organización debe garantizar un determinado ancho de banda para que los
clientes puedan utilizar servicios Web y de Correo Electrónico. En el caso de quedar ancho
de banda disponible en algún determinado momento, éste debe ser asignado a otro tipo de
servicios, ej. aplicaciones p2p, mensajería, radios online, etc.
Antes de la implantación de esta solución, el MODEM ADSL, era el encargado de
encolar y desencolar los paquetes que iban hacia Internet. La cola utilizada por el módem
era una cola de tipo FIFO (First in first out), esto generaba un grave inconveniente a la hora
de poder utilizar determinados servicios de Internet.
El problema radica en que cuando las aplicaciones de tipo p2p llenaban la cola del
MODEM con paquetes impidiendo que los clientes Web puedan enviar sus Ack. Como
consecuencia los servidores Web tardaban en contestar las solicitudes a causa de las
demoras de envíos de los ack de nuestra red. Finalmente la navegación Web era
extremadamente lenta.
La solución que se plantea en este ejemplo, es realizar el encolado de las
conexiones en el Servidor Linux, priorizando las que son necesarias para el normal
funcionamiento de la organización. De este modo, la cola del MODEM continuará siendo de
tipo FIFO pero a ella arribarán los paquetes de acuerdo a las prioridades que se le asignen
en el servidor GNU/Linux. La figura número 1 muestra en forma de árbol el detalle de
asignación de ancho de banda a las diferentes aplicaciones.
Requisitos
•
Sistema Operativo en el Servidor (Gateway) GNU/Linux Debian Lenny 5.03.
•
Última versión estable de kernel 2.6.32.5 (fecha actual).
•
Paquete Iproute2.
•
Última versión de Iptables. 1.4.5 (fecha acual)
•
Paquete Layer7
Funcionamiento QoS en GNU/Linux
Las diferentes aplicaciones clientes envían los paquetes hacia el la puerta de enlace
que en este caso es el Servidor con Lenny GNU/Linux 5.03. Una vez que el paquete llega al
servidor, es capturado por el kernel del equipo. Luego iptables se encarga de etiquetar el
paquete con alguna marca determinada dependiendo en este caso de la aplicación cliente a
la que pertenezca. En el próximo paso, mediante el uso de disciplinas de colas, los paquetes
se van a ir encolando de acuerdo a las etiquetas que contengan.
Las disciplinas de colas (qdisc) están compuestas por estructuras jerárquicas de
clases formando una arquitectura de árbol. Cada interfaz de red del servidor posee una raíz
de árbol (qdisc raíz) asociada. Cada clase (hoja del árbol) está asociada a las etiquetas que
contienen los paquetes, entonces cuando un paquete es manipulado por iptables, éste es
llevado a una determinada clase. Por otro lado, cada clase tiene asignado un mínimo ancho
de banda garantizado y un excedente que se puede utilizar en el caso que exista mas ancho
de banda disponible. Finalmente cada paquete es enviado a una clase determinada
dependiendo de la etiqueta que contenga y se le asignará el ancho de banda que tenga
predeterminado la clase.
Existen diferentes algoritmos que permiten el funcionamiento de las disciplinas de
colas. En este caso se utilizara HTB (Hierarchical Token Bucket) que permite dividir el ancho
de banda disponible entre un máximo y un mínimo. Se caracteriza por garantizar el mínimo y
alcanzar el máximo en el caso que exista ancho de banda disponible.
Implementación
Distribución de ancho de banda según aplicaciones:
Ancho de banda disponible: 256kbps de Upstream
Servicio
Mínimo
Máximo
Web:
150 kbps
256 kbps
SMTP:
30 kbps
256 kbps
FTP
26 kbps
256 kbps
MSN
18 kbps
256 kbps
P2P
18 kbps
256 kbps
BITORRENT
18 kbps
256 kbps
Estructura de árbol
Figura 1
Configuración mediante reglas
Creación del árbol
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit ceil 256kbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 56kbit ceil 256kbit
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 200kbit ceil 256kbit prio 1
tc class add dev eth0 parent 1:10 classid 1:11 htb rate 18kbit ceil 256kbit prio 6
tc class add dev eth0 parent 1:10 classid 1:12 htb rate 18kbit ceil 256kbit prio 6
tc class add dev eth0 parent 1:10 classid 1:13 htb rate 18kbit ceil 256kbit prio 6
tc class add dev eth0 parent 1:20 classid 2:21 htb rate 150kbit ceil 256kbit prio 1
tc class add dev eth0 parent 1:20 classid 2:22 htb rate 26kbit ceil 256kbit prio 2
tc class add dev eth0 parent 1:20 classid 2:23 htb rate 30kbit ceil 256kbit prio 3
Marcado de paquetes según la aplicación
iptables -t mangle -A FORWARD -o eth1 –m layer7 –l7proto msn-messenger -j MARK --setmark 11
iptables -t mangle -A FORWARD -o eth1 –m layer7 –l7proto edonkey -j MARK --set-mark 12
iptables -t mangle -A FORWARD -o eth1 –m layer7 –l7proto bitorrent -j MARK --set-mark 13
iptables -t mangle -A FORWARD -o eth1 –m layer7 –l7proto http -j MARK --set-mark 21
iptables -t mangle -A FORWARD -o eth1 –m layer7 –l7proto ftp -j MARK --set-mark 22
iptables -t mangle -A FORWARD -o eth1 –m layer7 –l7proto smtp -j MARK --set-mark 23
Asociación de marcas con hojas del árbol
tc filter add dev eth0 protocol ip parent 1: handle 11 fw classid 1:11
tc filter add dev eth0 protocol ip parent 1: handle 12 fw classid 1:12
tc filter add dev eth0 protocol ip parent 1: handle 13 fw classid 1:13
tc filter add dev eth0 protocol ip parent 1: handle 21 fw classid 1:21
tc filter add dev eth0 protocol ip parent 1: handle 22 fw classid 1:22
tc filter add dev eth0 protocol ip parent 1: handle 23 fw classid 1:23
Conclusión
El desarrollo de este trabajo permite implementar políticas de balance de carga
controlando el ancho de banda según la aplicación que lo solicite, garantizando un mínimo a
aplicaciones predefinidas. De esta manera se garantiza que aplicaciones indeseadas no
consuman recursos de ancho de banda en el caso que las aplicaciones con prioridad lo
necesiten.
En el mercado existen alternativas similares pero su implementación es por hardware
(mayor costo). Otras solo contemplan los puertos utilizados sin tener en cuenta qué
aplicación lo este usando resultando ser ineficientes.
Esta solución se implementa por software de código abierto con todos los beneficios
que esto acarrea y los requerimientos de hardware son mínimos. Además se tiene en cuenta
la aplicación en cuestión y no el puerto que esté utilizando.
Bibliografía
Martin Devera aka devik (2009), “HTB Home”, http://luxik.cdi.cz/~devik/qos/htb/
Bert Hubert, Linux Advanced Routing & Traffic Control, http://lartc.org/
Daniel P. Bovet, Marco Cesati (2005), “Understanding the Linux Kernel”, 3° edición, Ed. O’
Reilly
Richard Blum (2008), “Linux Command Line and Shell Scripting Bible”, Ed. Wiley
Steve Hunger (2001), “Debian Gnu-Linux Bible”, Ed. Hungry Minds
Linux Kernel Organization Inc (2008), “The Linux Kernel Archives”, www.kernel.org
Free Software Foundation Inc. (2008), “GNU Operating System”, www.gnu.org
Matthew Strait (2006), Application Layer Packet Classifier for Linux, http://l7filter.sourceforge.net
Kwan Lowe, “Kernel Rebuild Guide” (2004), http://www.digitalhermit.com/linux/Kernel-BuildHOWTO.html
Debian Project (2008), “Debian GNU/Linux”, www.debian.org