La mayoría de las redes WiFi operan en el modo infraestructura: consisten en un punto de acceso en algún lugar (con un radio operando en el modo maestro), conectado a una línea DSL u otra red cableada de larga distancia. En un “hot spot” el punto de acceso generalmente actúa como una estación master que distribuye el acceso a Internet a sus clientes, que operan en el modo administrado. Esta topología es similar al servicio GSM de teléfonos móviles. Los teléfonos móviles se conectan a una estación base sin la cual no se pueden comunicar entre sí. Si hace una llamada en broma a un amigo que está del otro lado de la mesa, su teléfono envía los datos a la estación base de su proveedor que puede estar a una milla de distancia. Luego la estación base reenvía los datos al teléfono de su amigo.

Las tarjetas WiFi en el modo administrado tampoco pueden comunicarse directamente. Los clientes –por ejemplo, dos computadoras portátiles en la misma mesa– tienen que usar un punto de acceso como intermediario. Todo el tráfico entre dos clientes conectados a un punto de acceso debe ser enviado dos veces. Si los clientes A y C se comunican, el cliente A envía datos al punto de acceso B, y luego el punto de acceso va a retransmitir los datos al cliente C. Una transmisión puede tener una velocidad de 600 kbyte/seg (que es prácticamente la máxima velocidad que podemos obtener con 802.11b). En nuestro ejemplo, puesto que los datos deben ser repetidos por el punto de acceso antes de que lleguen a su objetivo, la velocidad real entre ambos clientes va a ser de sólo 300 kbyte/seg.

En el modo ad hoc no hay una relación jerárquica entre maestro-cliente. Los nodos pueden comunicarse directamente si están dentro del rango de su interfaz inalámbrica. Por lo tanto, en nuestro ejemplo ambas computadoras podrían conectarse a la velocidad máxima cuando operan en ad hoc bajo circunstancias ideales.

La desventaja del modo ad hoc es que los clientes no repiten el tráfico destinado a otros clientes. En el ejemplo del punto de acceso, si dos clientes A y C no pueden “verse” directamente con su interfaz inalámbrica, todavía se pueden comunicar si el AP está dentro del rango inalámbrico de ambos clientes.

Los nodos ad hoc no repiten datos por omisión, pero pueden hacerlo si se aplica el enrutamiento. Las redes malladas (mesh) están basadas en la estrategia de que cada nodo actúa como un relevo para extender la cobertura de la red inalámbrica. Cuantos más nodos, mejor será la cobertura de radio y rango de la nube mallada. Hay un tema álgido que debe ser mencionado en este punto. Si el dispositivo utiliza solamente una interfaz de radio, el ancho de banda disponible se ve reducido significativamente cada vez que el tráfico es repetido por los nodos intermedios en el camino desde A hasta B. Además, va a haber interferencia en la transmisión de esos nodos compartiendo el mismo canal. Por lo tanto, las económicas redes malladas ad hoc pueden suministrar muy buena cobertura de radio a una red inalámbrica comunitaria a expensas de la velocidad –especialmente si la densidad de los nodos y la potencia de transmisión son elevadas. Si una red ad hoc consiste sólo en unos pocos nodos que están funcionando simultáneamente, si no se mueven y siempre tienen radioenlaces estables –y una larga lista de otras condicionantes– es posible escribir a mano una tabla de enrutamiento individual para todos los nodos.

Desafortunadamente, esas condiciones raramente se encuentran en el mundo real. Los nodos pueden fallar, los dispositivos WiFi pueden cambiar de lugar, y la interferencia puede hacer que los radioenlaces estén inutilizados en cualquier momento. Además nadie quiere actualizar varias tablas de enrutamiento a mano si se adiciona un nodo a la red. Mediante la utilización de protocolos que mantienen automáticamente las tablas de enrutamiento individuales de cada nodo involucrado, podemos olvidarnos de esos temas. Los protocolos de enrutamiento más comunes en el mundo cableado (como el OSPF) no funcionan bien en este ambiente porque no están diseñados para tratar con enlaces perdidos o con topologías que cambian rápidamente.

El Optimized Link State Routing Daemon –olsrd– (Demonio de Enrutamiento de Estado de Enlace) de olsr.org es una aplicación desarrollada para el enrutamiento de redes inalámbricas. Nos vamos a concentrar en este software de enrutamiento por varias razones. Es un proyecto fuente abierta que soporta Mac OS X, Windows 98, 2000, XP, Linux, FreeBSD, OpenBSD y NetBSD. Olsrd está disponible para puntos de acceso que corren Linux como Linksys WRT54G, Asus Wl500g, AccessCube o Pocket PCs que corren Linux Familiar, y viene incluido en los equipos Metrix que corren Metrix Pebble. Olsrd puede manejar interfaces múltiples y puede extenderse con diferentes plug-ins. Soporta IPv6 y está siendo desarrollado y utilizado activamente en redes comunitarias alrededor del mundo.

Existen varias implementaciones para OLSR, que comenzaron como un borrador IETF escrito en el INRIA en Francia. La implementación de olsr.org comenzó como la tesis de máster de Andreas Toennesen en la Universidad UniK. El demonio de enrutamiento se modificó con base en la experiencia práctica de las redes comunitarias gratuitas. El olsrd actual difiere significativamente del borrador original porque incluye un mecanismo denominado Link Quality Extension (Extensión de la Calidad del Enlace) que mide la cantidad de paquetes perdidos entre nodos y calcula las rutas de acuerdo con esta información. Esta extensión rompe la compatibilidad con los demonios de enrutamiento que adhieren al borrador del INRIA. El olsrd disponible en olsr.org puede ser configurado para comportarse de acuerdo al borrador del IETF que carece de esta característica –pero no hay una razón para deshabilitar el Link Quality Extension (Extensión de la Calidad del Enlace), a menos que se requiera la compatibilidad con otras implementaciones.

Después de haber corrido olsrd por un rato, cada nodo adquiere conocimiento acerca de la existencia de los otros nodos en la nube mallada, y sabe cuáles nodos pueden ser utilizados para enrutar el tráfico hacia ellos. Cada nodo mantiene una tabla de enrutamiento que cubre la totalidad de la nube mesh. Este enfoque de enrutamiento mallado es denominado enrutamiento proactivo. En contraste, los algoritmos de enrutamiento reactivo buscan rutas sólo cuando es necesario enviar datos a un nodo específico.

Hay argumentos en favor y en contra del enrutamiento proactivo, y hay muchas otras ideas acerca de cómo hacer el enrutamiento mallado que vale la pena mencionar. La ventaja más grande del enrutamiento proactivo es que sabemos quién está dentro o fuera de la red y no debemos esperar hasta que se encuentre una ruta. El alto tráfico de protocolo y la mayor cantidad de carga de CPU son algunas de las desventajas. En Berlín, la comunidad de Freifunk está operando una nube mallada donde olsrd tiene que administrar más de 100 interfaces. El promedio de carga del CPU causada por olsrd en un Linksys WRT54G corriendo a 200 MHz es aproximadamente del 30% en la mesh de Berlín. Hay un límite al grado hasta el cual la extensión de un protocolo proactivo puede escalar –dependiendo de cuántas interfaces estén involucradas y cuán a menudo se actualizan las tablas de enrutamiento.

Mantener rutas en una nube mallada con nodos estáticos toma menos esfuerzo que hacerlo en una mesh compuesta de nodos que están en constante movimiento, ya que la tabla de enrutamiento no necesita ser actualizada tan a menudo.

Un nodo que corre olsrd envía constantemente mensajes de “Hello” con un intervalo dado para que sus vecinos puedan detectar su presencia. Cada nodo computa una estadística de cuántos “Hellos” ha recibido y perdido desde cada vecino –de esta forma obtiene información sobre la topología y la calidad de enlace de los nodos en el vecindario. La información de topología obtenida es difundida como mensajes de control de topología (TC messages) y reenviada por los vecinos que olsrd ha elegido para ser relevadores “multipunto”.

El concepto de relevadores multipunto es una nueva idea en el enrutamiento proactivo que viene desde el borrador de OLSR. Si cada nodo retransmite la información de topología que ha recibido, se puede generar una sobrecarga innecesaria. Dichas transmisiones son redundantes si un nodo tiene muchos vecinos. Por esta razón, un nodo olsrd decide cuáles vecinos serán designados “relevadores multipunto favorables”, encargados de reenviar los mensajes de control de topología. Nótese que los relevadores multipunto son elegidos exclusivamente con el propósito de reenviar mensajes de CT, la carga útil (payload) se enruta utilizando todos los nodos disponibles. Existen otros dos tipos de mensajes en OLSR que informan cuándo un nodo ofrece una pasarela (gateway) a otras redes (mensajes HNA) o tiene múltiples interfaces (mensajes MID). No hay mucho más que decir acerca de estos mensajes más allá del hecho de que existen. Los mensajes HNA hacen al olsrd muy conveniente para conectarse a Internet con un dispositivo móvil. Cuando un nodo mesh se mueve detectará pasarelas a otras redes y siempre elegirá la pasarela a la que tenga la mejor ruta. No obstante, olsrd no es a prueba de balas. Si un nodo anuncia que es una pasarela a Internet –cuando en realidad no lo es, porque nunca tuvo acceso o lo perdió– los otros nodos van a creer esta información de todas formas. La seudo-pasarela es un agujero negro. Para solucionar este problema se desarrolló una aplicación de pasarela dinámica. La aplicación detecta automáticamente si la pasarela está verdaderamente conectada y si el enlace está activo. Si no es así, olsrd interrumpe el envío de mensajes HNA falsos. Es muy recomendable construir y utilizar esta aplicación en lugar de depender de los mensajes HNA estáticos.

Olsrd implementa enrutamiento IP en una aplicación interna de los usuarios –la instalación es bastante sencilla. Los paquetes de instalación están disponibles para OpenWRT, AccessCube, Mac OSX, Debian GNU/Linux y Windows. OLSR es una parte estándar de Metrix Pebble. Si usted debe compilar desde la fuente, por favor lea la documentación que viene con el paquete. Si todo está configurado correctamente, lo único que tiene que hacer es iniciar el programa OLSR.

En primer lugar debe asegurarse de que cada una de las interfaces del nodo de la mesh tiene asignada una dirección IP estática. No se recomienda (ni es práctico) utilizar DHCP en una red IP mallada. Una solicitud DHCP no va a ser contestada por un servidor DHCP si el nodo que la solicita necesita un enlace de múltiples saltos para alcanzarlo, y aplicar relevo de DHCP (DHCP relay) en toda una malla es poco práctico. El problema podría ser resuelto utilizando IPv6, puesto que se dispone de suficientes direcciones para generar una IP a partir de la dirección MAC para cada tarjeta involucrada (como se sugiere en "IPv6 Stateless Address Autoconfiguration in large mobile ad hoc networks" por K. Weniger y M. Zitterbart, 2002).

Una página-wiki donde todas las personas interesadas pueden elegir una dirección IPv4 para cada interfaz que esté corriendo OLSR daemon puede ayudar al propósito bastante bien. No existe una manera sencilla de automatizar el proceso cuando se utiliza IPv4.

En general, la dirección de difusión en las interfaces mesh debe ser 255.255.255.255, por convención. No hay una razón para ingresar explícitamente la dirección de difusión, ya que olsrd puede ser configurado para reemplazar cualquier dirección de difusión con su valor por convención. Sólo debemos asegurarnos de que las configuraciones son las mismas en todos lados. Olsrd puede hacer esto por sí mismo. Cuando se establece un archivo de configuración olsrd por omisión, esta característica debe ser habilitada para eliminar confusiones del tipo “¿por qué los otros nodos no pueden ver mi máquina?"

Configuremos ahora la interfaz inalámbrica. Aquí hay un comando que ejemplifica como configurar una tarjeta WiFi con el nombre wlan0 utilizando Linux:

iwconfig wlan0 essid olsr.org mode ad-hoc channel 10 rts 250 frag 256

Verifique que la parte inalámbrica de la tarjeta WiFi ha sido configurada de manera que tenga una conexión ad hoc con otros nodos mesh dentro del rango directo (salto único). Asegúrese de que la interfaz usa el mismo canal inalámbrico, el mismo nombre de red inalámbrica ESSID (Extended Service Set IDentifier) y tiene la misma Cell-ID (Identificación de la Célula) que todas las otras tarjetas WiFi que conforman la malla. Muchas tarjetas WiFi o sus respectivos drivers no actúan de acuerdo con el estándar 802.11 para redes ad hoc y por lo tanto no pueden conectarse a una célula. Por otro lado pueden ser incapaces de conectarse con otros dispositivos en la misma tabla, aún si están configurados con el canal y el nombre de la red inalámbrica correctos. Incluso pueden confundir otras tarjetas que se comportan de acuerdo con el estándar creando su propio Cell-ID en el mismo canal y con el mismo nombre de red inalámbrica. Las tarjetas WiFi hechas por Intel que son distribuidas en Notebooks Centrino tienen esta falla.

Para comprobar esto puede utilizar el comando iwconfig cuando utiliza Linux GNU. Aquí están lo resultados de mi computadora:

wlan0   IEEE 802.11b ESSID:"olsr.org"
        Mode:Ad-Hoc Frequency:2.457 GHz Cell: 02:00:81:1E:48:10
        Bit Rate:2 Mb/s Sensitivity=1/3
        Retry min limit:8 RTS thr=250 B Fragment thr=256 B
        Encryption key:off
        Power Management:off
        Link Quality=1/70 Signal level=-92 dBm Noise level=-100 dBm
        Rx invalid nwid:0 Rx invalid crypt:28 Rx invalid frag:0
        Tx excessive retries:98024 Invalid misc:117503 Missed beacon:0

Es importante configurar el valor umbral “RTS” 'Request To Send' para una malla, con el fin de mitigar el efecto de las colisiones entre las transmisiones de los nodos del mismo canal. RTS/CTS establece un procedimiento antes de la transmisión de cada paquete para estar seguro de que el canal está libre. Esto implica una sobrecarga, pero incrementa la prestación en el caso de nodos ocultos –¡y éstos son inherentes a una mesh! Este parámetro establece el tamaño del paquete más pequeño (en bytes) para el cual el nodo envía RTS. El valor umbral de RTS debe ser menor que IP-Packet Size” –Tamaño del paquete IP– y que el ”Fragmentation Threshold” –Umbral de Fragmentación–; en caso contrario estaría deshabilitado. En nuestro ejemplo este valor es de 256 bytes. TCP es muy sensible a las colisiones, por lo tanto es importante habilitar RTS.

La fragmentación permite dividir un paquete IP en una ráfaga de paquetes más pequeños para su transmisión. Si bien implica una sobrecarga, en un medio ambiente ruidoso esto reduce la penalización por los errores y le permite a los paquetes atravesar ráfagas de interferencia. Las redes mesh son muy ruidosas porque los nodos utilizan el mismo canal y por lo tanto las transmisiones están predispuestas a interferir unas con otras. Este parámetro configura el tamaño máximo antes de que un paquete de datos sea dividido y enviado en una ráfaga –un valor igual al tamaño máximo del paquete IP deshabilita el mecanismo, por lo tanto el umbral de fragmentación debe ser menor que el tamaño del paquete IP. Se recomienda utilizar el umbral de fragmentación.

Una vez que se asigna una dirección IP válida y una máscara de red, y que la interfaz inalámbrica está funcionando, el archivo de configuración de olsrd debe ser cambiado para que éste encuentre y utilice las interfaces sobre las cuales debe trabajar.

Para Mac OS-X y Windows se dispone de una buena guía para la configuración y el monitoreo del demonio. Desafortunadamente, esto lleva a que los usuarios que tienen poco conocimiento previo hagan mal las cosas –como permitir agujeros negros. En BSD y Linux el archivo de configuración /etc/olsrd.conf tiene que ser editado con el editor de texto.

No vamos a mostrar un archivo de configuración completo. Aquí hay algunas de las cosas esenciales que deben ser chequedas.

UseHysteresis            no
TcRedundancy             2
MprCoverage              3
LinkQualityLevel         2
LinkQualityWinSize       20

LoadPlugin "olsrd_dyn_gw.so.0.3"
{
       PlParam "Interval" "60"
       PlParam "Ping" "151.1.1.1"
       PlParam "Ping" "194.25.2.129"
}

Interface "ath0" "wlan0" {
       Ip4Broadcast 255.255.255.255
}

Hay muchas más opciones disponibles en el archivo olsrd.conf, pero estas opciones básicas le van a permitir comenzar. Después de realizar estos pasos, olsrd puede ser iniciado con un simple comando en el terminal:

olsrd -d 2

Personalmente, cuando usamos una estación de trabajo recomiendo correrlo con la opción de depuración –d 2, especialmente la primera vez. Podemos ver qué es lo que hace olsrd y monitorear cómo están funcionando los enlaces a sus vecinos. En dispositivos integrados el nivel de depuración debe ser 0 (apagado), porque genera mucha carga en la CPU.

El resultado debe ser algo parecido a esto:

--- 19:27:45.51 --------------------------------------------- DIJKSTRA

192.168.120.1:1.00 (one-hop)
192.168.120.3:1.00 (one-hop)

--- 19:27:45.51 ------------------------------------------------ LINKS

IP address      hyst   LQ     lost   total   NLQ     ETX
192.168.120.1   0.000  1.000  0      20      1.000   1.00
192.168.120.3   0.000  1.000  0      20      1.000   1.00

--- 19:27:45.51 -------------------------------------------- NEIGHBORS

IP address      LQ     NLQ    SYM    MPR     MPRS    will
192.168.120.1   1.000  1.000  YES    NO      YES     3
192.168.120.3   1.000  1.000  YES    NO      YES     6

--- 19:27:45.51 --------------------------------------------- TOPOLOGY

Source IP addr  Dest IP addr     LQ      ILQ      ETX
192.168.120.1   192.168.120.17   1.000   1.000    1.00
192.168.120.3   192.168.120.17   1.000   1.000    1.00

No es necesario tener una interfaz inalámbrica para probar o utilizar olsrd, aunque fue diseñado para éstas. También puede ser utilizado en cualquier NIC. Las interfaces WiFi no tienen que operar siempre en el modo ad hoc para formar una malla cuando los nodos mesh tienen más de una interfaz. Para los enlaces dedicados puede ser una buena opción que corran en el modo de infraestructura. Muchas tarjetas y manejadores (drivers) WiFi tienen problemas en el modo ad hoc, pero el modo de infraestructura trabaja bien –porque todos esperamos que al menos esta característica funcione. El modo ad hoc no ha tenido muchos usuarios hasta ahora, por lo que la implementación del mismo ha sido descuidada por muchos fabricantes. Actualmente, debido al aumento de la popularidad de las redes mesh, se está mejorando esta situación.

Muchas personas utilizan olsrd en interfaces cableadas así como inalámbricas porque no piensan en la arquitectura de red. Simplemente conectan antenas a sus tarjetas WiFi, cables a sus tarjetas Ethernet, habilitan olsrd para que corra en todas las computadoras e interfaces y arrancan. Esto es abusar de un protocolo que fue diseñado para hacer redes inalámbricas en enlaces con pérdidas; pero, ¿por qué no?

Se espera que olsrd sea un superprotocolo. Evidentemente no es necesario enviar mensajes de “Hello” cada dos segundos en una interfaz cableada –pero funciona. Esto no debe ser tomado como una recomendación– simplemente es sorprendente lo que la gente hace con este protocolo y todavía les funciona. De hecho la idea de tener un protocolo que hace todo es muy atractiva para los novatos que quieren tener una LAN enrutada de tamaño pequeño a mediano.

Existen varias aplicaciones para olsrd. Para obtener una lista completa, puede chequear el sitio web olsr.org. Aquí hay unas instrucciones resumidas para la aplicación de visualización de la topología de la red olsrd_dot_draw.

A menudo es muy bueno para la comprensión de una red mallada poder mostrar la topología de la red gráficamente. El olsrd_dot_draw produce la topología en un archivo de formato dot en el puerto TCP 2004. Las herramientas graphviz pueden utilizarse para dibujar los gráficos.

Compile todas las aplicaciones OLSR por separado e instálelas. Para cargarlas agregue las siguientes líneas a /etc/olsrd.conf

LoadPlugin     "olsrd_dot_draw.so.0.3"
{
       PlParam "accept" "192.168.0.5"
       PlParam "port" "2004"
}

El parámetro "accept" especifica el host que fue aceptado para visualizar la Información Topológica (por el momento, uno solo) y es el "localhost" (host local) por omisión. El parámetro "port" especifica el puerto TCP.

Luego reinicie OLSR y chequee si tiene un resultado en el Puerto TCP 2004

telnet localhost 2004

Después de un rato debe aparecer algún texto.

Puede guardar las descripciones gráficas resultantes y correr las herramientas dot o neato del paquete graphviz para obtener imágenes.

Bruno Randolf ha escrito un pequeño programa perl que obtiene continuamente la información topológica desde olsrd y la despliega utilizando las herramientas gráficas graphviz e ImageMagick.

Primero instale los siguientes paquetes en su estación de trabajo:

• graphviz, http://www.graphviz.org/
• ImageMagick, http://www.imagemagick.org/

Descargue el programa en: http://meshcube.org/nylon/utils/olsr-topology-view.pl

Ahora usted puede correr el programa con ./olsr-topology-view.pl y visualizar la topología actualizada casi en tiempo real.

Siempre que las tarjetas WiFi pueden “verse” directamente con sus radios, la herramienta “ping” funcionará sea que olsrd esté corriendo o no. Esto es así porque las máscaras de red grandes efectivamente hacen de cada nodo un enlace local, por lo que los temas de enrutamiento son eludidos en el primer salto. Esto debe ser chequeado en primer lugar, si las cosas no funcionan como se espera. La mayoría de los dolores de cabeza que la gente enfrenta con WiFi en el modo ad hoc son causados por el hecho de que este modo ha sido implementado descuidadamente en los manejadores (drivers) y las tarjetas. Si no es posible hacer ping a los nodos que están en el rango, es probable que sea un problema de las tarjetas o los manejadores, o que la configuración de la red esté mal.

Si cada máquina puede hacer ping a las otras, pero olsrd no encuentra las rutas, entonces deben chequearse las direcciones IP, la máscara de red y la dirección de difusión.

¿Está utilizando un cortafuego? Asegúrese de que no bloquee el puerto UDP 698.

¡Que se divierta!

• Anterior: Redes Internet.
• Siguiente: Estimando la capacidad.
• Volver al índice.