Problem bei Vernetzung mit IP-Routern

[tstalzer]

Wenn ein Switch kein Querier ist und kein Querier Port definiert ist, weiss der Switch nicht, wohin mit dem Multicast Datenpacket. Damit irgendwas funktioniert ist i.d.R. Flooding definiert im Switch wenn es keine Querier Response gibt. (Ja, ja, ich weiss, man kann/sollte dann die Datenpakete "droppen" aber dann bekommt man bei einer Fehlkonfiguration gar nichts ans Laufen)

Worauf ich hinaus wollte - eine richtige Multicast Konfiguration über mehrere Switche ans Laufen zu bekommen verlangt etwas mehr als nur Grundwissen.

traxanos - dass war jetzt nicht auf Dich bezogen. Multicast ist nicht einfach/trivial und ist alles andere als "Plug&Play". Jeder der mit einem IP Router mehr als einen Router/Netzwerk (womöglich noch über VLAN Grenzen hinweg) konfigurieren möchte muss sich in das Thema einarbeiten. (und ja - ich habe auch meine Trial&Error Phase hinter mir und auch den gelegentlichen Frust)

[traxanos]

Das war ernst gemeint, ich verstehe es nicht was du schreibst und das passt halt auch nicht zu dem was ich weis. Jeder Switch lernt für sich welcher Port in welcher Multicastgruppe er ist. Wenn man einen Multicast-Router verwendet, dann muss man einen Port definieren, weil der Switch nicht wissen kann was wo anders ggf. per Routing erreichbar ist und joint diesen Port in alle MC-Gruppen als "hier kannste alles hab schau selber was du brauchst".

Der Querier fragt ja sozusagen nur alle Multicastgeräte an "welche Gruppen interessieren dich?". Die Switche lesen diese IGMP Infos für sich auch mit. Da wird nichts Rund geschickt. Flooding wäre es ja nur Wenn ein Port auf "no snooping" steht wie z.B: ein MC-Routerport und das Snooping ist sogar komplett aus.

Daher meine Rückfrage. Alles was du sagst macht nur Sinn im Kontext eines Multicast-Routing, da aber in kleinen Netzen eigentlich nicht anzufinden ist. Ein Switch der Querier macht braucht das nicht. Wobei man aufpassen muss da großer Enterpriseswitch meisten L3 sind und damit auch Routing anbieten.

[Hubertus81]

Muss der KNX-IP Traffic denn zwangsweise über das restliche Netz gehen? So ein ITler kann immer mal irgendwas "zerschießen" oder falsch konfigurieren und der dürfte vielleicht nicht immer Ahnung von KNX haben... Ich persönlich würde daher schauen ob es nicht machbar ist die KNX Router direkt mit einer eigenen Netzwerkleitung zu verbinden, bei kleinen Projekten sollte das unter Umständen der bessere Weg sein.

[BadSmiley]

Ich habe mein Unifi LAN um 10GB Switche, APs usw erweitert. Die Pornos laufen so flüssig wie nie!
Allerdings habe ich seit dem ein Problem mit meiner Allgemeinlinie... ja das Netzwerk ist natürlich gewachsen und total falsch aufgebaut, mehr Baum als Stern, aber hey, wer kennt das nicht?
Ich bräuchte bitte nochmal einen Tritt in die richtige Richtung. Es kamen immer wieder alle Telegramme in der Allgemeinlinie an. Erst dachte ich ja, der Enertex IP Router hätte ein Traffic Problem, aber der OpenKNX Router zeigt nach anfänglichen Erfolgen das gleiche Verhalten. Es kommt alles sauber durch um dann für Minuten wieder nichts durch zu lassen. Egal ob TP->IP oder IP->TP.
Also an den Thread erinnert, das IGMP Snooping an gemacht (hat gefühlt am meisten geholfen) und anschließen die Querier Switch eingerichtet.
Aktuell würde ich sagen, läuft es wieder so flüssig wie vorher.. mit einer Ausnahme. An meinem Haupt PC kommt jetzt kein Multicast Traffic mehr an. Ich vermute das IGMP Snooping sagt (Da ist nix was Multicast braucht) und dreht mir den Traffic ab. Also kann ich in der ETS den Gruppenmonitor zwar an machen, aber ich sehe nichts?

Nachtrag: Ich kann Multicast von meinem PC aus senden, die Befehle werden auch sofort und korrekt um gesetzt, aber ich sehe nichts.
grafik.png

Querier kann es geben soviel man will, man muss aber auch darauf achten, dass die dann synchron sind. Bei Zyxel muss der "Querier Port" noch angegeben werden; dies ist der Port wo der nächste Switch hängt, der auch als Querier agiert.

Das geht bei UI auch, habe ich auch brav gemacht!

[traxanos]

meiner meinung muss man das normal nicht machen. da die switche das IGMP wie Broadcast weiter leiten sollten und somit die uplink ports auch normal angelernt werden. der hintergrund ist, das es ggf generische multicast router gibt, und somit kein igmp für jede gruppe gibt. da sagt man hier "die z.b. firewall soll einfach alles bekommen" und dann selber entscheiden was es damit macht. anderes beispiel könnten auch ein IDS sein das nur "lauscht"

zu deinem problem: du könntest dich per console auf dem switch einloggen wo dein rechner dran hängt und erstmal schauen ob du teil der mutlicast gruppe bist.

schau mal hier https://openknx.atlassian.net/wiki/s...3746/Multicast

show ip igmp snooping groups

müsste das sein.

[BadSmiley]

Danke für den Tipp traxanos das habe ich dann gar nicht mehr weiter verfolgt und kurz geschaut..es geht inzwischen!

AAABER, ich habe dafür ein neues, nerviges Problem. Ich habe 2 OpenKNX-IP-Router und das lief jetzt auch alles brav und damit habe ich die Sensoren und Aktoren Linie via IP an mein Bus System angebunden. Seit neusten verlieren die beiden Router nach ein paar Stunden (wie viel genau, kann ich nicht sagen, aber weniger als 24h) die Multicast Verbindung. Keine Multicast Kommunikation mehr möglich, also auch kein Licht an/aus, Unicast geht. Die ETS findet sie auch nicht mehr, bis ich die Bus Klemme ziehe, kurz warte und wieder anstecke. Dann geht es wieder für ein x Stunden.

Meiner Meinung nach habe ich an den Einstellungen im UI Netzwerk nichts geändert, vor allem nicht an dem Switch an dem sie gerade hängen. Ich teste mal noch einen Switch davor... Firmware Upgrade auf 0.4.0 habe ich bei einem Router zum testen auch mal gemacht, bei einem nicht. Das Verhalten bleibt bei beiden Routern gleich.

[traxanos]

weist du ob es der ESP oder der RP2040 Router ist?

[BadSmiley]

Das USB Firrmware Upload Tool sagt ESP32:
Unbenannt.jpg

[Ing-Dom]

Seit neusten verlieren die beiden Router nach ein paar Stunden (wie viel genau, kann ich nicht sagen, aber weniger als 24h) die Multicast Verbindung. Keine Multicast Kommunikation mehr möglich, also auch kein Licht an/aus, Unicast geht. Die ETS findet sie auch nicht mehr, bis ich die Bus Klemme ziehe, kurz warte und wieder anstecke. Dann geht es wieder für ein x Stunden.

Das Problem ist leider bekannt, die Lösung leider nicht.
Bei manchen Usern tritt das regelmäßig auf, bei manchen nie. Leider gibts noch keine direkten Verdachtsmoment wo das herkommt.
Aber:
da Unicast noch geht, kann weder HW noch die PHY sein
da die Geräte in dem Zustand noch per Konsole erreichbar sind etc.. ist es auch nicht der OpenKNX-Stack.
Ich vermute dass der Netzwerkstack im ESP-IDF da irgendwo noch einen Bug in Verbindung mit Multicast hat.. der von irgendwas getriggert wird, dass bei manchen User vorkommt und bei manchen nicht (zB irgendwelche IGMP Pakete oder sowas).