Montaje NFS desde Emtec Q800

QNAP TS-210

Hace unos días he comprado un NAS, el QNAP TS-210, y por alguna extraña razón, el acceso mediante samba desde mi reproductor multimedia (un Emtec Q800) no iba nada fino. Según las pruebas que he estado haciendo, el acceso Samba desde otros dispositivos al QNAP funciona perfectamente, y el acceso Samba desde el Emtec a otros servidores también funciona correctamente, pero entre ellos no iba nada fino y los problemas eran muy extraños. Los ficheros .avi y las fotos, se reproducían correctamente, pero ni los .mpg ni las imagenes de DVD se reproducían en absoluto, aparecía un “Fatal error” seguido de un “Buffering” y como resultado, no se reproducía nada de nada.

Emtec Q800

Después de darle muchas vueltas al tema de Samba y no encontrar ninguna solución, decidí buscar otro camino para conseguir el mismo resultado. El QNAP exporta contenidos por unos cuantos protocolos, y en concreto me interesé por NFS. El Emtec es un pequeño Linux (BusyBox) que permite acceso por telnet, y me permitía hacer montajes NFS manuales sin mayor complicación. Pero claro, la imagen del sistema está en almacenamiento flash de solo lectura y no permite hacer ningún cambio, hasta que encontré una forma de hacerlo.

En /usr/local/etc hay varios ficheros con permiso de lectura/escritura cuyos cambios son permanentes cuando se apaga el dispositivo. Así que, lo primero que intenté fue añadir el comando para montar el volumen NFS en /usr/local/etc/rcS, de esta forma:

mount -t nfs 192.168.1.137:/share/HDA_DATA/Multimedia /tmp/hdd/volumes/HDD1/nfs

Pero no funcionaba, me aparecía este error:


mount: 192.168.1.137:/share/HDA_DATA/Multimedia failed, reason given by server: Permission denied
mount: nfsmount failed: Bad file descriptor
mount: Mounting 192.168.1.137:/share/HDA_DATA/Multimedia on /tmp/nfs failed: Bad file descriptor

Y problema de permisos de servidor no era, porque el montaje manual funciona correctamente desde esta misma máquina. Comprobé mediante trazas que la red estaba operativa y había conectividad con el servidor antes de ejecutar el comando de montaje, y también que el punto de montaje estaba disponible, pero el error continuaba.

Temía que había algo que todavía no estaba bien montado, o terminado de cargar correctamente y que debía retrasar el montaje del volumen un poco más hasta que la máquina terminara de arrancar. Así que cambié la línea del rcS por esta otra:


/usr/local/etc/mount_nfs.sh &

Y el contenido de ese fichero contiene lo siguiente:


#!/bin/sh
sleep 30
mount -t nfs 192.168.1.137:/share/HDA_DATA/Multimedia /tmp/hdd/volumes/HDD1/nfs -o ro,vers=3

De esta forma, la máquina termina de arrancar y cargar lo que le faltara y el volumen se monta un tiempo después de arrancar.

Problema solucionado!!!

PD: Por cierto, aunque probé a actualizar el firmware del Emtec Q800 hasta la última 906, esta solución solo me ha funcionado con la 751 (tuve que cargar versiones más antiguas) porque el contenido de /usr/local/etc/rcS parece no ejecutarse en las versiones posteriores.

Cluster, alta disponibilidad en Linux

Linux permite la creación de sistemas en cluster formados por al menos dos máquinas, en el que se pueden crear servicios en alta disponibilidad que pueden superar situaciones en las que una de las máquinas sufra un problema de pérdida de servicio. De esta forma, aunque una de las máquinas deje de estar disponible (por fallo hardware o software), el servicio puede continuar estando disponible desde la otra máquina sin que haya apenas corte en el servicio ofrecido, proporcionando alta disponibilidad de aplicaciones.

Para implementar este tipo de soluciones se puede hacer uso de hearbeat, que es un software que permite enviar “pulsos” entre ambos servidores para detectar cuando uno de ellos tiene algún problema, y de esta forma poder mover los servicios configurados al otro nodo. También, por supuesto, se pueden programar diferentes chequeos para mover servicios en caso de que se detecte algún fallo de software, con mon, monit u otro similar.

Por tanto, la idea básica de heartbeat es que se definen uno o varios servicios para los que se desea obtener alta disponibilidad (apache, mysql, …) entre varios servidores en modos activo/pasivo o activo/activo, y heartbeat se encargará de hacer que estos servicios estén siempre ejecutándose mientras uno de los dos nodos esté funcionando correctamente.

Prerrequisitos

Alguno de los prerrequisitos para montar un sistema de clúster con heartbeat son los siguientes:

  • Un interfaz de red para ofrecer el servicio
  • Un interfaz de red para los pulsos heartbeat. Habitualmente un cable cruzado entre ambos servidores
  • Conexión por cable serie cruzado entre servidores, por si hay algún error con la conexión ethernet. Si las máquinas no tienen puerto serie, se puede utilizar un conversor USB-Serie que funcionan sin problema.

Instalación

La instalación es tan sencilla como lo siguiente:

# apt-get install heartbeat

Configuración

Los ficheros de configuración se encuentran en /etc/ha.d. Al menos, hay que configurar tres ficheros. Por un lado, una clave secreta y compartida solamente en estos dos servidores, por ejemplo:


maquinaA-dedi:/etc/ha.d# cat authkeys
auth 2
#1 crc
2 sha1 uhmuHsiK_52,diWJiwLm
#3 md5 Hello!

Por otro lado, el fichero de configuración general de heartbeat (ha.cf). En este fichero se especifican las opciones de configuración generales que establecen los interfaces por los que se envían los pulsos, los ficheros de log, los nodos que forman parte del cluster,… por ejemplo:


debugfile /var/log/ha-debug
logfile /var/log/ha-log
serial /dev/ttyS0 # Linux
bcast eth1 eth2 # Linux
auto_failback off
node maquinaA-dedi.acens.net maquinaB-dedi.acens.net

Y por último, en el fichero haresources se especifican los servicios que forman parte del cluster y que estarán en alta disponibilidad, por ejemplo:


maquinaA-dedi.acens.net IPaddr::X.X.X.X/29/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/shared::ext3 drbdlinks mysql apache2

En el ejemplo anterior, se especifica que uno de los servicios del cluster es IPaddr::X.X.X.X/29/eth0, eso significa que en el nodo activo del cluster se configurará la dirección IP X.X.X.X. Esta es la IP de servicio y es la que se suele asociar a los servicios en alta disponibilidad que se presten en la máquina.

Además de la dirección IP, también se especifica que se va a utilizar el dispositivo drbd r0, que configuramos anteriormente, en el nodo activo, y por tanto será montado automáticamente en el mismo por heartbeat.

Por último, aparecen los servicios drbdlinks, mysql y apache2. Esto significa que cuando un nodo se convierte en primario, se ejecutará lo siguiente de forma automática:


# /etc/init.d/drbdlinks start
# /etc/init.d/mysql start
# /etc/init.d/apache2 start

NOTA: Es importante tener en cuenta que los servicios gestionados por heartbeat (drbdlinks, mysql y apache2 en este ejemplo) deben ser deshabilitados de los niveles de ejecución predeterminados para que no sean arrancados al entrar en ellos, porque será heartbeat el que se encargue de pararlos o arrancarlos cuando corresponda. Para ello, en Debian habría que hacer lo siguiente:


# update-rc.d –f drbdlinks remove
# update-rc.d –f apache2 remove
# update-rc.d –f mysql remove

El servicio drbd si debe estar activo en los niveles de ejecución predeterminados, porque se encarga de cargar el módulo de kernel correspondiente y de disponer los metadispositivos disponibles, pero no de poner activo en el nodo primario, de esto último se encargará heartbeat.

DRBD: RAID1 en red entre varios equipos

DRBD es un software que permite hacer réplica de los datos de una partición entre varias máquinas. Es decir, que si tengo una partición del mismo tamaño en dos máquinas, con DRBD puedo hacer una réplica del contenido de esta partición de forma automática, para que en el caso de que una máquina falle, tenga todo el contenido de esa partición accesible desde la otra máquina. Es como un RAID1, pero entre distintas máquinas.

Habitualmente, esta partición de la que se hace mirror, solamente está montada en una de las máquinas porque se utiliza un sistema de ficheros tradicional: ext3, raiserfs, xfs, … De esta forma, solo una de las máquinas puede acceder a los datos, la que tiene la partición montada. Sirve para montar un sistema de cluster en modo activo/pasivo, y que una de las máquinas tenga todos los datos hasta que falle, y en ese momento se puede acceder desde la otra máquina.

Pero también se puede configurar para que ambas máquinas tengan acceso a la partición en espejo, y en este caso habría que montar un sistema de ficheros para acceso en clúster, como GFS o OCFS. De esta forma podemos montar un clúster activo/activo donde ambas máquinas tienen acceso simultáneo al recurso de datos.

Instalación

Para la versión 0.7 (la que había en Debian Lenny), hay que hacer lo siguiente:

Es necesario instalar las drbd-utils:

# apt-get install drbd0.7-utils

Y el módulo de kernel:

# apt-get install drbd0.7-module-source
# apt-get install dpatch
# cd /usr/src
# tar -zxf drbd0.7.tar.gz
# cd /usr/src/modules/drbd
# module-assistant prepare
# module-assistant automatic-install drbd0.7-module-source
(Navigate the module package creation procedure as logically as
possible; details for this procedure are not provided.)
# cd /usr/src
# dpkg -i drbd0.7-module-2.4.27-2-7_0.7.10-3+2.4.27-8_i386.deb

Configuración

Configurar el propio servicio en ambas máquinas (/etc/drbd.conf), por ejemplo así:

# Definicion recurso
resource r0 {
protocol C;
disk {
on-io-error panic;
}
syncer {
rate 50M; # Note: 'M' is MegaBytes, not MegaBits
}

on maquinaA.dominio.tld {
address 192.168.20.1:7789;
device /dev/drbd0;
disk /dev/sda8;
meta-disk internal;
}
on maquinaB.dominio.tld {
address 192.168.20.2:7789;
device /dev/drbd0;
disk /dev/sda8;
meta-disk internal;
}
}

Después, arrancar el servicio en ambos nodos:

# /etc/init.d/drbd start

Ejecutar lo siguiente en el nodo que queremos que sea el primario:

# drbdsetup /dev/drbd0 primary --do-what-I-say

Y cuando termine lo anterior (solo en el primario):

# drbdadm primary r0
# mkfs.ext3 /dev/drbd0

Después, ya se puede configurar el metadispositivo en el /etc/fstab de ambas máquinas:

/dev/drbd0 /shared ext3 rw,noauto 0 2

Y después, probar a montar la unidad en el primario.

# mount /shared

Cortar un vídeo

Si necesitas cortas un trozo de un vídeo, ya sea un .avi, .mpg o lo que sea puedes usar mencoder. Es tan sencillo como esto:

$ mencoder -of mpeg -ovc copy -oac copy -idx -ss 1000 -endpos 500 -o fichero_destino.mpg fichero_origen.mpg

Es decir, que copia y vídeo y el audio al formato que le especifiques (-of mpeg, avi, rawvideo), empezando en el segundo 1000 (-ss) y copiando los siguientes 500 segundos (-endpos). También reconstruye el índice del fichero destino (-idx).

Bonding ethernet en GNU/Linux

Bonding ethernet se utiliza para combinar varios interfaces de red en uno solo, para ser usados como redundancia o para aumentar el ancho de banda disponible.

Para usar bonding ethernet en linux, lo primero que hay que hacer es tener soporte en el kernel y cargar el módulo correspondiente si no está cargado, por ejemplo:

# modprobe bonding mode=balance-alb miimon=100
# modprobe e100

También hay que tener instalado ifenslave, que en debian es tan sencillo como:

# apt-get install ifenslave

Y después, configurar el interfaz de bonding y añadir los interfaces físicos que necesitemos:

# ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
# ifenslave bond0 eth0
# ifenslave bond0 eth1

Hay que tener en cuenta que al cargar el módulo hemos seleccionado el tipo de bonding, que debe ser uno de los siguientes:

balance-rr
Se reparte el tráfico en modo Robin Round, un paquete para cada interfaz contínuamente
active-backup
Solo un interfaz está activo, y se produce el cambio de activo al otro interfaz cuando el primero falla
balance-xor
Balanceo de carga entre interfaces y tolerancia a fallos, en base a una política de hash
802.3ad
Se balancea la carga entre grupos de interfaces, que son creados en base a sus configuración de velocidad y duplex
balance-tlb
El tráfico de salida se reparte en base a la “carga” de cada interfaz, el tráfico de entrada se recibe en uno de los interfaces
balance-alb
Como el anterior pero también reparte el tráfico de entrada

Al cargar el módulo también se pasa el parámetro miimon, que especifica cada cuantos milisegundos se comprueba el estado de cada uno de los interfaces que pertenece al bonding.

Para comprobar el estado de los interfaces de bonding, se debe mirar los ficheros contenidos en el directorio, por ejemplo:

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: 2.6.1 (October 29, 2004)
Bonding Mode: load balancing (round-robin)
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 1000
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth1
MII Status: up
Link Failure Count: 1

Slave Interface: eth0
MII Status: up
Link Failure Count: 1

WRT54G

Hay muchos dispositivos inalámbricos “económicos” en el mercado, pero personalmente me quedo con este punto de acceso de Linksys, o alguna de sus variantes. El WRT54G, es de Linksys (que pertenece a Cisco) y el cacharro tiene más o menos lo siguiente (depende de la versión)

  • 200Mhz de procesador
  • 4MB de memoria flash
  • 16 MB de RAM
  • 5 interfaces ethernet
  • una tarjeta Wifi 802.11b/802.11g con dos antenas

Lo interesante de este router-wifi es que por defecto trae un firmware con Linux dentro. Aunque por defecto tiene un interfaz web algo limitado, pero para versiones de hardware 4 y anteriores (o versiones WRT54GL) hay muchos
firmwares que se le pueden meter para hacer muchas virguerías, aunque después de probar unas cuantas yo me quedo sin duda con OpenWRT.

Con éste pierdes el interfaz web (aunque se lo puedes poner), tienes lo mínimo necesario, un kernel 2.4.26 y muy pocos paquetes instalados, y después trae un sistema de gestión de paquetes (ipkg) similar a dpkg, con el que puedes instalar todo lo que se te ocurra: dropbear, iptables, tc, asterisk, chillispot, kismet, … En definitiva, tienes un Linux con un hardware limitado, pero que te permite hacer muchísimas cosas.

En breve, publicaré un manual sobre cómo instalar openwrt y hacer un router muy potente con este dispositivo.

Balanceo de carga

Cuando tenemos un router conectado a internet, hay ocasiones en las que no es suficiente con realizar el encaminamiento a través de un solo proveedor de acceso a internet, sino que es necesario realizar un balanceo de carga entre varias líneas de conexión a internet, como por ejemplo dos lí­neas ADSL.

Al balancear la carga entre varias líneas podemos decidir qué parámetro tener en cuenta para realizar ese balanceo: podemos realizarlo en base a las direcciones IP origen, la dirección IP destino, el puerto origen o destino u otros factores. La configuración que se muestra a continuación balancea la carga de forma aleatoria entre los dos accesos a internet en base al peso que se otorgue a cada enlace. Con esto se consigue repartir la carga entre los dos enlaces en base a su disponibilidad de ancho de banda, por ejemplo.

Realizar un balanceador de carga es una tarea que se puede realizar de forma muy sencilla utilizando un router con GNU/Linux siguiendo los siguientes pasos:

Datos previos

Si suponemos los siguientes datos:

eth0: Interfaz conectado a un ADSL
eth1: Interfaz conectado a otro ADSL
IP0: Dirección IP de la máquina en eth0
IP1: Dirección IP de la máquina en eth1
GW0: Dirección IP del gateway en el interfaz eth0
GW1: Dirección IP del gateway en el interfaz eth1
NET0: Subred de la salida ADSL 0
NET1: Subred de la salida ADSL 1

Definir tablas de rutas

Definir dos tablas de routing auxiliares en el fichero /etc/iproute2/rt_tables, simplemente añade estas dos lí­neas:

2 T0
3 T1

Añadir rutas de encaminamiento

Añadir información a las dos tablas auxiliares con información de routing de cada una de las dos salidas:

ip route add default via GW0 dev table T0
ip route add NET0 dev eth0 src IP0 table T0
ip route add default via GW1 dev table T1
ip route add NET1 dev eth1 src IP1 table T1

Añadir las reglas de encaminamiento

Añadir las reglas necesarias para utilizar cada una de las dos tablas auxiliares:

ip rule add from IP0/32 table T0
ip rule add from IP1/32 table T1

Añadir la ruta por defecto

Añadir la ruta por defecto en la tabla principal, que se encarga de repartir la carga. Puedes cambiar el peso de cada enlace después del parámetro weight:

ip route add default scope global nexthop via GW0 dev eth0 weight 1
nexthop via GW1 dev eth1 weight 1

Y esto es básicamente lo que hay que hacer. Aunque recomiendo echar un vistazo a las siguientes direcciones donde lo explican más en detalle:

Howto del LARTC y en especial al apartado que hablan sobre balanceo de carga.

Y como siempre lo mejor es hacer uso de tcpdump y comprobar lo que está pasando por cada interfaz.

Instalación de MobileIP

1. Introducción

En este documento se explica como realizar la instalación de Mobile IP sobre linux. El trabajo se ha realizado sobre 4 PCs con la distribución de linux Debian en version testing, y los PCs tienen kernel 2.4.1.

Para empezar lo primero que hay que hacer es crear dos subredes distintas, y después instalar instalar el software necesario para hacer funcionar Mobile IP.

2. Creación de dos subredes

Lo primero que hay que hacer es crear dos subredes para poder hacer las pruebas con la implementación de Mobile IP de la Helsinki University of Technology. Para ello, uno de los requisitos es que el Home Agent y el Foreign Agent están en distintas subredes.

La estructura de la red elegida es la siguiente:

Esquema de la maqueta

Para ello hay que seguir varios pasos:

* Recompilar los kernels de los PCs con las opciones adecuadas.
* Configurar los interfaces de red.

2.1 Recompilar kernels

La primera etapa a la hora de recompilar el kernel es (si no se tienen ya) instalarse los ficheros fuentes del kernel. Para trabajar con Dynamics (la implementación de la Helsinky University of Technology para Mobile IP) es necesario tener un kernel con versión 2.2.x o superior (la versión actual a fecha de hoy del kernel de linux es la 2.4.3).

Para conseguir instalarte los ficheros fuentes del kernel puedes usar tu forma habitual de instalar paquetes en linux (a partir de la herramienta ”dselect” si tu distribución es Debian, o directamente a partir del fichero .deb también en Debian, o bien del .rpm si usas Red Hat).

El lugar por defecto donde se instalarán los fuentes es ”/usr/src/kernel-2.x.x/” (si estás en Debian). Lo siguiente que hay que hacer es arrancar una de las tres herramientas que te permiten recompilar el kernel. Para ello hay que situarse en el diretorio anteriormente mencionado y ejecutar una de estas tres opciones:

* make menuconfig
* make oldconfig
* make xconfig

Nosotros utilizamos la tercera de las opciones, ”make xconfig”, que usa las X y es más vistosa.

Una vez arrancada la herramienta para recompilar el kernel, se han de seleccionar las siguientes opciones para que funcione correctamente la solución Dynamics de la Helsinky University of Technology para Mobile IP. Las opciones que hay que seleccionar son las siguientes (todas incluidas dentro de la sección Networking options:

* Packet socket (opción CONFIG_PACKET)
* Kernel/User netlink socket (opción CONFIG_NETLINK)
* Routing messages (opción CONFIG_RTNETLINK)
* Socket filtering (opción CONFIG_FILTER, para los MNs; opcional pero recomendado)
* IP: advanced router (opción CONFIG_ADVANCED_ROUTER, para los FAs)
* IP: policy routing (opción CONFIG_IP_MULTIPLE_TABLES, para los FAs)
* IP: tunneling (opción CONFIG_NET_IPIP)

Aunque vienen opciones con el comentario ”para los MNs” o ”para los FAs ” es conveniente marcarlas todas a pesar de que nuestra máquina no vaya hacer la función que se cita.

Con las opciones ya marcadas, sólo queda guardar los cambios y recompilar el kernel:

* make dep
* make clean
* make bzImage
* make modules
* make modules_install

Ya está preparado el kernel para poder funcionar con Dynamics y para que la máquina encargada de hacer de router de las redes encamine los paquetes. Sólo queda actualizar LILO. Para ello hay que hacer una copia de la imagen del kernel recién compilado (bajo ”/usr/src/kernel/2.x.x/arch/i386/boot/bzImage”) dentro del directorio con las imágenes de kernel habitual (normalmente en ”/boot”):

* cp arch/i386/boot/bzImage /boot/vmlinuz-2.x.x

Ahora hay que añadir una nueva entrada en el fichero ”/etc/lilo.conf” con el siguiente texto:


image=/boot/vmlinuz-2.x.x
label=Linux-2.x.x
readonly

Si se han completado todos estos pasos satisfactoriamente, lo único que queda es ejectuar ”lilo” desde un terminal (para que los cambios realizados en ”/etc/lilo.conf” tengan efecto) y reiniciar la máquina. Cuando aparezca LILO escribiremos Linux-2.x.x y ya tendremos nuestro equipo con la configuración adecuada.

2.2 Configurar interfaces de red

El fichero clave a la hora de configurar las interfaces de red es el fichero ”/etc/network/interfaces”. De este fichero coge la información el kernel cuando arranca para configurar las interfaces de red que tenga la máquina.

El fichero de configuración de interfaces para el router de nuestras redes tienen el siguiente aspecto:

# /etc/network/interfaces — configuration file for ifup(8), ifdown(8)

# The loopback interface
# automatically added when upgrading
auto lo
iface lo inet loopback

# The first network card – this entry was created during the Debian installation
# (network, broadcast and gateway are optional)
# automatically added when upgrading
auto eth1
iface eth1 inet static
address 192.168.242.3
netmask 255.255.255.0
network 192.168.242.0
broadcast 192.168.242.255
gateway 192.168.242.3
auto eth0
iface eth0 inet static
address 192.168.240.3
netmask 255.255.255.0
network 192.168.240.0
broadcast 192.168.240.255
gateway 192.168.240.3

Tras configurar la interfaz de loopback, se configuran las dos tarjetas de red que tiene el router, eth0 y eth1 con las direcciones IP 192.18.240.3 y 192.168.242.3 respectivamente.

Otras informaciones relevantes son la máscara de red, la dirección de la red, la dirección de broadcast y el gateway.

Para asegurarse que las interfaces de red están correctamente configuradas se puede usar el comando ”ifconfig” desde un terminal. Si las interfaces están bien configuradas debería mostrarse una información como la que sigue (ejemplo de una máquina con una sola tarjeta de red):

eth0 Link encap:Ethernet HWaddr 00:01:02:29:3E:59
inet addr:192.168.242.3 Bcast:192.168.242.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1617627 errors:0 dropped:0 overruns:0 frame:0
TX packets:80109 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:787664102 (751.1 Mb) TX bytes:23374191 (22.2 Mb)
Interrupt:10 Base address:0xd800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16144 Metric:1
RX packets:269 errors:0 dropped:0 overruns:0 frame:0
TX packets:269 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:14508 (14.1 Kb) TX bytes:14508 (14.1 Kb)

Para activar/desactivar interfaces de red se usa este mismo comando ”ifconfig” con una serie de argumentos. Así, para desactivar la interfaz eth0 se usa:

* ifconfig eth0 down

Si lo que se quiere es levantar un interfaz se ha de usar la siguiente línea (por ejemplo, para levantar la interfaz de la máquina cuya dirección IP es la 192.168.242.1):

* ifconfig eth0 192.168.242.1 up

Con el comando ”netstat -rn” se puede visualizar la tabla de encaminamiento del kernel de una máquina:

debian:# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window
irtt Iface
192.168.242.1 0.0.0.0 255.255.255.0 U 40 0 0
eth0

Para añadir una nueva ruta a esta tabla de encaminamiento se usa el comando ”route” de la siguiente forma:

* route add -net 0.0.0.0 gw 192.168.242.1 dev eth0

Otro aspecto a tener en cuenta en la máquina que hace de router es el contenido del fichero ”/proc/sys/net/ipv4/ip_forward”. Para que el router funcione perfectamente ha de contener un 1, pues por defecto el valor que trae es 0.

Con toda esta información, ya es posible montar dos subredes como las de la figura al comienzo del capítulo y comenzar a probar la implementación Dynamics para Mobile IP de la Helsinky University of Technology.

3. Instalar Mobile IP

Una vez que las dos redes están montadas y funcionan perfectamente ya podemos empezar a instalar el software necesario para hacer funcionar Mobile IP en nuestras subredes.

3.1 Instalación del software

El software utilizado lo puedes encontrar en http://www.cs.hut.fi/Research/Dynamics/software.html. Actualmente está disponible en paquetes .deb, .rpm (hasta versión 0.6.1), pero tuvimos problemas con esta versión que se arreglaron cuando pasamos a la versión 0.6.2, disponible solamente en formato .tar.gz.

La implementación necesita como mí­nimo un kernel 2.2.x, y resumiendo las opciones necesarias son las siguiente:

* Networking options:

Packet socket (CONFIG_PACKET)
Kernel/User netlink socket (CONFIG_NETLINK)
Routing messages (CONFIG_RTNETLINK)
IP: Socket Filtering (CONFIG_FILTER)
IP: tunneling (CONFIG_NET_IPIP)

* Adicionalmente para los Foreign Agents:

IP: Advanced router (CONFIG_IP_ADVANCED_ROUTER)
IP: policy routing (CONFIG_IP_MULTIPLE_TABLES)

* Opción adicional para el MN si se quiere probar con wireless:

Wireless LAN (non-hamradio) (CONFIG_NET_RADIO)

Por lo tanto el primer paso es conseguir esos paquetes y prepararnos para instalarlo en cada uno de los nodos (Mobile Node, Foreign Agent y Home Agent). Descomprimimos los fuentes:

tar xvfz dynamics-0.6.2.tar.gz

Después compilamos e instalamos de la manera tradicional:

* ./configure
* make
* make install

Tenemos que seguir esos pasos en cada uno de los nodos, y ya tendremos instalado el software para trabajar con Mobile IP sobre IPv4.

3.2 Configuración

Lo siguiente que tenemos que hacer es configurar cada uno de los nodos, para que haga la función de MN, HA o FA. Para ello tenemos unos ficheros de configuración bastante bien comentads en /usr/local/etc/ que se llaman:

* /usr/local/etc/dynmnd.conf: Para el Mobile Node.
* /usr/local/etc/dynhad.conf: Para el Home Agent.
* /usr/Local/etc/dynfad.conf: Para el Foreign Agent.

Después de instalar, los ficheros ya tienen por defecto una configuración básica para probar Mobile IP. Esta configuración es la siguiente:

Las direcciones IP son las que se muestran al principio del documento, y el comienzo de la prueba comienza cuando el MN está en la red de “casa”, es decir con el HA.

Al comenzar la ejecución el HA manda mensajes para ver si el MN está en casa, si es así­ el MN se registra en su HA y todo el tráfico del MN va directamente desde y hacia el MN (CN->MN y MN->CN).

Cuando cambiamos al MN de su red y lo llevamos a la red del Foreign Agent, el FA está mandando mensajes a ver si llega el MN, y cuando llega (sin cambiar la dirección IP) se registra en el FA, y entonces el FA establece un tunnel entre el FA y el HA. Desde ese momento todo el tráfico del MN, pasa desde el CN->HA->FA->MN y al revés MN->FA->HA->CN. Este modo se llama FA decapsulation, porque los paquetes llegan “encapsulados” hasta el FA, que es quien los desencapsula y se los entrega al MN.

Los parámetros de configuración más importantes de cada uno de los nodos son los siguientes:

* Home Agent:

# Dirección IP del Home Agent
HAIPAddress 192.168.242.1

# Número máximo de nodos conectados
MaxBindings 20

# Tiempo de vida del tunnel
HADefaultTunnelLifetime 600

# Especifica que manda avisos para localizar al MN
SendAdvertisements TRUE

# Tiempo entre avisos
AdvertisementInterval 1

# Triangle tunneling. Los paquetes van MN->FA->HA->CN y CN->HA->FA->MN
EnableTriangleTunneling TRUE

* Mobile Node:

# Dirección IP del MN
MNHomeIPAddress 192.168.242.2

# Dirección IP del HA
HAIPAddress 192.168.242.1

# FADecapsulation. Los paquetes hacia el MN son desencapsulados por el
# FA. Esto debe ser así­ si la dirección IP del MN no cambia cuando se
# va a la Foreign Network
EnableFADecapsulation TRUE

* Foreign Agent:

# Se especifica el interfaz que utiliza en FA, y el intervalo de
# tiempo entre los mensajes de aviso que manda.
INTERFACES_BEGIN
# interface type agentadv interval force_IP_addr
eth0 1 1 30

# Dirección IP del FA mayor. Esta opción y la siguiente se utiliza
# porque puede haber una estructura de FA en árbol, y solo el HighestFA
# se comunica con el HA
dHighestFAIPAddress 192.168.240.1

# Especifica si este nodo es el HiguestFA, quien se comunica con el HA.
HighestFA TRUE

3.3 Ejecución

Después de configurar los nodos, hay que lanzar los demonios que corren en cada uno de ellos y empezar a hacer pruebas. Para arrancar los demonios:

* MN: dynmnd -fg -debug -no-wireless Con esto conseguimos que se ejecute en ForeGround y en modo debug para poder observar posibles errores, y ver todo el proceso de comunicación entre los nodos. También se indica que no se utiliza wireless.
* HA: dynhad -fg -debug Igual que antes, se ejecuta en foreground y en modo debug.
* FA: dynfad -fg -debug Idem …

Con todos estos pasos se consigue hacer funcionar Mobile IP, pero hay muchas opciones que se pueden variar en los ficheros de configuración para poder hacer pruebas …

4. Experiencia Propia

Bueno, pues a partir de aquí­ vamos a contar un poco cual ha sido nuestra experiencia con este software y cuales han sido los problemillas que hemos ido teniendo.

Nuestras primeras pruebas las hicimos con los ficheros de configuración tal cual vienen con los fuentes, pero esto no nos termino de funcionar. El problema que teniamos era con el parámetro timestamp, definido en el Home Agent, que por defecto venía puesto a 400. Este parámetro comprueba algo así­ como la diferencia horaria entre el HA y FA, hace alguna comprobación de ese tipo por razones de seguridad. Lo que hicimos fue sincronizar los relojes y reducir ese tiempo poniéndolo a 120 y empezá a funcionar más o menos bien.

Después teníamos el problema de que tardaba mucho en empezar a establecerse el tunnel cuando el MN se cambiaba a la Foreign Network. Después de investigar mucho, y al final recurriendo al código fuente, observamos que el tiempo que tardaba en empezar a establecerse el tunel era igual a 3 veces el intervalo de tiempo con el que el HA mandaba mensajes de aviso. Es algo aparentemente sin sentido, pero puede que tenga alguno, hemos mandado un mensaje a los desarrolladores para que nos lo expliquen, pero todavía no nos han contestado. La solución a este problema es reducir el intervalo de tiempo en el que el HA manda los mensajes de aviso al MN, y el tiempo que tarda en empezar a establecerse el tunel también se reduce. Actualmente tenemos puesto este intervalo a 1 segundo. (Este parámetro, que está en el fichero de configuración del HA se llama AdvertisementInterval).