I'm trying to figure out the best way
Your question reads as if you believe you've already come up with "the best way" and are now trying to arm-twist the universe into conforming. Let go of your preconceptions!
multiple separate networks sharing multicast
You don't come right out and say "wireless" or "WiFi," but since I do believe that's what you want to do, I must warn you that
multicast over WiFi is an absolute mess. Success is possible under controlled conditions with careful optimization and configuration, but it is by no means as easy as reading top-line specs ("up to 1Gbps!") would lead you to believe.
each device must have the same configuration
Why?
This feels like
an XY problem. Tell us what end goal you're trying to achieve, not the problems you're having with the solution you've come up with on your own.
share multicast so that devices inside each network can 'broadcast' to other devices in the other 'private networks'.
First off, realize that the primary distinction between multicast and broadcast collapses over a shared medium like WiFi. There are low-level technical details that produce some further small distinctions, but if you were hoping that protocols like IGMP snooping would somehow keep traffic between networks A and B from affecting network C, you're dreaming. It's all effectively broadcast until you get back to the wired domain.
Second, those low-level technical details play into this. To speak of multicast vs broadcast implies that you
do have meaningful IGMP traffic. The question then becomes, how do you get that traffic between these networks when you've gone and broken the distinction that routing uses — different IP subnets — to decide how that traffic gets between networks?
Let's get concrete. Device A' on network A is able to multicast a stream that device B' on network B wants to receive, so it sends out an IGMP group-join command, which
something on network A is listening for. IGMP is normally dropped at a routing boundary unless you go out of your way to configure it otherwise, which then brings you to an assortment of options for getting that packet between the two networks:
- PIM-SM won't work because it's a proper routing protocol and will break if you don't give it different IPs on each side to work with.
- IGMP proxying is likely to fail for much the same reason: devices A' and B' could have the same IP under your scheme, so how would it know that A' is to the "left" of the proxy on the network and B' on the "right"?
- That only leaves you with things like blind IGMP echoing, where every packet that appears on one side of a network boundary gets copied to the other in the wild hope that it may be useful.
Okay, fine. Problem solved. Device A' begins sending the multicast stream that B' wanted.
(Before, host A' was muted by network A because it didn't have any clients wanting its stream, so why burn network bandwidth? If it wants to babble to itself, let it, but until someone actually wants the stream, pinch it off. This is the essence of IGMP snooping, PIM-SM, etc.)
New problem: how does network A run an IGMP querier to determine whether there are any hosts on network B that are still interested in the stream? Any IGMP packets it sends will be
from 10.10.10.1/24
to 10.10.10.1/24, so they'll stop at the boundary! And, if you solve that by more IGMP echoing, and the reply comes back "yes, I am host 10.10.10.42 and I still want the stream," how does it know that it is a device on network B that said that, since the IP is "local" to network A as well?
Now you're stuck unless you just want to flood all multicast across all networks blindly.
And that
sucks.
So, how about you tell us what you actually want to accomplish here, and we can come up with a solution that doesn't suck.