Distribuição de vídeo e conteúdo : Software Cisco Digital Content Manager (DCM)

Pesquise defeitos edições da inundação UDP no DCM

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como pesquisar defeitos o User Datagram Protocol (UDP) que inunda no gerente do conteúdo digital de Cisco (DCM).

Contribuído por Sourav Jyoti DAS, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

A informação neste documento é baseada em Cisco DCM D9902. 

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Problema

As encenações foram observadas onde o D9902 é conectado a um interruptor da camada 2 (L2) e configurado para receber fluxos de vídeo do unicast. Contudo, depois que o vídeo do unicast é fluído por aproximadamente cinco minutos, o mesmo LAN observa a inundação no interruptor, que causa uma indisponibilidade na rede cliente. Nesta encenação, determinou-se que a porta de switch conectada ao DCM envelheceu para fora a tabela de endereço de controle de acesso de mídia (MAC), que causou a inundação porque o endereço MAC de destino era desconhecido ao interruptor.

A inundação UDP é um problema comum em encenações unidirecionais. O temporizador do esconderijo do Address Resolution Protocol (ARP) (com um padrão de quatro horas) no roteador/camada 3 do Switches (L3) é sempre mais alto do que o intervalo da idade do MAC address (com um padrão de cinco minutos). Isto significa que há sempre uma possibilidade que a informação do MAC address pode ser removida do interruptor se não há nenhuma resposta do dispositivo de destino.

Nota: Um aumento no valor de timeout da idade da tabela de MAC não é recomendado, porque pode criar uma carga significativa no interruptor e fazer com que seja executado fora dos recursos.

Solução

Estão aqui três métodos diferentes que você pode executar a fim resolver esta edição:

  • O mais seguro e solução simples para esta edição são criar um manequim que o Multicast se junta no DCM. Neste caso, o DCM envia uns relatórios de associação do Internet Group Management Protocol (IGMP) ao interruptor, e o interruptor começa a votar periodicamente o DCM. A fim votar o DCM, o interruptor envia uma consulta de associação IGMP, que refresque a tabela de endereços MAC no interruptor.

  • Uma outra solução para esta edição é diminuir o valor do temporizador do cache ARP no interruptor de modo que seja menos do que ou perto do aging timer da tabela de MAC. Isto faz com que os pacotes ARP transformem-se transmissão, e o MAC address deve ser relearned antes das idades de entrada L2 para fora.

  • Como uma terceira opção, você pode configurar uma entrada do endereço MAC estático no interruptor, que permanece mesmo depois uma repartição e elimina a questão de timeout.

Cuidado: Ciao se você decide executar a terceira opção, porque pode ser perigoso quando você muda a expedição de cabogramas.

Dica: Refira o Switches ARP do Catalyst 6500/6000 ou as edições da tabela CAM que pesquisam defeitos o documento Cisco para obter mais informações sobre da inundação UDP.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 118966