Fehlerbehebung: Firepower Threat Defense - IGMP- und Multicast-Grundlagen

Download-Optionen

PDF (3.2 MB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (3.0 MB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (1.8 MB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:19. Mai 2022

Dokument-ID:217891

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Konfigurieren

IGMP-Grundlagen

Aufgabe 1: Multicast-Verkehr auf der Kontrollebene

Aufgabe 2: Konfigurieren von einfachem Multicast

IGMP-Snooping

Schritt 3: IGMP static-group und IGMP join-group

igmp static-group

igmp-Join-Gruppe

Schritt 4: Konfigurieren von IGMP-Stub-Multicast-Routing

Bekannte Probleme

Filtern von Multicast-Datenverkehr in Zielzonen

IGMP-Berichte werden von der Firewall abgelehnt, wenn der IGMP-Schnittstellengrenzwert überschritten wird

Die Firewall ignoriert IGMP-Berichte für den Adressbereich 232.x.x.x/8.

Zugehörige Informationen

Einleitung

Dieses Dokument beschreibt die Grundlagen von Multicast und wie Firepower Threat Defense (FTD) das Internet Group Management Protocol (IGMP) implementiert.

Voraussetzungen

Anforderungen

Grundlegende Kenntnisse zu IP-Routing

Verwendete Komponenten

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Der Inhalt dieses Artikels gilt auch für die Software der Adaptive Security Appliance (ASA).

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

Cisco FirePOWER 4125 Threat Defence Version 7.1.0
FirePOWER Management Center (FMC) Version 7.1.0
ASA Version 9.19.1.

Hintergrundinformationen

Definitionen

Unicast = von einem einzelnen Host zu einem anderen Host (One-to-One).
Broadcast = von einem einzelnen Host zu ALLEN möglichen Hosts (One-to-All).
Multicast = von einem Host einer Gruppe von Hosts zu einer Gruppe von Hosts (One-to-Many oder Many-to-Many).
Anycast = von einem Host zum nächsten Host einer Gruppe (One-to-One-of-Many).

Grundlagen

Multicast RFC 988 wurde 1986 von Steve Deering geschrieben.
IPv4-Multicast verwendet den Bereich 224.0.0.0/4 (die ersten 4 Bit, 1110) - 224.0.0.0 - 239.255.255.255.
Für IPv4 wird die L2-MAC-Adresse von der L3-Multicast-IP-Adresse abgeleitet: 01005e (24 Bit) + 25^. Bit immer 0 + 23 niedrigere Bits der Multicast-IPv4-Adresse.
IPv6-Multicast verwendet den Bereich FF00::/8 und ist flexibler als IPv4-Multicast, da Rendezvous Point (RP)-IP eingebettet werden kann.
Für IPv6 wird die L2-MAC-Adresse aus dem L3-Multicast abgeleitet: 333 + 32 niedrigere Bits der Multicast-IPv6-Adresse.
Multicast-Vorteile: Effizienz durch geringere Auslastung der Quelle. Leistung, da Datenverkehrsduplikate und -überflutungen vermieden werden.
Multicast-Nachteile: Unzuverlässiger Transport (UDP-basiert), keine Vermeidung von Überlastung, Out-of-Sequence-Bereitstellung.
Multicast wird im öffentlichen Internet nicht unterstützt, da hierfür alle Geräte im Pfad erforderlich sind. Wird in der Regel verwendet, wenn alle Geräte einer gemeinsamen administrativen Behörde unterstehen.
Typische Multicast-Anwendungen: interner Video-Stream, Videokonferenz.

Multicast und repliziertes Unicast

Bei repliziertem Unicast erstellt die Quelle mehrere Kopien desselben Unicast-Pakets (Replikate) und sendet sie an mehrere Ziel-Hosts. Multicast verlagert die Last vom Quell-Host zum Netzwerk, während bei Repliziertem Unicast die gesamte Arbeit auf dem Quell-Host ausgeführt wird.

Konfigurieren

IGMP-Grundlagen

IGMP ist die "Sprache", die zwischen den Multicast-Empfängern und dem lokalen L3-Gerät (in der Regel einem Router) gesprochen wird.
IGMP ist ein Layer-3-Protokoll (wie ICMP) und verwendet das IP-Protokoll Nummer 2.
Derzeit gibt es drei IGMP-Versionen. Die IGMP-Standardversion der Firewall ist Version 2. Derzeit werden nur die Versionen 1 und 2 unterstützt.
Zwischen IGMPv1 und IGMPv2 bestehen die Hauptunterschiede in folgenden Bereichen:

IGMPv1 hat keine Nachricht "Leave Group" (Gruppe verlassen).
IGMPv1 verfügt über keine gruppenspezifische Abfrage (wird von der Firewall verwendet, wenn ein Host eine Multicast-Gruppe verlässt).
IGMPv1 verfügt über keinen Abfrageauswahlprozess.

IGMPv3 wird derzeit auf ASA/FTD nicht unterstützt, der wesentliche Unterschied zwischen IGMPv2 und IGMPv3 besteht jedoch in der Aufnahme einer gruppen- und quellenspezifischen Abfrage in IGMPv3, die in Source-Specific Multicast (SSM) verwendet wird.
IGMPv1/IGMPv2/IGMPv3-Abfragen = 224.0.0.1
IGMPv2 Leave = 224,0.0,2
IGMPv3-Mitgliedsbericht = 224.0.0.22
Wenn ein Host beitreten möchte, kann er eine nicht angeforderte IGMP-Meldung senden:

igmp_membership

Vom Firewall-Standpunkt aus gibt es zwei Arten von IGMP-Abfragen: Allgemeine Abfragen und gruppenspezifische Abfragen.
Wenn die Firewall die IGMP-Meldung "Leave Group" (Gruppe verlassen) empfängt, muss sie prüfen, ob sich andere Mitglieder dieser Gruppe im Subnetz befinden. Aus diesem Grund sendet die Firewall eine gruppenspezifische Abfrage:

igmp_membership_specific

In Subnetzen mit mehreren Routern/Firewalls wird ein Abfrager (ein Gerät, das alle IGMP-Abfragen sendet) ausgewählt:

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

Auf FTD können Sie, ähnlich wie bei klassischen ASA-Geräten, IGMP aktivieren, um IGMP-bezogene Meldungen anzuzeigen:

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

Ein Host verlässt normalerweise eine Multicast-Gruppe mit einer Leave Group-Nachricht (IGMPv2).

igmp_leave

Aufgabe 1: Multicast-Verkehr auf der Kontrollebene

OSPF_topology

Konfigurieren Sie OSPFv2 und OSPFv3 zwischen dem FTD und der ASA. Prüfen Sie, wie die beiden Geräte den von OSPF generierten L2- und L3-Multicast-Datenverkehr verarbeiten.

Lösung

OSPFv2-Konfiguration

ospf_config_ftd

ospf_config_interface

Ähnlich für OSPFv3

Konfiguration auf FTD CLI:

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

Bei der Konfiguration werden diese Einträge in den Erlaubnistabellen für den FTD Accelerated Security Path (ASP) erstellt, damit der eingehende Multicast-Datenverkehr nicht blockiert wird:

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

Für 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
...

Die OSPFv2- und OSPFv3-Adjacencies sind 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

Die folgenden Multicast-OSPF-Sitzungen werden an der Box terminiert:

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

Aktivieren Sie als Test die Erfassung für IPv4, und löschen Sie die Verbindungen zum Gerät:

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

Warnung: Dies führt zu einem Ausfall! Das Beispiel dient nur zu Demonstrationszwecken.

Die erfassten OSPF-Pakete:

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]

So wird das OSPFv2-Multicast-Paket von der Firewall behandelt:

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

So wird das OSPFv3-Multicast-Paket von der Firewall behandelt:

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

Aufgabe 2: Konfigurieren von einfachem Multicast

Topologie

Anforderung

Konfigurieren Sie die Firewall so, dass Multicast-Datenverkehr vom Server an den Multicast-Client unter IP 230.10.10.10 übertragen wird.

Lösung

Aus Sicht der Firewall muss Multicast-Routing mindestens global aktiviert werden. Dadurch werden IGMP und PIM im Hintergrund auf allen Firewall-Schnittstellen aktiviert.

Auf der FMC-Benutzeroberfläche:

enable_ftd_multicast

In der Firewall-CLI ist dies die Push-Konfiguration:

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

IGMP-Verifizierung

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

PIM-Verifizierung

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

MFIB-Verifizierung

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

Multicast-Verkehr durch die Firewall

In diesem Fall wird die VLC Media Player-Anwendung als Multicast-Server und Client zum Testen des Multicast-Datenverkehrs verwendet:

multicast_through_ftd

Konfiguration des VLC-Multicast-Servers:

vlc_stream

vlc_add_file

Wählen Sie auf dem nächsten Bildschirm einfach Weiter.

Format auswählen:

vlc_add_method

Geben Sie die Multicast-IP und den Multicast-Port an:

vlc_add_ip

vlc_enable

Aktivieren Sie LINA-Aufzeichnungen auf der FTD-Firewall:

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

Wählen Sie die Stream-Taste für das Gerät aus, um den Multicast-Stream zu starten:

vlc_start_stream

Aktivieren Sie die Option "loop" (Schleife), damit der Stream kontinuierlich gesendet wird:

vlc_loop

Überprüfung (nicht betriebsbereites Szenario)

Dieses Szenario ist eine Demonstration eines nicht betriebsbereiten Szenarios. Ziel ist es, das Verhalten der Firewall zu demonstrieren.

Das Firewall-Gerät empfängt den Multicast-Stream, leitet ihn aber nicht weiter:

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

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

Um ein Paket zu verfolgen, muss das erste Paket des Multicast-Flusses erfasst werden. Aus diesem Grund löschen Sie die aktuellen Ströme:

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

Die Detailoption gibt die Multicast-MAC-Adresse an:

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

Die Ablaufverfolgung eines echten Pakets zeigt, dass das Paket zulässig ist. Dies ist jedoch nicht der Fall:

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

Basierend auf den mroute- und mfib-Zählern werden die Pakete verworfen, da die OIL (Outgoing Interface List) leer ist:

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

Die MFIB-Zähler zeigen RPF-Fehler an, die in diesem Fall nicht das sind, was wirklich passiert:

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

Ähnliche RPF-Fehler in der Ausgabe von "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

Konfigurieren Sie den VLC-Multicast-Empfänger:

vlc_play_stream

Geben Sie die Multicast-Quell-IP an, und wählen Sie Wiedergabe:

Sobald Sie im Backend Play (Wiedergabe) auswählen, kündigt der Host seine Bereitschaft an, der spezifischen Multicast-Gruppe beizutreten, und sendet eine IGMP-Bericht-Nachricht:

multicast_through_ftd_ok

Wenn Sie ein Debugging aktivieren, werden die IGMP-Berichtsmeldungen angezeigt:

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

Der Datenstrom wird gestartet:

vlc_video_on

Überprüfung (Betriebsszenario)

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

Die Routing-Tabelle der Firewall:

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

MFIB-Zähler:

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

IGMP-Snooping wird auf Switches verwendet, um Multicast-Flooding zu verhindern.
Der Switch überwacht IGMP-Berichte, um festzustellen, wo sich Hosts (Empfänger) befinden.
Der Switch überwacht IGMP-Abfragen, um festzustellen, wo sich Router/Firewalls (Absender) befinden.
IGMP-Snooping ist auf den meisten Cisco Switches standardmäßig aktiviert. Weitere Informationen finden Sie in den entsprechenden Switching-Leitfäden. Dies ist die Beispielausgabe eines L3 Catalyst Switches:

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

Schritt 3: IGMP static-group und IGMP join-group

Überblick

	ip igmp static-group	ip igmp join-group
Auf FTD-Schnittstelle angewendet?	Ja	Ja
Zieht die FTD einen Multicast-Stream an?	Ja, eine PIM-Join wird an das Upstream-Gerät, die Quelle oder an den Rendezvous Point (RP) gesendet. Dies ist nur der Fall, wenn es sich bei dem FTD mit diesem Befehl um den PIM Designated Router (DR) an dieser Schnittstelle handelt.	Ja, eine PIM-Join wird an das Upstream-Gerät, die Quelle oder an den Rendezvous Point (RP) gesendet. Dies ist nur der Fall, wenn es sich bei dem FTD mit diesem Befehl um den PIM Designated Router (DR) an dieser Schnittstelle handelt.
Leitet das FTD Multicast-Datenverkehr von der Schnittstelle weiter?	Ja	Ja
Nutzt die FTD den Multicast-Datenverkehr und antwortet sie darauf?	Nein	Ja, die FTD analysiert den Multicast-Stream an die CPU, nutzt ihn und antwortet an die Quelle.
CPU-Auswirkung	Minimal, da das Paket nicht an die CPU gesendet wird.	Kann die FTD-CPU beeinflussen, da jedes Multicast-Paket, das zu der Gruppe gehört, an die FTD-CPU gesendet wird.

Voraussetzung für diese Aufgabe

Betrachten Sie diese Topologie:

igmp_snooping_topology

Aktivieren Sie auf der Firewall die folgenden Funktionen:

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

Verwenden Sie den ICMP-Ping vom L3-Switch, um Multicast-Datenverkehr an die IP 230.11.11.11 zu senden und zu überprüfen, wie die Firewall damit umgeht.
Aktivieren Sie den Befehl igmp static-group an der Firewall INSIDE-Schnittstelle, und überprüfen Sie, wie der Multicast-Stream (IP 230.11.11.11) von der Firewall verarbeitet wird.
Aktivieren Sie den Befehl igmp static-group an der Firewall INSIDE-Schnittstelle, und überprüfen Sie, wie der Multicast-Stream (IP 230.11.11.11) von der Firewall verarbeitet wird.

Lösung

Die Firewall verfügt über keine Routen für die 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

Eine einfache Möglichkeit zum Testen von Multicast ist die Verwendung des ICMP-Ping-Tools. Starten Sie in diesem Fall einen Ping vom R2 zur Multicast-IP-Adresse 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:
...............................

Auf der Firewall wird dynamisch eine Route erstellt, und das OIL ist leer:

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

Die Erfassung auf der Firewall zeigt Folgendes:

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

Die Firewall erstellt für jeden Ping eine Verbindung, verwirft jedoch die Pakete unbeaufsichtigt:

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

Hinweis: Bei der LINA ASP-Abwurfaufzeichnung werden die verworfenen Pakete nicht angezeigt.

Der Hauptindikator für das Verwerfen von Multicast-Paketen ist:

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

Konfigurieren Sie auf FMC eine statische IGMP-Gruppe:

igmp_static_config

Im Hintergrund wird Folgendes bereitgestellt:

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

Der Ping schlägt fehl, aber der ICMP-Multicast-Verkehr wird nun durch die Firewall weitergeleitet:

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

Hinweis: Die Ablaufverfolgung des Pakets zeigt eine falsche Ausgabe an (die Eingangsschnittstelle ist mit der Ausgangsschnittstelle identisch). Weitere Informationen finden Sie unter Cisco Bug ID 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

Tipp: Sie können einen Ping mit Timeout 0 vom Quellhost senden und die Firewall-Konfigurationszähler überprüfen:

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

Auf FMC-Remote-Server die zuvor konfigurierte statische Gruppe konfigurieren und eine IGMP-Beitrittsgruppe konfigurieren:

igmp_join_config

igmp_join_topology

Die bereitgestellte Konfiguration:

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

Die IGMP-Gruppe:

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

Testen Sie vom Quellhost aus den ersten ICMP-Multicast-Test in Richtung 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

Hinweis: Wenn nicht alle Antworten angezeigt werden, überprüfen Sie die Cisco Bug-ID CSCvm90069.

Schritt 4: Konfigurieren von IGMP-Stub-Multicast-Routing

stub_topology

Konfigurieren Sie das Stub-Multicast-Routing auf FTD, sodass die auf der INSIDE-Schnittstelle empfangenen IGMP-Mitgliedschaftsberichte an die OUTSIDE-Schnittstelle weitergeleitet werden.

Lösung

Die bereitgestellte Konfiguration:

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

Verifizierung

Erfassung auf FTD aktivieren:

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

Verifizierung

Um einen IGMP-Mitgliedschaftsbericht zu erzwingen, können Sie eine Anwendung wie VLC verwenden:

vlc_play_ip_stream

Der FTD leitet die IGMP-Pakete weiter:

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

Die FTD ändert die Quell-IP:

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

Wenn Sie die pcap in Wireshark überprüfen, können Sie sehen, dass das Paket vollständig von der Firewall neu generiert wird (die IP-Identifikation ändert sich).

Ein Gruppeneintrag wird auf FTD erstellt:

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

Die FTD-Firewall erstellt zwei Verbindungen auf Kontrollebene:

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

Nachverfolgung des ersten Pakets:

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

Bekannte Probleme

Filtern von Multicast-Datenverkehr in Zielzonen

Sie können keine Zielsicherheitszone für die Zugriffssteuerungsrichtlinienregel angeben, die mit dem Multicast-Verkehr übereinstimmt:

acp_misconfig

Dies wird auch im FMC-Benutzerhandbuch dokumentiert:

fmc_config_guide

IGMP-Berichte werden von der Firewall abgelehnt, wenn der IGMP-Schnittstellengrenzwert überschritten wird

Standardmäßig lässt die Firewall maximal 500 aktive Joins (Berichte) auf einer Schnittstelle zu. Wenn dieser Grenzwert überschritten wird, ignoriert die Firewall zusätzliche eingehende IGMP-Berichte von den Multicast-Empfängern.

Um die IGMP-Beschränkung und die aktiven Joins zu überprüfen, führen Sie den Befehl show igmp interface name aus:

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)

Der IGMP-Debug-Befehl debug igmp zeigt folgende Ausgabe an:

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

Die Softwareversionen mit der Cisco Bug-ID CSCvw60976 Benutzer können bis zu 5.000 Gruppen pro Schnittstelle konfigurieren.

Die Firewall ignoriert IGMP-Berichte für den Adressbereich 232.x.x.x/8.

Der Adressbereich 232.x.x.x/8 ist für Source Specific Multicast (SSM) vorgesehen. Die Firewall unterstützt weder die PIM Source Specific Multicast (SSM)-Funktion noch die zugehörige Konfiguration.

Der IGMP-Debug-Befehl debug igmp zeigt folgende Ausgabe an:

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

Cisco Bug-ID CSCsr53916 verfolgt die Erweiterung zur Unterstützung des SSM-Bereichs.

Zugehörige Informationen

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	19-May-2022	Erstveröffentlichung

Beiträge von Cisco Ingenieuren

Mikis Zafeiroudis
Cisco TAC Engineer
Ilkin Gasimov
Cisco TAC Engineer

Fehlerbehebung: Firepower Threat Defense - IGMP- und Multicast-Grundlagen

Download-Optionen

Inklusive Sprache

Informationen zu dieser Übersetzung

Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Konfigurieren

IGMP-Grundlagen

Aufgabe 1: Multicast-Verkehr auf der Kontrollebene

Aufgabe 2: Konfigurieren von einfachem Multicast

IGMP-Snooping

Schritt 3: IGMP static-group und IGMP join-group

igmp static-group

igmp-Join-Gruppe

Schritt 4: Konfigurieren von IGMP-Stub-Multicast-Routing

Bekannte Probleme

Filtern von Multicast-Datenverkehr in Zielzonen

IGMP-Berichte werden von der Firewall abgelehnt, wenn der IGMP-Schnittstellengrenzwert überschritten wird

Die Firewall ignoriert IGMP-Berichte für den Adressbereich 232.x.x.x/8.

Zugehörige Informationen

Revisionsverlauf

Beiträge von Cisco Ingenieuren

War dieses Dokument hilfreich?

Cisco kontaktieren

Dieses Dokument gilt für folgende Produkte.