Este documento lo publiqué a fines del año pasado para que mis compañeros de la maestría en redes tuvieran una herramienta en Software Libre con la cual probar un escenario que nos habían planteado para medir el jitter entre dos puntos de una red congestionada.
Aquí publico la parte técnica de este documento pues me parece útil que otras personas puedan tener acceso a cómo probar el escenario y además usar ZS:
——————————————————–
Bueno, la idea de este laboratorio independiente es la siguiente:
Se necesita priorizar el tráfico de VoIP para evitar o minimizar el jitter.
Ahora consideremos:
1- El detectar el equipo que consume ancho de banda no me parece una buena idea puesto que no será un sólo equipo el que consuma ancho de banda, sino que pueden ser equipos diversos en diversos momentos del tiempo. Ahora es cierto que típicamente lo que sugieren algunas personas es precisamente esto pero no estoy de acuerdo con esta sugerencia.
2- Otra opción sería poner en redes diferentes los equipos que harán VoIP de los que tendrán un tráfico normal de forma tal que controle yo lo que consume cada red. Esto es válido, pero no es el caso que nos ocupa ahora.
3- Cuando hice el trabajo (porque ya lo hice) no nos habían indicado que además había que usar el emulador gns3 que es un gran consumidor de ram y complica por gusto el trabajo y no aporta mucho al hecho de diferenciar en clases el ancho de banda, por tanto en esta explicación no hablaré del gns3 ya que incluso no nos indican todavía cómo configurar frame relay, tema simple pero algunos no conocen.
Por tanto le realicé el laboratorio de la siguiente forma:
Para virtualizar usé KVM pero bien podrían usar VirtualBox
Cada equipo le instalé con 1GB de ram pero una vez le encendí le bajé a 256MB pues como es Linux en modo texto no hace falta tanta RAM. De disco creo que le puse 5GB a cada equipo pero podría ser menos (2 ó 3 GB ) si no vas a instalar modo gráfico.
En KVM creé 5 máquinas virtuales:
1 equipo con Linux ZeroShell (ZS) en el medio.
2 máquinas CentOS a la izquierda de ZeroShell
2 máquinas CentOS a la derecha de ZheroShell, una de ellas será Trixbox.
ZeroShell es una distro que pueden bajar de aquí:
http://www.zeroshell.org
La imagen ISO tiene como 200MB, a algunos de los compañeros del grupo 1 que tuvieron el interés de acercarse ya les copié el ISO. Por demás se puede bajar de este sitio si te interesa probar esto que estoy indicando
A la máquina virtual de zeroshell le creé dos redes LAN:
– una de las LAN le llamé “izquierda” y es donde irán los dos equipos que estarán a la izquierda de ZS
– la otra se llamó “derecha” y como ya habrás adivinado es donde irán los dos equipos de la derecha
En uno de los equipos de la derecha puse trixbox , que es una distro de linux basada en CentOS con todo preparado para actuar de servidor de telefonía y que puede se bajada de http://www.trixbox.org la realidad esta parte me resultó rápida porque en este KVM teníamos un trixbox que usábamos hace unos meses y ahi estaba todavía y ya estaba configurado y demás.
En uno de los equipos de la izquierda instalé CentOS con un paquete del repositorio EPEL llamado SIPP (yum install sipp) que es un sistema que realiza varias y continuas llamadas a un servidor de SIP (el trixbox) y parece ser (esto toca validarlo) que me puede ayudar a medir el jitter de esas llamadas a través de wireshark pues al generar tantas llamadas genera suficiente tráfico para que wireshark pueda realizar mediciones. (ACTUALIZACION: A la final preferimos no usar sipp y usar un softphone como ekiga o twinkle para realizar llamadas a la extension 7777 y que quedara activa por buen tiempo).
En este mismo equipo donde puse sipp también instalé wireshark (yum install wireshark-gnome) y me conecté a él vía SSH con los switches -XYC para poder observar esta aplicación wireshark que es gráfica
Sobre los otros dos equipos: el que sobra a la izq y el que sobra a la der, fueron los generadores de tráfico. En ambos instalé CentOS y dentro de ellos instalé un paquete llamado iperf que está en el repositorio de EPEL.
(Como tema aparte: En realidad instalé un sólo CentOS y luego de instalarle el repo de EPEL le cloné y obtuve estos 3 centos similares en su paquetería. Todo esto gracias a las clases de virtualización que dictamos con Linux)
Sigamos: En el CentOS de la derecha ejecuté entonces: iperf -s que es el iperf listo para actuar como servidor, para recibir tráfico indiscriminado
En el de la izquierda ejecuté: iperf -c ipdel.iperf.dela.derecha lo que me permite generar tráfico de este cliente iperf hacia el anterior iperf que actúa como servidor.
Bueno, esto lo ejecuté tantas veces como me pareció conveniente. Y en realidad pueden estudiar más el iperf ya que este tiene una opción para decirle al cliente de iperf que no envíe solo 10 ó 30 segundos de tráfico sino que se pase enviando tráfico por varios minutos, etc. Así fue como hice en la vida real.
Siempre instalé CentOS-6 en los equipos de la der y de la izq. Y este CentOS pueden bajarlo de: http://centos.mirror.iweb.ca/6/isos/i386/CentOS-6.3-i386-minimal.iso es la variante mínima, para que no se demoren tanto en el proceso de instalación.
De los 5 equipos instalados:
- los 4 Centos van dos conectados a la red de la izq y dos conectados a la red de la derecha (uno es trixbox que es una variante especializada de centos) y todos estos 4 fueron creados con una sóla tarjeta de red cada uno. (ACTUALIZACION: uno de los equipos de la izquierda no fue centos sino debian, pero no altera el cómo se hacen las cosas)
- El equipo ZS es el único que tendrá 2 tarjetas de red, una hacia la red de la izq donde están dos centos y otro hacia la red de la der donde están los otros dos centos.
- ACTUALIZACION: El debian actuó de NAT para que todos los equipos de esta red pudieran navegar a internet e instalar paquetes
Ahora viene lo interesante: Entré al zeroshell, y le configuré como un bridge. A los 4 equipos de ambos lados les puse una IP de la misma red e igual le puse una IP de la red al zeroshell.
Usé un recurso idéntico para ponerles la IP: Supongamos al zeroshell le configuré la IP 100, entonces a los de la izq le puse una IP menor que 100 y a los de la derecha una IP mayor que 100, para saber que si era 101, era un equipo de la derecha del 100 (del ZS) y si era .98 era un equipo con una IP menor que 100 y por tanto a la izquierda del ZS.
Entonces seguí las instrucciones aquí dadas:
http://www.zeroshell.org/qos/
Para catalogar el tráfico y todo funcionó! Lógico que seguir estas instrucciones te tomará un rato pero bueno, esta es la parte importante para la clase, el probar QoS.
Le puse un control de ancho de banda al ZS para que no dejara pasar más de 1 ó 2 mbits entre ambos lados… entonces realicé las siguientes pruebas (se pueden realizar más):
1- puse al sipp twinkle (equipo de la izq) a conectarse al server de trixbox (equipo de la der) a generar llamadas a la extensión 7777 (conexiones) y en efecto todo funcionó de maravillas. Este sistema de sipp podría ser sustituido por un cliente de telefonía sip si el caso lo amerita. Por ejempo ekiga. (ACTUALIZACION: así hice al final)
2- entonces puse a los equipos de iperf a generar tráfico (el cliente iperf a la izq y el servidor a la der) y en efecto en esos momentos el sipp comenzó a reportar pérdidas de llamadas pues el canal estaba saturado, pues recuerda que al ZS le dije que iba a ser un canal de 1 ó 2mbit/s
3- entonces seguí las instrucciones listadas en la última url que te he dado para clasificar y activar el control de tráfico, detectando en una cola todo lo relacionado con voip (rtp, skype, sip, etc), luego poniendo esta cola con más prioridad que el resto del tráfico, etc.. y repetí el paso 2… y el sipp ya no reportó pérdidas en las llamadas!
4- ahi me puse a hacer otros experimentos pues el ZS tiene chorro de cosas, pero esto ya no es tema del laboratorio este.
Consideraciones finales:
Para las personas que conocen Linux (que supongo sean la mayoría pues me dijeron que algunos ya han recibido muy buenas capacitaciones en Linux) este proceso les tomará varias horas en echarlo a andar, quizá un par de días bien dedicados a esto.
De mi parte me tomó como 2 días encontrar una solución que me pareciera adecuada (la de ZS) y varias horas más el preparar y probar el escenario aquí descrito. Hay más soluciones que puedes investigar si deseas, muchas más, tienes todo un mes todavía para investigar y prepararle el laboratorio.
Para los que no conocen Linux: es hora de comenzar a estudiarlo porque el tiempo apremia.
¿Cómo incorporar el gns3 ahi? Realmente no me parece conveniente y, la verdad sea dicha, para ser un experimento me parece ya bastante complejo e interesante. Incorporar el gns3 en mi caso me sería problemático pues ya tendría que dedicar otro hardware al gns3 ya que este es realmente un emulador, que consume recursos, que es lento (hecho en un lenguaje interpretado) y hasta incluso debido a ser un emulador podría falsear las interpretaciones que podríamos hacer de este experimento por su lentitud y consumo de recursos.
Pienso que se va a aprender lo siguiente (con lo hasta ahora dicho):
- A instalar linux, para algunos
- A instalar trixbox, para algunos
- A instalar zeroshell, para casi todos
- A configurar un repositorio para poder instalar sipp, para algunos
- A configurar una extensión en trixbox, para algunos
- A configurar un teléfono sip, para algunos
- a configurar ZS, para casi todos
- A configurar QoS en ZS, para casi todos
- A luego probar todo este escenario, para todos.
