Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)
Hallo liebe Gemeinde!
Kennt wer ein gutes Tool zur Fehlersuche in einem verzweigten Netz in dem Multicast verwendet wird?
Ich glaube das sich ein System sporadisch von der Multicastdomäne abmeldet/ausgeschlossen wird, möchte dies aber gerne genauer analysieren. Das System ist permanent über ping erreichbar, aber beteiligt sich "spontan" nicht mehr an der Multicastdomäne. Glaube das mir hier Wireshark nicht viel helfen kann...
Zweites Anliegen: wäre sehr Dankbar wenn jemand einen Tipp für gute Literatur zu diesem Thema hat
Vielen Dank im Voraus && viele grüße aus Bayern
Flo
Kennt wer ein gutes Tool zur Fehlersuche in einem verzweigten Netz in dem Multicast verwendet wird?
Ich glaube das sich ein System sporadisch von der Multicastdomäne abmeldet/ausgeschlossen wird, möchte dies aber gerne genauer analysieren. Das System ist permanent über ping erreichbar, aber beteiligt sich "spontan" nicht mehr an der Multicastdomäne. Glaube das mir hier Wireshark nicht viel helfen kann...
Zweites Anliegen: wäre sehr Dankbar wenn jemand einen Tipp für gute Literatur zu diesem Thema hat
Vielen Dank im Voraus && viele grüße aus Bayern
Flo
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 362413
Url: https://administrator.de/contentid/362413
Ausgedruckt am: 21.11.2024 um 15:11 Uhr
8 Kommentare
Neuester Kommentar
Mir hat Multicast Hammer sehr geholfen. Literatur suche ich auch noch, möglichst irgendwas deutlich unter 1000 Seiten.
http://multicast-hammer.software.informer.com/2.1/
http://multicast-hammer.software.informer.com/2.1/
Inhaltsverzeichnis
Kennt wer ein gutes Tool zur Fehlersuche in einem verzweigten Netz in dem Multicast verwendet wird?
Das Schweizer Armeemesser der Netzwerker: Wireshark!Speziell zum Testen von Multicasting und Multicast PIM Routing / IGMP Proxy sowie der sehr wichtigen Multicast_zu_Unicast Konvertierung im WLAN bzw. WLAN APs sind 2 freie Tools dafür sehr hilfreich:
- Das oben schon genannte Multicast Hammer Tool
- oder das Netspanner Tool.
Video Streamen via Multicast und GUI
Es geht aber noch viel realitätsnaher und einfacher mit dem allseits bekannten Klassiker VLC wenn man damit Filme oder Audio per Multicast ins Netzwerk streamt:
- Lade dir einen kleinen, freien Film runter wie z.B. Big Buck Bunny --> https://peach.blender.org bzw. https://download.blender.org/peach/bigbuckbunny_movies/ (Die 320x180.mp4 Version reicht für den Test)
- Installiere dir den kostenlosen Klassiker VLC. Der rennt auf allen Plattformen, Windows, MacOS, Linux, Raspberry Pi (apt install vlc), Smartphones, Tablets, usw. --> https://www.videolan.org/vlc/index.de.html
- Starte VLC und streame den o.a. Film als Endlosschleife via Multicast ins Netz. Das geht so:
- Streaming Assistent im VLC aufrufen Medien --> Stream und mit "+ Hinzufügen" Video Datei wie z.B. oben auswählen.
- Dann unten den "Stream" Button klicken und im nächsten Fenster "Nächstes"
- Als Ziel = RTP/MPEG Transportstream auswählen und "Hinzufügen" klicken
- Als Adresse eine Multicast Adresse z.B. 239.255.1.2 angeben. Port belassen und optional einen Namen angeben z.B. "Kinotest". (⚠️ In deinem Netz sollte diese Multicast Adresse natürlich unbenutzt sein und es sollte KEINE sog. Link Local MC Adresse sein mit festem TTL=1 sein !)
- Transkodierung deaktivieren (Haken entfernen) und "Nächstes" klicken
- Wichtig ist hier im Kommando Editor Feld das TTL auf 10 zu setzen. (= damit es dann auch routebar ist !)
- "Fertig" klicken.
- Dann in VLC die ">" Play Taste drücken und den Netzwerk Stream starten. Ggf. noch den Film auf Endlosschleife klicken.
Stream empfangen
So kannst du dann im ganzen Netz mit jedem Endgerät wie PCs, Mac, iPad, Linux, Tablet, iPhone, Smartphone usw. den Film ansehen.
Auch wieder mit VLC als Client indem du "Netzwerkstream öffnen" klickst und als Quelle rtp:@239.255.1.2 eingibst. Ggf. wenn du nicht den Standard Port benutzt, dann den mit einem Doppelpunkt getrennt mit angeben ala rtp:@239.255.1.2:5004
Fertisch !
Streamen via Multicast und Kommandozeile
Multicast Streaming Server mit Linux (Debian, Ubuntu, Raspberry Pi etc.)
Wer einen headless Linux, Raspberry Pi, Linux VM oder ähnlich ohne grafisches GUI betreibt, kann auch ganz einfach über die Kommandozeile per Multicast Filme, wie den von oben, ins Netzwerk streamen. Voraussetzung natürlich VLC ist installiert oder wurde vorher mit sudo apt install vlc (Linux, RasPi) installiert !
Wer zusätzlich noch das Screen Package installiert kann nebenher in einem separaten Terminal im Hintergrund streamen ohne den Stream zu verlieren wenn man sich ausloggt.
Das Kommando sieht dann so aus: (Alles eine Zeile !)
cvlc /home/pi/Videos/BigBuckBunny_320x180.mp4 --sout "#rtp{dst=239.255.1.2,port=5004,ttl=10,mux=ts,sap,name=Bunny}" --no-sout-all --sout-keep --loop
QoS Priorisierung mit DSCP setzen
Eine interessante Option ist den Multicast Stream mit einer DSCP Priorisierung im Layer 3 Header zu versehen. Hier CS3 (24). Wer einen QoS fähigen Switch besitzt kann den Video Traffic so klassifizieren und über den Switch (und auch Router) priorisiert forwarden. Über die Queue Auslastung des Switches kann man so genau beobachten ob sich der Switch entsprechend den DSCP Settings korrekt verhält.cvlc /home/pi/Videos/BigBuckBunny_320x180.mp4 --sout "#rtp{dst=239.255.1.2,port=5004,ttl=10,mux=ts,sap,name=Bunny}" --dscp=96 --no-sout-all --sout-keep --loop
Nebenbei kann man hier nicht nur Dateien per Multicast streamen sondern natürlich auch Videos direkt von Kameras und Video Capture Karten oder Capture USB Sticks ! Letztere streamen dann alles was einen HDMI Output hat.
Das macht in deinem Umfeld sicher mehr Sinn, das so zu testen, denn jeden kleinen Aussetzer im Netz erkennst du im Client sofort als Ruckler oder Blockartefakte im Film.
Multicast Adressierung
Der Multicast Adress Block 239.0.0.0 bis 239.255.255.255 und speziell 239.255.0.0 /16 bzw. 239.192.0.0 /14 ist für die Nutzung in lokalen LANs definiert.
https://www.iana.org/assignments/multicast-addresses/multicast-addresses ...
Und auch RFC 2365.
Wer mehrere Netzwerk Interface Karten am RasPi oder Server hat (wie hier eth1) kann mit dem Parameter --miface=ethX
cvlc /home/pi/Videos/BigBuckBunny_320x180.mp4 --sout "#rtp{dst=239.255.1.2,port=5004,ttl=10,mux=ts,sap,name=Bunny}" --no-sout-all --sout-keep --loop --miface=eth1
Zusätzlich zu guter Multicast Literatur gibt es auch auf z.B. YouTube eine sehr gute Doku / Schulung zum Thema Multicast:
https://www.youtube.com/watch?v=AvbSMBKBZgY
Alle 6 Teile sind sehenswert für MC Anfänger !
Wer ein gutes Buch zum Thema Multicast sucht wird, wie immer zu Netzwerk Themen, bei Cisco Büchern fündig:
https://www.amazon.de/IP-Multicast-Cisco-Networking-Technology/dp/158714 ...
⚠️ Wichtig: IGMP Snooping
Du solltest natürlich tunlichst immer IGMP Snooping auf ALLEN deinen Netzwerk Switches aktiviert haben in einem MC Umfeld !
Andernfalls müsste ein Switch alle diese Multicast Pakete, genau wie Broadcast, an sämtliche Switchports fluten was zu massiven Performance Problemen auf dem Switch, im Netz und Endgeräten führen kann. Ohne aktives IGMP Snooping muss die Switch CPU alle MC Frames kopieren und an aktive Ports forwarden. Weisst du ja aber sicher auch selber.
Wenn man Multicast im WLAN überträgt ist das auch mit Multicast erheblich skalierbarer als zig Einzelstreams. Hier findet man speziell zum Thema Multicast in WLAN Netze noch weitere Detailinfos:
https://www.heise.de/select/ct/archiv/2014/14/seite-76
Ein Beispiel für ein klassisches PIM Routing mit pfSense bzw. OPNsense (PIMD Package) findet man in diesem Thread:
Multicast über VLANs hinweg auf PfSense
Trotzdem kann man ja in diese Netze ein paar Testrechner / Laptops hängen, oder ?
Aber war ja nur ein Beispiel wie es geht. MC Hammer geht auch, obwohl du da ja auch wieder 2 Testrechner ins Netz hängen musst.
Na ja...du hast ja nun genug Test Tools um das zum Fliegen zu bringen ! Mit den Show und Debug Kommandos auf den Switches zusammen sollte das ja nicht so schwer sein.
Achte auch darauf das die Switches bzw. Infrastruktur die aktuellsten Firmwares geflasht haben.
Bei Multicast Funktionen pfuschen Hersteller gerne mal.
Aber war ja nur ein Beispiel wie es geht. MC Hammer geht auch, obwohl du da ja auch wieder 2 Testrechner ins Netz hängen musst.
Na ja...du hast ja nun genug Test Tools um das zum Fliegen zu bringen ! Mit den Show und Debug Kommandos auf den Switches zusammen sollte das ja nicht so schwer sein.
Achte auch darauf das die Switches bzw. Infrastruktur die aktuellsten Firmwares geflasht haben.
Bei Multicast Funktionen pfuschen Hersteller gerne mal.
Im Linux-Bereich finde ich noch empfehlenswert: omping
Die Verwendung ist sehr einfach: auf allen Geräten, die man testen will, laufen lassen:
und man kann direkt sehen, wo Multicast eingeht und wo nicht.
Die beteiligten Adressen müssen angegeben werden. Zusätzlich lassen sich eine bestimmte Multicast-Adresse, Port, TTL etc. festlegen.
Eine weitere Möglichkeit ist iperf (das auf einem Linux-System bereits standardmäßig installiert sein könnte). Hier muss man das Programm auf einem Host als Server starten und auf dem zweiten mit entsprechender Konfiguration als Client. Wird eine Multicast-Adresse angegeben, tritt der Server der Gruppe bei und sollte die Pakete vom Client auf diesem Weg erhalten. Auch hier werden Pings durchgeführt, womit sich die Übertragungsgeschwindigkeit usw. ermitteln lässt.
Server:
Client:
Die Verwendung ist sehr einfach: auf allen Geräten, die man testen will, laufen lassen:
omping 192.168.0.2 10.0.0.20 -m 239.255.255.250 -p 1900 -t 64
und man kann direkt sehen, wo Multicast eingeht und wo nicht.
Die beteiligten Adressen müssen angegeben werden. Zusätzlich lassen sich eine bestimmte Multicast-Adresse, Port, TTL etc. festlegen.
Eine weitere Möglichkeit ist iperf (das auf einem Linux-System bereits standardmäßig installiert sein könnte). Hier muss man das Programm auf einem Host als Server starten und auf dem zweiten mit entsprechender Konfiguration als Client. Wird eine Multicast-Adresse angegeben, tritt der Server der Gruppe bei und sollte die Pakete vom Client auf diesem Weg erhalten. Auch hier werden Pings durchgeführt, womit sich die Übertragungsgeschwindigkeit usw. ermitteln lässt.
Server:
iperf -s -u -B 239.255.255.250 -p 1900 -i 1
Client:
iperf -c 239.255.255.250 -u -p 1900 -T 4 -t 3 -i 1
Danke für den Tip !
Ob nun UDP Port 1900 eine besonders intelligente Wahl ist da das SSDP ist sei mal dahingestellt.
https://www.iana.org/assignments/service-names-port-numbers/service-name ...
Das könnte man auch weglassen und dann den weniger Konflikt beladenen Standard 5201 nutzen.
Ist aber sicher nur kosmetisch..
Ob nun UDP Port 1900 eine besonders intelligente Wahl ist da das SSDP ist sei mal dahingestellt.
https://www.iana.org/assignments/service-names-port-numbers/service-name ...
Das könnte man auch weglassen und dann den weniger Konflikt beladenen Standard 5201 nutzen.
Ist aber sicher nur kosmetisch..