26.10.2017

17516

UPNP mit Mikrotik Routerboard hEX PoE und D-Link DGS-1210-24 Switch

Hallo,

seit neuestem versuche ich mein Heimnetzwerk neu zu strukturieren und bin dank vieler hilfreicher Diskussionen hier schon eine ganze Ecke weiter gekommen.
Kurze Anmerkung vorweg, ich bin kein Netzwerkprofi aber arbeite mich bedingt durch mein Vorhaben gerne immer tiefer ein. Verzeiht mir also, wenn ich Euren Gedanken vielleicht nicht immer sofort folgen kann.

Wie aus dem Thema zu ersehen ist, versuche ich mich an uPNP. Das Netzwerk steht soweit, alle Geräte sind erreichbar und was ins Internet soll, kann dies auch. Also der Grundstock steht.
Das Netzwerk sieht wie folgt aus:

Der Switch von D-Link (DGS-1210-24) nimmt alle Dosen und die bei ihm stehenden Geräte auf. Somit hängt alles beginnend von den Access-Points für WLAN (darüber Mobilgeräte mit DLNA-Client), dem Sat-Receiver, dem AVR-Receiver mit DLNA-Client bis hin zum Rechner mit uPNP-Server und NAS direkt am Switch.
Die Geräte sind in VLANS unterteilt. Ich nenne mal die, welche meiner Meinung nach für den Fall relevant sind:

VLAN mit der ID 120 - Access-Points mit allen mobilen Geräten
VLAN mit der ID 130 - Win10 Rechner mit dem uPNP-Server drauf.
VLAN mit der ID 100 - Netzwerk für AV-Receiver mit DLNA-Client und artverwandten Geräte

Diese VLANs gehen auf den Mikrotip, sind dort sauber mit Interfaces, Adressen, einzelnen DHCP-Servern und allem was dazu gehört angelegt. Ich kann vom mobilen Device oder Rechner per WLAN mittels RDP auf den Rechner im VLAN 130. Der Rechner kann ins Internet, alle anderen Geräte schaffen das aus. Alle bekommen die IP-Adressen in den Bereichen, die ich für sie vorgesehen habe, also für mich sieht es bis hierhin erstmal gut aus. Grundfunktion hergestellt.

Jetzt bin ich schon soweit, dass ich auf den D-Link "IGMP Snooping" für alle Ports aktiviert habe. Danach konnte ich auf dem Switch ersehen, dass im VLAN 130 eine Quelle Multicast in die weite Welt ruft. Das hat mich schon froh gestimmt. Mit Hilfe der dort vorgefundenen Daten (VLAN-ID, Portnummer, Multicast-IP 239.255.255.255 und MAC 01:00:5E:FF:FF:FA habe ich auf dem Switch "Multicast Forwarding" konfiguriert. Ich habe dort das VLAN "130" mit Multicast MAC-Adresse "01-00-5E-FF-FF-FA" und dem Port des Win10-Rechners angegeben. Der Port des Rechners auf dem Switch passt zu der Angabe des IGMP Snooping Dialoges.
Somit war ich erstmal der Meinung, dass ich auf dem Switch alles gemacht hätte.

Auf dem Mikrotik habe ich "IP > uPNP" aktiviert und alle Interfaces die ich habe (LAN-Ports ether1-5 sowie alle VLAN-Ports) drauf gelegt sowie "external" aktiviert.

Jetzt stehe ich hier und die Clients sehen den uPNP-Server in VLAN 130 nicht.
Seht Ihr spontan den Fehler im Bild? Ich sehe ihn leider nicht bzw. kann auch mögliche Lücken, welche das Fehlverhalten erklären, mangels wissen nicht entdecken.
Ich hoffe Ihr habt den einen oder anderen sachdienlichen Hinweis. Wenn Ihr noch mehr Informationen benötigt stehe ich diese sehr gerne zur Verfügung!

Gruß,
Jens

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

Content-ID: 352942

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

Ausgedruckt am: 21.11.2024 um 10:11 Uhr

25 Kommentare

Neuester Kommentar

Hi.

Auf dem Mikrotik habe ich "IP > uPNP" aktiviert und alle Interfaces die ich habe (LAN-Ports ether1-5 sowie alle VLAN-Ports) drauf gelegt sowie "external" aktiviert.

Das hat damit nichts zu tun. Das was du brauchst findest du unter /routing PIM (Platform Independend Multicast) oder den IGMP Proxy (für simples uPnP, ebenfalls zu finden im routing Menü) , welches die Multicastpakete VLAN übergreifend routet, da, wie du hoffentlich weist Multicast per Default Ihre eigene Layer-2 Domain nicht verlassen.
Dazu brauchst du das multicast package:
https://wiki.mikrotik.com/wiki/Manual:Routing/IGMP-Proxy
https://wiki.mikrotik.com/wiki/Manual:Routing/Multicast

Dort definiert man ein Upstream und ein oder mehrere Downstream Interfaces auf welche die Multicast-Packages verteilt werden.

Bitte beachte das es Multicast-Protokolle gibt die auch mit PIM nicht funktionieren, wie z.B. das Bonjour-Protokoll von Apple welches Multicast-DNS verwendet. Hier ist dann ein Proxy wie Avahi von Nöten den man bspw. auf einen Raspi installieren kann.

versuche ich mich an uPNP

Normal ein NoGo im Netzwerk. Auf alle Fälle aber am Internet Router, denn dort sollte UPnP immer dekativiert sein, weil man damit die Firewall manipulieren kann mit fatalen Folgen.
Ob du generell willst das UPnP "rumfummeln" darf an deinen Infrastruktur Komponenten wie Router oder Switch musst du selber wissen. Verantwortungsvolle Netzwerker lassen es logischerweise immer AUS aus naheliegenden Gründen ! Mal abgesehen davon das man es dort auch gar nicht braucht und es mit deinem eigentlichen Problem auch nicht das geringste zu tun hat.
Ggf. solltest du also dein Vorhaben nochmal überdenken ?!

also für mich sieht es bis hierhin erstmal gut aus. Grundfunktion hergestellt.

Yepp, das sieht in der Tat gut aus...!

dass im VLAN 130 eine Quelle Multicast in die weite Welt ruft.

Nicht in die weite Welt, das ist Unsinn. Die MC Gruppe ist immer nur in der Layer 2 Domain aktiv, also rein in dem VLAN Segment sonst nirgendwo.
Wie man mit Multicast auch einmal testweise im LAN umgeht erklärt dieser Forenthread!

Fazit:
Dringend Grundlagen zum Multicasting lesen bzw. ansehen und verstehen !!

https://www.youtube.com/watch?v=AvbSMBKBZgY

Am besten ALLE Folgen !!

Multicast-IP 239.255.255.255

Keine gute Wahl !

Auch für Multicast gibt es private Bereiche analog zum RFC 1918 der privaten IP Netze !!
Dafür ist der Bereich 239.253.0.0 /16 und 239.192.0.0 /14 fest reserviert und du solltest tunlichst auch diese Adressen dafür nutzen. Siehe RFC 2365.
Idealerweise also Irgendwetwas mit 239.192.x.y.

Vermutlich machst du einen Denkfehler der aus fehlenden Netzwerk Kentnissen resultiert.
IGMP Snooping ist eine reine Layer 2 Funktion, wirkt also nur im lokalen Layer 2 Segment.
Es ist richtig das global auf dem Switch zu aktivieren damit der Switch das für alle VLANs macht und nicht nur für ein spezifisches.
Das reduziert Traffic und schont die Performance des Switches bzw. Netzes !
IGMP hat aber nichts mit Multicast Routing zu tun, also dem Layer 3 Forwarding von Multicast !
Um Multicast in die anderen VLAN Segmente zu bekommen musst du Multicast Routing aktivieren mit PIM Sparse Mode und eine Rendezvous Point IP Adresse auf dem Mikrotik setzen.
Kollege @kokosnuss hat ja schon alles Relevante dazu gesagt oben.

~~Dazu ist zwingend das Multicast Package auf dem MT zu installieren was im Default auf den MIPS basierten MT Modellen nicht aktiv bzw. nicht installiert ist.~~
Ist seit Version 7 im Default mit an Bord.
Du lädst dir dazu das "Extra Package" runter: https://mikrotik.com/download für deine Plattform und die korrespondierende Version ! (aktuell 6.48.3)
Dann entpackst du das .zip File
In Winbox gehst du unter "Files" und ziehst einfach das Multicast Package multicast-6.40.4-mipsbe.npk in den Dateibereich per Drag and Drop.
Danach rebootest du den MT
Wenn du jetzt unter Packages gehst dann siehst du das Multicast Routing als Feature installiert ist und auch aktiviert ist im Setup des MT:

Danach gehst du auf deine Layer 3 Interfaces am MT und konfigurierst dort PIM Routing. Zusätzlich musst du eine Rendezvous Point IP Adresse angeben. Das kann irgendeine IP Adresse eines deiner Interfaces sein. Am besten die die niemals oder selten in den Down State geht oder gehen und nahe des Multicast Senders sind.

bzw. RP

Die Warnung vom Kollegen @kokosnuss (aus dem Forum abgemeldet deshalb "134464" oben) ist berechtigt.
Beachte das es Multicast Gruppen gibt die reine local Multicasts sind. (Sog. Link Local Multicast Goups) Diese haben ein TTL von 1, können also per se NICHT geroutet werden. Bonjour bzw. mDNS gehören dazu.
Hier hilft dann nur ein Proxy Server wie hier beschrieben.

Weitere Multicast Routing Beispiele zeigt das PIM Routing mit pfSense und OPNsense Firewalls:
Multicast über VLANs hinweg auf PfSense

Danke für die tollen Hinweise!
Ja, ich bin noch am Anfang was das angeht. Aber ich gelobe Besserung!

Ich werde berichten, wie weit ich mit der Verarbeitung Eurer Hinweise komme.

Gruß,
Jens

Wir sind gespannt...

Hallo zusammen und nachträglich,

Ich werde berichten, wie weit ich mit der Verarbeitung Eurer Hinweise komme.

Wenn alle Stricke reißen sollten, kann man auch folgendes mit dem MikroTik Router machen;
- WireShark installieren und dann heraus finden welche Protokolle und Ports vom uPnP Server benutzt werden
- Den SOCKS Proxy am MikroTik aktivieren und dann dort die TCP/UDP Ports freigeben und dann läuft damit auch uPnP
wie gewünscht wenn man einen Routerkaskade hat, also der MikroTik Router der zweite (interne) Router ist empfiehlt sich
das ganze Vorhaben auf jeden Fall. Und Netzwerk interne auch, sollte der MikroTik Router aber der WAN Router sein sollte
man davon Abstand nehmen.

Gruß
Dobby

Es geht ja gar nicht um UPnP sondern Multicast wie sich herausgestellt hat

Und da nützt ihm der Socks Proxy nix.

So, ich habe mich mal an dem Package versucht. Leider werde ich noch nicht so recht aus den Beschreibungen zu dem Package schlau, was wohl daran liegt, das vor dem Gerät, was für Profis gedacht ist, im Moment noch ein kleiner Lehrling sitzt.

Also folgendes habe ich mal gemacht, weil ich es mir ein wenig versucht habe zusammenzureimen (ich fürchte das ist ein Schüttelreim geworden!):

Mein Ansatz war erstmal die Schrotflinte auszupacken und all umfassend reinzukonfigurieren, um so sehen zu sehen ob es überhaupt funktioniert. Deswegen habe ich unter Interfaces mal alle reingenommen, inkl. der VLAN-Interface, und pim sowie igmp aktiviert.
Als Rendezvous Point habe ich die IP-Adresse des ether2 genommen und als Group "239.255.255.250/32". Diese Adresse habe ich mir daraus abgeleitet, dass Sie unter dem Karteireiter "IGMP Groups" zu finden ist, und weil ich im "Packet Sniffer" sehen konnte, dass der Rechner, auf dem alles installiert ist, dorthin seine Multicast-Leidenschaft äußert. Zumindest sah das für mich so aus.
Diese Gruppe habe ich unter "RP Candidates" und "BSR Candidates" (obwohl mir letzteres von der Erläuterung nichts gesagt hat, ich dachte mir viel hilft viel) ebenfalls hinterlegt

Was mir alle die anderen Punkte sagen sollen, weiß ich leider nicht. Im Bereich "MRIB" sind auch alle meine Adressbereiche mit den jeweiligen Interfaces hinterlegt. Ich weiß nicht mehr genau, ob ich das war oder der Router das selber gemacht hat. Ganz oben in dieser Liste steht ein Eintrag mit Source 0.0.0.0/0 und der hat als Gateway meinen Speedport als Einstieg zum Internet drin. Ob das etwa ein Problem ist? Ich fürchte den Speedport hatte ich noch gar nicht erwähnt

Also der ist mein Zugang zum Internet und der Mikrotik soll mein Netzwerk intern regeln. Der Speedport nimmt also keinerlei Aufgaben großartig wahr.

Unter dem Karteireiter "MFC" sehe ich nun 3 Einträge für meine Gruppe. Einer als Source mein Rechner, der die Quelle für den DLNA-Client ist. Der RP passt, dass ist mein angelegter. Incoming Interface passt auch und Outgoing ist unter anderem das VLAN-Interface vom Empfänger, dem AV-Receiver drin. Sieht für mich erstmal gut aus.
Ferner sehe ich dort einen Eintrag mit der Source Empfänger AV-Receiver. RP ist wieder der von mir angelegte. Incoming das korrekte Interface und beim Outgoing ist unter anderem das Interface des Rechner-VLANs drin.
Ich sehe dort aber auch noch einen Eintrag mit der Source des Empfängers für die Gruppe "239.255.250.250", der auf den RP 0.0.0.0 will. Outgoing ist leer. Was mir der Eintrag sagen soll, ist mir schleierhaft.

Bei den Joins sehe ich den besagten Rechner (Quelle) und den Av-Receiver (Empfänger) mit dem von mir angelegten RP und dem Status joined.
Ferner sehe ich eine Source "0.0.0.0" mit dem von mir angelegten RP und Status joined.

Irgendwie finde ich, dass diese Konstellation gar nicht so schlecht klingt, nichts desto trotz ist Funkstille unter den beiden Geräten - also hinsichtlich DLNA. Beide sind per Kabel angeschloßen, also nicht Wireless dabei im Spiel.

Hast Du einen oder mehrere Fehler im Bild gefunden?

Das Verfahren ist hier eigentlich sehr anschaulich erklärt
https://wiki.mikrotik.com/wiki/Manual:Multicast_detailed_example
Wenn du das durch hast sollten eigentlich keine Fragen mehr offen sein.

Hm, das muss mir irgendwie durch die Lappen gegangen sein. Ich lese mir das mal in Ruhe durch!
Danke für den Link!

Da bin ich nochmal.

Jetzt klappt es mit PIM wie ich es oben konfiguriert habe! Ich hatte das Multicast Forwarding auf dem Switch noch etwas unvollständig hinterlegt! Dort war bis eben nur das VLAN des Rechners (Quelle) und nicht des AV-Recevers (Empfänger) drin. Kaum habe ich das noch nachgezogen läuft es

Solltet Ihr dennoch Denkfehler meinerseits bei der Konfiguration von PIM wie oben beschrieben finden, will ich trotz des Teilerfolges gerne weiter lernen

Eine Schönheitsfehler habe ich noch festgestellt. Ein DLNA-Player auf dem Handy kommt trotzdem nicht dran. Auf dem Switch habe ich auch für das VLAN alles notwendige konfiguriert.
Oder kann es daran liegen, dass der Player nicht standardkonform arbeitet? Denn eigentlich müsste es doch klappen, oder?

Das mit dem DLNA-Client hat sich wohl auch geklärt. Manche funktionieren, manche nicht. Ich denke mal nicht jeder finktioniert nach Standard, was erst auffällt, wenn nicht alles im selben Netz steht und die ersten Koppelelemente dazu kommen.

Die Baustellen reissen nicht ab, habe ich schon festgestellt. Das nächste Kapitel nennt sich Musiccast. Bei Airprint habe ich den Drucker mit den druckenden Geräten schon in einen Netzbereich gestellt, weil das wohl nicht anders geht. Mal sehen wie ich bei der Musiccast-Baustelle vorankomme. Oder habt Ihr damit zufällig schon Erfahrung?

Zitat von @Niffchen:

Das mit dem DLNA-Client hat sich wohl auch geklärt. Manche funktionieren, manche nicht.

Das liegt daran das manche zur Erkennung von Dlna Quellen unterschiedliche Verfahren einsetzen.

Bei Airprint habe ich den Drucker mit den druckenden Geräten schon in einen Netzbereich gestellt, weil das wohl nicht anders geht.

Doch das geht, hatten wir oben schon geschrieben, du brauchst einen Avahi Daemon see mit mDNS umgehen kann.

Mal sehen wie ich bei der Musiccast-Baustelle vorankomme. Oder habt Ihr damit zufällig schon Erfahrung?

Musiccast kenne ich momentan noch leider nicht, basiert aber auf UDP Multicasts und das unterstützt der Mikrotik IMHO noch nicht.
https://github.com/neutmute/neutmute.github.io/blob/master/_posts/blog/2 ...

Leider werde ich noch nicht so recht aus den Beschreibungen zu dem Package schlau

Woran hapert es denn ??
Die "Beschreibung" ist ja auch erstmal völlig egal. Als erstes sollst du ja ewrstmal nur das Package instrallierenb auf dem Router !!!
Hat das denn wenigstens geklappt ? Siehst du die Option PIM Routing zu konfigurieren im Setup ??
DAS wäre wichtig, denn das zeigt das das Feature sauber installiert und erkannt wurde !!!
Bis dahin solltest du erstmal kommen.

im Moment noch ein kleiner Lehrling sitzt.

Nein,. solche simplen Basics wie erstmal die grundlegende Installation sollte man auch als Laie können.

Als Rendezvous Point habe ich die IP-Adresse des ether2 genommen und als Group "239.255.255.250/32"

Richtig und falsch !
Richtig ist der RP aber vollkommen falsch die Group anzugeben ! Hier MUSS der default 0.0.0.0 stehen. Damit routet der Router dann ALLE Multicast Gruppen unjd nicht nur eine spezifische !
Das solltest du also besser schnell wieder korrigieren !

Diese Gruppe habe ich unter "RP Candidates" und "BSR Candidates"

Das ist falsch bzw. ganz falsch !!
Warum: Damit aktivierst du das BSR Protocoll auf dem MT:
http://blog.ine.com/2009/04/07/understanding-bsr-protocol/
BSR nutzt man zur dynamischen Weiterleitung von RPs in einem Multicast Netz mit mehreren PIM Routern. BSR distribuiert dann die RPs mit Backup RP in einem Nertzwerk vollkommen automatisch.
Das ist bei dir vollkommen überflüssig und sinnfrei, da du keine multiplen MC PIM Router hast im Netz.
Finger weg also von den "Candidate" Konfigs !!! Dort musst du NICHTS eintragen weil du BSR nicht nutzt bzw. nutzen sollst !!
Abgesehen davon ist die BSR Implementation auf dem MT in der 6.x er Version vom Router OS total buggy und funktioniert nicht richtig. Ein weiterer gewichtiger Grund das NICHT zu nutzen.
Also auch das bitte löschen ! Du brauchst lediglich PIM Routing auf den beteiligten Interfaces wo MC rüber soll und die statische RP Adresse !! Mehr nicht !

ich dachte mir viel hilft viel

Ganz Falsch !
Es gilt: Weniger ist mehr. Und bitte nicht denken sondern nachdenken !!!

Was mir alle die anderen Punkte sagen sollen, weiß ich leider nicht.

Deshalb belasse diese bitte auch auf deren Default Settings !

Ich fürchte den Speedport hatte ich noch gar nicht erwähnt

Igittt... das Gruseligste und Übelste an Router was man sich antun kann. Aber egal...das ist nicht das Problem. Der muss ja nicht MC routen und ist nur der doofe Internet Router an den der MT alles forwardet.
Solche einfachen Basics kann auch der doofe Speedport.
Solange du beachtest das der kein statisches Routing kann und du auf dem WAN Port des MT (also der der zum Speedport geht) damit dann zwingend NAT (Adress Translation, Masquerading) machen musst !!

rgendwie finde ich, dass diese Konstellation gar nicht so schlecht klingt,

Das stimmt. Sieht soweit schon ganz gut aus. Wenn du die o.a. Anpassungen machst, insbesondere die Finger vom BSR Setup (Candidate xyz) lässt, dann funktioniert das auch !

Gruppe "239.255.250.250"

Wie gesagt. Nicht wirklich gut. Halte dich an den Standard und nutze eine dafür reservierte Gruppe im Bereich 239.253.x.y /16 oder 239.192.x.y /16 !
Sofern du das selber bestimmen kannst im Setup !

du brauchst einen Avahi Daemon see mit mDNS umgehen kann.

Richtig ! Das ist mDNS und nutzt eine local MC Gruppe mit TTL = 1 das ist nicht routebar aber ein kleiner Raspberry als mDNS Proxy bringt das auch zum Fliegen...siehe oben.

Zitat von @134464:

Das liegt daran das manche zur Erkennung von Dlna Quellen unterschiedliche Verfahren einsetzen.

Wieder etwas gelernt!

Doch das geht, hatten wir oben schon geschrieben, du brauchst einen Avahi Daemon see mit mDNS umgehen kann.

Hatte ich in der Tat verdrängt. Ich werde es dann auf diese Art und Weise angegen, wenn gleich es mich schon nervt das Netz durch solche Sonderlocken aufzublähen. Es macht es nicht gerade übersichtlicher. Aber was tut man nicht alles für lieb gewonnene Spielereien.

Danke für den Link. Das schaue ich mir mal an!

Zitat von @aqui:

Woran hapert es denn ??
Die "Beschreibung" ist ja auch erstmal völlig egal. Als erstes sollst du ja ewrstmal nur das Package instrallierenb auf dem Router !!!
Hat das denn wenigstens geklappt ? Siehst du die Option PIM Routing zu konfigurieren im Setup ??
DAS wäre wichtig, denn das zeigt das das Feature sauber installiert und erkannt wurde !!!
Bis dahin solltest du erstmal kommen.

Hm, ich sollte wohl dazu sagen, dass ich wenn die Finger nicht davon lassen kann und direkt an die Konfiguration gegangen bin. Und dafür hat mir die Dokumentation nicht so recht geholfen. Es mangelt wohl an den Grundlagen bei mir, da ist noch viel zu tun.

Danke für die Erläuterung. Habe ich direkt berichtigt.

Habe ich berichtigt. Deine Erläuterung hat mich deutlich weiter gebracht. Danke dafür!

Das NAT habe ich wie von Dir beschrieben direkt zu Anfang eingebaut. Mal sehen ob es irgendwann noch Gründe gibt den Speedport zu ersetzen. So in der Kombination tut er es erstmal.

Gruppe "239.255.250.250"

Wie gesagt. Nicht wirklich gut. Halte dich an den Standard und nutze eine dafür reservierte Gruppe im Bereich 239.253.x.y /16 oder 239.192.x.y /16 !
Sofern du das selber bestimmen kannst im Setup !

Das steht auf dem Zettel. Ich muss mal schauen ob ich das bei der Anwendung anpassen kann.

du brauchst einen Avahi Daemon see mit mDNS umgehen kann.

Richtig ! Das ist mDNS und nutzt eine local MC Gruppe mit TTL = 1 das ist nicht routebar aber ein kleiner Raspberry als mDNS Proxy bringt das auch zum Fliegen...siehe oben.

Das werde ich als nächstes so tun. Ich bin immer wieder erstaunt, dass die Baustellen deutlich mehr werden als anfänglich vermutet. Aber was soll es, ich hatte wohl etwas naive Vorstellungen. Jetzt sehe ich als Lernprojekt

Und dafür hat mir die Dokumentation nicht so recht geholfen.

Deswegen immer besser hier fragen

Mal sehen ob es irgendwann noch Gründe gibt den Speedport zu ersetzen.

Noch ??? Richtige Netzwerker setzen so einen Schrott nicht ein und bestimmen ihre Hardware immer selber.
Eine Fritzbüx wäre da die bessere Wahl wenns denn Consumer Equipment sein soll.
Noch besser wäre es den MT statt so einer Kaskade mit einem einfachen nur Modem direkt anzuschliessen. Siehe hier:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
oder Alternative 1 hier:
Kopplung von 2 Routern am DSL Port
Da gibts noch Verbesserungs Potentzial

Das steht auf dem Zettel. Ich muss mal schauen ob ich das bei der Anwendung anpassen kann.

Wenns nicht geht dann so lassen.... Ein KO Kriterium ist das nicht.

Jetzt sehe ich als Lernprojekt

Das ist die richtige Einstellung.

Und die Erfahrungen kann dir keiner mehr nehmen.

Zitat von @aqui:

Die Warung vom Kollegen Kokosnuss ist berechtigt. Beachte das es Multicast Gruppen gibt die reine local Multicasts sind. Diese haben ein TTL von 1, können also per se NICHT geroutet werden. Bonjour bzw. mDNS gehören dazu.
Hier hilft dann nur ein Proxy Server wie hier beschrieben.

Also ich habe den Avahi jetzt wie beschrieben aufgesetzt und er hat auch schon "Apple Filesharing" gefunden. Jetzt stelle ich mir nur die Frage, wie ich ihn in den Mikrotik einbinden muss. Irgendwie muss ja alles in die ganzen Netze transportiert werden, damit die dort angesiedelten Geräte auch etwas davon wissen ... ich muss das abstrakte Denken bei mir definitiv weiter entwickeln ...

Ich habe jetzt diverse VLANs auf dem Raspi angelegt, damit das mit den VLAN-IDs auf dem Mikrotik zu bestehnden VLANs passt.
Wenn ich ihn jetzt aber direkt an einen Port an den Mikrotik anschließe, haut das mit den dort hinterlegten VLANs nicht mehr hin. Diese habe ich ja auch einen anderen Port gelegt.

Wenn ich auf dem D-Link etwas mit Tagged Port mache, dann ist das nach meinem Verständnis das zusammenfassen diverser VLANs auf einem Port nach oben. Oder muss ich den Raspi auf dem Switchin eigenes VLAN stecken und dieses mit einem weiteren Tagged Port versehen, den ich in alle anderen VLANs mit aufnehmen? Da habe ich gerade einen Knoten im Kopf ...

stelle ich mir nur die Frage, wie ich ihn in den Mikrotik einbinden muss.

Gar nicht !
Der Avahi broadcastet ja all diese Informationen mit einer local Multicast Adresse an die entsprechenden Clients in dem Netzsegment. Dort gibt er ihnen dann ja auch via mDNS die Ziel IP Adressen mit über die dieser Dienst zu erreichen ist und dann greift wieder stinknormales IP Routing.
Der MT muss also nur sauber routen können (was er bei dir ja kann) und gut iss.

Ich habe jetzt diverse VLANs auf dem Raspi angelegt

So wie hier beschrieben ??:
Netzwerk Management Server mit Raspberry Pi

Wenn ich ihn jetzt aber direkt an einen Port an den Mikrotik anschließe, haut das mit den dort hinterlegten VLANs nicht mehr hin.

Mmmhhh...wenn du den RasPi Port entsprechend der o.a. Beschreibung angelegt hast dann ist das ja ein tagged Port sprich er sendet bis aufs Native VLAN alle Pakete zu den anderen VLANs an diesem Port dann mit einem VLAN Tag aus.
Logischerweise muss der Port am MT an dem der RasPi angeschlossen ist dann auch TAGGED sein !!
Hast du das so umgesetzt ??? Vermutlich wohl nicht

Hier wäre ein Output der Datei etc/network/interfaces und ein Screenshot der MT Port Konfig sehr hilfreich gewesen um dir zielführend helfen zu können. Aber leider fehlte das

Diese habe ich ja auch einen anderen Port gelegt.

Bahnhof ? Ägypten ? Rembrandt ?

Wenn ich auf dem D-Link etwas mit Tagged Port mache, dann ist das nach meinem Verständnis das zusammenfassen diverser VLANs auf einem Port nach oben.

Gernau so ist es !
Guckst du hier für eine Schnellschulung zum Therma VLANs:
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
Oder auch hier im hiesigen VLAN Tutorial:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern

Oder muss ich den Raspi auf dem Switchin eigenes VLAN stecken und dieses mit einem weiteren Tagged Port versehen, den ich in alle anderen VLANs mit aufnehmen?

Ja und Nein....
Ja, was die tagged VLANs auf dem Port anbetrifft
Nein was das Native VLAN anbetrifft. Also das VLAN in das der Port untagged Pakete forwardet im Switch. In der Regel ist das das VLAN 1.
Der RasPi sendet alle Pakete die vom phyischen Port z.B. eth1 kommen immer untagged. (Native VLAN)
Beispiel mit externem USB Adapter an eth1 am RasPi:
allow-hotplug eth1
iface eth1 inet static --> Das ist das native VLAN, untagged
address 10.1.1.1
netmask 255.255.255.0
auto vlan10
iface vlan10 inet static --> Das ist das VLAN 10 Interface auf eth1 , tagged Pakete mit VLAN ID 10
address 10.10.1.1
netmask 255.255.255.0
vlan_raw_device eth1
auto vlan20
iface vlan20 inet static --> Das ist das VLAN 20 Interface auf eth1 , tagged Pakete mit VLAN ID 20
address 10.20.1.1
netmask 255.255.255.0
vlan_raw_device eth1
Der dazu korrespondierende Port am Switch muss tagged für VLAN 10 und 20 eingerichtet sein und das native, oder Default VLAN ist 1.
Damit ist dann der PasPi im VLAN 1 unter 10.1.1.1 und im VLAN 10 unter 10.10.1.1 und im VLAN 20 unter 10.20.1.1 anpingbar.
So einfach ist das !

Da habe ich gerade einen Knoten im Kopf ...

Yepp, das kann man wohl sagen....

Zitat von @aqui:

Ich habe jetzt diverse VLANs auf dem Raspi angelegt

So wie hier beschrieben ??:
Netzwerk Management Server mit Raspberry Pi

Hier mein Auszug. Ich hatte noch ein paar Ungereimtheiten drinnen und habe es nun wie dort genannt angepasst:

auto lo

iface lo inet loopback
iface eth0 inet dhcp

auto vlanA
iface vlanA inet static
address 192.168.A.5
netmask 255.255.255.0
vlan_raw_device eth0

auto vlanB
iface vlanB inet static
address 192.168.B.5
netmask 255.255.255.0
vlan_raw_device eth0

auto vlanC
iface vlanC inet static
address 192.168.C.5
netmask 255.255.255.0
vlan_raw_device eth0

auto vlanD
iface vlanD inet static
address 192.168.D.5
netmask 255.255.255.0
vlan_raw_device eth0

auto vlanE
iface vlanE inet static
address 192.168.E.5
netmask 255.255.255.0
vlan_raw_device eth0

auto vlanF
iface vlanF inet static
address 192.168.F.5
netmask 255.255.255.0
vlan_raw_device eth0

auto vlanG
iface vlanG inet static
address 192.168.G.5
netmask 255.255.255.0
vlan_raw_device eth0

Danach habe ich den Raspi an einen Switchport angeschlossen, der zum default-VLAN gehört. Ich denke das ist mit native VLAN gemeint, oder?
Alle anderen VLANs mit den IDs 100-160 hängen am Port 11 mit Zusatz "Tagged" dran. Diesen Port habe ich nun auch zum Default-VLAN hinzugenommen, allerdings untagged. Habe ich das einigermassen korrekt verstanden oder liege ich hier schon komplett falsch?

Ich denke mal dass ich falsch liege, weil der Raspi darüber nun auf keinem Interface erreichbar ist.
Vielleicht hast Du noch Anregungen, ich entwirre erstmal die Knoten und gehe morgen früh wieder frisch ans Werk.
Ich danke Dir schon mal sehr für die viele Mühe und die vielen sehr guten Links!!!

Vor allem ein Gedanke macht mir Kopfzerbrechen oder ich habe da wieder einen der besagten Knoten.
Wenn ich das eth0 auf DHCP stelle, muss er zum Mikrotik kommen, weil der auf allen VLANs und physischen Interfaces je einen separaten DHCP-Server hat. Ich habe grundsätzlich nur ein Kabel vom Switch zum Mikrotik (Switch-Port 11), wo alle VLANs switch-seitig tagged drauf liegen. Damit werden alle angeschlossenen Geräte am Mikrotip sauber den VLANs zugeteilt und bekommen Adressen aus dem jeweiligen Bereich.

Wenn ich nun den Raspi anschließe und der mit dem besagten eth0 auch vom Mikrotik versorgt werden soll, muss ich ihn ja auch über den Switch-Port 11 an den Mikrotip anschließen. Wenn ich den "untagged" setze, sollte er vom DHCP des physischen Interfaces auf dem Mikrotik mit einer Adresse versorgt werden - so mein Verständnis. Parallel soll er ja auch in die verschiedenen VLANs schauen dürfen bzw. müssen. Wenn das Raspi über den "untagged" Switch-Port 11 an den Mikrotik angebunden ist, müssten doch alle dort angelegten VLANs ebenfalls darüber zum Mikrotik rausgehen. Die VLAN-Tags der jeweiligen Pakete aus den VLANs des Raspi dürften unverändert oben ankommen, weil der Switch mit den Tags an den Paketen nichts macht. Ist mein Verständnis hinsichtlich Funktion korrekt?

Oder muss ich dem Raspi ein weiteres Bein direkt in die VLANs auf dem Switch verpassen? Muss ich also einen weiteren Port in das VLAN, wo der Raspi drin ist, hinzunehmen und den auf "untagged" setzen? Diesen Port dann auch in alle anderen VLANs auf dem Switch aufnehmen, dort dann aber "tagged" weil die Geräte Ihre Pakete nicht selber taggen?

Das sind die Gedanken, welche sich um die "Verkabelung" bei mir ranken. Ich fürchte dass ich von meinen Gedanken her noch nicht so richtig da angekommen bin, wo ich gedanklich hin muss. Ich hoffe Du verstehst was in meinem kleinen Köpfchen gerade los ist ...

Die RasPi Konfig ist soweit OK ! Natürlich nur wenn du auch den VLAN Support mit apt-get install vlan vorher installiert hast, was wir aber mal annehmen.
Ein ifconfig sollte dir dann die Interfaces und deren IPs auf dem RasPi anzeigen nach einem Reboot.

Danach habe ich den Raspi an einen Switchport angeschlossen, der zum default-VLAN gehört.

OK, das kann man natürlich machen.
Wenn das ein normaler untagged Port ist der nur ausschliesslich im Default VLAN 1 hängt dann ist am RasPi auch nur das native eth0 Interface aktiv. Das kannst du wie gesagt mit ifconfig wasserdicht überprüfen:
root@raspi:/home/admin# ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:ec:d6:d8:1f
inet addr:172.16.1.100 Bcast:172.16.1.255 Mask:255.255.255.0<--
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3219642 errors:0 dropped:0 overruns:0 frame:0
TX packets:484603 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:181462112 (173.0 MiB) TX bytes:59001454 (56.2 MiB)
Wenn dieser Port dann zusätzlich noch TAGGED gesetzt ist für die VLANs 100 und 101 ist das genau richtig.
Die jeweiligen RasPi IP Adressen sollten sich dann in den VLANs 1, 100 und 101 fehlerfrei anpingen lassen.

Habe ich das einigermassen korrekt verstanden oder liege ich hier schon komplett falsch?

Das ist korrekt verstanden und alles richtig gemacht !

Ich denke mal dass ich falsch liege,

Nein, tust du nicht ! Der RasPi Port ist dann untagged in VLAN 1 und tagged in VLAN 100 und 101. Das ist von Seiten des RasPi alles richtig.
Aber Vorsicht hier. Die RasPi IP im Default VLAN 1 ist DHCP basierend. Die kann sich also nach jedem Reboot ändern. Hier solltest du VORHER immer direkt am Terminal mit ifconfig nachsehen was da für eine IP anliegt.
Sinnvoll wäre es dem RasPi hier auch eine feste statische IP zu geben oder den DHCP Server so zu setzen, das der RasPi auf Basis seiner Mac Adresse immer eine feste IP im VLAN 1 bekommt.
Ein ifconfig Screenshot vom RasPi wäre mal hilfreich hier.
Sollte es dennch wider Erwarten nicht klappen, dann hast du an der Switchkonfig was falsch gemacht ! Das dürfte der Grund sein warum es nicht klappt, denn das es sauber klappt kannst du am obigen RasPi Tutorial in der Rubrik VLAN ja nachlesen.
Du kannst das auch ganz einfach mal verifizieren indem du an den Switchport mal einen Wireshark anschliesst. Das wäre ein wasserdichter Beweis um zu sehen ob die Pakete aus den VLANs 100 und 101 dort mit einem entsprechenden Tag versehen sind.
Analog kann man das am RasPi Port machen und dann vom RasPi mal einen Ping ins VLAN 100 oder 101 absetzen. Der Wireshark sollte dann zwingend getaggte Pakete anzeigen.

Das wäre dann ein sicheres Indiz das Switchport und RasPi richtig konfiguriert sind.

Wenn ich das eth0 auf DHCP stelle, muss er zum Mikrotik kommen,

Ja, das ist richtig sofern an dem Port das Default VLAN anliegt.
Das kannst du auch ganz einfach mit einem stinknormalen PC testen. An den Port 11 anschliessen und dann sollte der eine IP per DHCP bekommen (ipconfig).
Das VLAN 1 ist ja immer untagged am Port und wenn der Switch richtig mit dem MT gekoppelt ist über einen Tagged Link dann funktioniert das auch.
Das ist so oder so der grundlegende test den du zwingen machen musst. Auf dem Switch jeweils einen Port untagged in VLAN 1, 100 und 101 und sehen ob dort Endgeräte sauber eine IP vom MT DHCP Server bekommen.
Wenn das der Fall ist funktioniert das Grundkonzept sauber und dann kann es ausschliesslich nur noch an der Switchport Konfig liegen wo der RasPi dranhängt.
Eine IP auf eth0 sollte der RasPi aber immer bekommen (ifconfig)

Ich habe grundsätzlich nur ein Kabel vom Switch zum Mikrotik (Switch-Port 11),

Ist auch genau richtig und hier steht wie das konfiguriert sein muss:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Aber das klappt ja soweit alles bei dir schon, oder ??

Wenn ich den "untagged" setze, sollte er vom DHCP des physischen Interfaces auf dem Mikrotik mit einer Adresse versorgt werden - so mein Verständnis.

Das ist auch genau richtig ! Siehe oben...

Wenn das Raspi über den "untagged" Switch-Port 11 an den Mikrotik angebunden ist, müssten doch alle dort angelegten VLANs ebenfalls darüber zum Mikrotik rausgehen.

Das ist auch richtig ! eth0 direkt sendet untagged Pakete. Im DHCP Mode bekommt eth0 direkt dann eine IP vom DHCP Server VLAN 1. Das kann man auch mit anderen Endgeräten testen und klappt auch wenn man den RasPi in einen nur untagged VLAN 1 Port steckt.
Wie bereits gesagt, kann man auch vorher mit jedem anderen x-beliebigen Endgerät testen. Alle müssten an dem Port per DHCP eine IP im VLAN 1 bekommen.

müssten doch alle dort angelegten VLANs ebenfalls darüber zum Mikrotik rausgehen.

Auch das ist richtig. Der rasPi sendet alle Pakete die in die VLANs 100 und 101 gehen dann mit einem VLAN Tag aus am selben Port eth0.
Empfängt der Switch diese Pakete dann leist er das VLAN Tag und ordnet so dieses Paket dem richtigen VLAN zu.
ACHTUNG: Das setzt natürlich voraus dasa dieser Port dann zwingend auch als Tagged für diese VLANs definiert wurde. Ohne das, kann der Switch die Tags nicht lesen.

weil der Switch mit den Tags an den Paketen nichts macht. Ist mein Verständnis hinsichtlich Funktion korrekt?

Ist richtig !

Oder muss ich dem Raspi ein weiteres Bein direkt in die VLANs auf dem Switch verpassen?

Das wäre natürlich völliger Quatsch. Mal ganz abgesehen davon das du das ja indirekt quasi virtuell ja auch machst ! Durch die Tags an den Paketen die der RasPi den Ethernet Pakete mitgibt versetzt er den Switch ja in die Lage das er diese Pakete wieder genau dem VLAN zuordnen kann für den sie bestimmt sind.
Virtuell gesehen hast du also in der Strippe vom RasPi zum Port 11 auch alle virtuellen Strippen pro VLAN mit drin.
Logisch, und das ist ja auch der tiefere Sinn vom 802.1q VLAN Tagging !!!
Eben das man bei 10 VLANs nicht 10 Patchstrippen zum RasPi ziehen muss, mal ganz abgesehen davon das du dann ja auch 10 RJ-45 Interfaces brauchst. Das das Blödsinn ist erkennst du vermutlich selber auch, oder ?

Ich fürchte dass ich von meinen Gedanken her noch nicht so richtig da angekommen bin, wo ich gedanklich hin muss

Kann man eigentlich nicht sagen....du hast schon sehr viel richtig gemacht und denkst auf dem richtigen Wege..

Hier nochmal ein strukturelles Bild dazu:

Die Ports zw. Mikrotik und Switch sind entsprechend auch VLAN 1 = Untagged und VLAN 2-x Tagged zu setzen !
Wie bereits gesagt, die Clients in den 3 VLANs müssen an einem jeweils untagged Port im VLAN eine IP vom Mikrotik bekommen und Pingen muss untereinander problemlos möglich sein.. Damit ist dann sichergestellt das zw. MT und VLAN Switch alles richtig ist.

Zitat von @aqui:

Oder muss ich dem Raspi ein weiteres Bein direkt in die VLANs auf dem Switch verpassen?

Ich fürchte dass ich von meinen Gedanken her noch nicht so richtig da angekommen bin, wo ich gedanklich hin muss

Kann man eigentlich nicht sagen....du hast schon sehr viel richtig gemacht und denkst auf dem richtigen Wege..

Danke dass Du Dir solch Mühe mit mir machst!
Du hast eben meinen Knoten zerschlagen! Ich habe völligen Quatsch gedacht, wobei ich mich schon selber gefragt habe, wie das klappen soll! Ich war gedanklich immer da, dass ich unten das Kabel vom Raspi in den Switch "untagged" rein gebe und die Daten "oben" dann raus hole und zu den VLANs schleuse - weiterer Port vom Switch zum VLAN des Raspis rein, taget setzen und diesen Port auch bei allen anderen VLANs zusätzlich "tagged" rein. Es kam mir schon komisch vor, aber dass ich von "unten" die virtuellen Kabel gleich in die anderen VLANs stecke, da hatte ich die Denkblockade.
Jetzt ist der Raspi für mich sauber zu erreichen und er ist auch in allen VLANs drin. Er kann dort die jeweiligen Gateways anpingen, sieht gut aus.

Jetzt muss ich nur noch den Avahi zum Laufen bringen. Ich habe zumindest eine Musikfreigabe von iTunes im Netz, die sollte er nun finden, denke ich. Dann wäre das für mich ein sicheres Zeichen, dass hier alles in bester Ordnung ist.

Konfiguriert habe ich den Aval wie folgt:

Avahi aufsetzen

Dann habe ich noch den Parameter "enable_refelctor" aktiviert und auf "yes" gesetzt.
Das wollte nicht so recht und ich habe mich gewundert, warum ich nur Einträge von eth0 sehe (Kommando: avahi-browse -at).
Durch Zufall habe ich in der Konfiguration den Parameter "enable_interfaces" gesehen. Dort habe ich das eth0 und alle VLANs mit Komma getrennt hintereinander weg eingetragen, den Avahi gestartet und schwupp findet er einen A*** voll Dienste! Und was sagt das Handy ... Privatfreigabe vom Server ist da, wird angezogen und Musi kommt aus der Taschendisko!

Du hast diesen Tag zu einem sonnigen gemacht!!!!!
Bis vor Deiner Antwort habe ich schon seit 6 Uhr hier rumgebastelt und wollte alles hinwerfen. Und das alles nur wegen dieses einen Denkfehlers.
Du hast mir vom Verständnis allgemein echt sehr viel weiter geholfen! Möge die Sonne heute mit Dir sein und Deinen Tag verschönern

Er kann dort die jeweiligen Gateways anpingen, sieht gut aus.

Röchel...! Das war ja ne schwierige Geburt mit dir

Aber du siehst...wenn man alles richtig macht klappt das auch wie gewollt.

Jetzt muss ich nur noch den Avahi zum Laufen bringen.

Na das ist ja dann nun ein Kinderspiel für dich....

Privatfreigabe vom Server ist da, wird angezogen und Musi kommt aus der Taschendisko!

Tadaaaa !!! Glückwunsch !

Du hast diesen Tag zu einem sonnigen gemacht!!!!!

So sollte es sein an Herrn Luthers Feiertag

alles hinwerfen. Und das alles nur wegen dieses einen Denkfehlers.

Auch hier siehst du das Dranbleiben sich auszahlt ! Die Erfahrung mit VLANs kann dir jetzt keiner mehr nehmen ! Weiter so...
Und... danke für die Blumen