NetUP IPTVProbe

Code source - iptvprobe_v0.4.tbz2

Les questions concernant IPTVProbe peuvent être posées sur le Forum IPTV de NetUP

Chronogramme de modification

Version 0.4
• Nettoyage périodique de la base de données.
• Supervision des multiples flux multicast par sonde.
• Manque de mémoire dans iptvprobe_server résolue.
Note! La base de données doit être complètement recréée lors de la mise à niveau à partir des versions précédentes.

Version 0.3
• traitement de requêtes IGMP et affichage temporel des paramètres IGMP ajouté.
• nettoyage du code, résolution de bugs mineurs.
• Protocole d’échange de données avec les sondes mises à jour vers la nouvelle version.

Version 0.2
• Prise en charge de Aminet 110 (ppc) ajoutée.

Version 0.1
• Version originale.
• Ajout du contrôle des paquets perdus.
• Affichage de la vitesse de réception des paquets UDP ajouté.

Schéma du réseau

Structure de fonctionement de Probe (iptvprobe) et Collector

Construction et Installation du logiciel

Le logiciel est constitué des parties suivantes:

• Collector - collecte les statistiques à partir des sondes. Les statistiques collectées sont stockées dans la base de données (mysql).
• Probe - est une application fonctionnant à distance. Les statistiques sur les paquets IP reçus sont collectées par la sonde et envoyés au collecteur. La sonde est constituée d’un module de noyau Linux (netup_netprobe.ko) et d’un logiciel de niveau utilisateur (iptvprobe).
• Sous-système de rapports - c’est un ensemble de scripts Web pour visualiser les statistiques collectées.

Construction et demarrage de Collector

Construction de Collector:

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

Création de la base de données:

mysqladmin create iptvprobe
mysql iptvprobe < db.sql

Démarrage de Collector:

./iptvprobe_server -l root -s 127.0.0.1

dans cet exemple le Collector écrit les statistiques dans la base de données 'iptvprobe' sur l'hôte local (127.0.0.1)

Construction de iptvprobe

Construction de l’application pour plateforme x86 :

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

Construction du module à noyau Linux pour plateforme x86:

cd iptvprobe/kmodule/
make

Construction du module à noyau Linux pour plateforme sh4 (IP STB AmiNET 130):

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

Le répertoire aminet130_bin/ contient un module noyau Linux déjà construit et une application utilisateur pour AmiNET 130 IP STB.

Démarrage de Probe

Chargemet du module de noyau Linux:

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

Le paramètre hook_position spécifie la position des paquets IP de netfilter:

0 – traite à tous les paquets IP rentrants (PREROUTING policy) 1 – traite tous les paquets IP sortants (POSTROUTING policy)

La valeur "0" doit être définie lors de l’exécution du module sur l’appareil client (par exemple, IP STB AmiNET 130). EN cas d’exécution du module sur un serveur envoyant le trafic multicast, la valeur "1" doit être définie.

C’est nécessaire de faire un noeud dans /dev filesystem et de démarrer l’application iptvpobe lorsque le module netup_netprobe.ko est chargé avec succès:

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

Options de ligne de commande:

-i Définit l'adresse multicast pour supervision
-s Spécifie l’adresse IP du Collector
-p Spécifie le port du Collector pour accepter les connexions des sondes
-r Spécifie un identifiant d’exécution

La commande complètement assemblée peut être trouvée dans le sous-système de rapports.

Sous-système de rapports

Dans le but d’exécuter le sous système de rapports il est nécessaire de copier tous les scripts Web à partir de iptvprobe/report_sys/ vers le dossier cgi-bin de votre serveur Web:

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

perl et GD doivent être installés sur le système pour un fonctionnement correct.

Pointez le navigateur Internet sur l’URL suivante:

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

où "address" est une adresse de votre serveur Web.

La page de démarrage contient la liste des exécutions de sonde:

La colonne "Command to run on probe" contient une commande complètement assemblée qui doit être exécutée sur la sonde.

Le flux de représentation graphique de multicast peut être visualisé en utilisant les liens "diagramme de temps UDP" ou "Intervalle d’arrivée IPCR". Environ les 30 dernières secondes sont affichées dans le daigramme.

Deux exemples d’exécution ont été faits. Le premier a été fait sur AmiNET 130 IP STB connecté via un simple commutateur SOHO sans support de snooping IGMP. Le second a été fait sur AmiNET 130 IP STB connecté via un commutateur Cisco catalyst avec snooping IGMP. Dans le premier cas il y a beaucoup de paquets IP perdus. Les diagrammes suivants visualisent ces deux cas:

Explication du diagramme

Approximativement les 15-30 dernières secondes sont affichées sur l'axe x.

Les paramètres suivants sont affichés sur l’axe y:

• Compte les paquets IP groupés dans 100 msec.
• Nombre d’octets groupés dans 100 msec.
• La ligne rouge indique la perte de paquets IP. Un pic est montré sur le diagramme s'il y a une discontinuité détectée dans "IP packet ID" . La valeur 0 signifie qu’il n’y a pas de paquet perdu.

Description de la base de données

Supervision IGMP

Depuis iptvprobe v0.3, les requêtes IGMP envoyées et reçues par un STB IP peuvent être pistées par la sonde. Les compteurs numériques de référence temporelle(timestamps) du dernier paquet du groupe avant de quitter un groupe et le premier paquet après en avoir rejoint un sont également enregistrés. Ces données peuvent être utilisées pour évaluer la performance de l’équipement réseau qui traite les requêtes IGMP et le snooping IGMP.

Ci-dessous voici un exemple de cette fonctionnalité avec Aminet 130 IP STB pour sonde et Middleware de NetUP pour Collector. Un Cisco Catalyst 3560 a été utilisé comme commutateur avec prise en charge de snooping IGMP, et un Cisco Catalyst C3550-12T a servi de demandeur IGMP.

Les chaînes de TV étaient permutées sur le STB IP. À ce moment le STB envoie une requête IGMP pour quitter le groupe multicast 224.121.0.4 et puis un autre rejoint le groupe sur 224.121.0.3. Ces requêtes sont enregistrées par la sonde et affichées dans l’interface Web avec les compteurs numériques à référence temporelle (timestamps):

Les éléments qui nous intéressent sont dans le cadre bleu. Il est clair qu’après la requête pour quitter IGMP vers le groupe multicast sur 224.121.0.4, le STB a continue à recevoir des paquets envoyés sur le groupe en question pendant d'autres 4996.2 ms. Le délai entre la demande de rejoindre IGMP sur le groupe 224.121.0.3 et la réception du premier paquet pour ce groupe est passé à 80 ms. Le délai entre les requêtes IGMP (principalement determiné par le logiciel du STB) était de 12.0 ms.

Ensemble, la durée totale de permutation de chaîne de TV au niveau des requêtes IGMP est de 92 millisecondes. Le délai réel jusqu’à ce que la nouvelle chaîne sélectionnée apparaisse sur l’écran de TV dépend de beaucoup de paramètres, incluant la mise en tampon MPEG, la synchronisation audio/vidéo, etc., et peut être de 1 seconde ou même plus.

À côté de ça, le STB a reçu les paquets à partir des groupes multicast pendant environ 5 secondes, ainsi gaspillant de la largeur de bande supplémentaire. Pour éviter une telle perte, le commutateur doit être configuré pour quitter instantanément. Ceci est fait par ce qui suit:

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

Une fois configuré de cette manière, le commutateur va commuter le flux de données pour le groupe abandonné en un instant. Les résultats sont affichés dans le cadre rouge. On peut voir qu’après avoir la requête pour quitter "IGMPv2: Leave Group 224.121.0.11" le STB n'a reçu aucun paquet pour le groupe 224.121.0.11. Par conséquent, à tout moment le STB reçoit des paquets d’une seule chaîne uniquement.

Pour l’enregistrement correct des paramètres temporels des requêtes IGMP, l’interface réseau doit être définie sur le régime promisc avant le démarrage de la sonde sonde sur le STB:

# ifconfig eth0 promisc

Liste des choses à faire

• Améliorations du diagramme (évolutif, variable, etc.)
• Diagramme "PCR jitter", autres diagrammes
• Exécutables de Probe pour différents type de STB IP
• Disponibilité du moniteur Probe pour gestion du réseau