Control de Trafico y Calidad en el Servicio: Traffic Shaping with Hierarchical Token Bucket

Transcripción

1 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 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.

2 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.

3 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 Última versión estable de kernel (fecha actual). Paquete Iproute2. Última versión de Iptables (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 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.

4 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

5 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

6 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.

7 Bibliografía Martin Devera aka devik (2009), HTB Home, Bert Hubert, Linux Advanced Routing & Traffic Control, 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, Free Software Foundation Inc. (2008), GNU Operating System, Matthew Strait (2006), Application Layer Packet Classifier for Linux, filter.sourceforge.net Kwan Lowe, Kernel Rebuild Guide (2004), HOWTO.html Debian Project (2008), Debian GNU/Linux,