Solución de problemas de multidifusión de ASA y problemas comunes
Contenido
Introducción
Este documento explica las funciones de multidifusión del dispositivo de seguridad adaptable (ASA), así como los posibles problemas que pueden surgir al utilizar la función.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
-
multidifusión ASA
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
Convenciones
Información sobre la Función
La Guía de Configuración de la Línea de Comandos de ASA describe la función de ruteo multicast y cómo configurarla:
http://www.cisco.com/en/US/docs/security/asa/asa90/configuration/guide/route_multicast.html
La multidifusión en el ASA se puede configurar en uno de dos modos:
-
Modo disperso PIM (preferido)
-
Modo Stub de IGMP (protocolo de administración de grupos de Internet, RFC 2236 IGMPv2)
El modo disperso de PIM es la opción preferida porque el ASA se comunica con los vecinos mediante un protocolo de routing multidifusión verdadero (PIM). El modo Stub de IGMP era la única opción de configuración multicast antes de que se lanzara la versión 7.0 de ASA, y funcionaba simplemente reenviando los informes IGMP recibidos de los clientes hacia los routers ascendentes.
Funcionamiento en modo disperso de PIM
-
El ASA admite el modo disperso PIM y el modo bidireccional PIM.
-
Los comandos PIM sparse-mode e IGMP stub-mode no deben configurarse simultáneamente.
-
Con el modo disperso de PIM, todo el tráfico de multidifusión fluye inicialmente al punto de encuentro (RP) y, a continuación, se reenvía hacia los receptores. Después de algún tiempo, el flujo multicast irá directamente desde el origen a los receptores (omitiendo el RP).
La siguiente imagen ilustra una implementación común en la que ASA tiene clientes multicast en una interfaz y vecinos PIM en otra:
Ejemplo de Configuración de PIM Sparse-Mode
Complete estos pasos:
-
Habilite el ruteo multicast (modo de configuración global).
ASA(config)# multicast-routing
-
Defina la dirección del punto de encuentro PIM.
ASA(config)# pim rp-address 172.18.123.3
-
Permita que los paquetes multicast ingresen la interfaz apropiada (necesaria sólo si la política de seguridad del ASA está bloqueando los paquetes multicast entrantes).
access-list 105 extended permit ip any host 224.1.2.3 access-group 105 in interface outside
Operación en modo Stub de IGMP
-
En el modo Stub de IGMP, el ASA actúa como cliente de multidifusión al generar o reenviar informes IGMP (también conocidos como "uniones" de IGMP) hacia los routers adyacentes, para activar la recepción del tráfico de multidifusión
-
Los routers enviarán periódicamente consultas a los hosts para ver si algún nodo de la red desea continuar recibiendo el tráfico multicast.
-
No se recomienda el modo Stub de IGMP porque el modo disperso de PIM ofrece muchas ventajas sobre el modo Stub (incluidos flujos de tráfico multicast más eficientes, capacidad de participar en PIM, etc).
La siguiente imagen ilustra el funcionamiento básico de un ASA configurado para el modo Stub de IGMP.
Configuración de Modo Stub de IGMP
Complete estos pasos:
-
Habilite el ruteo multicast (modo de configuración global).
ASA(config)# multicast-routing
-
En la interfaz en la que recibirá los informes igmp, configure el comando igmp forward-interface. Reenvíe los paquetes fuera de la interfaz hacia el origen del flujo. En el siguiente ejemplo, los receptores multicast están conectados directamente a la interfaz interna y el origen multicast está más allá de la interfaz 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 !
-
Permita que los paquetes multicast ingresen la interfaz apropiada (sólo es necesario si la política de seguridad del ASA niega el tráfico multicast entrante).
access-list 105 extended permit ip any host 224.1.2.3 access-group 105 in interface outside
A menudo hay confusión en torno a los diferentes comandos igmp interface sub-mode, y el siguiente diagrama intenta describir cuándo usar cada uno:
Metodología de solución de problemas
Información Que Se Debe Recopilar Al Resolver Problemas De Multidifusión
Para entender y diagnosticar completamente un problema de reenvío multicast en el ASA, es posible que se necesite parte o toda esta información:
-
Una descripción de la topología de red, incluida la ubicación de los remitentes, receptores y punto de encuentro de multidifusión.
-
La dirección IP de grupo específica que está utilizando el tráfico, así como los puertos y protocolos empleados.
-
Los registros del sistema generados por el ASA en el momento en que el flujo multicast tiene problemas.
-
Salida específica del comando show de la interfaz de línea de comandos ASA, que incluye:
show mroute show mfib show pim neighbor show route show tech-support
-
El paquete captura para mostrar si los datos de multidifusión llegan al ASA y si los paquetes se reenvían a través del ASA.
-
Capturas de paquetes que muestran paquetes IGMP y/o PIM.
-
Información de dispositivos de multidifusión adyacentes (routers) como "show mroute" y "show mfib".
-
El paquete captura y/o muestra comandos para determinar si el ASA está descartando los paquetes multicast. El comando 'show asp drop' se puede utilizar para determinar si el ASA está descartando los paquetes. Además, las capturas de paquetes del tipo 'asp-drop' se pueden utilizar para capturar todos los paquetes que descarta ASA y, a continuación, examinarlos para ver si los paquetes multicast están presentes en la captura de descarte.
Resultado útil del comando show
El resultado del comando show mroute muestra los diversos grupos y la información de reenvío, y es muy similar al comando show mroute del IOS. El comando show mfib muestra el estado de reenvío de los diversos grupos multicast. Es especialmente importante observar el contador de paquetes de reenvío, así como otro (que indica caídas):
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#
El comando clear mfib counters se puede utilizar para borrar los contadores, lo que es muy útil durante las pruebas:
ciscoasa# clear mfib counters ciscoasa#
Uso de Capturas de Paquetes para Capturar el Tráfico Multicast
La utilidad de captura de paquetes integrada del ASA es muy útil para resolver problemas de multidifusión. En el siguiente ejemplo, se capturarán todos los paquetes que lleguen a la interfaz DMZ del ASA, destinados a 239.17.17.17:
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 ....
Las capturas de paquetes también son útiles para capturar tráfico PIM e IGMP. La captura siguiente muestra que la interfaz interna ha recibido un paquete IGMP (protocolo IP 2) originado desde 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#
Ejemplo de implementación de multidifusión en modo disperso de ASA PIM
Los diagramas siguientes ilustran cómo el ASA interactúa con los dispositivos vecinos para que el tráfico multicast fluya con el modo disperso de PIM. En este ejemplo específico, el ASA recibe.
Introducción a la topología de red
Determine exactamente dónde residen el remitente y el receptor de la secuencia multicast específica que está probando. Además, determine la dirección IP del grupo multicast que se está utilizando, así como la ubicación del punto de encuentro.
En este caso, los datos deben recibirse en la interfaz exterior del ASA y reenviarse al receptor multicast en la interfaz interna. Debido a que el receptor se encuentra en la misma subred IP que la interfaz interna del ASA, espere ver un informe IGMP recibido en la interfaz interna del ASA cuando el cliente solicite recibir el flujo. La dirección IP del remitente es 192.168.1.50.
Verificación del ASA recibe el informe IGMP del receptor
En este ejemplo, el informe IGMP es generado por el receptor y procesado por el ASA.
Las capturas de paquetes y la salida de debug igmp se pueden utilizar para verificar que el ASA recibió y procesó exitosamente el mensaje IGMP.
Verificación del ASA envía un mensaje de unión PIM hacia el punto de encuentro
El ASA interpreta el informe IGMP y genera un mensaje de unión PIM y luego lo envía fuera de la interfaz hacia el RP.
El siguiente resultado es del grupo debug pim 224.1.2.3 y muestra el ASA enviando correctamente el mensaje de unión PIM. El remitente de la secuencia multicast es 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
Verificación de ASA recibe y reenvía el flujo multicast
El ASA comienza a recibir tráfico multicast en la interfaz exterior (ilustrado por las flechas verdes) y a reenviarlo a los receptores en el interior.
Los comandos show mroute y show mfib, así como las capturas de paquetes, se pueden utilizar para verificar que el ASA recibe y reenvía los paquetes multicast.
Se creará una conexión en la tabla de conexión del ASA para representar el flujo de multidifusión:
ciscoasa# show conn 59 in use, 29089 most used ... UDP outside:192.168.1.50/52075 inside:224.1.2.3/1234 flags - ...
Análisis de datos
Problemas Comunes
Esta sección proporciona una serie de problemas reales relacionados con la multidifusión ASA que los administradores de red han encontrado en el pasado.
El ASA No Puede Enviar Mensajes PIM Hacia Los Routers Ascendentes Debido A HSRP
Cuando se encuentra este problema, el ASA no puede enviar ningún mensaje PIM fuera de una interfaz. El siguiente diagrama muestra que el ASA no puede enviar mensajes PIM hacia el remitente, pero se puede ver el mismo problema cuando el ASA necesita enviar un mensaje PIM hacia el RP.
El resultado de debug pim muestra que el ASA no puede enviar el mensaje PIM al router ascendente de siguiente salto:
IPv4 PIM: Sending J/P to an invalid neighbor: outside 10.0.0.1
Este problema no es específico del ASA, y también afecta a los routers. El problema se desencadena por la combinación de la configuración de la tabla de ruteo del ASA y la configuración HSRP utilizada por los vecinos PIM.
La tabla de ruteo de ASA señala a la IP 10.0.0.1 de HSRP como dispositivo de salto siguiente:
ciscoasa# sh run route route outside 0.0.0.0 0.0.0.0 10.0.0.1 1
Sin embargo, la relación de vecino PIM se forma entre las direcciones IP de la interfaz física de los routers, y no la 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)
Consulte ¿Por qué el Modo Disperso PIM no Funciona con una Ruta Estática a una Dirección HSRP? para más información.
Un extracto del documento:
"¿Por qué el router no envía el mensaje Join/Prune? RFC 2362 establece que "un router envía un mensaje de Unión/Separación periódico a cada vecino RPF distinto asociado con cada entrada (S,G), (*,G) y (*,*,RP). Los mensajes de unión/separación se envían solamente si el vecino RPF es un vecino PIM."
Para mitigar el problema, agregue una entrada de ruta multicast estática en el ASA para el tráfico en cuestión. Asegúrese de que señala a una de las direcciones IP de la interfaz de los dos routers (10.0.0.2 o 10.0.0.3 en el ejemplo anterior). En este caso, el siguiente comando permite al ASA enviar mensajes PIM dirigidos al remitente multicast en 172.16.1.2:
ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 10.0.0.3
Una vez hecho esto, la tabla de ruteo multicast invalidará la tabla de ruteo unicast del ASA, y el ASA enviará los mensajes PIM directamente al vecino 10.0.0.3.
ASA Ignora Los Informes IGMP Porque No Es El Router Designado En El Segmento LAN
Para este problema, el ASA recibe un informe IGMP de un receptor multicast conectado directamente, pero lo ignora. No se generará ninguna salida de depuración y el paquete simplemente se descartará y la recepción del flujo falla.
Para este problema, el ASA ignora el paquete porque no es el router designado elegido por PIM en el segmento LAN donde residen los clientes.
El resultado de la CLI de ASA a continuación muestra que un dispositivo diferente es el router designado (indicado por "DR") en la red de interfaz 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)
De forma predeterminada, PIM se habilita en todas las interfaces ASA cuando el comando multicast-routing se agrega a la configuración del ASA. Si hay otros vecinos PIM (otros routers o ASA) en la interfaz interna del ASA (donde residen los clientes) y uno de esos vecinos fue elegido porque el DR para ese segmento, entonces otros routers no DR descartarán los informes IGMP. La solución es inhabilitar PIM en la interfaz de ASA (con el comando no pim en la interfaz involucrada), o hacer que ASA sea el DR para el segmento usando el comando pim dr-priority interface.
El ASA No Puede Reenviar El Tráfico Multicast En El Rango 232.x.x.x/8
Este intervalo de direcciones se utiliza con Source Specific Multicast (SSM) que el ASA no admite actualmente.
El resultado de debug igmp mostrará este error:
IGMP: Exclude report on inside ignored for SSM group 232.179.89.253
El ASA Descarta Paquetes Multicast Debido A La Verificación De Reenvío De Trayectoria Inversa
En este caso, el ASA recibe tráfico multicast en una interfaz, pero no se reenvía al receptor. Los paquetes son descartados por el ASA porque fallan en la verificación de seguridad Reverse Path Forwarding (RPF). El RPF está habilitado en todas las interfaces para el tráfico multicast y no se puede inhabilitar (para los paquetes unicast, la verificación no está activada de forma predeterminada y se habilita con el comando ip verify reverse-path interface).
Debido a la verificación RPF, cuando se recibe tráfico multicast en una interfaz, el ASA verifica que tiene una ruta de regreso al origen del tráfico multicast (verifica la tabla de ruteo de unidifusión y multidifusión) en esa interfaz. Si no tiene una ruta al remitente, descarta el paquete. Estas caídas pueden verse como un contador en la salida 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
Este problema se puede mitigar agregando una entrada específica de la tabla de ruteo multicast al ASA para el remitente del tráfico. En el siguiente ejemplo, el comando mroute se utiliza para satisfacer la verificación RPF del tráfico multicast originado en 172.16.1.2 recibido en la interfaz exterior:
ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 outside
El ASA no genera la unión de PIM en el PIM Switchover al árbol de origen
Inicialmente, los paquetes de multidifusión en modo disperso PIM fluirán del remitente multicast al RP, luego del RP al receptor a través de un árbol de multicast compartido. Sin embargo, una vez que la velocidad de bits agregada alcanza un cierto umbral, el router más cercano al receptor multicast intentará recibir tráfico a lo largo del árbol específico del origen. Este router generará una nueva unión PIM para el grupo y la enviará al remitente del flujo multicast (y no hacia el RP, como antes).
Según la topología de red, el remitente del tráfico multicast podría residir en una interfaz ASA diferente a la del RP. Cuando el ASA recibe la unión PIM para conmutar al árbol específico de origen, el ASA debe tener una ruta a la dirección IP del remitente. Si no se encuentra esta ruta, el paquete de unión PIM se descartará y se verá el siguiente mensaje en la salida de debug pim:
NO RPF Neighbor to send J/P
La solución para este problema es agregar una entrada de ruta multicast estática para el remitente del flujo, señalando la interfaz ASA de la cual reside el remitente.
ASA Descarta Los Paquetes Multicast Debido Al Tiempo De Vida (TTL) Excedido
En este caso, el tráfico multicast falla porque el TTL de los paquetes es demasiado bajo. Esto hace que el ASA, o algún otro dispositivo de la red, los descarte.
A menudo, los paquetes multicast tienen el valor TTL IP establecido muy bajo por la aplicación que los envió. A veces esto se hace de forma predeterminada para ayudar a garantizar que el tráfico multicast no se desplaza demasiado a través de la red. Por ejemplo, de forma predeterminada, la aplicación Video LAN Client (una herramienta de prueba y transmisor de multidifusión popular) establece el TTL en el paquete IP en 1 de forma predeterminada.
El ASA Experimenta Un Uso Elevado De La CPU Y Paquetes Descartados Debido A Una Topología Multicast Específica
El ASA podría experimentar una CPU alta y el flujo de multidifusión podría experimentar caídas de paquetes si todo lo siguiente es cierto con respecto a la topología de multidifusión:
-
El ASA actúa como RP.
-
El ASA es el primer receptor de salto del flujo multicast. Esto significa que el remitente multicast está en la misma subred IP que una interfaz ASA.
-
El ASA es el router de último salto del flujo multicast. Esto significa que un receptor multicast está en la misma subred IP que una interfaz ASA.
Si todo lo anterior es cierto, entonces debido a una limitación del diseño, el ASA se verá obligado a procesar el tráfico multicast del switch. Esto da como resultado flujos de multidifusión de alta velocidad de datos para experimentar caídas de paquetes. El contador show asp drop que aumenta cuando se descartan estos paquetes es punt-rate-limit.
Para determinar si un ASA está experimentando este problema, complete estos pasos:
Paso 1: Verifique si ASA es el RP usando los dos comandos:
show run pim show pim tunnel
Paso 2: Verifique si ASA es el router de último salto mediante este comando:
show igmp group <mcast_group_IP>
Paso 3: Verifique si ASA es el primer router de salto mediante este comando:
show mroute <mcast_group_IP>
Un Receptor Multicast Que Desconecta Interrumpe La Recepción Del Grupo Multicast En Otras Interfaces
Sólo los ASA que funcionan en modo Stub de IGMP experimentan este problema. Los ASA que participan en el ruteo de multidifusión PIM no se ven afectados.
El problema es identificado por el bug CSCeg48235 - IGMP: Detener la recepción del grupo rcvr interrumpe la recepción del grupo en otras interfaces
Esta es la nota de lanzamiento del error, que explica el 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.
El ASA descarta paquetes de multidifusión debido a la política de seguridad de la lista de acceso saliente
Con este problema específico, ASA está descartando correctamente los paquetes multicast (según la política de seguridad configurada). Sin embargo, es difícil para el administrador de la red identificar el motivo de las caídas de paquetes. En este caso, el ASA está descartando paquetes debido a la lista de acceso saliente configurada para una interfaz. La solución alternativa es permitir el flujo multicast en la lista de acceso saliente.
Cuando esto ocurra, se descartarán los paquetes multicast y el contador de descarte de ASP será "FP no mcast output intrf (no-mcast-intrf)".
El ASA Descarta Los Primeros Paquetes Cuando Se Inicia Un Flujo Multicast
Cuando los primeros paquetes de un flujo multicast llegan al ASA, el ASA debe construir esa conexión multicast particular y la entrada de ruta multicast asociada para reenviar los paquetes. Mientras se crea la entrada, algunos paquetes de multidifusión podrían descartarse hasta que se hayan establecido la ruta multicast y las conexiones (normalmente esto lleva menos de un segundo). Una vez finalizada la configuración del flujo multicast, los paquetes dejarán de estar limitados por la velocidad.
Los paquetes descartados por esta razón tendrán el motivo de caída de ASP "(punt-rate-limit) Punt rate limit ". A continuación se muestra el resultado de show capture asp (donde asp es una captura de descarte ASP configurada en el ASA para capturar los paquetes perdidos) y puede ver los paquetes multicast que fueron descartados por esta razón:
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
Información Relacionada
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)