Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recieve UDP multicast inside a docker container without "--net host" option #2397

Open
druanoor opened this issue Jun 23, 2019 · 5 comments
Open

Comments

@druanoor
Copy link

Is there any way to achieve this? I can't use "--net host" since i need more containers to run in the same host and map ports with the host.

@cornim
Copy link

cornim commented Mar 6, 2021

I'm faced with the same issue. Is there a way to receive multicast traffic which was sent to the host inside a docker container?

@jackhart
Copy link

jackhart commented Oct 5, 2021

Multicast to/from a docker bridge network is currently not possible. This is due to limitations with how linux kernels provide support for multicast routing. Packets are forwarded to the docker bridge using iptables and the unicast routing table, but multicast packets are handled differently in linux kernels. A workaround is to run a tool like smcrouted on the host (or in a container with access to the host network). This process does the work of managing the linux multicast forwarding cache.

Side note: If running docker swarm, and all your multicast communication is happening between nodes you can control, you could use weave net, which apparently has support for multicast.

It would be nice if we could see some multicast support added here... but ultimately it feels like more of a kernel issue.

@tymonx
Copy link

tymonx commented Aug 25, 2022

There is a working solution using virtual ethernet veth or real physical device with macvlan or ipvlan drivers #552 (comment) The veth can be used for internal multicast side-by-side communication between containers. To work with multicast from outside world (machine) use real physical device in the --opt parent=<device> option for the docker network create command. It works in local scope (standalone, compose) or swarm scope (cluster, stack).

@TW4177
Copy link

TW4177 commented Jul 29, 2023

...To work with multicast from outside world (machine) use real physical device in the --opt parent=<device> option for the docker network create command. It works in local scope (standalone, compose) or swarm scope (cluster, stack).

Would you please elaborate on this a bit? I'm not sure how to subset the container<->container multicast setup to work with a {host-or-outside-world}<->container setup. Thanks v. much. @tymonx

osmocom-gerrit pushed a commit to osmocom/docker-playground that referenced this issue Feb 9, 2024
We cannot execute the virtphy based testcases due to the limitations
of Docker (see moby/libnetwork#2397).  The
function starting the testsuite was already commented out, but not
the lines starting containers with osmo-bts-virtual and virtphy.

To put it simple, we start and immediately terminate those containers.
And since recently (Feb 1st), we started seeing socket creation errors
in both containers, causing jenkins.sh to abort early.  It's yet
unclear what's the cause of those socket errors, but regardless of
that we should still be running other pending testcases.

Change-Id: I7c9ccc9cc400edb7a05e222e51671fd49631a4cd
Fixes: OS#6352
@heffneil
Copy link

I don't know how this can be true for ALL docker containers? I know people running docker containers for Weatherflow2MQTT which is all multicast traffic and it works. Its not within Nomad but it works?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants