Multicast over “stupid” networks

IP multicast is an interesting technology. It’s main purpose is to
save network bandwidth as much as possible – traffic is sent to hosts
which asked for it only (as opposed to broadcast). On the other
side, you need smarter (manageable) switches and separate and
non-trivial configuration on both routers and switches. Even more
complicated it is when you try to make it work over VPN.

I have a server, which can join multicasts using IGMP on one
interface and has a public IP on another interface. I wanted it to make
those multicasts available via VPN.

It has a static route for multicast to know where to join them:

route add -net 224.0.0.0/4 dev eth1

So my first try was to use OpenVPN with tun device (routed IP packets). I set it up to push route to clients:

push "route 224.0.0.0 240.0.0.0"

And to to preserve TOS value for QoS:

passtos

Next, I needed to make my server join on eth1 and route multicasts to
tun0 interface. Linux has a native support for multicast routing but it
needs to be managed by an userspace application which statically or
dynamically manages routes. For this I used igmpproxy. It listens for IGMP packets on tun0, joins/unjoins multicasts on eth1 and install multicast routes accordingly.

# ip mroute show
(10.2.3.1, 239.12.12.1)   Iif: eth1       Oifs: tun0

This was working ok, but it has one huge disadvantage: OpenVPN treats
multicasts as broadcast and sends them to all clients. If you have VPN
clients with poor network or CPU performance, you can effectively make
the VPN unusable for them.

igmpproxy can listen on multiple interfaces (even dynamically created)
so if each client had it’s own tun interface the above problem would
disappear, but unfortunately OVPN can’t do this. There are VPNs which do
this by default e.g. pptpd (I tested it and it works) but I wanted to
stay with OpenVPN.

Solution

So I came to an idea to use tap device. Even though OVPN does the
same as in TUN mode and brodacasts packets to all clients (there are
some efforts to change it), I got a new opportunity: to direct the packets using Ethernet header.

The idea is following: I’ll write a daemon, which will listen and
process IGMP joins on VPN tap interface. When it gets one, it will
record senders MAC address, join requested group on upstream interface a
listen for incoming multicast packets. It will then take the whole IP
packet, prepends recorded destination MAC, some source MAC and send it
to the tap interface. This should cause the packet to be sent only to
one client but keep the IP payload unchanged.

So I wrote a prototype and for my surprise it also WORKS! At least on Linux. You can find it here.
Feel free to test it. Now to explain the title, this daemon can be also
used for network with stupid switches to avoid network flooding. The
traffic effectively changes to unicast on link layer and is delivered
directly to subscribers.

I hope this helps someone with similar problem.
Looking forward for your comments and suggestions.

Bye!

3 thoughts on “Multicast over “stupid” networks”

  1. Hi Danman

    Im struckling with openvpn and multicast my self, but and fairly new to linux and openvpn.

    I have my openvpn running on an virtual server, and devices can see each other by ping, but i need to allow multicast.

    The devices are on mobile 3g/4g networks with the vpn to the openvpn server and of what i can understand the android devices does not allow TAPs which in my case then leave me for routing vpn.

    Not sure if i understand your topology correct. but if you any hint/ guides everything would be grateful accepted

    best regards
    Kevin

      1. Hi again.

        I want the multicast send from the tunnel returned to other devices in the tunnel if this makes sense

        Best regards
        K

Leave a Reply

Your email address will not be published. Required fields are marked *