14.01.2024

3363

Multicast über VLANs hinweg auf PfSense

Hallo allerseits,

ich habe hier Verständnis-Probleme bei Multicast-Kommunikation über VLAN-Grenzen hinweg.

Gegeben ist ein SMA-Homemanager (192.168.10.143, VLAN10), der auf 239.12.255.254 seine Zählerstände verschickt. Diese Daten kommen allerdings nur im eigenen VLAN (10) an.

Erster Gedanke: IGMP aktivieren. Das findet man bei pfsense unter "Services/IGMP-Proxy". Die Beschreibung des IGMP-Proxies habe ich nun mindestens 10 mal gelesen, ohne daraus wirklich schlau zu werden:

Man kann/muss mehrere Proxy-Instanzen anlegen
Je Instanz kann/muss man ein interface (soweit klar) und eine oder mehrere CIDR (das wären wohl die multicast-Adressen?) angeben
Es können mehrere downstream-Instanzen (also interfaces, wo sich multicast-Clients befinden) definiert werden.
Es kann aber nur GENAU EIN upstream-Interface (also multicast-server) definiert werden.

Das würde doch bedeuten, dass nur in einem einzigen VLAN multicast-server existieren können, weil man ja kein zweites upstream-interface eintragen kann?

Das macht doch keinen Sinn?

Kann jemand diesen Widerspruch auflösen? Wo genau bin ich falsch abgebogen?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 4823726230

Url: https://administrator.de/forum/multicast-ueber-vlans-hinweg-auf-pfsense-4823726230.html

Ausgedruckt am: 22.12.2024 um 05:12 Uhr

33 Kommentare

Neuester Kommentar

dass nur in einem einzigen VLAN multicast-server existieren können

Nein, das wäre eine falsche Schlussfolgerung! Richtig ist das es nur ein Segment (Interface) geben kann indem sich Multicast Server befinden können von denen es dort aber durchaus mehrere geben kann.
Bedenke das du hier nur einen Proxy hast und eben kein transparentes Multicast Routing mit PIM. Siehe dazu auch hier.
Bei einem Web Proxy z.B. ist das ja auch nicht anders! Proxying ist kein Routing.

Du kannst das Proxy und das PIM Routing Verhalten bei Multicast auch recht einfach lokal testen wie u.a. in diesem Tutorial beschrieben.

Vielen Dank erst mal für die Antwort!

dass nur in einem einzigen VLAN multicast-server existieren können

Hmmm... Da werde ich jetzt nicht wirklich schlau draus. Worauf konkret bezieht sich dieses "nur ein" genau? In der oben verlinkten Beschreibung steht "instance". Das würde ich so interpretieren, dass nur eine Zeile auf der IGMP-Konfiguration mit uplink existieren darf. Oder ist damit die Kombination von Interface und CIDR-Adressereichen gemeint, so dass für einen CIDR-Adressbereich nur ein uplink-Eintrag existieren darf?

Bedenke das du hier nur einen Proxy hast und eben kein transparentes Multicast Routing mit PIM. Siehe dazu auch hier.

Danke für den Link. Werde das mal intensiver durchkauen.

Du kannst das Proxy und das PIM Routing Verhalten bei Multicast auch recht einfach lokal testen wie u.a. in diesem Tutorial beschrieben.

Hmm... Ich glaube Teil des Problems ist, dass der SMA-Homemanager seine Daten mit TTL=1 versendet. Das kann man dem Gerät auch nicht anders konfigurieren, AFAIK. Gibt es eine Möglichkeit mit IGMP-Proxy und/oder PIMD die Pakete trotz TTL=1 weiterzureichen?

Das ist dann identisch zu z.B. mDNS was auch eine Link Local Multicast Gruppe mit einer TTL von 1 nutzt. Mit dem Proxy ist das aber übertragbar da der, wie schon gesagt, nicht routet. Siehe dazu auch:
Apple AirPrint über VLANs

Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?

Gelöst ist das leider noch nicht. Versuche noch verzweifelt, die Puzzleteile zusammezubekommen.

Für den Anfang will ich es erst einmal mit nur einem Server auf die Reihe kriegen (stelle also die Frage nach einer zweiten Upstream-Instanz erst einmal zurück)

Zunächst zum TTL=1: das wäre doch nur für link-local korrekt? Aber 239.12.255.254 ist doch eine "Organization-local"-Adresse? Darf der da überhaupt TTL=1 verwenden?

Und aus der Beschreibung des Proxies werde ich immer noch nicht schlau.

Ich lege also eine Upstream-Instanz an mit:

interface=vlan10
threshold=0 (in der Hoffnung, dass dann TTL=1 durchgeht)
networks=239.12.255.254/32 (nur dieser Host darf multicast aus diesem Netz senden)

dann lege ich eine downstream-Instanz an mit:

interface=vlan20
threshold=0
networks=192.168.20.0/24 (darf nicht leer bleiben, warum?)

Weiterhin habe ich eine firewall-rule auf vlan10 (also wo der multicast-server sitzt) die IPv4/UDP von 192.168.10.23 (Multicast-source) auf 239.12.255.254 duchlässt mit "Allow IP options" angeklickt.

Das sollte doch gehen? Was fehlt hier denn noch?

Was ich noch vergessen habe zu erwähnen:

eine firewall-rule, die von vlan20 (also client-Seite) alle IPv4 IGMP mit "Allow IP options" angeklickt.

Im Packet-Capture der pfsense kann ich auch die igmp-Anforderungen des Client sehen

Im Log des IGMP-Proxy kann ich aber keine zugehörigen Registrierungen in der route-table sehen. Da sehe ich rein gar nichts von vlan20 (also der client-Seite)

Aber 239.12.255.254 ist doch eine "Organization-local"-Adresse? Darf der da überhaupt TTL=1 verwenden?

Das TTL Setting ist kein Protokollzwang bzw. nur bei Link Local Multicast. "Darf" ist also sicher der falsche Ausdruck. Es könnte, wäre dann aber unsinnig. Solche Frames haben auch nie eine TTL von 1.
Threshold auf 0 zu setzen ist natürlich fatal. Erstmal ist dieser Wert im TCP/IP gar nicht definiert, also per se schon falsch. Das Feld sollte leer bleiben, damit der Proxy alles annimmt. Bei 0 würde er alles abweisen. ("Packets with a TTL lower than the value in this field will be ignored")

Auch deine VLAN10 Rule ist recht fatal, da IGMP Join Messages usw. weitere funktionale Multicast Adressen nutzen die du damit allesamt aussperrst. Multicasting kann damit nicht funktionieren.
Sieh dir mit dem Wireshark in dem oben beschriebenen MC Testdesign einmal die Kommunikation an, dann wirst du sehen das dort weit mehr Gruppenadressen benutzt werden! Dein Filter ist nicht korrekt und Wireshark immer dein bester Freund und etwas Multicast Training (https://www.youtube.com/watch?v=AvbSMBKBZgY) kann sich nicht schaden!

Normalerweise geht man auch so bei einer Firewall niemals vor und stellt sich vorab selber eine Falle. Strategisch erlaubt man im Testbetrieb erstmal alles um die (MC) Funktion an sich zu verifizieren und erstellt danach das Regelwerk, weil man so sicher weiss das Fehler dann einzig nur am Regelwerk liegen können. Du bist also in deine eigene Falle getappt.

Vielen Dank für die ausführliche Antwort!

Beim Lesen dachte ich schon: "ja, das wars!". Aber irgendwo ist da noch ein Haken...

Zitat von @aqui:

Aber 239.12.255.254 ist doch eine "Organization-local"-Adresse? Darf der da überhaupt TTL=1 verwenden?

Threshold auf 0 zu setzen ist natürlich fatal. Erstmal ist dieser Wert im TCP/IP gar nicht definiert, also per se schon falsch.

Der Threshold wird ja nicht in irgend ein Paket gesteckt, sondern ist lediglich ein Konfigurations-Wert mit dem der Proxy den TTL aus dem Paket vergleicht um zu entscheiden ob das Paket verarbeitet werden soll.

Das Feld sollte leer bleiben, damit der Proxy alles annimmt.

Leeres Feld wird al 1 gewertet. Macht aber keinen Unterschied: es geht weder mit 0 noch mit 1 noch mit leer.

Bei 0 würde er alles abweisen. ("Packets with a TTL lower than the value in this field will be ignored")

Hmmm... Kein TTL kann kleiner sein als 0, insofern müsste er alle Pakete akzeptieren.

Aber wie oben geschrieben, macht es keinen Unterschied

Auch deine VLAN10 Rule ist recht fatal, da IGMP Join Messages usw. weitere funktionale Multicast Adressen nutzen die du damit allesamt aussperrst. Multicasting kann damit nicht funktionieren.

Hmmm. Also ich habe jetzt:

Rules auf vlan10:

Pass IP-Option IPv4 IGMP dest:224.0.0.0/4 # Jeglichen Mulicast-Traffic durchlassen
Pass IP-Option IPv4 UDP src:192.168.10.23 dest:239.12.255.0/24 # MCast-Server

Rules auf vlan20:

Pass IP-Option IPv4 IGMP # Jeden IGMP-Traffic durchlassen

Die Scheunentore sind damit vermutlich grösser als die Feuermauer...

Und dann noch IGMP-Proxy:

vlan10 upstream 239.12.255.0/24
vlan20 downstream 239.12.255.0/24, 192.168.20.0/24

Sieh dir mit dem Wireshark in dem oben beschriebenen MC Testdesign einmal die Kommunikation an,

Tue ich doch, wie Du an meinem vorigen Beitrag sehen kannst.

Dein Filter ist nicht korrekt

Obiges steht doch schon auf "alles durchlassen". Was fehlt da noch?

etwas Multicast Training (https://www.youtube.com/watch?v=AvbSMBKBZgY) kann sich nicht schaden!

Da bin ich schon mehrfach durch.

Normalerweise geht man auch so bei einer Firewall niemals vor und stellt sich vorab selber eine Falle.

Hmmm... Ich kenne es eigentlich anders herum: erst mal alles zumachen und dann gezielt Löchlein bohren bei dem das nicht funktioniert.

Ich kenne es eigentlich anders herum: erst mal alles zumachen und dann gezielt Löchlein bohren bei dem das nicht funktioniert.

Ja, das ist per se auch nicht falsch aber wenn man nicht weiss was passiert macht man erstmal alles auf.

Hast du dir das mit dem Wireshark mal angeschaut wie der Join Prozess abläuft einmal direkt und einmal über den Proxy? Wo hakt es da?
Ich setze das parallel auch mal auf und sehe mir das an.

Hier erstmal der output von

tcpdump -v -n -i eth0  \( host 192.168.10.23  \) and \( ip multicast \) | \
perl -ne '  
   chomp;
   s/, (id|length) \d+//g;
   s/\.\d+( > 255.255.255.255.20560)/.xxxxx $1/;
   if (s/^[\d.:]+ (.*)//) {
      print "$line\n" if defined $line;  
      $line=$1;
   } else {
      $line.=" $_";  
  }' | \  
sort|uniq -c

wenn server und client auf demselben vlan sind (etwas händisch nachbearbeitet um Lesbarkeit zu erhöhen):

  13 IP (tos 0x0, ttl 1, offset 0, flags [DF], proto IGMP (2), options (RA))
          192.168.10.23 > 224.0.0.1: igmp query v3

  13 IP (tos 0xc0, ttl 1, offset 0, flags [DF], proto IGMP (2), options (RA))
          192.168.10.23 > 224.0.0.22: igmp v3 report, 7 group record(s)
            [gaddr 239.12.0.174    is_ex, 0 source(s)]
            [gaddr 239.12.1.116    is_ex, 0 source(s)]
            [gaddr 239.12.255.253  is_ex, 0 source(s)]
            [gaddr 239.12.255.254  is_ex, 0 source(s)]
            [gaddr 224.0.0.251     is_ex, 0 source(s)]
            [gaddr 239.170.0.1     is_ex, 0 source(s)]
            [gaddr 239.255.255.250 is_ex, 0 source(s)]

1637 IP (tos 0x0, ttl 1,   offset 0, flags [DF], proto UDP (17))   192.168.10.23.36814 > 239.12.255.254.9522
  53 IP (tos 0x0, ttl 1,   offset 0, flags [DF], proto UDP (17))   192.168.10.23.9522  > 239.12.255.255.9522
  28 IP (tos 0x0, ttl 64,  offset 0, flags [DF], proto UDP (17))   192.168.10.23.xxxxx > 255.255.255.255.20560
  26 IP (tos 0x0, ttl 2,   offset 0, flags [DF], proto UDP (17))   192.168.10.23.52339 > 239.255.255.250.1900


   9 IP (tos 0x0, ttl 255, offset 0, flags [DF], proto UDP (17))   192.168.10.23.5353  > 224.0.0.251.5353: 0 [2q] SRV (QM)? SEMPSHIPGW._ship._tcp.local. A (QM)? SMAxxxx.local. (65)
   9 IP (tos 0x0, ttl 255, offset 0, flags [DF], proto UDP (17))   192.168.10.23.5353  > 224.0.0.251.5353: 0*- [0q] 2/0/0 SMAxxxx.local. (Cache flush) A 192.168.10.23, SEMPSHIPGW._ship._tcp.local. (Cache flush) SRV SMAxxxx.local.:4712 0 0 (89)
   8 IP (tos 0x0, ttl 255, offset 0, flags [DF], proto UDP (17))   192.168.10.23.5353  > 224.0.0.251.5353: 0*- [0q] 2/0/0 SEMPSHIPGW._ship._tcp.local. (Cache flush) SRV SMAxxxx.local.:4712 0 0, SMAxxxx.local. (Cache flush) A 192.168.10.23 (89)
   7 IP (tos 0x0, ttl 255, offset 0, flags [DF], proto UDP (17))   192.168.10.23.5353  > 224.0.0.251.5353: 0 [2q] A (QM)? SMAxxxx.local. SRV (QM)? SEMPSHIPGW._ship._tcp.local. (65)
   1 IP (tos 0x0, ttl 255, offset 0, flags [DF], proto UDP (17))   192.168.10.23.5353  > 224.0.0.251.5353: 0 SRV (QM)? SEMPSHIPGW._ship._tcp.local. (45)
   1 IP (tos 0x0, ttl 255, offset 0, flags [DF], proto UDP (17))   192.168.10.23.5353  > 224.0.0.251.5353: 0 [2q] PTR (QM)? _ship._tcp.local. TXT (QM)? SEMPSHIPGW._ship._tcp.local. (51)
   1 IP (tos 0x0, ttl 255, offset 0, flags [DF], proto UDP (17))   192.168.10.23.5353  > 224.0.0.251.5353: 0 [1a] PTR (QM)? _http._tcp.local. (67)
   1 IP (tos 0x0, ttl 255, offset 0, flags [DF], proto UDP (17))   192.168.10.23.5353  > 224.0.0.251.5353: 0*- [0q] 4/0/0 SEMPSHIPGW._ship._tcp.local. (Cache flush) TXT "model=Sunny Home Manager 2.0" "type=Energy Manager" "brand=SMA" "ski=...0eff2d98..." "register=false" "path=/ship/" "id=SEMPSHIPGW" "txtvers=1", _ship._tcp.local. PTR SEMPSHIPGW._ship._tcp.local., SEMPSHIPGW._ship._tcp.local. (Cache flush) SRV SMAxxxx.local.:4712 0 0, SMAxxxx.local. (Cache flush) A 192.168.10.23 (270)  
   1 IP (tos 0x0, ttl 255, offset 0, flags [DF], proto UDP (17))   192.168.10.23.5353  > 224.0.0.251.5353: 0*- [0q] 4/0/0 _http._tcp.local. PTR Website on SMAxxxx._http._tcp.local., Website on SMAxxxx._http._tcp.local. (Cache flush) TXT "path=/legal_notices.txt", Website on SMAxxxx._http._tcp.local. (Cache flush) SRV SMAxxxx.local.:80 0 0, SMAxxxx.local. (Cache flush) A 192.168.10.23 (153)  

Wie kann ich die

    [gaddr 239.12.0.174    is_ex, 0 source(s)]
    [gaddr 239.12.1.116    is_ex, 0 source(s)]
    [gaddr 239.170.0.1     is_ex, 0 source(s)]

einordnen? Auf dem Netz sind die nicht zu sehen.

Bei verschiedenen vlans muss ich mir erst überlegen wie ich das bei pfsense mit dem capture auf die Reihe kriege.

Hier jetzt die Mitschnitte wenn Server und Client auf unterschiedlichen VLANs sind.

Zunächst einmal: das Firewall-Log sagt, dass IGMP-Pakete nur auf WAN blockiert wurden. Das bestätigt, dass die in vorigen Beiträgen genannten Rules komplett auf Durchzug stehen.

Auf dem Multicast-Client sehe ich folgendes:

IP (tos 0x0, ttl 255, offset 0, flags [DF],   proto UDP (17))                192.168.20.101.5353 > 224.0.0.251.5353: 0 [2q] PTR (QM)? _ipps._tcp.local. PTR (QM)? _ipp._tcp.local. (45)
IP (tos 0xc0, ttl 1,  offset 0, flags [DF],   proto IGMP (2), options (RA))  192.168.20.1        > 224.0.0.22:     igmp v3 report, 2 group record(s) [gaddr 224.0.0.22 to_ex, 0 source(s)] [gaddr 224.0.0.2 to_e
IP (tos 0xc0, ttl 1,  offset 0, flags [DF],   proto IGMP (2), options (RA))  192.168.20.101      > 239.12.255.254: igmp v2 report 239.12.255.254
IP (tos 0xc0, ttl 1,  offset 0, flags [DF],   proto IGMP (2), options (RA))  192.168.20.101      > 224.0.0.251:    igmp v2 report 224.0.0.251
IP (tos 0xc0, ttl 1,  offset 0, flags [none], proto IGMP (2), options (RA))  192.168.20.1        > 224.0.0.1:      igmp query v2

Dieselben Pakete sehe ich auch auf dem vlan20-Interface der pfsense (= Client-Seite).
Im Log vom IGMP-Proxy kann ich aber nichts finden was auf das netz auf vlan20 hindeuten würde. Das obwohl (wie oben beschrieben) die Firewall-Rules komplett auf Durchzug stehen.

Im igmpproxy-log sehe ich aber solche Einträge:

Jan 30 22:59:07  igmpproxy  24144  Inserted route table entry for 239.255.255.250 on VIF #-1

[ ... ]
Jan 30 22:59:29  igmpproxy  24144  Removing MFC: 192.168.1.162 -> 239.255.255.250, InpVIf: 0
Jan 30 22:59:29  igmpproxy  24144  MRT_DEL_MFC; Errno(49): Can't assign requested address  

Der MRT_DEL_MFC ist ja gut zu sehen.

Aber Interface-Nummer -1 ist doch auch hübsch?!?
Das schaut mir ganz danach aus, als wenn die Fehlermeldung der Routine die nach dem Interface sucht nicht sauber abgefangen wird. Wenn man dann schreibend mit einem negativen Index in die Tabelle einsteigt, dann macht man höchstwahrscheinlich vollkommen unschuldige Daten kaputt...

Das scheint mir eine böse Falle zu sein... Ohne den Code gesehen zu haben, kommen Zweifel an dessen Qualität auf...

Auf dem Server kann ich leider keinen tcpdump laufen lassen (proprietäres embedded device), also muss ich mich mit dem pfsense-Capture des vlan10 begnügen:

3 IP (tos 0xc0, ttl 1, offset 0, flags [DF], proto IGMP (2), options (RA))
    192.168.10.23 > 224.0.0.22: igmp v3 report, 7 group record(s)
       [gaddr 239.12.0.174    is_ex, 0 source(s)]
       [gaddr 239.12.1.116    is_ex, 0 source(s)]
       [gaddr 239.12.255.253  is_ex, 0 source(s)]
       [gaddr 239.12.255.254  is_ex, 0 source(s)]
       [gaddr 224.0.0.251     is_ex, 0 source(s)]
       [gaddr 239.170.0.1     is_ex, 0 source(s)]
       [gaddr 239.255.255.250 is_ex, 0 source(s)]

Das alles scheint mir auf ein Problem beim igmpproxy hinzudeuten..

Interessant ist HIER noch der letzte Satz!
Hast du diese Option gesetzt?! Gilt auch für die LAN to any Regel!
Ebenfalls muss die Regel für die "Bogon networks" außer Kraft gesetzt werden sofern diese aktiv sein sollte! (Siehe Thread Kommentar!)

Zitat von @aqui:

Interessant ist HIER noch der letzte Satz!
Hast du diese Option gesetzt?! Gilt auch für die LAN to any Regel!

Jupp:

Zitat von @FailedNet:
Weiterhin habe ich eine firewall-rule auf vlan10 (also wo der multicast-server sitzt) die IPv4/UDP von 192.168.10.23 (Multicast-source) auf 239.12.255.254 duchlässt mit "Allow IP options" angeklickt.

Zitat von @FailedNet:
eine firewall-rule, die von vlan20 (also client-Seite) alle IPv4 IGMP mit "Allow IP options" angeklickt.

Beim obigen Zahnrad ist ebenfalls "allowopts" gesetzt. Das habe ich auf beiden interfaces so.

Also mir sind die Ideen ausgegangen, wie ich auf noch mehr Durchzug stellen könnte... Höchstens noch das IPv4 auf "Any", aber ob das hilft?

Ebenfalls muss die Regel für die "Bogon networks" außer Kraft gesetzt werden sofern diese aktiv sein sollte! (Siehe Thread Kommentar!)

Diese Regel ist doch nur auf den Provider-Leitungen, und im Artikel ging es ja auch um MC vom Provider? Da will ich doch gar nicht hin?

Auf den lokalen interfaces habe ich keine solche Regel...

Deine Erfahrungen lassen sich leider bestätigen. Trotz any any Scheunentorregeln mit aktiven Options auf WAN und LAN Port und Überprüfung mit Packet Capture am WAN das dort die Multicasts auch ankommen forwardet der Proxy den Join Request des Clients nicht.

Da ist wohl grundsätzlich was im Argen (Bug) beim Proxy... 🤔

Interessanterweise gibt es aber mit PIMD einem Multicast Routing Daemon in den Packages. Es ist sicher einen Versuch wert den einmal in einem sauberen PIM Routing Szenario zu testen wie es z.B. HIER in einem Mikrotik Umfeld beschrieben ist. IP technisch ist das auch besser als ein Proxy.
Es bleibt also spannend...

Zitat von @aqui:

Deine Erfahrungen lassen sich leider bestätigen. Trotz any any Scheunentorregeln mit aktiven Options auf WAN und LAN Port und Überprüfung mit Packet Capture am WAN das dort die Multicasts auch ankommen forwardet der Proxy den Join Request des Clients nicht.

Da ist wohl grundsätzlich was im Argen (Bug) beim Proxy... 🤔

Vielen Dank für das Gegenchecken! Ich dachte schon ich hätte den Schlauch auf dem ich stehe komplett zerdrückt

Interessanterweise gibt es aber mit PIMD einem Multicast Routing Daemon in den Packages. Es ist sicher einen Versuch wert den einmal in einem sauberen PIM Routing Szenario zu testen

Tatsächlich habe ich pimd schon probiert, mit ähnlichen Ergebnissen. Da bin ich aber noch am Recherchieren. Das Thema BSR-Candidates/RP-Candidates/RP-Address ist mir noch undurchsichtig.

Die XX_Candidates zu setzen macht ja keinen Sinn, wenn man nur einen Router hat? Mit nur einem Router kann ja keine Wahl stattfinden? Nach meinem Verständnis müsste man also stattdessen eine fixe RP-Adresse setzen. Wenn ich hier nichts setze, dann tauchen die Routing-Einträge immer nur kurzzeitig auf und verschwinden sofort wieder.

Die Beschreibung ist an dieser Stelle doch sehr... ähm... übersichtlich.

Hast Du evtl einen Link zu einer Beschreibung und/oder ein "working example" für eine pimd-Konfiguration?

Soweit ich verstanden habe, ist RIP für Kommunikation ZWISCHEN Routern zuständig. Würde bei nur einem Router also nur wenig Sinn machen?

Bei der Suche bin ich auch darüber gestolpert, dass eine (oder zwei?) kernel-optionen für das multicast-routing aktiviert werden müssen. Finde das jetzt aber leider nicht mehr. Das scheint mir auch wenig sinnvoll zu sein, denn das sollte doch nur dann erforderlich sein, wenn der kernel direkt das routing machen soll?

Ansonsten gibt es ja noch avahi, mrouted und udp-broadcast-relay, wobei mir letzteres am vielversprechendsten zu sein scheint. Da finde ich aber keine vernünftigen Vergleiche, welches der Pakete was kann.

Ich habe es gerade mal vorab mit einem Mikrotik Router und einem PIM Banalsetup (RP nicht erforderlich bei 2 lokal gerouteten Netzen) getestet:
https://help.mikrotik.com/docs/display/ROS/PIM-SM
Das gleiche mit einem Banalsetup auf einem Cisco 890er Router:
interface GigabitEthernet1
description Lokales LAN1
ip address 192.168.1.254 255.255.255.0
ip pim sparse-mode
!
interface GigabitEthernet2
description Lokales LAN2
ip address 192.168.2.254 255.255.255.0
ip pim sparse-mode
Beide rennen mit dem Multicast Testsetup und auch den üblichen Multicast Test Tools wie Multicast Hammer und Netspanner fehlerlos. Konfig und Funktion ist also per se schon mal richtig und das PIM Routing ist wie erwartet Standard konform was der Wireshark auch klar belegt!
Nächster Step... pimd. Mal sehen...

Also mit pimd komme ich auch nicht so recht weiter.

Rules stehen auf Scheunentore, wie oben beschrieben

pimd aktiviert mit default-Einstellungen:

zwei vlans als interfaces eingetragen:

die vlans ebenfalls default, alledings mit "always bind":

Als Rendezvous-point den beide vlan-interfaces ds routesr mit 224.0.0.0/4 eingetragen:

vlc server mit dst=239.255.1.2,port=5004 gestartet:

ssh testkiste cvlc  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  

pimd zeigt die Gruppe auch an:

Virtual Interface Table ======================================================
Vif  Local Address    Subnet              Thresh  Flags      Neighbors
---  ---------------  ------------------  ------  ---------  -----------------
  0  192.168.178.20   192.168.178              1  DISABLED
  1  192.168.1.1      192.168.1                1  DR NO-NBR
  2  192.168.2.1      192.168.2                1  DR NO-NBR
  3  93.228.32.240    93.228.32.240/32         1  DISABLED
  4  192.168.10.1     192.168.10               1  DISABLED
  5  192.168.1.1      register_vif0            1 

 Vif  SSM Group        Sources             

Multicast Routing Table ======================================================
----------------------------------- (S,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.1.160    224.0.23.12      192.168.1.1      CACHE SG
Joined   oifs: .....j              
Pruned   oifs: ......              
Leaves   oifs: ......              
Asserted oifs: ......              
Outgoing oifs: .....o              
Incoming     : .I....              

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5
           105    20     0       0        0  0  0  0  0  0
----------------------------------- (S,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.2.103    239.255.1.2      192.168.1.1      CACHE SG
Joined   oifs: .....j              
Pruned   oifs: ......              
Leaves   oifs: ......              
Asserted oifs: ......              
Outgoing oifs: .....o              
Incoming     : ..I...              

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5
           105    20     0       0        0  0  0  0  0  0
----------------------------------- (S,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.1.20     239.255.255.250  192.168.1.1      CACHE SG
Joined   oifs: .....j              
Pruned   oifs: ......              
Leaves   oifs: ......              
Asserted oifs: ......              
Outgoing oifs: .....o              
Incoming     : .I....              

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5
           195    50     0       0        0  0  0  0  0  0
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.1.21     239.255.255.250  192.168.1.1      CACHE SG
Joined   oifs: .....j              
Pruned   oifs: ......              
Leaves   oifs: ......              
Asserted oifs: ......              
Outgoing oifs: .....o              
Incoming     : .I....              

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5
           195    50     0       0        0  0  0  0  0  0
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.1.22     239.255.255.250  192.168.1.1      CACHE SG
Joined   oifs: .....j              
Pruned   oifs: ......              
Leaves   oifs: ......              
Asserted oifs: ......              
Outgoing oifs: .....o              
Incoming     : .I....              

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5
           165    20     0       0        0  0  0  0  0  0
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.1.23     239.255.255.250  192.168.1.1      CACHE SG
Joined   oifs: .....j              
Pruned   oifs: ......              
Leaves   oifs: ......              
Asserted oifs: ......              
Outgoing oifs: .....o              
Incoming     : .I....              

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5
           135    50     0       0        0  0  0  0  0  0
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.1.162    239.255.255.250  192.168.1.1      CACHE SG
Joined   oifs: .....j              
Pruned   oifs: ......              
Leaves   oifs: ......              
Asserted oifs: ......              
Outgoing oifs: .....o              
Incoming     : .I....              

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5
           150     5     0       0        0  0  0  0  0  0
----------------------------------- (S,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.2.103    239.255.255.255  192.168.1.1      CACHE SG
Joined   oifs: .....j              
Pruned   oifs: ......              
Leaves   oifs: ......              
Asserted oifs: ......              
Outgoing oifs: .....o              
Incoming     : ..I...              

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5
           105    20     0       0        0  0  0  0  0  0
--------------------------------- (*,*,G) ------------------------------------
Number of Groups: 4
Number of Cache MIRRORs: 8
------------------------------------------------------------------------------

Client gestartet:

vlc rtp://@239.255.1.2:5004

Auf dem client-vlan kann ich auch die igmp-reports des clients sehen, aber keinerlei video-daten:

multicast-x13:11:50:02.467280 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.251 is_ex, 0 source(s)]
multicast-x13:11:50:16.054888 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.255.1.2 to_ex, 0 source(s)]
multicast-x13:11:50:16.870895 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.255.1.2 to_ex, 0 source(s)]
multicast-x13:11:50:20.642943 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 48, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 2 group record(s) [gaddr 239.255.1.2 is_ex, 0 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)]
multicast-x13:11:50:28.098929 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 48, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 2 group record(s) [gaddr 239.255.1.2 is_ex, 0 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)]
multicast-x13:11:50:39.534888 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.255.1.2 to_in, 0 source(s)]
multicast-x13:11:50:39.779266 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.255.1.2 to_in, 0 source(s)]
multicast-x13:11:50:47.010944 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.251 is_ex, 0 source(s)]

entsprechende reports sind auch auf dem vlan-client interface der pfsense zu sehen:

28:24.544552 9c:53:22:24:e8:f0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.105 tell 192.168.1.21, length 46
28:29.571615 04:7b:cb:ba:d7:7c > 00:0d:b9:35:b7:5e, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 45531, offset 0, flags [DF], proto TCP (6), length 52)   192.168.1.105.56910 > 23.43.60.131.443: Flags [.], cksum 0xa27f (correct), seq 1955570225, ack 1766506198, win 501, options [nop,nop,TS val 4022740188 ecr 4104426581], length 0
28:29.571735 04:7b:cb:ba:d7:7c > 00:0d:b9:35:b7:5e, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 45532, offset 0, flags [DF], proto TCP (6), length 52)   192.168.1.105.56910 > 23.43.60.131.443: Flags [.], cksum 0x9e7f (correct), seq 0, ack 1, win 501, options [nop,nop,TS val 4022741212 ecr 4104426581], length 0
28:29.599700 00:0d:b9:35:b7:5e > 04:7b:cb:ba:d7:7c, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 57, id 13224, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->f85c)!)   23.43.60.131.443 > 192.168.1.105.56910: Flags [.], cksum 0xc828 (correct), seq 1, ack 1, win 501, options [nop,nop,TS val 4104438465 ecr 4022718662], length 0
28:29.980298 04:7b:cb:ba:d7:7c > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 60: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.255.1.2 to_ex { }]
28:30.715854 04:7b:cb:ba:d7:7c > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 60: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.255.1.2 to_ex { }]
28:36.544598 9c:53:22:24:e8:f0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.105 tell 192.168.1.21, length 46
28:37.760255 04:7b:cb:ba:d7:7c > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 62: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 48, options (RA))   192.168.1.105 > 224.0.0.22: igmp v3 report, 2 group record(s) [gaddr 239.255.1.2 is_ex { }] [gaddr 224.0.0.251 is_ex { }]

aber eben keinerlei video-Daten!

Auf dem server-vlan interface der pfsense sehe ich:

die video-daten:

   3441 e4:7f:b2:16:e8:95 > 01:00:5e:7f:01:02, ethertype IPv4 (0x0800), length 1370: (tos 0x0, ttl 10, offset 0, flags [DF],
           proto UDP (17), length 1356)   192.168.2.103.39901 > 239.255.1.2.5004: [udp sum ok] UDP, length 1328

igmp-queries (vom pimd?)

      1 00:0d:b9:35:b7:5e > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 50: (tos 0xc0, ttl 1, offset 0, flags [none],
           proto IGMP (2), length 36, options (RA), bad cksum 0 (->124e)!)   192.168.2.1 > 224.0.0.1: igmp query v3
      1 00:0d:b9:35:b7:5e > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 50: (tos 0xc0, ttl 1, offset 0, flags [none],
           proto IGMP (2), length 36, options (RA), bad cksum 0 (->9053)!)   192.168.2.1 > 224.0.0.1: igmp query v3

igmp-reports, die aber die angeforderte 239.255.1.2 NICHT enthalten:

      2 00:0d:b9:35:b7:5e > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 70: (tos 0xc0, ttl 1, offset 0, flags [DF],
           proto IGMP (2), length 56, options (RA), bad cksum 0 (->4140)!)
             192.168.2.1 > 224.0.0.22: igmp v3 report, 3 group record(s)
               [gaddr 224.0.0.22 is_ex { }]
               [gaddr 224.0.0.2 is_ex { }]
               [gaddr 224.0.0.13 is_ex { }]
      2 e4:7f:b2:16:e8:95 > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 60: (tos 0xc0, ttl 1, offset 0, flags [DF],
           proto IGMP (2), length 40, options (RA))
             192.168.2.103 > 224.0.0.22: igmp v3 report, 1 group record(s)
               [gaddr 224.0.0.251 is_ex { }]

Telegramme vom Server auf den verwendeten Port plus eins (Was ist das? gesendet werden sollte ja auf 239.255.1.2:5004):

      7 e4:7f:b2:16:e8:95 > 01:00:5e:7f:01:02, ethertype IPv4 (0x0800), length 106: (tos 0x0, ttl 10, offset 0, flags [DF],
           proto UDP (17), length 92)   192.168.2.103.39902 > 239.255.1.2.5005: [udp sum ok] UDP, length 64

Hmm:

      7 e4:7f:b2:16:e8:95 > 01:00:5e:7f:ff:ff, ethertype IPv4 (0x0800), length 303: (tos 0x0, ttl 255, offset 0, flags [DF],
           proto UDP (17), length 289)   192.168.2.103.50770 > 239.255.255.255.9875: [udp sum ok] UDP, length 261

Dann ist da noch ein PIM-Datagramm, was aber irrelevant sein dürfte, weil ja kein weiterer PIM-Router vorhanden ist:

      1 00:0d:b9:35:b7:5e > 01:00:5e:00:00:0d, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 1, offset 0, flags [none],
           proto PIM (103), length 46, bad cksum 0 (->16a1)!)   192.168.2.1 > 224.0.0.13: PIMv2, length 26
             Hello, cksum 0x9f23 (correct)
             Hold Time Option (1), length 2, Value: 1m45s
             0x0000:  0069
             DR Priority Option (19), length 4, Value: 1
             0x0000:  0000 0001
             Generation ID Option (20), length 4, Value: 0x7f9fc0a0
             0x0000:  7f9f c0a0

Ich bin mit dem Latein am Ende...

Tja, wenn man im PIM Router Setup schludrig ist und vergisst PIMD auf seine entsprechenden Netzwerk Interfaces zu binden ("none") war das zu erwarten! 🧐
Der 2te Fehler: Es gibt immer nur eine statische RP Adresse! Da nimmt man immer das Interface wo sich die MC Quelle (Server) befindet. Deine bessere Hälfte schickst du ja auch nicht zu mehreren verschiedenen Rendezvous Punkten wenn du keinen Ärger haben willst.

Eine Group musst du dort auch NICHT eintragen!
Die BSR Settings musst du ebenfalls nicht anfassen wenn du nur einen singulären MC Router hast. Die sind nur dann relevant wenn man die RP Adresse in einem Netz dynamisch und redundant auf alle PIM Router verteilen will ohne sie immer umständlich statisch zu setzen.

Alles was in den u.a. Screenshots nicht abgebildet ist bleibt leer bzw. immer auf den Default Settings!
Testlab mit LAN1=192.168.1.0 /25 und LAN2=192.168.1.128 /25

So klappt es auf Anhieb:

Group Registration (man achte auf die Flags!):

(RP wurde hier nachträglich auf LAN1 geändert, sorry!)

Test mit dem o.a. Film Streaming unter VLC und auch mit dem Netspanner Tool klappt fehlerlos und auf Anhieb!

Fazit: Works as designed!! 👍 😉

Zitat von @aqui:
Tja, wenn man im PIM Router Setup schludrig ist und vergisst PIMD auf seine entsprechenden Netzwerk Interfaces zu binden ("none") war das zu erwarten! 🧐

Hmm.. Diese Aussage widerspricht der Manpage und auch der Erläuterung auf der Konfigurations-Seite:

"Default interface binding behavior. Per-interface behavior can be set on the Interfaces tab."

Und bei den Interfaces habe ich ja "Always bind" gesetzt. Siehe zweites und drittes Bild in meinem vorigen Post. Die zwei Interfaces um die es geht sind also gebunden! Ich will ja kein MC auf WAN haben, was man bei "Default: bind to all" aber hätte!

Wie auch immer: das so abändern wie Du schreibst bringt auch keine Abhilfe.

Der 2te Fehler: Es gibt immer nur eine statische RP Adresse! Da nimmt man immer das Interface wo sich die MC Quelle (Server) befindet.

Das hatte ich ursprünglich auch so, ohne Erfolg!

Aber mit nur einem RP wird man auch nicht hinkommen, wenn man MC-Sourcen in mehreren VLANs hat?

Wie auch immer: auch mit RP nur auf dem Server-Vlan geht es nicht.

Eine Group musst du dort auch NICHT eintragen!

Auch das herausnehmen der Group hilft nicht....

Wobei der Default (224.0.0.0/16) ja die Gewünschte Adresse (239.255.1.2) ja nicht enthält??!

Die BSR Settings musst du ebenfalls nicht anfassen wenn du nur einen singulären MC Router hast.

Habe ich ja auch nicht.

Group Registration (man achte auf die Flags!):

(RP wurde hier nachträglich auf LAN1 geändert, sorry!)

Der Eintrag mit dem Server ist ja da:

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3  4  5
           105    20     0       0        0  0  0  0  0  0
----------------------------------- (S,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
192.168.2.103    239.255.1.2      192.168.1.1      CACHE SG
Joined   oifs: .....j              
Pruned   oifs: ......              
Leaves   oifs: ......              
Asserted oifs: ......              
Outgoing oifs: .....o              
Incoming     : ..I...              

Was fehlt, ist der Eintrag mit INADDR_ANY.

Auch die Scheunentor-Regeln mit ip-options sind auf beiden interfaces gesetzt.

Test mit dem o.a. Film Streaming unter VLC und auch mit dem Netspanner Tool klappt fehlerlos und auf Anhieb!

Fazit: Works as designed!! 👍 😉

Bei mir leider nicht.

Diese Aussage widerspricht der Manpage

Nein, nicht wirklich. Man muss im Default erstmal alles mappen und kann dann in der Interface Auswahl spezifisch Interface aktivieren und deaktivieren. Mit der Logik klappt es fehlerlos.

habe ich ja "Always bind" gesetzt.

Gut, ich habe hier "Bind to all" gesetzt...

Ich will ja kein MC auf WAN haben

Deshalb löscht man ja auch mit Klick auf den Mülleimer das WAN Interface wie hier im Setup.

In den Interface stehen hier nur die PIM relevanten Interfaces LAN und LAN2.

Aber mit nur einem RP wird man auch nicht hinkommen, wenn man MC-Sourcen in mehreren VLANs hat?

Doch das geht natürlich auch. Man muss dann nur sicherstellen das der RP aus allen diesen Netzen erreichbar ist.

Auch die Scheunentor-Regeln mit ip-options sind auf beiden interfaces gesetzt.

Nur irgendwie sinnfrei, zumindestens die 2te Regel. Wenn man oben alles freigibt muss man ja nicht danach nochmal extra IGMP freigeben was ja oben schon inkludiert ist.
Wie gesagt...rennt hier alles fehlerlos.
Ich ziehe für dich nochmal ein paar Wireshark Traces...

Zitat von @aqui:

Diese Aussage widerspricht der Manpage

Nein, nicht wirklich. Man muss im Default erstmal alles mappen und kann dann in der Interface Auswahl spezifisch Interface aktivieren und deaktivieren. Mit der Logik klappt es fehlerlos.

Naja, es gibt da eben zwei Wege:

als Default alles aktivieren, und dann das nicht gewünschte deaktivieren
als default nichts aktivieren, und das gewünschte explizit aktivieren

Und in Deinem Beispiel ist auch 10.99.1.0/24 gebunden, das ist vermutlich das WAN, weil Du erst mal "alles" bindest..

habe ich ja "Always bind" gesetzt.

Gut, ich habe hier "Bind to all" gesetzt...

Also sollte das passen..

Ich will ja kein MC auf WAN haben

Deshalb löscht man ja auch mit Klick auf den Mülleimer das WAN Interface wie hier im Setup.

???

Wenn man bei Default=bindall das WAN deaktivieren will, muss man dafür einen Eintrag erstellen mit "never bind". Wenn man den Eintrag mit dem Mülleimer entfernt, wird das interface wieder gebunden, weil dann der default "Bind all" greift.

In den Interface stehen hier nur die PIM relevanten Interfaces LAN und LAN2.

Ja, und nur diese sollen doch gebunden werden.

Auch die Scheunentor-Regeln mit ip-options sind auf beiden interfaces gesetzt.

Nur irgendwie sinnfrei, zumindestens die 2te Regel. Wenn man oben alles freigibt muss man ja nicht danach nochmal extra IGMP freigeben was ja oben schon inkludiert ist.

Liegt daran, dass ich die Scheunentore schrittweise immer weiter geöffnet habe.

Ursprünglich existierte nur die obere Regel mit IP4,TCP+UDP
Dann habe ich die zweite Regel mit IP+IGMP hinzugefügt
weil es dann immer noch nicht ging habe ich die obere auf IPv4,* gestellt. und die untere Regel als Gedächtnisstütze belassen.

Wie auch immer: das Scheunentor ist breiter als die Mauer. Das kann also nicht der Grund sein, dass es nicht geht.

BTW: ich habe die oben erwähnte Seite wieder gefunden, wo das mit der kernel-Option stand: README-debug

Wie kann ich überprüfen, ob diese Optionen gesetzt sind?

       options    MROUTING         # Multicast routing
       options    PIM              # Enable for pimd

Oh:"sysctl net.inet.ip.mforwarding" gibt:

sysctl: unknown oid 'net.inet.ip.mforwarding'

So, das Ganze nochmal mit deinen Bind Settings aufgesetzt und auch da klappt es erwartungsgemäß fehlerlos.
RP Adresse auch einmal testweise umgesetzt auf die Client Seite und auch das rennt absolut sauber. Mit anderen Worten das PIM Routing funktioniert absolut fehlerlos und verhält sich absolut identisch zu einem PIM Routing Setup mit Mikrotik und Cisco.
Ein entsprechender Wireshark Trace auf der Client Seite (Win 10 Notebook mit VLC) zeigt das auch eindeutig:

Du kannst an der Absender Mac Adresse (PCEngines APU Board) deutlich sehen das der Multicast RTP Frame von der LAN Mac Adresse der pfSense kommt. Der MC Streaming Server befindet sich im Segment LAN-2
Ebenso das um 1 reduzierte TTL zeigt eindeutig das es durch den PIM Router gelaufen ist, denn der Stream wurde mit TTL=10 und QoS Priorisierung mit DSCP ToS=CS3 am Server gestartet. (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)
Auch ohne das man die hier verwendete MC Gruppenadresse 239.232.1.2 im RP einträgt rennt es fehlerlos

⚠️ Es gibt eine böse Falle in die du ggf. im Eifer des Gefechts getappt bist und die lauert auf der Multicast Source Seite (Server) sofern dort ein Switch im Einsatz ist der IGMP Snooping aktiv hat!
Solltest du das aktiviert haben und das Feature "Drop unknown Multicast" aktiv sein scheitert das PIM Routing von Multicast Quellen die an diesem Switch betrieben werden.
Das ist auch klar, denn ein Server wie der VLC sendet im Gegensatz zu einem Client sofort los ohne einen IGMP Join zu senden. Ein IGMP Snooping Switch registriert ohne ein Join diese Gruppenadresse verständlicherweise dann als "unknown" und dropped diesen Traffic am Switchport sofort. Der MC Traffic hat in dem Falle also überhaupt keine Chance erst überhaupt zum PIM Router zu gelangen.
Das Dropping von unknown Multicasts ist in der Regel bei IGMP Snooping immer aktiv weil man dort von Client Traffic ausgeht der natürlich immer Joins sendet und dann die Gruppenadressen im Switch sauber registriert.

Prüfe das also sollte IGMP Snooping bei dir auf der Server Seite aktiv sein und deaktiviere dies ggf. auf dem Switch dort (und nur da) sofern aktiv. Bei einfachen Switches geht das global in den IGMP Settings, bei besseren Switches kann man es auch per Interface machen was natürlich effizienter ist. Hier am Beispiel eines Cisco SG/CBS Modells

Das folgende Beispiel zeigt es auf einem einfachen Zyxel Switch mit aktivem IGMP Snooping und nochmals die dazu korrespondierenden PIMD Settings der pfSense.

Zitat von @aqui:

Vielen Dank erst mal, dass Du da so unermüdlich dranbleibst!

War/bin schon mittlerweile am Überlegen, probehalber auf opnsense umzusteigen. Allerdings ist das ein Produktiv-Netz, da macht man ja nicht einfach so leichtfertig einen Umstieg...

Oder aber alternativ pfsense ersetzen durch einen Mikrotik-Router? Da gibt es glaube ich auch welche mit vielen Ports, dann hätte man Router+Switch in einem....

Hmmm... Durchaus denkbar. Das ist ein älterer Level1 gsw2472tgx 24port 10/100 vlan-fähig. Der hat keinerlei Einstell-Möglichkeiten bezüglich IGMP.

Den Switch zu ersetzen steht auf der Todo-Liste. Ich wollte aber erst den VLAN-Kram sauber haben bevor ich den Switch ersetze.

Das ist auch klar, denn ein Server wie der VLC sendet im Gegensatz zu einem Client sofort los ohne einen IGMP Join zu senden. Ein IGMP Snooping Switch registriert ohne ein Join diese Gruppenadresse verständlicherweise dann als "unknown" und dropped diesen Traffic am Switchport sofort. Der MC Traffic hat in dem Falle also überhaupt keine Chance erst überhaupt zum PIM Router zu gelangen.

Hmmm... Aber ich sehe den MC-Traffic auf der am interface der pfsense?

in diesem Zusammenhang nochmal die Frage, was der VLC-server da auf Port 5005 sendet obwohl ich Port 5004 eingegeben habe?

Das Dropping von unknown Multicasts ist in der Regel bei IGMP Snooping immer aktiv weil man dort von Client Traffic ausgeht der natürlich immer Joins sendet und dann die Gruppenadressen im Switch sauber registriert.

Der Switch hat ezüglich IGMP keinerlei Einstellmöglichkeiten (auch nicht, das Snooping zu aktivieren). Ich hätte also vermutet, dass der alles an alle Ports rauswirft die zum gleichen VLAN gehören?

Aber ich sehe den MC-Traffic auf der am interface der pfsense?

Zumindestens am pfSense Interface wo die Multicast Quelle ist (Server). Dort muss natürlich der Stream Traffic des Servers über die FW interne Paket Capture Funktion immer zu sehen sein! (Hier LAN-2)
Wenn er da nicht ankommen sollte kann es die oben erwähnte IGMP Problematik sein!
Wenn dort erst gar nichts ankommt kann der PIM Router natürlich auch nix auf die Client Seite routen.

was der VLC-server da auf Port 5005 sendet obwohl ich Port 5004 eingegeben habe?

Da kann man leider nur kristallkugeln weil relevante Infos fehlen.

Sehr hilfreich wäre wenn du mal einen Wireshark oder Paket Capture hier posten würdest indem du auf die Server IP und UDP 5005 filterst wo das herkommen soll. Dann kann man das genau sehen.
Natürlich sollte es keinen solchen "Geisterstream" geben wenn du nur einen einzigen gestartet hast!

Die gleiche Multicast Gruppenadresse nur mit unterschiedlichen UDP Ports zu verwenden wäre natürlich fatal und auch ein möglicher Grund des Scheiterns! Das geht natürlich immer nur andersrum. Gleicher Port aber zwingend unterschiedliche Gruppenadressen.
Genug freie Filme um mehrere RTP MC Streams zu senden gibt es ja zuhauf um dir dein eigenes IP TV zu basteln.

https://archive.org/details/ElephantsDream
https://durian.blender.org/download/
https://mango.blender.org/download/
usw. usw.

Zitat von @aqui:

Aber ich sehe den MC-Traffic auf der am interface der pfsense?

Da ich den Traffic ja an der pfsense sehe, kann es eigentlich nicht das oben erwähnte Switch-Problem sein...

was der VLC-server da auf Port 5005 sendet obwohl ich Port 5004 eingegeben habe?

Da kann man leider nur kristallkugeln weil relevante Infos fehlen.

Sehr hilfreich wäre wenn du mal einen Wireshark oder Paket Capture hier posten würdest indem du auf die Server IP und UDP 5005 filterst wo das herkommen soll. Dann kann man das genau sehen.

Hatte ich doch oben schon geschrieben:

      7 e4:7f:b2:16:e8:95 > 01:00:5e:7f:ff:ff, ethertype IPv4 (0x0800), length 303: (tos 0x0, ttl 255, offset 0, flags [DF],
           proto UDP (17), length 289)   192.168.2.103.50770 > 239.255.255.255.9875: [udp sum ok] UDP, length 261

(192.168.2.103 ist der vlc-server) Mehr wirft wireshark an dieser Stelle leider auch nicht aus.

Natürlich sollte es keinen solchen "Geisterstream" geben wenn du nur einen einzigen gestartet hast!

Hmmm...

Die gleiche Multicast Gruppenadresse nur mit unterschiedlichen UDP Ports zu verwenden wäre natürlich fatal und auch ein möglicher Grund des Scheiterns! Das geht natürlich immer nur andersrum. Gleicher Port aber zwingend unterschiedliche Gruppenadressen.

Das ist ja der standard-vlc aus den Standard-ubuntu-repositories. Der sollte sich bei mir ja nicht anders verhalten als woanders in der Welt. Und Port 5005 habe ich niemals nicht irgendwo eingegeben/verwendet.

Da ich den Traffic ja an der pfsense sehe, kann es eigentlich nicht das oben erwähnte Switch-Problem sein...

Das ist absolut korrekt!
Das ist dann eher ein Regel Problem oder das du z.B. vergessen hast die IGMP Proxy Funktion im Setup zu deaktivieren. (beides parallel geht natürlich nicht!) usw. usw. Den Switch kann man dann ausschliessen.

Hatte ich doch oben schon geschrieben:

Shame on me... Im Eifer des Gefechts glatt übersehen. 🙈
Das ist ein UDP Multicast Frame mit Ziel 239.255.255.255 und UDP Port 9875
Offiziell das SAP Protokoll (Telefonie und Multimedia) nutzt aber standartkonform eine andere (offizielle) Multicast Gruppenadresse als oben bei dir, was auffällig ist.
UDP 9875 wird auch mal für böse Dinge gekapert wenn man danach sucht.
Die Adresse ist in Bezug auf SAP verdächtig, denn sie gehört zum Organizational Local Scope RFC2365 also zum Kontingent was man frei vergeben kann und wo nichts reserviert ist und entspricht dem RFC1918 für Unicast.
Auffällig auch das es die letzt nutzbare Adresse im Multicast Spektrum überhaupt ist.

Der Absender ist e4:7f:b2:16:e8:95 und damit ein Fujitsu Rechner!
Hier solltest du dann einmal in die Mac Forwarding Tabelle deines Switches sehen an welchem Port der hängt und dort mal genau forschen warum der sowas raussendet und ob er das auch darf.
Der o.a. Absender nutzt laut Trace die IP 192.168.2.103 und wenn du sagst dein VLC Streaming Server ist die 192.168.1.103 dann klingt das ja schonmal verdächtig, denn es kommt dann offensichtlich nicht vom VLC Server sondern aus einem fremden IP Netz.

Der sollte sich bei mir ja nicht anders verhalten als woanders in der Welt.

Absolut korrekt! Er sendet auch garantiert nichts so mirnichtsdirnichts von selber auf Adressen im Organizational Local Scope raus.

Und Port 5005 habe ich niemals nicht irgendwo eingegeben/verwendet.

Wie kommst du auch darauf?? Der o.a. Trace sagt doch klar das der Absender den Source Port UDP 50770 verwendet und den Destination Port UDP 9875. Wo also hast du die ominöse 5005 her? 🤔

Zitat von @aqui:

Da ich den Traffic ja an der pfsense sehe, kann es eigentlich nicht das oben erwähnte Switch-Problem sein...

Double-Check: IGMP-Proxy ist deaktiviert.

Hatte ich doch oben schon geschrieben:

Shame on me... Im Eifer des Gefechts glatt übersehen. 🙈

Das "shame on me" ist auf meiner Seite: ich habe das falsche Paket herunterkopiert. Hier ist das mit Port 5005:

      7 e4:7f:b2:16:e8:95 > 01:00:5e:7f:01:02, ethertype IPv4 (0x0800), length 106: (tos 0x0, ttl 10, offset 0, flags [DF],
           proto UDP (17), length 92)   192.168.2.103.39902 > 239.255.1.2.5005: [udp sum ok] UDP, length 64

Das ist ein UDP Multicast Frame mit Ziel 239.255.255.255 und UDP Port 9875
Offiziell das SAP Protokoll (Telefonie und Multimedia) nutzt aber standartkonform eine andere (offizielle) Multicast Gruppenadresse als oben bei dir, was auffällig ist.
UDP 9875 wird auch mal für böse Dinge gekapert wenn man danach sucht.
Die Adresse ist in Bezug auf SAP verdächtig, denn sie gehört zum Organizational Local Scope RFC2365 also zum Kontingent was man frei vergeben kann und wo nichts reserviert ist und entspricht dem RFC1918 für Unicast.
Auffällig auch das es die letzt nutzbare Adresse im Multicast Spektrum überhaupt ist.

Der Absender ist e4:7f:b2:16:e8:95 und damit ein Fujitsu Rechner!
Hier solltest du dann einmal in die Mac Forwarding Tabelle deines Switches sehen an welchem Port der hängt und dort mal genau forschen warum der sowas raussendet und ob er das auch darf.
Der o.a. Absender nutzt laut Trace die IP 192.168.2.103 und wenn du sagst dein VLC Streaming Server ist die 192.168.1.103 dann klingt das ja schonmal verdächtig, denn es kommt dann offensichtlich nicht vom VLC Server sondern aus einem fremden IP Netz.

die 192.168.2.103 ist der Fujitsu, auf dem ich unter Ubuntu den vlc-server laufen habe. Passt also soweit. Vlc würde ja auch unter "multimedia" fallen. Und tatsächlich kommen beide Pakete vom vlc:

jw@h730:/home/jw$ sudo tcpdump -Xvv port 5005 or port 9875
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:35:34.001059 IP (tos 0x0, ttl 10, id 30870, offset 0, flags [DF], proto UDP (17), length 92)
    h730.wolf.lan.44892 > 239.255.1.2.5005: [bad udp cksum 0xb46a -> 0x480d!] UDP, length 64
        0x0000:  4500 005c 7896 4000 0a11 43ea c0a8 0267  E..\x.@...C....g
        0x0010:  efff 0102 af5c 138d 0048 b46a 80c8 0006  .....\...H.j....
        0x0020:  4986 0557 e970 d2d6 0043 1d58 7b68 df47  I..W.p...C.X{h.G
        0x0030:  0000 5896 01cb 8a20 81ca 0008 4986 0557  ..X.........I..W
        0x0040:  010d 3139 322e 3136 382e 322e 3130 3306  ..192.168.2.103.
        0x0050:  0b76 6c63 2033 2e30 2e39 2e32            .vlc.3.0.9.2
17:35:34.056621 IP (tos 0x0, ttl 255, id 9429, offset 0, flags [DF], proto UDP (17), length 289)
    h730.wolf.lan.55851 > 239.255.255.255.9875: [bad udp cksum 0xb42d -> 0x164c!] UDP, length 261
        0x0000:  4500 0121 24d5 4000 ff11 a2e7 c0a8 0267  E..!$.@........g
        0x0010:  efff ffff da2b 2693 010d b42d 2000 1c80  .....+&....-....
        0x0020:  8c6c 0048 6170 706c 6963 6174 696f 6e2f  .l.Happlication/
        0x0030:  7364 7000 763d 300d 0a6f 3d2d 2031 3638  sdp.v=0..o=-.168
        0x0040:  3231 3137 3533 3732 3733 3134 3139 3238  2117537273141928
        0x0050:  3420 3136 3832 3131 3735 3337 3237 3331  4.16821175372731
        0x0060:  3431 3932 3834 2049 4e20 4950 3420 6837  419284.IN.IP4.h7
        0x0070:  3330 0d0a 733d 4275 6e6e 790d 0a69 3d4e  30..s=Bunny..i=N
        0x0080:  2f41 0d0a 633d 494e 2049 5034 2032 3339  /A..c=IN.IP4.239
        0x0090:  2e32 3535 2e31 2e32 2f32 3535 0d0a 743d  .255.1.2/255..t=
        0x00a0:  3020 300d 0a61 3d74 6f6f 6c3a 766c 6320  0.0..a=tool:vlc.
        0x00b0:  332e 302e 392e 320d 0a61 3d72 6563 766f  3.0.9.2..a=recvo
        0x00c0:  6e6c 790d 0a61 3d74 7970 653a 6272 6f61  nly..a=type:broa
        0x00d0:  6463 6173 740d 0a61 3d63 6861 7273 6574  dcast..a=charset
        0x00e0:  3a55 5446 2d38 0d0a 6d3d 7669 6465 6f20  :UTF-8..m=video.
        0x00f0:  3530 3034 2052 5450 2f41 5650 2033 330d  5004.RTP/AVP.33.
        0x0100:  0a62 3d52 523a 300d 0a61 3d72 7470 6d61  .b=RR:0..a=rtpma
        0x0110:  703a 3333 204d 5032 542f 3930 3030 300d  p:33.MP2T/90000.
        0x0120:  0a                                       .

Auf Port 9875 announced der also tatächlich den Hasen-Film. Warum falsche Group? keine Ahnung. Was der auf Port 5005 treibt ist aber immer noch schleierhaft.

Und Port 5005 habe ich niemals nicht irgendwo eingegeben/verwendet.

Wie kommst du auch darauf?? Der o.a. Trace sagt doch klar das der Absender den Source Port UDP 50770 verwendet und den Destination Port UDP 9875. Wo also hast du die ominöse 5005 her? 🤔

Sorry, da hatte ich das falsche Paket aus obigem Beitrag runterkopiert.

Und tatsächlich kommen beide Pakete vom vlc:

Kann man nicht sehen weil du die DNS Namensauflösung nicht abgeschaltet hast.

Du sagst ja oben der VLC ist der .1.103, das Paket kommt aber vom .2.103?!
Ist das jetzt ein Typo oder sind es wirklich 2 unterschiedliche Maschinen. Wenn einer der Hypervisor ist und der andere die VM wäre es ja ok aber aus 2 unterschiedlichen IP Netzen? OK, ist jetzt auch nur geraten sofern du eine andere Maske fährst als einen 24er Präfix?!

Mit welchem Kommando startest du denn den Film?? Hier:

cvlc /home/pi/Videos/BigBuckBunny_320x180.mp4 --sout "#rtp{dst=239.232.1.2,port=5004,ttl=10,mux=ts,sap,name=Bunny}" --dscp=96 --no-sout-all --sout-keep --loop   

Plattform ist ein Raspberry Pi 4 mit aktuellstem Debian Bookworm (RasPiOS). Da mit screen und "screen -S vlc" ein separates Terminal eröffnet und dort der Stream gestartet. <ctrl ad> lässt das dann im Hintergrund werkeln. Das auch mit mehreren Filmen auf unterschiedlichen Gruppenadressen.
Sniffert man per Kabelhai den Start mit ist da erstmal nix zu sehen von anderen Ports und Multicast Adressen außer den im o.a. Kommando. 🤔
Möglich aber das mir da was durch die Lappen gegangen ist, denn och habe nur auf Clientseite hinter dem PIM gesniffert. Wenn das eine Link Local Gruppe mit TTL=1 sieht man die auf der anderen Seite natürlich nicht.
Der Kommandoparameter "mux=ts,sap,name=Bunny.." besagt ja das da irgendwie auch SAP mit im Spiel ist....
Das VLC Wiki lüftet dann das Geheimnis!! 😉
https://wiki.videolan.org/Documentation:Streaming_HowTo/Advanced_Streami ...
Genau DAS sendet den SAP. Nur irgendwie mit einer falschen Gruppenadresse bei dir. 🤔
Muss ich hier nochmal genauer mittracen mit dem Kabelhai ob das hier auch der Fall ist.

Zitat von @aqui:

Und tatsächlich kommen beide Pakete vom vlc:

Kann man nicht sehen weil du die DNS Namensauflösung nicht abgeschaltet hast.

Du sagst ja oben der VLC ist der .1.103, das Paket kommt aber vom .2.103?!
Ist das jetzt ein Typo oder sind es wirklich 2 unterschiedliche Maschinen.

Upps, das war tatsächlich ein Vertippser! Sorry. Habe das soeben korrigiert.

Mit welchem Kommando startest du denn den Film?? Hier:

cvlc /home/pi/Videos/BigBuckBunny_320x180.mp4 --sout "#rtp{dst=239.232.1.2,port=5004,ttl=10,mux=ts,sap,name=Bunny}" --dscp=96 --no-sout-all --sout-keep --loop 

cvlc  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  

ebenfalls in einer screen-session auf einem fujitsu h30 laptop unter Ubuntu

Der Kommandoparameter "mux=ts,sap,name=Bunny.." besagt ja das da irgendwie auch SAP mit im Spiel ist....

Hmm, ja. Die Kommandozeile habe ich aus einer vlc-howto geklaut. Vermutlich fehlt da noch ein Parameter für die SAP-Gruppenadresse.

Die Kommandozeile habe ich aus einer vlc-howto geklaut.

Vermutlich HIER. 😉
Die Gruppenadresse ist ja dem Protokoll fest zugewiesen wie z.B. 224.0.0.252 bei LLMNR oder 224.0.0.251 bei mDNS / Bonjour. Die kann man normalerweise nicht so einfach frei "würfeln".
Ich schmeiss mal den Kabelhai an...

10 Minuten mitgeschnitten aber mit UDP 9875 kommt gar nix hier....
Das ist aber scheinbar nicht verwunderlich den cvlc quittiert hier den "sap" Parameter mit einem Fehler (letzte Zeile):

cvlc /home/user/Videos/BigBuckBunny_320x180.mp4 --sout "#rtp{dst=239.232.1.2,port=5004,ttl=10,mux=ts,sap,name=Bunny}" --dscp=96  --no-sout-all --sout-keep --loop  
VLC media player 3.0.20 Vetinari (revision 3.0.20-0-g6f0d0ab126b)
[0000005584783f90] main interface error: no suitable interface module
[000000558469b560] main libvlc error: interface "globalhotkeys,none" initialization failed  
[0000005584783f90] dummy interface: using the dummy interface module...
[0000007f900013e0] main stream out error: Out-of-scope multicast address not supported by SAP 

Ersetzt man die "232" im 2ten Oktet testweise mit .255 oder .192 klappt es ohne Fehlermeldung und dann auch mit dem SAP Announcement!

Sieht also so aus als ob es etwas mit dem Multicast Adress Scope zu tun hat und geht auch einher mit dem o.a. zitierten RFC2365 der die Ranges 239.255.0.0/16 und "abwärts" 239.254.0.0/16 und 239.253.0.0/16 und auch die Ranges 239.192.0.0/14 sowie 239.0.0.0/10, 239.64.0.0/10 und 239.128.0.0/10 dafür vorgibt. Wobei man hier sehr vorsichtig sein muss wegen des 32:1 Overlaps der IP Multicast Adressen zu ihren korrespondierenden Mac Adressen! Aus diesem Grund sollte man generell die Gruppenadressen x.0.0.x und x.128.0.x immer zwingend vermeiden!!
Bewegt man sich innerhalb dieser Ranges dann taucht auch die VLC SAP Fehlermeldung nicht auf.

Mit anderen Worten: Dein Traffic ist SAP und damit standardkonform. Übrigens...
Auch mit all diesen MC Adressen klappt das PIM Routing auf der pfSense fehlerlos. (Version 2.7.2) 😉

Spaßeshalber aus Neugier auch gleich mal Magenta TV getestet...

Works as designed! 😉 👍

Sorry für die lange Pause. Ich war hier am rotieren (siehe unten)

Zitat von @aqui:

10 Minuten mitgeschnitten aber mit UDP 9875 kommt gar nix hier....
Das ist aber scheinbar nicht verwunderlich den cvlc quittiert hier den "sap" Parameter mit einem Fehler (letzte Zeile):

cvlc /home/user/Videos/BigBuckBunny_320x180.mp4 --sout "#rtp{dst=239.232.1.2,port=5004,ttl=10,mux=ts,sap,name=Bunny}" --dscp=96  --no-sout-all --sout-keep --loop  
VLC media player 3.0.20 Vetinari (revision 3.0.20-0-g6f0d0ab126b)
[0000005584783f90] main interface error: no suitable interface module
[000000558469b560] main libvlc error: interface "globalhotkeys,none" initialization failed  
[0000005584783f90] dummy interface: using the dummy interface module...
[0000007f900013e0] main stream out error: Out-of-scope multicast address not supported by SAP 

Ersetzt man die "232" im 2ten Oktet testweise mit .255 oder .192 klappt es ohne Fehlermeldung und dann auch mit dem SAP Announcement!

Wie kommst Du eigentlich auf die 239.232.1.2? Ich habe immer nur die 239.255.1.2 verwendet.

Auch mit all diesen MC Adressen klappt das PIM Routing auf der pfSense fehlerlos. (Version 2.7.2) 😉

Bei mir leider nicht, ebenfalls 2.7.2 (siehe unten).

Spaßeshalber aus Neugier auch gleich mal Magenta TV getestet...

Works as designed! 😉 👍

Ist das bei Dir eigentlich ein produktiv-System oder ein Testaufbau? Wenn Testaufbau, dann kannst Du mir evtl die Config zusenden, dann könnte ich evtl auf dieser aufsetzend schauen wo es bei meiner config konkret hakt?

Ansonsten war ich hier in den letzten Wochen kräftig am Rotieren:

Weil zeitweise auch der Switch im Verdacht stand und mein level1 sowieso eigentlich auf den Elektroschrott gehört, habe ich einen d-link DGS-1510-20 besorgt. (BTW: kann es sein, dass d-link sehr eigenwillig zu konfigurieren sind?) Bei diesem gibt es einige Einstellmöglichkeiten bezüglich IGMP-Snooping. Aber keine dieser Einstellungen haben weitergeholfen.

Der nächste Schritt war, opnSense aufzusetzen. Auch damit habe ich das nicht zum Laufen kriegen können.

Nach vielen langen google-Sitzungen bin ich irgendwann auf der Seite des (so glaube ich) ursprünglichen pimd-Autors über folgenden Satz gestolpert:

Zitat von https://troglobit.com/howtos/multicast/#faq

What’s the routing performance of pimd/mrouted/smcroute?

N/A. Neither of them take active part in the actual forwarding of multicast frames. This is what the kernel or dedicated routing HW does. The routing daemons pimd/mrouted/smcroute only manipulate the multicast routing table(s) of the operating system’s kernel.

Das erklärt natürlich, warum pimd bei meinem ursprünglichen Problem 239.12.255.254:9522 mit ttl=1 nicht weiterhilft. Warum vlc mit ttl=10 nicht funktioniert, bleibt aber trotzdem ein Rätsel. Hier habe ich den Verdacht, dass die IGMP-Anforderungen des vlc-Clients (bei dem ja das ttl nicht verstellbar ist) nicht bis zum pimd durchkommen und der pimd insofern auch keine IGMP-Reports in Richtung vlc-server sendet.

Nach vielen weiteren langwierigen Therapie-Sitzungen bei Tante Gockel habe ich dann udpbroadcastrelay ausprobiert. Und siehe da: ES GEHT!

Als Gegencheck wieder zurück zu pimd: geht wieder nicht.

Wobei ich jetzt nicht so richtig davon überzeugt bin, dass das was udpbroadcastrelay macht in irgend einer Form mit irgend einem Standard in Übereinstimmung zu bringen ist. Der bindet sich ja an allen definierten interfaces an die MC-Gruppen und flutet im Grunde alle Netze mit den Daten, und zwar unabhängig davon ob da jemand zuhört oder nicht. Das löuft eigentlich vollkonnen konträr zum MC-Gedaken. Bei mDNS/SSDP mag das ja akzeptabel sein, aber bei video-Daten ist das eher sub-optimal.

Jetzt gilt es aber erst einmal die oben genannten Scheunentore wieder zu schliessen. Gibt es da entsprechend best-practices? Man hört ja, dass man sich zB mit UPnP schnell mal Löcher in die firewall reisst.

Wie kommst Du eigentlich auf die 239.232.1.2?

Das war nur ein spielerischer Versuch und entstammte, oh Wunder, einem strukturierten Adressierungsvorschlag aus der Cisco Fachliteratur.
Der ist aber de facto falsch und ignoriert die RFC Vorgaben.
Der RFC2365 gibt dafür klar drei feste /16er Ranges 239.255.0.0/16 und "abwärts" vor. Also

239.254.0.0/16
239.253.0.0/16

sowie die Ranges

239.192.0.0/14
239.0.0.0/10
239.64.0.0/10
239.128.0.0/10

239.232. gehört ganz klar NICHT dazu und ist ein Fehler! In der Beziehung verhält sich VLC dazu also absolut vorbildlich und RFC konform!
Wie gesagt: Wegen des 32:1 Overlaps der IP Multicast Adressen zu ihren korrespondierenden Mac Adressen muss man die Gruppenadressen x.0.0.x und x.128.0.x immer zwingend vermeiden!!

VLC-Clients (bei dem ja das ttl nicht verstellbar ist)

Da ist ja auch gar kein TTL erforderlich, denn der sendet ja lediglich einen lokalen IGMP Join Request. Für den ist ein TTL also völlig irrelevant weil der ja niemals geroutet wird!

Hab das gleiche Setup auch nochmal mit einem Mikrotik Router mit PIM Routing und auch mit einem Cisco 880er Router und PIM Routing aufgesetzt und auch da funktioniert das PIM Multicast Routing, wie zu erwarten war, fehlerlos und standardkonform!

Frage Router, Routing

Mehr von FailedNet

Pimp up my networkFailedNet - 12 Kommentare

Heiß diskutiert