Tutorial

[VeniceNerd]

Hi!

this plugin looks exactly like what I need but I’m wondering if a tutorial is available on how to install and how to use it?

I would like to install this in a docker container (via Portainer) on my raspberry Pi to route mdns traffic between my main lan and my VPN VLAN. Currently ubiquity does not forward mdns traffic to the VPN.

Couple of questions:

• would that work with this plugin?
• If my pi is only connected to the main LAN can it still broadcast to the other vlans?
• Is it possible to install this in a docker container? And if so what network mode would I have to choose?

And if anyone knows any YouTube tutorials or step by step guides that would be wonderful! Right now I’m having a bit of a hard time getting everything to work.

Thanks so much!

[alsmith]

Hi there!

• Yes this ought to work!
• Yes if your Pi is connected to the main LAN then you can configure a VLAN on it and it'll work fine.
• @scyto made a docker container out of this and you can pass in the required arguments (https://github.com/scyto/multicast-relay) although adding it to /etc/rc.local might well be simpler.

To enable your Pi to see VLANs, you'd need to do the following somewhere in the system's startup scripts. If you need to talk to vlan 10, for example, this is how you'd set that up.

vconfig add eth0 10
ifconfig eth0.10 up

Then pass in the required interface names to multicast-relay - this would bridge mDNS etc between eth0 and vlan 10.:

./multicast-relay.py --interfaces eth0 eth0.10

Does this help you out ?

[VeniceNerd]

Hey thanks so much for your time explaining this!

Quick questions:

• if I install this on a Pi (adding the VLANS to the startup scripts) do I still have to install anything on my Dream Machine Pro Just wondering since you linked to SYCTO's forge and if I understand correctly they are supposed to be run directly on the DMP? I'm a bit nervous about fiddling with my DMP so I'm hoping I can just achieve this on a Pi by itself.

• If I add your two commands to the PI startup script ("vconfig add eth0 10" & "ifconfig eth0.10 up") does the PI then automatically understand that VLAN 10 has address 10.0.10.x? My main network is 10.0.1.x. My VLANs are 20 (10.0.20.x) and 30 (10.0.30.x). Just trying to wrap my head around how the PI would figure out that eth0 20 translates to 10.0.20.x.

• If I install this in a docker container on my Pi what network mode would I have to set the container to? Bridge mode, Host mode or Container mode? For most of my containers (homebridge, etc...) I just use Bridge Mode but since this seems to need more direct access to the network I'm not sure.

Thank again for your help!

[alsmith]

Hi @VeniceNerd !

1. I reckon that if you manage to get the discovery working via the Pi, that you'd not need to install anything special on the DMP.

2. Ah you'd have to work out how to either get it to run dhcpd and grab an address, or configure the address manually in somewhere like /etc/rc.d/rc.inet1.conf

3. And finally, you'd need something like macvlan so that the docker container appears directly on the network rather than via the docker's networking stack. Then again, the very easiest way to run this is just add the multicast-relay.py invocation into /etc/rc.local and call it good. Maybe I'm not seeing what benefits a docker container has?

Kind regards,
Al.

[VeniceNerd]

Interesting. So do you recon it would be easier to just install this on the UDMP since it sits right at the source instead of installing it on a raspberry pi?

I have to install all of this remotely since im currently stuck in Europe and im a bit nervous about messing something up. ;)

[alsmith]

Ah no I was thinking that it would be easier to install it on the Pi directly, rather than put it in a docker container on the Pi.

[noumenon272]

In case anyone stumbles on this:

after quite a lot of trial and error, I managed to get this to work via docker compose in a docker container not on my unifi system (rather it is on my server where I also run a dockerized version of the unifi controller). the sticking point, ultimately, was that the interface names inside the container are eth0, eth1 etc. once I figured that out, it was pretty straight forward. I have macvlans for each vlan defined by my Unifi UXG.

  multicast-relay:
    container_name: multicast-relay
    image: scyto/multicast-relay
    restart: unless-stopped
    networks:
      core:
        ipv4_address: 192.168.1.52
      vlan20:
        ipv4_address: 192.168.20.43
      vlan30:
        ipv4_address: 192.168.30.20
      vlan40:
        ipv4_address: 192.168.40.52
      vlan60:
        ipv4_address: 192.168.60.52
      vlan70:
        ipv4_address: 192.168.70.52 
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - INTERFACES=eth0 eth1 eth2 eth3 eth4 eth5
      - OPTS=--noMDNS

networks:
  core:
    driver: macvlan
    driver_opts:
      parent: bond0
    ipam:
      config:
        - subnet: 192.168.1.0/24
  vlan20:
    driver: macvlan
    driver_opts:
      parent: bond0.20
    ipam:
      config:
        - subnet: 192.168.20.0/24 

etc for all additional vlans

[scyto]

@noumenon272 welcome to the world of linux interfaces :-) yes there rarely bridges on standard servers which is why you dont need to use BRx interfaces.

You shouldn't need to use macvlan - host networking will work just as well (of course if you want a different mac for this traffic and used macvlan for that thats ok too :-) )

want to suggest an edit to the project readme about interfaces? feel free to clone the rep and propose some changes in a PR.

[noumenon272]

@scyto
That would only work if the host had an IP or interface on each vlan, correct?

B/c my host only has one IP and then it has a bunch of docker containers on different vlans.