Fehlerbehebung bei Sicherheitsgeräten

Problem

Lösung

Sie können eine Scheduler-Karte auf das Multilink-Paket und seine konstituierenden Links anwenden. Sie können zwar mehrere CoS-Komponenten mit der Schedulerzuordnung anwenden, konfigurieren Sie jedoch nur die erforderlichen Komponenten. Wir empfehlen, die Konfiguration der konstituierenden Verbindungen einfach zu halten, um unnötige Verzögerungen bei der Übertragung zu vermeiden.

Tabelle 1 zeigt die CoS-Komponenten an, die auf ein Multilink-Paket und seine konstituierenden Verbindungen angewendet werden sollen.

Problem

Lösung

Gehen Sie wie folgt vor, um Jitter und Latenz zu reduzieren:

1. Stellen Sie sicher, dass Sie eine Shaping-Rate für jeden konstituierenden Link konfiguriert haben.

2. Stellen Sie sicher, dass Sie keine Shaping-Rate auf der Link-Services-Schnittstelle konfiguriert haben.

3. Stellen Sie sicher, dass der konfigurierte Shaping-Rate-Wert gleich der physischen Schnittstellenbandbreite ist.

4. Wenn die Geschwindigkeiten richtig konfiguriert sind und der Jitter weiterhin besteht, wenden Sie sich an das Juniper Networks Technical Assistance Center (JTAC).

Problem

Lösung

Wenn LFI aktiviert ist, werden Datenpakete (nicht LFI) mit einem MLPPP-Header gekapselt und in Pakete einer bestimmten Größe fragmentiert. Die verzögerungsempfindlichen Sprachpakete (LFI) sind PPP-gekapselt und zwischen Datenpaketfragmenten interleaviert. Queuing und Load Balancing werden für LFI- und Nicht-LFI-Pakete unterschiedlich durchgeführt.

Um zu überprüfen, ob LFI korrekt ausgeführt wird, stellen Sie fest, dass Pakete fragmentiert und wie konfiguriert gekapselt sind. Nachdem Sie wissen, ob ein Paket als LFI-Paket oder als Nicht-LFI-Paket behandelt wird, können Sie bestätigen, ob das Load Balancing korrekt durchgeführt wurde.

Solution Scenario– Nehmen wir an, dass zwei Geräte von Juniper Networks, R0 und R1, durch ein Multilink-Paket lsq-0/0/0.0 verbunden sind, das zwei serielle Verbindungen aggregiert, se-1/0/0 und se-1/0/1. Auf R0 und R1 sind MLPPP und LFI auf der Schnittstelle der Link-Services aktiviert und der Fragmentierungsschwellenwert auf 128 Bytes festgelegt.

In diesem Beispiel haben wir einen Paketgenerator verwendet, um Sprach- und Datenströme zu generieren. Sie können die Paketerfassungsfunktion verwenden, um die Pakete auf der eingehenden Schnittstelle zu erfassen und zu analysieren.

Die folgenden zwei Datenströme wurden über das Multilink-Paket gesendet:

• 100 Datenpakete mit 200 Bytes (größer als der Fragmentierungsschwellenwert)

• 500 Datenpakete mit 60 Bytes (kleiner als die Fragmentierungsschwelle)

Die folgenden beiden Sprachströme wurden über das Multilink-Paket gesendet:

• 100 Sprachpakete mit 200 Bytes vom Quell-Port 100

• 300 Sprachpakete mit 200 Bytes vom Quell-Port 200

Um zu bestätigen, dass LFI und Load Balancing korrekt durchgeführt wurden:

1. Paketfragmentierung überprüfen. Geben Sie im Betriebsmodus den show interfaces lsq-0/0/0 Befehl ein, um zu überprüfen, ob große Pakete korrekt fragmentiert sind.

   Meaning— Die Ausgabe zeigt eine Zusammenfassung der Pakete, die das Gerät im Multilink-Paket transiten. Überprüfen Sie die folgenden Informationen im Multilink-Paket:

   • Die Gesamtzahl der Übertragungen von Paketen = 1000

   • Die Gesamtzahl der Transitfragmente=1100

   • Die Anzahl der fragmentierten Datenpakete =100

   Die Gesamtzahl der im Multilink-Paket gesendeten Pakete (600 + 400) entspricht der Anzahl der übertragenen Pakete (1000), was bedeutet, dass keine Pakete gelöscht wurden.

   Die Anzahl der Transitfragmente übersteigt die Anzahl der transitierenden Pakete um 100, was darauf hinweist, dass 100 große Datenpakete korrekt fragmentiert wurden.

   Corrective Action— Wenn die Pakete nicht richtig fragmentiert sind, überprüfen Sie die Konfiguration des Fragmentierungsschwellenwerts. Pakete, die kleiner als der angegebene Fragmentierungsschwellenwert sind, werden nicht fragmentiert.

2. Verifizieren Sie die Paketkapselung. Um herauszufinden, ob ein Paket als LFI- oder Nicht-LFI-Paket behandelt wird, bestimmen Sie seinen Kapselungstyp. LFI-Pakete sind PPP-gekapselt, und Nicht-LFI-Pakete werden mit PPP und MLPPP gekapselt. Ppp- und MLPPP-Kapselungen haben unterschiedliche Overheads, was zu unterschiedlichen Paketen führt. Sie können die Paketgrößen vergleichen, um den Kapselungstyp zu bestimmen.

   Ein kleines, nichtfragmentiertes Datenpaket enthält einen PPP-Header und einen einzigen MLPPP-Header. In einem großen fragmentierten Datenpaket enthält das erste Fragment einen PPP-Header und einen MLPPP-Header, aber die aufeinander folgenden Fragmente enthalten nur einen MLPPP-Header.

   PPP- und MLPPP-Kapselungen fügen einem Paket die folgende Anzahl von Bytes hinzu:

   • Die PPP-Kapselung fügt 7 Bytes hinzu:

     4 Bytes Header+2 Bytes Frame Check Sequence (FCS)+1 Byte, das im Leerlauf ist oder eine Flag enthält

   • MLPPP-Kapselung fügt zwischen 6 und 8 Bytes hinzu:

     4 Bytes PPP-Header+2 bis 4 Bytes Multilink-Header

   Abbildung 1 zeigt den Overhead an, der zu PPP- und MLPPP-Headern hinzugefügt wurde.

   Abbildung 1: PPP- und MLPPP-Header

   Bei CRTP-Paketen sind der Kapselungsaufwand und die Paketgröße sogar geringer als bei einem LFI-Paket. Weitere Informationen finden Sie im Beispiel: Konfigurieren des komprimierten Echtzeitübertragungsprotokolls.

   Tabelle 2 zeigt den Kapselungsaufwand für ein Datenpaket und ein Sprachpaket mit jeweils 70 Bytes. Nach der Kapselung ist die Größe des Datenpakets größer als die Größe des Sprachpakets.

   Tabelle 2: PPP- und MLPPP-Kapselungsaufwand

   Pakettyp	Kapselung	Anfängliche Paketgröße	Kapselungsaufwand	Paketgröße nach Kapselung
   Voice Packet (LFI)	PPP	70 Bytes	4 + 2 + 1 = 7 Bytes	77 Bytes
   Datenfragment (nicht-LFI) mit kurzer Sequenz	MLPPP	70 Bytes	4 + 2 + 1 + 4 + 2 = 13 Bytes	83 Bytes
   Datenfragment (Nicht-LFI) mit langer Sequenz	MLPPP	70 Bytes	4 + 2 + 1 + 4 + 4 = 15 Bytes	85 Bytes

   Geben Sie im Betriebsmodus den show interfaces queue Befehl ein, um die Größe des übertragenen Pakets in jeder Warteschlange anzuzeigen. Teilen Sie die Anzahl der übertragenen Bytes durch die Anzahl der Pakete, um die Größe der Pakete zu erhalten und den Kapselungstyp zu bestimmen.

3. Load Balancing überprüfen. Geben Sie im Betriebsmodus den show interfaces queue Befehl für das Multilink-Paket und seine konstituierenden Links ein, um zu bestätigen, ob das Load Balancing entsprechend auf den Paketen durchgeführt wird.

   Meaning— Die Ausgabe dieser Befehle zeigt die Pakete, die in jeder Warteschlange der Schnittstelle der Verbindungsservices und ihrer konstituierenden Verbindungen übertragen und in die Warteschlange gestellt werden. Tabelle 3 zeigt eine Zusammenfassung dieser Werte. (Da die Anzahl der übertragenen Pakete gleich der Anzahl der in der Warteschlange zusammengestellten Pakete auf allen Verbindungen entsprach, zeigt diese Tabelle nur die in der Warteschlange zusammengestellten Pakete.)

   Tabelle 3: Anzahl der pakete, die in einer Warteschlange übertragen werden

   Pakete in der Warteschlange	Paket lsq-0/0/0.0	Konstituierende Verbindung se-1/0/0	Bestandteil der Verbindung se-1/0/1	Erklärung
   Pakete im Q0	600	350	350	Die Gesamtzahl der Pakete, die die konstituierenden Verbindungen durchfuhren (350+350 = 700), überstieg die Anzahl der Pakete, die in der Warteschlange standen (600) im Multilink-Paket.
   Pakete im 2. Quartal	400	100	300	Die Gesamtzahl der Pakete, die die konstituierenden Verbindungen durchfuhren, entsprach der Anzahl der Pakete im Paket.
   Pakete im 3. Quartal	0	19	18	Die Pakete, die Q3 der konstituierenden Verbindungen durchfahren, sind für Keepalive-Nachrichten, die zwischen konstituierenden Verbindungen ausgetauscht werden. Somit wurden auf Q3 des Pakets keine Pakete gezählt.

   Überprüfen Sie im Multilink-Paket Folgendes:

   • Die Anzahl der Pakete, die in der Warteschlange stehen, entspricht der Anzahl der übertragenen Pakete. Wenn die Zahlen übereinstimmen, wurden keine Pakete gelöscht. Wenn mehr Pakete in der Warteschlange als übertragen wurden, wurden Pakete gelöscht, weil der Puffer zu klein war. Die Puffergröße auf den konstituierenden Verbindungen steuert die Überlastung in der Ausgabephase. Um dieses Problem zu beheben, vergrößern Sie den Puffer für die konstituierenden Verbindungen.

   • Die Anzahl der Pakete, die Q0 transitieren (600), entspricht der Anzahl der im Multilink-Paket empfangenen großen und kleinen Datenpakete (100+500). Wenn die Zahlen übereinstimmen, wurden alle Datenpakete Q0 korrekt transitiert.

   • Die Anzahl der Pakete, die Q2 im Multilink-Paket durchfahren (400), entspricht der Anzahl der Sprachpakete, die im Multilink-Paket empfangen werden. Wenn die Zahlen übereinstimmen, haben alle Sprach-LFI-Pakete Q2 korrekt transitiert.

   Überprüfen Sie auf den konstituierenden Links Folgendes:

   • Die Gesamtzahl der Pakete, die Q0 durchfahren (350+350), entspricht der Anzahl der Datenpakete und Datenfragmente (500+200). Wenn die Zahlen übereinstimmen, wurden alle Datenpakete nach der Fragmentierung korrekt Q0 der konstituierenden Verbindungen durch transitiert.

     Pakete transitierten beide konstituierenden Verbindungen, was darauf hinweist, dass Load Balancing bei Nicht-LFI-Paketen korrekt durchgeführt wurde.

   • Die Gesamtzahl der Pakete, die Q2 (300+100) auf konstituierenden Verbindungen durchfahren, entspricht der Anzahl der empfangenen Sprachpakete (400) im Multilink-Paket. Wenn die Zahlen übereinstimmen, haben alle Sprach-LFI-Pakete Q2 korrekt transitiert.

     LFI-Pakete vom Quell-Port 100 transitiert se-1/0/0und LFI-Pakete vom Quell-Port 200 transitiert se-1/0/1. Daher wurden alle LFI (Q2)-Pakete basierend auf dem Quellport hashed und korrekt beide konstituierenden Verbindungen transitiert.

   Corrective Action—Wenn die Pakete nur einen Link transitiert haben, führen Sie die folgenden Schritte aus, um das Problem zu beheben:

   1. Bestimmen Sie, ob die physische Verbindung (betriebsbereit) oder down (nicht verfügbar) ist up . Eine nicht verfügbare Verbindung weist auf ein Problem mit PIM, Schnittstellenport oder physischer Verbindung hin (Link-Layer-Fehler). Wenn die Verbindung in Betrieb ist, gehen Sie mit dem nächsten Schritt fort.

   2. Stellen Sie sicher, dass die Klassifizierer für Nicht-LFI-Pakete korrekt definiert sind. Stellen Sie sicher, dass Nicht-LFI-Pakete nicht so konfiguriert sind, dass sie bis zum 2. Quartal in die Warteschlange gestellt werden. Alle Pakete, die bis zum 2. Quartal in der Warteschlange stehen, werden als LFI-Pakete behandelt.

   3. Stellen Sie sicher, dass sich mindestens einer der folgenden Werte in den LFI-Paketen unterscheidet: Quelladresse, Zieladresse, IP-Protokoll, Quell-Port oder Ziel-Port. Wenn für alle LFI-Pakete dieselben Werte konfiguriert sind, werden alle Pakete an den gleichen Datenstrom hashet und leiten dieselbe Verbindung durch.

4. Verwenden Sie die Ergebnisse, um das Load Balancing zu überprüfen.

Problem

Lösung

Wenn das Drittanbietergerät nicht über die gleiche FRF.12-Unterstützung wie das Gerät von Juniper Networks verfügt oder FRF.12 auf andere Weise unterstützt, kann die Geräteschnittstelle von Juniper Networks auf dem PVC ein fragmentiertes Paket mit FRF.12-Headern verwerfen und als "Policed Discard" gezählt werden.

Als Problemumgehung konfigurieren Sie Multilink-Pakete auf beiden Peers und Konfigurieren von Fragmentierungsschwellenwerten in den Multilink-Paketen.

Problem

• Beschreibung
• Infrastruktur
• Symptome

Lösung

Verwenden Sie den show security policies checksum Befehl, um den Wert der Sicherheitsrichtlinien-Prüfsumme anzuzeigen, und verwenden Sie den request security policies resync Befehl, um die Konfiguration der Sicherheitsrichtlinien in der Routing-Engine und der Packet Forwarding Engine zu synchronisieren, wenn die Sicherheitsrichtlinien nicht synchronisiert sind.

Problem

Lösung

Gehen Sie folgendermaßen vor, um diese Fehler zu beheben:

1. Überprüfen Sie Ihre Konfigurationsdaten.

2. Öffnen Sie die Datei /var/log/nsd_chk_only. Diese Datei wird jedes Mal, wenn Sie eine Commit-Prüfung durchführen, überschrieben und enthält detaillierte Fehlerinformationen.

Problem

Lösung

1. Betriebsbefehle show : Führen Sie die Betriebsbefehle für Sicherheitsrichtlinien aus und stellen Sie sicher, dass die in der Ausgabe angezeigten Informationen mit den erwartungen übereinstimmen. Falls nicht, muss die Konfiguration entsprechend geändert werden.

2. Traceoptions: Legen Sie den traceoptions Befehl in Ihrer Richtlinienkonfiguration fest. Die Flags unter dieser Hierarchie können je nach Benutzeranalyse der show Befehlsausgabe ausgewählt werden. Wenn Sie nicht bestimmen können, welches Flag verwendet werden soll, kann die Flag-Option all verwendet werden, um alle Ablaufverfolgungsprotokolle zu erfassen.

Sie können auch einen optionalen Dateinamen konfigurieren, um die Protokolle zu erfassen.

Wenn Sie in den Trace-Optionen einen Dateinamen angegeben haben, können Sie im /var/log/<filename> nach der Protokolldatei suchen, um festzustellen, ob Fehler in der Datei gemeldet wurden. (Wenn Sie keinen Dateinamen angegeben haben, ist der Standarddateiname ereignisiert.) Die Fehlermeldungen geben den Ort des Fehlers und den entsprechenden Grund an.

Nach der Konfiguration der Trace-Optionen müssen Sie die Konfigurationsänderung erneut verwenden, die das falsche Systemverhalten verursacht hat.

Problem

Lösung

Problem

Lösung

Verwenden Sie die Fehlermeldungen, um die Probleme im Zusammenhang mit chassisd zu verstehen.

Wenn ISSU gestartet wird, wird eine Anfrage an chassisd gesendet, um zu prüfen, ob es Aus Sicht des Gehäuses Probleme im Zusammenhang mit der ISSU gibt. Wenn es ein Problem gibt, wird eine Protokollmeldung erstellt.

Problem

Lösung

Alle Fehler, die während einer ISSU auftreten, führen zur Erstellung von Protokollmeldungen, und ISSU funktioniert weiterhin ohne Auswirkungen auf den Datenverkehr. Wenn eine Revertierung zu früheren Versionen erforderlich ist, wird das Ereignis entweder protokolliert oder die ISSU wird angehalten, um keine nicht übereinstimmenden Versionen auf beiden Knoten des Chassis-Clusters zu erstellen. Tabelle 4 stellt einige der häufigen Fehlerbedingungen und die Problemumgehungen für sie bereit. Die darin Tabelle 4 verwendeten Beispielnachrichten stammen vom SRX1500-Gerät und gelten auch für alle unterstützten Geräte der SRX-Serie.

error: [Oct  6 12:30:16]: Reboot secondary node failed (error-code: 4.1)

       error: [Oct  6 12:30:16]: ISSU Aborted! Backup node maybe in inconsistent state, Please restore backup node
       [Oct  6 12:30:16]: ISSU aborted. But, both nodes are in ISSU window.
       Please do the following:
       1. Rollback the node with the newer image using rollback command
          Note: use the 'node' option in the rollback command
          otherwise, images on both nodes will be rolled back
       2. Make sure that both nodes (will) have the same image
       3. Ensure the node with older image is primary for all RGs
       4. Abort ISSU on both nodes
       5. Reboot the rolled back node

[Oct  3 14:00:46]: timeout waiting for secondary node node1 to sync(error-code: 6.1)
        Chassis control process started, pid 36707 

       error: [Oct  3 14:00:46]: ISSU Aborted! Backup node has been upgraded, Please restore backup node 
       [Oct  3 14:00:46]: ISSU aborted. But, both nodes are in ISSU window. 
       Please do the following: 
      1. Rollback the node with the newer image using rollback command 
          Note: use the 'node' option in the rollback command 
          otherwise, images on both nodes will be rolled back 
      2. Make sure that both nodes (will) have the same image 
      3. Ensure the node with older image is primary for all RGs 
      4. Abort ISSU on both nodes 
      5. Reboot the rolled back node  

[Aug 27 15:28:17]: Secondary node0 ready for failover.
[Aug 27 15:28:17]: Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
error: remote rg1 priority zero, abort failover.
[Aug 27 15:28:17]: failover all RGs to node node0 failed (error-code: 7.1)
error: [Aug 27 15:28:17]: ISSU Aborted!
[Aug 27 15:28:17]: ISSU aborted. But, both nodes are in ISSU window.
Please do the following:
1. Rollback the node with the newer image using rollback command
    Note: use the 'node' option in the rollback command
           otherwise, images on both nodes will be rolled back
2. Make sure that both nodes (will) have the same image
3. Ensure the node with older image is primary for all RGs
4. Abort ISSU on both nodes
5. Reboot the rolled back node
{primary:node1}

Reboot failure on     Before the reboot of primary node, devices will be out of ISSU setup and no primary node error messages will be displayed.
Primary node

Problem

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um die Kompatibilitätsprobleme zu verstehen:

Problem

Lösung

Die Validierungsprüfungen schlagen fehl, wenn das Bild nicht vorhanden ist oder wenn die Bilddatei beschädigt ist. Die folgenden Fehlermeldungen werden angezeigt, wenn die anfänglichen Validierungsprüfungen fehlschlagen, wenn das Bild nicht vorhanden ist und die ISSU abgebrochen wird:

Wenn ein Bild nicht vorhanden ist

Wenn die Bilddatei beschädigt ist

Wenn die Bilddatei beschädigt ist, wird die folgende Ausgabe angezeigt:

Der Primäre Knoten validiert die Gerätekonfiguration, um sicherzustellen, dass sie mit der neuen Softwareversion festgelegt werden kann. Wenn etwas schief läuft, bricht die ISSU ab und Fehlermeldungen werden angezeigt.

Problem

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um die installationsbezogenen Probleme zu verstehen:

ISSU lädt das Installationsimage, wie im ISSU-Befehl angegeben, als Argument herunter. Die Bilddatei kann eine lokale Datei sein oder sich an einem Remote-Standort befinden. Wenn die Datei nicht vorhanden ist oder die Remote-Site nicht zugänglich ist, wird ein Fehler gemeldet.

Problem

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um das Problem zu verstehen:

Problem

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um die Probleme im Zusammenhang mit ksyncd zu verstehen:

ISSU prüft, ob ksyncd-Fehler auf dem sekundären Knoten (Knoten 1) vorliegen, und zeigt die Fehlermeldung an, wenn es Probleme gibt, und bricht das Upgrade ab.