AirPlay can’t see the living room Apple TV. Chromecast disappears from the Google Home app the moment you walk into the kitchen. The HomePod mini in the bedroom shows up on one phone but not the other. The HP printer in the office is reachable from the main floor but invisible from upstairs. The Sonos app grays out a speaker every few hours. The Hue bridge works on Wi-Fi but not over the wired guest VLAN.
These look like five different problems. They’re all the same problem. Multicast.
This is the broader companion to our Sonos drops post and our VLANs explained for homeowners post. If you’ve started taking your home network seriously — managed switch, multiple SSIDs, an IoT VLAN, a guest network — there’s a class of consumer device that depends on the network being gloriously dumb to work right. Once you stop being dumb about your network, you have to make some deliberate choices about multicast or these devices start failing in confusing, intermittent ways.
Why “smart” devices lean so hard on multicast
Almost every consumer device that “just works” on Wi-Fi uses one of three discovery protocols, and all three rely on multicast or broadcast traffic:
- mDNS / Bonjour (Apple, printers, AirPlay, HomeKit, many IoT devices). Devices announce themselves on the link-local multicast address 224.0.0.251. Every other device listening for the same address hears the announcement. This is how your iPhone “just sees” the AirPlay target, no setup required.
- SSDP (Chromecast, Roku, DLNA, UPnP, some smart TVs). Same idea, different multicast address (239.255.255.250). The phone says “is anyone here a Chromecast?” and every Chromecast on the same broadcast domain answers.
- Plain broadcast (Hue bridges, older smart-home gear, some Wi-Fi setup flows). The device sends a packet to the entire subnet’s broadcast address. Anything on the same subnet sees it.
None of these protocols cross subnets by themselves. None of them survive aggressive multicast filtering. None of them were designed for a home with VLANs. They were designed for a flat network behind a single ISP router, where every device was on the same broadcast domain and multicast just “flowed.”
The minute you build a real network, you’ve introduced switches that can filter multicast (or do IGMP snooping), VLANs that don’t pass multicast between segments, and APs that may or may not bridge multicast to the wired side. Each of these is doing something legitimate. None of them know that your phone wants to find the AirPlay speaker.
The four levers you actually have
1. mDNS reflection (the one most people need)
If your phones live on the main VLAN and your AirPlay/Chromecast/HomeKit devices live on the IoT VLAN, mDNS reflection is the bridge. It listens for discovery packets on one VLAN, copies them to the other VLAN, and answers come back the same way. The packets are still multicast — they just get reflected across the VLAN boundary by the gateway.
On UniFi, you turn it on under Settings → Networks → [VLAN] → Multicast DNS. You enable it on every VLAN that needs to participate. Phones on the main VLAN will then see speakers, printers, and Apple TVs on the IoT VLAN. EdgeRouter and pfSense users use the Avahi package; OPNsense has it built in. Consumer routers don’t do this at all because they don’t do VLANs in the first place.
Caveat: mDNS reflection is leaky on purpose. It doesn’t care which device is asking. If you enable it between the main VLAN and the guest VLAN, guests will see your AirPlay speakers. Don’t enable it on guest networks unless you actually want that. Most properly-designed setups reflect between main and IoT only.
2. IGMP snooping (and the querier you forgot to configure)
IGMP snooping is a managed-switch feature that tries to be efficient about multicast. Instead of flooding every multicast packet to every port, it listens to IGMP “join” messages from devices and only forwards the relevant traffic to the ports that asked for it. It’s great for a network with a lot of multicast video. It’s a disaster for a home network that hasn’t configured a querier.
Snooping needs an IGMP querier on the network to periodically ask “hey, who’s still listening?” If no querier exists, the membership table on the switch ages out, the switch stops forwarding multicast to the ports it forgot about, and devices silently drop off groups. This is the single most common cause of intermittent AirPlay, Chromecast, and Sonos problems on “upgraded” home networks.
Two correct fixes. First: turn IGMP snooping off on the VLANs where it isn’t helping. The bandwidth savings on a residential network are negligible, and snooping-off restores the flat-network behavior these devices were designed for. Second: turn snooping on and also enable an IGMP querier on the gateway for that VLAN. UniFi calls this “IGMP Snooping” on the network and the querier is implicit when enabled gateway-side. Pick one path and commit; halfway is where the support calls live.
3. PIM (the one you almost certainly don’t need)
PIM (Protocol Independent Multicast) is what real routers use to route multicast between Layer 3 segments. If you have a campus, multiple buildings, or a wide-area video distribution system, PIM is what carries the multicast across routed links.
A house does not need PIM. Almost no residential gateway runs it correctly anyway. We mention it only because every couple of months a homeowner reads a blog post recommending PIM-SM and tries to enable it on their UDM. Don’t. mDNS reflection plus disabled snooping (or properly-configured snooping) handles every device class you’ll encounter in a single-family home.
4. AP-side multicast settings
Wi-Fi access points have their own opinions about multicast. By default, multicast frames are sent at the lowest supported data rate so every client can hear them — which means a single legacy 2.4 GHz client can drag your multicast traffic down to 1 Mbps and chew up disproportionate airtime.
On UniFi APs there are two relevant knobs: Multicast Enhancement (IGMPv3), which converts multicast to unicast for known listeners and is genuinely helpful on busy networks, and the multicast/broadcast rate limiter, which caps how much low-rate multicast can saturate the air. For a typical Utah home with 30–100 devices, Multicast Enhancement on, snooping off at the switch, and reflection on across VLANs is the stable combination we use on every install.
The classic device failures, mapped to causes
When we get called out for one of these, we already know which lever to pull before we walk in the door.
- AirPlay target invisible from one phone. Phone is on a different VLAN than the speaker, mDNS reflection isn’t enabled. Turn on multicast DNS for both VLANs.
- Chromecast disappears every few hours. IGMP snooping on, no querier. Disable snooping on the IoT VLAN or configure the querier on the gateway.
- HomeKit accessories “not responding” randomly. Almost always mDNS, occasionally a 2.4 GHz coverage issue masquerading as one. Check reflection and signal strength in that order.
- Hue bridge unreachable from the main VLAN. Bridge is on the IoT VLAN, discovery uses broadcast, the gateway isn’t bridging it. Either move the bridge to the main VLAN, set a static reservation and reach it by IP from the Hue app, or use mDNS reflection (Hue speaks mDNS too on recent firmware).
- Network printer scanning works but AirPrint doesn’t. Bonjour again. The printer is on the IoT VLAN, the laptop is on the main VLAN, no reflection.
- Sonos works on Wi-Fi but the app can’t see it from the wired desktop. Wired desktop is on a different VLAN than the speakers. See the Sonos drops post for the full walkthrough.
How we actually configure multicast on a Utah install
On a typical 4,000–6,000 sq ft Wasatch Front home with our standard four-VLAN layout (main, IoT, cameras, guest), the configuration looks like this:
- IGMP snooping off on the IoT and main VLANs. The 2–3 Mbps of multicast chatter we’re “saving” with snooping is invisible on a 10 Gbps switch backplane and not worth the support overhead.
- mDNS reflection enabled between the main VLAN and the IoT VLAN. Phones can find speakers and Apple TVs and printers; speakers can’t see the file server.
- No reflection from the guest or camera VLAN to anything else. Guests don’t need to see your home; cameras don’t need to talk to your phone — the NVR handles that.
- Multicast Enhancement on at the AP level. Quietly improves Wi-Fi airtime on busy networks.
- 2.4 GHz minimum data rate set to 12 Mbps, which prevents legacy clients from dragging multicast frames to 1 Mbps and starving the rest of the radio.
- Static DHCP reservations for every Apple TV, HomePod, Sonos, printer, and Hue bridge so we can reach them by IP if discovery breaks. Discovery is the easy mode; static IP is the fallback that always works.
Why the “just put it on the main VLAN” advice is wrong
A common shortcut, especially in Reddit threads, is “if multicast is hard, just put your AirPlay stuff on the same VLAN as your phones.” That works, in the same way that not building a roof makes you not have to clean the gutters.
The reason VLANs exist on a home network in the first place is that your IoT devices are untrustworthy. A modern Wi-Fi camera, a smart plug, a TV, a Roku — these run firmware you don’t control and phone home to servers you didn’t pick. Putting them on the same broadcast domain as your laptop and your photos is the security mistake you were trying to avoid by VLAN-ing in the first place. Multicast across VLANs is a solved problem. Use the lever, don’t collapse the network.
What this looks like in real Utah houses
The kind of home where this matters most:
- A four-AP wired UniFi install in a 5,000 sq ft Lehi build with two HomePods, three Apple TVs, four Chromecasts, two Sonos Era 300 speakers, a HEOS receiver, and an HP LaserJet. The owner uses a mix of iOS and Android. With reflection on and snooping off, everything is visible from every device.
- A Park City mountain home running a Lutron HomeWorks system and a 12-camera UNVR setup, with whole-home Sonos. Cameras live on a fully isolated VLAN that does not reflect mDNS. The Sonos and AirPlay layer works flawlessly across the main and IoT VLANs because we configured the reflector, not because we collapsed the segmentation.
- A Holladay remodel where the homeowner had a consumer mesh kit and “everything just worked.” We installed a managed network, half their Apple ecosystem went silent, and we got the panicked call within 24 hours. Two multicast settings later, every device was back. Same story we tell in the consumer-router upgrade post — the new network is better in every way once you’ve done the multicast homework.
Bottom line
Multicast is the invisible plumbing under most of what makes a smart home feel smart. AirPlay, Chromecast, HomeKit, AirPrint, Sonos, Hue, printers — all of it. On a flat consumer network it works by accident. On a real managed network with VLANs, you have to configure it deliberately: reflection across the VLANs that need it, snooping off (or a properly-configured querier), and a conservative AP-side multicast policy.
Get those three settings right and the smart-home layer feels exactly the way it did on the consumer router, with none of the security or reliability downsides. Get them wrong and you spend your evenings wondering why the bedroom HomePod disappeared again.
Keystone Integration designs and tunes managed home networks across Holladay, Park City, Lehi, Draper, and the rest of the Wasatch Front — VLAN-segmented, multicast-aware, and built so AirPlay and Chromecast still work the way you expect. See the full service list or get in touch for a network audit if your smart-home devices have started ghosting you.