Segurança : Dispositivos de segurança adaptáveis Cisco ASA 5500 Series

Troubleshooting e problemas comuns do Multicast ASA

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


Índice


Introdução

Este documento explica potencialidades de transmissão múltipla da ferramenta de segurança adaptável (ASA), assim como problemas potenciais que podem ser encontrados ao usar a característica.

Nota: Contribuído pelo gaio Johnston, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

  • Multicast ASA

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Caracterize a informação

O guia do comando line configuration ASA esboça a característica do roteamento de transmissão múltipla e como configurar-la:

http://www.cisco.com/en/US/docs/security/asa/asa90/configuration/guide/route_multicast.html

O Multicast no ASA pode ser configurado em um de dois modos:

  • Modo escasso de PIM (preferido)

  • IGMP Stub-MODE (protocolo de gestão do grupo do Internet, RFC 2236 IGMPv2)

O modo escasso de PIM é a opção preferida porque o ASA se comunica com os vizinhos que usam um protocolo de roteamento de transmissão múltipla verdadeiro (PIM). O IGMP Stub-MODE foi a única opção de configuração do Multicast antes que a versão ASA 7.0 esteve liberada, e operada simplesmente enviando os relatórios IGMP recebidos dos clientes para roteadores fluxo acima.

Operação do modo escasso de PIM

  • O ASA apoia o modo escasso de PIM e o modo bidirecional PIM.

  • O modo escasso de PIM e os comandos IGMP stub-MODE não devem ser configurados simultaneamente.

  • Com modo escasso de PIM que todo o tráfego multicast flui ao ponto de reunião (RP), a seguir é enviado inicialmente para os receptores. Depois que alguns cronometram o fluxo do Multicast irá diretamente da fonte aos receptores (que contorneiam o RP).

A imagem abaixo ilustra uma distribuição comum onde o ASA tenha clientes do Multicast em uma relação, e vizinhos de PIM em outra:

http://www.cisco.com/c/dam/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115804-asa-multi-probs-01.gif

Configuração de exemplo do modo escasso de PIM

Conclua estes passos:

  1. Permita o roteamento de transmissão múltipla (modo de configuração global).

    ASA(config)# multicast-routing
  2. Defina o endereço do ponto de reunião PIM.

    ASA(config)# pim rp-address 172.18.123.3
  3. Permita os pacotes de transmissão múltipla dentro na relação apropriada (necessária somente se a política de segurança do ASA está obstruindo os pacotes de transmissão múltipla de entrada).

    access-list 105 extended permit ip any host 224.1.2.3
    access-group 105 in interface outside

Operação IGMP Stub-MODE

  • Em IGMP Stub-MODE o ASA atua como um cliente do Multicast gerando ou enviando os relatórios IGMP (igualmente conhecidos como o IGMP “se junta”) para roteadores adjacentes, para provocar a recepção do tráfego multicast

  • O Roteadores enviará periodicamente perguntas aos anfitriões para ver se qualquer nó na rede quer continuar a receber o tráfego multicast.

  • O IGMP Stub-MODE não é recomendado porque o modo escasso de PIM oferece muitos benefícios sobre o Stub-MODE (que inclui fluxos de tráfego multicast dos mais eficiente, capacidade participar no PIM, etc.).

A imagem abaixo ilustra a operação básica de um ASA configurado para IGMP Stub-MODE.

http://www.cisco.com/c/dam/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115804-asa-multi-probs-02.gif

Configuração IGMP Stub-MODE

Conclua estes passos:

  1. Permita o roteamento de transmissão múltipla (modo de config global).

    ASA(config)# multicast-routing
  2. Na relação em que você receberá os relatórios do igmp, configurar o comando da dianteiro-relação do igmp. Envie aos pacotes para fora a relação para a fonte do córrego. No exemplo abaixo, os receptores de transmissão múltipla são conectados diretamente à interface interna, e o origem de transmissão múltipla é além da interface externa.

    !
    interface Ethernet0
     nameif outside
     security-level 0
     ip address 172.16.1.1 255.255.255.0
     no pim
    !
    interface Ethernet1
     nameif inside
     security-level 100
     ip address 10.0.0.1 255.255.255.0
     no pim
     igmp forward interface outside
    !
  3. Permita os pacotes de transmissão múltipla dentro na relação apropriada (somente necessária se a política de segurança do ASA nega o tráfego multicast de entrada).

    access-list 105 extended permit ip any host 224.1.2.3
    access-group 105 in interface outside

    Frequentemente há uma confusão em torno dos comandos diferentes da relação secundário-MODE do igmp, e o diagrama abaixo tenta descrever quando usar cada um:

    http://www.cisco.com/c/dam/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115804-asa-multi-probs-03.gif

Metodologia de Troubleshooting

Informação a serem coletadas ao pesquisar defeitos problemas de transmissão múltipla

A fim compreender e diagnosticar completamente um problema do Multicast Forwarding no ASA, alguma ou tudo esta informação puderam ser precisados:

  • Uma descrição da topologia de rede, incluindo o lugar FO os remetentes do Multicast, os receptores, e o ponto de reunião.

  • O endereço IP de Um ou Mais Servidores Cisco ICM NT que específico do grupo o tráfego se está usando, assim como as portas e protocolo empregadas.

  • Syslog gerados pelo ASA então o fluxo de transmissão múltipla tem o problema.

  • Show command output (resultado do comando show) específico da interface da linha de comando ASA, incluindo:

    show mroute
    show mfib
    show pim neighbor
    show route
    show tech-support
  • Capturas de pacote de informação para mostrar se os dados de transmissão múltipla chegam no ASA, e se os pacotes estão enviados com o ASA.

  • Capturas de pacote de informação que mostram o IGMP e/ou os pacotes de PIM.

  • Informação dos dispositivos adjacentes do Multicast (Roteadores) como da “o mrouter mostra” e da “o mfib mostra”.

  • Capturas de pacote de informação e/ou comandos show determinar se o ASA está deixando cair os pacotes de transmissão múltipla. Da “o comando da gota asp mostra” pode ser usado para determinar se o ASA está deixando cair os pacotes. Adicionalmente, as capturas de pacote de informação do tipo “ASP-gota” podem ser usadas para capturar todos os pacotes que o ASA deixa cair, a seguir ser examinadas para considerar se os pacotes de transmissão múltipla estam presente na captação da gota.

Saída do comando de exibição útil

A saída do comando do mrouter da mostra mostra os vários grupos e informação de encaminhamento, e é muito similar ao comando do mrouter da mostra IO. O comando do mfib da mostra indica o estado da transmissão dos vários grupos de transmissão múltipla. É especialmente importante observar o contador de pacote de informação da transmissão, assim como outro (que indica gotas):

ciscoasa# show mfib
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
             AR - Activity Required, K - Keepalive
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
Interface Flags: A - Accept, F - Forward, NS - Negate Signalling 
             IC - Internal Copy, NP - Not platform switched
             SP - Signal Present
Interface Counts: FS Pkt Count/PS Pkt Count
(*,224.1.2.3) Flags: S K
   Forwarding: 0/0/0/0, Other: 0/0/0
   inside Flags: F
     Pkts: 0/0
(192.168.1.100,224.1.2.3) Flags: K
   Forwarding: 6749/18/1300/182, Other: 690/0/690
   outside Flags: A
   inside Flags: F
     Pkts: 6619/8
(*,232.0.0.0/8) Flags: K
   Forwarding: 0/0/0/0, Other: 0/0/0
ciscoasa# 

O comando claro dos contadores do mfib pode ser usado para cancelar os contadores, que é muito útil durante testes:

ciscoasa# clear mfib counters
ciscoasa#

Usando capturas de pacote de informação para capturar o tráfego multicast

A utilidade a bordo da captura de pacote de informação do ASA é muito útil para pesquisar defeitos problemas de transmissão múltipla. No exemplo abaixo, todos os pacotes que chegam no DMZ do ASA conectam, destinaram a 239.17.17.17 serão capturados:

ciscoasa# capture dmzcap interface dmz 
ciscoasa# capture dmzcap match ip any host 239.17.17.17
ciscoasa# show cap dmzcap

324 packets captured

   1: 17:13:30.976618       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
   2: 17:13:30.976679       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
   3: 17:13:30.996606       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
   4: 17:13:30.996652       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
   5: 17:13:31.016676       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
   6: 17:13:31.016722       802.1Q vlan#301 P0 10.1.123.129.2000 > 239.17.17.17.16384:
  udp 172 
....

As capturas de pacote de informação são igualmente úteis para capturar o tráfego PIM e IGMP. A captação abaixo mostra que a interface interna recebeu um pacote de IGMP (protocolo IP 2) originado de 10.0.0.2:

ciscoasa# capture capin interface inside
ciscoasa# capture capin match igmp any any
ciscoasa# show cap capin
1 packets captured
1: 10:47:53.540346 802.1Q vlan#15 P0 10.0.0.2 > 224.1.2.3:
  ip-proto-2, length 8
ciscoasa#

Desenvolvimento do Multicast do modo escasso de PIM do exemplo ASA

Os diagramas abaixo ilustram como o ASA interage com os dispositivos vizinho para obter o fluxo de tráfego multicast com modo escasso de PIM. Neste exemplo específico, o ASA recebe.

Compreendendo a topologia de rede

Determine exatamente onde o remetente e o receptor do fluxo de transmissão múltipla específico você estão testando residem. Também, determine o endereço IP de Um ou Mais Servidores Cisco ICM NT do grupo de transmissão múltipla que estão sendo usados, assim como o lugar do ponto de reunião.

http://www.cisco.com/c/dam/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115804-asa-multi-probs-04.gif

Neste caso, os dados devem ser recebidos na interface externa do ASA, e ser enviados ao receptor de transmissão múltipla na interface interna. Porque o receptor está na mesma sub-rede IP que a interface interna do ASA, espere ver um relatório IGMP recebido na interface interna do ASA quando os pedidos do cliente receber o córrego. O endereço IP de Um ou Mais Servidores Cisco ICM NT do remetente é 192.168.1.50.

Verificar o ASA recebe o relatório IGMP do receptor

Neste exemplo, o relatório IGMP é gerado pelo receptor e processado pelo ASA.

As capturas de pacote de informação e a saída de debugam o igmp podem ser usadas para verificar que o ASA recebido, e processado com sucesso o mensagem IGMP.

Verificar o ASA envia um juntar mensagem PIM para o ponto de reunião

O ASA interpreta o relatório IGMP e gerencie um juntar mensagem PIM, a seguir envia-lhe para fora a relação para o RP.

http://www.cisco.com/c/dam/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115804-asa-multi-probs-05.gif

A saída abaixo é de debuga o grupo 224.1.2.3 do pim e mostra o ASA que envia com sucesso o juntar mensagem PIM. O remetente do fluxo de transmissão múltipla é 192.168.1.50

IPv4 PIM: (*,224.1.2.3) J/P processing
IPv4 PIM: (*,224.1.2.3) Periodic J/P scheduled in 50 secs
IPv4 PIM: (*,224.1.2.3) J/P adding Join on outside
IPv4 PIM: (*,224.1.2.3) inside Processing timers
IPv4 PIM: Sending J/P message for neighbor 10.2.3.2 on outside for 1 groups
IPv4 PIM: [0] (192.168.1.50,224.1.2.3/32) MRIB update (a=0,f=0,t=1)
IPv4 PIM: [0] (192.168.1.50,224.1.2.3/32) outside MRIB update (f=20,c=20)
IPv4 PIM: [0] (192.168.1.50,224.1.2.3) Signal present on outside
IPv4 PIM: (192.168.1.50,224.1.2.3) Create entry
IPv4 PIM: [0] (192.168.1.50,224.1.2.3/32) outside MRIB modify NS
IPv4 PIM: Adding monitor for 192.168.1.5

Verificar o ASA recebe e para a frente o fluxo de transmissão múltipla

O ASA começa a receber o tráfego multicast na interface externa (ilustrada pelas setas verde), e a enviá-lo aos receptores no interior.

http://www.cisco.com/c/dam/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115804-asa-multi-probs-06.gif

O mrouter da mostra e os comandos do mfib da mostra, assim como as capturas de pacote de informação, podem ser usados para verificar que o ASA recebe e para a frente os pacotes de transmissão múltipla.

Uma conexão será construída na tabela de conexão do ASA para representar o fluxo de transmissão múltipla:

ciscoasa# show conn
59 in use, 29089 most used
...
UDP outside:192.168.1.50/52075 inside:224.1.2.3/1234 flags -
...

Análise de dados

Problemas comuns

Esta seção fornece uma série de problemas relacionados do Multicast do mundo real ASA que os administradores de rede encontraram no passado.

O ASA não envia mensagens PIM para os roteadores fluxo acima devido ao HSRP

Quando este problema é encontrado, o ASA não envia a todas as mensagens PIM para fora uma relação. O diagrama abaixo mostra que o ASA não pode enviar mensagens PIM para o remetente, mas o mesmo problema pode ser considerado quando o ASA precisa de enviar uma mensagem PIM para o RP.

http://www.cisco.com/c/dam/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115804-asa-multi-probs-07.gif

A saída de debuga o pim mostra que o ASA não pode enviar a mensagem PIM ao roteador de próximo salto ascendente:

IPv4 PIM: Sending J/P to an invalid neighbor: outside 10.0.0.1

Esta edição não é específica ao ASA, e igualmente afeta o Roteadores. O problema é provocado pela combinação da configuração da tabela de roteamento do ASA e da configuração de HSRP usadas pelos vizinhos de PIM.

A tabela de roteamento do ASA aponta ao IP 10.0.0.1 HSRP como o dispositivo de próximo salto:

ciscoasa# sh run route
route outside 0.0.0.0 0.0.0.0 10.0.0.1 1

Contudo, o relacionamento do vizinho de PIM é formado entre os endereços IP de Um ou Mais Servidores Cisco ICM NT da interface física do Roteadores, e não o IP HSRP:

ciscoasa# sh pim neighbor
Neighbor Address  Interface          Uptime    Expires DR pri Bidir
10.0.0.2          outside            01:18:27  00:01:25 1 
10.0.0.3          outside            01:18:03  00:01:29 1 (DR)

Refira porque não faz o trabalho do modo escasso de PIM com uma rota estática a um endereço hsrp? para obter mais informações.

Um trecho do documento:

“Por que o roteador não está enviando o join/prune message? O RFC 2362 indica que “um roteador envia um join/prune message periódico a cada vizinho distinto de RPF associado com o cada (S, G), (*, G) e (*, *, RP) entrada. Mensagens de junção e remoção são enviadas somente se o vizinho de RPF for um vizinho de PIM.

A fim abrandar o problema, adicionar uma entrada do mroute estática no ASA para o tráfego na pergunta. Certifique-se de que aponta a um endereços IP de Um ou Mais Servidores Cisco ICM NT da relação de dois do roteador (10.0.0.2 ou 10.0.0.3 no exemplo acima). Neste caso, o comando seguinte permite que o ASA envie as mensagens PIM dirigidas para o remetente do Multicast em 172.16.1.2:

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 10.0.0.3

Uma vez que isto é feito a tabela de roteamento de transmissão múltipla cancelará a tabela de roteamento unicast do ASA, e o ASA enviará as mensagens PIM diretamente ao vizinho de 10.0.0.3.

O ASA ignora relatórios IGMP porque não é o roteador designado no segmento de LAN

Para este problema, o ASA recebe um relatório IGMP de um receptor de transmissão múltipla diretamente conectado, contudo ignora-o. Nenhum resultado do debug será gerado e o pacote é deixado cair simplesmente, e a recepção do córrego falha.

http://www.cisco.com/c/dam/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115804-asa-multi-probs-08.gif

Para este problema, o ASA está ignorando o pacote porque não é o roteador designado eleito PIM no segmento de LAN onde os clientes residem.

A saída ASA CLI abaixo mostra que um dispositivo diferente é o roteador designado (denotado pelo “DR”) na rede da interface interna:

ciscoasa#show pim neighbor

 Neighbor Address  Interface          Uptime    Expires DR pri Bidir
 192.168.1.2       outside      	   01:18:27  00:01:25 N/A> 
 10.0.0.2          inside              01:18:03  00:01:29 1 (DR)

À revelia, o PIM está permitido em todas as relações ASA quando o comando do roteamento de transmissão múltipla é adicionado à configuração do ASA. Se há outros vizinhos de PIM (outros Roteadores ou ASA) na interface interna do ASA (onde os clientes residem) e um daqueles vizinhos foi elegido porque o DR para esse segmento, a seguir outro, roteadores não-dr deixará cair relatórios IGMP. A solução é desabilitar o PIM na relação do ASA (com nenhum comando pim na relação envolvida), ou fazer ao ASA o DR para o segmento usando o comando interface da DR-prioridade do pim.

O ASA não envia o tráfego multicast na escala 232.x.x.x/8

Esta escala de endereço é para o uso com Source Specific Multicast (SSM) que o ASA não apoia atualmente.

A saída de debuga o igmp mostrará este erro:

IGMP: Exclude report on inside ignored for SSM group 232.179.89.253

Os pacotes de transmissão múltipla das gotas ASA devido à verificação do encaminhamento de caminho reverso

Neste caso, o ASA recebe o tráfego multicast em uma relação, mas não é enviado sobre ao receptor. Os pacotes são deixados cair pelo ASA porque falham a verificação de segurança do encaminhamento de caminho reverso (RPF). O RPF é permitido em todas as relações para o tráfego multicast e não pode ser desabilitado (para pacotes do unicast a verificação não está ligada à revelia, e é permitida com o IP verifica o comando interface do caminho reverso).

Devido à verificação RPF, quando o tráfego multicast é recebido em uma relação, o ASA verifica para ver que tem uma rota de volta à fonte do tráfego do tráfego multicast (verifica o unicast e a tabela de roteamento de transmissão múltipla) nessa relação. Se não tem uma rota ao remetente, deixa cair o pacote. Estas gotas podem ser consideradas como um contador na saída da gota asp da mostra:

ciscoasa(config)# show asp drop

Frame drop:
  Invalid UDP Length                                          2
  No valid adjacency                                         36
  No route to host                                         4469
  Reverse-path verify failed                      121012

Este problema pode ser abrandado adicionando uma entrada de tabela específica do roteamento de transmissão múltipla ao ASA para o remetente do tráfego. No exemplo abaixo, o comando do mrouter é usado satisfazer a verificação RPF para o tráfego multicast originado de 172.16.1.2 recebeu na interface externa:

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 outside

O ASA não gerencie o PIM junta-se em cima do Switchover PIM à Fonte-árvore

Inicialmente, os pacotes de transmissão múltipla do modo escasso de PIM fluirão do remetente do Multicast ao RP, a seguir do RP ao receptor através de uma árvore de transmissão múltipla compartilhada. Contudo, uma vez que a taxa de bits agregada alcança um determinado ponto inicial, o roteador o mais próximo ao receptor de transmissão múltipla tentará receber o tráfego ao longo da árvore fonte-específica. Este roteador gerará um PIM novo junta-se para o grupo e envia-se o para o remetente do fluxo de transmissão múltipla (e não para o RP, como antes).

Segundo a topologia de rede, o remetente do tráfego multicast pôde residir em uma relação diferente ASA do que o RP. Quando o ASA recebe o PIM junte-se para comutar à árvore específica da fonte, o ASA deve ter uma rota ao endereço IP de Um ou Mais Servidores Cisco ICM NT do remetente. Se esta rota não é encontrada, o PIM junta-se ao pacote estará deixado cair e o seguinte mensagem será considerado na saída de debuga o pim:

NO RPF Neighbor to send J/P

A solução para este problema é adicionar uma entrada do mroute estática para o remetente do córrego, indicando a relação ASA fora de que o remetente reside.

O ASA deixa cair os pacotes de transmissão múltipla devido ao Time to Live (TTL) excedido

Neste caso, o tráfego multicast está falhando porque o TTL dos pacotes é demasiado baixo. Isto faz com que o ASA, ou algum outro dispositivo na rede, deixem-nos cair.

Frequentemente os pacotes de transmissão múltipla têm o conjunto de valores IP TTL muito baixo pelo aplicativo que os enviou. Isto é feito às vezes à revelia para ajudar a assegurar-se de que o tráfego multicast não viaje demasiado distante embora a rede. Por exemplo, à revelia o aplicativo de cliente de LAN video (uma ferramenta popular do transmissor e de testes do Multicast) ajusta o TTL no pacote IP a 1 à revelia.

O ASA experimenta o uso e os pacotes descartado da alta utilização da CPU devido à topologia específica do Multicast

O ASA pôde experimentar a alta utilização da CPU e o fluxo de transmissão múltipla pôde experimentar quedas de pacote de informação se todo o seguimento é verdadeiro sobre a topologia do Multicast:

  1. O ASA está atuando como o RP.

  2. O ASA é o primeiro receptor do salto do fluxo de transmissão múltipla. Isto significa que o remetente do Multicast é na mesma sub-rede IP uma relação ASA.

  3. O ASA é o roteador do último salto do fluxo de transmissão múltipla. Isto significa que um receptor de transmissão múltipla está na mesma sub-rede IP que uma relação ASA.

Se todos os acima são verdadeiros, a seguir a dívida faz uma limitação de projeto que o ASA será forçado para processar o interruptor o tráfego multicast. Isto conduz aos fluxos de transmissão múltipla altos da taxa de dados para experimentar quedas de pacote de informação. O contador de queda asp da mostra que incrementa quando estes pacotes são deixados cair é pontapé-taxa-limite.

A fim determinar se um ASA está experimentando este problema, termine estas etapas:

Passo 1: Verifique se o ASA é o RP usando os dois comandos:

show run pim
show pim tunnel

Passo 2: Verifique se o ASA é o roteador do último salto usando este comando:

show igmp group <mcast_group_IP>

Passo 3: Verifique se o ASA é o primeiro roteador de salto usando este comando:

show mroute <mcast_group_IP>

Um receptor de transmissão múltipla de desligamento interrompe a recepção do grupo de transmissão múltipla em outras relações

Somente os ASA que operam-se em IGMP Stub-MODE experimentam este problema. Os ASA que participam no roteamento de transmissão múltipla PIM não são afetados.

A edição é identificada pelo erro CSCeg48235 - IGMP: Parar o rcvr do grupo interrompe a recepção do grupo em outras relações

Este é o Release Note do erro, que explica o problema:

Symptom:
When a PIX or ASA firewall is configured for IGMP stub mode multicast reception and 
traffic from a multicast group is forwarded to more than one interface, if a host 
behind a receiving interface sends an IGMP Leave message for the group, it could 
temporarily interrupt the reception for that group on other interfaces of the firewall.

The problem is triggered when the firewall forwards the IGMP leave for the group 
towards the upstream device; that device then sends a IGMP query to determine if any 
other receivers exist out that interface towards the firewall, but the firewall does 
not report that it still has valid receivers.

Conditions:
The PIX or ASA must be configured for IGMP stub mode multicast. IGMP stub mode is a 
legacy multicast forwarding technique, whereby IGMP packets from receivers are forwarded 
through the firewall towards the source of the stream. It is recommended to use PIM 
multicast routing instead of stub igmp forwarding.

Workarounds:
1) Use PIM multicast routing instead of IGMP stub mode.
2) Decrease multicast IGMP query timers so that the receivers are queried more frequently, 
causing their IGMP reports to be forwarded towards the sender more frequently, thus 
restarting the stream quicker.

O ASA deixa cair os pacotes de transmissão múltipla devido à política de segurança da lista de acesso de partida

Com esta edição específica o ASA está deixando cair corretamente pacotes de transmissão múltipla (pela política de segurança configurada). Contudo, é difícil para o administrador de rede identificar a razão para as quedas de pacote de informação. Neste caso, o ASA é deixar cair pacotes devido à lista de acesso de partida configurada para uma relação. A ação alternativa é permitir o fluxo de transmissão múltipla na lista de acesso de partida.

Quando isto ocorre, os pacotes de transmissão múltipla estarão deixados cair e o contador de queda ASP será “FP nenhum intrf da saída do mcast (nenhum-mcast-intrf)”.

O ASA deixa cair os pacotes primeiros quando um fluxo de transmissão múltipla é começado primeiramente

Quando os primeiros pacotes de um fluxo de transmissão múltipla chegam no ASA, o ASA deve construir essa conexão particular do Multicast e a entrada de rota m associada para enviar os pacotes. Quando a entrada for criada alguns pacotes de transmissão múltipla puderam ser deixados cair até o mrouter e as conexões foram estabelecidas (geralmente esta toma menos do que um segundo). Uma vez que a instalação do fluxo de transmissão múltipla está completa, os pacotes já não serão taxa limitada.

Os pacotes deixados cair por este motivo terão a razão da gota ASP “do limite de taxa do pontapé (do pontapé-taxa-limite) excedido”. Está abaixo a saída da captação asp da mostra (onde o asp é uma captação da gota ASP configurada no ASA para capturar pacotes descartado) e você pode ver os pacotes de transmissão múltipla que foram deixados cair por este motivo:

ASA # sh capture asp
2 packets captured
   1: 16:14:49.419091 10.23.2.2.810 > 239.255.123.123.890:  udp 32 Drop-reason:
 (punt-rate-limit) Punt rate limit exceeded
   2: 16:14:49.919172 10.23.2.2.810 > 239.255.123.123.890:  udp 32 Drop-reason:
 (punt-rate-limit) Punt rate limit exceeded
2 packets shown

Informações Relacionadas


Document ID: 115804