Auf dieser Seite
Fehlerbehebung bei Sicherheitsgeräten
Fehlerbehebung bei der DNS-Namensauflösung in Logischen Systemsicherheitsrichtlinien (nur primäre Administratoren)
Problem
Beschreibung
Die Adresse eines Hostnamens in einem Adressbucheintrag, der in einer Sicherheitsrichtlinie verwendet wird, kann möglicherweise nicht richtig aufgelöst werden.
Ursache
Normalerweise werden Adressbucheinträge, die dynamische Hostnamen enthalten, für Geräte der SRX-Serie automatisch aktualisiert. Das TTL-Feld, das einem DNS-Eintrag zugeordnet ist, gibt die Zeit an, nach der der Eintrag im Richtliniencache aktualisiert werden soll. Sobald der TTL-Wert abläuft, aktualisiert das Gerät der SRX-Serie automatisch den DNS-Eintrag für einen Adressbucheintrag.
Wenn das Gerät der SRX-Serie jedoch keine Antwort vom DNS-Server erhalten kann (z. B. geht die DNS-Anfrage oder das Antwortpaket im Netzwerk verloren oder der DNS-Server kann keine Antwort senden), kann die Adresse eines Hostnamens in einem Adressbucheintrag möglicherweise nicht richtig aufgelöst werden. Dies kann dazu führen, dass der Datenverkehr abfällt, da keine Sicherheitsrichtlinien oder Sitzungsabgleiche gefunden werden.
Lösung
Der primäre Administrator kann den show security dns-cache
Befehl verwenden, um DNS-Cache-Informationen auf dem Gerät der SRX-Serie anzuzeigen. Wenn die DNS-Cacheinformationen aktualisiert werden müssen, kann der primäre Administrator den clear security dns-cache
Befehl verwenden.
Diese Befehle stehen nur dem primären Administrator auf Geräten zur Verfügung, die für logische Systeme konfiguriert sind. Dieser Befehl ist in logischen Benutzersystemen oder auf Geräten, die nicht für logische Systeme konfiguriert sind, nicht verfügbar.
Siehe auch
Fehlerbehebung an der Link Services-Schnittstelle
So lösen Sie Konfigurationsprobleme auf einer Link-Services-Schnittstelle:
- Bestimmen, welche CoS-Komponenten auf die konstituierenden Verbindungen angewendet werden
- Ermitteln der Ursachen von Jitter und Latenz im Multilink-Paket
- Stellen Sie fest, ob LFI und Load Balancing korrekt funktionieren
- Ermitteln, warum Pakete auf einem PVC zwischen einem Gerät von Juniper Networks und einem Gerät eines Drittanbieters abgelegt werden
Bestimmen, welche CoS-Komponenten auf die konstituierenden Verbindungen angewendet werden
Problem
Beschreibung
Sie konfigurieren ein Multilink-Paket, aber Sie haben auch Datenverkehr, ohne dass die MLPPP-Kapselung die konstituierenden Links des Multilink-Pakets passiert. Wenden Sie alle CoS-Komponenten auf die konstituierenden Links an oder reichen sie auf das Multilink-Paket aus?
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.
Cos-Komponente |
Multilink-Paket |
Verknüpfungen |
Erklärung |
---|---|---|---|
Klassifizierung |
Ja |
Nicht vorhanden. |
Die CoS-Klassifizierung findet auf der eingehenden Seite der Schnittstelle statt, nicht auf der Sendeseite, sodass keine Klassifizierer auf konstituierenden Verbindungen benötigt werden. |
Forwarding-Klasse |
Ja |
Nicht vorhanden. |
Die Weiterleitungsklasse ist einer Warteschlange zugeordnet, und die Warteschlange wird durch eine Scheduler-Karte auf die Schnittstelle angewendet. Die Warteschlangenzuweisung ist auf die konstituierenden Links vorab festgelegt. Alle Pakete aus Q2 des Multilink-Pakets werden Q2 der konstituierenden Verbindung zugewiesen, und Pakete aus allen anderen Warteschlangen werden bis Q0 des konstituierenden Links in die Warteschlange gestellt. |
Scheduler-Karte |
Ja |
Ja |
Wenden Sie Planerkarten für das Multilink-Paket und den konstituierenden Link wie folgt an:
|
Shaping-Rate für einen Scheduler pro Einheit oder einen Scheduler auf Schnittstellenebene |
Nicht vorhanden. |
Ja |
Da die Planung pro Einheit nur am Endpunkt angewendet wird, wenden Sie diese Formungsrate nur auf die konstituierenden Verbindungen an. Jede zuvor angewendete Konfiguration wird durch die konstituierende Linkkonfiguration überschrieben. |
Genaue Übertragungsrate oder Shaping auf Warteschlangenebene |
Ja |
Nicht vorhanden. |
Das Shaping auf Schnittstellenebene, das auf die konstituierenden Links angewendet wird, überschreibt jedes Shaping in der Warteschlange. Wenden Sie daher die genaue Shaping-Übertragungsrate nur auf dem Multilink-Paket an. |
Rewrite-Regeln |
Ja |
Nicht vorhanden. |
Rewrite-Bits werden während der Fragmentierung automatisch aus dem Paket in die Fragmente kopiert. So wird das, was Sie auf dem Multilink-Paket konfigurieren, über die Fragmente zu den konstituierenden Links übertragen. |
Virtuelle Channel-Gruppe |
Ja |
Nicht vorhanden. |
Virtuelle Kanalgruppen werden durch Firewall-Filterregeln identifiziert, die nur vor dem Multilink-Paket auf Pakete angewendet werden. Daher müssen Sie die Konfiguration der virtuellen Kanalgruppe nicht auf die konstituierenden Links anwenden. |
Siehe auch
Ermitteln der Ursachen von Jitter und Latenz im Multilink-Paket
Problem
Beschreibung
Um Jitter und Latenz zu testen, senden Sie drei Streams von IP-Paketen. Alle Pakete haben die gleichen IP-Rangfolgeeinstellungen. Nach der Konfiguration von LFI und CRTP erhöhte sich die Latenz sogar über eine nicht überlastete Verbindung. Wie können Sie Jitter und Latenz reduzieren?
Lösung
Gehen Sie wie folgt vor, um Jitter und Latenz zu reduzieren:
Stellen Sie sicher, dass Sie eine Shaping-Rate für jeden konstituierenden Link konfiguriert haben.
Stellen Sie sicher, dass Sie keine Shaping-Rate auf der Link-Services-Schnittstelle konfiguriert haben.
Stellen Sie sicher, dass der konfigurierte Shaping-Rate-Wert gleich der physischen Schnittstellenbandbreite ist.
Wenn die Geschwindigkeiten richtig konfiguriert sind und der Jitter weiterhin besteht, wenden Sie sich an das Juniper Networks Technical Assistance Center (JTAC).
Stellen Sie fest, ob LFI und Load Balancing korrekt funktionieren
Problem
Beschreibung
In diesem Fall haben Sie ein einzelnes Netzwerk, das mehrere Services unterstützt. Das Netzwerk überträgt Daten und verzögerungensensiblen Sprachverkehr. Stellen Sie nach der Konfiguration von MLPPP und LFI sicher, dass Sprachpakete mit sehr geringer Verzögerung und Jitter über das Netzwerk übertragen werden. Wie können Sie herausfinden, ob Sprachpakete als LFI-Pakete behandelt werden und Load Balancing korrekt durchgeführt wird?
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:
In diesem Beispiel werden nur die wesentlichen Teile der Befehlsausgabe angezeigt und beschrieben.
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.user@R0#> show interfaces lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Link-level type: LinkService, MTU: 1504 Device flags : Present Running Interface flags: Point-To-Point SNMP-Traps Last flapped : 2006-08-01 10:45:13 PDT (2w0d 06:06 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface lsq-0/0/0.0 (Index 69) (SNMP ifIndex 42) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP Bandwidth: 16mbps Statistics Frames fps Bytes bps Bundle: Fragments: Input : 0 0 0 0 Output: 1100 0 118800 0 Packets: Input : 0 0 0 0 Output: 1000 0 112000 0 ... Protocol inet, MTU: 1500 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 9.9.9/24, Local: 9.9.9.10
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.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-HeaderBei 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.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.user@R0> show interfaces queue lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 600 0 pps Bytes : 44800 0 bps Transmitted: Packets : 600 0 pps Bytes : 44800 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 400 0 pps Bytes : 61344 0 bps Transmitted: Packets : 400 0 pps Bytes : 61344 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 0 0 pps Bytes : 0 0 bps …
user@R0> show interfaces queue se-1/0/0 Physical interface: se-1/0/0, Enabled, Physical link is Up Interface index: 141, SNMP ifIndex: 35 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps ... Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 100 0 pps Bytes : 15272 0 bps Transmitted: Packets : 100 0 pps Bytes : 15272 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 19 0 pps Bytes : 247 0 bps Transmitted: Packets : 19 0 pps Bytes : 247 0 bps …
user@R0> show interfaces queue se-1/0/1 Physical interface: se-1/0/1, Enabled, Physical link is Up Interface index: 142, SNMP ifIndex: 38 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 300 0 pps Bytes : 45672 0 bps Transmitted: Packets : 300 0 pps Bytes : 45672 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 18 0 pps Bytes : 234 0 bps Transmitted: Packets : 18 0 pps Bytes : 234 0 bps
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
transitiertse-1/0/0
und LFI-Pakete vom Quell-Port200
transitiertse-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:Bestimmen Sie, ob die physische Verbindung (betriebsbereit) oder
down
(nicht verfügbar) istup
. 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.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.
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.
Verwenden Sie die Ergebnisse, um das Load Balancing zu überprüfen.
Ermitteln, warum Pakete auf einem PVC zwischen einem Gerät von Juniper Networks und einem Gerät eines Drittanbieters abgelegt werden
Problem
Beschreibung
Sie konfigurieren einen permanenten virtuellen Circuit (PVC) zwischen T1-, E1-, T3- oder E3-Schnittstellen auf einem Gerät von Juniper Networks und einem Gerät eines Drittanbieters, und Pakete werden gelöscht und Ping schlägt fehl.
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.
Fehlerbehebung bei Sicherheitsrichtlinien
- Synchronisierung von Richtlinien zwischen Routing-Engine und Packet Forwarding Engine
- Überprüfung eines Commit-Fehlers bei einer Sicherheitsrichtlinie
- Verifizieren eines Commits zur Sicherheitsrichtlinie
- Debugging-Richtliniensuche
Synchronisierung von Richtlinien zwischen Routing-Engine und Packet Forwarding Engine
Problem
Beschreibung
Sicherheitsrichtlinien werden in der Routing-Engine und der Packet Forwarding Engine gespeichert. Sicherheitsrichtlinien werden von der Routing-Engine an die Packet Forwarding Engine übertragen, wenn Sie Konfigurationen festlegen. Wenn die Sicherheitsrichtlinien der Routing-Engine nicht mit der Packet Forwarding Engine synchronisiert sind, schlägt das Commit einer Konfiguration fehl. Core-Dump-Dateien können generiert werden, wenn der Commit wiederholt versucht wird. Der Ausfall der Synchronisierung kann auf folgendes zurückzuführen sein:
Eine Richtliniennachricht von der Routing-Engine an die Packet Forwarding Engine geht bei der Übertragung verloren.
Ein Fehler mit der Routing-Engine, wie z. B. eine wiederverwendete Richtlinie WIESS.
Infrastruktur
Die Richtlinien in der Routing-Engine und der Packet Forwarding Engine müssen synchronisiert sein, damit die Konfiguration festgelegt wird. Unter bestimmten Umständen können die Richtlinien in der Routing-Engine und der Packet Forwarding Engine nicht synchronisiert sein, was dazu führt, dass das Commit fehlschlägt.
Symptome
Wenn die Richtlinienkonfigurationen geändert werden und die Richtlinien nicht synchronisiert sind, wird die folgende Fehlermeldung angezeigt: error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)> Please request security policies check/resync.
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.
Siehe auch
Überprüfung eines Commit-Fehlers bei einer Sicherheitsrichtlinie
Problem
Beschreibung
Die meisten Fehler bei der Richtlinienkonfiguration treten während eines Commits oder der Laufzeit auf.
Commit-Fehler werden direkt über die CLI gemeldet, wenn Sie den CLI-Befehl commit-check im Konfigurationsmodus ausführen. Diese Fehler sind Konfigurationsfehler, und Sie können die Konfiguration nicht ohne behebung dieser Fehler festlegen.
Lösung
Gehen Sie folgendermaßen vor, um diese Fehler zu beheben:
Überprüfen Sie Ihre Konfigurationsdaten.
Ö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.
Verifizieren eines Commits zur Sicherheitsrichtlinie
Problem
Beschreibung
Führen Sie beim Ausführen eines Richtlinienkonfigurations-Commits die folgenden Schritte aus, um dieses Problem zu beheben, wenn Sie feststellen, dass das Systemverhalten falsch ist:
Lösung
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.
Traceoptions: Legen Sie den
traceoptions
Befehl in Ihrer Richtlinienkonfiguration fest. Die Flags unter dieser Hierarchie können je nach Benutzeranalyse dershow
Befehlsausgabe ausgewählt werden. Wenn Sie nicht bestimmen können, welches Flag verwendet werden soll, kann die Flag-Optionall
verwendet werden, um alle Ablaufverfolgungsprotokolle zu erfassen.user@host#
set security policies traceoptions <flag all>
Sie können auch einen optionalen Dateinamen konfigurieren, um die Protokolle zu erfassen.
user@host# set security policies traceoptions <filename>
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.
Debugging-Richtliniensuche
Problem
Beschreibung
Wenn Sie über die richtige Konfiguration verfügen, aber ein Teil des Datenverkehrs fälschlicherweise unterbrochen oder zugelassen wurde, können Sie das lookup
Flag in den Traceoptionen für Sicherheitsrichtlinien aktivieren. Das lookup
Flag protokolliert die suchbezogenen Ablaufverfolgungen in der Trace-Datei.
Lösung
user@host# set security policies traceoptions <flag lookup>