Hello, I'm trying to figure out the best way to have multiple separate networks sharing multicast. The trouble is that each device must have the same configuration without any conflicts. Use case: 3 mikrotiks with their own 'private network' (same IP range eg. 10.10.10.1/24) able to share multicast so that devices inside each network can 'broadcast' to other devices in the other 'private networks'.

I was thinking about HWMPplus but each device in the mesh needs an IP so the config of each mikrotik would need to be different. I saw WDS but I'm not clear if that will actually work for me in this way.

Any ideas or help?

Thanks

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.

OK.. not sure if you read my post tbh...

But you're right, I did not say 'Wireless' or 'Wifi' although one might say thats self evident given my mention of some ways I was considering. I have no 'preconceptions', just trying to find a solution.

I'm aware both broadcast and multicast is a mess over a wifi. Unless there is a way to move data between two different devices without wires or without using wireless radios, it would seem wifi is required. This is not a high throughput application so speed is not very important.

Each device must have the same configuration because there will not be any special configuration done to achieve this link when its required, it must happen automatically.

I stated my use case, or 'what I'm trying to achieve'. Let me try to state it again in a different way.
Use case 2.0: When 2 or more 'units' (which have a mikrotik inside) are in range, they pass multicast between them. The multicast can just be a few addresses, not the whole range. Each of the 'units' need to have the exact same config because there will not be someone around to configure them, these will have the 'standard config' on them. The data needing to be shared is few kb in size so no huge data transfer needed. Since the internal IP range will be the same, the only data shared must only be multicast. Most of the time these 'units' will be alone and not in range, its less than %5 of the time this situation is even needed.

I have some ideas on how to try this, but no idea which will work, if any. I mentioned WDS which looks promising as it passed L2 traffic but this configuration is not an easy one.

And yes, flooding all multicast across all networks blindly is actually fine here. There are 2 IP devices in each 'unit' and the only multicast will be the traffic I'm trying to bridge.

OK.. not sure if you read my post tbh...

As for myself, I believe you're depending on us to read your mind for all of the details you've left unstated, yet which are perfectly clear inside your own mind.

I have no 'preconceptions'

A single shared IP space across multiple networks absolutely does count as a preconception.

Fortunately, I think we can get around that by changing your mind on the "multiple networks" requirement. What I now believe you actually want is a single network that is allowed to break up into multiple networks, then rejoin to become a single network again.

As you suggest, WDS and HWMP+ are meant to do this. What I don't see is how they help with the addressing problem.

Let's say all of the equipment starts out in the same room and is chatting away successfully as a single network, all meshed nicely together. Then some number of elements are calved off and become independent. A DHCP timeout occurs. How does a host get a fresh IP in this new scheme?

Then, having solved that, how do you know that host A on the old "single" network wasn't given 192.168.88.6, the same IP that host B on the newly-independent network got when it timed out and grabbed a new lease?

And then, this having occurred, when B's network rejoins the mesh, how is that IP conflict resolved?

If your answer is "multicast addressing," you're ignoring the fact that multicast packets have a sender address as well as a destination address. A packet that is from host 192.168.88.6 to multicast group 239.255.1.1 is liable to be ignored by a second host that also believes itself to have IP 192.168.88.6. Its network stack will say, "I didn't send that!" and drop the packet as clearly bogus.

I believe you can solve this by switching to IPv6, since it allows dynamic neighbor discovery, plus link-local address assignment based on the interface's MAC address to avoid collisions.

There's one detail you've left out that I think is critical: does this mesh have an uplink to the Internet? And, when elements of it calve off into this independent operating mode — the 95% case you speak of — do they continue to have some uplink, or are they then isolated?

I ask because I see two likely cases, which affects how you design the network:

• If only one of the routers has an Internet uplink, and the rest have to come back into proximity with it to rejoin the Internet, you can use WDS or HWMP to designate that router a "portal" node.
• If instead each router could potentially be a portal to a non-mesh portion of the network (including the Internet) depending on where in the world each piece is, that affects the design considerably. In that case, I think you'd best run the mesh over the Internet rather than over the WLAN, as with ZeroTier, VXLAN, or similar.