0

I am trying to forward the multicast traffic arriving on interface eth1 to a bridge I created with ip link add br0 type bridge.

Elsewhere I have done this with a simple ip route add 226.3.2.1 dev docker0 (other machine).

I have now tried several things and also played around with multicast routers like pimd. However, I do not manage to redirect or forward the traffic. When I use the ip route add command in my test setup, I still see the multicast traffic in tcpdump but not in my multicast receive script (on eth1).

In context, I want to forward the multicast traffic to a bridge, which I somehow include in a kubernetes container via multus-cni.

The interfaces (eth1 is receiving the multicast traffic on 226.3.2.1):

2324: eth0@if2325: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:c0:a8:80:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.128.2/20 brd 192.168.143.255 scope global eth0
       valid_lft forever preferred_lft forever
21: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether be:ec:42:84:8c:35 brd ff:ff:ff:ff:ff:ff
2340: eth1@if2341: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:c0:a8:90:05 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.144.5/20 brd 192.168.159.255 scope global eth1
       valid_lft forever preferred_lft forever

tcpdump of eth1 226.3.2.1

15:07:52.288989 IP (tos 0x0, ttl 3, id 22735, offset 0, flags [DF], proto UDP (17), length 34)
    192.168.144.1.37394 > 226.3.2.1.9000: [bad udp cksum 0x34ce -> 0xd209!] UDP, length 6
15:07:52.435168 IP (tos 0x0, ttl 3, id 22745, offset 0, flags [DF], proto UDP (17), length 34)
    192.168.144.1.37394 > 226.3.2.1.9000: [bad udp cksum 0x34ce -> 0xd209!] UDP, length 6
15:07:52.620215 IP (tos 0x0, ttl 3, id 22758, offset 0, flags [DF], proto UDP (17), length 34)
    192.168.144.1.37394 > 226.3.2.1.9000: [bad udp cksum 0x34ce -> 0xd209!] UDP, length 6
15:07:52.747806 IP (tos 0x0, ttl 3, id 22783, offset 0, flags [DF], proto UDP (17), length 34)
    192.168.144.1.37394 > 226.3.2.1.9000: [bad udp cksum 0x34ce -> 0xd209!] UDP, length 6

ip maddr

21:     br0
        link  33:33:00:00:00:01
        link  01:00:5e:00:00:6a
        link  33:33:00:00:00:6a
        link  01:00:5e:00:00:01
        link  01:00:5e:03:02:01
        inet  226.3.2.1
        inet  224.0.0.1
        inet  224.0.0.106
        inet6 ff02::6a
        inet6 ff02::1
        inet6 ff01::1
2324:   eth0
        link  33:33:00:00:00:01
        link  01:00:5e:00:00:01
        inet  224.0.0.1
        inet6 ff02::1
        inet6 ff01::1
2340:   eth1
        link  33:33:00:00:00:01
        link  01:00:5e:00:00:01
        link  01:00:5e:03:02:01
        inet  226.3.2.1
        inet  224.0.0.1
        inet6 ff02::1
        inet6 ff01::1

If I run iperf locally with a server bound to br0 and a client bound to eth1 without any ip route the server on br0 receives the traffic. (iperf -c 226.3.2.1%eth1 -u -T 32 -t 3 -i 1 and iperf -s -u -B 226.3.2.1%br0 -i 1)

Also if I run iperf iperf -c 226.3.2.1%eth1 -u -T 32 -t 3 -i 1 on the server and iperf -s -u -B 226.3.2.1%eth1 -i 1 inside the container it receives the traffic (eth1 are different interfaces here).

The problem is just how do I forward from eth1->br0

EDIT:

Network context

Ok, so I try to provide a little more context. I use multus-cni to attach multiple network interfaces to the container. This additional interface inside the container is called eth1 and is bridged with br0 on the host (via cni bridge plugin).

A thing which is currently working is, if I run an iperf client on the eth1 interface on the host and and iperf client on eth1 on the container the traffic is shown.

The problem is the eth1->br0 part on the host this multicast traffic don’t gets forwarded and therefore is not accessible of the br0 interface. I cannot tell if it would be accessible inside the container if the forwarding would succeed.

Currently if I run a small python script, which binds on the network interfaces and joins the 226.3.2.1 multicast group it only shows the traffic if bound to eth1 on the host. With br0 it shows nothing.

The TTL of the udp packets is 3 but I could increase it if necessary.

0

1 Answer 1

0

So, after a complete reset of my test envirionment and purging everything it started working.

  1. I add an bridge interface
ip link add br0 type bridge

# The ip addr add step is optional but otherwise 
# pimd will not recognize the interface as present.
ip addr add 10.10.0.1/16 brd + dev br0

ip link set up br0
  1. Edit the pimd config in /etc/pimd.conf by appending the following:
phyint eth1 enable ttl-threshold 1
phyint br0 enable ttl-threshold 1
  1. Start pimd pimd --disable-vifs -l debug
  2. Install multus-cni inside the kubernetes cluster
  3. Create a bridge network attachment
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: udp-multicast-conf
  namespace: kube-system
spec:
  config: '{
      "cniVersion": "1.0.0",
      "type": "bridge",
      "bridge": "br0",
      "ipMasq": true,
      "isGateway": true,
      "hairpinMode": true,
      "ipam": {
          "type": "host-local",
          "subnet": "10.10.0.0/16"
      }
    }'
  1. Attach the bridge to your pods by adding k8s.v1.cni.cncf.io/networks: kube-system/udp-multicast-conf@eth1 as annotation.

Note

pimd will only route the traffic of eth1 to the br0 interface, if anything on the br0 side has joined a specific multicast group. With multiple network interfaces make sure to join the multicast group on the right one. Default implementation will default to join the nic with the default ip route.

Ref: C/Python -> IP_ADD_MEMBERSHIP

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .