IPTVProbe de NetUP

Código fuente: iptvprobe_v0.4.tbz2

Las consultas relativas a IPTVProbe pueden ser hechas en Foro IPTV de NetUP

Cronograma de modificaciones

Versión 0.4
• Depuración periódica de la base de datos.
• Monitoreo múltiple de flujos multicast por sonda.
• Pérdida de memoria en iptvprobe_server solucionada. Nota! La base de datos debe ser recreada completamente cuando se actualiza desde versiones anteriores.

Versión 0.3
• Inclusión de solicitud de procesamiento IGMP y vista de parámetros IGMP temporales
  
• Depuración de código; se solucionan problemas menores.
• Actualización, a una versión nueva, del protocolo de intercambio de información con las sondas.

Versión 0.2
• Inclusión de soporte para Aminet 110 (ppc).

Versión 0.1
• Versión original.
• Inclusión de control de paquetes perdidos.
• Inclusión de vista de velocidad de recepción para paquetes UDP.

Plan de red

Diseño de sonda (iptvprobe) y operación del colector

Construcción e instalación del software

El software contiene los componente siguientes:

• Colector: recoge estadísticas proporcionadas por la sonda. La información recolectada es almacenada en una base de datos (mysql).
• Sonda: es una aplicación que trabaja remotamente. La información estadística sobre recepción de paquetes IP es recogida por la sonda y enviada al colector. La sonda está constituida por un módulo de nivel kernel de Linux (netup_netprobe.ko) y un software de nivel usuario (iptvprobe).
• Subsistema de informes: está conformado por un conjunto de scripts que permiten visualizar las estadísticas recogidas.

Construcción e inicio de colector

Construcción del colector:

cd iptvprobe/userver/
cmake --debug-output . -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
make

Creación de la base de datos:

mysqladmin create iptvprobe
mysql iptvprobe < db.sql

Inicio del colector:

./iptvprobe_server -l root -s 127.0.0.1

En este ejemplo, el colector escribe información estadística en la base de datos 'iptvprobe' del servidor local (127.0.0.1)

Construir iptvprobe

Construcción de la aplicación para la plataforma x86:

cd iptvprobe/udaemon/
cmake --debug-output . -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
make

Construcción del módulo de nivel kernel para plataforma x86:

cd iptvprobe/kmodule/
make

Construcción del módulo de nivel kernel Linux para plataforma sh4 (IP STB AmiNET 130):

cd iptvprobe/kmodule/
export CROSS_COMPILE=sh4-unknown-linux-gnu-
make ARCH=sh amino130

El directorio aminet130_bin/ contiene un módulo de nivel kernel Linux ya construido y una aplicación de nivel usuario para AmiNET 130 IP STB.

Iniciar la sonda

Cargar el módulo de nivel kernel Linux:

cd iptvprobe/kmodule/
insmod netup_netprobe.ko hook_position=0

El parámetro hook_position determina la posición de los paquetes IP de netfilter:

0 - procesar todos los paquetes IP entrantes (directiva PREROUTING) 1 - procesar todos los paquetes IP salientes (directiva POSTROUTING)

El valor "0" debe ser definido cuando se ejecuta el módulo en el dispositivo cliente (por ejemplo: IP STB AmiNET 130). En caso de ejecutar el módulo en un servidor que envía tráfico multicast, el valor debe ser establecido en "1".

Es necesario hacer un nodo en el sistema de archivos /dev e iniciar la aplicación iptvprobe cuando el módulo netup_netprobe.ko se haya cargado exitosamente:

mknod /dev/iptvprobe c 61 0
cd iptvprobe/udaemon/
./iptvprobe -i 224.117.117.10 -s 10.1.4.242 -r 5 -p 7700

Opciones de la línea de comandos:

-i define la dirección multicast para monitoreo
-s define la dirección IP del colector
-p define el puerto por el cual el colector aceptará conexiones desde la sonda
-r define un identificador de proceso

En los subsistemas de informes puede encontrar ejemplos completos de comandos.

Subsistema de informes

A efectos de poder ejecutar el subsistema de informes, es necesario copiar todos los scripts web desde iptvprobe/report_sys/ a la carpeta cgi-bin en su servidor web:

cd iptvprobe/report_sys/
cp *.pl /var/www/localhost/cgi-bin/

tanto perl como GD deben estar instalados en el sistema para una operación eficaz.

Direccione el explorador web hacia la dirección URL siguiente:

http://address/cgi-bin/iptvprobe_runs.pl

donde "address" es la dirección de su servidor web.

La página de inicio contiene la lista de sondas:

La columna "Command to run on probe" muestra comandos completamente constuidos que podrían ser ejecutados en la sonda.

Una representación gráfica de flujo multicast puede ser vista utilizando los enlaces "UDP timeline diagram" o "PCR Arrival Interval". El diagrama muestra, aproximadamente, los últimos 30 segundos.

Dos ejemplos fueron realizados. El primero en AmiNET 130 IP STB, conectado por medio de un switch simple SOHO sin soporte de snooping para IGMP. El segundo fue hecho en AmiNET 130 IP STB, conectado por medio de un switch Catalyst Cisco con snooping de IGMP. En el primer caso se aprecia una cantidad importante de pérdida de paquetes IP. El diagrama siguiente muestra ambos casos:

Explicación del diagrama

El eje de las x muestra, aproximadamente, los últimos 15 a 30 segundos.

Los parámetros siguientes se muestran en el eje de las y:

• Conteo de paquetes IP agrupados en 100 mseg.
• Número de bytes agrupados en 100 mseg.
• La línea roja indica los paquetes IP perdidos. Si se ha detectado discontinuidad en "IP packet ID", se muestra en forma de pico. Un valor igual a "0" significa que no se han detectado pérdidas de paquetes.

Descripción de la base de datos

Monitoreo IGMP

Desde la versión v0.3 de iptvprobe, las solicitudes IGMP enviadas y recibidas por un IP STB pueden ser monitoreadas por la sonda. También se guardan las horas del último grupo de paquetes antes de dejar el grupo y el primer paquete luego de asignarse. Esta información puede ser útil para evaluar el desempeño de un equipamiento de red que procesa solicitudes y snooping para IGMP.

A continuación, puede verse un ejemplo de esta funcionalidad con Aminet 130 IP STB como sonda y NetUP Middleware como colector. Cisco Catalyst 3560 fue utilizado como conmutador para soporte de snooping IGMP y Cisco Catalyst C3550-12T ofició de buscador IGMP.

Los canales de TV fueron cambiados en el IP STB. En ese momento, el STB envió una solicitud IGMP para dejar el grupo multicast 224.121.0.4 y otra para ser incluido en el grupo en 224.121.0.3. Dichas solicitudes son grabadas por la sonda y mostradas en la interfaz web junto con las horas:

Los puntos de interés que queremos destacar está marcados en un recuadro azul. Es claro que luego de la solicitud IGMP para abandonar el grupo multicast en 224.121.0.4, el decodificador STB continuó recibiendo paquetes enviados a ese grupo durante otros 4996.2 ms. El tiempo de demora entre la solicitud IGMP para unirse al grupo 224.121.0.3 y el primer paquete recibido en ese grupo fue de 80 ms. La demora entre las solicitudes IGMP (determinado principalmente por el software STB) fue de 12.0 ms.

En conjunto, el tiempo total del cambio de canal de TV, a nivel de las solicitudes IGMP, fue de 92 milisegundos. La demora real, hasta que el nuevo canal elegido aparece en la pantalla de TV, depende de varios parámetros incluyendo el buffering MPEG, la sincronización de audio y video, etc. y puede llegar a 1 segundo o más.

Además de ello, el STB recibió paquetes de ambos grupos multicast por apenas 5 segundos, con lo cual desperdició ancho de banda extra. Para evitar dicha pérdida, el conmutador debe estar configurado para una salida instantánea. Ello se logra de la manera siguiente:

c3560(config)#ip igmp snooping vlan 1 immediate-leave

Cuando se halla configurado de esta forma, el conmutador detendrá el flujo de información del grupo abandonado en un instante. Los resultados pueden verse en el recuadro rojo. Se puede apreciar que luego de la solicitud de salida "IGMPv2: Leave Group 224.121.0.11" el STB no recibió paquetes para el grupo 224.121.0.11. Por lo tanto, el STB recibe paquetes para un solo canal en todo momento.

Para una grabación correcta de los parámetros temporales de las solicitudes IGMP, la interfase de red debe ser definida en regimen promisc antes de iniciar la sonda en el STB:

# ifconfig eth0 promisc

Tareas pendientes

• Perfeccionamiento del diagrama (escala, valores, etc.)
• Diagrama "PCR jitter", otros diagramas
• Construcciones binarias de sonda para varios tipos de IP STB
• Monitor de disponibilidad de sonda para administración de la red