Routing multicast to docker

[campanada]

Hi all,
We have an application running on docker (over Ubuntu 20.04) that receives several multicast video flows. Currently, smcroute is used to setup statically multicast routes but the problem is that the huge amount of possible multicast flows overload the machine and network when not all multicast flows are used at same time.
To solve this problem we are testing PIMD that subscribes dynamically to multicast when requested but we are facing problem to setup.

Internal docker receiver application is continuously requesting multicast subscription but it seems that PIMD service doesn’t receive them or not distribute.

Any idea of what we are doing wrong?

Thanks in advance
Regards

This is the network schema

bond0 10.10.21.7
MC sender ---> [ Server host ]    <--- router running pimd
232.0.83.101       |
                           |
               ________|________
              / docker_bridge   \   <--- bridge    ______
             /       172.20.0.1  \                |      |   <--- MC receiver
  __________/          |          \_______________|______|_____
\                     |                            /         /
  \                     `------------------>-------'         /
   \________________________________________________________/
      Container ship

pimd tables
---------------------------------------------------------------------------------------------------------------------------------------------------
Virtual Interface Table 
======================================================
Vif  Local Address    Subnet              Thresh  Flags      Neighbors
---  ---------------  ------------------  ------  ---------  -----------------
  0  10.10.21.7       10.10.21/24              1  PIM        10.10.21.254   
  1  172.17.0.1       172.17                   1  DR NO-NBR
  2  172.20.0.1       172.20                   1  DR NO-NBR
  3  10.10.21.7       register_vif0            1 

Vif  SSM Group        Sources             
   0  232.0.83.101    232.0.83.101 
   2  232.0.83.101    232.0.83.101 

Multicast Routing Table 
======================================================
----------------------------------- (S,G) ------------------------------------
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
172.18.144.135   232.0.83.101     SSM              SG
Joined   oifs: ....                
Pruned   oifs: ....                
Leaves   oifs: ....                
Asserted oifs: ....                
Outgoing oifs: ....                
Incoming     : I...                

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3
           200    55     0       0        0  0  0  0
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
172.18.144.143   232.0.83.101     SSM              SG
Joined   oifs: ....                
Pruned   oifs: ....                
Leaves   oifs: ....                
Asserted oifs: ....                
Outgoing oifs: ....                
Incoming     : I...                

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3
           200    55     0       0        0  0  0  0
Source           Group            RP Address       Flags
---------------  ---------------  ---------------  ---------------------------
172.18.144.161   232.0.83.101     SSM              SG
Joined   oifs: ....                
Pruned   oifs: ....                
Leaves   oifs: ....                
Asserted oifs: ....                
Outgoing oifs: ....                
Incoming     : I...                

TIMERS:  Entry    JP    RS  Assert VIFS:  0  1  2  3
           205    60     0       0        0  0  0  0
---------------------------------------------------------------------------------------------------------
$ netstat -g
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.251
lo              1      224.0.0.1
eth1            1      224.0.0.1
eth0            1      224.0.0.1
bond0           1      224.0.0.251
bond0           1      224.0.0.1
docker0         1      224.0.0.251
docker0         1      224.0.0.1
docker0         1      224.0.0.106
docker_gwb      1      224.0.0.251
docker_gwb      1      224.0.0.1
docker_gwb      1      224.0.0.106
vethdd2048      1      224.0.0.1
veth8da20e      1      224.0.0.1
lo              1      ff02::fb
lo              1      ip6-allnodes
lo              1      ff01::1
eth1            1      ip6-allnodes
eth1            1      ff01::1
eth0            1      ip6-allnodes
eth0            1      ff01::1
bond0           1      ff02::fb
bond0           1      ff02::1:ff2f:4b2a
bond0           2      ip6-allnodes
bond0           1      ff01::1
docker0         1      ff02::6a
docker0         1      ip6-allnodes
docker0         1      ff01::1
docker_gwbridge 1      ff02::fb
docker_gwbridge 1      ff02::1:ff18:7958
docker_gwbridge 1      ff02::6a
docker_gwbridge 1      ip6-allnodes
docker_gwbridge 1      ff01::1
vethdd20482     1      ff02::fb
vethdd20482     1      ff02::1:ff8a:c374
vethdd20482     1      ip6-allnodes
vethdd20482     1      ff01::1
veth8da20e2     1      ff02::fb
veth8da20e2     1      ff02::1:ff74:16d5
veth8da20e2     1      ip6-allnodes
veth8da20e2     1      ff01::1

[troglobit]

My guess is that the docker_bridge in the image blocks IGMP messages to/from the routing process from/to the docker multicast receiver application. Try disabling multicast_snooping on the bridge to see if that helps.

[campanada]

Thanks for the quick response. We will test and inform with any update

[campanada]

Hi again,

First of all thanks for the support,we finally got it to work. The problem was that the multicast address used seemed to be reserved and we don't know why but it doesn't work with that IPs 232.X.X.X
We changed to 224.0.83.x and now we can subscribe dinamically to multicast flow from docker.

The problem what we are trying to solve now is that is really slow. It takes more than 1.5 minutes to receive multicast and pimd notice since the internal docker application subscribes.

We are setup pimd.conf to only take into account the multicast range used but we have same behaviour.

Do you know what could be do to try to speed up?

Thanks again for your answers

Regards

[troglobit]

232.x.x.x is the SSM range.

I don't know what version of pimd you are running, but there have been several speedup fixes on the master branch for the next major release. However, there's at least one major issue remaining and I've not had time to work on pimd for a good while now.