Fehlerbehebungsleitfaden für die Konfiguration von ZBFW für IOS-XE

Einführung

In diesem Dokument wird beschrieben, wie Sie die ZBFW-Funktion (Zone Based Firewall) auf dem Aggregation Services Router (ASR) 1000 am besten beheben können. Hierzu werden Befehle verwendet, mit denen die Hardware-Drop-Zähler auf dem ASR abgefragt werden. Die ASR1000 ist eine hardwarebasierte Weiterleitungsplattform. Die Softwarekonfiguration von Cisco IOS-XE^® programmiert die Hardware-ASICs (Quantum Flow Processor (QFP)), um Funktionen zur Funktionsweiterleitung auszuführen. Dies ermöglicht einen höheren Durchsatz und eine bessere Leistung. Der Nachteil dabei ist, dass die Fehlerbehebung eine größere Herausforderung darstellt. Herkömmliche Cisco IOS-Befehle, die zum Abfragen aktueller Sitzungen und zum Ablegen von Zählern über eine zonenbasierte Firewall (ZBFW) verwendet werden, sind nicht mehr gültig, da diese in der Software nicht mehr enthalten sind. 

Links und Dokumentation

Befehlsreferenzen

• Cisco Aggregation Services Router der Serie ASR 1000 - Befehlsreferenzen
• Cisco IOS XE 3S-Befehlsreferenzen

Schritte zur Datenpflege

Um eine Fehlerbehebung für den Datenpfad durchzuführen, müssen Sie ermitteln, ob der Datenverkehr ordnungsgemäß über den ASR- und den Cisco IOS-XE-Code geleitet wird. Speziell für Firewall-Funktionen führt die Datenpfadfehlerbehebung die folgenden Schritte aus:

1. Konfiguration überprüfen - Ermitteln Sie die Konfiguration, und überprüfen Sie die Ausgabe, um die Verbindung zu überprüfen.
   
   
2. Verbindungsstatus überprüfen: Wenn der Datenverkehr ordnungsgemäß verläuft, öffnet Cisco IOS-XE eine Verbindung mit der ZBFW-Funktion. Diese Verbindung verfolgt den Datenverkehr und die Statusinformationen zwischen einem Client und Server.
   
   
3. Verifizieren von Drop-Zählern - Wenn der Datenverkehr nicht ordnungsgemäß verläuft, protokolliert Cisco IOS-XE einen Drop-Zähler für verworfene Pakete. Überprüfen Sie diese Ausgabe, um die Ursache für den Datenverkehrsausfall zu identifizieren.
   
   
4. Protokollierung - Erfasst Syslogs, um detailliertere Informationen über Verbindungsbuilds und Paketverluste bereitzustellen.
   
   
5. Paketverfolgung verlorene Pakete - Mithilfe der Paketverfolgung können verlorene Pakete abgefangen werden.
   
   
6. Debugs - Die ausführlichste Option Debuggen sammeln. Debugger können nur bedingt abgerufen werden, um den genauen Weiterleitungspfad für die Pakete zu bestätigen.

Konfiguration überprüfen

Die Ergebnisse von show tech support firewall sind hier zusammengefasst:

-------- show clock --------
-------- show version -------
-------- show running-config --------
-------- show parameter-map type inspect --------
-------- show policy-map type inspect -------
-------- show class-map type inspect --------
-------- show zone security --------
-------- show zone-pair security --------
-------- show policy-firewall stats global --------
-------- show policy-firewall stats zone --------
-------- show platform hardware qfp active feature firewall datapath <submode> --------
-------- show platform software firewall RP <submode> --------

Verbindungsstatus überprüfen

Verbindungsinformationen können abgerufen werden, sodass alle Verbindungen auf ZBFW aufgelistet sind. Geben Sie den folgenden Befehl ein:

ASR#show policy-firewall sessions platform           
--show platform hardware qfp active feature firewall datapath scb any any any any any all any --
[s=session  i=imprecise channel  c=control channel  d=data channel]
 14.38.112.250 41392 14.36.1.206 23 proto 6 (0:0)    [sc]

Es wird eine TCP-Telnet-Verbindung zwischen 14.38.112.250 und 14.36.1.206 angezeigt.

Hinweis: Beachten Sie, dass es bei Ausführung dieses Befehls sehr lange dauert, wenn auf dem Gerät viele Verbindungen vorhanden sind. Cisco empfiehlt die Ausführung dieses Befehls mit speziellen Filtern, wie hier beschrieben.

Die Verbindungstabelle kann bis zu einer bestimmten Quell- oder Zieladresse gefiltert werden. Verwenden Sie Filter nach dem Plattform-Submodus. Folgende Filteroptionen stehen zur Verfügung:

radar-ZBFW1#show policy-firewall sessions platform ?
  all                     detailed information
  destination-port        Destination Port Number
  detail                  detail on or off
  icmp                    Protocol Type ICMP
  imprecise               imprecise information
  session                 session information
  source-port             Source Port
  source-vrf              Source Vrf ID
  standby                 standby information
  tcp                     Protocol Type TCP
  udp                     Protocol Type UDP
  v4-destination-address  IPv4 Desination Address
  v4-source-address       IPv4 Source Address
  v6-destination-address  IPv6 Desination Address
  v6-source-address       IPv6 Source Address
  |                       Output modifiers
  <cr>

Diese Verbindungstabelle wird gefiltert, sodass nur Verbindungen angezeigt werden, die vom 14.38.112.250 stammen:

ASR#show policy-firewall sessions platform v4-source-address 14.38.112.250
--show platform hardware qfp active feature firewall datapath scb 14.38.112.250
 any any any any all any --
[s=session  i=imprecise channel  c=control channel  d=data channel]
 14.38.112.250 41392 14.36.1.206 23 proto 6 (0:0)    [sc]

Nach dem Filtern der Verbindungstabelle können die detaillierten Verbindungsinformationen für eine umfassendere Analyse abgerufen werden. Um diese Ausgabe anzuzeigen, verwenden Sie das detail-Schlüsselwort.

ASR#show policy-firewall sessions platform v4-source-address 14.38.112.250 detail
--show platform hardware qfp active feature firewall datapath scb 14.38.112.250
 any any any any all any detail--
[s=session  i=imprecise channel  c=control channel  d=data channel]
 14.38.112.250 41426 14.36.1.206 23 proto 6 (0:0)       [sc]
 pscb : 0x8c5d4f20,  bucket : 64672, fw_flags: 0x204 0x20419441,
        scb state: active, scb debug: 0
 nxt_timeout: 360000, refcnt: 1,  ha nak cnt: 0,  rg: 0, sess id: 117753
 hostdb: 0x0, L7: 0x0, stats: 0x8e118e40, child: 0x0
 l4blk0: 78fae7a7 l4blk1: e36df99c l4blk2: 78fae7ea l4blk3: 39080000
 l4blk4: e36df90e l4blk5: 78fae7ea l4blk6: e36df99c l4blk7: fde0000
 l4blk8: 0 l4blk9: 1
 root scb: 0x0 act_blk: 0x8e1115e0
 ingress/egress intf: GigabitEthernet0/0/2 (1021), GigabitEthernet0/0/0 (131065)
 current time 34004163065573 create tstamp: 33985412599209 last access: 33998256774622
 nat_out_local_addr:port: 0.0.0.0:0 nat_in_global_addr:port: 0.0.0.0:0
 syncookie fixup: 0x0
 halfopen linkage: 0x0 0x0
 cxsc_cft_fid: 0x0
 tw timer: 0x0 0x0 0x372ba 0x1e89c181
 Number of simultaneous packet per session allowed: 25
    bucket 125084 flags 1 func 1 idx 8 wheel 0x8ceb1120

Firewall-Drop-Zähler überprüfen

Die Ausgabe des Drop-Zählers hat sich während XE 3.9 geändert. Vor XE 3.9 waren die Gründe für einen Firewall-Ausfall sehr allgemein. Nach XE 3.9 wurden die Gründe für den Firewall-Ausfall erweitert, um eine präzisere Handhabung zu ermöglichen.

Führen Sie zwei Schritte aus, um Drop-Zähler zu überprüfen:

1. Bestätigen Sie die globalen Drop-Zähler in Cisco IOS-XE. Diese Zähler zeigen an, welche Funktion den Datenverkehr verworfen hat. Beispiele für Funktionen sind Quality of Service (QoS), Network Address Translation (NAT), Firewall usw.
   
   
2. Nachdem die Unterfunktion identifiziert wurde, fragen Sie die detaillierten Ablagezähler ab, die von der Unterfunktion bereitgestellt werden. In diesem Leitfaden ist die zu analysierende Unterfunktion die Firewall-Funktion.

Globale Drop-Zähler für QFP

Der grundlegende Befehl, auf den man sich verlassen muss, enthält alle Dropdown-Menüs im QFP:

Router#show platform hardware qfp active statistics drop

Dieser Befehl zeigt die globalen Drops im QFP an. Diese Drops können für jede Funktion verwendet werden. Einige Beispielfunktionen sind:

Ipv4Acl
Ipv4NoRoute
Ipv6Acl
Ipv6NoRoute
NatIn2out
VfrErr
...etc

Um alle Verwerfen anzuzeigen, schließen Sie Zähler mit dem Wert 0 ein, verwenden Sie den folgenden Befehl:

show platform hardware qfp active statistics drop all

Um die Zähler zu löschen, verwenden Sie diesen Befehl. Die Ausgabe wird gelöscht, nachdem sie auf dem Bildschirm angezeigt wurde. Dieser Befehl ist beim Lesen deutlich sichtbar, sodass die Ausgabe nach Anzeige auf dem Bildschirm auf Null zurückgesetzt wird.

show platform hardware qfp active statistics drop clear

Nachfolgend finden Sie eine Liste der globalen QFP-Firewall-Drop-Zähler und Erklärungen:

Globale Firewall-Sperrgrund	Erläuterung
Firewall-Backdruck	Paketverlust aufgrund von Rückdruck durch Protokollierungsmechanismus.
FirewallInvalidZone	Keine Sicherheitszone für die Schnittstelle konfiguriert.
FirewallL4insp	Fehler bei der L4-Richtlinienüberprüfung. In der Tabelle unten finden Sie detailliertere Gründe für das Verwerfen von Firewall-Funktionen (Gründe für das Verwerfen von Firewall-Funktionen).
FirewallNoForwardingZone	Die Firewall ist nicht initialisiert, und es darf kein Datenverkehr passieren.
FirewallKeine Sitzung	Die Sitzungserstellung schlägt fehl. Dies kann darauf zurückzuführen sein, dass die maximale Sitzungsgrenze erreicht oder ein Speicherzuweisungsfehler aufgetreten ist.
FirewallPolicy	Die konfigurierte Firewall-Richtlinie wird verworfen.
FirewallL4	Fehler bei L4-Prüfung. Die nachfolgende Tabelle enthält detailliertere Gründe für einen Ausfall der Firewall-Funktion.
FirewallL7	Paketverlust aufgrund von L7-Prüfung. Im Folgenden finden Sie eine Liste detaillierterer L7-Gründe (Gründe für Firewall-Feature-Drop).
FirewallNotInitiator	Kein Sitzungsinitiator für TCP, UDP oder ICMP. Es wird keine Sitzung erstellt. Für ICMP ist das erste empfangene Paket beispielsweise nicht ECHO oder TIMESTAMP. Bei TCP handelt es sich nicht um ein SYN. Dies kann bei der normalen Paketverarbeitung oder bei der ungenauen Kanalverarbeitung der Fall sein.
FirewallNoNewSession	Die hohe Firewall-Verfügbarkeit lässt keine neuen Sitzungen zu.
FirewallSyncookieMaxDst	Um einen hostbasierten SYN-Flood-Schutz zu bieten, gibt es eine SYN-Rate pro Ziel als SYN-Flood-Grenzwert. Wenn die Anzahl der Zieleinträge die Grenze erreicht, werden neue SYN-Pakete verworfen.
FirewallSyncookie	SYNCOOLIE-Logik wird ausgelöst. Dies weist darauf hin, dass SYN/ACK mit dem SYN-Cookie gesendet wurde und das ursprüngliche SYN-Paket verworfen wurde.
FirewallARStandby	Asymmetric Routing ist nicht aktiviert, und die Redundanzgruppe ist nicht im aktiven Zustand.

Firewall Feature Drop Zähler für QFP

Die Einschränkung beim globalen QFP-Drop-Zähler besteht darin, dass die Drop-Gründe nicht präzise genug sind, und einige Gründe wie FirewallL4 werden so überlastet, dass sie für die Fehlerbehebung wenig nützlich sind. Dies wurde seither in Cisco IOS-XE 3.9 (15.3(2)S) verbessert, wo die Zähler für die Firewall-Feature-Drop hinzugefügt wurden. Dies führt zu einer sehr viel präziseren Auswahl an Gründen:

ASR#show platform hardware qfp active feature firewall drop all
-------------------------------------------------------------------------------
Drop Reason                                                             Packets
-------------------------------------------------------------------------------
Invalid L4 header                                                             0
Invalid ACK flag                                                              0
Invalid ACK number                                                            0
....

Im Folgenden finden Sie eine Liste mit Gründen und Erklärungen zu Firewall-Funktionen:

Firewall-Feature-Dropdown-Grund	Erläuterung
Ungültige Headerlänge	Das Datagramm ist so klein, dass es den Layer-4-TCP-, UDP- oder ICMP-Header nicht enthalten konnte. Dies kann durch folgende Faktoren verursacht werden: TCP-Header-Länge < 20 UDP-/ICMP-Headerlänge < 8
Ungültige UDP-Datenlänge	Die UDP-Datagrammlänge stimmt nicht mit der im UDP-Header angegebenen Länge überein.
Ungültige ACK-Nummer	Dieser Rückgang könnte auf einen der folgenden Gründe zurückzuführen sein: ACK entspricht nicht dem nächsten_seq# des TCP-Peers. Das ACK ist größer als der letzte vom TCP-Peer gesendete FF#. Im TCP-SYNSENT- und SYNRCVD-Zustand wird erwartet, dass die ACK# gleich ISN+1 ist, dies jedoch nicht.
Ungültige ACK-Markierung	Dieser Rückgang könnte auf einen der folgenden Gründe zurückzuführen sein: ACK-Flag wird erwartet, jedoch nicht in einem anderen TCP-Status festgelegt. Außer dem ACK-Flag wird auch ein anderes Flag (wie RST) gesetzt.
Ungültiger TCP-Initiator	Dies geschieht in folgenden Fällen: Das erste Paket von einem TCP-Initiator ist keine SYN (kein initiales TCP-Segment wird ohne gültige Sitzung empfangen). Für das erste SYN-Paket ist das ACK-Flag festgelegt.
SYN mit Daten	Das SYN-Paket enthält Payload. Dies wird nicht unterstützt.
Ungültige TCP-Flags	Ungültige TCP-Flags können durch Folgendes verursacht werden: Das erste TCP-SYN-Paket enthält andere Flags als SYN. Im TCP-Listen-Zustand empfängt ein TCP-Peer einen RST oder ein ACK. Das Paket des anderen Responders wird vor SYN/ACK empfangen. Die erwartete SYN/ACK-Nummer wird nicht vom Responder empfangen.
Ungültiges Segment im SYNSENT-Status	Ein ungültiges TCP-Segment im SYNSENT-Status wird verursacht durch: SYN/ACK hat Payload. SYN/ACK hat andere Flags (PSH, URG, FIN) gesetzt. Empfangen einer Transit-SYN mit Nutzlast. Empfangen eines Nicht-SYN-Pakets vom Initiator.
Ungültiges Segment im SYNRCVD-Status	Ein ungültiges TCP-Segment im SYNRCVD-Status könnte durch folgende Faktoren verursacht werden: Empfangen einer SYN für die erneute Übertragung mit Payload vom Initiator. Erhalten Sie vom Responder ein ungültiges Segment, das nicht SYN/ACK, RST oder FIN ist.
Ungültiges Format	Dies tritt im SYNRCVD-Zustand auf, wenn Segmente vom Initiator stammen. Sie wird verursacht durch: Seq# ist kleiner als ISN. Wenn die Größe des rcvd-Fensters des Empfängers 0 und ist: Segment hat Nutzlast oder  Out of Order Segment (seq# ist größer als Empfänger LASTACK. Wenn der Empfänger rcvd Fenstergröße 0 ist und seq# über das Fenster fällt. Seq# entspricht ISN, aber kein SYN-Paket.
Ungültige Fensterskalierungsoption	Die Option für die TCP-Fensterskalierung ist ungültig, da die Option für die Fenstergröße in Byte-Länge falsch ist.
TCP außerhalb des Fensters	Das Paket ist zu alt - ein Fenster hinter dem ACK der anderen Seite. Dies kann im Status ESTABLISHED, CLOSEWAIT und LASTACK geschehen.
TCP-zusätzliche Payload nach Versand von FIN	Payload, die nach dem Senden der FIN-Nachricht empfangen wurde. Dies könnte im CLOSEWAIT-Staat passieren.
TCP Window Overflow	Dies tritt auf, wenn die Größe eingehender Segmente das Fenster des Empfängers überschreibt. Wenn jedoch vTCP aktiviert ist, ist diese Bedingung zulässig, da die Firewall das Segment puffern muss, damit ALG es später nutzen kann.
Wiederholt mit ungültigen Flags	Ein erneut übertragenes Paket wurde bereits vom Empfänger bestätigt.
TCP-Out-of-Order-Segment	Das Out-of-Order-Paket wird bald zur Prüfung an L7 geliefert. Wenn L7 kein OOO-Segment zulässt, wird dieses Paket verworfen.
SYN Flood	Bei einem TCP SYN Flood-Angriff. Unter bestimmten Bedingungen, wenn die aktuellen Verbindungen zu diesem Host den konfigurierten halb-offenen Wert überschreiten, lehnt die Firewall neue Verbindungen zu dieser IP-Adresse für einen bestimmten Zeitraum ab. Dadurch werden die Pakete verworfen.
Interner Fehler - Synflood-Überprüfung fehlerhaft	Bei der Synflood-Überprüfung schlägt die Zuweisung von hostdb fehl.  Empfohlene Aktion: Aktivieren Sie "show platform hardware qfp active feature firewall memory" (Plattform-Hardware-QFP-Firewall-Arbeitsspeicher anzeigen), um den Speicherstatus zu überprüfen.
Synflood Blackout Drop	Wenn konfigurierte Half-Open-Verbindungen überschritten und die Blackout-Zeit konfiguriert wird, werden alle neuen Verbindungen zu dieser IP-Adresse verworfen.
Halboffene Sitzungsbegrenzung überschritten	Das aufgrund der zulässigen halb geöffneten Sitzungen verworfene Paket wurde überschritten. Überprüfen Sie außerdem die Einstellungen für "max-uncomplete high/low" und "one minute high/low", um sicherzustellen, dass die Anzahl der halb geöffneten Sitzungen durch diese Konfigurationen nicht gedrosselt wird.
Zu viele Pkt pro Fluss	Die maximal zulässige Anzahl an überprüfbaren Paketen pro Datenfluss wird überschritten. Die maximale Anzahl beträgt 25.
Zu viele ICMP-Fehlerpakete pro Flow	Die maximal zulässige Anzahl an ICMP-Fehlerpaketen pro Datenfluss wird überschritten. Die maximale Anzahl beträgt 3.
Unerwartete TCP-Payload vom RSP zum Init	Im SYNRCVD-Status empfängt TCP ein Paket mit Payload vom Responder auf die Richtung des Initiators.
Interner Fehler - Nicht definierte Richtung	Paketrichtung nicht definiert.
SYN im aktuellen Fenster	Ein SYN-Paket wird im Fenster einer bereits bestehenden TCP-Verbindung angezeigt.
RST im aktuellen Fenster	Ein RST-Paket wird im Fenster einer bereits bestehenden TCP-Verbindung beobachtet.
Streamsegment	Es wird ein TCP-Segment empfangen, das nicht über den TCP-Statuscomputer empfangen werden sollte, z. B. ein TCP-SYN-Paket, das vom Responder im Listen-Zustand empfangen wurde.
Interner ICMP-Fehler - fehlende ICMP NAT-Informationen	Das ICMP-Paket ist nicht vorhanden, aber interne NAT-Informationen fehlen. Dies ist ein interner Fehler.
ICMP-Paket im SCB-Nahzustand	ICMP-Paket im SCB CLOSE-Status empfangen.
Verpasster IP-Header im ICMP-Paket	IP-Header im ICMP-Paket fehlt.
ICMP-Fehler Keine IP oder ICMP	ICMP-Fehlerpaket ohne IP oder ICMP in Nutzlast. Wird wahrscheinlich durch ein fehlerhaftes Paket oder einen Angriff verursacht.
ICMP-Err-Pkt zu kurz	Das ICMP-Fehlerpaket ist zu kurz.
ICMP-Fehler überschreitet Burst-Grenzwert	ICMP Error Pkt überschreitet die Burst-Grenze von 10.
ICMP-Fehler nicht erreichbar	Der ICMP-Fehler Pkt nicht erreichbar überschreitet den Grenzwert. Nur das 1. nicht erreichbare Paket darf passieren.
ICMP-Fehler ungültiges Suchkennzeichen	Die SEQ# des integrierten Pakets entspricht nicht der seq# des Pakets, das den ICMP-Fehler auslöst.
ICMP-Fehler ungültig	Ungültiges ACK im integrierten ICMP-Fehler-Paket.
ICMP Action Drop	Die konfigurierte ICMP-Aktion wird verworfen.
Zonenpaar ohne Richtlinienzuweisung	Die Richtlinie ist für Zonenpaar nicht vorhanden. Dies kann darauf zurückzuführen sein, dass ALG (Application Layer Gateway) nicht so konfiguriert wurde, dass das Nadelloch für den Anwendungsdatenkanal geöffnet wird, dass ALG das Pinloch nicht richtig geöffnet hat oder dass aufgrund von Skalierbarkeitsproblemen kein Pinloch geöffnet wird.
Sitzung fehlt, Richtlinie nicht vorhanden	Sitzungssuche fehlgeschlagen, und es ist keine Richtlinie vorhanden, um dieses Paket zu überprüfen.
ICMP-Fehler und -Richtlinie nicht vorhanden	ICMP-Fehler ohne Konfiguration einer Richtlinie für Zonenpaar.
Klassifizierung fehlgeschlagen	Klassifizierungsfehler in einem bestimmten Zonenpaar, wenn die Firewall versucht festzustellen, ob das Protokoll inspizierbar ist.
Löschung einer Klassifizierungsaktion	Die Klassifizierungsaktion wird gelöscht.
Misconfig der Sicherheitsrichtlinie	Fehlgeschlagene Klassifizierung aufgrund einer fehlerhaften Konfiguration der Sicherheitsrichtlinien. Dies kann auch darauf zurückzuführen sein, dass für den L7-Datenkanal kein Pinpol vorhanden ist.
RST an Antwort senden	Senden Sie RST an Responder im SYNSENT-Status, wenn ACK# nicht gleich ISN+1 ist.
Firewall-Policy-Drop	Policy Action is to drop.
Fragment-Verlust	Verbleibende Fragmente werden gelöscht, wenn das erste Fragment verworfen wird.
ICMP-Firewall Policy Drop	Die Richtlinienaktion des integrierten ICMP-Pakets lautet DROP.
L7-Inspektionsrücksendungen DROP	L7 (ALG) beschließt, Pakete zu verwerfen. Der Grund hierfür kann aus verschiedenen ALG-Statistiken abgeleitet werden.
L7-Segment-Pkt nicht zulassen	Empfangenes segmentiertes Paket, wenn ALG es nicht einhält.
L7 Fragment-Pkt nicht zulassen	Empfangene fragmentierte (oder VFR-)Pakete, wenn ALG sie nicht einhält.
Unbekannter L7-Prootyp	Nicht erkannter Protokolltyp.

Fehlerbehebung bei Firewall-Ausfällen

Sobald der Grund für den Ausfall anhand der oben genannten globalen oder Firewall-Feature-Drop-Zähler identifiziert wurde, können weitere Schritte zur Fehlerbehebung erforderlich sein, wenn diese Verwerfen unerwartet auftreten. Abgesehen von der Konfigurationsvalidierung muss für den betreffenden Datenverkehrsfluss häufig eine Paketerfassung durchgeführt werden, um sicherzustellen, dass die Konfiguration für die aktivierten Firewall-Funktionen korrekt ist, um festzustellen, ob die Pakete fehlerhaft sind oder ob Probleme mit der Protokoll- oder Anwendungsimplementierung vorliegen.

Protokollierung

Die ASR-Protokollierungsfunktion generiert Syslogs, um verlorene Pakete aufzuzeichnen. Diese Syslogs liefern weitere Details darüber, warum das Paket verworfen wurde. Es gibt zwei Arten von Sysloggings:

1. Lokale gepufferte Syslogging-Protokollierung
   
   
2. Remote-Hochgeschwindigkeitsprotokollierung

Lokales gepuffertes Syslogging

Um die Ursache der Verwerfen zu isolieren, können Sie eine generische ZBFW-Fehlerbehebung verwenden, z. B. das Aktivieren von Protokollverwerfen. Die Protokollierung von Paketverlusten kann auf zwei Arten konfiguriert werden.

Methode 1: Verwenden Sie inspect-global parameter-map, um alle verworfenen Pakete zu protokollieren.

parameter-map type inspect-global     log dropped-packets

Methode 2: Verwenden Sie eine benutzerdefinierte inspect parameter-map, um verlorene Pakete nur für eine bestimmte Klasse zu protokollieren.

parameter-map type inspect LOG_PARAM
     log dropped-packets
!
policy-map type inspect ZBFW_PMAP
  class type inspect ZBFW_CMAP
   inspect LOG_PARAM

Diese Meldungen werden je nach Konfiguration des ASR für die Protokollierung an das Protokoll oder die Konsole gesendet. Hier sehen Sie ein Beispiel für eine Drop-Log-Meldung.

*Apr  8 13:20:39.075: %IOSXE-6-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:103
 TS:00000605668054540031 %FW-6-DROP_PKT: Dropping tcp pkt from GigabitEthernet0/0/2
 14.38.112.250:41433 => 14.36.1.206:23(target:class)-(INSIDE_OUTSIDE_ZP:class-default)
 due to Policy drop:classify result with ip ident 11579 tcp flag 0x2, seq 2014580963,
 ack 0

Einschränkungen bei der lokalen Syslogging-Protokollierung

1. Diese Protokolle sind gemäß Cisco Bug ID CSCud09943 begrenzt.
   
   
2. Diese Protokolle werden möglicherweise nur gedruckt, wenn eine spezifische Konfiguration angewendet wurde. Beispielsweise werden Pakete, die durch Standardpakete der Klasse verworfen wurden, nur protokolliert, wenn das log-Schlüsselwort angegeben wurde:

policy-map type inspect ZBFW_PMAP
  class class-default
   drop log

Remote-Hochgeschwindigkeitsprotokollierung

Hochgeschwindigkeitsprotokollierung (HSL) erzeugt Syslogs direkt vom QFP und sendet sie an den konfigurierten NetFlow HSL Collector. Dies ist die empfohlene Protokollierungslösung für die ZBFW auf dem ASR.

Verwenden Sie für HSL folgende Konfiguration:

parameter-map type inspect inspect-global
   log template timeout-rate 1
   log flow-export v9 udp destination 1.1.1.1 5555

Um diese Konfiguration verwenden zu können, ist ein NetFlow Collector erforderlich, der Netflow Version 9 unterstützen kann. Dies wird in detailliert beschrieben. 

Konfigurationsanleitung: Zonenbasierte Firewall, Cisco IOS XE Release 3S (ASR 1000), Firewall Hochgeschwindigkeits-Protokollierung

Ablaufverfolgung von Paketen mithilfe von konditioneller Übereinstimmung

Aktivieren Sie bedingtes Debuggen, um die Paketverfolgung zu aktivieren und anschließend die Paketverfolgung für die folgenden Funktionen zu aktivieren:

ip access-list extended CONDITIONAL_ACL
  permit ip host 10.1.1.1 host 192.168.1.1
  permit ip host 192.168.1.1 host 10.1.1.1
!
debug platform condition feature fw dataplane submode all level info
debug platform condition ipv4 access-list CONDITIONAL_ACL both 

Hinweis: Die Übereinstimmung-Bedingung kann die IP-Adresse direkt verwenden, da keine ACL erforderlich ist. Dies entspricht als Quelle oder Ziel, das bidirektionale Spuren ermöglicht. Diese Methode kann verwendet werden, wenn Sie die Konfiguration nicht ändern dürfen. Beispiel: debug plattform condition ipv4 address 192.168.1.1/32.

Aktivieren Sie die Funktion zur Paketverfolgung:

debug platform packet-trace copy packet both
debug platform packet-trace packet 16
debug platform packet-trace drop
debug platform packet-trace enable

Es gibt zwei Möglichkeiten, diese Funktion zu verwenden:

1. Geben Sie den Befehl debug platform packet-trace ein, um nur die verworfenen Pakete zu verfolgen.
   
   
2. Durch den Ausschluss des Befehls debug platform packet-trace drop werden alle Pakete verfolgt, die mit der Bedingung übereinstimmen, einschließlich der Pakete, die vom Gerät geprüft/übergeben werden.

Aktivieren von bedingtem Debuggen:

debug platform condition start

Führen Sie den Test aus, und deaktivieren Sie dann die Debugger:

debug platform condition stop

Jetzt können die Informationen auf dem Bildschirm angezeigt werden. In diesem Beispiel wurden ICMP-Pakete aufgrund einer Firewall-Richtlinie verworfen:

Router#show platform packet-trace statistics
Packets Summary
  Matched  2
  Traced   2
Packets Received
  Ingress  2
  Inject   0
Packets Processed
  Forward  0
  Punt     0
  Drop     2
    Count       Code  Cause
    2           183   FirewallPolicy
  Consume  0

Router#show platform packet-trace summary
Pkt   Input            Output           State  Reason
0     Gi0/0/2          Gi0/0/0          DROP   183 (FirewallPolicy)
1     Gi0/0/2          Gi0/0/0          DROP   183 (FirewallPolicy)

Router#show platform packet-trace packet 0
Packet: 0           CBUG ID: 2980
Summary
  Input     : GigabitEthernet0/0/2
  Output    : GigabitEthernet0/0/0
  State     : DROP 183 (FirewallPolicy)
  Timestamp
    Start   : 1207843476722162 ns (04/15/2014 12:37:01.103864 UTC)
    Stop    : 1207843477247782 ns (04/15/2014 12:37:01.104390 UTC)
Path Trace
  Feature: IPV4
    Source      : 10.1.1.1
    Destination : 192.168.1.1
    Protocol    : 1 (ICMP)
  Feature: ZBFW
    Action  : Drop
    Reason  : ICMP policy drop:classify result
    Zone-pair name  : INSIDE_OUTSIDE_ZP
    Class-map name  : class-default
Packet Copy In
  c89c1d51 5702000c 29f9d528 08004500 00540000 40004001 ac640e26 70fa0e24
  01010800 172a2741 00016459 4d5310e4 0c000809 0a0b0c0d 0e0f1011 12131415
Packet Copy Out
  c89c1d51 5702000c 29f9d528 08004500 00540000 40003f01 ad640e26 70fa0e24
  01010800 172a2741 00016459 4d5310e4 0c000809 0a0b0c0d 0e0f1011 12131415

Der Befehl show platform packet-trace paket <num> decode dekodiert die Informationen und den Inhalt des Paket-Headers. Diese Funktion wurde in XE3.11 eingeführt:

Router#show platform packet-trace packet all decode
Packet: 0           CBUG ID: 2980
Summary
  Input     : GigabitEthernet0/0/2
  Output    : GigabitEthernet0/0/0
  State     : DROP 183 (FirewallPolicy)
  Timestamp
    Start   : 1207843476722162 ns (04/15/2014 12:37:01.103864 UTC)
    Stop    : 1207843477247782 ns (04/15/2014 12:37:01.104390 UTC)
Path Trace
  Feature: IPV4
    Source      : 10.1.1.1
    Destination : 192.168.1.1
    Protocol    : 1 (ICMP)
  Feature: ZBFW
    Action  : Drop
    Reason  : ICMP policy drop:classify result
    Zone-pair name  : INSIDE_OUTSIDE_ZP
    Class-map name  : class-default
Packet Copy In
  c89c1d51 5702000c 29f9d528 08004500 00540000 40004001 ac640e26 70fa0e24
  01010800 172a2741 00016459 4d5310e4 0c000809 0a0b0c0d 0e0f1011 12131415
  ARPA
    Destination MAC     : c89c.1d51.5702
    Source MAC          : 000c.29f9.d528
    Type                : 0x0800 (IPV4)
  IPv4
    Version             : 4
    Header Length       : 5
    ToS                 : 0x00
    Total Length        : 84
    Identifier          : 0x0000
    IP Flags            : 0x2 (Don't fragment)
    Frag Offset         : 0
    TTL                 : 64
    Protocol            : 1 (ICMP)
    Header Checksum     : 0xac64
    Source Address      : 10.1.1.1
    Destination Address : 192.168.1.1
  ICMP
    Type                : 8 (Echo)
    Code                : 0 (No Code)
    Checksum            : 0x172a
    Identifier          : 0x2741
    Sequence            : 0x0001
Packet Copy Out
  c89c1d51 5702000c 29f9d528 08004500 00540000 40003f01 ad640e26 70fa0e24
  01010800 172a2741 00016459 4d5310e4 0c000809 0a0b0c0d 0e0f1011 12131415
  ARPA
    Destination MAC     : c89c.1d51.5702
    Source MAC          : 000c.29f9.d528
    Type                : 0x0800 (IPV4)
  IPv4
    Version             : 4
    Header Length       : 5
    ToS                 : 0x00
    Total Length        : 84
    Identifier          : 0x0000
    IP Flags            : 0x2 (Don't fragment)
    Frag Offset         : 0
    TTL                 : 63
    Protocol            : 1 (ICMP)
    Header Checksum     : 0xad64
    Source Address      : 10.1.1.1
    Destination Address : 192.168.1.1
  ICMP
    Type                : 8 (Echo)
    Code                : 0 (No Code)
    Checksum            : 0x172a
    Identifier          : 0x2741
    Sequence            : 0x0001

Integrierte Paketerfassung

Die integrierte Paketerfassungs-Unterstützung wurde in Cisco IOS-XE 3.7 (15.2(4)S) hinzugefügt. Weitere Informationen finden Sie unter 

Integrierte Paketerfassung für Cisco IOS und IOS-XE - Konfigurationsbeispiel.

Debugger

Bedingtes Debuggen

In XE3.10 werden bedingte Debuggen eingeführt. Bedingte Anweisungen können verwendet werden, um sicherzustellen, dass die ZBFW-Funktion nur Debugmeldungen protokolliert, die für die Bedingung relevant sind. Bei der bedingten Fehlersuche werden ACLs verwendet, um Protokolle zu beschränken, die den ACL-Elementen entsprechen. Vor XE3.10 waren die Debug-Meldungen außerdem schwieriger zu lesen. Die Debug-Ausgabe wurde in XE3.10 verbessert, um sie einfacher zu verstehen.

Führen Sie folgenden Befehl aus, um diese Debugger zu aktivieren:

debug platform condition feature fw dataplane submode [detail | policy | layer4 | drop]
debug platform condition ipv4 access-list <ACL_name> both
debug platform condition start

Beachten Sie, dass der Condition-Befehl über eine ACL und eine Direktionalität festgelegt werden muss. Die bedingten Debuggen werden erst implementiert, wenn sie mit dem Befehl debug platform condition start gestartet werden. Um bedingte Debuggen zu deaktivieren, verwenden Sie den Befehl debug platform condition stop.

debug platform condition stop

Um bedingte Debuggen zu deaktivieren, verwenden Sie NICHT den Befehl undebug all. Verwenden Sie den folgenden Befehl, um alle bedingten Debugging-Vorgänge zu deaktivieren:

ASR#clear platform condition all

Vor XE3.14 sind ha- und Ereignis-Debug nicht bedingt. Infolgedessen ermöglicht der Befehl debug platform condition fw dataplane submode all die Erstellung aller Protokolle, unabhängig von der unten ausgewählten Bedingung. Dies kann zu zusätzlichen Geräuschen führen, die das Debuggen erschweren.

Standardmäßig ist die bedingte Protokollierungsebene info. Um die Protokollierungsebene zu erhöhen/zu verringern, verwenden Sie den folgenden Befehl:

debug platform condition feature fw dataplane submode all [verbose | warning]

Erfassen und Anzeigen von Debuggern

Debugdateien werden nicht auf die Konsole oder den Monitor gedruckt. Alle DebuggingInnen werden auf die Festplatte des ASR geschrieben. Debugger werden unter dem Ordner tracelogs mit dem Namen cpp_cp_F0-0.log auf die Festplatte geschrieben. Um die Datei anzuzeigen, in der Debugger geschrieben sind, verwenden Sie die Ausgabe:

ASR# cd harddisk:
ASR# cd tracelogs
ASR# dir cpp_cp_F0*Directory of harddisk:/tracelogs/cpp_cp_F0*

Directory of harddisk:/tracelogs/

3751962  -rwx     1048795  Jun 15 2010 06:31:51 +00:00
  cpp_cp_F0-0.log.5375.20100615063151
3751967  -rwx     1048887  Jun 15 2010 02:18:07 +00:00
  cpp_cp_F0-0.log.5375.20100615021807
39313059840 bytes total (30680653824 bytes free)

Jede Debugdatei wird als cpp_cp_F0-0.log.<date>-Datei gespeichert. Dabei handelt es sich um reguläre Textdateien, die mit TFTP aus dem ASR kopiert werden können. Die maximale Protokolldatei auf dem ASR beträgt 1 MB. Nach 1 MB werden die Debugger in eine neue Protokolldatei geschrieben. Aus diesem Grund wird jede Protokolldatei mit einem Zeitstempel versehen, um den Start der Datei anzuzeigen.

Protokolldateien können an diesen Speicherorten vorhanden sein:

harddisk:/tracelogs/
bootflash:/tracelogs/

Da Protokolldateien erst nach dem Rotieren angezeigt werden, kann die Protokolldatei mit dem folgenden Befehl manuell rotiert werden:

ASR# test platform software trace slot f0 cpp-control-process rotate

Dadurch wird sofort eine "cpp_cp"-Protokolldatei erstellt und eine neue Datei im QFP gestartet. Beispiel:

ASR#test platform software trace slot f0 cpp-control-process rotate
  Rotated file from: /tmp/fp/trace/stage/cpp_cp_F0-0.log.7311.20140408134406,
 Bytes: 82407, Messages: 431

ASR#more tracelogs/cpp_cp_F0-0.log.7311.20140408134406
04/02 10:22:54.462 : btrace continued for process ID 7311 with 159 modules
04/07 16:52:41.164 [cpp-dp-fw]: (info): QFP:0.0 Thread:110 TS:00000531990811543397
 :FW_DEBUG_FLG_HA:[]: HA[1]: Changing HA state to 9
04/07 16:55:23.503 [cpp-dp-fw]: (info): QFP:0.0 Thread:120 TS:00000532153153672298
 :FW_DEBUG_FLG_HA:[]: HA[1]: Changing HA state to 10
04/07 16:55:23.617 [buginf]: (debug): [system] Svr HA bulk sync CPP(0) complex(0)
 epoch(0) trans_id(26214421) rg_num(1)

Mit diesem Befehl können die Debugdateien zur Vereinfachung der Verarbeitung in einer einzelnen Datei zusammengeführt werden. Es führt alle Dateien im Verzeichnis zusammen und überschneidet sie je nach Zeit. Dies kann hilfreich sein, wenn die Protokolle sehr ausführlich sind und über mehrere Dateien hinweg erstellt werden:

ASR#request platform software trace slot rp active merge target bootflash:MERGED_OUTPUT.log
Creating the merged trace file: [bootflash:MERGED_OUTPUT.log]
 including all messages

Done with creation of the merged trace file: [bootflash:MERGED_OUTPUT.log]