Airplay/Multicast packet not flooding in bridge vlan

user52032 · Sun Aug 20, 2023 9:46 pm

Hi,

I've been stuck on this issue for a couple months now. I still can't get airplay to work on Sonos. Can I get some help?
I understand there's a thing called unknown-multicast-flood, but it isn't working for me.

Reproduction steps:

iphone->control center->antenna icon

In "Speakers & TV's" section, hit "TV Room" in list.

Expected result:

Links up in seconds.

Bug result:

Spinny wheel, then "[AirPlay] Unable to connect to "TV Room".

Cannot see packet at Mikrotik egress interface.

Config summary:

I have 1 bridge setup, with 3 VLANs on it. The VLAN with the airplay is 12.

Wireless Access Point is connected as a trunk port.

Dumb L2 switch is connected as an access port.

Sonos Arc is connected to the L2 switch.

AP -> port -> bridge -> port -> dumb switch -> Sonos.

Interface config:

# 2023-08-20 11:25:18 by RouterOS 7.11
# software id = <redacted>
#
# model = RB5009UPr+S+
# serial number = <redacted>
/interface bridge
add name=BR vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] name="1-Study Top" poe-out=off
set [ find default-name=ether2 ] name="2-Wifi Access Point"
set [ find default-name=ether3 ] name=3-VM poe-out=off
set [ find default-name=ether4 ] name=4-Switch poe-out=off
set [ find default-name=ether5 ] name=5-Hikvision poe-out=off
set [ find default-name=ether6 ] name="6-Living Top" poe-out=off
set [ find default-name=ether7 ] name="7-Living White" poe-out=off
set [ find default-name=ether8 ] name="8-Living Yellow" poe-out=off
set [ find default-name=sfp-sfpplus1 ] <redacted>
/interface vlan
add interface=BR name=BR-VLAN-Internet vlan-id=12
add interface=BR name=BR-VLAN-Restricted vlan-id=13
add interface=BR name=BR-VLAN-Work vlan-id=14
/interface list
add name=WAN
add name=LAN
add name=Internet
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=BR interface="1-Study Top"
add bridge=BR interface="2-Wifi Access Point"
add bridge=BR interface=3-VM
add bridge=BR frame-types=admit-only-untagged-and-priority-tagged interface=\
    4-Switch pvid=12
add bridge=BR frame-types=admit-only-untagged-and-priority-tagged interface=\
    5-Hikvision pvid=13
add bridge=BR interface="6-Living Top"
add bridge=BR frame-types=admit-only-untagged-and-priority-tagged interface=\
    "7-Living White" pvid=12
add bridge=BR frame-types=admit-only-untagged-and-priority-tagged interface=\
    "8-Living Yellow" pvid=12
/interface bridge vlan
add bridge=BR tagged="BR,2-Wifi Access Point,3-VM" untagged=\
    "4-Switch,7-Living White,8-Living Yellow" vlan-ids=12
add bridge=BR tagged="BR,2-Wifi Access Point,3-VM" untagged=5-Hikvision \
    vlan-ids=13
add bridge=BR tagged="BR,2-Wifi Access Point" vlan-ids=14
/interface detect-internet
set detect-interface-list=all
/interface l2tp-server server
set use-ipsec=yes

I can see the packet in the Wifi Access Point interface:

 0 time=0.187 num=1 direction=rx src-mac=E8:7F:95:3B:0B:15 dst-mac=01:00:5E:00:00:FB vlan=12:6 interface=2-Wifi Access Point src-address=192.168.12.253:5353 dst-address=224.0.0.251:5353 protocol=ip ip-protocol=udp size=189 cpu=0 
   ip-packet-size=171 ip-header-size=20 dscp=0 identification=32292 fragment-offset=0 ttl=255

I can see the packet at the bridge:

 time=0.805 num=1 direction=rx src-mac=E8:7F:95:3B:0B:15 dst-mac=18:FD:74:CC:B8:BC vlan=12:1 interface=BR src-address=192.168.12.253:49440 dst-address=192.168.200.15:8123 protocol=ip ip-protocol=tcp size=82 cpu=2 ip-packet-size=64 
   ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=64 tcp-flags=syn

I can even see the packet at the CPU VLAN interface on the bridge:

0 time=1.426 num=1 direction=rx src-mac=E8:7F:95:3B:0B:15 dst-mac=01:00:5E:00:00:FB interface=BR-VLAN-Internet src-address=192.168.12.253:5353 dst-address=224.0.0.251:5353 protocol=ip ip-protocol=udp size=177 cpu=0 ip-packet-size=163 
   ip-header-size=20 dscp=0 identification=24992 fragment-offset=0 ttl=255

But I don't see it on the L2 Switch port:

<empty>

sniffer setting:

[admin@MikroTik] /tool/sniffer> print 
                     only-headers: no
                     memory-limit: 100KiB
                    memory-scroll: yes
                        file-name: 
                       file-limit: 1000KiB
                streaming-enabled: no
                 streaming-server: 0.0.0.0:37008
                    filter-stream: no
                 filter-interface: 4-Switch
               filter-mac-address: 
           filter-src-mac-address: 
           filter-dst-mac-address: 
              filter-mac-protocol: 
                filter-ip-address: 192.168.12.253/32
            filter-src-ip-address: 
            filter-dst-ip-address: 
              filter-ipv6-address: 
          filter-src-ipv6-address: 
          filter-dst-ipv6-address: 
               filter-ip-protocol: 
                      filter-port: 
                  filter-src-port: 
                  filter-dst-port: 
                      filter-vlan: 
                       filter-cpu: 
                      filter-size: 
                 filter-direction: any
  filter-operator-between-entries: or
                          running: no

pe1chl · Mon Aug 21, 2023 12:46 am

It is correct behavior that multicast packets do not cross over to another VLAN in the bridge. You would need multicast routing or a multicast repeater for that.
When you have issues with Wireless on a VLAN not relaying multicast, configure "Multicast helper: full" on the Wireless interface.

user52032 · Mon Aug 21, 2023 1:41 am

Yes, I realize that I need a mDNS to get things working if they are across 2 VLANs. However, I moved out of that design a while back. The phone, the Sonos Arc, and the switch are all on VLAN 12.

What do you mean by "wireless interface"? I have a RB5009, which is all wired.

mkx · Mon Aug 21, 2023 8:37 am

What do you mean by "wireless interface"? I have a RB5009, which is all wired.

That's access point setting ... we probably all assume there is one in the game since you're mentioning iPhone ...

You could be seeing some bug with L2 HW offload on RB5009 (IIRC there are problems in latest ROS versions with that) ... so you may want to disable bridge HW offload by setting hw=no on all bridge ports and see if that helps.

pe1chl · Mon Aug 21, 2023 11:13 am

Yeah, when you are using an access point from another manufacturer, still check if it has some "multicast helper" or "multicast enhancement" and enable it, and if it has some "multicast filter" and disable it.

user52032 · Mon Aug 21, 2023 9:23 pm

What do you mean by "wireless interface"? I have a RB5009, which is all wired.

That's access point setting ... we probably all assume there is one in the game since you're mentioning iPhone ...

You could be seeing some bug with L2 HW offload on RB5009 (IIRC there are problems in latest ROS versions with that) ... so you may want to disable bridge HW offload by setting hw=no on all bridge ports and see if that helps.

I tried disabling HW switch a while back. I retried it just now on all ports.

Actually, that got the packets to the switch port at least. Thank you. AirPlay still doesn’t work though.

user52032 · Mon Aug 21, 2023 9:25 pm

Yeah, when you are using an access point from another manufacturer, still check if it has some "multicast helper" or "multicast enhancement" and enable it, and if it has some "multicast filter" and disable it.

I looked through all options in my AP, an Omada EAP 650. Didn’t find anything related to multicast.

Kentzo · Mon Aug 21, 2023 11:34 pm

AirPlay only uses mDNS for device discovery, not for actual streaming. If you see "TV Room" in the list then mDNS is working and the issue is not related to multicast.

The streaming itself is a unicast. Apple lists the following ports for Airplay: 554 UDP and 3689 TCP. Have you checked the firewall?

Amm0 · Tue Aug 22, 2023 1:23 am

And, AirPlay protocol apparently restricts itself to hosts within the same subnet. AirPlay also unusual in that it does not support DNS-SD registration either, which follow that the protocol is restricted, internally, to using same LAN. AirPrint etc allows cross-subnet/routed communications – just AirPlay does not.

So if even if mDNS reaches a subnet... the AirPlay "client" and "server" must be in same IP address range.

user52032 · Tue Aug 22, 2023 1:40 am

AirPlay only uses mDNS for device discovery, not for actual streaming. If you see "TV Room" in the list then mDNS is working and the issue is not related to multicast.

The streaming itself is a unicast. Apple lists the following ports for Airplay: 554 UDP and 3689 TCP. Have you checked the firewall?

Thanks for the suggestion. That does make sense. I explicitly added a rule in the firewall just now allowing those 2 ports as destination on forwarding chain. Still doesn’t work.

user52032 · Tue Aug 22, 2023 1:41 am

And, AirPlay protocol apparently restricts itself to hosts within the same subnet. AirPlay also unusual in that it does not support DNS-SD registration either, which follow that the protocol is restricted, internally, to using same LAN. AirPrint etc allows cross-subnet/routed communications – just AirPlay does not.

So if even if mDNS reaches a subnet... the AirPlay "client" and "server" must be in same IP address range.

Thanks for checking. They are both indeed on the same subnet.

user52032 · Tue Aug 22, 2023 1:42 am

At this point I blame Sonos actually. After disabling hardware switch, the multicast packet clearly reach the Sonos Arc port based on packet capture, but I don’t see a reply packet coming back.

Kentzo · Tue Aug 22, 2023 1:47 am

It's Sonos that sends mDNS for iPhone (and other devices to see), not the other way around.

Must be a misconfiguration somewhere. What is the IP of the Sonos device? Try to sniff all traffic between your iPhone and Sonos to see what ports are being used, see if you recognize any from the list.

jbl42 · Tue Aug 22, 2023 1:50 am

So if even if mDNS reaches a subnet... the AirPlay "client" and "server" must be in same IP address range.

My MacBook Pro streams video and audio over airplay to an AppleTV in a different VLAN/subnet without problems. Running an mDNS forwarder for discovery.
Don't know about Sonos, but this does not to seem general restriction with Airplay. At least not from Apple to Apple.

For the HW VLAN filtering on the bridge (what you definitely want to reenable once the problem with post discovery stream connections is solved):
mDNS L2 forwarding works on my RB5009 with VLAN HW filtering active on the bridge. mDNS uses 224.0.0.251, a link local multicast address which should be forwarded by bridges among L2 broadcast domains but never routed on L3 per RFC.
The only possibly relevant difference I see from your to my configuration is I have RSTP and IGMP snooping enabled on the bridge. Both should not affect link local multicast, but I saw some issues in this area on RB5009 bridges with HW offloading without. Maybe it's worth a try to enable those options (on or the other or both) on the bridge too see if it makes mDNS passing among bridge ports in the same VLAN.

robbiereindeer · Sun Mar 03, 2024 1:38 pm

Apologies for resurrecting an old thread, but turns out enabling IGMP snooping on the bridge was key to getting AirPlay to work across VLANs!

Without it, streaming to a HomePod would start for a second and then stop. Streaming to Sonos speakers worked fine. Apple devices apparently use multicast, Sonos does not.

AirPlay across VLANs with different subnets works, you need an mDNS repeater (the mDNS repeater docker image from https://hub.docker.com/r/scyto/multicast-relay works a treat, and as a bonus also repeats the SSDP protocol that Sonos uses besides mDNS) and as it turns out you need to enable IGMP snooping on your bridge.

The firewall rules between the VLANs to get it all working are left as an exercise for the reader, I'm still working on locking those down. You can always just allow AirPlay device unfettered access to the VLAN with clients.

Kentzo · Tue Mar 12, 2024 1:19 am

turns out enabling IGMP snooping on the bridge was key to getting AirPlay to work across VLANs!

This is interesting. If anything, I'd expect this feature to break things not fix them.

robbiereindeer · Tue Mar 12, 2024 12:52 pm

Hey Kentzo,

Turns out you're right, and I was wrong. I've turned off IGMP snooping, as it doesn't help after all (like you say, it has the potential to hinder).

I have multiple VLANs, and all of them run IPv4 and IPv6. I have homepods, an Apple TV and Sonos speakers in an IOT VLAN and my phone and Macbook in a trusted VLAN. Airplay (or rather Apple Music streaming via Airplay) sometimes worked, sometimes didn't. I have an mDNS repeater between the VLANs and the DNS entries make it across (There's an excellent mDNS browser called Discovery in the MacOS Appstore)

After deploying Wireshark, turns out the dual stack plays a role: when the Macbook is on Wifi, Airplay uses IPv4. When it's on a wired connection, it uses IPv6. Airplay over IPv4 works, over IPv6 it doesn't. It seems to break soon after it receives an mDNS reply for RAOP (Remote Audio Output Protocol), which is a different service to AirPlay. I guess Airplay is for streaming from a device to a speaker, RAOP is for when the speaker plays a source by itself (Apple Music) under the control of another device.

I'm still trying to figure out what is going on, but one theory is that RAOP uses the link local IPv6 address from a device on another VLAN, instead of its local or globally routable one (my VLANs run a private range and a public one obtained via prefix delegation)

I got confused because it sometimes worked and sometimes didn't, and switching on snooping seemed to fix it. Turns out i was sometimes trying it with the wired connection plugged in, and sometimes without (it would be on wireless, hence IPv4, hence working)

IGMP snooping and MLD (it's IPv6 friend) are meant to help reduce multicast traffic by having the MikroTik send it only where it is needed, not every port. Ubiquitu has the same, but in some older firmware versions with it switched off multicast Neighbour Discoverey messages also got dropped, breaking IPv6. That's no longer an issue. So yes, IGMP snooping doesn't fix AirPlay.

As far as I can tell, other than mDNS, AirPlay itself does not use broadcast or multicast in any way, it's all unicast. Which is why I'm stumped as to why it doesn't work on IPv6 - unless it's using link local addresses instead of routable ones.

Kentzo · Tue Mar 12, 2024 10:44 pm

I’m using Avahi in IPv4-only mode as the mDNS repeater in my HomeKit setup. However, my Airplay sources and destinations are in the same VLAN.

Airplay/Multicast packet not flooding in bridge vlan

Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Re: Airplay/Multicast packet not flooding in bridge vlan

Who is online