search

troglobit / pimd

PIM-SM/SSM multicast routing for UNIX and Linux
http://troglobit.com/projects/pimd/
BSD 3-Clause "New" or "Revised" License
202 stars 90 forks source link

Problem with ignoring same subnet #156

Closed hugohuetzel closed 4 years ago

hugohuetzel commented 4 years ago

Hi,

i have a special configuration to test/simulate automotive ethernet. I have configured for each ECU to simulate a device to set the MAC address and set a link for each VLAN. All devices are connected to a virtual bridge.

for example: Virtual-BRIDGE -- ECU1 MAC=20:00:00:00:01:01 ---- VLAN1 192.168.1.1/24 ---- VLAN2 192.168.2.1/24 ---- VLAN3 192.168.3.1/24 -- ECU2 MAC=20:00:00:00:01:03 ---- VLAN1 192.168.1.3/24 ---- VLAN2 192.168.2.3/24

The problem is that ECU2-VLAN1 and ECU2-VLAN2 are ignored because they are in the same subnet as ECU1-VLAN1 and ECU1-VLAN2. So no multicast packet from ECU2 can be send to ECU1.

troglobit commented 4 years ago

I'm sorry, but I don't understand your setup. What is a virtual bridge, and what is an ECU?

When I use bridges I set up things like this:

      br0.1    br0.2
           \  /     
         .--br0---. 
        /  /   \   \
    eth0 eth1  eth2 eth3
     1U   1U    2U   2U 

br0.1 -- IP: 192.168.1.1/24
br0.2 -- IP: 192.168.2.1/24

In my example pimd runs on br0.1 and br0.2 VLAN interfaces (layer-3). Any multicast coming in on any of the Ethernet ports in VLAN 1 (eth0 or eth1), can both be bridged to the other port in the same VLAN, or routed using the kernel multicast routes, set up by pimd, to VLAN 2 where either eth2 or eth3 is the receiver, or both.

pimd does not support having the same IP subnet on br0.1 and br0.2, but neither does regular unicast routing. For that to work you need either policy routing or VRF, neither of which have support in pimd, and even if it did it would not be possible to route between different "domains" like that.

PIM is a protocol independent multicast routing protocol. This means it relies on unicast routes being set up, either statically or using protocols like RIP or OSPF which are handy when there are multiple routers. A good basic test to use is to first try to send unicast ping between end devices, if that doesn't work, then multicast with pimd will not work either.

hugohuetzel commented 4 years ago

Hello,

ECU stands for electronic control unit (in german "Steuergerät"), the little computers in cars.

My setup looks like this:

               ...br0.....
              /           \
      ...veth1...           veth2
     /     |     \         /     \
 vlan1.1 vlan1.2 vlan1.3 vlan2.1 vlan2.2

With:

We need this to simulate (residual bus simulation) a car automotive ethernet setup (new vehicle bus like CAN or FlexRay in cars). The setup is given by the car manufacturers.

troglobit commented 4 years ago

From my limited understanding of bridging and IP networking in Linux, that will not work.

I'd try something like this, with a VLAN filtering bridge, and each of the veth-peerN's in a container, or at least separate network namespace, for each of the end devices. On the end of the veth pairs.

     br0.1  br0.2  br0.3      Layer-3 interfaces, with IP
          \   |   /           192.168.n.1/24 in each VLAN
           \  |  /
            \ | /             Layer-2 bridge w/ VLAN filtering
         .---br0---.          br0 is tagged member i all VLANs
         |         |
       veth1     veth2        veth1 tagged member in VLAN 1,2,3
         |         |          veth2 tagged member in VLAN 1,2
         |         |
       veth1     veth2        veth1-peer and vlan2-peer carries
       -peer     -peer        VLAN tagged traffic, which can be
     /   |  \                 extracted with a VLAN interface,
    ..  ..  veth1-peer.2      e.g., veth1-peer.2

Notice the br0.1 to br0.3 interfaces, that's where both ospf/rip and pimd could run and forward both unicast and multicast traffic.