Configuración de red en ILOM

El ILOM es el Integrated Lights Out Manager que existe en las antiguas máquinas de SUN, ahora propiedad de Oracle. Es un pequeño sistema operativo (Linux) integrado en el hardware de Sun/Oracle que te permite configurar/monitorizar el propio hardware independientemente del sistema operativo y del estado en que se encuentre el mismo.

Es decir, que independientemente del sistema operativo que instales en un servidor, tienes un pequeño gestor de recursos que es accesible mediante dos puertos externos:

  • Net Management: Puerto ethernet para acceder a la ILOM
  • Ser Management: Puerto serie para acceder a la ILOM

Puertos de gestión de la ILOM

Mediante uno de estos dos puertos puedes acceder a la ILOM mediante un interfaz serie, SSH, web, … Y gracias a la ILOM podrás hacer algunas de las siguientes tareas:

  • Abrir una consola remota desde un navegador web, para obtener la misma salida que si pincharas un monitor/teclado/ratón
  • Ver el estado del hardware
  • Ver el estado de los leds
  • Arrancar/Parar/Reiniciar el servidor

Hay varios métodos para configurar la red de la ILOM y acceder de forma sencilla de forma remota utilizando el interfaz de Net Management, y esta es una de ellas:

  1. Conectar un cable serie con el adaptador serie/ethernet que viene con el equipo al puerto Ser Management
  2. Conectar el PC mediante un HyperTerminal o similar con la siguiente configuración: 8 bits, sin paridad, 1 bit parada, 9600 baudios, control de flujo deshabilitado
  3. Hacer login en la ILOM: usuario por defecto root y contraseña por defecto changeme
  4. Acceder a la configuración de red:
    cd /SP/network
  5. Establecer los parámetros de red:

    set pendingipaddress=xxx.xxx.xx.xx
    set pendingipnetmask=yyy.yyy.yyy.y
    set pendingipgateway=zzz.zzz.zz.zzz
    set commitpending=true

Después de esto, podrás utilizar un navegador web para conectarte mediante el puerto Net management a la IP que configuraste en el paso anterior:

Interfaz web de la ILOM

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

Montaje de una maqueta de movilidad IP sobre IPv4

1. Introducción

En este documento se explica el montaje de una maqueta construida sobre una serie de PCs, para hacer pruebas sobre varias implementaciones de movilidad en IPV4 y también una implementación de Cellular IP.

La parte fundamental de la maqueta se basa en el siguiente esquema:

Esquema de la maqueta

El objetivo de este esquema es poder tener el mayor número de subredes, con el menor número de ordenadores. Tenemos 5 ordenadores, y también tenemos 5 subredes. Solamente 1 ordenador está conectado directamente a Internet, y hace de ProxyARP para que los demás también puedan acceder.

Las direcciones IP que usamos para las subredes tienen la siguiente estructura: 29 bits para la direccién de red, y 3 bits para la dirección de máquina. Por tanto podemos tener 6 máquinas en cada una de las subredes, lo que es más que suficiente ..

2. Mobile IP sobre la maqueta

La implementación de Mobile IP utilizada para el montaje sobre la maqueta es la de la universidad de Helsinki: http://www.cs.hut.fi/Research/Dynamics/

Para la instalación de Mobile IP sobre la maqueta la configuramos de la siguiente manera:

Configuración de Mobile IP

Tenemos las 5 subredes:

* Subred 1: 193.147.71.40 / 255.255.255.248
* Subred 2: 193.147.71.8 / 255.255.255.248
* Subred 3: 193.147.71.16 / 255.255.255.248
* Subred 4: 193.147.71.24 / 255.255.255.248
* Subred 5: 193.147.71.32 / 255.255.255.248

Tenemos un MN, con dirección 212.128.1.104, tiene una tarjeta wavelan mediante la que se conecta a los Foreign Agents (FA3, FA4 y FA2) que también tienen tarjetas wavelan, y todas ellas están configuradas de modo Ad-Hoc.

El MN se va moviendo por las subredes, y va cambiando de Foreign Agent sin cambiar su dirección IP, ya que usamos FA encapsulation. De este modo los paquetes que van desde el Correspondent Node al MN pasan por el HA, que encapsula los paquetes y se los envía al FA mediante un túnel, y después es el FA el que desencapsula el paquete y se lo entrega al MN.

Con la maqueta que tenemos también hacemos uso de los FA jerárquicos. Esto ocurre entre el FA1 y los FA3 y FA4. Esto proporciona cambios de subred para el MN más rápidos, ya que el túnel que tiene el HA siempre lo tiene con el FA1, y después dependiendo de si el MN está en el FA3 o el FA4, existirá otro tunel entre el FA1 y el FA3, o entre el FA1 y el FA4. Por eso cuando el MN cambia por ejemplo del FA3 al FA4, lo único que cambia es que el túnel entre FA1-FA3 se elimina y se crea otro entre FA1-FA4.

En el caso de no usar FA jerárquicos, como por ejemplo al cambiar del FA3 al FA2, el establecimiento de conexión del MN tiene un mayor retardo, ya que se debe establecer un tunel entre el HA y el FA2 y eso es más lento que el caso que se comentaba antes.

3. Cellular IP sobre la maqueta

La implementación de Cellular IP utilizada es la de la Universidad de Columbia: http://comet.ctr.columbia.edu/cellularip/

La configuración de la maqueta para el uso de Cellular IP es la siguiente:

Uso de Cellular IP

Con Cellular IP, el Mobile Host pertenece a las subredes de los Base Station para poder conectarse a ellos. En este caso el Mobile Host tiene una tarjeta wavelan, y los Base Station también tienen otra cada uno y todas configuradas en modo Ad-Hoc.

Con Cellular IP, en todo momento el Gateway sabe a que Base Station está conectado el Mobile Host, y lo que hace es enrutar los paquetes desde/hacia el MH por el Base Station adecuado en cada momento.

Los cambios de Base Station son más rápidos que los cambios de FA en Mobile IP, ya que aquí­ solo hay que cambiar una ruta en el Gateway-CellularIP y no hace falta establecer túneles ni encapsular paquetes que luego hay que desencapsular.

La solución ideal sería utilizar Cellular IP en las partes inferiores del árbol y Mobile IP para las partes más altas …

4. Herramientas utilizadas para las pruebas de MobileIP

Las pruebas realizadas con Mobile IP sobre la maqueta se han realizado con algunas herramientas existentes para este fin, y otras herramientas implementadas para determinadas pruebas.

Para la automatización de las pruebas se han realizado scripts en perl. En estos script se definen el tipo de pruebas, se lanza el proceso, y se generan algunos ficheros con los resultados.

Básicamente existe un script principal en el que se define el tipo de pruebas, la duración, el número de repeticiones, el programa utilizado para realizar la medición, … Y luego existen tantos scripts como herramientas de medición existen, en el que se indica la forma de ejecutar el programa de medición, y la forma de recoger sus resultados.

Los programas utilizados para las mediciones son netperf, y una implementación de un programa cliente/servidor que básicamente consiste en la medida de los paquetes que se pierden en una transferencia de paquetes entre el cliente/servidor.

5. Pruebas ancho de banda en Mobile IP

Se han realizado una serie de pruebas sobre la maqueta para comprobar el rendimiento de Mobile IP.

Para ello las pruebas realizadas consisten en medir el ancho de banda que se consigue entre el Mobile Node y el Correspondent Node, sobre distintos escenarios.

Para las pruebas se ha utilizado la herramienta netperf. Esta herramienta consisite en un modelo cliente/servidor, ejecutamos el servidor en el CN y el cliente en el MN. Durante el tiempo que dura cada prueba este programa realiza una transferencia entre ambos y mide el ancho de banda que se consigue…

Para la automatización de las pruebas se han construido unos scripts en perl, que realizan todas las pruebas que se le indiquen durante el tiempo que se le indique.

Las pruebas con netperf consisten en medir el ancho de banda conseguido entre ambos nodos, cuando el número de handoffs del MN varí­a. Se han tomado medidas cuando el MN no hace handoffs, y también se han hecho medidas cuando el MN hace unos handoffs de 8, 5, 4, 3 y 2 segundos. Los handoffs consisten en que el MN va cambiando de FA al que se conecta.

También se han hecho pruebas utilizando FA jerárquicos y sin utilizarlos para comprobar cual es la mejora que proporcionan los FA jerárquicos, en el que el túnel entre el HA y el FA superior no varía.

También se ha utilizado el programa nistnet, que sirve para variar el comportamiento de ciertos paquetes en la red. Por ejemplo para nuestras pruebas hemos hecho que el nistnet retrase todos los paquetes desde/hacia el HA 1 segundo, para simular cual sería la situación en la que el HA se encontrara lejos del MN.

Los resultados son los siguientes:

5.1 Resultados con FA jerárquicos

5.1.1 Con TCP

Ancho de banda

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 3.20125 2.9025 3.06625 3.13875 2.8025

Túneles jerárquicos - TCP

Ancho de banda alejando al HA

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 0.8875 0.83 0.7325 0.5875 0.19

Túneles jerárquicos - TCP - HA alejado

5.1.2 Con UDP

Ancho de banda

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.5325 2.56 2.65125 2.665 2.7

Túneles jerárquicos - UDP

Ancho de banda alejando al HA

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 3.23 3.195 3.1825 3.15 2.89

Túneles jerárquicos - UDP - HA alejado

5.2 Resultados sin FA jerárquicos

5.2.1 Con TCP

Ancho de banda

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.40125 2.20125 2.50875 2.65625 2.7675

Túneles no jerárquicos - TCP

Ancho de banda alejando al HA

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 0.1525 0.0575 0.03 0.0275 0.1075

Túneles no jerárquicos - TCP - HA alejado

5.2.2 Con UDP

Ancho de banda

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.595 2.683 2.73625 2.5475 2.5537

Túneles no jerárquicos - UDP

Ancho de banda alejando al HA

Handoffs (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.69 2.455 2.3875 2.4175 2.32

Túneles no jerárquicos - UDP - HA alejado

6. Pruebas pérdida de paquetes UDP en Mobile IP

Otro tipo de pruebas realizado consiste en medir el número de paquetes que se pierden entre el MN y el CN, con diferentes parámetros de configuración de la maqueta.

Para las pruebas de pérdida de paquetes se han realizado unos simples programas en Ada, utilizando la librería de comunicaciones Lower Layer, que consisten en un modelo cliente/servidor en el que se enví­an paquetes UDP de distinto tamaño, y se mide el número de paquetes perdidos.

En las pruebas de pérdidas de paquetes el método es el mismo pero se han realizado con tiempos de handoffs de 15, 12, 10, 8, 6, 5, 4, 3 y 2 segundos.

También se han usado FA jerárquicos y FA no jerárquicos, y también se ha utilizado la herramienta nistnet para alejar al HA.

6.1 Resultados con FA jerárquicos

6.1.1 Con tamaño de paquete de 32 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 0 0 2 2 2 2 4 2 7

Túneles jerárquicos - UDP (32b)

6.1.2 Con tamaño de paquete de 64 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 0 2 2 2 2 0 0 0 3

Túneles jerárquicos - UDP (64b)

6.1.3 Con tamaño de paquete de 512 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 0 0 7 7 5 2 5 7 1

Túneles jerárquicos - UDP (512b)

6.2 Resultados sin FA jerárquicos

6.2.1 Con tamaño de paquete de 32 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 12 16 20 24 29 26 11 3 4

Túneles No jerárquicos - UDP (32b)

6.2.2 Con tamaño de paquete de 64 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 13 16 19 24 29 21 12 2 5

Túneles No jerárquicos - UDP (64b)

6.2.3 Con tamaño de paquete de 512 bytes

Handoffs (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos (%) 14 17 23 26 31 21 25 11 4

Túneles No jerárquicos - UDP (512b)

Referencias

Implementación de Mobile IPv4 por el HUT

Grupo del IETF sobre Mobile IP

Implementación de Mobile IPv6 para Linux

Implementación de Cellular IP

Recursos sobre redes inalámbricas para linux

¿Qué es TCP/IP?

TCP/IP es un conjunto de protocolos en los que se basan la mayorí­a comunicaciones que se realizan hoy en día entre computadores.

El proceso de comunicación entre ordenadores consta de una serie de acciones que se deben realizar para que la comunicación se realice correctamente: división de los datos en paquetes de tamaño pequeño, control de errores, transmisiones físicas, enrutamiento, …

Para que este proceso de comunicación no está formado por un gran proceso complejo que aglutine muchas tareas, lo que se hace es dividir el mismo en procesos más pequeños que se denominan niveles o capas, y cada una de esas capas es la encargada de realizar parte de la funcionalidad del proceso de comunicación.

Las capas del modelo TCP/IP están basadas en el modelo de referencia OSI aunque no son exactamente las mismas. El modelo TCP/IP ha agrupado varias de las capas del modelo OSI y ha definido las capas siguientes:

– Capa de Aplicación (protoclos HTTP, FTP, DNS, …)
– Capa de Transporte (protocolos TCP, UDP)
– Capa de Interred (protocolos IPv4, IPv6)
– Capa de Enlace (protocolos Ethernet, Token Ring, …)

¿Qué es el protocolo IP?

IP es un protocolo del nivel de red (capa 3) del modelo OSI o del nivel de internet (capa 2) del modelo TCP/IP. IP es el protocolo encargado del transporte de paquetes desde el origen hasta el destino en una comunicación. Es un protocolo de mejor esfuerzo, lo que significa que no garantiza la fiabilidad aunque trata de hacer todo lo posible para que los paquetes lleguen al destino.

IP se basa en el encaminamiento que se produce entre dispositivos de la capa 3 (OSI) y en los identificadores únicos (direcciones IP) que asigna a cada dispositivo para que pueda comunicarse. Cada dispositivo de capa 3 realiza el proceso de encaminamiento en base a su tabla de rutas, que le indica el camino mas adecuado para llegar a cada destino.