Contents
Introdução
Este documento descreve o roteamento multicast no Adaptive Security Appliance (ASA) e problemas comuns.
Informações de recurso
Abreviações/acrônimos
| Acrônimos |
Explicação |
| FHR |
Roteador de primeiro salto - um salto diretamente conectado à origem do tráfego multicast. |
| LHR |
Roteador de último salto - um salto diretamente conectado aos receptores do tráfego multicast. |
| RP |
Ponto de reunião |
| DR. |
Roteador designado |
| SPT |
Árvore de caminho mais curto |
| RPT |
Árvore Rendezvous-Point (RP), árvore de compartilhamento |
| RPF |
Encaminhamento de caminho reverso |
| ÓLEO |
Lista de interface de saída |
| MRIB |
Base de Informações de Roteamento Multicast |
| MFIB |
Base de Informações de Encaminhamento Multicast |
| ASM |
Multicast de qualquer origem |
| BSR |
Roteador Bootstrap |
| SSM |
Multicast específico da origem |
| FP |
Caminho rápido |
| SP |
Caminho Lento |
| CP |
Ponto de controle |
| PPS |
Taxa de pacotes por segundo |
- PIM sparse-mode (Multicast independente de protocolo: RFC 4601)
- Modo stub IGMP (Internet Group Management Protocol: RFC 2236)
O modo escasso de PIM é a escolha preferencial porque o ASA se comunica com os vizinhos por meio de um verdadeiro protocolo de roteamento multicast (PIM). O modo stub IGMP era a única opção de configuração multicast antes do lançamento do ASA versão 7.0 e era operado simplesmente encaminhando relatórios IGMP recebidos de clientes para roteadores upstream.
Componentes do Multicast
Em geral, uma infraestrutura multicast é composta destes componentes:
Remetente => Host ou dispositivo de rede que origina o fluxo multicast. Exemplos são servidores que enviam fluxo de vídeo e/ou áudio e dispositivos de rede que executam um Routing Protocol, como EIGRP ou OSPF.
Receptor => Host ou dispositivo que recebe o fluxo multicast. Esse termo é usado com mais frequência para hosts ativamente interessados no tráfego e usam o IGMP para ingressar ou sair do grupo multicast em questão.
Roteadores / ASA => Dispositivos de rede responsáveis por processar e encaminhar o fluxo/tráfego multicast para outros segmentos da rede quando necessário da origem para o(s) cliente(s).
Multicast Routing Protocol => Protocolo responsável por encaminhar os pacotes multicast. O mais comum é o PIM (Protocol Independent Multicast), mas há outros como o MOSPF, por exemplo.
Internet Group Management Protocol (IGMP) => Processo usado pelos clientes para receber um fluxo multicast de um determinado grupo.
Operação PIM em modo escasso
- O ASA suporta PIM modo escasso e PIM modo bidirecional.
- Os comandos PIM sparse-mode e IGMP stub-mode não devem ser configurados simultaneamente.
-
Com o modo escasso de PIM, todo o tráfego multicast flui inicialmente para o ponto de encontro (RP) e é encaminhado para os receptores. Depois de algum tempo, o fluxo multicast vai diretamente da origem para os receptores (e ignora o RP).
Esta figura ilustra uma implantação comum em que o ASA tem clientes multicast em uma interface e vizinhos PIM em outra:
 |
Configuração de exemplo de modo escasso de PIM
1. Ative o roteamento multicast (modo de configuração global).
ASA(config)# multicast-routing
2. Defina o endereço de ponto de reunião PIM.
ASA(config)# pim rp-address 172.18.123.3
3. Permita a entrada de pacotes multicast na interface apropriada (necessário somente se a política de segurança do ASA bloquear os pacotes multicast de entrada).
access-list 105 extended permit ip any host 224.1.2.3 access-group 105 in interface outside
Exemplo de Modo Esparso de PIM:
Observe que o registro IGMP do cliente (etapas em vermelho) e o fluxo são recebidos pelo servidor (etapas em verde) têm cores diferentes, e isso foi feito dessa forma para evidenciar que ambos os processos podem ocorrer de forma independente.
Etapas de registro do cliente (etapas vermelhas):
1. O cliente envia um Relatório IGMP para o grupo 239.1.1.77
2. O roteador envia uma mensagem PIM Join ao RP estático configurado (10.1.1.1) para o grupo 239.1.1.7.
3. O ASA envia ao RP uma mensagem PIM Join para o grupo 239.1.1.77.
O ASA exibe a entrada PIM *,G na saída do comando show mroute:
ciscoasa# show mroute 239.1.1.77
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, 239.1.1.77), 00:03:43/00:02:41, RP 10.1.1.1, flags: S
Incoming interface: outside
RPF nbr: 10.38.111.240
Immediate Outgoing interface list:
inside, Forward, 00:03:43/00:02:41
Mas como o servidor de origem não iniciou nenhum fluxo, a saída "show mfib" no ASA não exibe nenhum pacote recebido:
ciscoasa# show mfib 239.1.1.77
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
(*,239.1.1.77) Flags: C K
Forwarding: 0/0/0/0, Other: 0/0/0
outside Flags: A
inside Flags: F NS
Pkts: 0/0
Antes que o servidor comece a enviar qualquer tráfego para o grupo multicast, o RP exibe apenas uma entrada "*.G" sem nenhuma interface de entrada na lista, como por exemplo:
CRSv#show ip mroute 239.1.1.77
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.77), 00:00:02/00:03:27, RP 10.1.1.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2, Forward/Sparse-Dense, 00:00:02/00:03:27
Uma vez que o servidor começa a fazer o fluxo para o grupo multicast, o RP cria uma entrada "S,G" e coloca a interface voltada para o remetente na lista de interfaces de entrada e começa a enviar o tráfego downstream para o ASA:
CRSv#show ip mroute 239.1.1.77
...
(*, 239.1.1.77), 00:03:29/stopped, RP 10.1.1.1, flags: SF
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2, Forward/Sparse-Dense, 00:03:29/00:02:58
(10.38.118.10, 239.1.1.77), 00:00:07/00:02:52, flags: FT
Incoming interface: GigabitEthernet1, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2, Forward/Sparse-Dense, 00:00:07/00:03:22
Use estes comandos para verificações:
- show mroute exibe uma entrada "S,G"
- show mfib command exibe contadores de pacotes de encaminhamento
O comando show conn exibe a conexão relacionada ao grupo de multicast ip
ciscoasa# show mroute 239.1.1.77
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, 239.1.1.77), 00:06:22/00:02:50, RP 10.1.1.1, flags: S
Incoming interface: outside
RPF nbr: 10.38.111.240
Immediate Outgoing interface list:
inside, Forward, 00:06:22/00:02:50
(10.38.118.10, 239.1.1.77), 00:03:00/00:03:28, flags: ST
Incoming interface: outside
RPF nbr: 10.38.111.240
Immediate Outgoing interface list:
inside, Forward, 00:03:00/00:03:26
ciscoasa# show mfib 239.1.1.77
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
(*,239.1.1.77) Flags: C K
Forwarding: 15/0/1271/0, Other: 0/0/0
outside Flags: A
inside Flags: F NS
Pkts: 0/15
(10.38.118.10,239.1.1.77) Flags: K
Forwarding: 7159/34/1349/360, Other: 0/0/0
outside Flags: A
inside Flags: F NS
Pkts: 7159/5
ciscoasa# show conn all | i 239.1.1.77
UDP outside 10.38.118.10:58944 inside 239.1.1.77:5004, idle 0:00:00, bytes 10732896, flags -
UDP outside 10.38.118.10:58945 inside 239.1.1.77:5005, idle 0:00:01, bytes 2752, flags -
UDP outside 10.38.118.10:58944 NP Identity Ifc 239.1.1.77:5004, idle 0:00:00, bytes 0, flags -
UDP outside 10.38.118.10:58945 NP Identity Ifc 239.1.1.77:5005, idle 0:00:01, bytes 0, flags -
Observação: quando o cliente fecha a aplicação cliente multicast, o host envia uma mensagem de Consulta IGMP.
Caso esse seja o único host conhecido pelo roteador como um cliente deseja receber o fluxo, o roteador envia uma mensagem IGMP Prune ao RP.
Operação do modo stub IGMP
- No modo stub IGMP, o ASA atua como um cliente multicast e gera ou encaminha relatórios IGMP (também conhecidos como "joins" IGMP) para roteadores adjacentes, para disparar a recepção de tráfego multicast
- Os roteadores enviam periodicamente consultas aos hosts para ver se algum nó na rede deseja continuar a receber o tráfego multicast.
- O modo stub IGMP não é recomendado porque o modo escasso PIM oferece muitos benefícios sobre o modo stub (com fluxos de tráfego multicast mais eficientes, capacidade de participar no PIM, etc.).
 |
Configuração do modo stub IGMP
1. Ative o roteamento multicast (modo de configuração global).
ASA(config)# multicast-routing
2. Na interface na qual o firewall recebe os relatórios igmp, configure o comando igmp forward-interface. Encaminhe os pacotes para fora da interface em direção à origem do fluxo. Neste exemplo, os receptores multicast são conectados diretamente à 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 a entrada de pacotes multicast na interface apropriada (necessário apenas se a política de segurança do ASA negar o tráfego multicast de entrada).
ASA(config)# access-list 105 extended permit ip any host 224.1.2.3 ASA(config)# access-group 105 in interface outside
Geralmente há confusão em torno dos diferentes comandos do submodo da interface IGMP e este diagrama descreve quando usar cada um:
 |
PIM Bidir
No PIM bidirecional, não há árvore compartilhada (SPT). Isso significa três coisas:
1. O roteador do primeiro salto (conectado ao remetente) não envia pacotes PIM Register ao RP.
2. O RP não envia mensagens PIM JOIN para se juntar à árvore de origem.
3. Os roteadores no caminho para o receptor enviam mensagens PIM join em direção ao RP para se unir ao RPT.
Isso significa que o ASA não gera um SPT (S,G) porque os dispositivos não participam do SPT. Todo o tráfego multicast passa pelo RP. O ASA encaminha todo o tráfego multicast, desde que haja um (*,G). Se não houver (*,G), isso significa que o ASA nunca recebeu um pacote de união PIM. Se esse for o caso, o ASA não deve encaminhar pacotes multicast.
Configuração do PIM Bidir
1. Ative o roteamento multicast (modo de configuração global).
ASA(config)# multicast-routing
2. Defina o endereço de ponto de reunião PIM.
ASA(config)# pim rp-address 172.18.123.3 bidir
3. Permita a entrada de pacotes multicast na interface apropriada (necessário somente se a política de segurança do ASA bloquear os pacotes multicast de entrada).
access-list 105 extended permit ip any host 224.1.2.3 access-group 105 in interface outside
Metodologia de Troubleshooting
Informações A Serem Coletadas Ao Solucionar Problemas De Multicast
Para compreender e diagnosticar completamente um problema de encaminhamento multicast no ASA, algumas ou todas essas informações são necessárias:
show mroute show mfib show pim neighbor show route show tech-support
capture cap1 interface outside match ip any host 239.1.1.77 >>> This captures the multicast traffic itself capture cappim1 interface inside match pim any any >>> This captures PIM Join/Prune messages capture capigmp interface inside match igmp any any >>> This captures IGMP Report/Query messages
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 IOS show mroute. O comando show mfib exibe o status de encaminhamento dos vários grupos multicast. É especialmente importante observar o contador de pacotes Forwarding, assim como Other (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
Capturas de pacotes
O utilitário integrado de captura de pacotes é muito útil para solucionar problemas de multicast. Neste exemplo, todos os pacotes de entrada na interface DMZ, destinados a 239.17.17.17, sã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 ....
A saída do comando show capture x detail mostra o TTL dos pacotes, o que é bastante útil. Nesta saída, o TTL do pacote é 1 (e o ASA passa esse pacote, já que ele não diminui o TTL dos pacotes IP por padrão), mas um roteador downstream descartaria os pacotes:
ASA# show cap capout detail
453 packets captured
...
1: 14:40:39.427147 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362
802.1Q vlan#1007 P0 10.4.2.95.1806 > 239.255.2.195.5000: [udp sum ok] udp 1316 (DF) [ttl 1] (id 0)
As capturas de pacotes também são úteis para capturar o tráfego PIM e IGMP. Esta captura 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#
Observe que o TTL dos pacotes pode ser visto com o comando 'show capture x detail'.
Aqui podemos ver as capturas de queda de ASP tomadas que mostram os pacotes multicast descartados e o motivo para as quedas (limite de taxa de punt):
ASA# show cap capasp det
12: 14:37:26.538332 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362
802.1Q vlan#1007 P0 10.76.4.95.1806 > 239.255.2.195.5000: [udp sum ok] udp 1316 (DF) [ttl 1] (id 0) Drop-reason: (punt-rate-limit) Punt rate limit exceeded
13: 14:37:26.538439 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362
802.1Q vlan#1007 P0 10.76.4.95.1806 > 239.255.2.195.5000: [udp sum ok] udp 1316 (DF) [ttl 1] (id 0) Drop-reason: (punt-rate-limit) Punt rate limit exceeded
Exemplo de implantação de multicast de modo escasso PIM ASA
Estes diagramas ilustram como o ASA interage com dispositivos vizinhos no modo escasso de PIM.
Entender a topologia da rede
Determine exatamente a localização dos remetentes e dos receptores do fluxo multicast específico. Além disso, determine o endereço IP do grupo multicast, bem como o local do ponto de encontro.
|
|
Nesse caso, os dados podem ser recebidos na interface externa do ASA e encaminhados para o 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 quando o cliente solicitar o recebimento do fluxo. O endereço IP do remetente é 192.168.1.50.
Verifique 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.
Verifique se o ASA envia uma mensagem de junção PIM em direção ao ponto de encontro
O ASA interpreta o relatório IGMP e gera uma mensagem de união PIM e, em seguida, envia-a pela interface em direção ao RP.
 |
Esta saída é de debug pim group 224.1.2.3 e mostra que o ASA envia 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.50
Verificar se o ASA recebe e encaminha o fluxo multicast
O ASA começa a receber tráfego multicast na interface externa (ilustrado pelas setas verdes) e a encaminhá-lo para os receptores na parte interna.
 |
Os comandos show mroute e show mfib, bem como as capturas de pacotes, podem ser usados para verificar se o ASA recebe e encaminha os pacotes multicast.
Uma conexão é criada na tabela de conexão 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 do ASA
O ASA falha ao enviar mensagens PIM para roteadores upstream devido ao HSRP
Quando esse problema é encontrado, o ASA não consegue enviar nenhuma mensagem PIM por uma interface. Este diagrama 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 comando 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 é disparado pela combinação da configuração da tabela de roteamento e da configuração de HSRP usada pelos vizinhos PIM.
A tabela de roteamento aponta para o IP 10.0.0.1 do HSRP como o dispositivo do próximo salto:
ciscoasa# show 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# show 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 PIM escasso não funciona com uma rota estática para um endereço 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 para 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 mroute estática no ASA para o tráfego em questão. Certifique-se de que ele aponte para um dos dois endereços IP da interface do roteador (10.0.0.2 ou 10.0.0.3). Nesse caso, esse comando permite que o ASA envie mensagens PIM direcionadas ao remetente multicast em 172.16.1.2:
ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 10.0.0.3
Uma vez feito isso, a tabela de roteamento multicast substitui a tabela de roteamento unicast do ASA, e o ASA envia as mensagens PIM diretamente ao vizinho 10.0.0.3.
O ASA ignora os relatórios 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 é gerada e o pacote é simplesmente descartado, e a recepção de fluxo falha.
 |
Para esse problema, o ASA ignora o pacote porque não é o roteador designado escolhido pelo PIM no segmento da LAN onde os clientes residem.
Esta saída da CLI do ASA mostra que um dispositivo diferente é o Roteador designado (indicado 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 é habilitado em todas as interfaces ASA quando o comando multicast-routing é adicionado à configuração. Se houver outros vizinhos PIM (outros roteadores ou ASAs) na interface interna do ASA (onde os clientes residem) e um desses vizinhos tiver sido escolhido porque o DR para esse segmento, os outros roteadores não DR descartarão os relatórios IGMP. A solução é desabilitar o PIM na interface (com o comando no pim na interface envolvida) ou tornar o ASA o DR para o segmento através do comando de interface pim dr-priority.
Os relatórios IGMP são negados pelo firewall quando o limite de interface IGMP é excedido
Por padrão, o ASA permite 500 junções ativas atuais (relatórios) rastreados em uma interface. Esse é o valor máximo configurável. Se um grande número de fluxos multicast for solicitado por clientes fora de uma interface, o máximo de 500 junções ativas pode ser encontrado, e o ASA pode ignorar relatórios IGMP de entrada adicionais dos receptores multicast.
Para confirmar se essa é a causa de uma falha de multicast, emita o comando 'show igmp interface interfacename' e procure as informações de 'IGMP limit' para a interface.
ASA# show igmp interface inside Hosting-DMZ is up, line protocol is up Internet address is 10.11.27.13/24 IGMP is enabled on interface Current IGMP version is 2 IGMP query interval is 125 seconds IGMP querier timeout is 255 seconds IGMP max query response time is 10 seconds Last member query response interval is 1 seconds Inbound IGMP access group is: IGMP limit is 500, currently active joins: 500 Cumulative IGMP activity: 7018 joins, 6219 leaves IGMP querying router is 10.11.27.13 (this system)
DEBUG - IGMP: Group x.x.x.x limit denied on outside
O ASA não consegue encaminhar o tráfego multicast no intervalo 232.x.x.x/8
Este intervalo de endereços deve ser usado com o Source Specific Multicast (SSM), para o qual o ASA não oferece suporte atualmente.
A saída do comando debug igmp mostra 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 eles não passam na verificação de segurança de Encaminhamento de Caminho Reverso (RPF). O RPF está habilitado 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 de 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. Esses descartes podem ser vistos 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
Uma opção é adicionar um mroute para o remetente do tráfego. Neste exemplo, 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 junção PIM na alternância de PIM para a árvore de origem
Inicialmente, os pacotes multicast PIM sparse-mode fluem 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 atinge um certo limiar, o roteador mais próximo do receptor multicast tenta receber tráfego ao longo da árvore específica da origem. Esse roteador gera uma nova junção PIM para o grupo e a envia para o remetente do fluxo multicast (e não para o RP, como antes).
O remetente do tráfego multicast pode residir em uma interface ASA diferente do RP. Quando o ASA recebe o PIM join para alternar para a árvore específica da 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 essa 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 mroute estática para o remetente do fluxo, que aponta para a interface ASA da qual o remetente reside.
O ASA descarta pacotes multicast porque o tempo de vida (TTL) foi excedido
Nesse caso, o tráfego multicast falha porque o TTL dos pacotes é 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 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 ícone Vídeo LAN O aplicativo cliente (um transmissor multicast popular e uma ferramenta de teste) define o TTL no pacote IP como 1 por padrão.
O ASA Experimenta Alto Uso Da CPU E Pacotes Ignorados Devido À Topologia De Multicast Específica
O ASA pode experimentar alta utilização da CPU e o fluxo de multicast pode experimentar quedas de pacotes se todas as afirmações a seguir forem verdadeiras com relação à topologia de multicast:
- O ASA atua como o RP.
- O ASA é o primeiro receptor de saltos do fluxo multicast. Isso significa que o remetente multicast está na mesma sub-rede IP que uma interface ASA.
- O ASA é o roteador do último salto do fluxo multicast. Isso significa que um receptor multicast está na mesma sub-rede IP que uma interface ASA.
Se todos os sintomas mencionados forem encontrados, devido a uma limitação de design, o ASA é forçado a processar o tráfego multicast do switch. Isso resulta em fluxos multicast de alta taxa de dados para experimentar quedas de pacotes. O contador de queda show asp que é incrementado quando esses pacotes são descartados é o limite de taxa de punt.
Para determinar se um ASA tem esse problema, conclua estas etapas:
Etapa 1: Verifique se o ASA é o RP:
show run pim show pim tunnel
Etapa 2: Verifique se o ASA é o roteador do último salto:
show igmp group <mcast_group_IP>
Etapa 3: Verifique se o ASA é o roteador do primeiro salto:
show mroute <mcast_group_IP>
Essas etapas podem ser executadas para atenuar esse problema:
- Modifique a topologia para que o ASA não seja o RP. Ou faça com que o emissor ou receptor não esteja diretamente conectado ao ASA
- Em vez de PIM, use IGMP stub-mode para encaminhamento de multicast.
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 mroute associada para encaminhar os pacotes. Enquanto a entrada está no processo de criação, alguns pacotes multicast podem ser descartados até que o mroute e as conexões tenham sido estabelecidas (normalmente isso leva menos de um segundo). Quando a configuração do fluxo multicast estiver concluída, os pacotes não serão mais limitados por taxa.
Os pacotes descartados por esse motivo têm o motivo de descarte ASP de "(limite de taxa de punt) Limite de taxa de punt excedido". Esta é a saída de 'show capture asp' (onde asp é uma captura de queda ASP configurada no ASA para capturar pacotes descartados) e você pode ver os pacotes multicast que foram descartados por este motivo:
ASA # show 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
Um Receptor Multicast De Desconexão Interrompe A Recepção Do Grupo Multicast Em Outras Interfaces
Somente os ASAs que operam no modo stub IGMP têm esse problema. Os ASAs que participam do roteamento multicast PIM não são afetados.
O problema é identificado pelo bug da Cisco ID CSCeg48235 
O IGMP Leave em uma interface interrompe o tráfego multicast 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 the 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, so their IGMP reports are 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 descarta pacotes multicast (de acordo com a política de segurança configurada). No entanto, é difícil para o administrador de rede identificar o motivo para as quedas de pacotes. Nesse caso, o ASA descarta pacotes devido à lista de acesso de saída configurada para uma interface. A solução é permitir o fluxo de multicast na lista de acesso de saída.
Quando isso ocorre, os pacotes multicast são descartados com o contador de queda ASP "FP no mcast output intrf (no-mcast-intrf)".
O ASA descarta continuamente alguns pacotes (mas não todos) em um fluxo multicast devido à limitação da taxa de ponto de controle
É mais provável que o tráfego tenha a taxa limitada pelo ponto de controle devido ao limite de taxa de punt. Examine a saída de queda e as capturas do asp para confirmar:
ASA# show asp drop Frame drop: Punt rate limit exceeded (punt-rate-limit) 1492520
ASA# show cap capasp det
12: 14:37:26.538332 c062.6baf.8dc3 0100.5e7f.02c3 0x8100 Length: 1362
802.1Q vlan#1007 P0 10.76.4.95.1806 > 239.255.2.195.5000: [udp sum ok] udp 1316 (DF) [ttl 1] (id 0) Drop-reason: (punt-rate-limit) Punt rate limit exceeded
A entrada mfib mostra que todo o tráfego é comutado por processo:
ASA(config)# show mfib 239.255.2.1195
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
(*,239.255.2.195) Flags: C K
Forwarding: 4278/50/1341/521, Other: 0/0/0
Outside-1007 Flags: A
RDEQ-to-Corporate Flags: F NS
Pkts: 0/4278 <---- HERE
A tabela de roteamento multicast mostra um (*,G) mas não (S,G).
ASA(config)# show mroute 239.255.2.1195
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, 239.255.2.195), 00:44:03/00:02:44, RP 10.1.135.10, flags: S
Incoming interface: Outside-1007
RPF nbr: 10.100.254.18
Immediate Outgoing interface list:
RDEQ-to-Corporate, Forward, 00:44:03/00:02:44
O problema aqui é que o TTL dos pacotes de dados multicast que chegam ao ASA é 1. O ASA está encaminhando esses pacotes para o dispositivo downstream (porque não diminui o TTL), mas o roteador downstream descarta os pacotes. Como resultado, o roteador downstream não envia uma junção PIM (S,G) (uma junção específica da origem) para o ASA em direção ao remetente. O ASA não cria uma entrada (S,G) até receber essa junção PIM. Como o (S,G) não é criado, todo o tráfego multicast é comutado por processo, o que resulta em limite de taxa.
A solução para esse problema é garantir que o TTL dos pacotes não seja 1, o que permite que o dispositivo downstream envie a junção específica da origem para o remetente; isso faz com que o ASA instale uma mroute específica da origem na tabela e, em seguida, todos os pacotes são comutados rapidamente (em vez de comutados processados) e o tráfego deve fluir pelo ASA sem problemas.
O fluxo multicast foi interrompido devido a uma mensagem PIM ASSERT
Se dois dispositivos de rede encaminharem os mesmos pacotes multicast para a mesma sub-rede, o ideal é que um deles pare de encaminhar os pacotes (já que é um desperdício duplicar o fluxo). Se os roteadores que executam o PIM detectarem que recebem os mesmos pacotes que também geram na mesma interface, eles gerarão mensagens ASSERT nessa LAN para selecionar qual dispositivo de rede para de encaminhar o fluxo.
Mais informações sobre esta mensagem podem ser vistas em uma seção do RFC 4601 relacionada ao processo ASSERT.
As depurações mostram que o ASA recebe um relatório IGMP para o grupo 239.1.1.227, mas ignora o relatório devido à mensagem de asserção que recebe de um roteador vizinho:
IPv4 PIM: (*,239.1.1.227) Periodic J/P scheduled in 50 secs IPv4 PIM: (*,239.1.1.227) J/P adding Join on outside IPv4 PIM: (10.99.41.205,239.1.1.227)RPT J/P adding Prune on outside IPv4 PIM: (10.99.41.253,239.1.1.227)RPT J/P adding Prune on outside IGMP: Received v2 Report on inside from 10.20.213.204 for 239.1.1.227 IGMP: Updating EXCLUDE group timer for 239.1.1.227 IPv4 PIM: (10.99.41.253,239.1.1.227) Received [15/110] Assert from 10.20.13.2 on inside IPv4 PIM: (10.99.41.253,239.1.1.227) Assert processing message wins IPv4 PIM: (10.99.41.253,239.1.1.227) inside Update assert timer (winner 10.20.13.2)
Esse problema foi observado em uma rede de produção onde dois locais foram acidentalmente ligados na camada 2, de modo que a LAN onde os receptores multicast estavam tinha dois dispositivos encaminhando tráfego multicast para eles. Devido a outro problema de rede, o ASA e outro dispositivo não puderam detectar um ao outro através de saudações PIM e, portanto, ambos assumiram a função de roteador designado para a LAN. Isso fez com que o tráfego multicast funcionasse por um tempo e falhasse quando as mensagens ASSERT fossem enviadas pelos dispositivos. Para resolver o problema, a conexão incorreta que ligava os dispositivos na camada 2 foi desativada e, em seguida, o problema foi resolvido.
O ASA envia PIM Join, mas não é processado pelo Vizinho devido ao tamanho do pacote maior que MTU
Isto foi observado em 629575899. O ASA foi configurado para Jumbo Frames e o 4900, não. Quando o cliente solicitou mais de 73 fluxos multicast, certos fluxos multicast não funcionariam. 73 SGs criariam uma mensagem PIM Join de tamanho 1494, que ainda estava dentro do MTU. 74SGs criariam uma mensagem PIM Join maior que 1500, o que fez com que o 4900M descartasse o pacote de entrada.
A correção para esse problema foi:
1. Verifique se os Jumbo Frames estão habilitados globalmente no 4900M
2. Configure a interface física e a SVI com uma MTU de 9216