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

Cannot receive external multicast inside container #23659

Open
combitel opened this issue Jun 17, 2016 · 12 comments
Open

Cannot receive external multicast inside container #23659

combitel opened this issue Jun 17, 2016 · 12 comments

Comments

@combitel
Copy link

@combitel combitel commented Jun 17, 2016

Output of docker version:

Client:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:23:39 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:23:39 2016
 OS/Arch:      linux/amd64

Output of docker info:

Containers: 4
 Running: 1
 Paused: 0
 Stopped: 3
Images: 2
Server Version: 1.11.2
Storage Driver: btrfs
 Build Version: Btrfs v3.17
 Library Version: 101
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.964 GiB
Name: swarm-vm
ID: IYZD:UVUB:A3V7:3E2D:YQSY:CHHB:PMIC:QQAC:TQKU:BS4G:XGMP:LLWW
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Labels:
 provider=generic

Steps to reproduce the issue:

  1. Start new container
    docker run -it --name node1 ubuntu:14.04 /bin/bash
  2. In container, install iperf and start multicast listener:
    apt-get update && apt-get install iperf
    iperf -s -u -B 224.0.55.55 -i 1
  3. On host, start multicast server:
    iperf -c 224.0.55.55 -u -T 32 -t 3 -i 1

Describe the results you received:
Multicast is not received by multicast listener inside container.

Describe the results you expected:
If application in container joins multicast group, then multicast traffic must be forwarded to container's NIC.

Additional information you deem important (e.g. issue happens only occasionally):
It works fine with --net host, but for various reasons it's not an option.
It looks like IGMP JOIN never leaves container's NIC. I checked it on host using tcpdump -i any host 224.0.55.55 and get 0 packets when container joins 224.0.55.55 group.

Any help or pointers is really appreciated.

@thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Jun 17, 2016

/cc @mavenugo

@combitel
Copy link
Author

@combitel combitel commented Jun 21, 2016

Tested as well on Docker for Mac v1.12.0-rc2. Same result.

@combitel
Copy link
Author

@combitel combitel commented Jun 28, 2016

anybody?

@Hugne
Copy link

@Hugne Hugne commented Jul 5, 2016

This is likely because you don't specify the correct interface/source address on the host, and the network stack on the host side is selecting one (the wrong one) for you.
If you do not bind a local interface address to the multicast sender socket, Linux (afaik) will select your default routes interface address.
You probably want the address of docker0 (or whatever the bridge is called),
so in your example above, try adding -B <ip of docker0> to the iperf sender.
e.g
iperf -B 172.17.42.1 -c 224.0.55.55 -u -T 32 -t 3 -b 100M

@combitel
Copy link
Author

@combitel combitel commented Jul 6, 2016

What happens is that it looks like IGMP JOIN never leaves container's network stack. I tried monitoring all host network interfaces with tcpdump -i any host 224.0.55.55 and see zero packets captured.

@Hugne
Copy link

@Hugne Hugne commented Jul 6, 2016

224.0.0.0/8 is not a host prefix.
what about tcpdump -i any igmp?
Did you try my previous suggestion?

@combitel
Copy link
Author

@combitel combitel commented Aug 18, 2016

Tried this just now. Same result - no multicast.

On Thu, Aug 18, 2016 at 6:04 AM Justin Cormack notifications@github.com
wrote:

I don't think containers by default have permission to create multicast
packets, can you try with --cap-add NET_BROADCAST on the docker run?

@PilgrimViis
Copy link

@PilgrimViis PilgrimViis commented Jul 6, 2017

@combitel, are you figured out it?
Does docker has problem with multicast (more precisely SSM) or not? Cause today I faced same issue and not quite sure is problem in my network configuration or docker itself.

@adampl
Copy link

@adampl adampl commented Apr 5, 2018

As of Docker 18 this is still an issue :(

@KylePreuss
Copy link

@KylePreuss KylePreuss commented Oct 18, 2018

The issue here is more than just "external" multicast. Two containers on a single host attached to the same network (default bridge network or a user-defined network,) cannot send/receive multicast with each other.

See this issue:
moby/libnetwork#552

Edit: Fixed link. Also, to clarify: my use has been with Docker for Windows running Linux containers (not LCOW).

@lfdominguez
Copy link

@lfdominguez lfdominguez commented Nov 24, 2020

But how this is a docker problem?? this is almost a network stack problem....

@cornim
Copy link

@cornim cornim commented Mar 6, 2021

There is also a ticket here moby/libnetwork#2397 which receives even less attention then this one.

I'm not a network expert, but shouldn't docker be able to forward the multicast messages just like a multicast enabled router would?

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

No branches or pull requests

9 participants