There is a moment, on almost every “upgrade from a consumer router to a real network” job, when half the house’s smart devices stop seeing each other. The AirPlay speakers are gone from the iPhone. The Chromecast doesn’t show up in YouTube. HomeKit accessories sit there with a little “no response” tag. The HP printer that worked yesterday is now invisible to every laptop in the house. Reboot the laptop — still gone. Reboot the printer — still gone. Reboot the access points — everything blinks back, and an hour later it’s gone again.
What changed isn’t the devices. What changed is the network underneath, and specifically how it handles multicast. AirPlay, Chromecast, HomeKit, Bonjour printers, Sonos, and almost every other “just works” consumer protocol depend on multicast for discovery. Once you put VLANs and a managed switch between them, you have to make some explicit decisions about how multicast moves around the house, or it doesn’t move at all.
Here is what multicast actually is, where it breaks on a home network, and the four or five settings that decide whether your “smart” devices see each other.
Multicast in one paragraph
Most network traffic is unicast: one device talking to one other device, addressed by IP. Multicast is one device talking to a group of other devices at the same time, addressed by a group IP that lives in a special range (224.0.0.0–239.255.255.255 in IPv4). Devices that want to participate “join” the group; the network is responsible for delivering the packets to everyone who joined and nobody who didn’t. It’s how AirPlay says “I exist, who else is here?” and how a Sonos group stays sub-millisecond synchronized between speakers in different rooms.
Two specific multicast protocols matter for home networks:
- mDNS / Bonjour — the discovery layer for AirPlay, HomeKit, AirPrint, Chromecast (partially), and most network printers. Uses multicast group 224.0.0.251 on UDP port 5353. Devices announce themselves on a tiny broadcast schedule and listen for queries from clients.
- SSDP — the discovery layer for DLNA, UPnP, some smart-TV apps, and older media-server protocols. Uses multicast group 239.255.255.250 on UDP 1900.
Both have one thing in common: they were designed for a flat network with one VLAN, one subnet, one broadcast domain. The minute you build a real home network with separate VLANs for IoT, guests, and trusted devices, those announcements don’t cross the boundary on their own. That’s when things break.
Why multicast breaks when you upgrade your network
A consumer router puts every device on the same flat /24 network. The TV, the phone, the printer, and the Hue bridge are all neighbors. Multicast packets sent by any of them are heard by all of them. Discovery just works.
A managed network introduces two complications. First, VLANs intentionally separate devices into broadcast domains so a compromised IoT device can’t talk to your laptop. Multicast doesn’t cross VLAN boundaries unless you tell it to. Second, IGMP snooping on the switch tries to be efficient about multicast inside a VLAN by only forwarding it to ports that asked for it. If you turn it on without configuring a querier, the switch slowly forgets who’s in each group and starts dropping multicast traffic that should be flowing.
Both of those features exist for good reasons. Both of them, when turned on without thought, quietly break consumer-grade smart-home discovery. If you’ve already read our Sonos drops post or our VLANs explainer, you’ve seen the symptoms. This post is the broader picture: AirPlay, Chromecast, HomeKit, printers, and everything else multicast-dependent.
mDNS reflection: the setting that fixes most of it
If your network has VLANs and you want devices on one VLAN to discover devices on another, you need mDNS reflection (sometimes called the “mDNS repeater” or “Bonjour gateway”). It’s a service running on the gateway that listens for mDNS announcements on each VLAN and re-broadcasts them onto the others you’ve allowed.
In UniFi, this lives in Settings → Networks → [VLAN] → Advanced → Multicast DNS, and you enable it on each VLAN that needs to participate. In OPNsense and pfSense it’s the Avahi or mDNSResponder package. On Firewalla and most consumer firewalls with a “pro” mode, it’s a single toggle. The detail that matters is which direction reflection runs.
- Phones (trusted VLAN) need to discover speakers (IoT VLAN). So mDNS has to reflect from IoT into trusted.
- The printer (IoT VLAN) needs to be discoverable from laptops (trusted VLAN). Same direction.
- Guest devices should usually NOT see your AirPlay speakers. Don’t reflect from IoT to guest. The whole point of a guest VLAN is that it’s isolated.
That asymmetry is the trick. Reflection should be a deliberate choice per VLAN pair, not a global “turn it on everywhere.” If you set it up so guest can see your HomeKit, the value of splitting them in the first place evaporates. We walk through this in our guest-Wi-Fi isolation post.
IGMP snooping and the querier
Inside a single VLAN, multicast still has to be forwarded efficiently. A switch can flood every multicast packet to every port on the VLAN (simple, works, slightly wasteful) or it can be clever and only forward each group to ports that joined the group. The clever version is IGMP snooping.
IGMP snooping needs an IGMP querier — a device that periodically asks “who’s in what group?” so the switch can keep the table fresh. On most home networks, the gateway is the querier. On UniFi, the option is on the VLAN settings page right next to mDNS. If snooping is on but no querier is running, the table ages out, the switch stops forwarding the multicast, and Sonos / AirPlay / HomeKit start dropping out for no apparent reason.
For a typical home, the right answer is one of two configurations:
- Snooping off, querier off. Multicast floods the VLAN. On a 1 Gbps home network with a few dozen devices, the overhead is unmeasurable. Sonos, AirPlay, and HomeKit stay rock-solid.
- Snooping on, querier on. Cleaner traffic, but only worth doing if you actually have hundreds of devices or you’re on a slow uplink that benefits from the bandwidth savings. Both have to be on, and on the same VLAN, or it doesn’t work.
The trap is the third configuration: snooping on, querier off. That’s the default behavior of a fresh UniFi managed switch with the option checked and no other configuration. It works for a week. Then it doesn’t.
When PIM and routed multicast actually matter
For 99% of homes, mDNS reflection plus a sensible IGMP setup is the whole answer. The fancy multicast routing protocols — PIM Sparse Mode, IGMPv3, MSDP — are useful in multi-subnet enterprise networks where multicast has to traverse routers, not just switches.
The home cases where you might actually need routed multicast: large estates with multiple buildings on different subnets that share an AV-over-IP video distribution system, or whole- home audio platforms like Just Add Power that rely on inter-subnet multicast. Those are custom-AV jobs, not typical residential. If you’re scoping that kind of system, the AV-over-IP vendor will give you an explicit list of multicast settings the network needs to provide. Hand it to your network installer and make sure they understand what each one does.
The protocols that break first, in order
AirPlay 2
AirPlay 2 is the canary. It’s the first protocol that breaks when mDNS reflection is missing or broken, and it’s the first one homeowners notice because they use it every day. Symptoms: speakers don’t appear in the phone’s Control Center, or they appear and then stream cuts out after 30 seconds. The fix is reflection between the phone’s VLAN and the speaker’s VLAN.
HomeKit
HomeKit accessories are mDNS-discovered just like AirPlay. Once paired, they’re also accessible over the home hub (Apple TV, HomePod, or iPad), but that hub itself is on a VLAN and discovers the accessories via mDNS. If the accessories live on an IoT VLAN and the hub lives on the trusted VLAN, you need reflection between them. The “no response” tag in the Home app is the giveaway. Our smart-home platform comparison covers HomeKit’s networking model in more detail.
Chromecast and Google Cast
Chromecast uses a mix of mDNS and SSDP for discovery. It also expects the casting device (phone, tablet, laptop) to be able to reach the Chromecast directly on TCP 8008/8009 once discovered. So you need both mDNS reflection and a firewall rule that allows the cross-VLAN TCP traffic. Phones-can-cast-to-living-room-TV is one of the most common test cases on a residential handoff.
Bonjour printers (AirPrint, IPP)
Network printers advertise via mDNS. They’re stateless from the client’s perspective — if discovery works, printing works. If discovery is broken, the printer is invisible even though it has an IP and would happily accept a job if you typed the IP in manually. Reflection between the printer’s VLAN and the user VLAN solves it.
Sonos
Sonos is its own story; we wrote a full Sonos-drops post because it’s the most common ticket we’ve seen post-network-upgrade. The short version: Sonos uses mDNS for discovery and tighter multicast (its own SSDP and IGMP-heavy sync traffic) for grouping. Reflection plus a clean IGMP setup plus no STP reconvergence.
Smart TVs and streaming sticks
A lot of smart-TV apps use SSDP for “find my Plex server” or “find my Roku.” If you’ve put Plex on a server VLAN and the TV on an IoT VLAN, you need to either reflect SSDP (some firewalls support this, some don’t) or just put both devices on the same VLAN and accept the trade-off.
The rule we follow on residential VLAN designs
Three VLANs is enough for almost every house we build:
- Trusted — phones, laptops, NAS, work computers. Allowed to talk to everything.
- IoT — speakers, TVs, printers, smart-home devices, cameras (in some designs cameras are their own VLAN; we discuss that in the local-NVR post). Allowed to be discovered and reached from trusted; cannot initiate connections to trusted.
- Guest — visitor devices. Internet only. No reflection. No cross-VLAN visibility. Period.
mDNS reflection runs from IoT into trusted, never from IoT into guest, never from guest into anything. IGMP snooping is off on IoT (where Sonos and AirPlay live) unless we have a specific reason to enable it and a working querier. SSDP reflection is on per-protocol if a specific app needs it. The whole config is documented as part of the handoff so the homeowner knows what was touched and why.
How to tell if multicast is your problem
If the symptoms in your house match this list, multicast is almost certainly involved:
- A device works on the same Wi-Fi as the user but not when the user switches to a different SSID/VLAN.
- Discovery works, then mysteriously stops after some hours, then returns when something reboots.
- Two devices that “should see each other” can ping each other by IP but don’t see each other by name.
- The problem appeared right after a network upgrade or a VLAN change, and didn’t exist on the old flat network.
- Wired devices behave the same as wireless devices on the same VLAN. (If the problem is wireless-only, look at band steering and fast-roaming first — that’s a different rabbit hole.)
The settings checklist
When we hand a network off to a homeowner and we want AirPlay, HomeKit, AirPrint, Chromecast, and Sonos to all behave, this is the configuration we set:
- mDNS reflection enabled between trusted and IoT VLANs, both directions.
- mDNS reflection disabled to/from the guest VLAN.
- IGMP snooping off on the IoT VLAN. (If on, querier on, on the same VLAN, on the gateway.)
- Firewall rules permit cross-VLAN traffic on the specific TCP/UDP ports each protocol needs after discovery (AirPlay 7000/49152– 65535, HomeKit 5353/random, AirPrint 631/9100, Chromecast 8008–8009).
- SSDP reflection only enabled if a specific app demands it. Default off.
- STP set to RSTP and edge ports configured on AP and IoT-device ports, so a topology reconvergence doesn’t kill multicast for five seconds in the middle of the night.
Bottom line
Multicast is the invisible plumbing that makes consumer smart-home gear feel magical. On a consumer flat network it just works. On a managed home network with VLANs, it requires three or four explicit settings — mDNS reflection per pair of VLANs, IGMP snooping with a working querier or off entirely, RSTP on the switch, sensible firewall rules — or the house feels worse than it did before the upgrade. The good news: once the settings are right, they stay right, and the network is strictly better than the consumer one in every other way.
Keystone Integration designs and tunes managed home networks across Holladay, Park City, Cottonwood Heights, Lehi, and the rest of the Wasatch Front — with multicast, mDNS, and VLANs configured so AirPlay, HomeKit, printers, and Sonos all behave the way they did on your old router, only on a network that’s actually secure. See the full service list or get in touch if your smart-home discovery has stopped working since you upgraded.