Cross-VLAN multicast needs three mechanisms working together: IGMP snooping inside each VLAN, proxy forwarding (or full multicast routing) to cross subnets, and a multicast VLAN so the uplink carries one copy of every stream instead of one copy per VLAN. Inside a single VLAN a switch can manage with snooping alone: it listens for client reports, binds each multicast group to the ports that asked for it, and forwards only there. Without snooping, multicast frames are treated as broadcast and flooded everywhere. The moment the stream has to leave its VLAN, none of that carries over — and that is where most "the config looks green but the video is black" projects stall.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
IGMP snooping only works inside one broadcast domain; crossing VLANs needs proxying or Layer 3 multicast routing.
An MVR multicast VLAN lets several user VLANs share one upstream copy of each stream — 32 x 25 Mbps cameras drop from 1.1 Gbps to 800 Mbps on the uplink.
Fast Leave shortens group cleanup from up to 260 s to instant, but only enable it on ports that serve a single client.
Crossing a VLAN boundary raises three separate problems, and each one needs its own fix:
Nobody is sending queries. IGMP depends on a querier that sends periodic Query messages so clients respond with reports. Layer 2 switches do not query by default; if no Layer 3 device or designated querier exists, the snooping table ages out and multicast stops. The classic industrial case: the upstream router has multicast disabled, and every group entry on the access switch silently expires.
The stream cannot cross subnets. Snooping only operates inside one broadcast domain. A client joining a group in VLAN 10 tells VLAN 20 nothing. Crossing subnets requires Layer 3 multicast routing — or proxying on the switch itself.
The uplink gets charged once per VLAN. A Layer 3 interface pushes the same stream into each subscribing VLAN separately, so each VLAN consumes its own share of uplink bandwidth. The more VLANs subscribe, the worse it gets. That is exactly what a multicast VLAN (MVR) exists to fix.
Pick the wrong mechanism for the problem at hand and you get exactly the "config all green, service down" outcome.
| Version | Standard | Join / leave behaviour | What it means for the switch |
|---|---|---|---|
| IGMPv1 | RFC 1112 | Report only; leaving is implicit | No Leave message; members exit by timeout, so reclamation is slow |
| IGMPv2 | RFC 2236 | Adds Leave and querier election | Enables fast leave (igmp fast leave); ports reclaim promptly |
| IGMPv3 | RFC 3376 | Adds source filtering (SSM), reports carry source lists | No report suppression; more packets, higher CPU demand |
Version mismatch is the most common fault source here. If the upstream runs v3 and the access switch only understands v2, clients report in v3 format and the switch may fail to parse the source-filtering fields — some channels work, others never arrive. Plan one version across the chain, or explicitly make the Layer 3 device do the translation.
Note: v1 and v2 suppress duplicate reports — on a segment, only one client answers each query, so the switch sees fewer members than actually exist. Bandwidth estimates built from report counts run low. v3 dropped suppression, so tables are accurate but query traffic is heavier.
An igmp proxy solves the case where the switch cannot run a multicast routing protocol itself but still has to forward across subnets. The switch plays two roles at once:
Upstream (router port): it acts as a host, sending reports to the Layer 3 device to join multicast groups.
Downstream (member ports): it acts as the querier, sending queries to clients and maintaining the membership table.
The direct benefit is that PIM-SM or PIM-DM never needs to be configured — a poor trade in industrial and campus access networks that have a single uplink, where PIM is heavy to configure and harder to troubleshoot. The proxy sends only reports upstream; the data stream is pushed down by the Layer 3 device, and the switch copies it to ports per its membership table.
The costs are equally concrete. First, the design only fits single-uplink topologies — a second uplink creates a second router port and needs extra planning. Second, it joins by group only, with no source-side selection, so strict SSM is out of reach. Third, if the upstream device also runs a querier, two queriers in one VLAN will shake the membership table; set the access switch's proxy querier priority lower so the Layer 3 device keeps the role.
MVR puts the multicast streams into a dedicated multicast VLAN and copies them out on the access switch according to each receiver VLAN's membership — an IPTV VLAN plan with separate user VLANs for staff, workshop and guests is the typical beneficiary. Upstream pushes exactly one copy, saving both uplink bandwidth and Layer 3 forwarding capacity. Two terms anchor the configuration:
Multicast VLAN: the dedicated VLAN that carries the multicast data, used internally and on the uplink only.
Receiver VLAN: the VLANs where real users live; the switch replicates the stream from the multicast VLAN into their member ports.
Replication happens as close to the terminals as possible, which is what saves the most upstream. MVR and IGMP snooping are partners, not alternatives: snooping decides which ports want the stream, MVR decides which VLAN it arrives in.
Know the boundary too. MVR applies on the access side only — every trunk between core and access must carry the multicast VLAN tags. If anything in the path does QinQ or strips tags, multicast breaks. Some implementations also restrict MVR to a single layer; crossing multiple switch tiers means configuring it hop by hop.
Scenario: a campus surveillance network, 32 4K cameras at 25 Mbps each (H.265 main stream with audio and container overhead), three user VLANs — VLAN 10 (security centre, all 32), VLAN 20 (workshop, 8), VLAN 30 (office, 4).
Step 1 — single-stream uplink demand. 32 x 25 Mbps = 800 Mbps. A gigabit uplink offers roughly 940 Mbps after Ethernet overhead, so one copy already sits at 85% of the port.
Step 2 — per-VLAN replication, no MVR. The Layer 3 device pushes each stream into VLAN 10, 20 and 30 separately. Intra-VLAN copying is free, but the uplink carries three copies:
| VLAN | Streams | Uplink load |
|---|---|---|
| VLAN 10 | 32 | 800 Mbps |
| VLAN 20 | 8 | 200 Mbps |
| VLAN 30 | 4 | 100 Mbps |
| Total | 1.1 Gbps |
1.1 Gbps exceeds gigabit line rate. Something must drop — and it shows up as every feed stuttering at once.
Step 3 — with a multicast VLAN. The upstream pushes one 800 Mbps copy into multicast VLAN 1000 and the access switch replicates per receiver VLAN:
Uplink: 800 Mbps — 300 Mbps saved, a 27% cut.
VLAN 10 egress: 800 Mbps (all 32; still bounded by the port).
VLAN 20 egress: 200 Mbps. VLAN 30 egress: 100 Mbps.
Step 4 — port-side limits. A security-centre terminal on a gigabit port facing 800 Mbps is near the ceiling. Decoders realistically show 8-16 streams at once; hand full 32-stream recording to the NVR. 16 x 25 = 400 Mbps is 43% of the port, which leaves real headroom.
Step 5 — timers and fast leave. Under IGMPv2 (RFC 2236) defaults the querier sends a general query every 125 s and group membership times out around 260 s — a departed viewer's slot lingers for minutes. Enabling igmp fast leave deletes the port entry the moment a Leave arrives. The catch: on a link shared by several clients, one departure cuts the stream for everyone behind it, so enable fast leave only on single-client ports.
| Symptom | Likely cause | How to confirm |
|---|---|---|
| No channel ever arrives | Multicast disabled upstream, or no querier | Check for group entries on the access switch |
| Missing in some VLANs only | Multicast VLAN not allowed on a trunk | Review each trunk's allowed-VLAN list |
| Picture continues after the client leaves | No fast leave; waiting for timeout | Check the group ageing timer against 260 s |
| Uplink near line rate, all feeds stutter | No MVR; per-VLAN replication | Compare uplink throughput with stream count x bit rate |
| Service drops every ~4 minutes | Missing querier; tables expire | Capture IGMP Query packets; confirm periodic queries |
| Frames appear on unrelated ports | Snooping off or flood fallback active | Check port membership and unknown-multicast policy |
That last row deserves a note. Most switches flood unknown multicast as broadcast while the snooping table is still empty — a short flood window on every new group. Dozens of video streams inside that window can congest the uplink. Set an unknown-multicast drop policy and make sure the querier is alive so the empty window stays short.
Rayin's 8+4-port gigabit industrial switches (PoE optional) handle VLANs, IGMP snooping and multicast forwarding with the same configuration model as campus gear; see the industrial switch solution page for ports and uplinks. Where the design mixes "OLT + ONU + switch", the way multicast maps across the PON side is covered on the PON access solution page.
Fix the order: plan VLAN and multicast VLAN numbers first, then enable snooping and the querier, then configure the proxy or MVR, and only then enable fast leave per port. The snippet below is generic syntax to show the sequence — real commands differ per platform:
; generic example: multicast VLAN + snooping, minimal order vlan 10,20,30,1000 igmp snooping enable igmp snooping vlan 10 querier enable igmp snooping vlan 1000 multicast-vlan mapper 10,20,30 interface gi0/1 switchport trunk allowed vlan 10,20,30,1000 interface gi0/5 igmp snooping fast-leave enable
| Parameter | Common value | Where to adjust |
|---|---|---|
| General query interval | 125 s (RFC 2236 default) | Shorter finds members faster at the cost of more packets |
| Group timeout (robustness 2) | 260 s | Moves in step with the query interval |
| Multicast VLAN ID | Avoid service and voice VLANs | Plan it centrally; never ship the default |
| Fast leave | Per port | On for single-client ports, off for shared links |
| Unknown multicast | Drop | Mandatory when uplink bandwidth is tight |
I only enabled IGMP snooping. Why can VLAN 20 not receive the stream that VLAN 10 joined? Snooping works inside a single broadcast domain: it builds port entries only in the VLAN where the report arrived. Crossing VLANs needs proxying or Layer 3 multicast routing (such as PIM-SM) to bring the stream into the target subnet. Snooping then distributes it per port inside that subnet — it never bridges groups between VLANs by itself.
Why do industrial networks rarely run PIM? PIM needs Layer 3 forwarding capability on the device, plus RP, BSR and neighbour configuration — expensive to set up and to troubleshoot. Industrial networks are usually single-uplink trees, and proxy forwarding already covers "one upstream copy, distribute downstream on demand". PIM earns its keep only with multiple uplinks, multiple sources, or true source filtering (SSM).
If a multicast VLAN saves bandwidth, why not use it on every project? Because it adds a configuration layer: numbering the multicast VLAN, keeping trunks open end to end, configuring MVR tier by tier, and one more mapping to check during faults. It pays off when one stream — an IPTV VLAN tier, a camera group, a plant-wide information feed — must reach several VLANs over a tight uplink. With a single viewing VLAN the gain is close to zero and the maintenance cost is real.
Can the switch itself send queries if the upstream has no querier? Yes — most managed switches can run a querier on a chosen VLAN. Keep exactly one querier per VLAN: two devices querying at once cause membership-table oscillation and doubled reports. Prefer making the Layer 3 device the querier and leaving the access switch passive; in a pure Layer 2 network without one, enable the nearest switch's querier and align versions across devices.
4K cameras switched to multicast still stutter — what do I check first? Check port bandwidth before touching multicast configuration. One 25 Mbps stream x 32 is 800 Mbps — 85% of a gigabit port — and container overhead plus retransmissions push it over the edge. Confirm how many streams each decoder shows simultaneously, then look at the uplink traffic curve, and only then inspect multicast group entries and querier status.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
