Fehlerbehebung bei Sicherheitsgeräten

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 1 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 2 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 2: 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 3 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 3: 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