Pour les partenaires
Vous êtes déjà partenaire?
ConnexionAvez-vous un compte?
Ce document explique les fonctionnalités de multidiffusion de l'ASA (Adaptive Security Appliance), ainsi que les problèmes potentiels pouvant être rencontrés lors de l'utilisation de la fonctionnalité.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Multidiffusion ASA
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Le Guide de configuration de la ligne de commande ASA présente la fonctionnalité de routage de multidiffusion et explique comment la configurer :
http://www.cisco.com/en/US/docs/security/asa/asa90/configuration/guide/route_multicast.html
La multidiffusion sur l'ASA peut être configurée dans l'un des deux modes suivants :
PIM sparse-mode (mode préféré)
Mode stub IGMP (Internet Group Management Protocol, RFC 2236 IGMPv2)
Le mode intermédiaire PIM est le choix préféré car l'ASA communique avec les voisins à l'aide d'un protocole de routage de multidiffusion (PIM) véritable. Le mode de stub IGMP était la seule option de configuration multicast avant la sortie de la version 7.0 d'ASA, et opéré en transférant simplement les rapports IGMP reçus des clients vers les routeurs en amont.
L'ASA prend en charge le mode intermédiaire PIM et le mode bidirectionnel PIM.
Les commandes PIM sparse-mode et IGMP stub-mode ne doivent pas être configurées simultanément.
Avec le mode intermédiaire PIM, tout le trafic de multidiffusion circule initialement vers le point de rendez-vous (RP), puis est transféré vers les récepteurs. Après un certain temps, le flux de multidiffusion va directement de la source aux récepteurs (contournant le RP).
L'image ci-dessous illustre un déploiement commun où l'ASA a des clients de multidiffusion sur une interface et des voisins PIM sur une autre :
Procédez comme suit :
Activez le routage de multidiffusion (mode de configuration globale).
ASA(config)# multicast-routing
Définissez l'adresse du point de rendez-vous PIM.
ASA(config)# pim rp-address 172.18.123.3
Autoriser les paquets de multidiffusion dans sur l'interface appropriée (nécessaire uniquement si la stratégie de sécurité de l'ASA bloque les paquets de multidiffusion entrants).
access-list 105 extended permit ip any host 224.1.2.3 access-group 105 in interface outside
En mode stub IGMP, l'ASA agit en tant que client de multidiffusion en générant ou en transmettant des rapports IGMP (également appelés « jointures » IGMP) vers des routeurs adjacents, pour déclencher la réception du trafic de multidiffusion
Les routeurs envoient régulièrement des requêtes aux hôtes pour voir si un noeud du réseau souhaite continuer à recevoir le trafic de multidiffusion.
Le mode stub IGMP n'est pas recommandé car le mode sparse PIM offre de nombreux avantages par rapport au mode stub (notamment des flux de trafic multicast plus efficaces, la possibilité de participer au mode PIM, etc.).
L'image ci-dessous illustre le fonctionnement de base d'un ASA configuré pour le mode stub IGMP.
Procédez comme suit :
Activez le routage de multidiffusion (mode de configuration globale).
ASA(config)# multicast-routing
Sur l'interface sur laquelle vous recevrez les rapports igmp, configurez la commande igmp forward-interface. Transférez les paquets de l'interface vers la source du flux. Dans l'exemple ci-dessous, les récepteurs de multidiffusion sont directement connectés à l'interface interne et la source de multidiffusion se trouve au-delà de l'interface externe.
! 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 !
Autoriser les paquets de multidiffusion dans sur l'interface appropriée (uniquement nécessaire si la stratégie de sécurité de l'ASA refuse le trafic de multidiffusion entrant).
access-list 105 extended permit ip any host 224.1.2.3 access-group 105 in interface outside
Souvent, il y a confusion autour des différentes commandes de sous-mode d'interface igmp, et le schéma ci-dessous tente de décrire quand utiliser chacune :
Afin de comprendre et de diagnostiquer complètement un problème de transfert de multidiffusion sur l'ASA, une partie ou la totalité de ces informations peuvent être nécessaires :
Description de la topologie du réseau, y compris l'emplacement des expéditeurs de multidiffusion, des récepteurs et du point de rendez-vous.
Adresse IP de groupe spécifique utilisée par le trafic, ainsi que les ports et les protocoles utilisés.
Syslogs généré par l'ASA au moment où le flux de multidiffusion rencontre des problèmes.
Sortie de commande show spécifique de l'interface de ligne de commande ASA, notamment :
show mroute show mfib show pim neighbor show route show tech-support
Captures de paquets pour indiquer si les données de multidiffusion arrivent sur l'ASA et si les paquets sont transférés via l'ASA.
Captures de paquets montrant les paquets IGMP et/ou PIM.
Informations provenant de périphériques de multidiffusion adjacents (routeurs) tels que show mroute et show mfib.
Les captures de paquets et/ou les commandes show permettent de déterminer si l'ASA abandonne les paquets de multidiffusion. La commande show asp drop peut être utilisée pour déterminer si l'ASA abandonne les paquets. En outre, des captures de paquets de type asp-drop peuvent être utilisées pour capturer tous les paquets que l'ASA abandonne, puis examinées pour voir si les paquets de multidiffusion sont présents dans la capture de goutte.
La sortie de la commande show mroute montre les différents groupes et les informations de transfert, et est très similaire à la commande show mroute IOS. La commande show mfib affiche l'état de transmission des différents groupes de multidiffusion. Il est particulièrement important d'observer le compteur de paquets Forwarding, ainsi que Other (qui indique des pertes) :
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#
La commande clear mfib counters peut être utilisée pour effacer les compteurs, ce qui est très utile lors du test :
ciscoasa# clear mfib counters ciscoasa#
L'utilitaire de capture de paquets intégré de l'ASA est très utile pour résoudre les problèmes de multidiffusion. Dans l'exemple ci-dessous, tous les paquets arrivant à l'interface DMZ de l'ASA, destinée à 239.17.17.17, seront capturés :
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 ....
Les captures de paquets sont également utiles pour capturer le trafic PIM et IGMP. La capture ci-dessous montre que l'interface interne a reçu un paquet IGMP (protocole IP 2) provenant 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#
Les diagrammes ci-dessous illustrent comment l'ASA interagit avec les périphériques voisins pour acheminer le trafic de multidiffusion avec le mode intermédiaire PIM. Dans cet exemple spécifique, l'ASA reçoit.
Compréhension de la topologie du réseau
Déterminez exactement où résident l'expéditeur et le récepteur du flux de multidiffusion spécifique que vous testez. Déterminez également l'adresse IP du groupe de multidiffusion utilisé, ainsi que l'emplacement du point de rendez-vous.
Dans ce cas, les données doivent être reçues à l'interface externe de l'ASA et transmises au récepteur de multidiffusion sur l'interface interne. Étant donné que le récepteur se trouve dans le même sous-réseau IP que l'interface interne de l'ASA, attendez-vous à voir un rapport IGMP reçu à l'interface interne de l'ASA lorsque le client demande à recevoir le flux. L'adresse IP de l'expéditeur est 192.168.1.50.
Vérification que l'ASA reçoit le rapport IGMP du récepteur
Dans cet exemple, le rapport IGMP est généré par le récepteur et traité par l'ASA.
Les captures de paquets et la sortie de debug igmp peuvent être utilisées pour vérifier que l'ASA a reçu et traité correctement le message IGMP.
Vérification que l'ASA envoie un message de jointure PIM vers le point de rendez-vous
L'ASA interprète le rapport IGMP et génère un message de jointure PIM, puis l'envoie par l'interface vers le RP.
Le résultat ci-dessous provient du groupe de débogage pim 224.1.2.3 et indique que l'ASA a réussi à envoyer le message de jointure PIM. L'expéditeur du flux multicast est 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
Vérification de la réception et du transfert du flux de multidiffusion par l'ASA
L'ASA commence à recevoir le trafic de multidiffusion sur l'interface externe (illustré par les flèches vertes) et à le transmettre aux récepteurs internes.
Les commandes show mroute et show mfib, ainsi que les captures de paquets, peuvent être utilisées pour vérifier que l'ASA reçoit et transfère les paquets de multidiffusion.
Une connexion sera créée dans la table de connexion de l'ASA pour représenter le flux de multidiffusion :
ciscoasa# show conn 59 in use, 29089 most used ... UDP outside:192.168.1.50/52075 inside:224.1.2.3/1234 flags - ...
Cette section présente une série de problèmes réels liés à la multidiffusion ASA que les administrateurs réseau ont rencontrés dans le passé.
Lorsque ce problème est rencontré, l'ASA ne parvient pas à envoyer de messages PIM à partir d'une interface. Le schéma ci-dessous montre que l'ASA ne peut pas envoyer de messages PIM vers l'expéditeur, mais le même problème peut être observé lorsque l'ASA doit envoyer un message PIM vers le RP.
La sortie de debug pim montre que l'ASA ne peut pas envoyer le message PIM au routeur de tronçon suivant en amont :
IPv4 PIM: Sending J/P to an invalid neighbor: outside 10.0.0.1
Ce problème n'est pas spécifique à l'ASA et affecte également les routeurs. Le problème est déclenché par la combinaison de la configuration de la table de routage de l'ASA et de la configuration HSRP utilisée par les voisins PIM.
La table de routage de l'ASA pointe vers l'adresse IP HSRP 10.0.0.1 en tant que périphérique de tronçon suivant :
ciscoasa# sh run route route outside 0.0.0.0 0.0.0.0 10.0.0.1 1
Cependant, la relation de voisinage PIM est formée entre les adresses IP de l'interface physique des routeurs, et non l'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)
Reportez-vous à Pourquoi le mode PIM Sparse ne fonctionne-t-il pas avec une route statique vers une adresse HSRP ? pour plus d'informations.
Extrait du document :
« Pourquoi le routeur n’envoie-t-il pas le message Joindre/Rentabiliser ? Le document RFC 2362 indique qu'« un routeur envoie un message Join/Prune périodique à chaque voisin RPF distinct associé à chaque entrée (S, G), (*, G) et (*,*, RP). Les messages Join/Prune sont envoyés uniquement si le voisin RPF est un voisin PIM. »
Afin d'atténuer le problème, ajoutez une entrée mroute statique sur l'ASA pour le trafic en question. Assurez-vous qu'il pointe vers l'une des adresses IP d'interface des deux routeurs (10.0.0.2 ou 10.0.0.3 dans l'exemple ci-dessus). Dans ce cas, la commande suivante permet à l'ASA d'envoyer des messages PIM dirigés vers l'expéditeur de multidiffusion à l'adresse 172.16.1.2 :
ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 10.0.0.3
Une fois cela fait, la table de routage de multidiffusion remplace la table de routage de monodiffusion de l'ASA et l'ASA envoie les messages PIM directement au voisin 10.0.0.3.
Pour ce problème, l'ASA reçoit un rapport IGMP d'un récepteur de multidiffusion directement connecté, mais il l'ignore. Aucune sortie de débogage ne sera générée et le paquet est simplement abandonné, et la réception du flux échoue.
Pour ce problème, l'ASA ignore le paquet car il ne s'agit pas du routeur désigné choisi par le PIM sur le segment LAN où résident les clients.
Le résultat de l'interface de ligne de commande ASA ci-dessous montre qu'un autre périphérique est le routeur désigné (désigné par le DR) sur le réseau d'interface interne :
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)
Par défaut, PIM est activé sur toutes les interfaces ASA lorsque la commande multicast-routing est ajoutée à la configuration ASA. S'il y a d'autres voisins PIM (d'autres routeurs ou ASA) sur l'interface interne de l'ASA (où résident les clients) et que l'un de ces voisins a été sélectionné parce que le routeur désigné pour ce segment, alors d'autres routeurs non DR supprimeront les rapports IGMP. La solution consiste à désactiver PIM sur l'interface de l'ASA (avec la commande no pim sur l'interface concernée), ou à faire de l'ASA le DR pour le segment à l'aide de la commande pim dr-priority interface.
Cette plage d'adresses est utilisée avec le SSM (Source Specific Multicast) que l'ASA ne prend pas actuellement en charge.
La sortie de debug igmp montrera cette erreur :
IGMP: Exclude report on inside ignored for SSM group 232.179.89.253
Dans ce cas, l'ASA reçoit le trafic de multidiffusion sur une interface, mais il n'est pas transféré au récepteur. Les paquets sont abandonnés par l'ASA parce qu'ils échouent à la vérification de sécurité de Reverse Path Forwarding (RPF). Le RPF est activé sur toutes les interfaces pour le trafic de multidiffusion et ne peut pas être désactivé (pour les paquets de monodiffusion, la vérification n'est pas activée par défaut et est activée avec la commande ip verify inverpath interface).
En raison du contrôle RPF, lorsque le trafic de multidiffusion est reçu sur une interface, l'ASA vérifie qu'il dispose d'une route vers la source du trafic de multidiffusion (il vérifie la table de routage de monodiffusion et de multidiffusion) sur cette interface. S'il n'a pas de route vers l'expéditeur, il abandonne le paquet. Ces gouttes peuvent être vues comme un compteur dans la sortie 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
Ce problème peut être atténué en ajoutant une entrée de table de routage de multidiffusion spécifique à l'ASA pour l'expéditeur du trafic. Dans l'exemple ci-dessous, la commande mroute est utilisée pour satisfaire le contrôle RPF pour le trafic de multidiffusion provenant de 172.16.1.2 reçu sur l'interface externe :
ciscoasa(config)# mroute 172.16.1.2 255.255.255.255 outside
Initialement, les paquets de multidiffusion en mode intermédiaire PIM vont circuler de l'expéditeur de multidiffusion vers le RP, puis du RP vers le récepteur via une arborescence de multidiffusion partagée. Cependant, une fois que le débit binaire agrégé atteint un certain seuil, le routeur le plus proche du récepteur de multidiffusion tente de recevoir le trafic le long de l'arborescence spécifique à la source. Ce routeur génère une nouvelle jointure PIM pour le groupe et l'envoie à l'expéditeur du flux de multidiffusion (et non vers le RP, comme précédemment).
Selon la topologie du réseau, l'expéditeur du trafic de multidiffusion peut résider sur une interface ASA différente de celle du RP. Lorsque l'ASA reçoit la jointure PIM pour basculer vers l'arborescence spécifique à la source, l'ASA doit avoir une route vers l'adresse IP de l'expéditeur. Si cette route est introuvable, le paquet de jointure PIM est abandonné et le message suivant apparaît dans la sortie de debug pim :
NO RPF Neighbor to send J/P
La solution à ce problème est d'ajouter une entrée de mroute statique pour l'expéditeur du flux, en pointant l'interface ASA sur laquelle réside l'expéditeur.
Dans ce cas, le trafic de multidiffusion échoue car la durée de vie des paquets est trop faible. L'ASA, ou un autre périphérique du réseau, est ainsi amené à les abandonner.
Souvent, les paquets de multidiffusion ont une valeur de durée de vie IP très faible définie par l'application qui les a envoyés. Cette opération est parfois effectuée par défaut pour garantir que le trafic de multidiffusion ne va pas trop loin sur le réseau. Par exemple, par défaut, l'application Video LAN Client (un émetteur multidiffusion populaire et un outil de test) définit la durée de vie du paquet IP sur 1 par défaut.
L'ASA peut connaître un CPU élevé et le flux de multidiffusion peut connaître des pertes de paquets si toutes les informations suivantes sont vraies sur la topologie de multidiffusion :
L'ASA agit en tant que RP.
L'ASA est le premier récepteur de saut du flux de multidiffusion. Cela signifie que l'expéditeur de multidiffusion se trouve dans le même sous-réseau IP et dans une interface ASA.
L'ASA est le dernier routeur de saut du flux de multidiffusion. Cela signifie qu'un récepteur de multidiffusion se trouve dans le même sous-réseau IP qu'une interface ASA.
Si tous les éléments ci-dessus sont vrais, alors en raison d'une limitation de conception, l'ASA sera forcé de traiter le commutateur du trafic de multidiffusion. Cela entraîne des flux de multidiffusion à haut débit de données pour connaître des pertes de paquets. La commande show asp drop counter qui s'incrémente lorsque ces paquets sont abandonnés est punt-rate-limit.
Afin de déterminer si un ASA rencontre ce problème, procédez comme suit :
Étape 1 : Vérifiez si l'ASA est le RP à l'aide des deux commandes suivantes :
show run pim show pim tunnel
Étape 2 : Vérifiez si l’ASA est le dernier routeur de saut à l’aide de cette commande :
show igmp group <mcast_group_IP>
Étape 3 : Vérifiez si l’ASA est le premier routeur de saut à l’aide de cette commande :
show mroute <mcast_group_IP>
Seuls les ASA fonctionnant en mode stub IGMP rencontrent ce problème. Les ASA qui participent au routage de multidiffusion PIM ne sont pas affectés.
Le problème est identifié par le bogue CSCeg48235 - IGMP : L'arrêt du groupe rcvr interrompt la réception du groupe sur d'autres interfaces
Voici la note de publication du bogue, qui explique le problème :
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.
Avec ce problème spécifique, l'ASA supprime correctement les paquets de multidiffusion (conformément à la stratégie de sécurité configurée). Cependant, il est difficile pour l’administrateur réseau d’identifier la raison des abandons de paquets. Dans ce cas, l'ASA abandonne les paquets en raison de la liste d'accès sortante configurée pour une interface. La solution de contournement consiste à autoriser le flux de multidiffusion dans la liste d'accès sortante.
Dans ce cas, les paquets de multidiffusion seront supprimés et le compteur de pertes ASP sera « FP no mcast output intrf (no-mcast-intrf)« .
Lorsque les premiers paquets d'un flux de multidiffusion arrivent à l'ASA, l'ASA doit créer cette connexion de multidiffusion particulière et l'entrée mroute associée pour transférer les paquets. Pendant la création de l'entrée, certains paquets de multidiffusion peuvent être abandonnés jusqu'à ce que la route et les connexions aient été établies (généralement, cela prend moins d'une seconde). Une fois la configuration du flux multicast terminée, les paquets ne seront plus limités en débit.
Les paquets abandonnés pour cette raison auront la raison de suppression ASP de "(punt-rate-limit) Punt rate limit limit dépassée ». Ci-dessous se trouve le résultat de show capture asp (où asp est une capture de suppression ASP configurée sur l'ASA pour capturer les paquets abandonnés) et vous pouvez voir les paquets de multidiffusion qui ont été abandonnés pour cette raison :
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