Solução de problemas comuns e multicast do ASA

Introduction

Este documento explica os recursos multicast do Adaptive Security Appliance (ASA), bem como os possíveis problemas que podem ser encontrados ao usar o recurso.

Prerequisites

Requirements

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.

Conventions

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

Informações do recurso

O Guia de configuração da linha de comando do ASA descreve o recurso de roteamento multicast e como configurá-lo:

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

O multicast no ASA pode ser configurado em um dos dois modos:

• PIM modo esparso (preferencial)

• Modo stub IGMP (Internet Group Management Protocol, RFC 2236 IGMPv2)

PIM sparse-mode é a escolha preferencial, pois o ASA se comunica com vizinhos usando um verdadeiro PIM (Multicast Routing Protocol). O modo Stub IGMP era a única opção de configuração multicast antes do lançamento do ASA versão 7.0 e operado simplesmente pelo encaminhamento de relatórios IGMP recebidos de clientes para roteadores upstream.

Operação em modo escasso de PIM

• O ASA oferece suporte ao modo escasso PIM e ao modo bidirecional PIM.

• Os comandos PIM sparse-mode e IGMP stub-mode não devem ser configurados simultaneamente.

• Com o PIM modo esparso, todo o tráfego multicast inicialmente flui para o ponto de encontro (RP), então é encaminhado para os receptores. Depois de algum tempo, o fluxo de multicast irá diretamente da origem para os receptores (ignorando o RP).

A figura abaixo ilustra uma implantação comum em que o ASA tem clientes multicast em uma interface e vizinhos PIM em outra:

Exemplo de configuração de modo escasso de PIM

Conclua estes passos:

1. Ative o roteamento multicast (modo de configuração global).

   ASA(config)# multicast-routing

2. Defina o endereço do ponto de encontro PIM.

   ASA(config)# pim rp-address 172.18.123.3

3. Permitir os pacotes multicast na interface apropriada (necessário somente se a política de segurança do ASA estiver bloqueando os pacotes multicast de entrada).

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

Operação em modo de stub IGMP

• No modo Stub IGMP, o ASA atua como um cliente multicast gerando ou encaminhando relatórios IGMP (também conhecido como "junções" de IGMP) para roteadores adjacentes, para disparar a recepção de tráfego multicast

• Os roteadores enviarão periodicamente consultas aos hosts para ver se qualquer nó na rede deseja continuar a receber o tráfego multicast.

• O modo Stub IGMP não é recomendado porque o modo esparso PIM oferece muitos benefícios sobre o modo Stub (incluindo fluxos de tráfego multicast mais eficientes, capacidade de participar no PIM, etc.).

A figura abaixo ilustra a operação básica de um ASA configurado para o modo Stub IGMP.

Configuração do modo stub IGMP

Conclua estes passos:

1. Ative o roteamento multicast (modo de configuração global).

   ASA(config)# multicast-routing

2. Na interface na qual você receberá os relatórios igmp, configure o comando igmp forward-interface. Encaminhe os pacotes para fora da interface em direção à origem do fluxo. No exemplo abaixo, os receptores multicast são diretamente conectados à interface interna e a origem multicast está 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 que os pacotes multicast entrem na interface apropriada (somente necessário se a política de segurança do ASA negar 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á confusão em torno dos diferentes comandos submodo de interface igmp, e o diagrama abaixo tenta descrever quando usar cada um deles:

   

Metodologia de solução de problemas

Informações a serem coletadas ao solucionar problemas de multicast

Para entender e diagnosticar completamente um problema de encaminhamento multicast no ASA, algumas ou todas essas informações podem ser necessárias:

• Uma descrição da topologia de rede, incluindo a localização dos remetentes multicast, receptores e ponto de encontro.

• O endereço IP do grupo específico que o tráfego está usando, bem como as portas e os protocolos empregados.

• Syslogs gerados pelo ASA no momento em que o fluxo multicast tem problemas.

• Saída específica do comando show da interface de linha de comando ASA, incluindo:

  show mroute
  show mfib
  show pim neighbor
  show route
  show tech-support

• O pacote captura para mostrar se os dados multicast chegam ao ASA e se os pacotes são encaminhados através do ASA.

• Capturas de pacotes mostrando pacotes IGMP e/ou PIM.

• Informações de dispositivos multicast adjacentes (roteadores) como "show mroute" e "show mfib".

• O pacote captura e/ou mostra comandos para determinar se o ASA está descartando os pacotes multicast. O comando 'show asp drop' pode ser usado para determinar se o ASA está descartando os pacotes. Além disso, as capturas de pacotes do tipo 'asp-drop' podem ser usadas para capturar todos os pacotes que o ASA descarta e, em seguida, examinadas para verificar se os pacotes multicast estão presentes na captura de descarte.

Saída útil do comando show

A saída do comando show mroute mostra os vários grupos e informações de encaminhamento e é muito semelhante ao comando show mroute do IOS. O comando show mfib exibe o status de encaminhamento dos vários grupos multicast. É especialmente importante observar o contador de pacotes de encaminhamento, bem como Outros (que indica quedas):

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 clear mfib counters pode ser usado para limpar os contadores, o que é muito útil durante o teste:

ciscoasa# clear mfib counters
ciscoasa#

Usando capturas de pacotes para capturar o tráfego multicast

O utilitário de captura de pacote integrado do ASA é muito útil para solucionar problemas de multicast. No exemplo abaixo, todos os pacotes que chegam à interface DMZ do ASA, destinados 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 pacotes também são úteis para capturar tráfego PIM e IGMP. A captura abaixo mostra que a interface interna recebeu um pacote 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#

Exemplo de implantação multicast de modo escasso de PIM ASA

Os diagramas abaixo ilustram como o ASA interage com dispositivos vizinhos para fazer com que o tráfego multicast flua com o modo escasso do PIM. Neste exemplo específico, o ASA recebe.

Entendendo a topologia de rede

Determine exatamente onde reside o emissor e o receptor do fluxo multicast específico que você está testando. Além disso, determine o endereço IP do grupo multicast que está sendo usado, bem como a localização do ponto de encontro.

Nesse caso, os dados devem ser recebidos na interface externa do ASA e encaminhados ao receptor multicast na interface interna. Como 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 o cliente solicitar o recebimento do fluxo. O endereço IP do remetente é 192.168.1.50.

Verificando se o ASA recebe o relatório IGMP do receptor

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

Capturas de pacotes e a saída de debug igmp podem ser usadas para verificar se o ASA recebeu e processou com êxito a mensagem IGMP.

Verificação de que o ASA envia uma mensagem de união PIM para o ponto de encontro

O ASA interpreta o relatório IGMP e gera uma mensagem de união PIM e, em seguida, o envia pela interface em direção ao RP.

A saída abaixo é do grupo de depuração pim 224.1.2.3 e mostra o ASA enviando com êxito a mensagem de junção PIM. O remetente do fluxo multicast é 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

Verificando se o ASA recebe e encaminha o fluxo multicast

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

Os comandos show mroute e show mfib, bem como capturas de pacotes, podem ser usados para verificar se o ASA recebe e encaminha os pacotes multicast.

Uma conexão será construída na tabela de conexão do ASA para representar o fluxo multicast:

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 reais relacionados ao multicast ASA que os administradores de rede encontraram no passado.

O ASA não consegue enviar mensagens PIM para roteadores upstream devido ao HSRP

Quando esse problema é encontrado, o ASA não envia nenhuma mensagem PIM para uma interface. O diagrama abaixo mostra que o ASA não pode enviar mensagens PIM para o remetente, mas o mesmo problema pode ser visto quando o ASA precisa enviar uma mensagem PIM para o RP.

A saída do debug pim mostra que o ASA não pode enviar a mensagem PIM para o roteador upstream do próximo salto:

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

Esse problema não é específico do ASA e também afeta os roteadores. O problema é desencadeado pela combinação da configuração da tabela de roteamento do ASA com a configuração do HSRP usada pelos vizinhos do PIM.

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

ciscoasa# sh run route
route outside 0.0.0.0 0.0.0.0 10.0.0.1 1

No entanto, a relação de vizinhança do PIM é formada entre os endereços IP da interface física dos roteadores, e não o IP do 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)

Consulte Por que o modo escasso de PIM não funciona com uma rota estática para um endereço de HSRP? para obter mais informações.

Um trecho do documento:

"Por que o roteador não está enviando a mensagem Join/Prune? O RFC 2362 afirma que "um roteador envia uma mensagem periódica Join/Prune a cada vizinho RPF distinto associado a cada entrada (S,G), (*,G) e (*,*,RP). Mensagens de junção e remoção são enviadas somente se o vizinho de RPF for um vizinho de PIM.

Para atenuar o problema, adicione uma entrada de rota estática no ASA para o tráfego em questão. Assegure-se de apontar para um dos endereços IP da interface do roteador (10.0.0.2 ou 10.0.0.3 no exemplo acima). Nesse caso, o comando a seguir permite que o ASA envie mensagens PIM direcionadas para o remetente multicast em 172.16.1.2:

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 10.0.0.3

Quando isso for feito, a tabela de roteamento multicast substituirá a tabela de roteamento unicast do ASA, e o ASA enviará as mensagens do PIM diretamente para o vizinho 10.0.0.3.

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

Para esse problema, o ASA recebe um relatório IGMP de um receptor multicast conectado diretamente, mas o ignora. Nenhuma saída de depuração será gerada e o pacote será simplesmente descartado, e a recepção de fluxo falhará.

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

A saída da CLI do ASA abaixo mostra que um dispositivo diferente é o roteador designado (denotado por "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)

Por padrão, o PIM é ativado em todas as interfaces ASA quando o comando multicast-routing é adicionado à configuração do ASA. Se houver outros vizinhos PIM (outros roteadores ou ASAs) na interface interna do ASA (onde os clientes residem) e um desses vizinhos tiver sido eleito porque o DR desse segmento, outros roteadores não-DR descartarão relatórios IGMP. A solução é desativar o PIM na interface do ASA (com o comando no pim na interface envolvida) ou tornar o ASA o DR do segmento usando o comando pim dr-priority interface.

O ASA não consegue encaminhar o tráfego multicast no intervalo 232.x.x.x/8

Esse intervalo de endereços deve ser usado com o Source Specific Multicast (SSM), que o ASA não suporta no momento.

A saída de debug igmp mostrará este erro:

IGMP: Exclude report on inside ignored for SSM group 232.179.89.253

O ASA descarta pacotes multicast devido à verificação de encaminhamento de caminho reverso

Nesse caso, o ASA recebe tráfego multicast em uma interface, mas não é encaminhado para o receptor. Os pacotes são descartados pelo ASA porque falham na verificação de segurança do Reverse Path Forwarding (RPF). O RPF é ativado em todas as interfaces para tráfego multicast e não pode ser desabilitado (para pacotes unicast, a verificação não está ativada por padrão e é habilitada com o comando ip verify reverse-path interface).

Devido à verificação RPF, quando o tráfego multicast é recebido em uma interface, o ASA verifica se tem uma rota de volta para a origem do tráfego multicast (ele verifica a tabela de roteamento unicast e multicast) nessa interface. Se não tiver uma rota para o remetente, ele descarta o pacote. Essas quedas podem ser vistas como um contador na saída de show asp drop:

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

Esse problema pode ser atenuado adicionando uma entrada específica da tabela de roteamento multicast ao ASA para o remetente do tráfego. No exemplo abaixo, o comando mroute é usado para satisfazer a verificação de RPF para tráfego multicast originado de 172.16.1.2 recebido na interface externa:

ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 outside

O ASA não gera PIM Join no PIM Switchover para a árvore de origem

Inicialmente, os pacotes multicast de modo esparso PIM fluirão do remetente multicast para o RP e, em seguida, do RP para o receptor através de uma árvore multicast compartilhada. No entanto, uma vez que a taxa de bits agregada atinja um determinado limite, o roteador mais próximo do receptor de multicast tentará receber tráfego ao longo da árvore de origem específica. Esse roteador gerará uma nova junção PIM para o grupo e a enviará para o remetente do fluxo multicast (e não para o RP, como antes).

Dependendo da topologia de rede, o remetente do tráfego multicast pode residir em uma interface ASA diferente do RP. Quando o ASA recebe a junção do PIM para alternar para a árvore específica de origem, o ASA deve ter uma rota para o endereço IP do remetente. Se essa rota não for encontrada, o pacote de junção PIM será descartado e a seguinte mensagem será vista na saída de debug pim:

NO RPF Neighbor to send J/P

A solução para esse problema é adicionar uma entrada de rota estática para o remetente do fluxo, apontando para fora a interface ASA de onde o remetente reside.

O ASA descarta pacotes multicast devido ao tempo de vida (TTL) excedido

Nesse caso, o tráfego multicast está falhando porque o TTL dos pacotes está muito baixo. Isso faz com que o ASA, ou algum outro dispositivo na rede, os descarte.

Frequentemente, os pacotes multicast têm o valor TTL de IP definido muito baixo pelo aplicativo que os enviou. Às vezes, isso é feito por padrão para ajudar a garantir que o tráfego multicast não vá muito longe pela rede. Por exemplo, por padrão, o aplicativo Video LAN Client (um conhecido transmissor multicast e ferramenta de teste) define o TTL no pacote IP como 1 por padrão.

O ASA Experimenta Alto Uso Da CPU E Pacotes Descartados Devido À Topologia Multicast Específica

O ASA pode experimentar alta CPU e o fluxo multicast pode experimentar descartes de pacotes se todas as seguintes situações forem verdadeiras com relação à topologia multicast:

1. O ASA está agindo como o RP.

2. O ASA é o primeiro receptor de salto do fluxo multicast. Isso significa que o remetente multicast está na mesma sub-rede IP e na interface ASA.

3. O ASA é o último roteador de salto do fluxo multicast. Isso significa que um receptor multicast está na mesma sub-rede IP de uma interface ASA.

Se todas as informações acima forem verdadeiras, então devido a uma limitação de design, o ASA será forçado a processar o tráfego multicast do switch. Isso resulta em fluxos multicast de alta taxa de dados para experimentar descartes de pacotes. O contador de queda show asp que é incrementado quando esses pacotes são descartados é o limite de taxa punt.

Para determinar se um ASA está enfrentando esse problema, faça o seguinte:

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 roteador do primeiro salto usando este comando:

show mroute <mcast_group_IP>

Um Receptor De Desconexão Multicast Interrompe A Recepção Do Grupo Multicast Em Outras Interfaces

Somente os ASAs que operam no modo Stub IGMP enfrentam esse problema. Os ASAs que participam do roteamento multicast PIM não são afetados.

O problema é identificado pelo bug CSCeg48235 - IGMP: Interrompendo a recepção de grupo de interrupções de rcvr em outras interfaces

Esta é a nota de versão do bug, 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 descarta pacotes multicast devido à política de segurança da lista de acesso de saída

Com esse problema específico, o ASA está descartando corretamente pacotes multicast (de acordo com a política de segurança configurada). No entanto, é difícil para o administrador de rede identificar o motivo das quedas de pacote. Nesse caso, o ASA está descartando pacotes devido à lista de acesso de saída configurada para uma interface. A solução é permitir o fluxo multicast na lista de acesso de saída.

Quando isso ocorrer, os pacotes multicast serão descartados e o contador de descarte ASP será "FP no mcast output intrf (no-mcast-intrf)".

O ASA Descarta Os Primeiros Pacotes Quando Um Fluxo Multicast É Iniciado Pela Primeira Vez

Quando os primeiros pacotes de um fluxo multicast chegam ao ASA, o ASA deve criar essa conexão multicast específica e a entrada de mroute associada para encaminhar os pacotes. Enquanto a entrada está sendo criada, alguns pacotes multicast podem ser descartados até que o mroute e as conexões tenham sido estabelecidas (geralmente isso leva menos de um segundo). Quando a configuração do fluxo multicast estiver concluída, os pacotes não serão mais limitados.

Os pacotes descartados por esse motivo terão o motivo de queda de ASP de "(punt-rate-limit) Punt rate limit excedido". Abaixo está a saída de show capture asp (onde asp é uma captura de queda de ASP configurada no ASA para capturar pacotes descartados) e você pode ver os pacotes multicast que foram descartados por esse 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

• Suporte Técnico e Documentação - Cisco Systems