Um IPTV que trava e um feed de CFTV que vira mosaico costumam ser a mesma falha com duas caras diferentes — uma associação multicast que nunca se completa, uma tabela de encaminhamento à qual falta uma entrada, ou rajadas de tráfego que ultrapassam o que a porta de saída consegue armazenar em buffer. Esta é a ordem de verificação que encontra mais rápido qual dos dois é — os comandos display exatos para IGMP, as tabelas multicast de camada 2 e 3, e as causas que respondem pela maioria desses chamados em campo.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Seja um decodificador que trava ou um feed de CFTV que se dissolve em blocos, a pergunta de fundo é a mesma: o fluxo multicast realmente chega a essa porta, e chega rápido o suficiente.
O congelamento de IPTV e o mosaico de vídeo de CFTV são reportados como se fossem problemas diferentes — um é reclamação de decodificador, o outro é reclamação de monitoramento de segurança — mas, no fundo, o vídeo multicast só pode falhar de duas formas: o fluxo nunca é encaminhado à porta, ou é encaminhado mas chega atrasado, incompleto ou descartado. A primeira é um problema de associação/tabela — IGMP, IGMP Snooping ou PIM nunca construíram o caminho. A segunda é um problema de capacidade — o caminho existe, mas algo entre a fonte e a tela não consegue acompanhar por um instante.
A seguir está a ordem de verificação que separa os dois casos: se a associação realmente chegou ao dispositivo, se as tabelas multicast de camada 2 e 3 realmente têm as entradas corretas, e só então se o próprio tráfego está em rajadas que ultrapassam o que uma porta consegue armazenar em buffer — além das causas que aparecem repetidamente em implantações reais de CFTV e IPTV, e as respostas às perguntas que isso mais gera.
O congelamento e o mosaico se dividem em exatamente duas formas nesta árvore: nenhum fluxo, ou um fluxo presente mas degradado.
Colocar primeiro o sintoma aqui indica qual das seções abaixo realmente se aplica — perseguir um problema de largura de banda quando a falha real é uma entrada de tabela IGMP Snooping ausente (ou o contrário) desperdiça muito tempo.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Uma entrada de tabela de encaminhamento ausente e um problema de largura de banda/rajada parecem idênticos na tela — ambos aparecem como congelamento ou mosaico — mas estão em lugares completamente diferentes e precisam de correções completamente diferentes. A árvore acima é o que os distingue antes de mexer em qualquer configuração.
Três verificações, em ordem — cada uma é contexto para a seguinte, e os comandos que indicam em qual você está realmente travado.
Se o roteamento multicast nunca foi habilitado, o tráfego multicast desconhecido é inundado como broadcast — e isso sozinho já basta para causar mosaico.
<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 enableO multicast pode estar habilitado em todos os lugares e a associação ainda assim não construir a entrada que leva o tráfego a essa porta específica.
<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 cutsÉ aqui que um fluxo comprovadamente chegando à porta certa e à entrada de tabela certa ainda assim pode congelar ou virar mosaico.
<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 shapeDepois de realizadas as três verificações acima, essas cinco causas respondem pela maior parte do que realmente está errado em implantações reais de CFTV e IPTV.
SINTOMAO feed da câmera mostra mosaico desde o momento em que é conectado — display interface na porta mostra um contador Discard grande e crescente no lado de saída.
CAUSAA rede do cliente carregava vídeo multicast, mas o dispositivo de acesso não tinha nenhuma configuração de IGMP Snooping. Sem uma tabela multicast para consultar, o tráfego multicast desconhecido é encaminhado exatamente como broadcast — inundado para todas as portas da VLAN — e o congestionamento resultante descarta pacotes, o que aparece na tela como mosaico.
CORREÇÃOHabilite o IGMP Snooping globalmente e na VLAN específica, e habilite a função de consultante de camada 2 no switch mais próximo da fonte multicast se a VLAN não tiver outro consultante.
igmp snooping enable
vlan 10
igmp snooping enable
igmp snooping querier enableSINTOMAO vídeo reproduz normalmente por um tempo e depois corta — desconectar e reconectar o cabo do usuário apenas atrasa a mesma falha, não a corrige.
CAUSAUma versão superior de IGMP/IGMP Snooping pode processar os pacotes de protocolo de uma versão inferior, mas não o contrário. O primeiro relatório do usuário constrói corretamente a entrada de encaminhamento em ambos os dispositivos — mas assim que a Consulta IGMPv3 periódica do dispositivo a montante é emitida, o dispositivo de versão inferior não consegue processá-la, a entrada envelhece, e o fluxo para.
CORREÇÃOConfigure a mesma versão de IGMP / IGMP Snooping em todos os dispositivos do mesmo domínio multicast — quando os dispositivos estão misturados, alinhe todos à mesma versão em vez de supor que um dispositivo de versão superior é automaticamente retrocompatível em ambas as direções.
<Device> display igmp snooping vlan 10
IGMP Version is Set to default 2
[Device-vlan10] igmp snooping version 3SINTOMAO mosaico aparece especificamente nos horários de pico do negócio, e display interface na porta voltada ao usuário mostra um contador Discard que continua subindo.
CAUSAAlguns codificadores de fonte multicast usam codificação de taxa de bits variável (VBR) e enviam dados em rajadas curtas e extremamente rápidas em vez de um fluxo constante — um caso real de campo mediu a fonte descansando por pouco mais de um segundo, depois enviando perto de 1Gbit/s por alguns milissegundos antes de descansar novamente, embora a taxa média ao longo do tempo fosse de apenas cerca de 10Mbit/s. O buffer de saída do dispositivo, dimensionado em torno da média, não consegue absorver uma rajada desse tamanho, e o excedente é descartado.
CORREÇÃOOnde a fonte suportar, mude-a de VBR para codificação de taxa de bits constante (CBR) para suavizar o padrão de envio; caso contrário, aumente a largura de banda da porta de saída (um Eth-Trunk, ou uma porta de velocidade maior), ou configure um modo de rajada aprimorado na porta para dar mais buffer exatamente para esse tipo de tráfego.
[Device] interface 10GE0/0/2
[Device-10GE0/0/2] qos burst-mode enhancedSINTOMAPerda de pacotes aleatória e dispersa aparece em muitos grupos multicast diferentes cerca de dois minutos depois que o fluxo começa, em vez de uma falha limpa em um único grupo.
CAUSAExistia mais de um consultante IGMP no mesmo segmento de usuário, e seus intervalos de consulta não coincidiam — um intervalo de consulta mais longo que o tempo de envelhecimento padrão do switch deixa apenas alguns segundos em cada ciclo para atualizar um grande número de entradas multicast, e o dispositivo não consegue processar a atualização rápido o suficiente, então as entradas envelhecem e são reconstruídas, aparecendo como perdas dispersas em vários grupos.
CORREÇÃODesative o consultante redundante — deve haver exatamente um consultante IGMP ativo em um determinado segmento de camada 2 — e se o intervalo precisar ser personalizado, defina-o de forma consistente em todos os dispositivos do segmento, não apenas no mais próximo da fonte.
<Device> display igmp interface
// querier elected on a device other than expected -- check its query-interval, disable the duplicateSINTOMAA reprodução trava fortemente através de um dispositivo de agregação com muitos dispositivos a jusante em uma VLAN, mas o mesmo conteúdo reproduz de forma limpa quando o terminal do usuário é conectado diretamente ao dispositivo do lado da fonte.
CAUSACom um grande número de dispositivos ramificados sob um switch de agregação na mesma VLAN, o tráfego broadcast inunda todas as portas dessa VLAN e pode, por si só, consumir largura de banda suficiente para privar o fluxo multicast que compartilha o link, mesmo que o caminho de encaminhamento multicast em si esteja funcionando corretamente.
CORREÇÃOConfigure o isolamento de porta no dispositivo de agregação para que as portas a jusante não possam mais inundar tráfego broadcast entre si, mantendo a largura de banda compartilhada disponível para o fluxo multicast.
[Device-Ethernet0/0/1] portswitch
[Device-Ethernet0/0/1] port default vlan 204
[Device-Ethernet0/0/1] port-isolate enable group 1Tiradas diretamente do campo — aquelas que vale a pena ter uma resposta pronta.
IGMP é o protocolo que um host usa para dizer ao seu roteador diretamente conectado a qual grupo multicast quer se associar — ele funciona na camada 3. IGMP Snooping é um recurso de switch de camada 2 que escuta essas mesmas mensagens IGMP passando por ele, para que o switch possa construir sua própria tabela de encaminhamento e enviar tráfego multicast apenas para as portas que realmente têm membros, em vez de inundá-lo para toda a VLAN. Um switch de acesso puramente de camada 2 sem interface multicast de camada 3 ainda precisa do IGMP Snooping habilitado, ou o multicast desconhecido é inundado como broadcast.
Verifique primeiro a tabela de camada 2 — display igmp snooping router-port e display l2-multicast forwarding-table para a VLAN em questão. Se a interface de saída em direção ao usuário estiver ausente ali, é um problema de camada 2, independentemente de como a camada 3 pareça. Se a entrada de camada 2 estiver correta, suba para display pim routing-table e display multicast routing-table — uma entrada (S,G) ausente ou travada ali, com o contador Matched não subindo, aponta para o caminho de camada 3.
Confirme que multicast routing-enable está configurado globalmente, e que pim sm e igmp enable estão configurados na interface de camada 3 voltada ao usuário — apenas IGMP sem PIM na mesma interface não construirá a tabela. Depois verifique display igmp snooping router-port no dispositivo de camada 2 entre o usuário e o roteador — se o router-port não estiver lá, a mensagem de associação do usuário nunca chegou de fato ao dispositivo de camada 3.
Esse padrão de horário aponta para um problema de rajada ou largura de banda, não um problema de associação/tabela — verifique display interface em busca de um contador Discard na porta afetada que suba especificamente durante essas horas, e espelhe a porta voltada para a fonte para verificar rajadas de tráfego estilo VBR. Uma falha de associação/tabela (entrada IGMP Snooping ausente, incompatibilidade de versão) geralmente aparece de forma constante, não apenas em horários específicos.
Isso muitas vezes mascara o sintoma por um tempo, mas não responde por que a rajada ou a inundação aconteceu em primeiro lugar, e tende a voltar quando o tráfego cresce novamente. Confirmar o mecanismo real — rajadas VBR, uma entrada IGMP Snooping ausente, um consultante duplicado, ou inundação de broadcast compartilhando a VLAN — leva aproximadamente o mesmo punhado de comandos display de qualquer forma, e é a única maneira de saber se mais largura de banda realmente resolverá ou apenas comprará alguns meses.
Esta nota se baseia no modelo de solução de problemas de multicast dos roteadores e switches Huawei série AR e seus comandos display igmp snooping / pim routing-table / multicast routing-table, além dos casos de campo por trás deles — vários de implantações reais de CFTV e IPTV. Se seu equipamento de acesso ou agregação for de outro fabricante, os comandos exatos mudam, mas a ordem de verificação subjacente — associação, tabela, capacidade — se aplica diretamente. Não cobre em profundidade casos específicos de mapeamento SSM nem cenários de multicast sobre overlay MPLS/VPN.
Conte-nos se é IPTV ou CFTV, se o sintoma é constante ou só em horários de pico, junto com a saída de display igmp snooping / pim routing-table, e ajudamos você a interpretá-la.