pktmirror: software para replicar paquetes

Technorati Tags: , , , , , ,

Para una demo del proyecto NOBEL 2, necesitábamos monitorizar unos paquetes RSVP que llegan de un router GMPLS. Como no tenemos acceso directo a dicho router, establecimos un túnel IP-in-IP (IP encapsulado sobre IP), y de ahí va a un túnel IPSec que nos conecta con el DCN del proyecto. Ambos túneles terminan en un servidor Linux, y el software de monitorización Clearpond corre bajo Windows. La topología en la siguiente figura:

Topología

La solución evidente para poder capturar los paquetes que llegan al servidor es poner un hub que conecte el servidor con una máquina Windows corriendo Clearpond, ¿verdad? Pues no exactamente, porque desde el hub se pueden ver paquetes IP encapsulados sobre IP y paquetes del túnel IPSec (que va cifrado, para más INRI). Y además de cerrado y sólo correr en Windows, el Clearpond sólo entiende paquetes IP normales, nada de paquetes encapsulados.

Por tanto, se nos ponía difícil la cosa. La solución de enchufar el PC con Windows directamente al router GMPLS tampoco servía, porque el túnel termina también en el propio router, por lo que habría que poner alguna máquina adicional más que terminara el túnel, y eso no es factible.

Así que la solución la dió otro compañero de TID (antes del CTTC), Fermín Galán, que nos sugirió utilizar libpcap para capturar los paquetes y reenviarlos al PC con Windows.

¿Y cómo reenviarlos? Evidente: usando sockets. RAW sockets para ser concretos. Pero tenemos un problema. Si ponemos la IP de origen y destino originales del paquete, las reglas de encaminamiento del servidor Linux mandarán el paquete por el túnel correspondiente, en lugar de mandarlo en bruto por la interfaz de red que ve el PC con Windows. Es decir, se vuelven a encapsular en sus túneles respectivos y estamos en las mismas, además de estar enviando los paquetes duplicados.

Otra opción sería enviarlos con las IPs origen y destino del servidor y del PC con Windows, pero existe el problema de que no sabemos si el software de monitorización toma las direcciones IP de la cabecera IP o del payload de RSVP, así que lo mismo eso no funciona.

La solución final: usar RAW Ethernet, y con la ayuda del software eth_send de Avelino Herrera, con algunas modificaciones (por ejemplo que ponga bien el campo tipo de protocolo de Ethernet), conseguí replicar los paquetes y enviarlos al PC con el Clearpond, tal cual los recibiría si no hubiera túneles de ningún tipo y haciendo que funcione a las mil maravillas el sistema de generación de la topología.

El código fuente del software: pktmirror-v0.1.tar.gz. Licenciado GPL v2.

Actualización 12/03/2008: nueva versión de pktmirror que soluciona un ligero memory leak.

Share

Las limitaciones agudizan el ingenio

Cuando uno quiere hacer un testbed de interconexión de varias máquinas y sólo dispone de una, hay que echarle imaginación. Pero si encima se quieren interconectar PCs con routers GMPLS y sólo se dispone de un PC, la cosa es mucho más divertida aún. Veamos cómo se hace para emular el comportamiento del Plano de Control de varios routers interconectados.

Ingredientes:

  • Servidor con Linux
  • Ganas de pegarse con interfaces virtuales y con software que no has escrito

Proceso:

  1. Crear tantas interfaces virtuales como máquinas se quieran interconectar:
    ifconfig eth0:0 10.0.1.1 netmask 255.255.255.0
    ifconfig eth0:1 10.0.2.1 netmask 255.255.255.0
  2. Usar un Proxy de UNI para emular el plano de control de GMPLS
  3. Integrar el software de monitorización, gestión de conexiones y base de datos de conexiones con el Proxy UNI
  4. Cargar una instancia del Proxy UNI por cada máquina del testbed, con sus configuraciones correspondientes
  5. Configurar el demonio de SNMP y escudriñar en la configuración del software de monitorización para que use los interfaces correctos
  6. Sazonar al gusto y disfrutar con la evolución de las conexiones

Ahora sólo falta emular las máquinas que van conectadas a los routers. Pero lo realmente interesante será hacerlo con routers de verdad. Bueno, y también hacer que dejen de aparecer mensajes de error en el gestor de conexiones.

Share

100 GbE y 40 GbE, haya paz

Technorati Tags: , , , ,

Después de algunos meses discutiendo acerca de cuál será el próximo estándar de alta velocidad para Internet, se empieza a ver un acuerdo en el HSSG (Higher Speed Study Group, Grupo de Estudio de Alta Velocidad) del IEEE, que se encarga de los estándares de interfaces de red a velocidades de 10 Gbps en adelante.

El nuevo estándar soportará capacidades de 100 Gbps sobre fibra monomodo (10-40 kilómetros), fibra multimodo (100 metros*) y pares de cobre (10 metros), y de 40 Gbps sobre fibra multimodo (100 metros), pares de cobre (10 metros) o blackplanes (buses de datos, como mínimo 1 metro).

Artículos relacionados:

Ethernet a 100 Gigabits por segundo, 15/11/2006

100 Gigabit Ethernet sobre cables de cobre, 27/3/2007

* corregido, no eran kilómetros, sino metros, gracias Muxfin 🙂

Share