Virtual ethernet or dummy for routing mDNS between vlans?

ginko · February 21, 2024, 6:39pm

Hi all, wanting to set up mDNS between my main network (vlan 20) and the IoT device network (vlan 40) to permit things like AirPlay to work.

At the present time I only have one device (eth1) that’s connected to my internal network as VyOS is set up as the WAN gateway/firewall to the rest of the network which itself is connected to a campus switch.

The switch itself doesn’t have any mDNS capability built-in which is why I’m looking to leverage the mDNS service in VyOS.

To set up mDNS on VyOS would it be better to:

Create two dummy interfaces assigning a unique IP from vlan 20 to one and a unique ip from vlan 40 to the other and setting the mDNS repeater service on the dummy interfaces
or
Similar to above but instead of dummy interfaces create two virtual ethernet devices veth0 and veth1 instead?

For this use case not sure if there’s difference in approach or whether one is better?

ginko · February 22, 2024, 2:02pm

Quick update:

I tried creating dummy interfaces assigning dum0 to 10.0.20.2/24 and dum1 to 10.0.40.2/24 and after issuing commit strangely all network access in and out was cut. Connectivity was restored through physical access and deleting the dummy interfaces.

Back to mDNS, I found a workaround through my access points which have a built-in mdns repeater and was able to get services like AirPlay working across vlans.

tristan · February 22, 2024, 7:47pm

That’s interesting. I haven’t had any issues using the mDNS repeater. I have a couple of VLANs that are on my bond0 interface (IoT/Servers/Users) that each have an interface on my router. I use Airplay and most importantly HomeKit for home automation stuff with Homeassistant/Homebridge.

set service mdns repeater interface 'bond0.4'
set service mdns repeater interface 'bond0.5'
set service mdns repeater interface 'bond0.100'

set interfaces bonding bond0 vif 4 address '10.0.4.2/24'
set interfaces bonding bond0 vif 5 address '10.0.5.2/24'
set interfaces bonding bond0 vif 100 address '10.0.100.2/24'

Share some of your configuration if you still want to leverage VyOS.

ginko · February 23, 2024, 1:38am

Hi Tristan, thank you and much appreciated! Yes would still be interested in doing this on VyOS rather than continue to put this duty on the AP. Below are snippets of my config along with explanation of the setup. Topology is looks like this: WAN<->VyOS<->Switch. VyOS and the switch are connected via through a single connection / trunk vlan.

10.0.255.1 and 10.0.255.254 are the IP’s on either end of the trunk with VyOS as x.255.254 and the Switch as x.255.1. The switch is configured to run as a router (L3). Fairly vanilla set up with no ACLs applied at this stage.

Vlan 20 and 40 are defined on the switch with interfaces 10.0.20.1 and 10.0.40.1 respectively. I’m doing DHCP on VyOS as the switch DHCP server can’t act as authoritative.

I previously tried tackling this through creating dummy interfaces assigned 10.0.20.2 and x.40.2 but as mentioned once I hit commit to create the interfaces it locked up all communication in and out of the network.

I saw that you used bonding interfaces → what led you to approach it this way?

interfaces {
    ethernet eth0 {
        ...
        description WAN
        ...
    }
    ethernet eth1 {
        address 10.0.255.254/24
        description LAN
        duplex auto
        hw-id xx:xx:xx:xx:xx:xx
    }
    loopback lo {
    }
}
...

service {
    dhcp-server {
        hostfile-update
        host-decl-name
        shared-network-name LAN {
            authoritative
            domain-name home.arpa
            subnet 10.0.255.0/24 {
                default-router 10.0.255.1
                range 0 {
                    start 10.0.255.50
                    stop 10.0.255.250
                }
            }
        }
        shared-network-name vl20_main {
            authoritative
            domain-name home.arpa
            domain-search home.arpa
            name-server 10.0.255.254
            subnet 10.0.20.0/24 {
                default-router 10.0.20.1
                range 0 {
                    start 10.0.20.50
                    stop 10.0.20.250
           		}
        	}
    	}
        shared-network-name vl40_iot {
            authoritative
            domain-name home.arpa
            name-server 10.0.255.254
            subnet 10.0.40.0/24 {
                default-router 10.0.40.1
                range 0 {
                    start 10.0.40.50
                    stop 10.0.40.250
                }
            }
        }
}
...

tristan · February 23, 2024, 3:42am

Thanks for the config insight! I was able to replicate your setup and noticed the same behavior when turning up the dum0/dum1 interfaces with 10.0.20.2/24 and 10.0.40.2/24 as the addresses. Removing them fixed the problem. How are you routing down to the switch? Static routes? Reason I ask is because the more preferred route will always be the directly attached one which is the dummy interfaces.

vyos@vyos:~$ sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

C>* 10.0.20.0/24 is directly connected, dum0, 00:01:55
S   10.0.20.0/24 [1/0] via 10.0.255.1, eth0, weight 1, 00:04:20
C>* 10.0.40.0/24 is directly connected, dum1, 00:01:54
S   10.0.40.0/24 [1/0] via 10.0.255.1, eth0, weight 1, 00:03:55
C>* 10.0.255.0/24 is directly connected, eth0, 00:17:27

This setup will blackhole your traffic till you remove the dum interfaces off. So that explains what you were seeing.

Here what I would do in your setup.

set interfaces ethernet eth1 vif 20 address '10.0.20.2/24'
set interfaces ethernet eth1 vif 40 address '10.0.40.2/24'

set service mdns repeater interface 'eth1.20'
set service mdns repeater interface 'eth1.40'

If your trunk isn’t carrying the VLANs then add them to it.

I use the bonded interfaces for some redundancy incase something happens on one of my switches in the stack the other link stays up. Honestly when it comes down to it I just over engineer everything and have too much equipment laying around to not use :).

ginko · February 23, 2024, 4:27am

Hi Tristan,

Thank you for your reply, yes the connection is through static routes between VyOS (eth1) and switch (uses the virtual ethernet device address for vlan 255). Regarding suggestion your suggestion to use a dummy interface here what would that do instead of using eth1? Initially thought it’s because the dummy interface stays up but if eth1 is down there won’t any traffic passing anyway.

From the VyOS side:

protocols {
    static {
        route 10.0.0.0/16 {
            next-hop 10.0.255.1 {
            }
        }
}

And from the switch side it’s configured as 0.0.0.0/0 to 10.0.255.254.

Waiting for the family to go to bed to implement your suggestion

tristan · February 23, 2024, 5:07am

Gotcha. Suggestion was to use virtual interfaces (vifs) and not use the dummy interfaces since those are causing the conflict on your network. When you commit the changes they end up squashing your static route pointing down to your switch this resulting in you losing internet connectivity.

With the dum interfaces on router

vyos@vyos:~$ sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

S>* 10.0.0.0/16 [1/0] via 10.0.255.1, eth0, weight 1, 00:00:03
C>* 10.0.20.0/24 is directly connected, dum0, 01:26:38
C>* 10.0.40.0/24 is directly connected, dum1, 01:26:37
C>* 10.0.255.0/24 is directly connected, eth0, 01:42:10

Switch#sh run | inc route
ip route 0.0.0.0 0.0.0.0 10.0.255.254

Switch#ping 10.0.255.254 source vlan 20
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.255.254, timeout is 2 seconds:
Packet sent with a source address of 10.0.20.1
.....
Success rate is 0 percent (0/5)
Switch#ping 10.0.255.254 source vlan 40
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.255.254, timeout is 2 seconds:
Packet sent with a source address of 10.0.40.1
.....
Success rate is 0 percent (0/5)

Without

vyos@vyos:~$  sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

S>* 10.0.0.0/16 [1/0] via 10.0.255.1, eth0, weight 1, 00:06:38
C>* 10.0.255.0/24 is directly connected, eth0, 01:48:45

Switch#ping 10.0.255.254 source vlan 20
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.255.254, timeout is 2 seconds:
Packet sent with a source address of 10.0.20.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/8/28 ms
Switch#ping 10.0.255.254 source vlan 40
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.255.254, timeout is 2 seconds:
Packet sent with a source address of 10.0.40.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/6 ms

Let me know how it goes! I would suspect it works .

ginko · February 24, 2024, 1:21am

Hi Tristan,

Tried the commands you suggested but it resulted in locking up the system again.

set interfaces ethernet eth1 vif 20 description 'vlan 20 interface for mDNS'
set interfaces ethernet eth1 vif 20 address '10.0.20.254/24'
set interfaces ethernet eth1 vif 20 description 'vlan 40 interface for mDNS'
set interfaces ethernet eth1 vif 40 address '10.0.40.254/24'

I’ve included a dump of the message log filtering on eth1.40 and eth1.20. Not sure what is happening to the VIF interfaces. I also see a few lines regarding martians on two devices at x.40.58 and x.40.60 …these are not critical components.

<user>@hostname:~$  cat /var/log/messages | grep "eth1.40"
Feb 23 19:18:50 <hostname> netplugd[1107]: eth1.40: state DOWN flags 0x00001002 BROADCAST,MULTICAST -> 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,10000
Feb 23 19:18:50 <hostname> netplugd[103818]: /etc/netplug/netplug eth1.40 in -> pid 103818
Feb 23 19:18:52 <hostname> netplugd[1107]: eth1.40: state INNING pid 103818 exited status 0
Feb 23 19:19:05 <hostname> zebra[1482]: [WPPMZ-G9797] if_zebra_speed_update: eth1.40 old speed: 0 new speed: 10000
Feb 23 19:19:13 <hostname> kernel: [244868.895122] IPv4: martian destination 0.0.0.0 from 10.0.40.58, dev eth1.40
Feb 23 19:19:16 <hostname> kernel: [244871.484539] IPv4: martian destination 0.0.0.0 from 10.0.40.58, dev eth1.40
Feb 23 19:19:19 <hostname> kernel: [244874.484373] IPv4: martian destination 0.0.0.0 from 10.0.40.58, dev eth1.40
Feb 23 19:19:22 <hostname> kernel: [244877.484138] IPv4: martian destination 0.0.0.0 from 10.0.40.58, dev eth1.40
Feb 23 19:19:25 <hostname> kernel: [244880.484259] IPv4: martian destination 0.0.0.0 from 10.0.40.58, dev eth1.40
Feb 23 19:19:28 <hostname> kernel: [244883.484284] IPv4: martian destination 0.0.0.0 from 10.0.40.58, dev eth1.40
Feb 23 19:19:31 <hostname> kernel: [244886.484267] IPv4: martian destination 0.0.0.0 from 10.0.40.58, dev eth1.40
Feb 23 19:19:35 <hostname> kernel: [244890.960735] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:19:38 <hostname> kernel: [244893.516986] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:19:41 <hostname> kernel: [244896.516944] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:19:44 <hostname> kernel: [244899.516848] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:19:47 <hostname> kernel: [244902.516968] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:19:50 <hostname> kernel: [244905.516927] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:19:53 <hostname> kernel: [244908.517013] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:02 <hostname> kernel: [244917.960729] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:05 <hostname> kernel: [244920.517178] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:08 <hostname> kernel: [244923.517033] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:11 <hostname> kernel: [244926.516996] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:14 <hostname> kernel: [244929.516811] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:17 <hostname> kernel: [244932.517254] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:20 <hostname> kernel: [244935.517252] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:31 <hostname> kernel: [244946.981949] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:34 <hostname> kernel: [244949.539346] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:37 <hostname> kernel: [244952.539435] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:40 <hostname> kernel: [244955.539763] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:43 <hostname> kernel: [244958.539196] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:46 <hostname> kernel: [244961.539699] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:20:49 <hostname> kernel: [244964.540514] IPv4: martian destination 0.0.0.0 from 10.0.40.60, dev eth1.40
Feb 23 19:25:15 <hostname> bgpd[1489]: [VCGF0-X62M1][EC 100663301] INTERFACE_STATE: Cannot find IF eth1.40 in VRF 0
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.40: can't get flags: No such device
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.40: state ACTIVE flags 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,10000 -> 0x00001002 BROADCAST,MULTICAST
Feb 23 19:25:15 <hostname> netplugd[104360]: /etc/netplug/netplug eth1.40 probe -> pid 104360
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.40: can't get flags: No such device
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.40: state PROBING pid 104360 exited status 256
Feb 23 19:25:15 <hostname> netplugd[1107]: Could not bring eth1.40 back up
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.40: can't get flags: No such device
Feb 23 19:25:20 <hostname> netplugd[1107]: eth1.40: can't get flags: No such device
Feb 23 19:25:20 <hostname> netplugd[1107]: eth1.40: can't get flags: No such device
Feb 23 19:25:20 <hostname> netplugd[1107]: eth1.40: can't get flags: No such device

<user>@hostname:~$  cat /var/log/messages | grep "eth1.20"
Feb 23 19:18:50 <hostname> netplugd[1107]: eth1.20: state DOWN flags 0x00001002 BROADCAST,MULTICAST -> 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,10000
Feb 23 19:18:50 <hostname> netplugd[103790]: /etc/netplug/netplug eth1.20 in -> pid 103790
Feb 23 19:18:52 <hostname> netplugd[1107]: eth1.20: state INNING pid 103790 exited status 0
Feb 23 19:19:05 <hostname> zebra[1482]: [WPPMZ-G9797] if_zebra_speed_update: eth1.20 old speed: 0 new speed: 10000
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.20: state ACTIVE flags 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,10000 -> 0x00001003 UP,BROADCAST,MULTICAST
Feb 23 19:25:15 <hostname> netplugd[104340]: /etc/netplug/netplug eth1.20 out -> pid 104340
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.20: state OUTING flags 0x00001003 UP,BROADCAST,MULTICAST -> 0x00001002 BROADCAST,MULTICAST
Feb 23 19:25:15 <hostname> bgpd[1489]: [VCGF0-X62M1][EC 100663301] INTERFACE_STATE: Cannot find IF eth1.20 in VRF 0
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.20: can't get flags: No such device
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.20: can't get flags: No such device
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.20: can't get flags: No such device
Feb 23 19:25:15 <hostname> netplugd[1107]: eth1.20: can't get flags: No such device
Feb 23 19:25:20 <hostname> netplugd[1107]: eth1.20: can't get flags: No such device
Feb 23 19:25:20 <hostname> netplugd[1107]: eth1.20: state DOWNANDOUT pid 104340 exited status 0
Feb 23 19:25:20 <hostname> netplugd[104419]: /etc/netplug/netplug eth1.20 probe -> pid 104419
Feb 23 19:25:20 <hostname> netplugd[1107]: eth1.20: can't get flags: No such device
Feb 23 19:25:20 <hostname> netplugd[1107]: eth1.20: state PROBING pid 104419 exited status 256
Feb 23 19:25:20 <hostname> netplugd[1107]: Could not bring eth1.20 back up
Feb 23 19:25:20 <hostname> netplugd[1107]: eth1.20: can't get flags: No such device

tristan · February 24, 2024, 3:31am

Strange… looks like it’s having trouble even bringing them up correctly. This is a fairly straightforward config.

What does show interfaces say and what version of VyOS are you running? Also your trunk port is it just the standard “switchport mode trunk” or the equivalent is to your switch?

Apachez · February 24, 2024, 3:55am

Generally speaking the naming in Linux kernel for various features are sometimes a bit confusing when coming from the networking world.

For example vrf in a Linux kernel (and therefor in VyOS) isnt the same as a vrf in a lets say Arista, Cisco or Juniper. The equal to vrf in them is rather netns in Linux (and by that VyOS) for the isolation of interfaces and then vrf in Linux (VyOS) for the routingtable itself.

Same goes with wtf a veth is compared to a vlan interface which with Linux and VyOS lingo is a vif.

Which boils down to dummy interfaces in Linux (VyOS) which is equal to loopback interfaces in regular network hardware.

The thing with dummy/loopback interfaces is that they are normally only configured as /32 when it comes to IPv4. The purpose of these is to have an “always on” interface connected to the router itself. This also means that this interface is available through all vlan interfaces with an IP address configured (and IP routing enabled on the device).

The always on comes from that an vlan interface is only reachable if one of the physical interfaces which belongs to this vlan is connected.

Example:

Regular network gear:

vlan101: 192.168.101.254/24
vlan102: 192.168.102.254/24
vlan103: 192.168.103.254/24
loopback0: 10.0.0.1/32

Linux (VyOS):

vif101: 192.168.101.254/24
vif102: 192.168.102.254/24
vif103: 192.168.103.254/24
dummy0: 10.0.0.1/32

The above means that a client on vlan101 lets says 192.168.101.1 who uses 192.168.101.254 as its default gateway can talk to (ping, ssh, bgp etc) with 10.0.0.1 which will be routed to the router itself since its “directly attached”.

The loopback interfaces can also be configured with vrf to isolate them from various networks, lets say you got MGMT, UNDERLAY and OVERLAY as vrfs. When the loopback0 is configured with vrf UNDERLAY then the OVERLAY clients wont be able to reach it (or rather the 10.0.0.1 which those clients reach will not be the router itself but something else thats reachable elsewhere as 10.0.0.1). To do this in a Linux (VyOS) box you would need to configure both netns and vrf.

So what I want to say with above is that you should try to set your dummy0 interface with a /32 mask. However in your usecase I think configuring your vif with an IP-address (which is what your clients at this vlan will use as their default gateway) should also be enough.

ginko · February 24, 2024, 6:55am

Thank you Apachez, your suggestion to use a /32 worked insofar as I was able to assign IPs to the vif’s.

I’m just trying to understand what you mean by “configuring your vif with an IP-address (which is what your clients at this vlan will use as their default gateway) should also be enough”

Do you mean that I assign the actual vlan gateway addresses as the address for each vif respectively on VyOS (which would be 10.0.20.1 and 10.0.40.1 as shown below)? Or do you mean to simply assign them any fixed address in the vlan 20 and vlan 40 ip range respectively ?

Last question is regarding the firewall zone for LAN, it presently includes interface eth1, would I need to include interfaces eth1.20 and eth1.40 or does having eth1 there imply that the vif traffic will also pass?

Config used in switch:

# Default vlan ... not used
interface ve 1
 ip address 10.0.1.1 255.255.255.0
!
# Main network vlan interface
interface ve 20
 ip address 10.0.20.1 255.255.255.0
 ip helper-address 1 10.0.255.254
!                                                             
# IoT network vlan interface
interface ve 40
 ip address 10.0.40.1 255.255.255.0
 ip helper-address 1 10.0.255.254
!
# transport vlan interface
interface ve 255
 ip address 10.0.255.1 255.255.255.0
!
!
!
!
# static route from switch to VyOS
ip route 0.0.0.0/0 10.0.255.254

ginko · February 24, 2024, 3:30pm

Update, I performed the below steps and can see mDNS traffic on the individual interfaces but I do not believe the interfaces are communicating between each other. I arrived at this because on my phone device, I do not see the speakers located on the IoT vlan show up in AirPlay.

Steps applied so far:

I went with .254 addresses for the vif interfaces
I added eth1.20 and eth1.40 to the LAN zone
Set up the mDNS repeater service between eth1.20 and eth1.40
I ran tcpdump on both eth1.20 and eth1.40 and could see some multicast traffic

My suspicion at this time:
Comparing traffic from tcpdump and the mDNS repeater log, I see references to .local without any additional host information added before the .local but on the VyOS mDNS repeater log I’m seeing reference to .local … could this difference in hostname be what’s preventing the traffic from reaching across the interfaces?

Feb 24 09:39:02 avahi-daemon[121823]: Server startup complete. Host name is (hostname).local. Local service cookie is 2923152998.

<user>@(hostname):~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface    IP Address             MAC                VRF        MTU  S/L    Description
-----------  ---------------------  -----------------  -------  -----  -----  --------------------------
eth0         xx.xx.xx.xxx           xx:xx:xx:xx:xx:xx  default   1500  u/u    WAN
eth1         10.0.255.254/24        xx:xx:xx:ea:xx:b1  default   1500  u/u    LAN
eth1.20      10.0.20.254/32         xx:xx:xx:ea:xx:b1  default   1500  u/u    vlan 20 interface for mDNS
eth1.40      10.0.40.254/32         xx:xx:xx:ea:xx:b1  default   1500  u/u    vlan 40 interface for mDNS

...
    zone LAN {
        default-action drop
        from LOCAL {
            firewall {
                name LOCAL-LAN
            }
        }
        from WAN {
            firewall {
                name WAN-LAN
            }
        }
        interface eth1
        interface eth1.20
        interface eth1.40
    }

...
sample output from tcpdump:
10:17:46.729659 IP 10.0.40.61.5353 > 224.0.0.251.5353: 0 SRV (QM)? switch 00146674._hap._tcp.local. (49)
10:16:46.688654 IP 10.0.40.61.5353 > 224.0.0.251.5353: 0 SRV (QM)? homepodsensor 610228._hap._tcp.local. (54)
10:16:46.942404 IP 10.0.40.64.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/5 (Cache flush) SRV Office.local.:60294 0 0 (188)