MikroTik über LBS steuern | Edomi

[coliflower]

Um einen anderen Thread nicht weiter zu verseuchen ...
Hier noch eine Frage zum Thema Multicast und der Kombination MikroTik/ETS5 in unterschiedlichen VLANs:
https://knx-user-forum.de/forum/projektforen/edomi/1000752-kompatibilität-von-edomi-mit-neueren-php-versionen?p=1182924#post1182924

[jonofe]

Auch wenn die Firewall auf Durchzug gestellt wird, kommt Multicast nicht an, denn es ist kein Firewall Thema, sondern ein Routing Thema. Und Multicast und Broadcast werden per default nicht aus dem eigenen Netz heraus geroutet. Sonst wäre das gesamte Internet ja nur noch voll mit Broadcast und Multicast Messages.
Daher braucht man spezifische Lösungen wie IGMP oder PIM, um solche Pakete kontrolliert über Netzgrenzen hinweg zu senden.

[coliflower]

Ahhhh, danke !
Dann werden die VLANs nicht umsonst auch Broadcast-Domänen genannt ...

Gibt es eine Empfehlung zu IGMP vs. PIM ?

[jonofe]

Dazu kann Carsten ( saegefisch ) bestimmt mehr sagen ...

[wintermute]

auch Broadcast-Domänen genannt

Broadcast-Domaenen sind was anderes, die trennen auf einer niedrigeren Schicht im Layer-Modell als Multicasts... aber vom Grundprinzip her aehnelt sich das ein wenig, ja.

[saegefisch]

Theorie bei MikroTik: IGMP-Proxy: nur ein Upstream <-> PIM: Eierlegende Wollmichsau
Praxis: Mein Psychologe hat mir geraten das Thema für ein paar Tage mal einfach auszublenden... Sorry, derzeit mit Multicast etwas frustriert, weil mit dem einen es per PIM so einfach war, aber ein anderer nicht - und ich begreif's (noch) nicht.

Letzlich würde ich sofort zu PIM gehen, weil in unser aller Häsuer sich ein Zoo hat Multicasts dreht und mit einem komm' ich sicher nicht aus. ETS5, SONOS, SMA,...
Todo:
* Im PIM x Intrefacses hinzufügen für x (relevante) VLAN.
* Eine RP - oder mehrerer? Meine Frage weiter oben dazu ist noch unbeantortet.
* Der Rest sollte nur noch FW ...siehe hier... und um ein Flut zu vermeiden, sollte man wohl die FW sehr scharfkantig wählen. Gerade mein haus-VLAN will ich vro weiterem schützen.

Eigentlich nur 5 Minuten Arbeit und sehr einfach. Wenn amn die IP/Ports alle kennt... Doku und Torch war mein Freund dabei...

[coliflower]

OK, danke, ich dachte es irgendwo so gelesen zu haben, da ein VLAN doch auf L2 aufbaut (hoffentlich irre ich mich auch hier nicht, da L1 Bits sind).

[coliflower]

Mein Psychologe hat mir geraten das Thema für ein paar Tage mal einfach auszublenden...

Dann müsste ich mich schon längst ins Irrenhaus begeben ...
Aber danke für dein Feedback !

[saegefisch]

Insgesamt ist die PIM-Erfahrunslage im WWW nicht so dick, wie bei anderen Themen. Pacom und andere übliche Verdächtige haben nichts dazu - zumindest nicht zusammen mit MT. Ist daher auch Selbstversuch und..und... PIM hätte so gut und einfach sein können... meine (teil-erfolreichen) Beiträge dazu scheinen schon fast das meiste dazu zu sein...<schluchz>.... - verdammt, mir kommen schon wieder die Tränen...

[coliflower]

Hier habe ich einen Tip von einem Netzwerker und einen Link zum Thema Multicast:

Ja, Multicast geht ohne weiteres nicht über geroutete Interfaces. Dazu musst du PIM Routing aktivieren, was die pfSense aber kann.
Auch ist es sehr wichtig WELCHE Multicast Gruppe hier verwendet wird !!
Es gibt Gruppen die nur ein lokales Multicasting zulassen. Dort ist der TTL Wert (Time To Live = ein Hopcounter) fest auf 1 gesetzt. Solche MCs können gar nicht geroutet werden...sollten sie auch nicht. Dazu gehört z.B. mDNS (Bonjour), VRRP und einige andere.
Da musst du dann einen Proxy einsetzen, wie z.B. HIER.
Also mal den Wireshark nehmen und belauschen mit welcher MC Gruppe deine KNXe da reden.
Eine super Quelle MC zu verstehen ist auch hier:
https://www.youtube.com/watch?v=AvbSMBKBZgY
Zieh dir mal die ersten 3 Teile rein, dann bist du schlau ! MC ist kein Hexenwerk.

[wintermute]

OK, danke, ich dachte es irgendwo so gelesen zu haben, da ein VLAN doch auf L2 aufbaut (hoffentlich irre ich mich auch hier nicht, da L1 Bits sind).

Ja, im siebenschichtigen Modell arbeitet ein VLAN in Schicht 2 (weil es da um Ethernet-Frames geht), Broad- & Multicasts gibt es entweder in Schicht 2 (als Ethernet Broadcasts, also mit Adressierung per MAC-Adresse) oder Schicht 3 (als IP-Broadcasts mit Adressierung ueber IP-Adressen) - KNX-Multicasts sind IP-basierend und gehoeren daher zu Schicht 3 (Vermittlung).
(Ich bin uebrigens ein Verfechter des 4-schichtigen Modells wenn es um IP geht aber ich will hier niemanden verwirren )

[coliflower]

Unabhänging vom Problem das ich habe ... Ich würde es gerne versuchen zu verstehen.

oder Schicht 3 (als IP-Broadcasts mit Adressierung ueber IP-Adressen) - KNX-Multicasts sind IP-basierend und gehoeren daher zu Schicht 3 (Vermittlung).

Multicast läuft von 224.0.0.0 bis 239.255.255.255 ...
Reserviert für KNXnet/IP ist die 224.0.23.12

Sendet jetzt die ETS5 ein Multicast von 224.0.23.12 ins LAN und warte auf eine Antwort von KNXnet/IP-Router um diesen als "erkannt" in der ETS5 darstellen zu können ?
Wenn ja, was hindert dann die ETS5 im VLAN50 das GW im VLAN10 zu finden ... ist das dann die 224.0.23.12 die nicht zwischen den zwei privaten Netzwerken 10.0.10.0/24 und 10.0.50.0/24 "flutschen" kann ?

[saegefisch]

Für den Fall wären wohl zwei PIM-Interfaces nötig: 10.0.10.0/24 und 10.0.50.0/24. bzw. eher deren vlan-bridges Dazu ein RP, vermutlich 10.0.10.1. Die FW braucht einen Forward-Regel für 224.0.23.12. Dazu zwei forward-Regel für hin und zurück --> da ist der/die Ports erforderlich und das/die Protokolle.

[Janncsi]

Jetzt hat es mich doch mal übermannt und ich hab mir gerade die Möglichkeiten bzgl. des CRS in Verbindung mit Multicast angeschaut.

Ich habe nämlich ebenfalls einige Probleme, die ich mir bisher nicht erklären kann, die aber wunderbar zu den hiesigen Fehlerbeschreibungen passen (bspw. die nicht Erreichbarkeit meines Denon Heos von einem anderen Vlan, die Verbindungsabbrüche in der ETS, etc.)

Nun las ich gerade das in dem Manual:CRS features:

CRS125 switch-chip supports up to 1024 entries in MFDB for multicast forwarding. For each multicast packet, destination MAC or destination IP lookup is performed in MFDB. MFDB entries are not automatically learnt and can only be configured.

Jetzt muss ich das ganze nur noch verstehen, damit ich weiß, was ich da machen kann...:-D

[coliflower]

saegefisch
Grundsätzlich zum Multicast - quick and dirty habe ich mal das IGMP.Proxy "aktiviert" und für VLAN10 den UPstream (Sender of Multicast, mit der Adresse des KNXnet/IP-Routers) und für VLAN50 den DOWNstream (Receiver of Multicast für das VLAN50net) zugewiesen ..
Gleich danach konnte ich die neu geblockten Pakete an der Firewall sehen, nämlich, Interface = VLAN10, Source = 10.0.10.2 (GW), Destination 224.0.23.12:3671.
Ich habe dann auch die FW-Regel für das VALN10-Interface angepasst (PASS), danach flossen die Information via Multicast von VLAN10 an VLAN50, dh, der IGMP scheint zu funktionieren.