DMX: can one OLA receiver block updates to others?

tl;dr Connecting a third OLA note, seemingly blocks traffic to other 2.

My system:
OH 2.5.7, running on a VM; DMX things config via text file, all items config via txt file.
installed bindings: icloud, hue, ntp, squeezebox, astro, http1, networkupstools, expire1, tplinksmarthome, network, tradfri, shelly, hpprinter, logreader, dmx
WIFI system: ORBI (2 Satellites); DMX bridge: SACN, tried both unicast and mulicast

I have 5 DMX PAR (7 channels) devices (for now), connected to three different pi’s (2, 3) running OLA (apt-get install). My apartment is not wired and has three levels, hence an ORBI wifi system with two satellites (star config, NOT daisy-chained) is connected all systems.
[edit: there is a smart switch connecting the OH2 server and the rpi2 and the router]
OH to 2 of the rpi’s/OLA goes through two hops (Sat1-Router-Sat2) the third raspi is connected to the same satellite as the OH2 server.

My initial setup had the two raspi’s (2 hops distance) connected, each with two PARs and all went well. When I connected the third rpi later (tried both wired and wifi, but it does connect to the same satellite as the OH2 server in both cases), communication with that third rpi/OLA was no problem, but the other two rpi’s stopped receiving any DMX commands and did not update their DMX devices anymore.

The manual does not seem to indicate that there is a limit to the number of receiving nodes. I tried both unicast (specifying the correct IPs of all three rpis) and multicast, no difference. The logs do not show any error or any other weird behavior, even with debug logging. As soon as I disconnect the third pi, either physically or I simply configure the corresponding DMX universe without any input, the other two notes react immediately to DMX commands from OH2 again. This behavior is reversible and reproducible. No amount of restarting the DMX bundle and/or OH2 and/or rpi’s has any influence on this behavior.

Any ideas anyone?

Well, just in case it may help future readers:
While I have not fully verified it, it may be that ICGMP snooping may cause problems in my setup (both the OH2 server and the “offending” rpi connect to the ORBI satellite through a managed switch that had ICGMP snooping enabled); this is a somewhat speculative statement, but the only one I can come up with so far.

I had used text based things definition and switched to PaperUI based things definition, separating the third rpi to Artnet (the other two are connecting via sACN) and that seems to allow connection to all three rpi’s