Dépannage de multidiffusion ASA et problèmes courants

Introduction

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é.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Multidiffusion ASA

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations sur les fonctionnalités

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.

Fonctionnement du mode intermédiaire PIM

• 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 :

Exemple de configuration PIM Sparse-mode

Procédez comme suit :

1. Activez le routage de multidiffusion (mode de configuration globale).

   ASA(config)# multicast-routing

2. Définissez l'adresse du point de rendez-vous PIM.

   ASA(config)# pim rp-address 172.18.123.3

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

Fonctionnement du mode stub IGMP

• 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.

Configuration en mode stub IGMP

Procédez comme suit :

1. Activez le routage de multidiffusion (mode de configuration globale).

   ASA(config)# multicast-routing

2. 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
   !

3. 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 :

   

Méthodologie de dépannage

Informations à collecter lors du dépannage de problèmes de multidiffusion

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.

Sortie de commande show utile

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#

Utilisation des captures de paquets pour capturer le trafic de multidiffusion

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#

Exemple de déploiement de multidiffusion en mode intermédiaire ASA PIM

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 -
...

Analyse des données

Problèmes courants

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é.

L'ASA ne parvient pas à envoyer des messages PIM vers des routeurs en amont en raison de HSRP

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.

L'ASA ignore les rapports IGMP car il ne s'agit pas du routeur désigné sur le segment LAN

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.

L'ASA ne parvient pas à transférer le trafic de multidiffusion dans la plage 232.x.x.x/8

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

L'ASA abandonne les paquets de multidiffusion en raison du contrôle de transfert inverse du chemin

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

L'ASA ne génère pas de jointure PIM lors du basculement PIM vers l'arborescence source

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.

L'ASA abandonne les paquets de multidiffusion en raison du dépassement du délai de vie (TTL)

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 Fait L'Objet D'Une Utilisation Élevée Du CPU Et De Paquets Abandonnés En Raison D'Une Topologie Multicast Spécifique

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 :

1. L'ASA agit en tant que RP.

2. 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.

3. 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>

Un Récepteur De Multidiffusion Déconnecté Interrompt La Réception Du Groupe De Multidiffusion Sur D'Autres Interfaces

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.

L'ASA supprime les paquets de multidiffusion en raison de la stratégie de sécurité de la liste d'accès sortante

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)« .

L’ASA Abandonne Les Premiers Paquets Lorsqu’Un Flux Multidiffusion Est Démarré Pour La Première Fois.

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

Informations connexes

• Support et documentation techniques - Cisco Systems