NetUP IPTVProbe

./iptvprobe_server -l root -s 127.0.0.1

In diesem Beispiel schreibt der Collector die Statistik in die Datenbank 'iptvprobe' auf localhost (127.0.0.1)

Aufbauen von iptvprobe

Aufbauen der Anwendung für die x86 Plattform:

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

Aufbauen des Linux-Kernelmoduls für die x86 Plattform:

cd iptvprobe/kmodule/
make

Aufbauen des Linux-Kernelmoduls für die sh4 Plattform (IP STB AmiNET 130):

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

Das Verzeichnis aminet130_bin/ enthält ein bereits aufgebautes Linux-Kernelmodul und eine Anwendung auf Benutzerebene für AmiNET 130 IP STB.

Überprüfung starten

Laden des Linux-Kernelmoduls:

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

Der Parameter hook_position legt die Hook-Position der IP-Pakete von Netfilter fest:

0 - alle eingehenden IP-Pakete werden verarbeitet (PREROUTING Regel) 1 - alle ausgehenden IP-Pakete werden verarbeitet (POSTROUTING Regel)

Als Wert muss "0" gesetzt sein, wenn das Modul auf einem Client-Gerät (zum Beispiel IP STB AmiNET 130) ausgeführt wird. Falls das Modul auf einem Server ausgeführt wird, der Multicast-Traffic sendet, muss als Wert "1" gesetzt sein.

Es ist erforderlich, einen Knoten in/dev filesystem zu erzeugen und die Anwendung iptvpobe zu starten, wenn das Modul netup_netprobe.ko erfolgreich geladen ist:

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

Kommandozeilenoptionen:

-i Legt die Multicast-Adresse für die Überwachung fest
-s Gibt die IP-Adresse des Collectors an
-p Gibt den Port für den Collector an, um Verbindungen aus Untersuchungen anzunehmen
-r Gibt eine Laufkennung an

Das vollständig assemblierte Kommando ist im Bericht-Subsystem zu finden.

Bericht-Subsystem

Um das Bericht-Subsystem laufen zu lassen, ist es erforderlich, alle Web-Skripte von iptvprobe/report_sys/ in das cgi-bin Verzeichnis Ihres Webservers zu kopieren:

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

Perl und GD müssen auf dem System installiert sein, damit dies ordnungsgemäß funktioniert.

Verweisen Sie den WWW-Browser auf folgende URL:

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

Wobei "address" eine Adresse Ihres Webservers ist.

Die Startseite enthält die Liste der Probeläufe:

Die Spalte "Command to run on probe" enthält einen vollständig assemblierten Befehl, der bei der Untersuchung ausgeführt werden muss.

Die grafische Darstellung des Multicast-Flows kann mittels der Links "UDP-Zeitliniendiagramm" oder "PCR Arrival Interval" angesehen werden. Im Diagramm werden in etwa die letzten 30 Sekunden angezeigt.

Es werden zwei Probeläufe durchgeführt. Der erste Probelauf erfolgte auf einer IP Set-Top-Box AmiNET 130, die über einen einfachen SOHO-Switch ohne IGMP-Snooping-Unterstützung angeschlossen wurde. Der zweite Lauf erfolgte auf einer IP Set-Top-Box AmiNET 130, die über einen Cisco Catalyst Switch mit IGMP-Snooping angeschlossen wurde. Im ersten Fall gibt es viele IP Paket-Verluste. Die folgenden Diagramme veranschaulichen diese beiden Fälle:

Diagramm-Erklärung

Auf der X-Achse werden in etwa die letzten 15 - 30 Sekunden angezeigt.

Folgende Parameter werden auf der Y-Achse angezeigt:

• Anzahl der IP-Pakete, die innerhalb von 100 ms gruppiert wurden.
• Anzahl der Bytes, die innerhalb von 100 ms gruppiert wurden
• Die rote Linie zeigt verlorene IP Pakete an. Wenn in "IP Paket-ID" Unregelmäßigkeiten entdeckt worden sind, wird ein Spitzenwert im Diagramm angezeigt. Der Wert 0 bedeutet, dass keine Paketverluste entdeckt worden sind.

Datenbankbeschreibung

IGMP-Überwachung

Seit iptvprobe v0.3 können die von einer IP STB gesendeten und empfangenen IGMP-Requests in der Untersuchung verfolgt werden. Die Zeitstempel des letzten Gruppenpakets vor dem Verlassen einer Gruppe und des ersten Pakets nach dem Beitritt zu einer Gruppe werden ebenfalls aufgezeichnet. Diese Daten können genutzt werden, um die Leistungsfähigkeit der Netzwerktechnik zu bewerten, die IGMP-Requests und IGMP-Snooping verarbeitet.

Unten ist ein Beispiel dieser Funktionsvielfalt mit Aminet 130 IP STB als Probe und NetUP Middleware als Collector. Ein Cisco Catalyst 3560 wurde als Kommutator mit IGMP Snooping-Unterstützung genutzt und ein Cisco Catalyst C3550-12T diente als IGMP-Querier.

Auf die IP STB wurden Fernsehkanäle geschaltet. In diesem Moment sendet die STB einen IGMP-Request, um die Multicast-Gruppe 224.121.0.4 zu verlassen und dann einen weiteren Request, um der Gruppe unter 224.121.0.3 beizutreten. Diese Requests werden in der Untersuchung aufgezeichnet und zusammen mit den Zeitstempeln in der Webschnittstelle angezeigt:

Die uns interessierenden Elemente werden von einem blauen Rahmen umspannt. Es ist klar, dass nach dem IGMP-Leave-Request an die Multicast-Gruppe unter 224.121.0.4 die STB damit fortfährt Pakete zu empfangen, die für weiter 4996,2 ms an die vorerwähnte Gruppe gesendet werden. Die Verzögerung zwischen dem IGMP-Join-Request an die 224.121.0.3 Gruppe und dem ersten erhaltenem Paket für diese Gruppe belief sich auf 80 ms. Die Verzögerung zwischen den IGMP-Requests (hauptsächlich bedingt durch die STB-Software) betrug 12,0 ms.

Die Gesamtzeit für das Umschalten eines Fernsehkanals summiert sich auf Ebene der IGMP-Requests auf 92 Millisekunden. Die tatsächliche Verzögerung, bis der neu gewählte Kanal auf dem Fernsehbildschirm erscheint, ist von vielen Parametern, einschließlich MPEG-Pufferung, Audio/Video Synchronisierung usw. abhängig und kann bis zu 1 Sekunde und mehr betragen.

Außerdem hat die STB etwa 5 Sekunden lang Pakete von beiden Multicast-Gruppen erhalten, wodurch zusätzlich Bandbreite vergeudet wird. Um diese Verluste zu vermeiden, muss der Kommutator auf sofortiges Verlassen konfiguriert werden. Dies geschieht wie folgt:

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

Wenn er auf diese Weise konfiguriert wird, schaltet der Kommutator den Datenstrom für die verlassene Gruppe sofort ab. Die Ergebnisse sind im roten Rahmen zu sehen. Nach dem Leave-Request "IGMPv2: Leave Group 224.121.0.11" zeigt sich, dass die STB für die 224.121.0.11 Gruppe keine Pakete empfangen hat. Somit empfängt die STB zum jeweiligen Zeitpunkt nur Pakete von einem Kanal.

Zur korrekten Erfassung der zeitlichen Parameter der IGMP-Requests muss die Netzschnittstelle in den promisc Modus versetzt worden sein, bevor die Untersuchung auf der STB gestartet wird:

# ifconfig eth0 promisc

TODO-Liste

• Diagramm-Optimierungen (Skalierung, Verschiebung, usw.)
• "PCR-Jitter" Diagramm, andere Diagramme
• Untersuchung der Binary Builds für verschiedene IP STB Typen
• Untersuchung des Availability Monitors für das Netzwerkmanagement