NetUP IPTVProbe

Codice sorgente - iptvprobe_v0.4.tbz2

È possibile discutere le questioni relative a IPTVProbe nel Forum IPTV di NetUP

Log delle modifiche

Versione 0.4
• Pulizia del database su base periodica.
• Monitoraggio multiplo dei flussi multicast per analisi realizzata.
• Ripristino perdita della memoria in iptvprobe_server.
Nota Quando si esegue l'aggiornamento da versioni precendenti, il database deve essere completamente ricreato.

Versione 0.3
• Per il protocollo IGMP è necessaria l'elaborazione e la visualizzazione dei parametri IGMP temporanei aggiunti.
• Pulizia del codice, correzioni dei bug minori.
• Protocollo dello scambio dei dati con i controlli aggiornati alla nuova versione.

Versione 0.2
• Supporto di Aminet 110 (ppc) aggiunto.

Versione 0.1
• Rilascio primario.
• Controllo aggiunto dei pacchetti perduti.
• Visualizzazione aggiunta della velocità di ricezione dei pacchetti UDP.

Schema della rete

Layout delle operazioni di analisi (iptvprobe) e di raccolta

Creazione e installazione del software

Il software è costituito dalle seguenti parti:

• Agente di raccolta - consente di raccogliere le statistiche restituite dalle analisi. Le statistiche raccolte vengono memorizzate nel database (mysql).
• Probe - applicazione che funziona in modalità remota. Le statistiche ricevute nei pacchetti IP vengono raccolte da questa applicazione e inviate all'agente di raccolta. L'applicazione di analisi consiste di un modulo kernel per Linux (netup_netprobe.ko) e di un software a livello utente (iptvprobe).
• Sottosistema dei rapporti - una serie di script Web per la visualizzazione delle statistiche raccolte.

Creazione e avvio dell'agente di raccolta

Creazione dell'agente di raccolta:

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

Creazione del database:

mysqladmin create iptvprobe
mysql iptvprobe < db.sql

Avvio dell'agente di raccolta:

./iptvprobe_server -l root -s 127.0.0.1

In questo esempio l'agente di raccolta scrive le statistiche nel database "iptvprobe" sul localhost (127.0.0.1)

Creazione di iptvprobe

Creazione dell'applicazione per piattaforma x86:

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

Creazione del modulo kernel di Linux per piattaforma x86:

cd iptvprobe/kmodule/
make

Creazione del modulo kernel di Linux per piattaforma sh4 (decodificatore IP AmiNET 130):

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

Nella directory aminet130_bin/ è contenuto un modulo kernel per Linux pre-creato e un'applicazione a livello utente per il decodificatore IP AmiNET 130.

Avvio dell'applicazione Probe

Caricamento del modulo kernel per Linux:

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

Il parametro hook_position specifica la posizione hook dei pacchetti IP di netfilter:

0 - elaborare tutti pacchetti IP in entrata (criterio di PREROUTING) 1 - elaborare tutti pacchetti IP in uscita (criterio di POSTROUTING)

Il valore "0" deve essere impostato quando si esegue il modulo su un dispositivo client (ad esempio, un decodificatore IP AmiNET 130). Nell'eventualità che il modulo venga eseguito su un server che invia traffico nella modalità multicast, deve essere impostato il valore "1".

Creare un nodo nel filesystem /dev e avviare l'applicazione iptvpobe quando il modulo netup_netprobe.ko è stato caricato correttamente:

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

Opzioni della riga di comando:

-i Sets the multicast address for monitoring
-s Specifies the IP address of the collector
-p Specifies the port for the collector to accept connections from probes
-r Specifies a run identifier

L'intero comando può essere trovato nel sottosistema del rapporto.

Sottosistema dei rapporti

Per eseguire il sottosistema dei rapporti, copiare tutti gli script Web contenuti nella cartella iptvprobe/report_sys/ to cgi-bin del server Web:

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

Per un funzionamento corretto, perl e GD devono essere installati nel sistema.

Nella barra degli indirizzi del browser Web, immettere il seguente URL:

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

dove "address" è un indirizzo del server Web dell'utente.

Nella pagina di avvio è contenuto l'elenco delle esecuzioni delle analisi:

Nella colonna "Command to run on probe" (Comando da eseguire in Probe) è contenuto il comando intero che deve essere eseguito nell'applicazione di analisi.

Una rappresentazione grafica del flusso multicast può essere visualizzata mediante i collegamenti "UDP timeline diagram" (diagramma orario UDP) oppure "PCR Arrival Interval" (Intervallo di arrivo PCR). Nel diagramma vengono mostrati gli ultimi 30 secondi circa.

Sono stati realizzati due esempi di esecuzione. Il primo è stato realizzato sul decodificatore IP AmiNET 130 connesso mediante un semplice switch SOHO senza il supporto dello snooping IGMP. Il secondo esempio di esecuzione è stato realizzato sul decodificatore IP AmiNET 130 connesso mediante uno switch Cisco catalyst con snooping IGMP. Nel primo caso si verifica una grande perdita di pacchetti IP. Nei seguenti diagrammi vengono mostrati i due esempi:

Spiegazione del diagramma

Sull'asse delle ascisse (x) sono mostrati gli ultimi 15-30 secondi circa.

I seguenti parametri, invece, sono mostrati sull'asse delle ordinate (y):

• Numero di pacchetti IP raggruppati entro i 100 msec.
• Numero di byte raggruppato entro i 100 msec.
• La linea rossa indica i pacchetti IP perduti. Se in "ID del pacchetto IP" è stata rilevata una discontinuità, nel diagramma viene mostrato un punto massimo. Il valore 0 indica che non è stata rilevata alcuna perdita di pacchetti.

Descrizione del database

Monitoraggio IGMP

Da iptvprobe v0.3, le richieste IGMP inviate e ricevute da un decodificatore IP possono essere tracciate mediante l'analisi. Sono registrati anche i dati relativi alla data e all'ora dell'ultimo pacchetto che ha abbandonato un gruppo e del primo pacchetto che si è appena unito a un gruppo. Tali dati possono essere utilizzati per valutare la prestazione dell'apparato di una rete che elabora le richieste e lo snooping IGMP.

A seguire, viene mostrato un esempio di questa funzionalità con il decodificatore IP Aminet 130 per l'analisi e con NetUP Middleware per l'agente di raccolta. Cisco Catalyst 3560 è stato utilizzato come un commutatore con il supporto di snooping IGMP, mentre Cisco Catalyst C3550-12T ha funzionato come agente di interrogazione IGMP.

I canali TV sono stati accesi mediante il decodificatore IP. A quel punto, il decodificatore invia una richiesta IGMP per abbandonare il gruppo multicast 224.121.0.4, quindi ne invia una seconda per unirsi al gruppo a 224.121.0.3. Queste richieste vengono registrate dall'applicazione di analisi e visualizzate nell'interfaccia Web insieme ai dati relativi alla data e all'ora:

Gli elementi di interesse sono quelli contenuti nel rettangolo blu. Risulta evidente che dopo la richiesta IGMP di abbandono al gruppo multicast a 224.121.0.4, il decodifcatore ha continuato a ricevere pacchetti inviati a tale gruppo per altri 4996,2 ms. Il ritardo di tempo tra la richiesta IGMP di unione al gruppo 224.121.0.3 e il primo pacchetto ricevuto ammonta a 80 ms. Il ritardo tra le richieste IGMP (determinato principalmente dal software del decodificatore) è stato di 12,0 ms.

Complessivamente, il tempo totale di accensione dei canali TV al livello delle richieste IGMP equivale a 92 millisecondi. Il ritardo reale fino al momento dell'apparizione sullo schermo della TV del nuovo canale selezionato dipende da molti parametri come il buffering MPEG, la sincronizzazione audio/video, ecc., e può arrivare fino a 1 secondo o più.

Oltre a ciò, il decodificatore ha ricevuto i pacchetti da entrambi i gruppi multicast per 5 secondi circa, sprecando così ulteriore banda larga. Per evitare una tale perdita, il commutatore deve essere configurato per abbandoni instantanei. È possibile conseguire tale configurazione nel seguente modo:

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

Una volta realizzata questa configurazione, il commutatore spegnerà il flusso di dati del gruppo abbandonato in un istante. I risultati sono mostrati all'interno del rettangolo rosso. Si potrebbe vedere che successiuvamente alla richiesta di abbandono "IGMPv2: Leave Group 224.121.0.11" il decodificatore non abbia ricevuto alcun pacchetto per il gruppo 224.121.0.11. Quindi, a ogni momento dato il decodificatore riceve i pacchetti relativi a un solo canale.

Per la registrazione corretta dei parametri temporanei delle richieste IGMP, l'interfaccia di rete deve essere impostata sul regime promisc prima di avviare l'analisi sul decodificatore:

# ifconfig eth0 promisc

Elenco Da fare

• Miglioramenti del diagramma (scala, differita, ecc.)
• Diagramma "Instabilità PCR", altri diagrammi
• Creazioni binarie di analisi per diversi tipi di decodificatori IP
• Monitor per la disponibilità di analisi per la gestione della rete