Closed sandersaares closed 6 years ago
troglobit
commented
6 years ago Really have no idea why it doesn't work for you, otoh I've never used iperf to test multicast. Mostly because it doesn't have an -I interface option like ping does. Try ping (with interface + TTL options) and check with tcpdump on the receiver.
sandersaares
commented
6 years ago The idea being that if I send a ping to a multicast address on eth0 it should route to docker0, right? With a listener in docker0 subscribed to the group, of course. This is also a negative result.
The ping shows up on docker0 only if I specify the docker0 interface to be used.
Can you suggest any detailed tracing I could turn on to find out how Linux is routing my packets? My Linux networking knowledge is very basic, so while I would like to get to the bottom of this, I really have no idea where to even look so any hints are appreciated.
More things I tried:
saares@michaelscarn:~$ ip route get 239.1.2.3
multicast 239.1.2.3 dev eth0 src 10.0.5.224
cache <mc>
saares@michaelscarn:~$ sudo iptables -4 --list -v
Chain INPUT (policy ACCEPT 889K packets, 55M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy DROP 5772 packets, 8638K bytes)
pkts bytes target prot opt in out source destination
79095 66M DOCKER-ISOLATION all -- any any anywhere anywhere
46341 63M DOCKER all -- any docker0 anywhere anywhere
40569 54M ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
32754 2471K ACCEPT all -- docker0 !docker0 anywhere anywhere
0 0 ACCEPT all -- docker0 docker0 anywhere anywhere
Chain OUTPUT (policy ACCEPT 43060 packets, 9907K bytes)
pkts bytes target prot opt in out source destination
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-ISOLATION (1 references)
pkts bytes target prot opt in out source destination
79095 66M RETURN all -- any any anywhere anywhereOh hey does that say DROP there?
saares@michaelscarn:~$ sudo iptables --policy FORWARD ACCEPTAnd now it works! Cool!
Is this something expected? That is to say, should changing this policy be a normal part of setting up multicast on a Docker host? Or is this just some overreaching workaround and a more fine tuned real change would be sufficient?
troglobit
commented
6 years ago I just re-read my own howto and realized I actually have used iperf before ... here it is, maybe you can find some pointers there: http://troglobit.com/howto/multicast/
Also, I think docker0 is a bridge, so some of the tips in the howto for bridges may be worth trying out.
sandersaares
commented
6 years ago Thank you for the assistance. I will close this issue now given that with the adjustment in the last comment it seems to work fine.
troglobit
commented
6 years ago Great to hear, good luck! :)
Having read #70 and http://troglobit.com/2016/03/07/testing-multicast-with-docker/ I approached the topic with great expectations but alas, I fail to configure multicast routing with Docker. Perhaps I am doing it wrong. Perhaps times have changed. I describe my scenario here and request guidance.
I have an Ubuntu 16.04 system that is a Docker host, with a default Docker bridge network in which I want to have a container receive multicast traffic.
I installed PIMD and started it with the default configuration and the DEBUG log level.
I started a container and in it ran
iperf -s -u -B 239.1.2.3 -i 1. In a packet capture on docker0 I see:On the host I then do
iperf -c 239.1.2.3 -u -T 32 -t 3 -i 1.In syslog I see
Added kernel MFC entry src 10.0.5.224 grp 239.1.2.3 from eth0 to docker0from pimd.In pimd routes I see some potentially relevant lines about this IP address:
sudo ip mroutehas(10.0.5.224, 239.1.2.3) Iif: eth0 Oifs: docker0listed.Linux firewall is off:
sysctl -asays this:But in the end, no multicast traffic is to be received by the container. In fact, I see no UDP traffic whatsoever if I do a packet capture on the docker0 network.
Is there something obvious I am doing wrong?