Mikrotik cAP Multicast Probleme
Hallo,
aufgrund eines OS-Wechsels bei meinen Sonos Geräten werden einigen ältere Komponenten deaktiviert. So auch meine Sonos Bridge, die für meine drahtlosen Player ein SONOSNet aufgespannt hat, welches parallel zum WLAN im 2.4GHz lief.
Inzwischen habe ich alle Player auf mein WALN umgestellt und soweit klappt das auch, allerdings kommt es bei Gruppenbildungen von Sonos-Playern zu Problemen. Lt. Sonos Support werden offenbar keine Multicast Pakete, die für die Gruppensteuerung nötig ist, über mein WLAN gesendet. Solange die Player verkabelt sind, also an meinem Cisco Switch hängen, läuft alles, wie es soll und somit scheint das Problem an den cAPs zu liegen.
Diese sind wie folgt konfiguriert:
- zentral über CAPSMAN gesteuert
- local Forwarding aktiv (datapath)
- Client2Client-Forwarding aktiv (datapath)
- Multicast-helper =full (datapath)
M.E. sollte alles korrekt konfiguriert. Was ist mit dem IGMP Snooping. Auf meinem Router (RB3011) an dem auch der Cisco Switch mit den cAPs hängen, ist das natürlich aktiviert. Muss das auf den lokalen Bridgen der cAPS auch aktiviert werden, oder werden die Einstellungen vom RB3011 übernommen, da im CAPSMAN unter Datapath ja auch die RB3011 Bridge verwendet wird, auf der das sowieso eingeschaltet ist.
Ich kann mir nicht erklären, warum bei den reinen WLAN-Playern die Gruppenbildung nicht funzt und im SonosNet oder im verkabelten NEtzt sauber läuft.
Danke und Gruß,
Spartacus
aufgrund eines OS-Wechsels bei meinen Sonos Geräten werden einigen ältere Komponenten deaktiviert. So auch meine Sonos Bridge, die für meine drahtlosen Player ein SONOSNet aufgespannt hat, welches parallel zum WLAN im 2.4GHz lief.
Inzwischen habe ich alle Player auf mein WALN umgestellt und soweit klappt das auch, allerdings kommt es bei Gruppenbildungen von Sonos-Playern zu Problemen. Lt. Sonos Support werden offenbar keine Multicast Pakete, die für die Gruppensteuerung nötig ist, über mein WLAN gesendet. Solange die Player verkabelt sind, also an meinem Cisco Switch hängen, läuft alles, wie es soll und somit scheint das Problem an den cAPs zu liegen.
Diese sind wie folgt konfiguriert:
- zentral über CAPSMAN gesteuert
- local Forwarding aktiv (datapath)
- Client2Client-Forwarding aktiv (datapath)
- Multicast-helper =full (datapath)
M.E. sollte alles korrekt konfiguriert. Was ist mit dem IGMP Snooping. Auf meinem Router (RB3011) an dem auch der Cisco Switch mit den cAPs hängen, ist das natürlich aktiviert. Muss das auf den lokalen Bridgen der cAPS auch aktiviert werden, oder werden die Einstellungen vom RB3011 übernommen, da im CAPSMAN unter Datapath ja auch die RB3011 Bridge verwendet wird, auf der das sowieso eingeschaltet ist.
Ich kann mir nicht erklären, warum bei den reinen WLAN-Playern die Gruppenbildung nicht funzt und im SonosNet oder im verkabelten NEtzt sauber läuft.
Danke und Gruß,
Spartacus
Please also mark the comments that contributed to the solution of the article
Content-ID: 574142
Url: https://administrator.de/contentid/574142
Printed on: November 11, 2024 at 10:11 o'clock
56 Comments
Latest comment
Was ist mit dem IGMP Snooping.
Sollte auf dem Switch natürlich immer aktiv sein. Inklusive des Queriers ! Ansonsten flutet der Switch und killt dir deine Performance.Muss das auf den lokalen Bridgen der cAPS auch aktiviert werden
Ja, das sollte zwingend so sein wenn MC im Netz ist. Gilt das gleiche wie für den Switch !Details zur Problematik von Multicasts in WLANs findest du hier:
https://www.heise.de/ct/ausgabe/2014-14-Probleme-bei-Multicast-im-W-LAN- ...
Das gilt dann offenbar für das MC nicht!
Richtig weil CapsMan ja nur WLAN spezifische Dinge als zentraler Controller bedient nicht aber grundlegende Netzwerk Parameter wie z.B. IGMP oder PIM usw. was heisst "inklusive des Queriers" in diesem Zusammenhang?
Der IGMP Querier sollte auch auf dem Switch aktiviert sein !würde dann die Kopplung als Stereopaar nicht mehr klappen.
Warum nicht ? Sofern sie sich im WLAN "sehen" erreichen sie sich doch auch ?!PIM muss ich dann mal installieren.
Musst du nur machen wenn du Multicast routen musst zwischen 2 oder mehr IP Netzen ! Sonst nicht. PIM spielt in gebridgten Umgebungen keinerlei Rolle.IGMP Querier heisst dann wohl soviel, wie IGMP Dienst
Nein !IGMP an sich ist der Dienst. Im IGMP kann man aber customizen wer der Querrier ist in einer L2 Domain. Das sollte immer der Switch sein. Möglich das man das in deiner HW nicht einstellen kann. Dann kaspern die das bei multiplen Querriern selber raus über die niedrigste Mac Adresse. Ist aber nicht ideal....
dass die Gruppeneinstellungen und Stereo-Paarbildungen zwingen MC benötigen.
Aber das ist doch vollkommen Latte in einem Layer 2 WLAN. Dort geht Multicast immer egal ob man IGMP oder was auch immer an oder aus hat.Ohne IGMP oder der Multicast zu Unicast Konvertierung im WLAN fluten die APs dann halt wie es auch billige Switches tun. Ist dann zwar nicht mehr performant aber bei Audio mit max. 128kiloBit spielt das in einem 20Mbit WLAN ja keine Rolle.
So oder so wird Multicast ach komplett ohne irgendwelches customizing übertragen. Muss es ja auch per Definition.
Anders sieht es beim Routing aus...da ist dann PIM Pflicht. Siehe hier:
UPNP mit Mikrotik Routerboard hEX PoE und D-Link DGS-1210-24 Switch
Du kannst das Multicast Verhalten auch ganz einfach selber auf Wasserdichtigkeit im LAN und WLAN testen mit einfachsten Bordmitteln:
Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)
Rennt hier in einem CapsMan WLAN mit billigen cAPs fehlerlos...und das mit Video !
Was häufig falsch gemacht wird sind die WLAN Settings im CapsMan. 20Mhz im 2,4Ghz und 40Mhz im 5Ghz.
Guckst du hier:
https://www.youtube.com/watch?v=JRbAqie1_AM
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Allerdings ist die Konfiguration etwas anders als von Dir im Tut beschrieben.
OK, danke für das Feedback. Ich werde das korrigieren !TTL kann ich hier nicht konfigurieren
Doch, das geht aber das muss man dann immer manuell in das angezeigte Kommando integrieren !Läuft das jetzt über MC, oder ist das nicht korrekt konfiguriert?
Wireshark ist wie immer dein bester Freund !!Wenn du 239.255.1.2 als Adresse gewählt hast kann es ja nur MC sein !
hat doch auch im 5GHz Band die Bandbreite auf 20MHz stehen
Control Channel ist NICHT gleich Extension Channel ! Ist bei MT etwas verwirrend.Aber vermutlich braucht mann dann den Erweiterungskanal Ce....
Bingo !Hier sprechen sie u.a. von WMM
Der Haken sollte natürlich zwingend immer gesetzt sein !Weißt Du, wo man das einstellt?
Im WLAN Profil unten !Sobald ein dritter Player beteiligt ist, tauchen die beschriebenen Probleme auf.
Bist du dir denn sicher das es bei solchem Fehlerbild wirklich an der Infrastruktur liegt ??Das hört sich eher nach einem Problem der Endgeräte an.
Im Grunde hast du alles richtig gemacht. Dein WLAN bridged ja immer in eine lokale VLAN Bridge sprich dieses VLAN in dem das Sonox WLAN arbeitet ist ja aus Layer 2 Sicht vollkommen transparent. Warum nimmst du da nichtmal einen Wireshark und checkst an einem Kupferport dieses VLANs mal ob dort die gesamte Multicast Kommunikation zu sehen ist.
Das geht aber nur wenn du IGMP Snooping deaktiviert hast in der Bridge, denn nur dann muss diese MC Pakete fluten. Ist natürlich etwas blöd, denn man aktiviert ja gerade IGMP um das Multicasting intelligent zu forwarden.
Ggf. ist es dann doch besser du arbeitets mit einem Mirror Port. Das hätte dann auch den großen Vorteil das du dir den gesamten Traffic eines der beteilgten APs ansehen kannst.
Hier kann man dann ja genau verfolgen wie die MC Pairing Kommunikation der Sonos abläuft und was da ggf. schief läuft.
Nicht mit local Forwading zu arbeiten würde ich als großen Nachteil einschätzen, denn dann müsste der gesamte Traffic encapsuliert und verschlüsselt werden und am CapsMan Controller wieder decapsuliert und entschlüsselt. Für Audio- und Video Daten ist sowas nie besonders gut und es erfordert erhebliche Resourcen in der Box.
Einen Versuch wäre es ggf. mal wert aber sollte eigentlich nichts bringen, eher im Gegenteil.
Nimmt man mal deine Symptome dann ist es ja so das 2 Geräte sauber funktionieren, 3 dann aber nicht mehr. Wenn hier gravierende MC Problematiken vorliegen würden, dann würde ja schon das Pairing von 2 Boxen sofort scheitern. Warum also erst bei 3 ? Es kann ja nicht sein das MC bei 2en sauber rennt aber wenn 3 im Netz sind nicht mehr. Das das ziemlich unlogisch und eher utopisch ist wirst du sicher auch annehmen.
Spannend wäre es wenn die 2 Boxen z.B. auf einem AP und die dritte auf einem anderen AP liegt. Das könnte dann ggf. auf einen Fehler im Bridging hindeuten aber auch dann wäre eine IP Connectivity zwischen diesen 2 APs auch gestört. Diese basiert immer auf einer L2 Erreichbarkeit.
Wie gesagt: Am besten Mirror Port und sich den AP Traffic der Sonos mal ansehen.
ich habe allerdings keine Ahnung davon und hoffe etwas auf Deine Hilfe
Das bitte unbedingt lesen dazu:https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
Als Source habe ich das VLAN 30 angegeben.
Nein, besser immer den physischen Port als Source angeben. Sonst bekommst du ALLES aus dem VLAN 30.Denk dran wenn dort Tagged Frames verwendetwerden das du das in deine Netzwerkkarte entsprechend aktivierst:
https://wiki.wireshark.org/CaptureSetup/VLAN
bzw.
https://www.intel.com/content/www/us/en/support/articles/000005498/netwo ...
Anders sieht es aus, wenn ich den Trunk Port des cAP mitschneiden wollte.
Richtig, da sollten dann in jedem Falle Tagged Frames zu sehen sein:unregisterd Multicast: alles auf Forwarding
Das ist richtig, das sind MC Adressen die der IGMP Prozess nicht registriert hat. Die sollte er dann fluten, ansonsten werden die unterdrückt was bei manchen Protokolle zu Fehlern führt z.B. bei Local Link MC Adressen.Nebenbei:
Multicast_Tutorial ist geupdatet !
ich habe festgestellt, das PIM bei mir nicht sauber läuft.
Das stimmt diese Fehlermeldungen sind nicht normal und deuten auf eine Problem hin !Was ist hier falsch konfiguriert? Ich verstehe das nicht!
Dein Kardinalsfehler springt einem förmlich ins Auge ! Komisch das du ihn übersehen hast...unverständlich ?!Der Rendezvous Point ist doch niemals eine Netzwerk Adresse !!! Wie soll das denn gehen ?? PIM braucht für den RP immer eine Host IP Adresse logischerweise. In der Regel ist das die Router LAN IP des Interfaces wo sich die MC Quelle befindet. Idealerweise eine Loopback Adresse da diese nicht auf Down gehen kann. Du aber hast hier unverständlicherweise eine Netzwerk Adresse eingetragen so das PIM niemals funktionieren kann. Das musst du also zwingend korrigieren.
ALLE beteiligten PIM Router bekommen diese RP IP Adresse eingetragen auch der der selber den RP hält !
Noch sinnvoller wäre es BSR zu aktivieren auf dem RP Router, dann distribuiert er den RP automatisch an alle beteiligten PIM Router und man müsste es nicht fehlerträchtig statisch machen. Das lohnt aber nur wenn man mehrere Router hat.
Das war es wohl.
👍Ja, Multicast als Fehlerquelle kann man dann zu 100% ausschliessen.
Das die Windows Controller die Player nicht finden ist komisch. Nur mal doof nachgefragt:
Am Cisco Switch hast du IGMPv2 oder v3 Snooping aktiviert ?? Das wäre zwingend nötig.
Da hast du aber 4 Optionen um das mal genau zu testen:
- IGMPv2 Snooping aktiv ohne Switch als Querrier
- IGMPv2 Snooping aktiv mit Switch als Querrier
- IGMPv3 Snooping aktiv ohne Switch als Querrier
- IGMPv3 Snooping aktiv mit Switch als Querrier
Die Sonos Dienste teilen sich ja nach Sniffer Trace mit einem routebaren SSDP auf Multicast Basis mit 239.255.x.y Gruppe mit TTL=4. Der PIM Router müsste diese Gruppe sehen und fest im Cache haben.
Man müsste die SSDP Frames auch in beiden Segmenten sniffern können. Wenn ja werden dort die Dienste in den Paket Inhalten auch angezeigt. Dann würde man wieder die Winblows Firewall vermuten. Hast du die testhalber mal deaktiviert ?
Es ist vollkommen unlogisch das die Android Controller fehlerlos laufen die von Winblows aber nicht. Man sollte ja erwarten das beide die gleichen Protokoll Mechanismen nutzen. Im ersten Ansatz bleibt da dann nur der lokale Firewall Verdacht...
Denn das Controller->Player Issue liegt definitiv an den verschiedenen Subnetzen..
Aber du sagts doch ein Androiden Controll arbeitet fehlerfrei über die Subnetze ??Sniffern wäre am besten.... Einmal aufzeichnen wie die Kommunikation im Layer 2 aussieht wo es klappt und einmal über die Subnetze wo es scheitert.
Dann kann man genau sehen was da ankommt und was nicht und was der genaue Grund ist.
Für mich sieht es im Moment leider so aus, als läge das Problem bei Sonos
Nach deinen Beschreibungen zu urteilen sieht das in der Tat sehr danach aus. LAN Gruppierung geht aber WLAN nicht, was eigentlich nicht sein kann und eher auf Firmware Problematiken schliessen lässt.allerdings weiß ich nicht was da die richtige Einstellung ist.Aktuell sieht es so aus:
Mac Group ist definitiv falsch. Wenn müsste es bei v4 und v6 immer die IP Group sein.Hier mal die Einstellung für ein IP VLAN mit Magenta TV (Telekom D, IP-TV). Die machen v3 und SSM deshalb gilt das für dich nicht aber relevant sind die IP Gruppenadressen !
Die entsprechenden MC IP Gruppenadressen werden dann auch angezeigt:
Diese Einstellungen müssen für ALLE VLANs in denen MC geroutet wird entsprechend so gesetzt werden !
v3 ist eigentlich abwärtskompatibel zu v2. Ich würde aber empfehlen sofern du kein Telekom D IP-TV Kunde bist das du die Version auf v2 belässt.
Alle Apple Produkte supporten derzeit kein v3 und da kann es dann zu Problemen kommen. Deshalb fährst du sicherer mit v3.
Ob MT auch v3 macht weiss ich nicht. Man müsste sich mal die Querrier Frames mit dem Wireshark ansehen dafür.
Normal geht aber an so einem Port die Version automatisch auf die kleinste Version.
Alle Apple Produkte supporten derzeit kein v3 und da kann es dann zu Problemen kommen. Deshalb fährst du sicherer mit v3.
Ob MT auch v3 macht weiss ich nicht. Man müsste sich mal die Querrier Frames mit dem Wireshark ansehen dafür.
Normal geht aber an so einem Port die Version automatisch auf die kleinste Version.
Wenn das stimmt, dann hat der Kollege Recht. Dann benötigt man einen UDP Helper der diese Broadcasts forwardet.
Sieh mal in deinen Wireshark Trace !! Da war recht intensiever SSDP Traffic und ich habe mir jetzt nicht jeden Frame einzeln angesehen.
Wenn da auch ein normaler Broadcast unter den Multicasts dabei ist dann wars das !
Sieh mal in deinen Wireshark Trace !! Da war recht intensiever SSDP Traffic und ich habe mir jetzt nicht jeden Frame einzeln angesehen.
Wenn da auch ein normaler Broadcast unter den Multicasts dabei ist dann wars das !
Für UDP 67/68 (DHCP) kann er das:
https://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Relay
Normal kann man die UDP Ports frei definieren im Relay und auch andere eintragen. Ob das aber bei MT auch möglich ist müsste ich auch nachlesen.
Wenn ja und diese wirklich relevant für die Connectivity ist dann ist sie das. Der .30.198 Client sendet sie ja aber parallel auch noch als Multicast. Er macht also nach Sonos Beschreibung genau das was er soll und fährt zweigleisig um sicherzugehen das es auch im L3 klappt, also einmal lokal und einmal routebar.
Wenn der Client aber rein nur mit den Broadcasts umgehen kann dann hat dieser ein Problem in einem L3 Umfeld und man müsste dann mit einem UDP Helper den SSDP Port forwarden.
https://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Relay
Normal kann man die UDP Ports frei definieren im Relay und auch andere eintragen. Ob das aber bei MT auch möglich ist müsste ich auch nachlesen.
Ich denke, das ist die Stelle, die hier Kummer macht!
Du meinst den SSDP Broadcast an die All Net IP 255.255.255.255 ??Wenn ja und diese wirklich relevant für die Connectivity ist dann ist sie das. Der .30.198 Client sendet sie ja aber parallel auch noch als Multicast. Er macht also nach Sonos Beschreibung genau das was er soll und fährt zweigleisig um sicherzugehen das es auch im L3 klappt, also einmal lokal und einmal routebar.
Wenn der Client aber rein nur mit den Broadcasts umgehen kann dann hat dieser ein Problem in einem L3 Umfeld und man müsste dann mit einem UDP Helper den SSDP Port forwarden.
Ethertype 0x6970 ist ein Sonos proprietäres Ethernet Format:
http://www.freepatentsonline.com/y2016/0006778.html
Wenn du dort nach "6970" suchst wird das auch recht detailiert dort erklärt wie die Kommunikation abläuft.
http://www.freepatentsonline.com/y2016/0006778.html
Wenn du dort nach "6970" suchst wird das auch recht detailiert dort erklärt wie die Kommunikation abläuft.
das 6970 für die Gruppenbildung verantwortlich ist.
Sofern die dafür keinen Link Local Adrese utzen, was ja nach Trace nicht der Fall ist, und auch das TTP größer 1 ist, was ja auch der Fall ist mit 4, sollte das also mit PIM auch über Routergrenzen routebar sein sofern Sonos hier den MC Standard mit IGMP Kommunikation einhält was vermutlich der Fall ist. Also Haken dran..Nützt aber nur nix wie du schon richtig sagst, denn die Gruppenbildung klappt ja.
Das andere ist die Broadcast Problematik die so natürlich nicht in unterschiedliche IP Netze geht. MT supportet keinen frei konfigurierbaren UDP Helper so das es ohne das Feature aussichtslos ist diese Broadcasts mit der MT Hardware forzuwarden.
Schlüsselfrage bleibt dann ob die Broadcatst wirklich relevant sind ??
Das kann vermutlich nur ein SONOS Techniker beantworten.
Die Regel ist m.E. falsch wenn Sonos tatsächlich dynamische Multicast Gruppenadressen verwendet, denn so lässt du rein nur die Gruppe durch. Das ist in 2 Gründen fatal, denn die ganzen MC IGMP Kontrollpakete die auch auf Gruppenadressen basieren kommen so nicht mehr durch und zudem limitierst du die Sonos Kommunikation rein nur auf diese Gruppe. Neue dynamische Adressen haben dann keine Chance...
Wenn, dann solltest du den gesamten MC Bereich mit 224.0.0.0/4 passieren lassen. Noch besser: Gar keine Filter Regeln für MC implementieren gerade wenn man mit unbekannten MC Protokollen testet.
Hier findest du noch etwas zum Verhalten von WLAN APs bei Multicast:
https://en.wikipedia.org/wiki/IP_multicast#Layer_2_delivery
Was an dem o.a. Trace sehr verwundert ist das da komplett die IGMP Join Messages fehlen, die aber essentiell sind für eine Multicast Kommunikation in einem Layer 2 Umfeld wo IGMP Snooping aktiv ist.
https://www.tldp.org/HOWTO/Multicast-HOWTO-2.html
Ohne eine solche IGMP Join Message kann der Switch die MC Gruppenadresse nicht registrieren und würde sog. "Unregistered Multicast" blocken. Bzw. der Switch behandelt ihn dann nach dem was man ihm mit Unregistered Multicast gesagt hat was er damit machen soll. Filtern (Drop) oder forwarden.
Eigentlich müsste der Sonos zwingen ein IGMP Join schicken wenn man ihn anschaltet wenn er sich Standard konform verhalten soll.
Wenn, dann solltest du den gesamten MC Bereich mit 224.0.0.0/4 passieren lassen. Noch besser: Gar keine Filter Regeln für MC implementieren gerade wenn man mit unbekannten MC Protokollen testet.
Hier findest du noch etwas zum Verhalten von WLAN APs bei Multicast:
https://en.wikipedia.org/wiki/IP_multicast#Layer_2_delivery
Was an dem o.a. Trace sehr verwundert ist das da komplett die IGMP Join Messages fehlen, die aber essentiell sind für eine Multicast Kommunikation in einem Layer 2 Umfeld wo IGMP Snooping aktiv ist.
https://www.tldp.org/HOWTO/Multicast-HOWTO-2.html
Ohne eine solche IGMP Join Message kann der Switch die MC Gruppenadresse nicht registrieren und würde sog. "Unregistered Multicast" blocken. Bzw. der Switch behandelt ihn dann nach dem was man ihm mit Unregistered Multicast gesagt hat was er damit machen soll. Filtern (Drop) oder forwarden.
Eigentlich müsste der Sonos zwingen ein IGMP Join schicken wenn man ihn anschaltet wenn er sich Standard konform verhalten soll.
Kann es sein das im VLAN 10 gar kein MC Traffic ist ? Dann würde ja auch nichts outgoing angezeigt werden. Normal musst du da nix einstellen, PIM aktivieren und Rendezvous IP zentral festlegen, fertisch. Mehr muss man nicht machen. Den Rest erledigt IGMP.
Was du mal machen kannst ist die Querrier Funktion auf dem Cisco deaktivieren und das nur den Mikrotik machen zu lassen. Bei aktivem PIM ist ein Querrier immer Default, deshalb kannman es im MT mit aktiviertem PIM nicht abstellen. Man kan es also nur in eine Richtung testen.
Aber auch den direkten PC Test am MT solltest du auch zusätzlich nochmal machen.
Vielleicht ist der Cisco hier noch der Übeltäter?
Generell sicherlich nicht aber ich habe in einigen Netzen festgestellt das es nicht trivial ist wer der Querrier im Netz ist. Bei den SG Modellen war es oft so das wenn er auch Querrier war plus eines Routers im Netz manchmal die IGMP Kommunikation stockt und es nicht zu einem IGMP Forwarding kam. Wenn es zwei Querrier in einem Segment gibt müssen die sich einigen. IGMP Standard sieht dann vor das die Mac Adresse der Tie Break ist was aber oft nicht implementiert ist bei einigen Herstellern und dann zu Chaos führt.Was du mal machen kannst ist die Querrier Funktion auf dem Cisco deaktivieren und das nur den Mikrotik machen zu lassen. Bei aktivem PIM ist ein Querrier immer Default, deshalb kannman es im MT mit aktiviertem PIM nicht abstellen. Man kan es also nur in eine Richtung testen.
Aber auch den direkten PC Test am MT solltest du auch zusätzlich nochmal machen.
Ich habe den Eindruck,MC Routing läuft nur von VLAn30 in VLAN 10, aber nicht umgekehrt
Das kannst du ja mit der "Big Buck Bunny" Test Methode mit VLC oder dem "MC Hammer" Test Tool schnell mal verifizieren.Packe einmal die Source (Sender) in VLAN 30 und den Client in VLAN 10 und einmal umgedreht Client in 30 und Sender in 10.
Wenns nicht geht stimmt deine Theorie !
puuh! Ich glaube ich gebe so langsam auf. VLC läuft weder von VLAN10->VLAN30 noch vom VLAN30->VLAN10. Geht irgendwie gar nix mehr!
Ooops...ja dann muss man sich nicht wundern das nix geht mit MC. Ist aber schon komisch. Klingt blöd aber hast du den Router mal rebootet ? Just in case das der sich irgendwie verschluckt hat mit dem PIM Routing.
Ich habs hier gerade mal an einem RB2011 probiert mit 5 VLANs. Da klappt das PIM Routing egal in welche Richtung und von welchem VLAN zu welchem mit dem Big Buck Bunny Test völlig fehlerfrei. Ich kann den Client bei laufendem Stream sogar einfach umklemmen. Sowie Spanning Tree den Port in den Forwarding Modus bringt ist der Stream da...
Da müsste doch die 239.255.1.2 kommen, oder?
Richtig wenn das deine Film Gruppenaddresse ist und die NICHT mit anderen Adressen kollidiert.Irgendwie habe ich den Verdacht, die Sonos Büchsen hauen dazwischen.
Das können sie eigentlich nicht sofern sie eine eigene MC Gruppenadresse nutzen und es keinerlei Überschneidungen gibt wovon wir mal nicht ausgehen.Versuchs mal mit einem Reboot. Zur Not kann ich auch nochmal einen Trace hier ziehen...
Ich habe jetzt offenbar auch noch ein Firewall Problem.
Warum machst du dir das Leben so schwer ?? Deaktiviere doch erstmal komplett die FW wärend der testphase. Das schafft doch nur ungeahnte weitere Probleme und man muss dann immer rätseln, Firewal, Konfig Fehler oder Bug.Der MT ist doch erstmal nur intern und da kannst du die Regeln ja testweise mal weglassen.
MC wird nur geroutet, wenn ich die Dst-Adresse 239.255.255.250 / 239.255.1.2 explizit in eine separate Forward Regel
Hatte ich auch schon geschrieben. Besser ist hier keine Regel, siehe oben ! Oder wenn das die gesamte Range 224.0.0.0/4 durchzulassen !!! Vergiss nicht das du damit auch funktionale MC Adressen filterst fürs PIM. Das ist extrem kontraproduktiv beim Troubleshooting ! Lass es am besten AUS für die Testphase. Daher kommen diese verrückten Verhaltensweisen.Ich glaub ich muss hier mal einen neuen Router kaufen
Das wäre das Sinnigste !!Ein kleiner hAP lite für 20 Euronen reicht völlig aus um das vorab wasserdicht zu testen und dann aufs Live System zu migrieren !!
https://www.varia-store.com/de/produkt/33635-mikrotik-routerboard-rb941- ...
Erheblich stressfreier und kostet weniger graue Haare !!
Irgendeine Idee, wo man gucken kann?
Spaßeshalber kannst du ja mal IGMP Snooping deaktivieren. Dann flutet der Cisco MC wie ein doofer ungemanagter Switch.Wenns dann klappt weisst du das du irgendwas falsch eingestellt hast mit dem IGMP Snopping.
Hier ist es so eingestellt und damit rennt es bidirektional fehlerlos (Latest und greatest Firmware auf dem SG):
Obiges für alle VLANs gleich setzen !!
Nochwas...
Hast du auch IGMP Snooping in der VLAN Bridge des Mikrotik aktiviert ? Das sollte man natürlich auch machen.
Ich habe keine einzige Einstellung verändert. Nur die Rechner gebootet.
Ja ja...das sagen sie alle hinterher... Meinst Du für alle VLANS, oder nur für die VLANS, die MC machen sollen?
Ja, natürlich nur für die VLANs in denen IGMP Snooping aktiviert ist. Sinnvollerweise aktiviert am das aber generell in allen VLANs. Etwas MC gibt es überall und das will man ja nicht Performance verschwenderisch fluten ! Hier identisch einstellen, oder den Querier ausschalten?
Identisch, den Querrier kaspern die automatisch aus.Hast du auch IGMP Snooping in der VLAN Bridge des Mikrotik aktiviert ?! Solltest du da auch tun !