56
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 574142
Url: https://administrator.de/contentid/574142
Ausgedruckt am: 23.11.2024 um 12:11 Uhr
56 Kommentare
Neuester Kommentar
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- ...
Moin aqui,
ich hatte geglaubt durch die CAPSMAN-Steuerung müsste man lokal an den cAPS nix mehr einstellen. Das gilt dann offenbar für das MC nicht! Ich werde es dann lokal auf den cAPs mal aktivieren.
Wenn ich das nicht in den Griff kriege, werde ich wohl mit künftigen Sonos-Geräten Probleme haben, denn die haben kein SonosNet mehr. Aktuell ist das bei mir der Sonos Move, der nur noch das konventionelle WLAN nutzt. Und bei 2 Geräten dieses Typs würde dann die Kopplung als Stereopaar nicht mehr klappen. Das wäre echt doof, wo ich doch so viel Arbeit in meine Netzwerkkonfiguration gesteckt habe
kann ich nicht lesen, gilt offenbar nur für Abonnenten der ct
Gruß,
Spartacus
ich hatte geglaubt durch die CAPSMAN-Steuerung müsste man lokal an den cAPS nix mehr einstellen. Das gilt dann offenbar für das MC nicht! Ich werde es dann lokal auf den cAPs mal aktivieren.
Wenn ich das nicht in den Griff kriege, werde ich wohl mit künftigen Sonos-Geräten Probleme haben, denn die haben kein SonosNet mehr. Aktuell ist das bei mir der Sonos Move, der nur noch das konventionelle WLAN nutzt. Und bei 2 Geräten dieses Typs würde dann die Kopplung als Stereopaar nicht mehr klappen. Das wäre echt doof, wo ich doch so viel Arbeit in meine Netzwerkkonfiguration gesteckt habe
Sollte auf dem Switch natürlich immer aktiv sein. Inklusive des Queriers ! Ansonsten flutet der Switch und killt dir deine Performance.
was heisst "inklusive des Queriers" in diesem Zusammenhang?kann ich nicht lesen, gilt offenbar nur für Abonnenten der ct
Gruß,
Spartacus
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 ?!
Hi,
ok. d.h. ich muss die ganzen MC Einstellungen inkl. PIM auch lokal auf den cAPs konfigurieren. Das habe ich natürlich nicht gemacht. IGMP ist inzwischen eingeschaltet; hat aber nix gebracht. PIM muss ich dann mal installieren. Die FW-Regeln brauche ich auf den cAPs aber nicht, richtig? Das läuft ja nachweislich alles über den Router. Und momentan gibt es für das SonosVLAN sowieso keine FW Regeln. Da ist alles auf Durchzug geschaltet um
IGMP Querier heisst dann wohl soviel, wie IGMP Dienst. Auf dem CISCO sollte IGMP aktiv sein. Das schaue ich auch noch mal nach, meine aber ich hätte das damals schon eingerichtet.
Der Sonos Support hat mir gesagt, dass die Gruppeneinstellungen und Stereo-Paarbildungen zwingen MC benötigen. Und er konnte in meinem Diagnose-File sehen, dass dies das Problem ist. Nachdem ich einen der 3 Player ans Kabel (Cisco switch) angeschlossen hatte, ging es, denn
- der kabelgebundene Player hat dann ein separates SonosNet aufgespannt
- den zweiten Stereo Kanal 2te. Player über das SonosNet eingebunden
- den Move über WLAN in die Stereogruppe eingebunden.
NACHTRAG:
Habe PIM auf dem cAP installiert. Aber wer ist denn dann mein RP? Die VLANs sieht doch der cAP gar nicht!
NACHTRAG 2:
aqui, ich habe den eindruck die Multicast Einstellungen am cAP werden ignoriert. Habe als RP nun verschieden Subnetzte konfiguriert, aber es werden keine aktive Gruppen angezeigt, so wie es auf dem Router der fall ist.
Danke Dir,
Spartacus
ok. d.h. ich muss die ganzen MC Einstellungen inkl. PIM auch lokal auf den cAPs konfigurieren. Das habe ich natürlich nicht gemacht. IGMP ist inzwischen eingeschaltet; hat aber nix gebracht. PIM muss ich dann mal installieren. Die FW-Regeln brauche ich auf den cAPs aber nicht, richtig? Das läuft ja nachweislich alles über den Router. Und momentan gibt es für das SonosVLAN sowieso keine FW Regeln. Da ist alles auf Durchzug geschaltet um
IGMP Querier heisst dann wohl soviel, wie IGMP Dienst. Auf dem CISCO sollte IGMP aktiv sein. Das schaue ich auch noch mal nach, meine aber ich hätte das damals schon eingerichtet.
Der Sonos Support hat mir gesagt, dass die Gruppeneinstellungen und Stereo-Paarbildungen zwingen MC benötigen. Und er konnte in meinem Diagnose-File sehen, dass dies das Problem ist. Nachdem ich einen der 3 Player ans Kabel (Cisco switch) angeschlossen hatte, ging es, denn
- der kabelgebundene Player hat dann ein separates SonosNet aufgespannt
- den zweiten Stereo Kanal 2te. Player über das SonosNet eingebunden
- den Move über WLAN in die Stereogruppe eingebunden.
NACHTRAG:
Habe PIM auf dem cAP installiert. Aber wer ist denn dann mein RP? Die VLANs sieht doch der cAP gar nicht!
NACHTRAG 2:
aqui, ich habe den eindruck die Multicast Einstellungen am cAP werden ignoriert. Habe als RP nun verschieden Subnetzte konfiguriert, aber es werden keine aktive Gruppen angezeigt, so wie es auf dem Router der fall ist.
Danke Dir,
Spartacus
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
Hi aqui,
danke für Deine Hilfe. Ich habe mir den neusten VLC unter Windows geladen und versucht ihn zu konfigurieren. Allerdings ist die Konfiguration etwas anders als von Dir im Tut beschrieben. TTL kann ich hier nicht konfigurieren und RTP Multicast gibt es als Streaming Methode nicht, wie Du im nachstehenden Bild 1 sehen kannst. Daher habe ich RTP Transportstream gewählt. Ich glaube dass dies nicht korrekt ist.
Als Adresse habe ich die 239.255.1.2 gewählt (Bild 2).
Bild 1
Bild 2
Bild 3
Der Streaming Server befindet sich in meinem WLAN im VLAN10, der Client ebenfalls im VLAN10. Also im Prinzip wie die Sonos Kisten beide im selben VLAN, der Server im WLAN, der Client per kabel an dem Cisco.
Wenn ich nun am Client auf "Netztwerktreams" klicke, wird mir direkt der am VLC-Server angelegte Stream angeboten.
Da der Client im 2,4 GHz Band hängt ist die Übertragung nicht ruckelfrei, aber sie läuft.
Läuft das jetzt über MC, oder ist das nicht korrekt konfiguriert?
NACHTRAG:
ich habe mir gestern noch die Präsentation auf youtube angesehen. Ich denke, da ist bei mir noch "room for improvement" . Zumindst im 5GHz Band könnte man noch einige Dinge anpassen. Die 40MHz kann ich aber nicht nachvollziehen. Der Kollege hat doch auch im 5GHz Band die Bandbreite auf 20MHz stehen. Setelle ich 40 MHz ein, klappt das nicht. Aber vermutlich braucht mann dann den Erweiterungskanal Ce....Egal, das schaue ich mir noch mal an.
Allerdings ändert das nicht an meinem Problem. Ich habe gestern noch einen Beitrag gefunden.
Capsman & Sonos. Hier sprechen sie u.a. von WMM. Diese Einstellung finde ich aber nicht im CAPSMAN bzw. in den cAPs. Weißt Du, wo man das einstellt?
Die "mangle" - Rule habe ich auf dem Router mal eingebaut. Gefühlt scheint die Controller App nun schneller zu reagieren. Auf den cAPs muss ich das noch einbauen. Ob das mein Gruppen-Problem löst, glaub ich noch nicht.
Danke dir,
Christian
danke für Deine Hilfe. Ich habe mir den neusten VLC unter Windows geladen und versucht ihn zu konfigurieren. Allerdings ist die Konfiguration etwas anders als von Dir im Tut beschrieben. TTL kann ich hier nicht konfigurieren und RTP Multicast gibt es als Streaming Methode nicht, wie Du im nachstehenden Bild 1 sehen kannst. Daher habe ich RTP Transportstream gewählt. Ich glaube dass dies nicht korrekt ist.
Als Adresse habe ich die 239.255.1.2 gewählt (Bild 2).
Bild 1
Bild 2
Bild 3
Der Streaming Server befindet sich in meinem WLAN im VLAN10, der Client ebenfalls im VLAN10. Also im Prinzip wie die Sonos Kisten beide im selben VLAN, der Server im WLAN, der Client per kabel an dem Cisco.
Wenn ich nun am Client auf "Netztwerktreams" klicke, wird mir direkt der am VLC-Server angelegte Stream angeboten.
Da der Client im 2,4 GHz Band hängt ist die Übertragung nicht ruckelfrei, aber sie läuft.
Läuft das jetzt über MC, oder ist das nicht korrekt konfiguriert?
NACHTRAG:
ich habe mir gestern noch die Präsentation auf youtube angesehen. Ich denke, da ist bei mir noch "room for improvement" . Zumindst im 5GHz Band könnte man noch einige Dinge anpassen. Die 40MHz kann ich aber nicht nachvollziehen. Der Kollege hat doch auch im 5GHz Band die Bandbreite auf 20MHz stehen. Setelle ich 40 MHz ein, klappt das nicht. Aber vermutlich braucht mann dann den Erweiterungskanal Ce....Egal, das schaue ich mir noch mal an.
Allerdings ändert das nicht an meinem Problem. Ich habe gestern noch einen Beitrag gefunden.
Capsman & Sonos. Hier sprechen sie u.a. von WMM. Diese Einstellung finde ich aber nicht im CAPSMAN bzw. in den cAPs. Weißt Du, wo man das einstellt?
Die "mangle" - Rule habe ich auf dem Router mal eingebaut. Gefühlt scheint die Controller App nun schneller zu reagieren. Auf den cAPs muss ich das noch einbauen. Ob das mein Gruppen-Problem löst, glaub ich noch nicht.
Danke dir,
Christian
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 !
Moin,
danke Dir! Den WMM Haken finde ich im CAPSMAN nicht.
Christian
danke Dir! Den WMM Haken finde ich im CAPSMAN nicht.
Christian
Hallo,
ich habe mich jetzt gestern einen ganzen Tag mit diesem Thema beschäftigt, konnte das Problem aber leider nicht lösen.
Mir ist immer noch nicht klar, was genau hier schief geht.
Ich habe allerdings Folgendes herausgefunden:
Zwei WLAN-Player lassen sich problemlos als Stereopaar koppeln, oder in eine Gruppe schieben. Sobald ein dritter Player beteiligt ist, tauchen die beschriebenen Probleme auf.
Verkabelt man einen Player, so können auch mehrere Player oder Stereopaare als Gruppe zusammengefasst werden.
Ich habe dazu in diversen Beiträgen gelesen, dass dieses Problem in Zusammenhang mit AVM Repeatern bekannt ist, da die Repeater Multicast-Traffic blockieren. Im AP Mode ist das bisher nicht bekannt.
Da ich meine Miktotik cAPs AC als APs betreibe, die alle mit 1GBit LAN angebunden sind, kann es daran eigentlich nicht liegen. M.E. ist auch das WMM im CAPSMAN Betrieb aktiviert. Einen separaten Schalter zum Aktivieren gibt es offenbar nicht mehr.
Im Datapath des CAPSMAN habe ich Client to Client Forwarding und Local Forwarding aktiviert. Ich habe den Verdacht, dass das Problem an dieser Stelle zu suchen ist und hier ggf. Pakete blockiert werden, die die Player benötigen, vor Allem, wenn Player an verschiedenen APs angemeldet sind.
Da das Forwarding ja lokal auf den cAPs erfolgt, kann es denn sein, dass hier auf den cAPS noch etwas konfiguriert werden muss? Die Sache mit der WMM Priorisierung bringt auf jeden Fall eine ganze Menge. Die SONOS App läuft jetzt viel flüssiger und die Ansteuerung der Player ist fixer geworden. Vielleicht muss man auch das Local Forwarding mal abschalten. Wenn ich es richtig verstehe, läuft dann der gesamte Traffic über den Router.
Ich bin etwas ratlos und habe auch keine richtige Idee, wie man hier mit Wireshark etwas herausfinden kann, da ich überhaupt nicht weiß, wo und vor allem wie ich suchen soll. Vielleicht hat noch jemand eine zündelnde Idee, der Sache auf die Spur zu kommen.
Die Vereitlung der WLAN Kanäle und Frequenzen habe ich wie in der youtube Präsentation beschrieben, vorgenommen.
Spartacus
ich habe mich jetzt gestern einen ganzen Tag mit diesem Thema beschäftigt, konnte das Problem aber leider nicht lösen.
Mir ist immer noch nicht klar, was genau hier schief geht.
Ich habe allerdings Folgendes herausgefunden:
Zwei WLAN-Player lassen sich problemlos als Stereopaar koppeln, oder in eine Gruppe schieben. Sobald ein dritter Player beteiligt ist, tauchen die beschriebenen Probleme auf.
Verkabelt man einen Player, so können auch mehrere Player oder Stereopaare als Gruppe zusammengefasst werden.
Ich habe dazu in diversen Beiträgen gelesen, dass dieses Problem in Zusammenhang mit AVM Repeatern bekannt ist, da die Repeater Multicast-Traffic blockieren. Im AP Mode ist das bisher nicht bekannt.
Da ich meine Miktotik cAPs AC als APs betreibe, die alle mit 1GBit LAN angebunden sind, kann es daran eigentlich nicht liegen. M.E. ist auch das WMM im CAPSMAN Betrieb aktiviert. Einen separaten Schalter zum Aktivieren gibt es offenbar nicht mehr.
Im Datapath des CAPSMAN habe ich Client to Client Forwarding und Local Forwarding aktiviert. Ich habe den Verdacht, dass das Problem an dieser Stelle zu suchen ist und hier ggf. Pakete blockiert werden, die die Player benötigen, vor Allem, wenn Player an verschiedenen APs angemeldet sind.
Da das Forwarding ja lokal auf den cAPs erfolgt, kann es denn sein, dass hier auf den cAPS noch etwas konfiguriert werden muss? Die Sache mit der WMM Priorisierung bringt auf jeden Fall eine ganze Menge. Die SONOS App läuft jetzt viel flüssiger und die Ansteuerung der Player ist fixer geworden. Vielleicht muss man auch das Local Forwarding mal abschalten. Wenn ich es richtig verstehe, läuft dann der gesamte Traffic über den Router.
Ich bin etwas ratlos und habe auch keine richtige Idee, wie man hier mit Wireshark etwas herausfinden kann, da ich überhaupt nicht weiß, wo und vor allem wie ich suchen soll. Vielleicht hat noch jemand eine zündelnde Idee, der Sache auf die Spur zu kommen.
Die Vereitlung der WLAN Kanäle und Frequenzen habe ich wie in der youtube Präsentation beschrieben, vorgenommen.
Spartacus
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.
Hallo aqui,
danke für Dein Feedback. Ich habe das Stereopaar mal räumlich getrennt, sodass der eine Kanal auf AP00(Keller) und der 2. Kanal auf AP04 (Gartenhaus) eingeloggt war. Das hat sauber geklappt. Beide Player haben die Mucke perfekt abgespielt.
Ich werde mal das VLAN30 auf einen Mirror Port am Cisco Switch legen. Vielleicht kann man das auch auf dem RB3011 einstellen. Muss ich mir mal ansehen. Ich werden das mal aufbauen und den Wireshark laufen lassen....ich habe allerdings keine Ahnung davon und hoffe etwas auf Deine Hilfe
Danke und Gruß,
Spartacus
danke für Dein Feedback. Ich habe das Stereopaar mal räumlich getrennt, sodass der eine Kanal auf AP00(Keller) und der 2. Kanal auf AP04 (Gartenhaus) eingeloggt war. Das hat sauber geklappt. Beide Player haben die Mucke perfekt abgespielt.
Ich werde mal das VLAN30 auf einen Mirror Port am Cisco Switch legen. Vielleicht kann man das auch auf dem RB3011 einstellen. Muss ich mir mal ansehen. Ich werden das mal aufbauen und den Wireshark laufen lassen....ich habe allerdings keine Ahnung davon und hoffe etwas auf Deine Hilfe
Danke und Gruß,
Spartacus
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
Moin,
irgendwie scheint mein SG350x kein Port /VLAN Mirroring zu unterstützen. Der Menüpunkt fehlt im Administrator Menü. Bin etwas ratlos. Konfiguration ist auf "advanced". Irgendeine Idee?
Spartacus
irgendwie scheint mein SG350x kein Port /VLAN Mirroring zu unterstützen. Der Menüpunkt fehlt im Administrator Menü. Bin etwas ratlos. Konfiguration ist auf "advanced". Irgendeine Idee?
Spartacus
Gewusst wo...
Ist unter "Status and Statistics" und dort unter SPAN !
Ist unter "Status and Statistics" und dort unter SPAN !
Hi,
ich denke, das Ganze läuft über RSPAN bin mir aber nicht sicher, ob ich es richtig konfiguriert habe.
Als Source habe ich das VLAN 30 angegeben.
Und dann soll er den Traffic auf Port 1 spiegeln.
Destination:
Stimmt das so?
Spartacus
ich denke, das Ganze läuft über RSPAN bin mir aber nicht sicher, ob ich es richtig konfiguriert habe.
Als Source habe ich das VLAN 30 angegeben.
Und dann soll er den Traffic auf Port 1 spiegeln.
Destination:
Stimmt das so?
Spartacus
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 ...
Hi,
danke Dir! Wenn ich direkt an einem verkabelten Port abhöre, ist hier nichts getagged. Anders sieht es aus, wenn ich den Trunk Port des cAP mitschneiden wollte. Wo muss ich denn überhaupt mitschneiden, wenn ich die Kommunikation zwischen den WLAN Playern abhören will?
And btw.
Habe hier im SG350 noch dieses Menü gefunden. Hier steht für VLAN 30 (Sonos VLAN)
ist hier ggf. auch noch was zu beachten? An XG2 hängt per Glasfaser der RB3011
Gruß,
Spartacus
danke Dir! Wenn ich direkt an einem verkabelten Port abhöre, ist hier nichts getagged. Anders sieht es aus, wenn ich den Trunk Port des cAP mitschneiden wollte. Wo muss ich denn überhaupt mitschneiden, wenn ich die Kommunikation zwischen den WLAN Playern abhören will?
And btw.
Habe hier im SG350 noch dieses Menü gefunden. Hier steht für VLAN 30 (Sonos VLAN)
- Multicast Router Port: nur der XG2 auf "static"
- Forward all: alles auf "none"
- unregisterd Multicast: alles auf Forwarding
ist hier ggf. auch noch was zu beachten? An XG2 hängt per Glasfaser der RB3011
Gruß,
Spartacus
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 !
Hi
ich habe festgestellt, das PIM bei mir nicht sauber läuft.
Im Log sehe ich Folgende Einträge:
PIM Interface ist wie folgt für VLAN 10 und VLAN30 konfiguriert:
(VLAN10, SONOS Controller, 172.16.10.x; VLAN30, SONOS Player, 172.16.30.x)
PIM-RP:
Was ist hier falsch konfiguriert? Ich verstehe das nicht!
ich habe festgestellt, das PIM bei mir nicht sauber läuft.
Im Log sehe ich Folgende Einträge:
PIM Interface ist wie folgt für VLAN 10 und VLAN30 konfiguriert:
(VLAN10, SONOS Controller, 172.16.10.x; VLAN30, SONOS Player, 172.16.30.x)
PIM-RP:
Was ist hier falsch konfiguriert? Ich verstehe das nicht!
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 !
Hallo aqui,
ja, danke für den Hinweis, aber durch das "Rumprobieren" hat sich da der Fehler eingeschlichen. Das war es aber nicht.
Offenbar gab es Probleme mit dem Multicast Paket auf dem Router. In irgendeinem Beitrag stand so im Nebensatz, dass man das Paket mal deinstallieren soll; Router neu starten; Paket neu installieren und dann wäre alles gut.
Das habe ich gemacht und siehe da, MC wird geroutet. Auch der ultimative VLC test läuft perfekt; auch wenn die Clients an den Ports des Cisco SG350 hängen. Das war es wohl.
Allerdings löst das funktionierende MC die Sonos-Problematik nicht!
Zur Erinnerung:
Ich denke, hier braucht es neue Ideen!
Spartacus
ja, danke für den Hinweis, aber durch das "Rumprobieren" hat sich da der Fehler eingeschlichen. Das war es aber nicht.
Offenbar gab es Probleme mit dem Multicast Paket auf dem Router. In irgendeinem Beitrag stand so im Nebensatz, dass man das Paket mal deinstallieren soll; Router neu starten; Paket neu installieren und dann wäre alles gut.
Das habe ich gemacht und siehe da, MC wird geroutet. Auch der ultimative VLC test läuft perfekt; auch wenn die Clients an den Ports des Cisco SG350 hängen. Das war es wohl.
Allerdings löst das funktionierende MC die Sonos-Problematik nicht!
Zur Erinnerung:
- Es lassen sich nur max. 2 WLAN Player koppeln (Stereopaar oder Gruppe)
- Windows-Controller (per Kabel am Cisco) finden die SONOS Player nur, wenn sie im selben Subnetz sindIch denke, wie die Player
- Android -Controller und Windows-WLAN-Controller laufen ohne Probleme über Subnetz-Grezen hinweg
Ich denke, hier braucht es neue Ideen!
Spartacus
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...
Hi aqui,,
danke für Dein Feedback. Ich hatte natürlich schon den Cisco in Verdacht, daher habe ich meine Windows Büchse direkt an einen der LAN Ports des RB3011 gehängt. Und auch damit klappt es nicht, oder mache ich hier einen Gedankenfehler?
Ich kann das natürlich noch mal testen, aber viel Hoffnung habe ich nicht, wenn es schon am MT nicht geht!
Vielleicht muss ich doch noch mal de Sniffer anschmeißen. Denn das Controller->Player Issue liegt definitiv an den verschiedenen Subnetzen..
Der Sonos Support verzweifelt auch so langsam und hat keine Ideen mehr. Ich hatte heute noch einmal mehrere Diagnosefiles gesendet. Einen Fehler kann der Support nicht mehr finden, aber Fakt ist:
Werden mehr als 2 reine WLAN-Player gruppiert, steigen 2 Player aus. Im Controller sieht man die Gruppe und es lassen sich auch alle Geräte bedienen, sowohl über den Controller, als auch über die Tasten am Gerät. Es kommt halt nur aus einem Gerät ein Ton. Ein Bandbreitenproblem schließt Sonos aus. Es ist kein entsprechender Fehler in deren Diagnosefiles zu sehen. Ganz im Gegenteil. Der Supporter sieht in den Files, dass alle Player abspielen!
Interessant ist allerdings noch:
Verkabelt man den Gruppen-Master, können beliebig viele WLAN-Player gruppiert werden und alle spielen einwandfrei.
Nimmt man die gleichen Player und legt den Gruppen-Master auf einen WLAN Player, so läuft es nicht mehr. Den Gruppen-Master bestimmt man über die Reihenfolge der Gruppierung.
Für mich sieht es im Moment leider so aus, als läge das Problem bei Sonos und nicht an meiner Konfiguration. Ich hatte den Support dann noch gebeten, dieses Szenario mal im Labor nachzustellen, doch leider zeigt sich SONOS da wenig kooperativ,. Da mein Netzwerk nicht so ganz dem Consumer-Standard entspricht, reden sie sich raus. Versichert hat man mir allerdings, dass man 3 reine WLAN-Player(das ist z.Zt. nur der Sonos MOVE alle andren spannen zusätzlich ein SonosNet auf) an einem ganz einfachen WLAN-Router (Fritte) gruppieren kann, ohne Probleme. Da werde ich mir wohl mal 2 weitere Move-Player anschaffen müssen und der Fritte ein eigens neues Subnetz mit 2.4 GHz WLAN verpassen um das Gegenteil zu beweisen. Einziges Manko. Ich muss 800€ für die beiden neues MOVEs investieren
Gruß,
Spartacus
danke für Dein Feedback. Ich hatte natürlich schon den Cisco in Verdacht, daher habe ich meine Windows Büchse direkt an einen der LAN Ports des RB3011 gehängt. Und auch damit klappt es nicht, oder mache ich hier einen Gedankenfehler?
Ich kann das natürlich noch mal testen, aber viel Hoffnung habe ich nicht, wenn es schon am MT nicht geht!
Vielleicht muss ich doch noch mal de Sniffer anschmeißen. Denn das Controller->Player Issue liegt definitiv an den verschiedenen Subnetzen..
Der Sonos Support verzweifelt auch so langsam und hat keine Ideen mehr. Ich hatte heute noch einmal mehrere Diagnosefiles gesendet. Einen Fehler kann der Support nicht mehr finden, aber Fakt ist:
Werden mehr als 2 reine WLAN-Player gruppiert, steigen 2 Player aus. Im Controller sieht man die Gruppe und es lassen sich auch alle Geräte bedienen, sowohl über den Controller, als auch über die Tasten am Gerät. Es kommt halt nur aus einem Gerät ein Ton. Ein Bandbreitenproblem schließt Sonos aus. Es ist kein entsprechender Fehler in deren Diagnosefiles zu sehen. Ganz im Gegenteil. Der Supporter sieht in den Files, dass alle Player abspielen!
Interessant ist allerdings noch:
Verkabelt man den Gruppen-Master, können beliebig viele WLAN-Player gruppiert werden und alle spielen einwandfrei.
Nimmt man die gleichen Player und legt den Gruppen-Master auf einen WLAN Player, so läuft es nicht mehr. Den Gruppen-Master bestimmt man über die Reihenfolge der Gruppierung.
Für mich sieht es im Moment leider so aus, als läge das Problem bei Sonos und nicht an meiner Konfiguration. Ich hatte den Support dann noch gebeten, dieses Szenario mal im Labor nachzustellen, doch leider zeigt sich SONOS da wenig kooperativ,. Da mein Netzwerk nicht so ganz dem Consumer-Standard entspricht, reden sie sich raus. Versichert hat man mir allerdings, dass man 3 reine WLAN-Player(das ist z.Zt. nur der Sonos MOVE alle andren spannen zusätzlich ein SonosNet auf) an einem ganz einfachen WLAN-Router (Fritte) gruppieren kann, ohne Probleme. Da werde ich mir wohl mal 2 weitere Move-Player anschaffen müssen und der Fritte ein eigens neues Subnetz mit 2.4 GHz WLAN verpassen
um das Gegenteil zu beweisen. Einziges Manko. Ich muss 800€ für die beiden neues MOVEs investieren Gruß,
Spartacus
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.
Hi aqui,
ja, das stimmt, unter Android geht es.
Ich spiele gerade noch mit den IGMP Einstellungen rum.
Aktuell steht das auf:
Es gibt auf der Switch Seite oben folgenden Hinweis:
IGMP Snooping is only operational when Bridge Multicast Filtering is enabled. Bridge Multicast Filtering is currently enabled.
Das ist bei mir auch enabled, allerdings weiß ich nicht was da die richtige Einstellung ist.Aktuell sieht es so aus:
Welche VLAN ID sollte hier stehen. Die für das Sonos VLAN?
Die Multicast Gruppe 239.255.255.250 hat er offenbar richtig gefunden, wie dieses Bild hier zeigt. Inkludiert sind hier auch die Uplink-Ports zu den cAPs
Gruß,
Spartacus
ja, das stimmt, unter Android geht es.
Ich spiele gerade noch mit den IGMP Einstellungen rum.
Aktuell steht das auf:
- IGMPv2 Snooping aktiv mit Switch als Querrier
Es gibt auf der Switch Seite oben folgenden Hinweis:
IGMP Snooping is only operational when Bridge Multicast Filtering is enabled. Bridge Multicast Filtering is currently enabled.
Das ist bei mir auch enabled, allerdings weiß ich nicht was da die richtige Einstellung ist.Aktuell sieht es so aus:
Welche VLAN ID sollte hier stehen. Die für das Sonos VLAN?
Die Multicast Gruppe 239.255.255.250 hat er offenbar richtig gefunden, wie dieses Bild hier zeigt. Inkludiert sind hier auch die Uplink-Ports zu den cAPs
Gruß,
Spartacus
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 !
Hi aqui,
danke für die schnelle Antwort.
Müssen denn auch die IGMP Interface settings angepasst werden, oder reicht es aus, wenn VLAN auf IGMP V2 steht.
Bei mir ist da nämlich noch alles auf default.
Spartacus
danke für die schnelle Antwort.
Müssen denn auch die IGMP Interface settings angepasst werden, oder reicht es aus, wenn VLAN auf IGMP V2 steht.
Bei mir ist da nämlich noch alles auf default.
Spartacus
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.
Hi aqui,
ich glaube ich habe hier etwas gefunden. Es sieht so aus, als würden die Player Broadcasts aussenden und die Sonos-Controller-App wartet da drauf:
Schau Dir mal diesen Link an. Und zwar diesen Absatz:
Jetzt muss ich nur noch wissen, wie man diese Broadcasts in das Controller VLAN10 routet. Komisch nur, dass dies offenbar bei den Android Kisten nicht sein muss. Oder hängt das ggf. mit den cAPs zusammen, dass die die BC durchlassen?
Spartacus.
ich glaube ich habe hier etwas gefunden. Es sieht so aus, als würden die Player Broadcasts aussenden und die Sonos-Controller-App wartet da drauf:
Schau Dir mal diesen Link an. Und zwar diesen Absatz:
Jetzt muss ich nur noch wissen, wie man diese Broadcasts in das Controller VLAN10 routet. Komisch nur, dass dies offenbar bei den Android Kisten nicht sein muss. Oder hängt das ggf. mit den cAPs zusammen, dass die die BC durchlassen?
Spartacus.
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 !
Moin aqui,
tja, ich komme nicht weiter. Wie setzt man so einen upd-Helper auf dem MT?
Der Wireshark gibt mir hier keinen eindeutigen udp-Port vor, SONOS scheint da etwas properitäres zu benutzen.
Schau mal in den Ausschnitt. Ich denke, das ist die Stelle, die hier Kummer macht!
*.30.198 ist der Rechner, die Player haben *.30.21
Spartacus
tja, ich komme nicht weiter. Wie setzt man so einen upd-Helper auf dem MT?
Der Wireshark gibt mir hier keinen eindeutigen udp-Port vor, SONOS scheint da etwas properitäres zu benutzen.
Schau mal in den Ausschnitt. Ich denke, das ist die Stelle, die hier Kummer macht!
*.30.198 ist der Rechner, die Player haben *.30.21
Spartacus
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.
Hi aqui,
sorry für die späte Antwort, aber ich war mal ein paar Tage "off"!
Ich habe mir das noch mal angesehen. Für mich sieht das aber so aus, als würde der SONOS-Player
(z.B. Zeile 38 im Trace) die Broadcast versenden und der Controller im Windows Netz darauf horchen und dann mit dem MC Paket 239.255.255.250 antworten (Zeile 40,41)
Allerdings steht bei der Broadcast nix von UDP im Wireshark. Protokoll ist 0x6970...was auch immer das heißt!
Ich habe auch keine Idee, wie man das auf MT umsetzen kann, dass die o.a. Broadcast von Sonos_xx:xx:xx , ins Controller VLAN kommen soll. Ich habe da nichts im Hinblick auf Broadcast weiterleiten mit Helper Adressen gefunden, was mir konkret weiterhilft
Spartacus.
sorry für die späte Antwort, aber ich war mal ein paar Tage "off"!
Ich habe mir das noch mal angesehen. Für mich sieht das aber so aus, als würde der SONOS-Player
(z.B. Zeile 38 im Trace) die Broadcast versenden und der Controller im Windows Netz darauf horchen und dann mit dem MC Paket 239.255.255.250 antworten (Zeile 40,41)
Allerdings steht bei der Broadcast nix von UDP im Wireshark. Protokoll ist 0x6970...was auch immer das heißt!
Ich habe auch keine Idee, wie man das auf MT umsetzen kann, dass die o.a. Broadcast von Sonos_xx:xx:xx , ins Controller VLAN kommen soll. Ich habe da nichts im Hinblick auf Broadcast weiterleiten mit Helper Adressen gefunden, was mir konkret weiterhilft
Spartacus.
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.
Hi aqui,
danke Dir. Das ist ein ziemlich fettes Dokument. Ich werde es lesen, aber fürchte, dass ich nur "Bahnhof" verstehe!
Du als Experte,
siehst Du eine Chance das Thema in den Griff zu kriegen? Beim Überfliegen habe ich festgestellt das 6970 für die Gruppenbildung verantwortlich ist. Mit der Controller Ansteuerung hat es offenbar nichts zu tun...
Schauen wir mal, melde mich, wenn ich die 33 Seiten durch habe!
danke Dir. Das ist ein ziemlich fettes Dokument. Ich werde es lesen, aber fürchte, dass ich nur "Bahnhof" verstehe!
Du als Experte,
siehst Du eine Chance das Thema in den Griff zu kriegen? Beim Überfliegen habe ich festgestellt das 6970 für die Gruppenbildung verantwortlich ist. Mit der Controller Ansteuerung hat es offenbar nichts zu tun...
Schauen wir mal, melde mich, wenn ich die 33 Seiten durch habe
!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.
Moin aqui,
ich bin heute noch einmal mit WireShark unterwegs gewesen um diesen Windows Controller ans Fliegen zu kriegen.
Ich habe immer noch den Eindruck, als würde PIM immer nicht richtig laufen.
Zum Versuchsaufbau:
Ich habe auf dem Windows Rechner den WS mitlaufen lassen und sehe, dass bei Start des Sonos Controllers ein Multicast paket mit 239.255.255.250 verschickt wird.
Im SONOS VLAN habe ich einen 2ten Wireshark laufen, der den Traffic in VLAN30 mitschneidet. Hier kommt aber das Multicast Paket von meinem Rechner in VLAN 10 gar nicht an? Auch sehe ich im Firewall Log auf dem MT, dass aus VLAN10 gar kein MC Paket verschickt wird. Ich sehe nur Pakete aus dem Sonos-VLAN in VLAN aber nicht umgekehrt.
Hast Du eine mögliche Erklärung dafür? Muss ich ggf. als RP beide GWs sowohl die 172.16.30.1 (VLAN30)als auch die 172.16.10.1 (VLAN10) eintragen? Die FW Regel für MC sieht so aus und sollte MC in jedes Subnetz weiterleiten.
Spartacus
ich bin heute noch einmal mit WireShark unterwegs gewesen um diesen Windows Controller ans Fliegen zu kriegen.
Ich habe immer noch den Eindruck, als würde PIM immer nicht richtig laufen.
Zum Versuchsaufbau:
Ich habe auf dem Windows Rechner den WS mitlaufen lassen und sehe, dass bei Start des Sonos Controllers ein Multicast paket mit 239.255.255.250 verschickt wird.
Im SONOS VLAN habe ich einen 2ten Wireshark laufen, der den Traffic in VLAN30 mitschneidet. Hier kommt aber das Multicast Paket von meinem Rechner in VLAN 10 gar nicht an? Auch sehe ich im Firewall Log auf dem MT, dass aus VLAN10 gar kein MC Paket verschickt wird. Ich sehe nur Pakete aus dem Sonos-VLAN in VLAN aber nicht umgekehrt.
Hast Du eine mögliche Erklärung dafür? Muss ich ggf. als RP beide GWs sowohl die 172.16.30.1 (VLAN30)als auch die 172.16.10.1 (VLAN10) eintragen? Die FW Regel für MC sieht so aus und sollte MC in jedes Subnetz weiterleiten.
Spartacus
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.
Hi aqui,
ich gebe mit PIM noch nicht auf.
wenn ich mir das Bild ansehe, dann kann ich sehen, dass PIM offenbar nicht in beide Richtungen funktioniert. Incoming Interface (VLAN30) geht über outgoing interface (VLAN10). Aber der umgekehrte weg offenbar nicht. Müsste da nicht für 172.16.10.20 das outgoing Interface VLAN30 stehen?
Aber wo ist der Fehler? Wo und vor Allem wie stelle ich das korrekt ein? Vielleicht ist der Cisco hier noch der Übeltäter? Ich hänge den Windows PC noch mal direkt an den Mikrotik Port und schließe den Cisco kurz.
Spartacus
ich gebe mit PIM noch nicht auf.
wenn ich mir das Bild ansehe, dann kann ich sehen, dass PIM offenbar nicht in beide Richtungen funktioniert. Incoming Interface (VLAN30) geht über outgoing interface (VLAN10). Aber der umgekehrte weg offenbar nicht. Müsste da nicht für 172.16.10.20 das outgoing Interface VLAN30 stehen?
Aber wo ist der Fehler? Wo und vor Allem wie stelle ich das korrekt ein? Vielleicht ist der Cisco hier noch der Übeltäter? Ich hänge den Windows PC noch mal direkt an den Mikrotik Port und schließe den Cisco kurz.
Spartacus
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.
Hi,
ich dachte eigentlich, ich hätte schon darauf geantwortet, aber offenbar vergessen es abzusenden!
Querrier am Cisco abgeschaltet, Neustart durchgeführt
PIM neu installiert, 6.47
beides keinen Erfolg!
Der PC sendet MC. Das kann man im WS sehen.
Ich habe den Eindruck,MC Routing läuft nur von VLAn30 in VLAN 10, aber nicht umgekehrt. Irgendwo ist hier der Wurm drin!
Ich habe zumindest herausgefunden, was die WOL-Pakete sollen, die der PC sendet. Die sind ganz klar an die SONOS Move gerichtet, damit diese ggf. aus dem Standby geholt werden können. Die haben aber nichts mit der Kommunikation zwischen SonosPlayer und Controller zu tun.
Spartacus.
ich dachte eigentlich, ich hätte schon darauf geantwortet, aber offenbar vergessen es abzusenden!
Querrier am Cisco abgeschaltet, Neustart durchgeführt
PIM neu installiert, 6.47
beides keinen Erfolg!
Der PC sendet MC. Das kann man im WS sehen.
Ich habe den Eindruck,MC Routing läuft nur von VLAn30 in VLAN 10, aber nicht umgekehrt. Irgendwo ist hier der Wurm drin!
Ich habe zumindest herausgefunden, was die WOL-Pakete sollen, die der PC sendet. Die sind ganz klar an die SONOS Move gerichtet, damit diese ggf. aus dem Standby geholt werden können. Die haben aber nichts mit der Kommunikation zwischen SonosPlayer und Controller zu tun.
Spartacus.
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 !
Hi,
puuh! Ich glaube ich gebe so langsam auf. VLC läuft weder von VLAN10->VLAN30 noch vom VLAN30->VLAN10. Geht irgendwie gar nix mehr!
Ich habe nun den VLC-Server in VLAN30 stehen. Die Adresse lautet 239.255.1.2. Der Client laust in VLAN10.
Im MT-Log sehe ich aber MC Pakete die komischerweise über die 239.255.255.250 von diesem VLC-Server gesendet werden. Was ist das denn jetzt für ein schei..! Da müsste doch die 239.255.1.2 kommen, oder? Und es ist definit der VLC. Wenn ich die Übertragung beende kommen auch keine Pakete mehr! ICh weiß echt nicht mehr, was da los ist! Und 1900 sind doch die Sonos Ports. Irgendwie habe ich den Verdacht, die Sonos Büchsen hauen dazwischen.
NACHTRAG:
offensichtlich liegt das daran, dass die IP des servers in PIM sowohl der 239.250.1.2 als auch der Sonos MC 239.255.255.250 zugeordnet ist. Den Cache kann man aber nicht löschen.
Spartacus
puuh! Ich glaube ich gebe so langsam auf. VLC läuft weder von VLAN10->VLAN30 noch vom VLAN30->VLAN10. Geht irgendwie gar nix mehr!
Ich habe nun den VLC-Server in VLAN30 stehen. Die Adresse lautet 239.255.1.2. Der Client laust in VLAN10.
Im MT-Log sehe ich aber MC Pakete die komischerweise über die 239.255.255.250 von diesem VLC-Server gesendet werden. Was ist das denn jetzt für ein schei..! Da müsste doch die 239.255.1.2 kommen, oder? Und es ist definit der VLC. Wenn ich die Übertragung beende kommen auch keine Pakete mehr! ICh weiß echt nicht mehr, was da los ist! Und 1900 sind doch die Sonos Ports. Irgendwie habe ich den Verdacht, die Sonos Büchsen hauen dazwischen.
NACHTRAG:
offensichtlich liegt das daran, dass die IP des servers in PIM sowohl der 239.250.1.2 als auch der Sonos MC 239.255.255.250 zugeordnet ist. Den Cache kann man aber nicht löschen.
Spartacus
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...
Hi aqui,
Ich habe jetzt offenbar auch noch ein Firewall Problem. Diese FWD Regel lässt die udp Pakete nicht durchkommen. Da müsste doch alles durchrennen, ink. Multicast
die Liste "LAN" beinhaltet alle VLANs, VlanFriends beinhaltet alle Subnetzte im Format 192.168.1.0/24, die miteinander quatschen dürfen.
MC wird nur geroutet, wenn ich die Dst-Adresse 239.255.255.250 / 239.255.1.2 explizit in eine separate Forward Regel einbaue. Bin ich jetzt total verwirrt oder hat mein Router ne Macke!
Aber btw: der Router Reset hat nichts gebracht. PIM läuft immer noch nicht!
Ich glaub ich muss hier mal einen neuen Router kaufen und von Grund auf neu einrichten irgendetwas läuft hier schief. Das Rumbasteln am produktiven System ist kacke! Ich würde allerdings bei MT bleiben wollen, den 4011? Der hat zumindest nen 10Gbit uplink.
Spartacus
Ich habe jetzt offenbar auch noch ein Firewall Problem. Diese FWD Regel lässt die udp Pakete nicht durchkommen. Da müsste doch alles durchrennen, ink. Multicast
die Liste "LAN" beinhaltet alle VLANs, VlanFriends beinhaltet alle Subnetzte im Format 192.168.1.0/24, die miteinander quatschen dürfen.
MC wird nur geroutet, wenn ich die Dst-Adresse 239.255.255.250 / 239.255.1.2 explizit in eine separate Forward Regel einbaue. Bin ich jetzt total verwirrt oder hat mein Router ne Macke!
Aber btw: der Router Reset hat nichts gebracht. PIM läuft immer noch nicht!
Ich glaub ich muss hier mal einen neuen Router kaufen und von Grund auf neu einrichten irgendetwas läuft hier schief. Das Rumbasteln am produktiven System ist kacke! Ich würde allerdings bei MT bleiben wollen, den 4011? Der hat zumindest nen 10Gbit uplink.
Spartacus
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 !!
Hi aqui,
leider hängt der MT 3011 im WAN. Daher ist es nicht so klug alle Regeln wegzulassen. Die Fritzbox hängt im IPCLIENT Mode als DECT TK Anlage.dahinter.
Ich glaube, der MT 3011 bracht einen Werksreset. Und dann müsse der Kleine, zumindest für eine gewisse Zeit, alle Aufgaben vom RB3011 übernehmen...und das schafft der leistungstechnisch nicht. Ich denke, hier muss Schritt für Schritt migriert werden um ein sauberes System zu bekommen. Und das geht nur mit einem Router, der ähnlich ist, sodass man die komplette Konfiguration spiegeln kann. Und falls man sich beim Aufbau verzettelt, einfach noch mal von vorne starten und den alten RB3011 aus dem "cold stanby" holen und an den Cisco anstöpseln.
Der RB4011 kostet round about 200€ + 2 x SFP+ LWL Modul für den MT und den CIsco.(ca. 60€).
Dann hätte ich auch ein Backup Gerät.
Was meinst Du?
Spartacus
leider hängt der MT 3011 im WAN. Daher ist es nicht so klug alle Regeln wegzulassen. Die Fritzbox hängt im IPCLIENT Mode als DECT TK Anlage.dahinter.
Ich glaube, der MT 3011 bracht einen Werksreset. Und dann müsse der Kleine, zumindest für eine gewisse Zeit, alle Aufgaben vom RB3011 übernehmen...und das schafft der leistungstechnisch nicht. Ich denke, hier muss Schritt für Schritt migriert werden um ein sauberes System zu bekommen. Und das geht nur mit einem Router, der ähnlich ist, sodass man die komplette Konfiguration spiegeln kann. Und falls man sich beim Aufbau verzettelt, einfach noch mal von vorne starten und den alten RB3011 aus dem "cold stanby" holen und an den Cisco anstöpseln.
Der RB4011 kostet round about 200€ + 2 x SFP+ LWL Modul für den MT und den CIsco.(ca. 60€).
Dann hätte ich auch ein Backup Gerät.
Was meinst Du?
Spartacus
Daher ist es nicht so klug alle Regeln wegzulassen.
Oooopps Ja, besser ist das.RB3011 als Spare Part ist dann in der Tat dein besserer Freund
Tach aqui,
ich habe nun am MT selber zwei Ports mit VLAN 10 und VLAN 30 definiert. Und siehe da, MC wird in beide Richtungen geroutet. Das Ganze käuft hier jetzt aber auch ohne Radius-Auth ab. Vielleicht ist da ja irgendwo der Wurm drin. Der Cisco macht die Auth ja direkt mit dem Freeradius.
Fazit:
Irgendetwas scheint am Cisco nicht richtig konfiguriert zu sein. Irgendeine Idee, wo man gucken kann?
NACHTRAG:
und jetzt kommt der Oberhammer:
an dem Client am MT-Port (VLAN10) läuft der Controller plötzlich, aber nur nach einem Windows Neustart.also quasi einmalig. Startet man den Windows Controller neu, findet es das Sonos System nicht mehr. Startet man Windows neu, läuft er.Versteht das jemand?
Christian
ich habe nun am MT selber zwei Ports mit VLAN 10 und VLAN 30 definiert. Und siehe da, MC wird in beide Richtungen geroutet. Das Ganze käuft hier jetzt aber auch ohne Radius-Auth ab. Vielleicht ist da ja irgendwo der Wurm drin. Der Cisco macht die Auth ja direkt mit dem Freeradius.
Fazit:
Irgendetwas scheint am Cisco nicht richtig konfiguriert zu sein. Irgendeine Idee, wo man gucken kann?
NACHTRAG:
und jetzt kommt der Oberhammer:
an dem Client am MT-Port (VLAN10) läuft der Controller plötzlich, aber nur nach einem Windows Neustart.also quasi einmalig. Startet man den Windows Controller neu, findet es das Sonos System nicht mehr. Startet man Windows neu, läuft er.Versteht das jemand?
Christian
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):
Hast du auch IGMP Snooping in der VLAN Bridge des Mikrotik aktiviert ? Das sollte man natürlich auch machen.
Hi,
die Einstellungen habe ich noch einmal kontrolliert. Ist alles genau so eingestellt. Witzigerweise habe ich nach dem erfolgreichen Test an den MT Ports alles zurück an den Cisco gehängt. Es funktioniert jetzt auch über den Cisco mit VLC.
in beide Richtungen. Offenbar hat der Cisco gelernt Ich habe keine einzige Einstellung verändert. Nur die Rechner gebootet.
Allerdings läuft der SONOS Controller nicht mehr auf dem PC.
BTW:
Meinst Du für alle VLANS, oder nur für die VLANS, die MC machen sollen?
und:
ich habe ja noch nen SG250-10 per Glas an dem SG350. Hier identisch einstellen, oder den Querier ausschalten?
Spartacus
die Einstellungen habe ich noch einmal kontrolliert. Ist alles genau so eingestellt. Witzigerweise habe ich nach dem erfolgreichen Test an den MT Ports alles zurück an den Cisco gehängt. Es funktioniert jetzt auch über den Cisco mit VLC.
in beide Richtungen. Offenbar hat der Cisco gelernt
Ich habe keine einzige Einstellung verändert. Nur die Rechner gebootet.Allerdings läuft der SONOS Controller nicht mehr auf dem PC.
BTW:
Obiges für alle VLANs gleich setzen !!
Meinst Du für alle VLANS, oder nur für die VLANS, die MC machen sollen?
und:
ich habe ja noch nen SG250-10 per Glas an dem SG350. Hier identisch einstellen, oder den Querier ausschalten?
Spartacus
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 !
Hi aqui,
yep! IGMP Snooping ist am MT aktiviert. Aber ich habe noch mal in die Wireshark Pakete geguckt. Schau mal selbst!
Die Msearch-Pakete haben eine TTL von 4 und gehen durch. Die Antworten von den Playern offensichtlich nur 1
Frag mich nur, warum das mal gegeht hat und was Android da anders macht.
Aber ich fürchte, das war es dann wohl!
Christian
yep! IGMP Snooping ist am MT aktiviert. Aber ich habe noch mal in die Wireshark Pakete geguckt. Schau mal selbst!
Die Msearch-Pakete haben eine TTL von 4 und gehen durch. Die Antworten von den Playern offensichtlich nur 1
Frag mich nur, warum das mal gegeht hat und was Android da anders macht.
Aber ich fürchte, das war es dann wohl!
Christian
TTL=1 bedeutet unroutebar, das ist klar. Das wars dann wirklich...jedenfalls für diese Pakete wenn sie geroutet werden müssen. Destination IP konnte man ja nicht sehen...
Hi aqui,
hier noch mal die Port Security für die cAPs.
Spartacus.
hier noch mal die Port Security für die cAPs.
Spartacus.
hier noch mal die Port Security für die cAPs.
Hast du da mal testweise einen PC oder Laptop angeschlossen ? Kommt der problem los ins Netz bzw. das native VLAN an dem Port ?Der cAP Port muss fest tagged in alle VLANs gesetzt sein die der cAP dynamisch zuweisen kann.
