14.07.2018, aktualisiert um 10:48:54 Uhr

11115

MIKROTIK + SONOS im VLAN

Hallo,
ich habe meine Sonos Player in ein separates Subnet verschoben (vlan30). Die Controller sind in div. anderen vlans (vlan60, vlan10).

Bis vor ein paar Tagen funktionierte das reibunsgslos, aber seit gestern finden die Controller die Player ur sporadisch. Ich habe dann die Controller zurückgesetzt, aber das scheint überhaupt nicht zu klappen. Ich kann die Controller nur verbinden, wenn sie im gleiche Subnetz sind. Irgendwie habe ich den Eindruck, dass ist nach dem Sonos-Update auf 9.0 passiert. Auch das ließ sich nur mit Controllern im gleiche Subnetz durchführen. Irgendwie scheint es hier noch Kommunikationsprobleme zwischen den Subnetzten zu geben:

Meine Konfig:

#
/interface list
add name="Sonos Control"  
#
/interface list member
add comment=SONOS disabled=yes interface=vlan99 list="Sonos Control"  
add comment=SONOS interface=vlan60 list="Sonos Control"  
add comment=SONOS interface=vlan10 list="Sonos Control"  
#
### vlan10
/ip firewall address-list
add address=172.16.10.0/24 list=SonosControl
#
### Firewall
/ip firewall filter
add action=accept chain=forward comment="SONOS: forward Multicast traffic" \  
    dst-address=239.255.255.250
add action=accept chain=forward comment=\
    "SONOS: forward  Controller events to Players" dst-port=1400,4444,4070 \  
    in-interface-list="Sonos Control" out-interface=vlan30 protocol=tcp  
add action=accept chain=forward comment=\
    "SONOS: Forward Contoller events  from Players" dst-port=\  
    3400,3401,3500,4070 in-interface=vlan30 out-interface-list=\
    "Sonos Control" protocol=tcp  
add action=accept chain=forward comment=\
    "SONOS. Forward UPnP Device Discovery events from Players" dst-port=\  
    136-139,1900,1901,2869,5353,6969 in-interface=vlan30 out-interface-list=\
    "Sonos Control" protocol=udp  
#
###PIM
/routing pim interface
add comment="Sonos player" interface=vlan30  
add comment="Sonos controller" interface=vlan10  
/routing pim rp
add address=172.16.30.1

Witzigerweise habe ich auch Controller in vlan60. Obwohl hier kein Eintrag in PIM ist, funktionieren diese Controller besser als die Windows Controller in vlan10. Irgendetwas stimmt hier noch nicht. Hat jemand eine Idee?

Christian

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

Content-ID: 380289

Url: https://administrator.de/forum/mikrotik-sonos-im-vlan-380289.html

Ausgedruckt am: 26.12.2024 um 19:12 Uhr

31 Kommentare

Neuester Kommentar

Sieh dir mal mit dem Wireshark an welche Multicast Adressen Sonos verwendet. Das TTL 1 Thema hatten wir ja neulich mit den link local Adressen.
Irgendjemand im letzten Post dazu schrieb hier im Forum noch das die Sonos mit der aktuellen Firmware jetzt Spanning Tree machen.
Achte deshalb darauf das die Bridge Priority in ALLEN deinen VLAN Segmenten am Mikrotik auf "4096" gesetzt ist damit der MT Root Bridge wird im Bezug zum Sonos.
Auch hier ist der Wireshark dein bester Freund !
Ggf. solltest du erstmal alle Filter entfernen um dir hier noch noch mehr potentielle Fallen zu schaffen indem du was wegfilterst was du brauchst.
Teste das erstmal in einem normal gerouteten Netz und mache erst dann wenn alles fehlerfrei rennt die Schotten dicht. So weisst du genau das es ggf. nur an falschen Filterregeln liegen kann !

Hi aqui,
was würde ich ohne Deine Hilfe nur machen....

Ich habe auf dem MT aber nur eine Bridge für alle vlans. Daher kann ich SPT nur zentral einstellen. Ist das ein Problem, oder kann man das auf das vlan begrenzen? Auf dem Cisco hatte ich das schon gemacht.

Das sieht dann so aus, richtig (stand vorher auf 8000 und none, gebracht hat es aber nichts)?

Christian.

Sonos braucht Multicast routing /forwarding für die Netze

https://en.community.sonos.com/home-theater-228993/sonos-across-multiple ...

Normalerweise werden die multicasts ja am Router nicht weitergeleitet. Dass muss explizit aktiviert ( und vom Router unterstützt werden)

Grüße

lcer

Hi,
ich kann hier mit Wire Shark keine Probleme erkennen.

Das Problem besteht auch hauptsächlich, wenn ein Controller dem System zugeordnert werden soll. ICh muss mal im vlan30 sniffen um zu gucken, ob hier ggf. noch andere Ports gezogen werden.

Wegen der SPT Einstellungen habe ich hier nichts gefunden, um es auf das vlan30 zu beschränken.

Christian

@icer00,
Multicast routing ist aktiviert, siehe PIM-Config.
Das hat ja auch 3 wochen lang gegeht, bis zum Update vorgestern. Und es geht ja auch sporadisch, aber ich kann z.B. keinen neuen controller hinzufügen.

Christian

Ich habe auf dem MT aber nur eine Bridge für alle vlans.

Richtig, denn der MT kann nur Single Span Verfahren, er kann kein PVST (Per VLAN Spanning Tree).
Also richtig einmal zentral eintragen und gut iss.
Vorsicht aber wenn du hier einen Core Switch hast an dem deine VLANs hängen mit ihren Endgeräte Ports.
Der sollte dann immer die Bridge Priority 4096 haben und der MT dann das zweithöchste sprich die 8192.
So stellt man sicher das der Core Root Bridge ist und der MT Backup Root.
Mit "none" schaltest du STP auf dem MT komplett aus !! Nicht gut !! Das dient zur Loop Protection und sollte im RSTP Mode besser anbleiben wie im Default.
Niemals auf "STP" stellen sondern heutzutage nur noch RSTP !!

Die MC Adresse 239.255.255.250 nutzt ja auch TTL 4, also sollte PIM sie problemlos routen und du diese Announcements auch in allen anderen VLAN Segmenten sehen. Ist dem so ?
Findest du dort im Sonos Controller VLAN oder in dem Segment wo Lautsprecher Clients sind ggf. noch MC Adressen die ein Link Local MC sind also einen TTL von 1 haben ?

Hi aqui,
alle Sonos Endgeräte und auch die Controller hängen am SG200. Ich habe daher den MT auf 8192 und auf RSTP gestellt; hatte ich doch richtig verstanden, oder?

Ich werde mir das vlan30 mal mit dem Wireshark ansehen und hier posten. Wird aber heute nichts mehr!

Auf jeden Fall laufen die Controller wieder im vlan10, allerdings erst, nachdem ich sie im "Player-LAN" neu angelernt hatte. Aus dem vlan10 klappt das nicht. Er findet das Player Netz nicht. Möglcherweise muss man hier die udp-Ports auch in beide Richtungen durchlassen.

Ich vermute daher, dass hier noch Ports fehlen, die der Sonos braucht. Auch das Update auf OS9 klappte nur an einem Controller im "Player-LAN". Da ist noch irgendetwas faul!

Ich bleibe dran, bis hierher schon mal Besten Dank!
Christian

Hallo,
ich habe mir heute mal mit wireshark angeguckt, was in meinen vlans passiert. Und ich muss sagen, nicht viel

!
PIM funktioniert nicht. Es werden aus dem vlan30 keine Meldungen ins vlan 10 bzw vlan60 geforwarded.

Ich habe PIM und alle Sonos FW Rules mal deaktiviert und mein Sonos lässt sich immer noch steuern. Das passiert rein über TCP. PIM scheint hier noch nie funktioniert zu haben und ich bin jetzt echt ratlos, warum das nicht läuft.

Es wird auch offenbar auch kein Multicast Traffic geroutet. Einfach nix los, die Counter bleiben auf 0.
Woran liegt das denn, an den vlans?

Den Router habe ich schon mehrfach neu gebootet, aber das hilft nix! Please help!
Christian

Hallo,

https://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/configuration/guide/fi ...

Soweit ich das verstehe ist PIM ein Protokoll zur Verwendung zwischen Routern. Das klingt anders als Multicasts von einem Netz ins andere Routen.

Kenne mich aber mit Deinem Router nicht aus. Vielleicht muss man das Multicast routing aber anders aktivieren.

Grüße

lcer

Hi Icer00,
eigentlich ist PIM schon die richtige Wahl, zumindest wird das in den Foren so beschrieben. Was allerdings sein kann ist, dass der Cisco SG200 die Multicast Weiterleitung blockiert. Aller Sonos Geräte hängen im vlan30 an diesem Switch. ICh könnte ja mal testweise eine vlan30 Port am RB3011 konfigurieren...aber so richtig will ich das nicht glauben, dass das das Problem ist!

Christian

Hallo

soweit ich mich erinnere, konnte man SG200 Ports als multicast-Router-Ports definieren. Schau mal ob es da sowas gibt.

Grüße

lcer

Habs gefunden:

SG200_Menü
- Multicast
- Multicast-Router-Port -> Entsprechende VLAN/Port-Kombination auf Statisch setzen
- Alle Weiterleiten -> Entsprechende VLAN/Port-Kombination auf Statisch setzen

habe beides auf statisch gesetzt, vielleicht reicht auch nur eins davon.

Grüße

lcer

Hallo zusammen
@ Icer00
Besten Dank für Deine Information. Ich habe es gleich am Cisco eingespielt, aber es bleibt dabei. Es wird kein Multicast geroutet.

Um den Cisco mal auszuschließen, habe ich das vlan30 (Player) und das vlan10 (Controller) am RB3011 konfiguriert. vlan10 ist auf ether3 und vlan30 auf ether4. Dann habe ich einen Sonos Player an ether4 angeschlossent und einen Windows PC an ether3. Auch hier bleibt es dabei. Kein Multicast Routing. Das heisst, PIM funktioniert einfach nicht. Ich weiß echt nicht, was ich noch machen soll!

Christian

NACHTRAG.
Ich habe etwas gefunden, allerdings hat das ganze auch einen Haken:

Wenn ich in den Bridge Settings die Einstellung auf "Use IP-Firewall for VLAN" aktiviere, kann ich im Log sehen, dass Multicast in die VLANs geroutet wird. Allerdings komme ich dann nicht mehr ins Internet

Zudem habe ich das IGMP snooping eingeschaltet. Das scheint aber keinen Effekt zu haben.

Hallo an alle,
hat hier niemand eine Idee, was man noch probieren könnte?
Christian

Hallo,
ich habe das Problem eingrenzen können. Offenbar liegt es an meiner NAT-Regel, allerdings weiß ich nicht, was ich daran ändern muss.
Deaktiviere ich die NAT Regel, läuft der Sonos problemlos und Player und Controller finden sich sofort. Der DNS-Part mit dem Redirect ist ok, nur das "masquerade " ist das Problem.

Hat jemand eine Idee?

/ip firewall nat
add action=redirect chain=dstnat comment=\
    "Force Users to Router for DNS - TCP" dst-port=53 protocol=tcp  
add action=redirect chain=dstnat comment=\
    "Force Users to Router for DNS - UDP" dst-port=53 protocol=udp  
add action=masquerade chain=srcnat comment="masquerade LAN->WAN" disabled=yes \  
    out-interface-list=WAN

In der Interface-Liste "WAN" ist ether1; in der Interface Liste "LAN" sind alle vlans enthalten

Christian

Ist der MT auch dein Internet Router ??
Wenn nicht wäre NAT ja eh Unsinn.

Hallo aqui,
war im Urlaub, daher melde ich mich erst jetzt.

Ja der RB3011 ist auch InternetRouter. Ich kann mir aber nicht erklären, warum das Problem am NAT liegen soll.

Im Prinzip läuft das ja auch mit dem Sonos. Wenn die Player / Controller einmal verbunden sind, ist eigentlich alles ok.

Will man aber einen neuen Controller/Player ins System einbinden, muss mindestens ein Controller im selben Subnetz (hier vlan30) sein. Verstehe nicht, woran das liegt!

Christian

Es liegt auch nicht am NAT an sich. Sofern man das richtg konfiguriert gehts auch darüber. Das ist aber nicht trivial.
Vermutlich "lernt" ein neues System über mDNS oder andere Techniken die IPs des Steuergerätes oder der Satelliten um sie dann zu "verinnerlichen".
Das ist aber jetzt nur eine Vermutung. Dazu müsstest du mal den Wireshark anschmeissen und dir mal genau ansehen WAS die Komponenten da machen im Netz.
Mit einer entsprechenden Konfig im MT klappt das dann natürlich auch über Router Grenzen.

Hallo aqui,
ich habe heute noch einmal mit dem Sonos Support telefoniert. Das sind alle Ports die der Sonos für die Kommunikation benötigt:

Im normalen Betrieb läuft die Kommunikation nur über TCP. Für das Gruppieren von Playern wird Multicast benutzt. Beides funktioniert bei mir und ich kann es an den entsprechenden Regeln in der FW erkennen, da die Anzahl der Pakete hochgezählt werden, wenn ich z.B. zwei Player gruppiere. Somit sollte Multicast Routing laufen.
Probleme gibt es mit den UDP-Paketen in den "UDP-Regeln". Die bleiben immer auf "0". Das heißt, hier wird nix geroutet.

Schalte ich jetzt aber diese NAT-Regel ab, werden die UDP-Pakete hochgezählt und ich kann auch einen neuen Controller anlernen.

add action=masquerade chain=srcnat comment="masquerade LAN->WAN" disabled=yes out-interface-list=WAN  

Ich bin nicht sicher, wie genau ich mit dem Wireshark der Sache auf den Grund gehen kann. Hast Du einen Tipp wonach ich genau suchen könnte, um den Fehler in der FW-Konfig einzugrenzen? Ich bin auf dem Gebiet totaler Laie!

Gruß,
Christian

Probleme gibt es mit den UDP-Paketen in den "UDP-Regeln". Die bleiben immer auf "0". Das heißt, hier wird nix geroutet.

Du kannst aber sicher ausschliessen das das NICHT durch die Regel selber bedingt ist ?!
Ggf. also mal alle Filterregeln deaktivieren. Für das Routing ist es generell egal ob TCP oder UDP. Solnage der TTL Wert im UDP nicht auf 1 steht ?!

Schalte ich jetzt aber diese NAT-Regel ab....

Exclude doch einfach mal die rein lokalen Netze vom Source NAT so das ausschliesslich NUR die Internet Verbindungen gesourceNATet werden NICHT aber die lokalen mit Zieladressen in den anderen VLANs.
Das sollte doch dann die Lösung sein.

Hi aqui,
hm! Bin mir nicht sicher, ob ich das hinkriege. Ich muss in der NAT Regel dann ja scrnat anstelle von "masquerade" verwenden. Aber "scrnat" geht doch nur, wenn sich die WAN IP nicht ändert, oder?
Hast Du mal ein Bsp., wie das aussehen muss?

and btw.
Sonos verwendet mDNS, das habe ich in anderen Threads gefunden, habe aber keine Ahnung was ich da an meinem RB3011 konfigurieren muss. Weiterhin habe ich Artikel gefunden, die besagen, das RSTP mit Sonos Probleme macht und man besser auf Classic STP umstellen sollte. Das habe ich auch wieder zurückgedreht.

Christian

Hallo,
ich kämpfe immer noch mit dem Sonos Phänomen. hat niemand eine Idee dazu, wie man die NAT Regel anpassen müsste?

Danke,
Christian

Hm!
ich habe jetzt die NAT-Regel etwas modifiziert und plötzlich geht es!
Allerdings verstehe ich nicht warum :

Anstelle

Out-Interface List = WAN

habe ich

Out-Interface = ether1

eingestellt. Der Interface List "WAN" ist nur ether1 zugeordnet.
Ich habe jetzt bestimmt 10 Tests mit Playern und Controllern gemacht und es scheint zu klappen.
Versteht jemand, warum das so ist?

Christian

ich habe jetzt die NAT-Regel etwas modifiziert und plötzlich geht es!

Ein WinBox Screenshot wäre mal hilfreich, weil das das ganze Regelwerk zeigt

Versteht jemand, warum das so ist?

Vermutlich....
Das Interface "WAN" gibt es so nicht ! Diese Name bezieht sich auf eine Interface Liste.
Hier hat MT eine recht verschwurbelte Logik hinter die ich ehrlich gesagt auch noch nicht gestiegen bin. Besser ist es also auf Interface Listen Namen zu verzichten und richtige Interfaces dort anzugeben.

Ich hatte versucht eine Liste zu definieren um dort die Autodiscovery (CDP, LLDP, WinBox) abzuschalten. Sinnvoll wäre hier ja einen Listennamen zu definieren und dort physische Ports zuzufügen. Das geht aber nicht.
Der List Button in der Listen Generierung gaukelt das zwar vor, man kann aber keine dedizierten Interfaces wählen.
In der Listendefinition selber lassen sich dann auch nur Listennamen kombinieren.
Recht verwirrend das. Vielleicht erbarmt sich hier jemand das mal aufzuklären....
Aber gut wenns nun rennt wie es soll.

Hi aqui,
danke für die Antwort. Mit dem "Interface-List"-Issue hatte ich nicht gerechnet. Ich verwende sehr oft Interface Lists in meiner Konfig und vielleicht sollte ich das mal ändern.

Was genau sollte ich per Screenshot hier posten? Die FW-Regeln? Oder was meinst Du?

Allerdings geht das mit dem SONOS doch noch nicht 100%tig. Das Anlernen von neuen Playern geht irgendwie doch nicht! Ich vermute jetzt mal, dass es an dem MDNS Request liegt, den der Mikrotik Router nicht verarbeiten kann. Ich habe mal nach SONOS und MultiCast-DNS gegoogelt, aber so richtig passende Treffer finde ich nicht. Offenbar scheinen die Ubiquiti-Router damit umgehen zu können, denn da hat ein User das mDNS auf dem Router aktiviert und hat keine Probleme mit dem Sonos. Auch Ciscos SG3xx-Serie scheint das zu können. Habe aber nur einen SG200 und SG250

.

Mit dem Umstand, dass das Anlernen der Sonos Player nicht geht, kann ich aber leben. Dann muss ich halt kurzfirstig einen Controller in das entsprechende VLAN bringen, wenn ich einen neuen Player anlernen will. So oft passiert das ja auch nicht.

Christian

Die FW-Regeln? Oder was meinst Du?

Ja.

an dem MDNS Request liegt, den der Mikrotik Router nicht verarbeiten kann

Was meinst du genau mit "verarbeiten" ??
mDNS nutzt die Multicast IP 224.0.0.251 mit dem UDP Port 5353.
Die Besonderheit hier ist das die Multicast Adresse 224.0.0.251 eine sog. Link Local Multicast Adresse ist. Sie kann also NICHT über einen Router per Multicast PIM geroutet werden oder sowas, da diese Pakete eine feste TTL von 1 haben.
Fragt sich also was du da "verarbeiten" willst ?

Kein Router der Welt kann Link Local Multicast Adressen routen, das ist prinzipienbedingt ber Standard nicht möglich.
Was aber geht ist das einige Hersteller von Komponenten diese Resourcen selber announcen in anderen Segmenten. Quasi gaukeln diese Router oder oft sind es WLAN Accesspoints per mDNS Resourcen und ihre IP Adressen in Segmenten vor die da gar nicht sind. Heisst dann oft "Bonjour Dienst" oder "Bonjour Dateway".
Dem Client Dienst der das dann nutzt ist das ja egal weil der ja nur einzig die Ziel IP Adresse benötigt um dahin eine Verbindung zu initiieren, die dann stinknormal geroutet wird.

Hi aqui,
ok, aber so ganz verstehe ich es nicht. Ich habe hier mal einen Screenshot von meinem Regelwerk gemacht. Kannst Du hier etwas erkennen? Oder brauchst Du mehr Details?

Christian

Was verstehst du denn nicht ? Das Regelwerk oder mDNS Multicast ?

...das mit dem mDNS MultiCast. Das ist schon recht komplex das Thema und schwierig für mich.

Aber es muss ja irgendeine Ursache haben, warum sich die Player nicht anlernen lassen. An den FW Regeln liegt es nicht, die habe ich komplett rausgenommen (bis auf UpnP und Multicast) und das Problem bestand immer noch. Daher habe ich versucht, es nach dem Ausschlussverfahren einzugrenzen, und ich bin der Meinung, dass hier diese TTL=1 Geschichte zum Tragen kommt. Aber ich bin nicht ganz sicher, wie ich das mit dem Wireshark nachweisen kann.

Christian

und schwierig für mich.

Was genau ist daran schwierig ?? Eigentlich ist das vom Protokoll her gesehen ganz logisch.

Aber ich bin nicht ganz sicher, wie ich das mit dem Wireshark nachweisen kann.

Ans Segment anklemmen und mal checken wie die Komponenten sich verhalten wenn ein neuer Player angelernt werden soll. Dort muss ja irgendwas mit 224.0.0.251 gesendet werden.
Wenn ja und du dir mit dem Wireshark mal das Paket ansiehst wirst du sehen das dort die TTL prinzipienbedingt auf 1 gesetzt ist, es also unroutebar ist und somit nicht in andere Segmente kommt.
https://www.iana.org/assignments/multicast-addresses/multicast-addresses ...