Dépannage de Firepower Threat Defense IGMP et des bases de la multidiffusion

Options de téléchargement

PDF (3.2 MB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
ePub (3.0 MB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (1.8 MB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:19 mai 2022

ID du document:217891

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Configurer

Notions de base IGMP

Tâche 1 - Trafic multidiffusion sur le plan de contrôle

Tâche 2 : configuration de la multidiffusion de base

IGMP Snooping

Tâche 3 : groupe IGMP statique et groupe IGMP de jointure

igmp static-group

igmp join-group

Tâche 4 : configuration du routage multidiffusion de stub IGMP

Problèmes identifiés

Filtrer le trafic multidiffusion sur les zones de destination

Les rapports IGMP sont refusés par le pare-feu lorsque la limite d'interface IGMP est dépassée

Le pare-feu ignore les rapports IGMP pour la plage d'adresses 232.x.x.x/8

Informations connexes

Introduction

Ce document décrit les bases de la multidiffusion et comment Firepower Threat Defense (FTD) implémente le protocole IGMP (Internet Group Management Protocol).

Conditions préalables

Exigences

Connaissances de base du routage IP.

Composants utilisés

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Le contenu de cet article s'applique également au logiciel ASA (Adaptive Security Appliance).

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

Cisco Firepower 4125 Threat Defense Version 7.1.0.
Firepower Management Center (FMC) version 7.1.0.
ASA version 9.19.1.

Informations générales

Définitions

Monodiffusion = d'un hôte unique vers un autre hôte (un vers un).
Diffusion = d’un hôte unique vers TOUS les hôtes possibles (un vers tous).
Multidiffusion = d'un hôte d'un groupe d'hôtes vers un groupe d'hôtes (un-à-plusieurs ou plusieurs-à-plusieurs).
Anycast = d'un hôte vers l'hôte le plus proche d'un groupe (un-à-un-parmi-plusieurs).

Notions de base

La RFC 988 multidiffusion a été écrite en 1986 par Steve Deering.
La multidiffusion IPv4 utilise la plage 224.0.0.0/4 (4 premiers bits 110) - 224.0.0.0 - 239.255.255.255.
Pour IPv4, l'adresse MAC de couche 2 provient de l'adresse IP de multidiffusion de couche 3 : 01005e (24 bits) + 25^e bit toujours 0 + 23 bits inférieurs de l'adresse IPv4 de multidiffusion.
La multidiffusion IPv6 utilise la plage FF00::/8 et elle est plus flexible que la multidiffusion IPv4 car elle peut intégrer l'IP Rendezvous Point (RP).
Pour IPv6, l'adresse MAC de couche 2 provient de la multidiffusion de couche 3 : 333 + 32 bits inférieurs de l'adresse IPv6 de multidiffusion.
Avantages de la multidiffusion : efficacité grâce à une charge réduite sur la source. Les performances, car elles évitent la duplication ou l'inondation du trafic.
Inconvénients de la multidiffusion : transport non fiable (basé sur UDP), pas d'évitement d'encombrement, livraison hors séquence.
La multidiffusion n'est pas prise en charge sur l'Internet public, car elle nécessite tous les périphériques du chemin pour l'activer. Généralement utilisé lorsque tous les périphériques sont sous une autorité administrative commune.
Applications de multidiffusion standard : flux vidéo interne, vidéoconférence.

Multidiffusion et monodiffusion répliquée

Dans la monodiffusion répliquée, la source crée plusieurs copies du même paquet de monodiffusion (réplicas) et les envoie à plusieurs hôtes de destination. La multidiffusion déplace la charge de l’hôte source vers le réseau, tandis que dans la monodiffusion répliquée, tout le travail est effectué sur l’hôte source.

Configurer

Notions de base IGMP

IGMP est le « langage » parlé entre les récepteurs de multidiffusion et le périphérique L3 local (généralement un routeur).
IGMP est un protocole de couche 3 (comme ICMP) et utilise le protocole IP numéro 2.
Il existe actuellement 3 versions IGMP. La version par défaut d'IGMP sur le pare-feu est la version 2. Seules les versions 1 et 2 sont actuellement prises en charge.
Entre IGMPv1 et IGMPv2, les principales différences sont les suivantes :

IGMPv1 n'a pas de message Leave Group.
IGMPv1 n'a pas de requête spécifique au groupe (utilisée par le pare-feu lorsqu'un hôte quitte un groupe de multidiffusion).
IGMPv1 n'a pas de processus de sélection de demandeur.

IGMPv3 n'est pas actuellement pris en charge sur ASA/FTD, mais comme référence, la différence importante entre IGMPv2 et IGMPv3 est l'inclusion d'une requête spécifique au groupe et à la source dans IGMPv3 qui est utilisée dans la multidiffusion spécifique à la source (SSM).
Requêtes IGMPv1/IGMPv2/IGMPv3 = 224.0.0.1
IGMPv2 Leave = 224.0.0.2
Rapport d'adhésion IGMPv3 = 224.0.0.22
Si un hôte veut rejoindre peut envoyer un message non sollicité de rapport d'adhésion IGMP :

igmp_membership

Du point de vue du pare-feu, il existe 2 types de requêtes IGMP : les requêtes générales et les requêtes spécifiques à un groupe
Lorsque le pare-feu reçoit un message IGMP Leave Group, il doit vérifier s'il y a d'autres membres de ce groupe sur le sous-réseau. Pour cette raison, le pare-feu envoie une requête spécifique au groupe :

igmp_membership_specific

Sur les sous-réseaux où il y a plusieurs routeurs/pare-feu, un demandeur (un périphérique qui envoie toutes les requêtes IGMP) est sélectionné :

firepower# show igmp interface INSIDE
INSIDE is up, line protocol is up
  Internet address is 192.168.1.97/24
  IGMP is enabled on interface
  Current IGMP version is 2
  IGMP query interval is 125 seconds
  IGMP querier timeout is 60 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: 2
  Cumulative IGMP activity: 21 joins, 20 leaves
  IGMP querying router is 192.168.1.97 (this system)  <-- IGMP querier

Sur FTD, comme un ASA classique, vous pouvez activer debug igmp pour voir les messages relatifs à IGMP :

firepower# debug igmp
IGMP debugging is on
IGMP: Received v2 Query on DMZ from 192.168.6.1
IGMP: Received v2 Report on INSIDE from 192.168.1.50 for 239.255.255.250   <-- Received an IGMP packet
IGMP: group_db: add new group 239.255.255.250 on INSIDE
IGMP: MRIB updated (*,239.255.255.250) : Success
IGMP: Switching to EXCLUDE mode for 239.255.255.250 on INSIDE
IGMP: Updating EXCLUDE group timer for 239.255.255.250
IGMP: Received v2 Report on INSIDE from 192.168.1.50 for 230.10.10.10
IGMP: group_db: add new group 230.10.10.10 on INSIDE
IGMP: MRIB updated (*,230.10.10.10) : Success
IGMP: Switching to EXCLUDE mode for 230.10.10.10 on INSIDE
IGMP: Updating EXCLUDE group timer for 230.10.10.10
IGMP: Send v2 general Query on INSIDE
IGMP: Received v2 Query on INSIDE from 192.168.1.97
IGMP: Send v2 general Query on OUTSIDE
IGMP: Received v2 Query on OUTSIDE from 192.168.103.91
IGMP: Received v2 Report on INSIDE from 192.168.1.50 for 239.255.255.250
IGMP: Updating EXCLUDE group timer for 239.255.255.250
IGMP: Received v2 Report on INSIDE from 192.168.1.50 for 230.10.10.10
IGMP: Updating EXCLUDE group timer for 230.10.10.10

Un hôte quitte normalement un groupe de multidiffusion avec un message Leave Group (IGMPv2).

igmp_leave

Tâche 1 - Trafic multidiffusion sur le plan de contrôle

OSPF_topology

Configurez un OSPFv2 et un OSPFv3 entre le FTD et l'ASA. Vérifiez comment les deux périphériques gèrent le trafic de multidiffusion de couche 2 et de couche 3 généré par OSPF.

Solution

Configuration OSPFv2

ospf_config_ftd

ospf_config_interface

De même, pour OSPFv3

Configuration sur CLI FTD :

router ospf 1
 network 192.168.103.0 255.255.255.0 area 0
 log-adj-changes
!
ipv6 router ospf 1
 no graceful-restart helper
 log-adjacency-changes
!
interface Ethernet1/4
nameif OUTSIDE
security-level 0
ip address 192.168.103.91 255.255.255.0
ipv6 address fc00:103::91/64
ospf authentication null
ipv6 ospf 1 area 0

La configuration crée ces entrées dans les tables d'autorisation FTD du chemin de sécurité accéléré (ASP) afin que le trafic de multidiffusion entrant ne soit pas bloqué :

firepower# show asp table classify domain permit
...
in id=0x14f922db85f0, priority=13, domain=permit, deny=false         <-- permit the packets
        hits=1, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=89
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=224.0.0.5, mask=255.255.255.255, port=0, tag=any, dscp=0x0, nsg_id=none     <-- OSPF for IPv4
        input_ifc=OUTSIDE(vrfid:0), output_ifc=identity(vrfid:0)     <-- ingress interface
in id=0x14f922db9350, priority=13, domain=permit, deny=false         <-- permit the packets
        hits=0, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=89
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=224.0.0.6, mask=255.255.255.255, port=0, tag=any, dscp=0x0, nsg_id=none     <-- OSPF for IPv4
        input_ifc=OUTSIDE(vrfid:0), output_ifc=identity(vrfid:0)     <-- ingress interface

Pour IPv6 :

...
in id=0x14f923fb16f0, priority=13, domain=permit, deny=false      <-- permit the packets
        hits=1, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=89
        src ip/id=::/0, port=0, tag=any
        dst ip/id=ff02::5/128, port=0, tag=any, , nsg_id=none     <-- OSPF for IPv6
        input_ifc=OUTSIDE(vrfid:0), output_ifc=identity(vrfid:0)  <-- ingress interface
in id=0x14f66e9d4780, priority=13, domain=permit, deny=false      <-- permit the packets
        hits=0, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=89
        src ip/id=::/0, port=0, tag=any
        dst ip/id=ff02::6/128, port=0, tag=any, , nsg_id=none     <-- OSPF for IPv6
        input_ifc=OUTSIDE(vrfid:0), output_ifc=identity(vrfid:0)  <-- ingress interface
...

Les contiguïtés OSPFv2 et OSPFv3 sont UP :

firepower# show ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.103.50 1 FULL/BDR 0:00:35 192.168.103.50 OUTSIDE   <-- OSPF neighbor is up

firepower# show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
192.168.103.50 1 FULL/BDR 0:00:34 3267035482 OUTSIDE       <-- OSPF neighbor is up

Voici les sessions OSPF de multidiffusion terminées vers le boîtier :

firepower# show conn all | include OSPF
OSPF OUTSIDE fe80::2be:75ff:fef6:1d8e NP Identity Ifc ff02::5, idle 0:00:09, bytes 5924, flags
OSPF OUTSIDE 192.168.103.50 NP Identity Ifc 224.0.0.5, idle 0:00:03, bytes 8904, flags
OSPF OUTSIDE ff02::5 NP Identity Ifc fe80::f6db:e6ff:fe33:442e, idle 0:00:01, bytes 6304, flags
OSPF OUTSIDE 224.0.0.5 NP Identity Ifc 192.168.103.91, idle 0:00:00, bytes 25220, flags

À titre de test, activez la capture pour IPv4 et effacez les connexions au périphérique :

firepower# capture CAP interface OUTSIDE trace
firepower# clear conn all
12 connection(s) deleted.
firepower# clear capture CAP
firepower# !

Avertissement : ceci provoque une panne ! L'exemple est présenté à des fins de démonstration uniquement !

Les paquets OSPF capturés :

firepower# show capture CAP | include proto-89
1: 12:25:33.142189 192.168.103.50 > 224.0.0.5 ip-proto-89, length 60
2: 12:25:33.702691 192.168.103.91 > 224.0.0.5 ip-proto-89, length 60
7: 12:25:36.317000 192.168.206.100 > 224.0.0.5 ip-proto-89, length 56
8: 12:25:36.952587 fe80::2be:75ff:fef6:1d8e > ff02::5 ip-proto-89 40 [flowlabel 0xe] [hlim 1]
12: 12:25:41.282608 fe80::f6db:e6ff:fe33:442e > ff02::5 ip-proto-89 40 [flowlabel 0xe] [hlim 1]

Voici comment le paquet de multidiffusion OSPFv2 est géré par le pare-feu :

firepower# show capture CAP packet-number 1 trace
115 packets captured

1: 12:25:33.142189 192.168.103.50 > 224.0.0.5 ip-proto-89, length 60    <-- The first packet of the flow
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 6344 ns
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 6344 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: No ECMP load balancing
Result: ALLOW
Elapsed time: 10736 ns
Config:
Additional Information:
Destination is locally connected. No ECMP load balancing.
Found next-hop 192.168.103.50 using egress ifc OUTSIDE(vrfid:0)

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 5205 ns
Config:
Implicit Rule
Additional Information:

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 5205 ns
Config:
Additional Information:

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 5205 ns
Config:
Additional Information:

Phase: 7
Type: CLUSTER-REDIRECT
Subtype: cluster-redirect
Result: ALLOW
Elapsed time: 29280 ns
Config:
Additional Information:

Phase: 8
Type: MULTICAST
Subtype:
Result: ALLOW
Elapsed time: 976 ns
Config:
Additional Information:

Phase: 9                     
Type: OSPF                   <-- The OSPF process
Subtype: ospf
Result: ALLOW
Elapsed time: 488 ns
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Elapsed time: 13176 ns
Config:
Additional Information:
New flow created with id 620, packet dispatched to next module

Result:
input-interface: OUTSIDE(vrfid:0)
input-status: up
input-line-status: up
output-interface: OUTSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: allow
Time Taken: 82959 ns

Voici comment le paquet de multidiffusion OSPFv3 est géré par le pare-feu :

firepower# show capture CAP packet-number 8 trace
274 packets captured

8: 12:25:36.952587 fe80::2be:75ff:fef6:1d8e > ff02::5 ip-proto-89 40 [flowlabel 0xe] [hlim 1]  <-- The first packet of the flow
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 7564 ns
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 7564 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: No ECMP load balancing
Result: ALLOW
Elapsed time: 8296 ns
Config:
Additional Information:
Destination is locally connected. No ECMP load balancing.
Found next-hop ff02::5 using egress ifc identity(vrfid:0)

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 8784 ns
Config:
Implicit Rule
Additional Information:

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 8784 ns
Config:
Additional Information:

Phase: 6
Type: CLUSTER-REDIRECT
Subtype: cluster-redirect
Result: ALLOW
Elapsed time: 27816 ns
Config:
Additional Information:

Phase: 7
Type: OSPF                    <-- The OSPF process
Subtype: ospf
Result: ALLOW
Elapsed time: 976 ns
Config:
Additional Information:

Phase: 8
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Elapsed time: 13664 ns
Config:
Additional Information:
New flow created with id 624, packet dispatched to next module

Result:
input-interface: OUTSIDE(vrfid:0)
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
Action: allow
Time Taken: 83448 ns

Tâche 2 : configuration de la multidiffusion de base

Topologie

Exigence

Configurez le pare-feu de sorte que le trafic de multidiffusion provenant du serveur soit transmis au client de multidiffusion sur IP 230.10.10.10

Solution

Du point de vue du pare-feu, la configuration minimale consiste à activer le routage de multidiffusion globalement. Cela active en arrière-plan les protocoles IGMP et PIM sur toutes les interfaces de pare-feu.

Sur l'interface utilisateur FMC :

enable_ftd_multicast

Sur l'interface de ligne de commande du pare-feu, voici la configuration poussée :

firepower# show run multicast-routing
multicast-routing                   <-- Multicast routing is enabled

Vérification IGMP

firepower# show igmp interface
diagnostic is up, line protocol is up
  Internet address is 0.0.0.0/0
  IGMP is disabled on interface
INSIDE is up, line protocol is up          <-- The interface is UP
  Internet address is 192.168.1.24/24
  IGMP is enabled on interface             <-- IGMP is enabled on the interface
  Current IGMP version is 2                <-- IGMP version
  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: 1
  Cumulative IGMP activity: 4 joins, 3 leaves
  IGMP querying router is 192.168.1.24 (this system)
OUTSIDE is up, line protocol is up         <-- The interface is UP
  Internet address is 192.168.103.91/24
  IGMP is enabled on interface             <-- IGMP is enabled on the interface
  Current IGMP version is 2                <-- IGMP version
  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: 1
  Cumulative IGMP activity: 1 joins, 0 leaves
  IGMP querying router is 192.168.103.91 (this system)

firepower# show igmp group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
239.255.255.250 INSIDE 00:09:05 00:03:19 192.168.1.50
239.255.255.250 OUTSIDE 00:06:01 00:02:33 192.168.103.60

firepower# show igmp traffic
IGMP Traffic Counters
Elapsed time since counters cleared: 03:40:48 Received Sent

                              Received     Sent
Valid IGMP Packets            21           207
Queries                       0            207
Reports                       15           0       <-- IGMP Reports received and sent
Leaves                        6            0
Mtrace packets                0            0
DVMRP packets                 0            0
PIM packets                   0            0

Errors:
Malformed Packets             0
Martian source                0
Bad Checksums                 0

Vérification PIM

firepower# show pim interface

Address          Interface          PIM  Nbr   Hello  DR         DR
                                       Count Intvl  Prior

0.0.0.0          diagnostic         off  0     30     1          not elected
192.168.1.24     INSIDE             on   0     30     1          this system
192.168.103.91   OUTSIDE            on   0     30     1          this system

Vérification MFIB

firepower# 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.0.1.39) Flags: S K
   Forwarding: 0/0/0/0, Other: 0/0/0   <-- The Forwarding counters are: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
(*,224.0.1.40) Flags: S K
   Forwarding: 0/0/0/0, Other: 8/8/0   <-- The Other counters are: Total/RPF failed/Other drops
(*,232.0.0.0/8) Flags: K
   Forwarding: 0/0/0/0, Other: 0/0/0

Trafic de multidiffusion via le pare-feu

Dans ce cas, l'application de lecteur multimédia VLC est utilisée comme serveur de multidiffusion et comme client pour tester le trafic de multidiffusion :

multicast_through_ftd

Configuration du serveur de multidiffusion VLC :

vlc_stream

vlc_add_file

Dans l'écran suivant, sélectionnez Suivant.

Sélectionnez le format :

vlc_add_method

Spécifiez l'adresse IP et le port de multidiffusion :

vlc_add_ip

vlc_enable

Activez les captures LINA sur le pare-feu FTD :

firepower# capture INSIDE interface INSIDE match ip host 192.168.103.60 host 230.10.10.10
firepower# capture OUTSIDE interface OUTSIDE trace match ip host 192.168.103.60 host 230.10.10.10

Sélectionnez le bouton Stream pour que le périphérique démarre le flux de multidiffusion :

vlc_start_stream

Activez l'option « loop » pour que le flux soit envoyé en continu :

vlc_loop

Vérification (scénario non opérationnel)

Ce scénario est une démonstration d'un scénario non opérationnel. L'objectif est de démontrer le comportement du pare-feu.

Le périphérique pare-feu obtient le flux de multidiffusion, mais ne le transfère pas :

firepower# show capture
capture INSIDE type raw-data interface INSIDE [Capturing - 0 bytes]     <-- No packets sent or received
match ip host 192.168.103.60 host 230.10.10.10
capture OUTSIDE type raw-data trace interface OUTSIDE [Buffer Full - 524030 bytes]  <-- The buffer is full
match ip host 192.168.103.60 host 230.10.10.10

Firewall LINA ASP drops show :

firepower# clear asp drop
firepower# show asp drop

Frame drop:
  Punt rate limit exceeded (punt-rate-limit)                         232  <-- The multicast packets were dropped
  Flow is denied by configured rule (acl-drop)                         2
  FP L2 rule drop (l2_acl)                                             2

Last clearing: 18:38:42 UTC Oct 12 2018 by enable_15

Flow drop:

Last clearing: 08:45:41 UTC May 17 2022 by enable_15

Pour suivre un paquet, il est nécessaire de capturer le premier paquet du flux de multidiffusion. Pour cette raison, effacez les flux actuels :

firepower# clear capture OUTSIDE
firepower# clear conn all addr 230.10.10.10
2 connection(s) deleted.

firepower# show capture OUTSIDE

379 packets captured

1: 08:49:04.537875 192.168.103.60.54100 > 230.10.10.10.5005: udp 64
2: 08:49:04.537936 192.168.103.60.54099 > 230.10.10.10.5004: udp 1328
3: 08:49:04.538027 192.168.103.60.54099 > 230.10.10.10.5004: udp 1328
4: 08:49:04.538058 192.168.103.60.54099 > 230.10.10.10.5004: udp 1328
5: 08:49:04.538058 192.168.103.60.54099 > 230.10.10.10.5004: udp 1328
6: 08:49:04.538073 192.168.103.60.54099 > 230.10.10.10.5004: udp 1328
...

L'option « detail » indique l'adresse MAC de multidiffusion :

firepower# show capture OUTSIDE detail

379 packets captured

1: 08:49:04.537875 0050.569d.344a 0100.5e0a.0a0a 0x0800 Length: 106
192.168.103.60.54100 > 230.10.10.10.5005: [udp sum ok] udp 64 (ttl 100, id 19759)
2: 08:49:04.537936 0050.569d.344a 0100.5e0a.0a0a 0x0800 Length: 1370
192.168.103.60.54099 > 230.10.10.10.5004: [udp sum ok] udp 1328 (ttl 100, id 19760)
3: 08:49:04.538027 0050.569d.344a 0100.5e0a.0a0a 0x0800 Length: 1370
192.168.103.60.54099 > 230.10.10.10.5004: [udp sum ok] udp 1328 (ttl 100, id 19761)
...

La trace d'un paquet réel montre que le paquet est autorisé, mais ce n'est pas ce qui se passe réellement :

firepower# show capture OUTSIDE packet-number 1 trace
379 packets captured

1: 08:49:04.537875 192.168.103.60.54100 > 230.10.10.10.5005: udp 64
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 11712 ns
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 11712 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: No ECMP load balancing
Result: ALLOW
Elapsed time: 7808 ns
Config:
Additional Information:
Destination is locally connected. No ECMP load balancing.
Found next-hop 192.168.103.60 using egress ifc OUTSIDE(vrfid:0)

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Elapsed time: 5246 ns
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434432
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: mzafeiro_empty - Default
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached

Phase: 5
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Elapsed time: 5246 ns
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection advanced-options UM_STATIC_TCP_MAP
service-policy global_policy global
Additional Information:

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 5246 ns
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 5246 ns
Config:
Additional Information:

Phase: 8
Type: CLUSTER-REDIRECT
Subtype: cluster-redirect
Result: ALLOW
Elapsed time: 31232 ns
Config:
Additional Information:

Phase: 9
Type: MULTICAST       <-- multicast process
Subtype:
Result: ALLOW
Elapsed time: 976 ns
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION   <-- the packet belongs to a new flow
Subtype:
Result: ALLOW          
Elapsed time: 20496 ns
Config:
Additional Information:
New flow created with id 3705, packet dispatched to next module

Result:
input-interface: OUTSIDE(vrfid:0)   
input-status: up
input-line-status: up
output-interface: OUTSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: allow            <-- The packet is allowed
Time Taken: 104920 ns

En fonction des compteurs mroute et mfib, les paquets sont abandonnés car la liste d'interfaces sortantes (OIL) est vide :

firepower# show mroute

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

(192.168.103.60, 230.10.10.10), 00:01:33/00:01:56, flags: SPF
Incoming interface: OUTSIDE          
RPF nbr: 192.168.103.60
Outgoing interface list: Null        <-- The OIL is empty!

(*, 239.255.255.250), 00:01:50/never, RP 0.0.0.0, flags: SCJ
Incoming interface: Null
RPF nbr: 0.0.0.0
Immediate Outgoing interface list:
INSIDE, Forward, 00:01:50/never

Les compteurs MFIB montrent des échecs RPF qui dans ce cas ne sont pas ce qui se passe réellement :

firepower# show mfib 230.10.10.10
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
             AR - Activity Required, K - Keepalive
firepower# show mfib 230.10.10.10
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   <-- Multicast forwarding counters
Other counts: Total/RPF failed/Other drops            <-- Multicast drop counters
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

(192.168.103.60,230.10.10.10) Flags: K
   Forwarding: 0/0/0/0, Other: 650/650/0       <-- Allowed and dropped multicast packets

Échecs RPF similaires dans la sortie « show mfib count » :

firepower# show mfib count
IP Multicast Statistics
8 routes, 4 groups, 0.25 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.0.1.39
  RP-tree:
    Forwarding: 0/0/0/0, Other: 0/0/0
Group: 224.0.1.40
  RP-tree:
    Forwarding: 0/0/0/0, Other: 0/0/0
Group: 230.10.10.10
  Source: 192.168.103.60,
    Forwarding: 0/0/0/0, Other: 1115/1115/0   <-- Allowed and dropped multicast packets
  Tot. shown: Source count: 1, pkt count: 0
Group: 232.0.0.0/8
  RP-tree:
    Forwarding: 0/0/0/0, Other: 0/0/0
Group: 239.255.255.250
  RP-tree:
    Forwarding: 0/0/0/0, Other: 0/0/0

Configurez le récepteur de multidiffusion VLC :

vlc_play_stream

Spécifiez l'adresse IP source de multidiffusion et sélectionnez Lire :

Dans le back-end, dès que vous sélectionnez Play, l'hôte annonce sa volonté de rejoindre le groupe de multidiffusion spécifique et envoie un message de rapport IGMP :

multicast_through_ftd_ok

Si vous activez un débogage, vous pouvez voir les messages de rapport IGMP :

firepower# debug igmp group 230.10.10.10
IGMP: Received v2 Report on INSIDE from 192.168.1.50 for 230.10.10.10  <-- IGMPv2 Report received
IGMP: group_db: add new group 230.10.10.10 on INSIDE
IGMP: MRIB updated (*,230.10.10.10) : Success
IGMP: Switching to EXCLUDE mode for 230.10.10.10 on INSIDE
IGMP: Updating EXCLUDE group timer for 230.10.10.10

Le flux commence :

vlc_video_on

Vérification (scénario opérationnel)

firepower# show capture
capture INSIDE type raw-data interface INSIDE [Buffer Full - 524156 bytes]    <-- Multicast packets on the egress interface
match ip host 192.168.103.60 host 230.10.10.10
capture OUTSIDE type raw-data trace interface OUTSIDE [Buffer Full - 524030 bytes]   <-- Multicast packets on the ingress interface
match ip host 192.168.103.60 host 230.10.10.10

La table mroute du pare-feu :

firepower# show mroute
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

(*, 230.10.10.10), 00:00:34/never, RP 0.0.0.0, flags: SCJ
  Incoming interface: Null
  RPF nbr: 0.0.0.0
  Immediate Outgoing interface list:
    INSIDE, Forward, 00:00:34/never

(192.168.103.60, 230.10.10.10), 00:01:49/00:03:29, flags: SFJT
  Incoming interface: OUTSIDE
  RPF nbr: 192.168.103.60
  Inherited Outgoing interface list:
    INSIDE, Forward, 00:00:34/never        <-- The OIL shows an interface

firepower# show mfib 230.10.10.10
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

(*,230.10.10.10) Flags: C K
  Forwarding: 0/0/0/0, Other: 0/0/0
  INSIDE Flags: F NS
    Pkts: 0/0
(192.168.103.60,230.10.10.10) Flags: K
  Forwarding: 6373/0/1354/0, Other: 548/548/0      <-- There are multicast packets forwarded
  OUTSIDE Flags: A
  INSIDE Flags: F NS
    Pkts: 6373/6

compteurs mfib :

firepower# show mfib count
IP Multicast Statistics
10 routes, 5 groups, 0.40 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.0.1.39
  RP-tree:
    Forwarding: 0/0/0/0, Other: 0/0/0
Group: 224.0.1.40
  RP-tree:
    Forwarding: 0/0/0/0, Other: 0/0/0
Group: 230.10.10.10
  RP-tree:
    Forwarding: 0/0/0/0, Other: 0/0/0
  Source: 192.168.103.60,
    Forwarding: 7763/0/1354/0, Other: 548/548/0   <-- There are multicast packets forwarded
  Tot. shown: Source count: 1, pkt count: 0
Group: 232.0.0.0/8
  RP-tree:
    Forwarding: 0/0/0/0, Other: 0/0/0
Group: 239.255.255.250
  RP-tree:
    Forwarding: 0/0/0/0, Other: 0/0/0
  Source: 192.168.1.50,
    Forwarding: 7/0/500/0, Other: 0/0/0
  Tot. shown: Source count: 1, pkt count: 0

IGMP Snooping

La surveillance IGMP est un mécanisme utilisé sur les commutateurs afin d'empêcher l'inondation de multidiffusion.
Le commutateur surveille les rapports IGMP pour déterminer où se trouvent les hôtes (récepteurs).
Le commutateur surveille les requêtes IGMP pour déterminer où se trouvent les routeurs/pare-feu (expéditeurs).
La surveillance IGMP est activée par défaut sur la plupart des commutateurs Cisco. Pour plus d'informations, consultez les guides de commutation associés. Voici l'exemple de sortie d'un commutateur Catalyst de couche 3 :

switch# show ip igmp snooping statistics

  Current number of Statistics entries    : 15
  Configured Statistics database limit    : 32000
  Configured Statistics database threshold: 25600
  Configured Statistics database limit    : Not exceeded
  Configured Statistics database threshold: Not exceeded

Snooping statistics for Vlan204
#channels: 3
#hosts   : 5

Source/Group                    Interface       Reporter        Uptime   Last-Join Last-Leave
0.0.0.0/230.10.10.10            Vl204:Gi1/48    192.168.1.50    2d13h        -     2d12h
0.0.0.0/230.10.10.10            Vl204:Gi1/48    192.168.1.97    2d13h    2d12h         -
0.0.0.0/230.10.10.10            Vl204:Gi2/1     192.168.1.50    2d10h    02:20:05  02:20:00
0.0.0.0/239.255.255.250         Vl204:Gi2/1     192.168.1.50    2d11h    02:20:05  02:20:00
0.0.0.0/239.255.255.250         Vl204:Gi2/1     192.168.2.50    2d14h    2d13h         -
0.0.0.0/239.255.255.250         Vl204:Gi2/1     192.168.6.50    2d13h        -     2d13h
0.0.0.0/224.0.1.40              Vl204:Gi2/26    192.168.2.1     2d14h    00:00:39  2d13h

Snooping statistics for Vlan206
#channels: 4
#hosts   : 3

Source/Group                    Interface       Reporter        Uptime   Last-Join Last-Leave
0.0.0.0/230.10.10.10            Vl206:Gi1/48    192.168.6.91    00:30:15 2d13h     2d13h
0.0.0.0/239.10.10.10            Vl206:Gi1/48    192.168.6.91    2d14h    2d13h         -
0.0.0.0/239.255.255.250         Vl206:Gi2/1     192.168.6.50    2d12h    00:52:49  00:52:45
0.0.0.0/224.0.1.40              Vl206:Gi2/26    192.168.6.1     00:20:10 2d13h     2d13h
0.0.0.0/230.10.10.10            Vl206:Gi2/26    192.168.6.1     2d13h    2d13h         -
0.0.0.0/230.10.10.10            Vl206:Gi2/26    192.168.6.91    2d13h        -     2d13h
0.0.0.0/239.10.10.10            Vl206:Gi2/26    192.168.6.1     2d14h    2d14h         -
0.0.0.0/239.10.10.10            Vl206:Gi2/26    192.168.6.91    2d14h        -     2d14h

Tâche 3 : groupe IGMP statique et groupe IGMP de jointure

Aperçu

	ip igmp static-group	ip igmp join-group
Appliqué sur l'interface FTD ?	Oui	Oui
Le FTD attire-t-il un flux de multidiffusion ?	Oui, une jointure PIM est envoyée vers le périphérique en amont. vers la source ou vers le point de rendez-vous (RP). Cela se produit uniquement si le FTD avec cette commande est le routeur désigné PIM (DR) sur cette interface.	Oui, une jointure PIM est envoyée vers le périphérique en amont. vers la source ou vers le point de rendez-vous (RP). Cela se produit uniquement si le FTD avec cette commande est le routeur désigné PIM (DR) sur cette interface.
Le FTD achemine-t-il le trafic de multidiffusion depuis l'interface ?	Oui	Oui
Le FTD consomme-t-il le trafic de multidiffusion et y répond-il ?	Non	Oui, le FTD envoie le flux de multidiffusion au processeur, l'utilise et répond à la source.
Impact sur le processeur	Minimal car le paquet n'est pas envoyé au processeur.	Peut affecter le CPU FTD puisque chaque paquet multicast qui appartient au groupe est envoyé au CPU FTD.

Exigence de la tâche

Considérez cette topologie :

igmp_snooping_topology

Sur le pare-feu, activez les captures suivantes :

firepower# capture CAPI interface OUTSIDE trace match icmp host 192.168.103.62 any
firepower# capture CAPO interface INSIDE match icmp host 192.168.103.62 any

Utilisez la commande ping ICMP à partir du commutateur L3 pour envoyer le trafic de multidiffusion vers IP 230.11.11.11 et vérifiez la manière dont le pare-feu gère cette opération.
Activez la commande igmp static-group sur l'interface INSIDE du pare-feu et vérifiez comment le flux de multidiffusion (IP 230.11.11.11) est géré par le pare-feu.
Activez la commande igmp static-group sur l'interface INSIDE du pare-feu et vérifiez comment le flux de multidiffusion (IP 230.11.11.11) est géré par le pare-feu.

Solution

Le pare-feu n'a pas de mroutes pour l'adresse IP 230.11.11.11 :

firepower# show mroute

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.255.255.250), 00:43:21/never, RP 0.0.0.0, flags: SCJ
  Incoming interface: Null
  RPF nbr: 0.0.0.0
  Immediate Outgoing interface list:
    OUTSIDE, Forward, 00:05:41/never
    INSIDE, Forward, 00:43:21/never

L’outil ping ICMP constitue un moyen simple de tester la multidiffusion. Dans ce cas, lancez une requête ping à partir de R2 vers l'adresse IP de multidiffusion 230.11.11.11 :

L3-Switch# ping 230.11.11.11 re 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 230.11.11.11, timeout is 2 seconds:
...............................

Sur le pare-feu, un mroute est créé dynamiquement et l'OIL est vide :

firepower# show mroute

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

(192.168.103.62, 230.11.11.11), 00:02:33/00:00:56, flags: SPF  <-- The mroute is added
  Incoming interface: OUTSIDE
  RPF nbr: 192.168.103.62
 Outgoing interface list: Null     <-- The OIL is empty

La capture sur le pare-feu montre :

firepower# show capture
capture CAPI type raw-data trace interface OUTSIDE [Capturing - 1040 bytes]    <-- There are ICMP packets captured on ingress interface
match icmp host 192.168.103.62 any
capture CAPO type raw-data interface INSIDE [Capturing - 0 bytes]     <-- There are no ICMP packets on egress
match icmp host 192.168.103.62 any

Le pare-feu crée des connexions pour chaque requête ping, mais supprime silencieusement les paquets :

firepower# show log | include 230.11.11.11
May 17 2022 11:05:47: %FTD-7-609001: Built local-host identity:230.11.11.11       <-- A new connection is created
May 17 2022 11:05:47: %FTD-6-302020: Built inbound ICMP connection for faddr 192.168.1.99/6 gaddr 230.11.11.11/0 laddr 230.11.11.11/0 type 8 code 0
May 17 2022 11:05:47: %FTD-6-302020: Built inbound ICMP connection for faddr 192.168.103.62/6 gaddr 230.11.11.11/0 laddr 230.11.11.11/0 type 8 code 0
May 17 2022 11:05:49: %FTD-6-302021: Teardown ICMP connection for faddr 192.168.1.99/6 gaddr 230.11.11.11/0 laddr 230.11.11.11/0 type 8 code 0
May 17 2022 11:05:49: %FTD-6-302021: Teardown ICMP connection for faddr 192.168.103.62/6 gaddr 230.11.11.11/0 laddr 230.11.11.11/0 type 8 code 0
May 17 2022 11:05:49: %FTD-7-609002: Teardown local-host identity:230.11.11.11 duration 0:00:02  <-- The connection is closed
May 17 2022 11:05:51: %FTD-7-609001: Built local-host identity:230.11.11.11             <-- A new connection is created
May 17 2022 11:05:51: %FTD-6-302020: Built inbound ICMP connection for faddr 192.168.1.99/6 gaddr 230.11.11.11/0 laddr 230.11.11.11/0 type 8 code 0
May 17 2022 11:05:51: %FTD-6-302020: Built inbound ICMP connection for faddr 192.168.103.62/6 gaddr 230.11.11.11/0 laddr 230.11.11.11/0 type 8 code 0
May 17 2022 11:05:53: %FTD-6-302021: Teardown ICMP connection for faddr 192.168.1.99/6 gaddr 230.11.11.11/0 laddr 230.11.11.11/0 type 8 code 0
May 17 2022 11:05:53: %FTD-6-302021: Teardown ICMP connection for faddr 192.168.103.62/6 gaddr 230.11.11.11/0 laddr 230.11.11.11/0 type 8 code 0
May 17 2022 11:05:53: %FTD-7-609002: Teardown local-host identity:230.11.11.11 duration 0:00:02      <-- The connection is closed

Remarque : la capture d'abandon LINA ASP n'affiche pas les paquets abandonnés

L'indication principale des abandons de paquets de multidiffusion est :

firepower# 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.0.1.39) Flags: S K
  Forwarding: 0/0/0/0, Other: 0/0/0
(*,224.0.1.40) Flags: S K
  Forwarding: 0/0/0/0, Other: 0/0/0
(192.168.103.62,230.11.11.11) Flags: K         <-- The multicast stream
  Forwarding: 0/0/0/0, Other: 27/27/0          <-- The packets are dropped

igmp static-group

Sur FMC, configurez un groupe IGMP statique :

igmp_static_config

Voici ce qui est déployé en arrière-plan :

interface Port-channel1.205
 vlan 205
 nameif INSIDE
 cts manual
  propagate sgt preserve-untag
  policy static sgt disabled trusted
 security-level 0
 ip address 192.168.1.24 255.255.255.0
 igmp static-group 230.11.11.11        <-- IGMP static group is enabled on the interface

La requête ping échoue, mais le trafic de multidiffusion ICMP est maintenant transféré via le pare-feu :

L3-Switch# ping 230.11.11.11 re 10000
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 230.11.11.11, timeout is 2 seconds:
............................

firepower# show capture
capture CAPI type raw-data trace interface OUTSIDE [Capturing - 650 bytes]   <-- ICMP packets are captured on ingress interface
match icmp host 192.168.103.62 any
capture CAPO type raw-data interface INSIDE [Capturing - 670 bytes]    <-- ICMP packets are captured on egress interface
match icmp host 192.168.103.62 any

firepower# show capture CAPI
8 packets captured

1: 11:31:32.470541 192.168.103.62 > 230.11.11.11 icmp: echo request
2: 11:31:34.470358 192.168.103.62 > 230.11.11.11 icmp: echo request
3: 11:31:36.470831 192.168.103.62 > 230.11.11.11 icmp: echo request
4: 11:31:38.470785 192.168.103.62 > 230.11.11.11 icmp: echo request
...

firepower# show capture CAPO
11 packets captured

1: 11:31:32.470587 802.1Q vlan#205 P0 192.168.103.62 > 230.11.11.11 icmp: echo request
2: 11:31:34.470404 802.1Q vlan#205 P0 192.168.103.62 > 230.11.11.11 icmp: echo request
3: 11:31:36.470861 802.1Q vlan#205 P0 192.168.103.62 > 230.11.11.11 icmp: echo request
4: 11:31:38.470816 802.1Q vlan#205 P0 192.168.103.62 > 230.11.11.11 icmp: echo request

Remarque : la trace du paquet indique une sortie incorrecte (l'interface d'entrée est identique à l'interface de sortie). Pour plus de détails, consultez l'ID de bogue Cisco CSCvm89673.

firepower# show capture CAPI packet-number 1 trace

1: 11:39:33.553987 192.168.103.62 > 230.11.11.11 icmp: echo request
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 3172 ns
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 3172 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: No ECMP load balancing
Result: ALLOW
Elapsed time: 9760 ns
Config:
Additional Information:
Destination is locally connected. No ECMP load balancing.
Found next-hop 192.168.103.62 using egress ifc OUTSIDE(vrfid:0)

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 5368 ns
Config:
Implicit Rule
Additional Information:

Phase: 5
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Elapsed time: 5368 ns
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection advanced-options UM_STATIC_TCP_MAP
service-policy global_policy global
Additional Information:

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 5368 ns
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 5368 ns
Config:
Additional Information:

Phase: 8
Type: CLUSTER-REDIRECT
Subtype: cluster-redirect
Result: ALLOW
Elapsed time: 31720 ns
Config:
Additional Information:

Phase: 9
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Elapsed time: 488 ns
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect icmp
service-policy global_policy global
Additional Information:

Phase: 10
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Elapsed time: 2440 ns
Config:
Additional Information:

Phase: 11
Type: MULTICAST    <-- The packet is multicast
Subtype:
Result: ALLOW
Elapsed time: 976 ns
Config:
Additional Information:

Phase: 12
Type: FLOW-CREATION    <-- A new flow is created
Subtype:
Result: ALLOW
Elapsed time: 56120 ns
Config:
Additional Information:
New flow created with id 5690, packet dispatched to next module

Phase: 13
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 10248 ns
Config:
Additional Information:
MAC Access list

Result:
input-interface: OUTSIDE(vrfid:0)
input-status: up
input-line-status: up
output-interface: OUTSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: allow       <-- The packet is allowed
Time Taken: 139568 ns

Conseil : vous pouvez envoyer une requête ping avec timeout 0 à partir de l'hôte source et vérifier les compteurs mfib du pare-feu :

L3-Switch# ping 230.11.11.11 re 500 timeout 0
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 230.11.11.11, timeout is 0 seconds:
......................................................................
......................................................................
......................................................................
....................

firepower# clear mfib counters
firepower# !ping from the source host. 

firepower# show mfib 230.11.11.11
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

(*,230.11.11.11) Flags: C K
  Forwarding: 0/0/0/0, Other: 0/0/0
  INSIDE Flags: F NS
    Pkts: 0/0
(192.168.103.62,230.11.11.11) Flags: K
  Forwarding: 500/0/100/0, Other: 0/0/0    <-- 500 multicast packets forwarded. The average size of each packet is 100 Bytes
  OUTSIDE Flags: A
  INSIDE Flags: F NS
    Pkts: 500/0

igmp join-group

Sur FMC remote, configurez le groupe statique précédemment configuré et configurez un groupe de jonction IGMP :

igmp_join_config

igmp_join_topology

La configuration déployée :

firepower# show run interface Port-channel1.205
!
interface Port-channel1.205
vlan 205
nameif INSIDE
cts manual
propagate sgt preserve-untag
policy static sgt disabled trusted
security-level 0
ip address 192.168.1.24 255.255.255.0
igmp join-group 230.11.11.11       <-- The interface joined the multicast group

Le groupe IGMP :

firepower# show igmp group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
230.11.11.11 INSIDE 00:30:43 never 192.168.1.24   <-- The group is enabled on the interface

À partir de l’hôte source, essayez le premier test de multidiffusion ICMP vers 230.11.11.11 IP :

L3-Switch# ping 230.11.11.11 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 230.11.11.11, timeout is 2 seconds:

Reply to request 0 from 192.168.1.24, 12 ms
Reply to request 1 from 192.168.1.24, 8 ms
Reply to request 2 from 192.168.1.24, 8 ms
Reply to request 3 from 192.168.1.24, 8 ms
Reply to request 4 from 192.168.1.24, 8 ms
Reply to request 5 from 192.168.1.24, 12 ms
Reply to request 6 from 192.168.1.24, 8 ms
Reply to request 7 from 192.168.1.24, 8 ms
Reply to request 8 from 192.168.1.24, 8 ms
Reply to request 9 from 192.168.1.24, 8 ms

Remarque : si vous ne voyez pas toutes les réponses, vérifiez l'ID de bogue Cisco CSCvm90069.

Tâche 4 : configuration du routage multidiffusion de stub IGMP

stub_topology

Configurez le routage de multidiffusion d'extrémité sur FTD de sorte que les messages IGMP Membership Report reçus sur l'interface INSIDE soient transférés vers l'interface OUTSIDE.

Solution

La configuration déployée :

firepower# show run multicast-routing
multicast-routing               <-- Multicast routing is enabled
firepower# show run interface Port-channel1.205
!
interface Port-channel1.205
 vlan 205
 nameif INSIDE
 cts manual
  propagate sgt preserve-untag
  policy static sgt disabled trusted
 security-level 0
 ip address 192.168.1.24 255.255.255.0
 igmp forward interface OUTSIDE        <-- The interface does stub multicast routing

Vérification

Activer les captures sur FTD :

firepower# capture CAPI interface INSIDE trace match igmp any host 230.10.10.10
firepower# capture CAPO interface OUTSIDE match igmp any host 230.10.10.10

Vérification

Pour forcer un rapport d'adhésion IGMP, vous pouvez utiliser une application comme VLC :

vlc_play_ip_stream

Le FTD proxie les paquets IGMP :

firepower# show capture
capture CAPI type raw-data trace interface INSIDE [Capturing - 66 bytes]  <-- IGMP packets captured on ingress
match igmp any host 230.10.10.10
capture CAPO type raw-data interface OUTSIDE [Capturing - 62 bytes]   <-- IGMP packets captured on egress
match igmp any host 230.10.10.10

Le FTD modifie l'adresse IP source :

firepower# show capture CAPI

1 packet captured

   1: 12:21:12.820483 802.1Q vlan#205 P6 192.168.1.50 > 230.10.10.10 ip-proto-2, length 8    <-- The source IP of the packet on ingress interface
1 packet shown
firepower# show capture CAPO

1 packet captured

   1: 12:21:12.820743 192.168.103.91 > 230.10.10.10 ip-proto-2, length 8  <-- The source IP of the packet on egress interface
1 packet shown

Si vous vérifiez le pcap dans Wireshark, vous pouvez voir que le paquet est complètement régénéré par le pare-feu (les changements d'identification IP).

Une entrée de groupe est créée sur le FTD :

firepower# show igmp group
IGMP Connected Group Membership
Group Address    Interface            Uptime    Expires   Last Reporter
230.10.10.10     INSIDE               00:15:22  00:03:28  192.168.1.50     <-- IGMP group is enabled on the ingress interface
239.255.255.250  INSIDE               00:15:27  00:03:29  192.168.1.50

Le pare-feu FTD crée 2 connexions de plan de contrôle :

firepower# show conn all address 230.10.10.10
9 in use, 28 most used
Inspect Snort:
preserve-connection: 0 enabled, 0 in effect, 0 most enabled, 0 most in effect
IGMP INSIDE 192.168.1.50 NP Identity Ifc 230.10.10.10, idle 0:00:09, bytes 8, flags          <-- Connection terminated on the ingress interface
IGMP OUTSIDE 230.10.10.10 NP Identity Ifc 192.168.103.91, idle 0:00:09, bytes 8, flags       <-- Connection terminated on the egress interface

Trace du premier paquet :

firepower# show capture CAPI packet-number 1 trace

6 packets captured

1: 12:21:12.820483 802.1Q vlan#205 P6 192.168.1.50 > 230.10.10.10 ip-proto-2, length 8   <-- The first packet of the flow
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 5124 ns
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 5124 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: No ECMP load balancing
Result: ALLOW
Elapsed time: 7808 ns
Config:
Additional Information:
Destination is locally connected. No ECMP load balancing.
Found next-hop 192.168.1.50 using egress ifc INSIDE(vrfid:0)

Phase: 4
Type: CLUSTER-DROP-ON-SLAVE
Subtype: cluster-drop-on-slave
Result: ALLOW
Elapsed time: 5368 ns
Config:
Additional Information:

Phase: 5
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 5368 ns
Config:
Implicit Rule
Additional Information:

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 5368 ns
Config:
Additional Information:

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 5368 ns
Config:
Additional Information:

Phase: 8
Type: CLUSTER-REDIRECT
Subtype: cluster-redirect
Result: ALLOW
Elapsed time: 40504 ns
Config:
Additional Information:

Phase: 9
Type: MULTICAST        <-- The packet is multicast
Subtype:
Result: ALLOW
Elapsed time: 976 ns
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION       <-- A new flow is created
Subtype:
Result: ALLOW
Elapsed time: 17568 ns
Config:
Additional Information:
New flow created with id 5945, packet dispatched to next module

Phase: 11
Type: FLOW-CREATION      <-- A second flow is created
Subtype:
Result: ALLOW
Elapsed time: 39528 ns
Config:
Additional Information:
New flow created with id 5946, packet dispatched to next module

Phase: 12
Type: NEXTHOP-LOOKUP-FROM-OUTPUT-ROUTE-LOOKUP
Subtype: Lookup Nexthop on interface
Result: ALLOW
Elapsed time: 6344 ns
Config:
Additional Information:
Found next-hop 230.10.10.10 using egress ifc OUTSIDE(vrfid:0)

Phase: 13
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 9760 ns
Config:
Additional Information:
MAC Access list

Result:
input-interface: INSIDE(vrfid:0)
input-status: up
input-line-status: up
output-interface: INSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: allow
Time Taken: 154208 ns

Problèmes identifiés

Filtrer le trafic multidiffusion sur les zones de destination

Vous ne pouvez pas spécifier une zone de sécurité de destination pour la règle de stratégie de contrôle d'accès qui correspond au trafic de multidiffusion :

acp_misconfig

Ceci est également documenté dans le guide de l'utilisateur FMC :

fmc_config_guide

Les rapports IGMP sont refusés par le pare-feu lorsque la limite d'interface IGMP est dépassée

Par défaut, le pare-feu autorise un maximum de 500 jointures actives (rapports) sur une interface. Si ce seuil est dépassé, le pare-feu ignore les rapports IGMP entrants supplémentaires des récepteurs de multidiffusion.

Pour vérifier la limite IGMP et les jointures actives, exécutez la commande show igmp interface name if:

asa# show igmp interface inside
inside is up, line protocol is up
  Internet address is 10.10.10.1/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: 0 joins, 0 leaves
  IGMP querying router is 10.10.10.1 (this system)

La commande de débogage IGMP debug igmp affiche ce résultat :

asa# debug igmp
Apr 20 2023 09:37:10: %ASA-7-711001: IGMP: Group 230.1.2.3 limit denied on inside

Les versions logicielles avec le correctif de l'ID de bogue Cisco CSCvw60976 permettent aux utilisateurs de configurer jusqu'à 5 000 groupes par interface.

Le pare-feu ignore les rapports IGMP pour la plage d'adresses 232.x.x.x/8

La plage d'adresses 232.x.x.x/8 doit être utilisée avec le protocole SSM (Source Specific Multicast). Le pare-feu ne prend pas en charge la fonctionnalité PIM Source Specific Multicast (SSM) et la configuration associée.

La commande de débogage IGMP debug igmp affiche ce résultat :

asa# debug igmp
Apr 20 2023 09:37:10: %ASA-7-711001: IGMP: Received v2 Report on inside from 10.10.10.11 for 232.179.89.253
Apr 20 2023 09:37:10: %ASA-7-711001: IGMP: group_db: add new group 232.179.89.253 on inside
Apr 20 2023 09:37:10: %ASA-7-711001: IGMP: Exclude report on inside ignored for SSM group 232.179.89.253

ID de bogue Cisco CSCsr53916 suit l'amélioration pour prendre en charge la gamme SSM.

Informations connexes

Historique de révision

Révision	Date de publication	Commentaires
1.0	19-May-2022	Première publication

Contribution d’experts de Cisco

Mikis Zafeiroudis
Ingénieur TAC Cisco
Ilkin Gasimov
Ingénieur TAC Cisco

Dépannage de Firepower Threat Defense IGMP et des bases de la multidiffusion

Options de téléchargement

Langage exempt de préjugés

À propos de cette traduction

Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Configurer

Notions de base IGMP

Tâche 1 - Trafic multidiffusion sur le plan de contrôle

Tâche 2 : configuration de la multidiffusion de base

IGMP Snooping

Tâche 3 : groupe IGMP statique et groupe IGMP de jointure

igmp static-group

igmp join-group

Tâche 4 : configuration du routage multidiffusion de stub IGMP

Problèmes identifiés

Filtrer le trafic multidiffusion sur les zones de destination

Les rapports IGMP sont refusés par le pare-feu lorsque la limite d'interface IGMP est dépassée

Le pare-feu ignore les rapports IGMP pour la plage d'adresses 232.x.x.x/8

Informations connexes

Historique de révision

Contribution d’experts de Cisco

Ce document vous est-il utile?

Contacter Cisco

Ce document s’applique à ces produits