I am running into an issue getting Multicast working in a docker environment. The goal is to have 1 container act as a router for all network communication between the other containers, since the goals is to use that container to apply tc commands to affect the network traffic. Below is the current setup.
What I have tried to do so far:
• Environment:
Docker containers, running inside an Ubuntu 22.02 VM (Virtual Box) on a Windows 11 machine.
Docker version 29.3.0, build 5927d80
Subscriber Container:
Network_B: 172.30.0.3
Deleted default route, added new default route via 172.30.0.2
Running socat command (iperf as server was causing issues on apline image):
socat UDP4-RECV:5201,ip-add-membership=224.0.1.1:eth0 STDOUT
When I run the iperf3 command from the client container, it is unable to find it’s destination.
Any insight on how to resolve this, or properly configure the setup, would be greatly appreciated.
Let me know if more info is required.
First of all: I am not an expert in multicast. I assume that as long as the containers are within the same subnet as the sender, it should reach them.
Can you share how you configured the docker side?
By default docker bridge networks are nat’ed, so they might be not the right fit. As long as your test is done from within the docker host, the non isolated host network namespace (if it’s an ip from the container network!) should be able to reach the isolated network namespaces in the same subnet. I know that broadcast packages can not cross subnet barriers, but I am not sure how multicast works here. With broadcast you would need a repeater to bounce broadcast messages from one subnet to another. A docker bridge subnet is alway private to the host, and should not collide with an existing subnet of the host!
it should work, if you use macvlan networks for the containers. This is the way to go, if the container should be in the same subnet(s) as the host. But macvlan networks have the limitation that the macvlan parent interfaces (the ones of your host) won’t be able to directly communicate with the macvlan child interfaces (=the ones of your containers). Some people add a macvlan shim to the host to at least solve this problem from host to container by introducing a child macvlan interface on the host. This interface is not affected by the constraint.
