IPTV that stutters and CCTV feeds that turn to mosaic are usually the same failure wearing two different faces — a multicast join that never completes, a forwarding table that's missing an entry, or traffic bursts that blow past what the egress port can buffer. This is the check order that finds which one it is fastest — the exact display commands for IGMP, Layer 2 and Layer 3 multicast tables, and the causes that account for most of these tickets in the field.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Whether it's a set-top box stuttering or a CCTV feed dissolving into blocks, the underlying question is the same: is the multicast stream actually reaching this port, and reaching it fast enough.
IPTV freezing and CCTV video mosaic get reported as if they were different problems — one's a set-top box complaint, the other's a security-monitoring complaint — but underneath, multicast video has exactly two ways to fail: the stream never gets forwarded to the port at all, or it gets forwarded but arrives late, incomplete, or dropped. The first is a join/table problem — IGMP, IGMP Snooping, or PIM never built the path. The second is a capacity problem — the path exists, but something between the source and the screen can't keep up with it for a moment.
What follows is the check order that separates the two: whether the join actually reached the device, whether the Layer 2 and Layer 3 multicast tables actually have the right entries, and only then whether the traffic itself is bursting past what a port can buffer — plus the causes that show up again and again in real CCTV and IPTV deployments, and answers to the questions this generates most.
Freezing and mosaic split into exactly two shapes on this tree: no stream at all, or a stream that's there but degraded.
Placing the symptom here first tells you which of the sections below actually applies — chasing a bandwidth problem when the real fault is a missing IGMP Snooping table entry (or the other way around) wastes a lot of time.
Diagram labels are kept in English for engineering clarity.
A missing forwarding-table entry and a bandwidth/burst problem look identical from the screen — both show up as freezing or mosaic — but they live in completely different places and need completely different fixes. The tree above is what tells them apart before any configuration gets touched.
Three checks, in order — each one is context for the next, and the commands that tell you which one you're actually stuck on.
If multicast routing was never enabled in the first place, unknown multicast traffic is flooded like broadcast — and that alone is enough to cause mosaic.
<Device> display interface 10GE0/0/1
Output: 490255596853 packets, 722496062037058 bytes
Discard: 416538726, Pause: 0
// Discard counter climbing on the output side -> congestion, not a join fault
<Device> display igmp snooping configuration
Info: There is no igmp snooping configuration.
// no multicast table at all -> unknown multicast is flooded exactly like broadcast
#
igmp snooping enable
vlan 10
igmp snooping enable
igmp snooping querier enableMulticast can be enabled everywhere and the join can still not build the entry that gets traffic to this specific port.
<Device> display l2-multicast forwarding-table
VLAN Total (Source,Group) Interface
100 1 (*, 226.0.1.205)
// no outgoing interface toward the PC listed -> entry never reached this port
<Device> display igmp snooping vlan 10
IGMP Version is Set to default 2
// third-party device sends IGMPv3 Query; this device is v2 and can't process it
// -> router-port ages out once the v3 Query goes out, stream cutsThis is where a stream that's provably reaching the right port and the right table entry can still freeze or turn to mosaic.
<Device> display interface 10GE0/0/2
Output: ... Discard: 33021, still increasing
// mirror the source-facing port and check with Wireshark:
// server sleeps ~1s, then bursts near 1Gbit/s for a few ms -- average rate only ~10Mbit/s
[Device] interface 10GE0/0/2
[Device-10GE0/0/2] qos burst-mode enhanced
// enhanced burst mode gives the egress port more buffer for this traffic shapeOnce the three checks above have told you where the problem sits, these five account for most of what's actually wrong in real CCTV and IPTV deployments.
SYMPTOMCamera feed shows mosaic from the moment it's connected — display interface on the port shows a large and climbing Discard counter on the output side.
CAUSEThe customer's network was carrying multicast video, but the access device had no IGMP Snooping configuration at all. With no multicast table to consult, unknown multicast traffic is forwarded exactly like broadcast — flooded to every port in the VLAN — and the resulting congestion drops packets, which shows up on screen as mosaic.
FIXEnable IGMP Snooping globally and under the specific VLAN, and enable the Layer 2 querier function on the switch closest to the multicast source if the VLAN has no other querier.
igmp snooping enable
vlan 10
igmp snooping enable
igmp snooping querier enableSYMPTOMVideo plays normally for a while and then cuts out — unplugging and replugging the user's cable only delays the same failure, it doesn't fix it.
CAUSEA higher IGMP/IGMP Snooping version can process a lower version's protocol packets, but not the other way around. The user's first report builds the forwarding entry correctly on both devices — but once the upstream device's periodic IGMPv3 Query goes out, the lower-version device can't process it, the entry ages out, and the stream stops.
FIXConfigure the same IGMP / IGMP Snooping version on every device in the same multicast domain — when devices are mixed, align all of them to the same version rather than assuming a higher-version device is automatically backward-compatible in both directions.
<Device> display igmp snooping vlan 10
IGMP Version is Set to default 2
[Device-vlan10] igmp snooping version 3SYMPTOMMosaic appears specifically during business peak hours, and display interface on the user-facing port shows a Discard counter that keeps climbing.
CAUSESome multicast source encoders use variable bit-rate (VBR) encoding and send data in short, extremely high-rate bursts rather than a steady stream — a real field case measured the source sleeping for just over a second, then sending at close to 1Gbit/s for a few milliseconds before sleeping again, even though the average rate over time was only around 10Mbit/s. The device's egress buffer, sized around the average, can't absorb a burst that size, and the overflow gets dropped.
FIXWhere the source supports it, switch it from VBR to constant bit-rate (CBR) encoding to smooth the send pattern; otherwise increase the egress port's bandwidth (an Eth-Trunk, or a higher-speed port), or configure an enhanced burst mode on the port to give it more buffer for exactly this kind of traffic.
[Device] interface 10GE0/0/2
[Device-10GE0/0/2] qos burst-mode enhancedSYMPTOMRandom, scattered packet loss appears across many different multicast groups roughly two minutes after the stream starts, rather than a clean failure on one group.
CAUSEMore than one IGMP querier existed on the same user segment, and their query intervals didn't match — a query interval longer than the switch's own default aging time leaves only a few seconds in each cycle to refresh a large number of multicast entries, and the device can't process the refresh fast enough, so entries get aged out and rebuilt, showing up as scattered drops across multiple groups.
FIXDisable the redundant querier — there should be exactly one IGMP querier active on a given Layer 2 segment — and if the interval has to be customized, set it consistently across every device on the segment, not just the one closest to the source.
<Device> display igmp interface
// querier elected on a device other than expected -- check its query-interval, disable the duplicateSYMPTOMPlayback stutters heavily through an aggregation device with many downstream devices in one VLAN, but the same content plays cleanly when the user's terminal is connected directly to the source-side device.
CAUSEWith a large number of devices fanned out under one aggregation switch on the same VLAN, broadcast traffic floods every port in that VLAN and can consume enough bandwidth on its own to starve the multicast stream sharing the link, even though the multicast forwarding path itself is working correctly.
FIXConfigure port isolation on the aggregation device so downstream ports can no longer flood broadcast traffic to each other, keeping the shared bandwidth available for the multicast stream.
[Device-Ethernet0/0/1] portswitch
[Device-Ethernet0/0/1] port default vlan 204
[Device-Ethernet0/0/1] port-isolate enable group 1Pulled straight from the field — the ones worth having an answer ready for.
IGMP is the protocol a host uses to tell its directly-connected router which multicast group it wants to join — it runs at Layer 3. IGMP Snooping is a Layer 2 switch feature that listens in on those same IGMP messages passing through it, so the switch can build its own forwarding table and send multicast traffic only out the ports that actually have members, instead of flooding it to the whole VLAN. A pure Layer 2 access switch with no Layer 3 multicast interface still needs IGMP Snooping enabled, or unknown multicast is flooded like broadcast.
Check the Layer 2 table first — display igmp snooping router-port and display l2-multicast forwarding-table for the VLAN in question. If the outgoing interface toward the user is missing there, it's a Layer 2 problem regardless of what Layer 3 looks like. If the Layer 2 entry is correct, move up to display pim routing-table and display multicast routing-table — a missing or stalled (S,G) entry there, with the Matched counter not climbing, points to the Layer 3 path instead.
Confirm multicast routing-enable is configured globally, and that pim sm and igmp enable are both configured on the user-facing Layer 3 interface — IGMP alone without PIM on the same interface won't build the table. Then check display igmp snooping router-port on the Layer 2 device between the user and the router — if the router-port isn't there, the join message from the user never actually reached the Layer 3 device in the first place.
That timing points at a burst or bandwidth problem rather than a join/table problem — check display interface for a Discard counter on the affected port that climbs specifically during those hours, and mirror the source-facing port to check for VBR-style traffic bursts. A join/table fault (missing IGMP Snooping entry, version mismatch) usually shows up consistently, not just during specific hours.
It often masks the symptom for a while, but it doesn't answer why the burst or the flooding happened in the first place, and it tends to come back once traffic grows again. Confirming the actual mechanism — VBR bursts, a missing IGMP Snooping entry, a duplicate querier, or broadcast flooding sharing the VLAN — takes roughly the same handful of display commands either way, and it's the only way to know whether more bandwidth will actually fix it or just buy a few months.
This note is built around the Huawei AR-series router and switch multicast troubleshooting model and its display igmp snooping / pim routing-table / multicast routing-table commands, plus the field cases behind them — several of them from real CCTV and IPTV deployments. If your access or aggregation gear is a different vendor, the exact commands change, but the underlying check order — join, table, capacity — carries over directly. It doesn't cover SSM-specific mapping edge cases or multicast over MPLS/VPN overlays in depth.
Tell us whether it's IPTV or CCTV, whether the symptom is constant or peak-hours-only, plus the display igmp snooping / pim routing-table output, and we'll help you read it.