Bonjour Across VLANs and a Multicast Video Stream That Melts Airtime

Why the current behavior is exactly what the design predicts

• mDNS snooping makes the controller cache service advertisements that arrive from wireless clients. It does not magically learn services that live on the wired network, and it does not bridge multicast between VLANs on its own.
• A printer on the same wired VLAN as a student client is reachable because that mDNS query and response are ordinary L2 multicast in the same subnet; the controller is not involved. That is why "same VLAN works".
• Printers and displays on other VLANs are invisible because nothing translates the query into those subnets.

What to configure

1. Global mDNS gateway enabled (snooping mode set to the gateway, not just snooping), with an mDNS service policy that contains the actual service types you need: _ipp._tcp, _ipps._tcp, _airplay._tcp, _raop._tcp, _googlecast._tcp, _airport._tcp. Only listed services are cached and relayed; anything else is dropped.
2. Attach that service policy to the student WLAN profile. Snooping must be enabled at the WLAN level as well as globally, and the WLAN must be in the same service domain as the services it needs to see.
3. For devices that live on the wired AV VLAN, the gateway must know about them. Confirm in your release how static/master service advertisement is configured and add the AV service there, or place the displays on a WLAN served by the same controller so snooping can learn them. Verify with a packet capture on the service interface.
4. Keep the service list small and identical on both controllers. A wide-open policy on 780 APs and thousands of clients is a CPU and scale problem, not just a security one.

Validation Clear the cache, associate a test client on the student VLAN, and confirm the query is answered by the gateway with a unicast response containing the service's A record and port. Then test the actual print or mirror operation, because discovery succeeding while the data connection fails is a different problem (usually an ACL on the destination VLAN).

The airtime math

• By default the controller replicates multicast to every AP and transmits at the lowest mandatory data rate of the BSS. If that is 6 Mbps, a 20 Mbps video stream cannot be carried: the AP would need several times the available airtime. What you see as stuttering is the AP transmitting far below the stream rate and dropping or delaying frames.
• Every client on the BSS must stay awake for multicast, so clients also burn receive time; with no IGMP snooping on the wired side, the stream is flooded to every switch port in the VLAN as well, multiplying the problem before it ever reaches the AP.

Changes, in order

1. Enable IGMP snooping on the distribution and access switches so multicast is only forwarded to ports with interested listeners. Verify the snooping querier is configured on the L3 gateway for the VLAN.
2. Set the 5 GHz multicast data rate explicitly to a realistic value (for example 24 Mbps) instead of inheriting the lowest mandatory rate, and remove 6, 9 and 12 Mbps from mandatory while keeping them supported. This reduces airtime per multicast frame substantially.
3. Enable multicast-direct if the client population supports it. With multicast-direct the AP sends the stream to a specific client at that client's rate rather than at the multicast rate, which converts the problem into unicast airtime and removes the 25-client cliff. It requires client and AP support and is intended for video; do not enable it campus-wide without testing older clients.
4. Cap the number of simultaneous video sessions per AP through call admission control for video, so the 26th client is refused rather than degrading all 25.
5. Consider moving the lecture stream to a dedicated AV SSID on a small number of APs in the lecture halls, so the load is contained.

Verify Post-change, compare per-radio channel utilization, multicast frame counts, and retries, and confirm the wired ports no longer see the stream where nobody joined.

Why it breaks

• mDNS snooping builds its cache on the controller that processed the advertisement. The cache is a local resource and is not shared to mobility peers, so a client whose session is now anchored on controller B cannot query the cache on controller A, even though both controllers are in the same mobility group and both have snooping enabled.
• After L3 roaming the client's traffic egresses at the new controller while its session anchor stays where it associated; the mDNS query now reaches a controller whose cache never saw the printer.

Design options

1. Re-advertise from the source. For services that live on the wired network, use the gateway's static/master service entries on every controller so each one can answer for the service without having learned it from a client. This is the most robust fix for printers and displays, because the service set is known and small.
2. Centralize the student WLAN. Terminate student sessions on a single controller (or on controllers where the service domain is identical) so the snooping cache is one cache. Coupled with L3 roaming, session anchoring keeps the client's data path coherent with the cache.
3. Keep the service on the wireless side. Place displays and printers on a WLAN served by the same controller set and in the same service domain, so any controller can learn the advertisement through snooping.
4. Reduce the reliance on mDNS for the critical service. For printing, publish a DNS-based or direct-IP print queue, which is immune to cache locality.

What to verify

• Same service policy and same service list on both controllers, and the same service domain.
• After a roam, capture on the client to confirm whether the query was answered by a local cache or never answered at all; that distinguishes a cache-miss from a policy miss.
• Clear the cache and repeat after roaming; a cache that repopulates only on one controller confirms the locality problem.