There’s a class of homeowner complaint that always comes in roughly the same shape: “Everything was working, then we upgraded to a managed network, and now AirPlay doesn’t see the living room speakers anymore.” Or HomeKit only shows half the lights. Or the printer disappears from the kids’ iPads but works on the parents’ laptops. Or Chromecast can’t cast from the guest Wi-Fi.
These all look like different problems. They’re the same problem. Every one of those features depends on a class of network traffic called multicast — and multicast is the single most common reason a “real” managed home network breaks consumer smart-home gear that worked fine on a flat ISP router. Our Sonos drops post covers the specific Sonos symptom in detail. This one is the broader companion: how multicast actually works, what mDNS and IGMP snooping do, and how to set them up so AirPlay, Chromecast, HomeKit, and printers behave on a network that has VLANs and managed switches.
What multicast is, in one paragraph
In a normal “unicast” conversation, one device talks to one other device by IP address. In a broadcast, one device talks to every device on the network at once (chatty, wasteful). Multicast is the middle path: one device sends a packet to a group address, and only the devices that have subscribed to that group receive it. This is how Sonos speakers find each other, how AirPlay announces an Apple TV, how mDNS lets your phone discover the printer without you typing in an IP, and how HomeKit discovers a new Hue Bridge. It’s elegant and efficient when it works. When it doesn’t, the features that depend on it just silently stop appearing.
The two protocols you actually need to know
mDNS (Multicast DNS)
mDNS is the discovery protocol that powers Bonjour (Apple), Avahi (Linux), and most of what Android calls Network Service Discovery. When your iPhone wants to find an AirPlay speaker, it sends a multicast query to a special address (224.0.0.251 / FF02::FB) asking “is anyone here advertising _airplay._tcp.local?” Every device on the local network that supports AirPlay answers. Your phone now has a list of speakers without anyone configuring an IP.
Critical detail: mDNS uses link-local multicast. That’s a fancy way of saying “the packet does not cross between subnets without help.” If your phone is on the main 10.0.10.x VLAN and the AirPlay speaker is on a 10.0.40.x IoT VLAN, mDNS packets do not cross the boundary by default. The phone never sees the speaker. The speaker is not broken. The router silently dropped the discovery packet at the VLAN edge.
IGMP snooping
IGMP (Internet Group Management Protocol) is how devices tell the network “I want to receive multicast traffic for group X.” The switch keeps a table of which switch ports have devices subscribed to which groups, and forwards multicast traffic only to those ports. Without snooping, the switch treats multicast like broadcast and floods every port. With snooping, traffic is targeted — efficient.
Snooping needs a querier on the network to periodically ask “hey, who’s still in group X?” If the querier is missing or misconfigured, the membership table goes stale, and multicast quietly stops being delivered to the right ports. Sonos drops, AirPlay vanishes, HomeKit shows “no response.”
The four scenarios where home multicast breaks
1. You added VLANs but didn’t set up mDNS reflection
The most common pattern. A homeowner reads our VLANs explained guide, builds a sane segmentation (Main, IoT, Guest, Cameras), and immediately discovers that the Sonos is on IoT, the iPhone is on Main, and they can’t see each other. The VLANs did exactly what they were supposed to do: they isolated traffic. Including the discovery traffic.
The fix is mDNS reflection (sometimes called Bonjour gateway, Avahi reflector, or repeater). The router reads the mDNS announcement on one VLAN and re-emits it on the others where it’s allowed. UniFi calls this the “mDNS Reflector” or “Bonjour Gateway” depending on firmware. On UDM Pro, you enable it under network > settings > advanced; on third-party gear it’s usually a checkbox or a short config line.
Even with reflection on, you still need firewall rules that allow established sessions to flow back to the IoT VLAN once a phone has discovered the speaker. Reflection is discovery only. Actual streaming traffic is unicast and needs the firewall to allow it. A common setup is “Main can initiate to IoT, IoT cannot initiate to Main” with established/related allowed both ways. That’s the rule pattern that keeps phones in control while still letting them control the speakers.
2. IGMP snooping is on but no querier is configured
Same root cause as the Sonos drops we wrote about earlier, except it shows up in dozens of other places too:
- AirPlay 2 multi-room groups stop staying synced. Speakers individually still play, but starting a multi-room group fails or only picks up some of the speakers.
- Chromecast targets occasionally vanish from the Google Home app and reappear after a phone reboot.
- HomeKit accessories show up under “recently added” but never make it onto the main grid.
- Network printers stop appearing in the macOS AirPrint picker even though the printer’s IP works fine if you type it in.
The fix is to either turn IGMP snooping off (fine on small networks, less efficient on big ones), or turn it on and configure an IGMP querier on the same VLAN where the multicast clients live. UniFi controllers will let you enable a querier on a per-network basis. On most home installs we just use the gateway as the querier and call it done.
3. The 6 GHz / Wi-Fi 7 wrinkle
Wi-Fi 6E and Wi-Fi 7 introduced something subtle: 6 GHz radios use a different multicast handling discipline than the older bands, and some early access-point firmware versions didn’t reflect multicast cleanly between 6 GHz and 5 GHz radios on the same SSID. The symptom on a fresh Wi-Fi 7 install was “HomeKit accessories work in the kitchen where the phone is on 5 GHz, but disappear in the office where the phone joined 6 GHz.” This has been mostly fixed in current firmware, but it’s worth checking if you’re on a recently shipped AP and seeing weird discovery gaps. Our Wi-Fi 7 MLO post touches on related multi-band behavior.
4. Guest network isolation is doing exactly what it’s supposed to do
Guest networks typically enable client isolation by default — every guest device sees only the gateway and not other guests. That’s correct behavior for a hotel-style guest SSID. But if a homeowner puts the kids’ iPads on the “guest” SSID for parental-control reasons, the iPads can no longer see the AppleTV or AirPrint to the printer, because client isolation is dropping the multicast.
The right fix is not to relax guest isolation. The right fix is to give the kids a separate SSID that lives on its own VLAN with deliberate cross-VLAN rules, not a generic “guest” SSID. See our guest Wi-Fi and smart-home isolation post for the architecture pattern.
What about PIM and routed multicast?
You will occasionally see networking forums recommend turning on PIM (Protocol Independent Multicast) at home for “true” cross-subnet multicast. Don’t. PIM is a routed multicast protocol designed for IPTV provider networks, hospitals, and stadiums — environments where you genuinely have multicast streams that need to traverse multiple routed hops. In a single-router home network, PIM is massive overkill, and most home gear that exposes the option implements it incompletely.
For a home, mDNS reflection plus IGMP snooping with a querier is the right tool. We have not yet found a Wasatch Front home where PIM was the correct answer.
How we configure this on a real install
For a typical Holladay or Lehi home with a UniFi stack, three SSIDs (Main, IoT, Guest), and four VLANs (Main, IoT, Cameras, Guest), the multicast config we ship is:
- mDNS reflector enabled between Main and IoT only. Cameras and Guest do not participate — cameras have no business discovering speakers, and Guest is intentionally isolated.
- IGMP snooping on, querier on the gateway for the Main and IoT networks. Off on Guest.
- Firewall: Main → IoT allowed, established back-flow allowed. IoT cannot initiate to Main. This keeps a hijacked smart bulb from rummaging through the laptops, while still letting the phone find and control the bulb.
- Sonos on the IoT VLAN, with reflector enabled. We do not put Sonos on the Main VLAN by default — it has too many cloud chat habits to live with the laptops, and it works fine on IoT once mDNS reflection is set up correctly.
- Printers on the IoT VLAN. Same rationale.
- Apple TVs on Main if they’re used for screen mirroring, on IoT if they’re just streaming. Most clients want them on Main so that AirPlay mirroring from the laptop works without having to think about cross-VLAN discovery.
Diagnostics: what to check when discovery breaks
When a homeowner says “HomeKit / AirPlay / AirPrint stopped working,” this is the order:
- Are the client and the target on the same VLAN? If yes, this is an IGMP/snooping problem. If no, it’s an mDNS reflection / firewall problem.
- On the client’s VLAN, is there an IGMP querier? Check the gateway config. The querier needs to live on the VLAN where the consumers are, not just the producers.
- On the gateway, is mDNS reflection enabled between the relevant VLANs? In UniFi, this is network-pair level, not global.
- Is the firewall allowing established/related sessions back from the IoT side? If reflection works (the phone sees the device) but streaming/control fails, this is the missing piece.
- Is client isolation enabled on either the client SSID or the target SSID? It will silently drop multicast even if everything else is configured correctly.
If you’re comfortable with a packet capture, tcpdump on port 5353 (mDNS) and on the multicast groups will show you exactly which side is talking and which is silent. We use this on harder calls. For most jobs, the four-step config above resolves the symptom inside an hour.
Why this matters more than it used to
Five years ago, a managed home network was rare. Most of the protocols we’re talking about here lived on a single flat /24 and never had to cross a VLAN boundary. As enterprise-grade gear — UniFi, Aruba, Omada — has become normal in homes across Lehi, Draper, Holladay, and Park City, the multicast question has gone from niche to constant. Homeowners aren’t asking for it by name. They’re asking why their AirPlay disappeared after the installer “cleaned up” the network.
The answer is: the cleanup was correct. The discovery glue that lets phones, speakers, lights, and printers find each other is what wasn’t configured. That’s the part that should ship with every managed-home install — alongside the VLAN segmentation and the managed switch that made it possible in the first place.
Bottom line
Multicast is the protocol layer that lets “just works” smart-home gear actually just work. mDNS handles discovery, IGMP snooping handles efficient delivery, and a properly configured network reflects discovery across VLANs while keeping the firewall strict. Get those three things right and AirPlay, HomeKit, AirPrint, and Chromecast all behave the way they did on the flat ISP router — while you still get the security and isolation benefits of a real network. Get them wrong and every smart-home feature you bought silently stops working.
If you’ve recently moved to a managed network and your discovery features broke, the cause is almost always one of the four scenarios above. It’s a config gap, not a hardware problem.
Keystone Integration designs and configures multicast-aware home networks across Holladay, Draper, Lehi, Park City, and the rest of the Wasatch Front — with VLAN segmentation, mDNS reflection, and discovery rules that let AirPlay, HomeKit, and Sonos behave the way they should. See the full service list or get in touch for a network review if discovery has stopped working since your last upgrade.