05.07.2018, aktualisiert um 22:41:29 Uhr

6040

Mikrotik Router - DLNA Routing Problem zwischen mehreren VLANs

Hallo,
ich betreibe einen Twonky MediaServer auf einer Qnap-NAS. Solange sich Server und Client im selben Subnetz befinden, funktioniert alles einwandfrei.
Verschiebe ich die Clients in ein separates Subnetz, habe ich gravierende Probleme, für die ich seit tagen keine Lösung finde.

Umgebung:

RB3011, PIM installiert.
VLAN10: qnap-DLNA Server (172.16.10.10)
VLAN30: Sonos-Player
VLAN40: Samsung Smart TV, Windows DLNA-Client (172.16.40.100)
VLAN60: android DLNA-Client (172.16.60.199), Sonos Clontroller

Das Multicast Routing zwischen Sonos Controller und Player läuft einwandfrei.
Probleme gibt es zwischen DLNA-Server und DLNA-Clients in VLAN40 und VLAN60. es dauert teilweise bis zu 10min, bis der Client den Server findet. hat er ihn gefunden, läuft alles einwandfrei.

Ich habe mit dem im Router eingebauten Sniffer den udp-Port 1900 im VLAN10, VLAn40 und VLAN60 angesehen.

VLAN10:

VLAN40:

VLAN60:

In der FW ist folgendes Regel eingestellt:

 /ip firewall filter add action=passthrough chain=forward dst-address-type=multicast port=1900, 1080, 9080 protocol=udp

PIM Details:

Flags: RP - (*,*,RP), WC - (*,G), SG - (S,G), SG_rpt - (S,G,rpt) 
       GROUP           SOURCE          RP             
    WC 224.0.0.0       172.16.30.1     172.16.30.1    
    SG 224.0.1.1       0.0.0.0         172.16.30.1    
    SG 224.0.1.60      0.0.0.0         172.16.30.1    
    SG 239.255.255.250 0.0.0.0         172.16.30.1    
SG_rpt 239.255.255.250 172.16.10.10    172.16.30.1    
SG_rpt 239.255.255.250 172.16.10.20    172.16.30.1    
SG_rpt 239.255.255.250 172.16.10.30    172.16.30.1    
SG_rpt 239.255.255.250 172.16.30.11    172.16.30.1    
SG_rpt 239.255.255.250 172.16.30.21    172.16.30.1    
SG_rpt 239.255.255.250 172.16.30.22    172.16.30.1    
SG_rpt 239.255.255.250 172.16.30.31    172.16.30.1    
SG_rpt 239.255.255.250 172.16.30.33    172.16.30.1    
SG_rpt 239.255.255.250 172.16.30.34    172.16.30.1    
SG_rpt 239.255.255.250 172.16.30.35    172.16.30.1    
SG_rpt 239.255.255.250 172.16.30.36    172.16.30.1    
SG_rpt 239.255.255.250 172.16.30.41    172.16.30.1    
SG_rpt 239.255.255.250 172.16.30.50    172.16.30.1    
SG_rpt 239.255.255.250 172.16.40.100   172.16.30.1    
SG_rpt 239.255.255.250 172.16.60.198   172.16.30.1

/routing pim mfc print detail
 group=239.255.255.250 source=172.16.10.10 rp=172.16.30.1 upstream-interface=vlan10 downstream-interfaces=vlan30,vlan40,vlan60 
 group=239.255.255.250 source=172.16.10.20 rp=172.16.30.1 upstream-interface=vlan10 downstream-interfaces=vlan30,vlan40,vlan60 
 group=239.255.255.250 source=172.16.10.30 rp=172.16.30.1 upstream-interface=vlan10 downstream-interfaces=vlan30,vlan40,vlan60 
 group=239.255.255.250 source=172.16.30.12 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60 
 group=239.255.255.250 source=172.16.30.21 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60 
 group=239.255.255.250 source=172.16.30.31 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60 
 group=239.255.255.250 source=172.16.30.33 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60 
 group=239.255.255.250 source=172.16.30.35 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60 
 group=239.255.255.250 source=172.16.30.36 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60 
 group=239.255.255.250 source=172.16.40.100 rp=172.16.30.1 upstream-interface=vlan40 downstream-interfaces=vlan10,vlan30,vlan60 
 group=239.255.255.250 source=172.16.60.198 rp=172.16.30.1 upstream-interface=vlan60 downstream-interfaces=vlan10,vlan30,vlan40

Man kann erkennen, dass die Search-Pakete der Clients zwar im VLAN10 ankommen, aber die Notify Pakete des servers nicht in die VLANs40 und 60 geleeitet werden. Das passiert nur sporadisch und ich habe keine Idee mehr, an welcher Schraube hier zu drehen ist.

Kann jemand helfen?

Danke und Gruß,
Christian

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

Content-ID: 379292

Url: https://administrator.de/contentid/379292

Ausgedruckt am: 23.11.2024 um 11:11 Uhr

12 Kommentare

Neuester Kommentar

Zitat von @Spartacus:
In der FW ist folgendes Regel eingestellt:

 /ip firewall filter add action=passthrough chain=forward dst-address-type=multicast port=1900, 1080, 9080 protocol=udp

Ich glaube du solltest dir besser noch mal den Parameter action genauer ansehen, denn so bringt die Firewall-Regel rein gar nüscht!!
https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter#Properties

passthrough - if packet is matched by the rule, increase counter and go to next rule (useful for statistics).

accept - accept the packet. Packet is not passed to next firewall rule.

Hi,
ich danke Dir recht herzlich für Deinen Hinweis. Habe es in "accept" geändert, hat aber leider nichts gebracht. Funktioniert immer noch nicht!

Christian

Hier erstmal die Grundlagen zur VLAN Einrichtung und Routing:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Hast du das so umgesetzt ?

Sonos nutzt Multicast was so ohne Multicast Routing (PIM) nicht routebar ist. Wenn dem so ist und das Streaming per Multicast passiert musst du zwingend PIM Routing einrichten.
UPNP mit Mikrotik Routerboard hEX PoE und D-Link DGS-1210-24 Switch
Ob es wirklich Multicast ist verrät dir dein bester Freund hier der Wireshark Sniffer

Natürlich testet man das erstmal OHNE Paket Filter aus um sich nicht gleich selber ein bein zu stellen und erst wenn es wasserdicht und fehlerfrei klappt zieht man die Schotten wieder dicht...

Hi aqui,
Sonos ist nicht mein Problem, das läuft über PIM einwandfrei.

Mein Problem ist DLNA über PIM. Server und Client finden sich zwar, aber es dauert unendlich lange, bis die Connection zwischen DLNA-Client und Twonky Server zustande kommt. Wenn die einmal steht, klappt auch der Stream.

Die Pakete, die ausgetauscht werden, kannst Du oben sehen und es sieht so aus, als würden einige M-Search bzw. Notify-Pakete nicht ins andere VLAN weitergeleitet, bzw. nur verzögert weitergeleitet. ICh verstehe aber nicht, woran das liegt? Beim Sonos läuft es doch reibungslos. Ggf. ist aber auch der Twonky-DLNA Server das Problem.

Mein TV finden den Server überhaupt nicht mehr!

Christian

Mein Problem ist DLNA über PIM

Hast du mal gesniffert welche Multicast Gruppe das DLNA benutzt ?? Wenn du Pech hast ist das ein Link Local Multicast 224.0.0.0 bis 224.0.0.255. Die haben eine feste TTL von 1 und sind prinzipienbedingt nicht routebar.
Dafür brauchst du dann einen Proxy.
Sieh dir das mit dem Wireshark mal an und achte mal genau auf den TTL Wert im Paket !

Hi,
ich habe den Hai jetzt mal installiert, aber ich bin etwas überfordert! Wonach muss ich jetzt filtern?

udp 1900, und IP des DLNA-Servers. Und dann? Wo muss ich dann genau drauf gucken?

Danke Dir,
Christian

Hi,
ich habe mal in so ein Paket reingeschaut. Da steht eine TTL von 4.

Ist das die Stelle, die gemeint ist?

BTW:
ich habe auch eine Rule definiert, die die TTL ändert. Bringt aber auch nix.

/ip firewall mangle
add action=change-ttl chain=prerouting dst-address-type="" log-prefix=TTL+ \  
    new-ttl=set:64 passthrough=no port=1900 protocol=udp

Ach ja, wie ist denn die Syntax im dem Wire-Shark Filter?
Ich habe es nicht geschafft, gleichzeitig auf "IP-addr" und udp==1900 zu filtern.

Danke und Gruß
Christian.

Ist das die Stelle, die gemeint ist?

Ja richtig. Das ist auch eine 239er Group Adresse die ist routebar mit PIM.

die die TTL ändert. Bringt aber auch nix.

Bei Link Local ist das sinnlos denn damit würdes du den Standard verletzten. Das wird der Router auch sicher nicht zulassen in der Konfig. Sollte er zumindestens nicht

Ach ja, wie ist denn die Syntax im dem Wire-Shark Filter?

Welchen der Filter meinst du denn ? Den Capture oder den Display Filter ??
https://wiki.wireshark.org/CaptureFilters
Filter lautet dann host x.y.z.h and port 1900 nur Multicast siehst du mit multicast
https://wiki.wireshark.org/DisplayFilters
da ist es ip.addr == 172.16.10.10 and udp.port eq 1900

Hast du das mal ganz ohne Filter auf dem Router probiert ? Ist im ersten Schritt besser um sich nicht selber Fallen durch falsche Filter zu stellen.
Wenn du einen Client hast der die Gruppenadresse 239.255.255.250 requestet per IGMP dann solltest du die auch in den anderen Segmenten sehen bei aktivem PIM.
Du kannst auch mit VLC mal einen Test machen wenn du Content (Video) etc. mal an diese Gruppenadresse streamst. Wie das geht steht hier:
Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)
Dazu solltest du natürlich vorher alles was sonst diese Gruppenadresse nutzt aus dem Netzwerk entfernen. Wie beim IP gilt auch beim Multicast das Adressen einzigartig im Netz sein müssen. Klar denn letztlich ist das ja auch IP

Hast du bei PIM einen Rendezvous Point konfiguriert ?

Hi aqui,
danke Dir schon mal für Deine neuen Anregungen.

Ein RP ist definiert. Das ist eine Adresse aus dem vlan30 (Sonos). Habe aber auch mal den Sonos komplett rausgeschmissen und das vlan40 als rp eingetragen. Hilft leider alles nix. Die PIM Config siehst Du übrigens weiter oben im thread).

Gestern den Router vom Internet getrennt und alle FW-Rules (bis auf die DLNA Multicast Weiterleitung) deaktiviert. Bring leider nix.

Das mit dem VLC probiere ich mal aus und melde mich. Vielleicht ist der Twonky auf der qnap etwas zickig, denn Sonos läuft ja wunderbar...

Christian

Das ist eine Adresse aus dem vlan30 (Sonos)

Ja das ist egal welche IP des MT das ist. Das muss eine eins seiner physischen Interfaces sein.
Hast du ggf. einen Switch dahinter und ist dort IGMP Snooping aktiviert ??
Du hast Recht, normal ist Sonos immer der Problemfall. Zeigt aber wunderbar das man das auch mit PIM gewuppt bekommt

Hi,
ja da ist der Cisco SG200 hinter aber IGMP Snooping ist abgeschaltet. Allerdings hatte ich es auf der MT Bridge mal aktiviert, hatte irgendwo gelesen, dass man das machen soll. Aber so oder so, bring das auch nix.

Ich denke wirklich es liegt am Twonky. Wenn das mit dem VLC klappt, dann liegt es wirklich am Twonky. Werde ich aber am WE wahrscheinlich nicht zu kommen...melde mich hierzu aber auf jeden Fall!

Christian

btw:
Ich habe da noch nen Problem mit den cAPs, da passt was mit dem Local Forwarding nicht zusammen... Ich wechsel mal in den anderen Thread

ja da ist der Cisco SG200 hinter aber IGMP Snooping ist abgeschaltet

Das ist ein großer Fehler ! Damit flutet der Switch ja dann alle MC Pakete, was massiv auf die Performance geht sollte das mehr sein, denn er muss das mit seiner CPU machen statt in HW.
IGMP Snooping auf ON sollte immer Default Pflicht sein bei managebaren Switches und immer aktiviert sein !!
Zudem sollte der Switch auch immer IGMP Querrier sein als zentrales Element im LAN.