Überwachung und Fehlerbehebung

Zweck

Zeigen Sie Echtzeitstatistiken über den Datenverkehr an, der über alle Schnittstellen des Routers oder Switches geleitet wird.

Action!

So zeigen Sie Echtzeitstatistiken über den Datenverkehr an, der durch alle Schnittstellen auf dem Router oder Switch geleitet wird:

Bedeutung

Die Beispielausgabe zeigt Datenverkehrsdaten für aktive Schnittstellen und den Betrag an, um den sich die einzelnen Felder seit dem Start des Befehls oder seit dem Löschen der Zähler mithilfe des C Schlüssels geändert haben. In diesem Beispiel wird der monitor interface Befehl seit 15 Sekunden ausgeführt, seit der Befehl ausgegeben wurde oder seit die Zähler zuletzt auf Null zurückgesetzt wurden.

Zweck

Zeigen Sie Echtzeitstatistiken über den Datenverkehr an, der durch eine Schnittstelle auf dem Router oder Switch geleitet wird.

Action!

Verwenden Sie den folgenden Junos OS CLI-Betriebsmodusbefehl, um den Datenverkehr anzuzeigen, der über eine Schnittstelle auf dem Router oder Switch geleitet wird:

Bedeutung

Die Beispielausgabe zeigt die Ein- und Ausgabepakete für eine bestimmte SONET-Schnittstelle (so-0/0/1). Die Informationen können häufige Schnittstellenfehler wie SONET/SDH- und T3-Alarme, erkannte Loopbacks und eine Zunahme von Framing-Fehlern umfassen.

Um die Ausgabe des Befehls zu steuern, während er ausgeführt wird, verwenden Sie die in Tabelle 1.

Weitere Informationen zur Verwendung von Übereinstimmungsbedingungen mit dem monitor traffic Befehl finden Sie im CLI-Explorer .

Problem

Lösung

Sie können eine Scheduler-Zuordnung auf das Multilink-Bundle und seine zugehörigen Links anwenden. Sie können zwar mehrere CoS-Komponenten mit der Scheduler-Zuordnung anwenden, konfigurieren Sie jedoch nur die erforderlichen. Es wird empfohlen, die Konfiguration der einzelnen Links einfach zu halten, um unnötige Verzögerungen bei der Übertragung zu vermeiden.

Tabelle 5 zeigt die CoS-Komponenten, die auf ein Multilink-Bündel angewendet werden sollen, und die darin enthaltenen Links.

Problem

Lösung

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

1. Stellen Sie sicher, dass Sie für jede konstituierende Verknüpfung eine Shaping-Rate konfiguriert haben.

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

3. Stellen Sie sicher, dass der konfigurierte Wert für die Shaping-Rate mit der Bandbreite der physischen Schnittstelle übereinstimmt.

4. Wenn die Shaping-Raten korrekt 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-Pakete) mit einem MLPPP-Header gekapselt und in Pakete einer bestimmten Größe fragmentiert. Die verzögerungssensitiven Sprachpakete (LFI) sind PPP-gekapselt und zwischen Datenpaketfragmenten verschachtelt. Warteschlangen und Lastenausgleich werden für LFI- und Nicht-LFI-Pakete unterschiedlich ausgeführt.

Um zu überprüfen, ob LFI korrekt ausgeführt wird, stellen Sie fest, dass die 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 überprüfen, ob der Lastenausgleich ordnungsgemäß durchgeführt wird.

Solution Scenario– Angenommen, zwei Juniper Networks-Geräte, R0 und R1, sind durch ein Multilink-Bündel lsq-0/0/0.0 verbunden, das zwei serielle Verbindungen aggregiert, se-1/0/0 und se-1/0/1. Auf R0 und R1 sind MLPPP und LFI auf der Link Services-Schnittstelle aktiviert, und der Fragmentierungsschwellenwert ist auf 128 Byte 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-Bundle gesendet:

• 100 Datenpakete à 200 Byte (größer als die Fragmentierungsschwelle)

• 500 Datenpakete à 60 Byte (kleiner als die Fragmentierungsschwelle)

Die folgenden zwei Sprachstreams wurden über das Multilink-Bundle gesendet:

• 100 Sprachpakete à 200 Byte von Quellport 100

• 300 Sprachpakete à 200 Byte von Quellport 200

So überprüfen Sie, ob LFI und Load Balancing korrekt durchgeführt werden:

1. Überprüfen Sie die Paketfragmentierung. 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-Bundle durchlaufen. Überprüfen Sie die folgenden Informationen auf dem Multilink-Bundle:

   • Die Gesamtzahl der Transitpakete = 1000

   • Die Gesamtzahl der transitierenden Fragmente = 1100

   • Die Anzahl der Datenpakete, die fragmentiert wurden =100

   Die Gesamtzahl der im Multilink-Bundle gesendeten Pakete (600 + 400) stimmt mit der Anzahl der Transitpakete (1000) überein, was darauf hinweist, dass keine Pakete verworfen wurden.

   Die Anzahl der transitierenden Fragmente ü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 korrekt fragmentiert sind, überprüfen Sie die Konfiguration des Fragmentierungsschwellenwerts. Pakete, die kleiner als der angegebene Fragmentierungsschwellenwert sind, werden nicht fragmentiert.

2. Überprüfen 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, Nicht-LFI-Pakete werden sowohl mit PPP als auch mit MLPPP gekapselt. PPP- und MLPPP-Kapselungen haben unterschiedliche Overheads, was zu unterschiedlich großen Paketen führt. Sie können Paketgrößen vergleichen, um den Verkapselungstyp zu bestimmen.

   Ein kleines, unfragmentiertes Datenpaket enthält einen PPP-Header und einen einzelnen MLPPP-Header. In einem großen fragmentierten Datenpaket enthält das erste Fragment einen PPP-Header und einen MLPPP-Header, die nachfolgenden Fragmente jedoch 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 Byte Header + 2 Byte Frame-Check-Sequenz (FCS) + 1 Byte, das sich im Leerlauf befindet oder ein Flag enthält

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

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

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

   Abbildung 1: PPP- und MLPPP-Header

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

   Tabelle 6 Zeigt den Kapselungsaufwand für ein Datenpaket und ein Sprachpaket von jeweils 70 Byte. Nach der Kapselung ist die Größe des Datenpakets größer als die Größe des Sprachpakets.

   Tabelle 6: PPP- und MLPPP-Kapselungs-Overhead

   Pakettyp	Verkapselung	Anfängliche Paketgröße	Kapselungs-Overhead	Paketgröße nach der Kapselung
   Sprachpaket (LFI)	KAUFKRAFTPARITÄT	70 Bytes	4 + 2 + 1 = 7 Bytes	77 Bytes
   Datenfragment (non-LFI) mit kurzer Sequenz	MLPPP	70 Bytes	4 + 2 + 1 + 4 + 2 = 13 Byte	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. Überprüfen Sie den Lastenausgleich. Geben Sie im Betriebsmodus den show interfaces queue Befehl für das Multilink-Bundle und seine zugehörigen Links ein, um zu bestätigen, ob der Lastenausgleich für die Pakete entsprechend durchgeführt wird.

   Meaning—Die Ausgabe dieser Befehle zeigt die Pakete, die in jeder Warteschlange der Link-Services-Schnittstelle und der zugehörigen Links übertragen und in die Warteschlange eingereiht wurden. Tabelle 7 Zeigt eine Zusammenfassung dieser Werte an. (Da die Anzahl der übertragenen Pakete der Anzahl der Pakete in der Warteschlange auf allen Verbindungen entsprach, werden in dieser Tabelle nur die Pakete in der Warteschlange angezeigt.)

   Tabelle 7: Anzahl der Pakete, die in einer Warteschlange übertragen wurden

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

   Überprüfen Sie im Multilink-Bundle Folgendes:

   • Die Anzahl der Pakete, die sich in der Warteschlange befinden, stimmt mit der Anzahl der übertragenen Pakete überein. Wenn die Nummern übereinstimmen, wurden keine Pakete verworfen. Wenn mehr Pakete in die Warteschlange eingereiht als übertragen wurden, wurden Pakete verworfen, weil der Puffer zu klein war. Die Puffergröße auf den konstituierenden Links steuert die Überlastung in der Ausgangsstufe. Um dieses Problem zu beheben, erhöhen Sie die Puffergröße für die konstituierenden Links.

   • Die Anzahl der Pakete, die Q0 (600) durchqueren, stimmt mit der Anzahl der großen und kleinen Datenpakete überein, die auf dem Multilink-Bundle empfangen wurden (100+500). Stimmen die Nummern überein, haben alle Datenpakete Q0 korrekt durchquert.

   • Die Anzahl der Pakete, die Q2 auf dem Multilink-Bundle (400) durchqueren, stimmt mit der Anzahl der Sprachpakete überein, die auf dem Multilink-Bundle empfangen wurden. Wenn die Nummern übereinstimmen, haben alle Sprach-LFI-Pakete Q2 korrekt übertragen.

   Überprüfen Sie bei den konstituierenden Links Folgendes:

   • Die Gesamtzahl der Pakete, die Q0 durchqueren (350+350), stimmt mit der Anzahl der Datenpakete und Datenfragmente (500+200) überein. Wenn die Zahlen übereinstimmen, haben alle Datenpakete nach der Fragmentierung Q0 der konstituierenden Links korrekt durchlaufen.

     Pakete durchliefen beide konstituierenden Links, was darauf hindeutet, dass der Lastenausgleich bei Nicht-LFI-Paketen korrekt durchgeführt wurde.

   • Die Gesamtzahl der Pakete, die Q2 (300+100) auf konstituierenden Verbindungen durchlaufen, stimmt mit der Anzahl der empfangenen Sprachpakete (400) auf dem Multilink-Bundle überein. Wenn die Nummern übereinstimmen, haben alle Sprach-LFI-Pakete Q2 korrekt übertragen.

     LFI-Pakete vom Quellport 100 übertragen se-1/0/0und LFI-Pakete vom Quellport 200 übertragen. se-1/0/1 Daher wurden alle LFI (Q2)-Pakete basierend auf dem Quellport gehasht und führten beide konstituierenden Links korrekt durch.

   Corrective Action—Wenn die Pakete nur eine Verbindung übertragen 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 dem PIM, dem Schnittstellenport oder der physischen Verbindung hin (Fehler auf der Verbindungsebene). Wenn die Verbindung betriebsbereit ist, fahren 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 in Q2 in die Warteschlange gestellt werden. Alle Pakete, die sich in Q2 in der Warteschlange befinden, werden als LFI-Pakete behandelt.

   3. Stellen Sie sicher, dass mindestens einer der folgenden Werte in den LFI-Paketen unterschiedlich ist: Quelladresse, Zieladresse, IP-Protokoll, Quellport oder Zielport. Wenn für alle LFI-Pakete die gleichen Werte konfiguriert sind, werden die Pakete alle mit demselben Datenstrom gehasht und durchlaufen dieselbe Verbindung.

4. Verwenden Sie die Ergebnisse, um den Lastenausgleich zu überprüfen.

Problem

Lösung

Wenn das Gerät eines Drittanbieters 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, verwirft die Geräteschnittstelle von Juniper Networks auf dem PVC möglicherweise ein fragmentiertes Paket, das FRF.12-Header enthält, und zählt es als "polizeilich verworfen".

Um dieses Problem zu umgehen, konfigurieren Sie Multilink-Bundles auf beiden Peers und Fragmentierungsschwellenwerte für die Multilink-Bundles.

Problem

• Beschreibung
• Infrastruktur
• Symptome

Lösung

Verwenden Sie den show security policies checksum Befehl, um den Prüfsummenwert der Sicherheitsrichtlinie anzuzeigen, und verwenden Sie den request security policies resync Befehl, um die Konfiguration der Sicherheitsrichtlinien in der Routing-Engine und der Paketweiterleitungs-Engine zu synchronisieren, wenn die Sicherheitsrichtlinien nicht synchron sind.

Problem

Lösung

Gehen Sie wie folgt 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 überschrieben, wenn Sie eine Commit-Prüfung durchführen, und enthält detaillierte Fehlerinformationen.

Problem

Lösung

1. Betriebsbefehle show : Führen Sie die Betriebsbefehle für Sicherheitsrichtlinien aus und überprüfen Sie, ob die in der Ausgabe angezeigten Informationen mit Ihren Erwartungen übereinstimmen. Ist dies nicht der Fall, 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 gemäß der Benutzeranalyse der show Befehlsausgabe ausgewählt werden. Wenn Sie nicht bestimmen können, welches Flag verwendet werden soll, kann die Option all flag 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 in /var/log/<filename> nach der Protokolldatei suchen, um festzustellen, ob Fehler in der Datei gemeldet wurden. (Wenn Sie keinen Dateinamen angegeben haben, lautet der Standarddateiname eventd.) Die Fehlermeldungen geben den Ort des Fehlers und die entsprechende Ursache an.

Nachdem Sie die Ablaufverfolgungsoptionen konfiguriert haben, müssen Sie die Konfigurationsänderung, die das falsche Systemverhalten verursacht hat, erneut bestätigen.

Problem

Lösung

Problem

Lösung

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

Wenn ISSU startet, wird eine Anfrage an chassisd gesendet, um zu überprüfen, ob es aus Chassis-Sicht Probleme im Zusammenhang mit der ISSU gibt. Wenn ein Problem auftritt, 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 das Zurücksetzen auf frühere 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 8 Enthält einige der häufigsten Fehlerzustände und die entsprechenden Problemumgehungen. Die in der Tabelle 8 Beispielmeldung stammen vom SRX1500 Gerät und gelten auch für alle unterstützten Firewalls 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 oder 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 das 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 ein Commit mit der neuen Softwareversion ausgeführt werden kann. Wenn etwas schief geht, bricht die ISSU ab und es werden Fehlermeldungen angezeigt.

Problem

Lösung

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

ISSU lädt das Installationsabbild, wie im ISSU-Befehl angegeben, als Argument herunter. Bei der Bilddatei kann es sich um eine lokale Datei handeln oder um eine Datei an einem Remote-Standort. Wenn die Datei nicht vorhanden ist oder auf die Remote-Site nicht zugegriffen werden kann, 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 auf dem sekundären Knoten (Knoten 1) ksyncd-Fehler vorliegen und zeigt bei Problemen die Fehlermeldung an und bricht das Upgrade ab.