Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

AUF DIESER SEITE
 

Fabric-Widerstandsfähigkeit

Fabric-Ausfallsicherheit und -Verschlechterung

Juniper und Switches sind integriert, um Ausfälle und Fehlerbedingungen während des normalen Betriebs zu beheben. Die JUNOS-Software kann sofortige Maßnahmen ergreifen, um Fehlerbedingungen zu beheben und den Datenverkehrsverlust zu minimieren. Manuelle Eingriffe sind nicht erforderlich. Fabric-Verschlechterungen könnten einer der Gründe dafür sein, dass solche Fehlerbedingungen auftreten können. In den folgenden Abschnitten wird erklärt, wie die PFEs nach diesen Ausfällen auf eine ausfallsichere Weise wiederhergestellt werden.

Packet Forwarding Engine und Wiederherstellung bei Routern der PTX-Serie

Packet Forwarding Engine-Ziele können auf Routern der PTX-Serie aus folgenden Gründen unerreicht werden:

  • Die Fabric-Switch-Schnittstellenkarten (SIBs) sind offline, wenn ein Befehl CLI oder eine bedruckte physische Schaltfläche verwendet wird.

  • Die Fabric-SIBs werden wegen hoher Temperaturbedingungen vom Steuerplatine offlinegeschaltet.

  • Volt- oder polled I/O-Fehler in den SIBs werden von der Steuerplatine erkannt.

  • Auf allen vernetzten Ebenen treten unerwartete Fehler beim Link-Training auf.

  • Zwei Packet Forwarding Engines können die Fabric erreichen, aber nicht miteinander.

  • Verbindungsfehler treten bei zwei Packet Forwarding Engines auf, die nicht über eine gemeinsame Ebene mit der Fabric verbunden sind.

Sie können ab Junos OS Version 13.3 die Router der PTX-Serie verwenden, um Fehlerstufen zu konfigurieren, die mit Packet Forwarding Engine (PFE) verbunden sind, und die Aktionen, die bei Erreichen eines angegebenen Grenzwerts durchgeführt werden.

Wenn keine Fehlerebenen definiert sind, beginnt ein Router der PTX-Serie die folgenden Phasen im Wiederherstellungsprozess:

  1. SIB-Neustartphase: Der Router versucht, das Problem zu beheben, indem er die SIBs 1 für Schritt neu startet. Diese Phase beginnt nicht, wenn die SIBs ordnungsgemäß arbeiten und eine einzelne Linekarte mit einem Problem konfrontiert wird.

  2. SIB und Linekartenneustartphase: Der Router startet sowohl die SIBs als auch die Linekarte neu. Wenn Es Linekarten gibt, die keine Hochgeschwindigkeitsverbindungen mit der Fabric nach dem Neustart initiieren können, ist dies nicht relevant für den Verlust des live-Datenverkehrs, da keine Schnittstellen für diese Linekarten erstellt werden, was das System vor Problemen verhindert.

  3. Offline-Phase der Linekarten: Da frühere Wiederherstellungsversuche fehlgeschlagen sind, werden Linekarten und Schnittstellen ausgeschaltet, und das System vermeidet Probleme und Fehlerbedingungen.

Packet Forwarding Engine und Wiederherstellung von Routern T640, T1600 oder TX Matrix-Routern

Packet Forwarding Engine-Ziele können für T640, T1600- oder TX Matrix-Router nicht erreichbar sein. Dies hat die folgenden Gründe:

  • Die Fabric-Switch-Schnittstellenkarten (SIBs) sind offline, wenn ein Befehl CLI oder eine bedruckte physische Schaltfläche verwendet wird.

  • Die Fabric-SIBs werden vom Switch Processor Mezhinine Board (SPMB) wegen hoher Temperaturbedingungen offlinegeschaltet.

  • Spannungs- oder polled I/O-Fehler in den SIBs werden von der SPMB erkannt.

  • Alle Packet Forwarding Engines erhalten Zielfehler auf allen Ebenen von Remote-Packet Forwarding Engines, selbst wenn die SIBs online sind.

  • Ein vollständiger Fabric-Verlust wird durch Ziel-Timeouts verursacht, auch wenn die SIBs online sind.

Der Wiederherstellungsprozess umfasst folgende Phasen:

  1. Der Router startet die Fabric-Ebene einmal neu. Diese Phase beginnt nicht, wenn die Fabric-Ebene ordnungsgemäß funktioniert und bei einer einzigen Linekarte Probleme auft kommt.

  2. Neustartphase der Fabric-Ebene und der Linekarten: Der Router startet sowohl die SIBs als auch die Linecards neu. Wenn Es Linekarten gibt, die keine Hochgeschwindigkeitsverbindungen mit der Fabric nach dem Neustart initiieren können, ist dies nicht relevant für den Verlust des live-Datenverkehrs, da keine Schnittstellen für diese Linekarten erstellt werden, was das System vor Problemen verhindert.

  3. Offline-Phase der Linekarten: Da frühere Wiederherstellungsversuche fehlgeschlagen sind, werden Linekarten und Schnittstellen ausgeschaltet, und das System vermeidet Probleme und Fehlerbedingungen mit gravierenden Folgen.

Hinweis:

Wenn die SIB ab Junos OS Veröffentlichungs-14.2R6 aufgrund extremen Bedingungen wie Hohespannung oder hoher Temperatur offline ist, startet der Router die Fabric-Ebene dieser SIB nicht neu, während des Wiederherstellungsprozesses.

Der oben genannte schrittweise Wiederherstellungsmechanismus ist erschöpfend, es sei denn, es gibt andere Fehler, die mit diesen Problemen in Zusammenhang stehen könnten.

Ausgehend von Junos OS Release 14.2R6 können Sie fabric-Verschlechterungen in Single-Chassis-Systemen besser verwalten, indem Sie Fabric-Selbst-Ping- und Packet Forwarding Engine-Liveness-Mechanismen integrieren. Fabric-Self-Ping ist ein Mechanismus zur Erkennung von Problemen im Fabric-Datenpfad. Mithilfe des Selbst-Ping-Mechanismus der Fabric Packet Forwarding Engine dass ein an sich bestimmtes Paket sie erreicht, wenn das Paket über den Fabric-Pfad gesendet wird. Packet Forwarding Engine live ist ein Mechanismus, um zu erkennen, ob ein Packet Forwarding Engine auf der Fabric-Ebene erreichbar ist. Um sicherzustellen, dass dies erreichbar ist, sendet Packet Forwarding Engine gelegentlich ein selbstbestimmtes Paket über die Fabric-Ebene. Wenn bei diesen beiden Mechanismen ein Fehler erkannt wird, löst der Fabric-Manager einen Alarm in der Fabric aus und initiiert die Wiederherstellung durch Neustart der Linekarte.

Router-Fabric-Ausfallsicherheit der MX-Serie

MX-Router bieten intelligente Mechanismen zur Reduzierung von Paketverlusten in Hardwarefehlern.

Dieses Thema enthält die folgenden Abschnitte, in denen die Optionen zur Ausfallsicherheit der Fabric, die verwendeten Methoden zur Fehlererkennung und Korrekturmaßnahmen beschrieben werden:

Fabric-Konnektivitätswiederherstellung

Packet Forwarding Engine Ziele können aus folgenden Gründen unerreicht werden:

  • Die Steuerkarten gehen offline, wenn ein Befehl CLI oder eine bedruckte physische Schaltfläche verwendet wird.

  • Die Fabric-Steuerkarten werden wegen hoher Temperatur offlinegeschaltet.

  • Spannungs- oder Abfragefehler bei E/A-Fehlern in der Fabric.

  • Alle Packet Forwarding Engines erhalten Zielfehler auf allen Ebenen von Remote-Packet Forwarding Engines, selbst wenn die Fabrics online sind.

  • Vollständiger Fabric-Verlust, der durch Ziel-Timeouts verursacht wird, selbst wenn die Fabrics online sind.

Wenn das System unbekannte Unbekanntes Packet Forwarding Engine erkennt, wird die Fabric-Konnektivität wiederherstellung versucht. Wenn die Wiederherstellung ausfällt, schaltet das System die Schnittstellen aus, um lokale Schutzmaßnahmen zu auslösen oder das Datenverkehrs-Rerouten zu den benachbarten Routern auszulösen.

Der Wiederherstellungsprozess umfasst folgende Phasen:

  1. Neustartphase der Fabric-Ebene: Wiederherstellung wird versucht, indem die Fabric-Plane nach und nach neu gestartet wird. Diese Phase beginnt nicht, wenn die Fabric-Ebene ordnungsgemäß funktioniert und nur von einer Linecard ein Fehler gemeldet wird. Es wird eine Fehlermeldung generiert, um anzugeben, dass ein Verbindungsverlust der Grund dafür ist, dass die Fabric-Ebene offline genommen wird. In dieser Phase werden nur Fehler auf der Fabric-Ebene ausgeführt.

  2. Neustartphase der Fabric-Ebene und Der Linekarten: Das System wartet darauf, dass die erste Phase abgeschlossen wird, bevor der Systemstatus erneut untersucht wird. Wird die Verbindung nach der ersten Phase nicht wiederhergestellt oder tritt das Problem innerhalb von 10 Minuten erneut auf, wird die Verbindung wiederhergestellt, indem sowohl die Fabric-Ebene als auch die Linekarten neu gestartet werden. Wenn Sie die Anweisung auf Hierarchieebene konfigurieren, um den Neustart der Linekarten zu deaktivieren, wenn eine Wiederherstellung versucht wird, wird ein Alarm ausgelöst, um einen Verbindungsverlust action-fpc-restart-disable [edit chassis fabric degraded] anzuzeigen. In dieser zweiten Phase werden drei Schritte unternommen:

    1. Alle Linekarten, die Zielfehler in einem PFE haben, sind offline.

    2. Die Fabric-Ebenen werden offline geschaltet und nach und nach online gebracht. Das beginnt mit der Ersatzebene.

    3. Die Offline-aktivierten Linekarten werden wieder online gebracht.

  3. Offline-Phase der Linekarte: Das System wartet darauf, dass die zweite Phase abgeschlossen ist, bevor der Systemstatus erneut untersucht wird. Der Verbindungsverlust wird begrenzt, indem die Linekarten offline genommen und Schnittstellen ausgeschaltet werden, da frühere Wiederherstellungsversuche fehlgeschlagen sind. Wenn das Problem nicht durch einen Neustart der Linekarten gelöst wird oder das Problem innerhalb von 10 Minuten nach Neustart der Linekarten erneut auftritt, wird diese Phase ausgeführt.

Die drei Phasen werden durch Timer gesteuert. Wenn in diesen Phasen eine Veranstaltung (z. B. Offlining/Onlining von Linekarten oder Fabric-Ebenen) mal ausschreitet, wird diese Veranstaltung überspringen und zum nächsten Event durchgeführt. Die Timer-Steuerung hat einen Timeout-Wert von 10 Minuten. Wenn der erste Fabric-Fehler in einem System mit zwei oder mehr Linekarten auftritt, werden die Fabric-Ebenen neu gestartet. Wenn innerhalb der nächsten 10 Minuten ein weiterer Fabric-Fehler auftritt, werden die Fabric-Ebenen und Linekarten neu gestartet. Wenn der zweite Fabric-Fehler jedoch außerhalb des Timeout-Zeitraums von 10 Minuten auftritt, wird die erste Phase ausgeführt, d. a. der Neustart nur der Fabric-Ebenen.

Wenn die Ziel-Timeouts auf eine bestimmte Linekarte zurückverfolgt werden, beispielsweise eine Quell-Linekarte oder eine Ziel-Linecard, wird nur diese Linecard offline und online aktiviert. Die Fabric-Ebenen werden nicht offline und online geschaltet. Wenn innerhalb von 10 Minuten ein weiterer Fabric-Fehler auftritt, wird die Linekarte offlinegeschaltet.

Standardmäßig begrenzt das System die Verbindungsverluste durch die Erkennung stark beeinträchtigter Fabrics. Es ist keine Benutzerinteraktion erforderlich.

Linekarten mit beeinträchtigter Fabric

Sie können eine Linekarte mit beeinträchtigter Fabric konfigurieren, um in den Offline-Status verschoben zu werden. Auf einem MX960-, MX480- oder MX240-Router können Sie Verbindungsfehler oder fehlerhafte Fabric-Ebenen konfigurieren. Diese Konfiguration ist besonders bei Szenarien mit teilweisem Verbindungsverlust nützlich, bei denen das Offline-Routing der Linekarte zu einem schnelleren Rerouting führt. Verwenden Sie die Anweisung auf der Hierarchieebene, um diese Option auf einer Linekarte offline-on-fabric-bandwidth-reduction [edit chassis fpc slot-number] zu konfigurieren.

Verbindungsverlust nur zu einem Ziel

Bei bestimmten Bereitstellungen gibt eine Linecard einen vollständigen Verbindungsverlust zu einem Ziel an, funktioniert aber für andere Ziele ordnungsgemäß. Ein solcher Fall wird identifiziert und die betroffenen Linecards werden wiederhergestellt. Stellen Sie sich ein Beispielszenario vor, in dem die aktiven Ebenen 0,1,2,3 und die Ersatzebenen 4,5,6,7 in der Verbindung zwischen Linekarte 0 und Linekarte 1 liegen. Wenn bei Linecard 0 einzelne Verbindungsfehler für die Ebenen 0 und 1 auftreten und bei Leitungskarte 1 Einzelverbindungsfehler für die Ebenen 2 und 3 auftreten, kommt es zwischen den beiden Linekarten zu einem vollständigen Verbindungsverlust. Sowohl Linecard 0 als auch Linecard 1 durchlaufen eine phasenweise Wiederherstellung und Fabric-Healing.

Redundanz Fabric-Modus auf aktiven Steuerkarten

Sie können die aktive Steuerplatine so konfigurieren, dass sie im Redundanzmodus oder im Fabric-Modus mit erhöhter Bandbreite ist. Verwenden Sie die Anweisung auf der Hierarchieebene, um den Redundanzmodus für die aktive Steuerplatine redundancy-mode redundant [edit chassis fabric] zu konfigurieren.

Erkennung und Korrekturmaßnahmen von Linekarten mit beeinträchtigter Fabric auf Routern der MX-Serie

Sie können eine Linekarte mit beeinträchtigter Fabric konfigurieren, damit sie auf einem Router der Reihe, MX960, MX480 MX240 oder einem anderen Router in den Offline-Status verschoben werden kann. Die Konfiguration dieser Funktion beeinträchtigt das System nicht. Sie können diese Funktion konfigurieren, ohne die Linekarte neu zu starten oder das System neu zu starten.

Wenn Sie die Funktion konfigurieren, um Linekarten mit einer beeinträchtigten Fabric zu deaktivieren, können die folgenden Szenarien auftreten:

  • Wenn eine Linekarte die Fabric-Bandbreite beeinträchtigt hat und Sie diese Funktion so konfigurieren, dass eine solche Linecard ausgeschaltet wird, nachdem sie eine zeitlang mit einem beeinträchtigten Fabric ausgeführt wurde, wird immer noch eine Korrekturmaßnahme ergriffen.

  • Wenn eine Linekarte aufgrund von Fabric-Fehlern offline gebracht wurde und diese Funktion, um die Linekarte in den Offline-Status zu verschieben, deaktiviert ist, wird die Linekarte automatisch in den Onlinestatus umgeschaltet.

  • Wenn eine Linekarte aufgrund von Fabric-Fehlern offline gebracht wurde und diese Funktion, um die Linekarte in den Offline-Status zu verschieben, deaktiviert oder für eine andere Linekarte konfiguriert ist, wird die Offline-Linekarte automatisch in den Onlinestatus umgeschaltet.

  • Alle Linekarten, die aufgrund einer beeinträchtigten Fabric zum Internet gebracht wurden, wenn Sie diese Einstellung konfiguriert haben, werden wieder online gebracht, wenn Sie eine Konfiguration in der [edit chassis] Hierarchieebene festlegen. In ähnlicher Weise führt ein Neustart des Chassis-Daemon oder des Graceful Routing-Engine Switchover-Betriebs (GRES) dazu, dass die Linecard deaktiviert ist, da eine verminderte Fabric in den Onlinestatus verschoben wird.

Degraded Fabric bedeutet, dass eine Linekarte mit weniger aktiven Fabric-Ebenen im Betrieb ist. Wenn eine Linekarte mit weniger als vier Ebenen ausgeführt wird, wird sie als beeinträchtigt angesehen. Diese Regel gilt für alle Arten von Linekarten und Fabrics. In einem zustandsverschlechterungen Zustand steht dafür, dass ein gutes Fabric-Datenverkehr mit weniger Bandbreite vorhanden ist.

Die folgenden Bedingungen können zu einer Verschlechterung der Fabric führen:

  • Die Fabric-Steuerkarten gehen infolge von unbeabsichtigter Leistungsabschaltung offline.

  • Fehler bei anwendungsspezifischen integrierten Schaltungen (ASIC), die dazu führen, dass eine Control Board-Ebene automatisch offline genommen wird.

  • Manuelles Aktivieren der Fabric-Ebene oder der Steuerplatine auf den Offline-Status.

  • Entfernung der Steuerplatine

  • Fehler beim Selbst-Ping auf jeder Ebene.

  • Fehler bei der HSL2-Schulung für die Active Plane.

  • Wenn auf einer Ersatz-Fabric-Ebene CRC-Fehler auftreten und diese Ersatzebene online gemacht wird, ist die Verbindung mit dem CRC-Fehler deaktiviert. Dieser Mechanismus kann zu einer Beeinträchtigung der Fabric in einer Richtung und zu Null-Route in die andere Richtung führen.

  • Wenn ein Selbst-Ping- oder HSL2-Trainingsfehler auftritt, ist die Fabric-Ebene für eine bestimmte Linecard deaktiviert und online für andere Linekarten. Diese Bedingung kann auch eine Null-Route verursachen.

Wenn Sie während einer Systemwartung die Steuerplatine entfernen oder eine Fabric-Ebene in den Offline-Status verschieben müssen, müssen Sie die Funktionalität aktivieren, damit die Linekarten mit verminderter Bandbreite auf den Offline-Status umgeschaltet werden können (mithilfe der Anweisung auf der offline-on-fabric-bandwidth-reduction [edit chassis fpc slot-number] Hierarchieebene).

Bei Null-Route- oder Fabric-Verschlechterungen werden die folgenden Korrekturmaßnahmen ausgeführt:

  • Unabhängig davon, ob eine Ersatzsteuerung verfügbar ist oder nicht, wird der Selbst-Ping-Status jeder Linekarte in 5-Sekunden-Abständen am System Routing-Engine. Fabric Manager verwendet die folgende Regel, um das Vorhandensein einer Ersatzsteuerungsplatine zu bestimmen:

    • MX960 mit I-Chip- oder I-Chip- sowie Trio-Chip-basierten Linekarten mit drei Steuerkarten

    • MX240- oder MX480-Router mit I-Chip oder I-Chip sowie Linekarten auf Trio-Chip-Basis mit zwei Steuerkarten

    • MX960-, MX480- oder MX240-Routern, die nur Trio-basierte Linekarten enthalten, gelten nicht als Ersatz-Control Board

    Wenn in einem Intervall von 5 Sekunden zwei Linekarten auf einen Fehler in der gleichen Ebene hinweisen, wird ein Switchover zur Ersatzsteuerungskarte angezeigt. In diesem Fall wird die Steuerplatine, die Gemeldete Fehler meldet, offline genommen und die Ersatzsteuerungsplatine online gemacht.

  • Wenn ein Ersatz-Control Board verfügbar ist und Sie die Funktionen konfigurieren, um Linekarten mit beeinträchtigter Fabric zu deaktivieren, wird der Selbst-Ping-Status jeder Linecard in 5-Sekunden-Intervallen des Status Routing-Engine. Folgende Bedingungen können auftreten:

    • Wenn nur eine Leitungskarte in einem Intervall von 5 Sekunden einen Fehler für eine Ebene angibt, wartet der Fabric Manager auf das nächste Intervall. Wenn in dem nachfolgenden Intervall keine andere Linekarte einen Fehler auf der gleichen Ebene angibt, wird die Switchover der Steuerplatine ausgeführt.

    • Wenn in einem Intervall von 5 Sekunden mehrere Linekarten Ausfälle für mehrere Steuerkarten anzeigen, wartet der Fabric Manager auf das nächste Intervall. Wenn sich derselbe Zustand im nachfolgenden Intervall befindet, werden alle leitungsgef lassenden Linekarten auch dann offline, wenn die Ersatzsteuerung vorhanden ist.

    • Wenn in einem Intervall von 5 Sekunden eine Leitungskarte einen Fehler für mehrere Ebenen in mehreren Steuerkarten zeigt, wartet der Fabric Manager mit dem nächsten Intervall. Wenn derselbe Zustand im nachfolgenden Intervall beibehalten wird, wird die Linekarte offlinegeschaltet, selbst wenn die Ersatzsteuerung vorhanden ist.

  • Wenn keine Ersatzebenen verfügbar sind, wird die Linekarte offlinegeschaltet, wenn ein Fehler für eine einzelne oder mehrere Ebenen angezeigt wird. Die Linekarte wird nur offline gebracht, wenn Sie die Anweisung zuvor offline-on-fabric-bandwidth-reduction auf der [edit chassis fpc slot-number] Hierarchieebene konfiguriert haben.

Verstehen der Fabric-Fehlerbehandlung auf T4000 Router

Der T4000 Router besteht aus einer Switch Interface Board (SIB) mit Fabric-Bandbreite, die die Kapazität des Routers T1600 verdoppelt. Die Fabric-Fehlerverwaltungsfunktionen sind mit denen in Routern T1600 vergleichbar. In diesem Thema wird die Fabric-Fehlerbehandlungsfunktionen auf Routern T4000 beschrieben.

Die Fabric-Fehlerverwaltung umfasst die Überwachung aller mit der Fabric verbundenen Hochgeschwindigkeitsverbindungen und der mit dem Fabric-Core verbundenen Hochgeschwindigkeitsverbindungen auf Verbindungsfehler und Verbindungsfehler.

Die Maßnahmen basieren auf dem Fehler und dem Standort. Die Maßnahmen umfassen:

  • Melden von Verbindungsfehlern in Systemprotokolldateien und Senden dieser Informationen Routing-Engine.

  • Melden von Verbindungsfehlern am Flexible Port Concentrator (FPC) oder an der SIB, und senden diese Informationen an das Routing-Engine.

  • Sib-Markierung im Check Status.

  • SIB in Status Fault verschieben.

Die SIB in T4000 bildet den Kern der Fabric mit 4:1-Redundanz: Die redundante SIB wird aktiv, wenn die aktive SIB nicht mehr verwendet wird, deaktiviert oder entfernt wird. Im Folgenden finden Sie die großen Anzeichen von Fabric-Fehlern, die von einem Überwachungspunkt Junos OS:

  • Ein SNMP-Trap wird generiert, wenn eine SIB wie oder gemeldet Check Fault wird.

  • show chassis alarms— Gibt an, dass sich eine SIB in Check oder dem Fault Status befindet.

  • show chassis sibs— Gibt an, dass sich eine SIB in oder mit dem Status einer SIB befindet, wenn die SIB initialisiert wird (dies geschieht, wenn die SIB nicht Check Fault vollständig Offline eingeordnet wird).

  • show chassis fabric fpcs-Gibt an, ob Fabric-Links auf der FPCs-Seite ein Fehler sind.

  • show chassis fabric sibs-Gibt an, ob Fabric-Links auf der SIBs-Seite ein Fehler sind.

  • Die /var/log/messages Systemprotokollmeldungen-Datei am Routing-Engine enthält Fehlermeldungen mit dem CHASSISD_FM_ERROR Präfix.

  • SiBs zeigen die FAIL LED an.

Hinweis:

Die Fabric-Ebenen im Gehäuse bestimmen, ob es sich um einen Router T640, Router T1600 Router oder einen Router T4000 handelt. Stromversorgungsmodule (PEMs), FPCs oder Lüftereinschübe bestimmen nicht die "Chassis Personality". Alarme werden ausgelöst, wenn die alten PEMs oder Lüfterhalterungen in einem Gehäuse T4000 werden. Sie können einen Router anhand seiner Fabric-Ebenen identifizieren:

  • Wenn alle beteiligten Ebenen F16-basierte SIBs sind, ist das Gehäuse ein T640 Gehäuse.

  • Wenn alle beteiligten Ebenen SF-basierte SIBs sind, ist das Gehäuse ein T1600 Gehäuse.

  • Wenn alle beteiligten Ebenen XF-basierte SIBs sind, ist das Gehäuse ein T4000 Gehäuse.

Beachten Sie, dass die Mischung aus Fabric-Ebenen außer während eines Upgrades keine unterstützte Konfiguration ist. Sie können die "Personality" eines Gehäuses ändern, ohne den Neustart durchführen zu müssen, indem Sie alle Fabric-Ebenen ändern und den Befehl CLI geben, um die set chassis fabric upgrade-mode "Personality" zu überprüfen. Wenn Sie das Kommando nicht CLI haben, ändert sich die set chassis fabric upgrade-mode "Personality" erst beim nächsten Start.

Bei T4000-Routern kommen Sie auf die folgenden Fehler:

  • Fehler auf Board-Ebene: Diese Fehler treten bei der Initialisierung oder in der Laufzeit auf. Stromausfälle während der Board-Initialisierung, Hochgeschwindigkeitsverbindungen Übertragungsfehler und polled I/O-Fehler während der Laufzeit sind einige Beispiele von Fehlern auf Board-Ebene.

  • Fehler auf Verbindungsebene: Diese Fehler treten bei der Initialisierung oder in der Laufzeit auf. Fehler bei der Verbindungsschulung zum Zeitpunkt der Initialisierung (Fehler der Datenebenenverbindungen zwischen einer FPC und einer SIB, die bei der Initialisierung der FPC oder SIB trainiert werden soll), Fehler, der auf dem Kanal zwischen der SIB und einem Packet Forwarding Engine erkannt wird, CRC-Fehler (Cyclic Redundanz Check), die in der Laufzeit erkannt werden, und Packet Forwarding Engine-Zielfehler sind Typen von Fehlern auf Verbindungsebene.

  • Fehler basierend auf Umgebungsbedingungen: Diese Fehler treten in der Laufzeit auf. Das plötzliche Entfernen einer FPC oder SIB kann zu einem Betreiberfehler führen. Wenn eine SIB zu heiß wird oder die SIB-Spannungen Schwellenwerte überschreiten, werden die generierten Fehler in Umweltfehler klassifiziert.

Sie können eine der folgenden Optionen implementieren, um die Fehler zu behandeln:

  • Protokollieren Sie den Fehler, und alarmieren Sie den Alarm.

  • Steigen Sie, falls vorhanden, auf die Ersatzebene um.

  • Fahren Sie mit einer reduzierten Anzahl von Teilen einer Ebene fort.

  • Fahren Sie mit einer reduzierten Anzahl von nutzbaren Ebenen fort.

  • Nutzen Sie eine abfragebasierte Fehlerbehandlung.

  • Überwachen Sie Verbindungsfehler in Hochgeschwindigkeitsgeschwindigkeit, und bringen Sie die Verbindung manuell auf einen geeigneten Schwellenwert.

Die angezeigten E/A-Fehler und Verbindungsfehler werden alle 500 Millisekunden überwacht und die Board-Erschöpfungstemperatur und -spannungen werden alle 10 Sekunden überwacht.

Verstehen der Fabric-Fehlerbehandlung auf PTX5000 Paketübertragungs-Router

Beginnend mit Junos OS Version 14.1 unterstützt der PTX5000 Paketübertragungs-Router neun Switch Interface Boards (SIBs). Jeder FPC2-PTX-P1A FPC unterstützt eine Kapazität von 1 TB pro Steckplatz und ergibt eine Fabric-Bandbreite von 16 Terabit pro Sekunde (Tbit/s), Vollduplex-Switching (8 Tbit/s von Any-to-Any-, nicht blockierende oder halbduplex) Switching.

Die Fabric-Fehlerverwaltung umfasst die Überwachung aller mit der Fabric und den innerhalb des Fabric-Cores verbundenen Hochgeschwindigkeitsverbindungen auf Verbindungsfehler und Verbindungsfehler.

Fehler, die in einem System auftreten PTX5000 lassen sich in grobe Kategorien einordnen:

  • Board-Fehler: Fehler, die bei einer SIB oder in einem Flexible Port Concentrator (FPC) während der Initialisierung oder in der Laufzeit auftreten, einschließlich Problemen, die auftreten, wenn eine Routerkomponente auf die SIB oder FPC zuzugriff oder Probleme, die aus Midplane-Ausfällen entstehen.

  • Verbindungsfehler: Fehler, die bei High-Level-Links in einem Router während der Initialisierung oder in der Laufzeit auftreten.

  • Fehler aufgrund von Umgebungsbedingungen – Fehler, die aufgrund von Überspannung oder Übertemperatur auftreten; -Fehler auftreten, die durch einen Betreiber auftreten, der eine SIB oder eine FPC falsch behandelt hat und so weiter.

Der Router führt Aktionen auf Grundlage der Fehlerkategorie und des Fehlerstandorts durch. Die Maßnahmen umfassen:

  • Melden von Verbindungsfehlern in Systemprotokolldateien und Senden dieser Informationen Routing-Engine.

  • Anzeige der Verbindungsfehler bei Ausführung eines der in Tabelle 1 aufgeführten Betriebsbefehle:

    Tabelle 1: Liste der Betriebsmodusbefehle

    Betriebsmodusbefehl

    Beschreibung

    show chassis sibs

    Zeigt Statusinformationen (Switch Interface Boards, SIBs) an.

    show chassis fabric fpcs <slot number>

    Zeigt den Fabric-Status des angegebenen FPC-Steckplatzes an. Wenn keine Steckplatznummer angegeben wird, wird der Status aller FPCs angezeigt.

    show chassis fabric sibs <slot number>

    Zeigt den Status der elektrischen Switch-Fabric-Verbindung zwischen den SIBs und den FPCs an.

    show chassis fabric reachability <detail>

    Zeigt den aktuellen Zustand der Fabric-Zielverfügbarkeit an.

    show chassis fabric unreachable-destinations

    Zeigt die Liste der Ziele an, die von einem erreichbaren Status in einen nicht erreichbaren Zustand umstellbar sind.

    show pfe statistics error

    Zeigt Packet Forwarding Engine Fehlerstatistiken an.

    show chassis fabric topology <sib_slot>

    Zeigt die Eingangs-Ausgabe-Link-Topologie an.

    show chassis fabric summary

    Zeigt den Status aller Fabric-Ebenen und die verstrichene Verfügbarkeit an.

  • Melden von Verbindungsfehlern auf FPC-Ebene oder auf SIB-Ebene und Senden dieser Informationen Routing-Engine.

  • Melden von Link-Fehlerinformationen im show chassis alarms Betriebsbefehl.

  • SIB in Fehlerstatus verschieben.

In den folgenden Abschnitten werden die Fabric-Fehlerbehandlungsfunktionen auf der PTX5000:

Fehler auf SIB-Ebene

In den folgenden Abschnitten erhalten Sie einen kurzen Überblick über die Typen von Fehlern auf einer SIB und deren Behebung:

Fehlerarten, die auf einer SIB auftreten

Board- und Linkfehler treten bei der Initialisierung und in der Laufzeit auf einer SIB auf. Zu einigen Fehlern kommen Umweltbedingungen wie Überspannung oder Übertemperatur oder wenn ein Betreiber die SIB falsch behandelt.

Hinweis:

Führen Sie die in Tabelle 1 aufgeführten Betriebsmodusbefehle aus, um Fehler zu erkennen.

Während der SIB-Initialisierung und Laufzeit können die folgenden Fehler auftreten:

  • Board-Fehler wie Ausfall der SIBs zum Einschalten, ASICs-Reset-Fehler, Switch Processor Mezine Board (SPMB) abfrageten E/A-Zugriffsfehler auf ASICs, Board-Komponentenfehler wie PIC-Ausfälle oder Zugriffsfehler auf Routerkomponenten.

  • Verbindungsfehler wie Linkfehler auf hoher Ebene, die im Link-Training auftreten.

  • Fehler, die aufgrund von Umgebungsbedingungen oder wegen Fehlverhalten des SIB durch den Betreiber auftreten.

Umgang mit Fehlern auf SIB-Ebene

Die folgende Liste veranschaulicht, wie der Router einen Fehler behandelt, der bei der Initialisierung, während der Laufzeit, aufgrund von Umgebungsbedingungen und wegen Falschhandhabung der SIB durch den Betreiber auf einer SIB auftritt:

  • Um einen Board-Fehler auf einer SIB während der Initialisierung zu verarbeiten, markiert der Chassis-Daemon(chassisd)die SIB als Fehlerstatus. Nachdem die SIB als fehler markiert wurde, findet auf dieser SIB kein Betrieb statt.

  • Um einen Board-Fehler auf einer SIB in der Laufzeit zu verarbeiten, protokolliert die Gehäuse einen Fehler in der Systemprotokolldatei, löst einen Fehlertyp der Alarmanzeige aus und markiert die SIB als fehlerbefehler. Nachdem die SIB als fehler markiert wurde, findet auf dieser SIB kein Betrieb statt.

  • Um einen Linkfehler auf einer SIB in der Laufzeit zu beheben, wenn in der Link-Schulung ein Verbindungsfehler auftritt, wird die Chassis-Funktion über die FPC informiert, die der Link entspricht, auf dem der Fehler aufgetreten ist, um die Verbindungen mit der betroffenen SIB zu deaktivieren. Das Gehäuse sendet dann eine Fehlermeldung an alle anderen FPCs im Router, um die Verwendung der fehlerhaften SIB-Verbindung zu beenden. Es wird ein Linkfehleralarm generiert. Beachten Sie, dass SIB deaktiviert ist, wenn mehr als eine FPC-Fehler für eine bestimmte SIB melden, und kein Datenverkehr von der betroffenen SIB Packet Forwarding Engine gesendet wird.

  • Um einen Verbindungsfehler auf einer SIB in der Laufzeit zu beheben, markiert das Gehäuse die SIB als fehleranfällig und gibt einen Grund für den Fehler an, und die SIB ist deaktiviert.

  • Bei Umgebungsfehlern – Überspannung oder Übertemperatur – wird die SIB sofort offline genommen. Beachten Sie, dass regelmäßig ein Fehler protokolliert wird, wenn die Temperatur oder Spannung steigt, und die SIB offline genommen wird, wenn sie eine bestimmte Grenzwertspannung oder -temperatur überschreitet.

  • Wenn eine SIB plötzlich entfernt oder dislodiert wird, verwenden alle betroffenen Packet Forwarding Engines diese Ebene nicht mehr, um andere Packet Forwarding Engines im Router zu erreichen.

Fehler auf FPC-Ebene

In den folgenden Abschnitten erhalten Sie einen kurzen Überblick über die Arten von Fehlern in einer FPC und deren Behebung:

Fehlerarten, die auf einer FPC auftreten

Board-Fehler und Verbindungsfehler treten bei der Initialisierung und in der Laufzeit auf einer FPC auf. Zu einigen Fehlern kommen auch Umweltbedingungen wie Überspannung, Übertemperatur oder wenn der Betreiber die FPC falsch behandelt.

Hinweis:

Führen Sie die in Tabelle 1 aufgeführten Betriebsbefehle aus, um Fehler zu erkennen.

Während der FPC-Initialisierung und Laufzeit können die folgenden Fehler auftreten:

  • Board-Fehler wie Ausfall der FPCs zum Netzzugriff, Ausfall von ASICs aus der Reset-Phase, PMB befragte E/A-Zugriffsfehler auf ASICs, Board-Komponentenfehler wie PIC-Fehler oder Zugriffsfehler bei Routerkomponenten.

  • Verbindungsfehler wie Linkfehler auf hoher Ebene, die im Link-Training auftreten.

  • Fehler, die aufgrund von Umgebungsbedingungen oder wegen Misshandling einer FPC durch den Betreiber auftreten.

Umgang mit FPC-Fehlern

Die folgende Liste zeigt, wie der Router einen Fehler behandelt, der bei der Initialisierung, in der Laufzeit, aufgrund von Umgebungsbedingungen und wegen Falschhandhabung der FPC durch den Betreiber auf einem FPC auftritt:

  • Um einen Board-Fehler an einer FPC während der Initialisierung zu beheben, markiert das Gehäuse die FPC als Fehlerzustand. Nachdem die SIB als fehler markiert wurde, findet auf dieser FPC kein Betrieb statt.

  • Um einen Board-Fehler auf einer FPC während der Laufzeit zu behandeln, protokolliert Chassisd einen Fehler in der Systemprotokolldatei, löst einen Fehlerfehler in der Alarmanzeige aus und markiert die FPC als fehlerbefehler. Nachdem die FPC als fehler markiert wurde, findet auf dieser FPC kein Betrieb statt.

  • Um integrierte Verbindungsfehler bei der FPC während der Initialisierung oder während der Laufzeit zu beheben, wird die FPC heruntergefahren, und alle betroffenen Packet Forwarding Engines verwenden diese Ebene nicht mehr, um andere Packet Forwarding Engines im Router zu erreichen.

    Hinweis:

    Bei der Initialisierung werden keine Ebenen heruntergefahren, da der Link-Schulungsprozess für die Fabric noch nicht abgeschlossen ist.

    Integrierte Verbindungsfehler werden in der Laufzeit anhand der aktuellen Konfiguration gelöst. entweder wird die FPC neu gestartet, oder der Fehler wird protokolliert, und die FPC wird mit der Initialisierung fortsetzt.

  • Bei Einem Umgebungsfehler – Überspannung oder Übertemperatur – wird die FPC sofort offline genommen. Beachten Sie, dass regelmäßig ein Fehler protokolliert wird, wenn die Temperatur oder Spannung steigt und der FPC offline genommen wird, wenn er eine bestimmte Grenzwerte oder Temperatur überschreitet.

  • Wenn eine FPC entfernt oder dislodiert wird, senden alle anderen Packet Forwarding Engines den Datenverkehr nicht mehr an die Packet Forwarding Engines in dieser FPC.

Understanding Fabric Fault Handling on Enhanced Switch Fabric Board (SFB2)

Die Router der MX2000-Reihe unterstützen Switch Fabric Boards (SFBs) und verbesserte SFBs (SFB2s), aber nicht beide gleichzeitig. Sfb und SFB2 hosten jeweils drei Fabric-Ebenen. Das Gehäuse unterstützt also insgesamt 24 Ebenen. Junos OS release 15.1F6 und 16.1R1 der Unterstützung der Fabric-Fehlerbehandlung für jede Ebene in SFB und SFB2. In früheren Versionen wird die Fabric-Fehlerbehandlung nicht für jede Ebene, sondern für jeden SFB unterstützt.

Tabelle 2 listet die Unterschiede zwischen der Fabric-Fehlerbehandlung pro Ebene und pro SFB auf.

Tabelle 2: SFB im Vergleich zu SFB2 Fabric Fault Handling

SFB Level (SFB)

Ebenen (SFB und SFB2)

CrC-Fehler (Cyclic Redundancy Check) auf jedem Link auf dem SFB sind auf dem SFB angegeben.

DIE CRC-Fehler auf den Links zu SFB und SFB2 sind auf der Ebene angegeben.

Bei Auftreten von Zielfehlern isoliert die Linekarte den SFB (alle 3 Ebenen).

Wenn Zielfehler auftreten, isoliert die Linekarte die entsprechende Ebene. Andere Ebenen werden weiterhin betrieben.

Fabric-Fehlerbehandlung auf einer Ebene bietet die folgenden Vorteile:

  • Höhere Granularität, die bei der Erkennung, Isolierung und Reparatur von Fehlern hilft.

  • Alarme und Protokollmeldungen liefern Fehlerinformationen pro Ebene anstelle von SFB. Dadurch wird das Debuggen einfacher.

  • Wenn ein SFB über eine einzelne Fehlerebene verfügt, können die anderen beiden Ebenen weiter betrieben werden. Es ist nicht notwendig, den gesamten SFB offline zu nehmen.

  • Bei vorübergehenden Fehlern kann eine einzelne Ebene isoliert werden, anstatt den SFB zu isolieren.

Verwenden Sie die Option mit den vorhandenen Fabric-Befehlen, um Informationen zur Fabric-Fehlerbehandlung für alle 24 extended Ebenen anzuzeigen.

Verwalten der Bandbreitenverschlechterung

Bestimmte Fehler führen dazu, dass Pakete ohne Benachrichtigung von einem System verworfen werden. Andere vernetzte Systeme geben den Datenverkehr weiter an das betroffene System weiter, was sich auf die Netzwerkleistung auswirken wird. Eine stark beeinträchtigte Fabric-Ebene kann einer der Gründe dafür sein.

Standardmäßig versuchen Juniper Networks, eine Bestimmte Situation zu beheben, wenn das System Probleme mit Packet Forwarding Engines erkennt. Wenn dieHeilung ausfällt, schaltet das System die Schnittstellen aus und verhindert so weitere Eskalationen.

Am Junos OS können Sie die Konfigurationserklärung an der Hierarchie verwenden, um Verschlechterungen der Fabric-Ebene zu erkennen und auf sie zu reagieren, wie bandwidth-degradation Sie sie als gut [edit chassis fpc slot-numberfabric] finden. Sie können den Router so konfigurieren, dass festgelegt wird, welche Healing-Aktionen der Router durchführen soll, sobald ein solcher Zustand erkannt wurde. Sie können mithilfe der optionalen Anweisung auch bestimmen, wie die Linekarte auf ein 100-prozentiges Szenario einer Fabric-Verschlechterung blackhole-action reagiert. Dieser Befehl ist optional und setzt die Härteverfahren für die Standard-Fabric um.

Hinweis:

Der bandwidth-degradation Befehl und die offline-on-fabric-bandwidth-reduction Anweisungen schließen sich gegenseitig aus. Wenn beide Befehle konfiguriert sind, wird während der Commit-Prüfung ein Fehler ausgegeben.

Die bandwidth-degradation Anweisung wird mit einem Prozentwert und einer Aktion konfiguriert. Dieser Wert kann zwischen 1 und 99 liegen und steht für den Anteil der Verschlechterungen der Fabric, der erforderlich ist, um eine Antwort von der Linecard percent-age zu erhalten. Das action Attribut bestimmt die Art der Antwort, die die Linekarte ausführt, sobald die Fabric-Verschlechterung den konfigurierten Prozentsatz erreicht.

Die Aussage wird nur mit einem Attribut konfiguriert und löst dann aus, wenn der Prozentsatz der Fabric-Verschlechterung action 100 Prozent erreicht.

Die folgenden Aktionen können auf jede Konfigurationserklärung angewendet werden:

  • log-only: Eine Nachricht wird in den Chassis- und Nachrichtendateien protokolliert, wenn der Grenzwert der Fabric-Verschlechterung erreicht wird. Es werden keine weiteren Maßnahmen ergriffen.

  • restart: Die Linekarte mit einer beeinträchtigten Fabric-Ebene wird neu gestartet, sobald der Grenzwert erreicht ist.

  • offline: Die Linekarte mit einer beeinträchtigten Fabric-Ebene wird offline genommen, sobald der Schwellenwert erreicht ist. Die Linecard erfordert einen manuellen Eingriff, um wieder online zu sein. Dies ist die Standard aktion, wenn kein Aktionsattribut konfiguriert ist.

  • restart-then-offline: Die Linekarte mit einer beeinträchtigten Fabric-Ebene wird neu gestartet, sobald der Grenzwert erreicht ist. Und wenn innerhalb von 10 Minuten eine Verschlechterung der Fabric-Ebene erkannt wird, wird die Linekarte offline genommen. Die Linecard erfordert einen manuellen Eingriff, um wieder online zu sein.

Hinweis:

Diese Funktion ist im Veröffentlichungs-Junos OS verfügbar 15.1R1.

Neustart der Linekarte zur Begrenzung der Wiederherstellungsmaßnahmen bei beeinträchtigten Fabric-Bedingungen

Sie können Neustarts der Linekarten deaktivieren, um Wiederherstellungsaktionen von einer beeinträchtigten Fabric-Bedingung zu begrenzen. Auf T640- T1600 Router wird nur die Fabric-Ebene neu gestartet. Auf Routern der PTX-Serie werden nur die Switch Interface Boards (SIBs) neu gestartet. Verwenden Sie die Anweisung auf der Hierarchieebene, um den Neustart von Linekarten action-fpc-restart-disable [edit chassis fabric degraded] zu deaktivieren:

Wenn ein Neustart der Linekarte deaktiviert ist, wird ein Alarm ausgelöst, wenn im Router unerreichte Ziele vorhanden sind. Sie müssen die Linekarten manuell neu starten.

Um sicherzustellen, dass sowohl die Fabric-Ebenen (T640 als auch T1600-Router) bzw. die SIBs (Router der PTX-Serie) und die Linekarten während des Wiederherstellungsprozesses neu gestartet werden, konfigurieren Sie die Anweisung nicht auf der action-fpc-restart-disable [edit chassis fabric degraded] Hierarchieebene.

Deaktivieren einer FPC mit beeinträchtigter Fabric-Bandbreite

Sie können eine FPC mit beeinträchtigter Fabric-Bandbreite offline bringen, um zu vermeiden, dass eine Null-Route für einen längeren Zeitraum im Gehäuse verursacht wird. Verwenden Sie die Anweisung auf der Hierarchieebene, um die Option zum Deaktivieren einer FPC mit verminderter offline-on-fabric-bandwidth-reduction [edit chassis fpc slot-number] Bandbreite zu konfigurieren:

Der Fabric-Manager überprüft regelmäßig die Anzahl der aktuellen aktiven Ebenen. Wenn die Anzahl der aktiven Ebenen unter der erforderlichen Anzahl aktiver Ebenen für einen bestimmten Router liegt, wartet das System 10 Sekunden, bevor korrekturmaßnahmen ergriffen werden. Wenn die verringerte Bandbreitenbedingung für eine FPC beibehalten wird und diese Funktion für die FPC konfiguriert wurde, wird die FPC offline.

Fehlerbehandlung durch Fabric OAM

Fabric Operation, Administration, Maintenance (OAM) hilft bei der Erkennung von Fehlern in Fabric-Pfaden. Fabric OAM überprüft die Fabric-Konnektivität, bevor Sie Datenverkehr auf einer Fabric-Ebene senden, wenn ein neuer Fabric-Pfad für ein PFE eingerichtet wird. Wenn ein Fehler erkannt wird, meldet die Software den Fehler und vermeidet die Verwendung dieser Fabric-Ebene für dieses PFE. Diese Funktion sendet eine sehr niedrige Paket pro Sekunde (PPS) selbstbestimmten OAM-Datenverkehr über jede der verfügbaren Fabric-Ebenen und erkennt jeglichen Datenverkehrsverlust an den Punkten (Fabric-Self-Ping-Prüfung).

Hinweis:
  • In Junos OS ist 20.4R1 Fabric-OAM-Funktion standardmäßig aktiviert. Sie können die Funktion mithilfe des Befehls CLI set chassis fabric oam detection-disable deaktivieren.
  • In Junos OS Evolved Releases 20.4R2 und 21.1R1 ist die Fabric-OAM-Funktion standardmäßig deaktiviert.

Die Fabric-OAM-Prüfungen werden beim Hochfahren durchgeführt. Die ausgefallenen Pfade sind deaktiviert. Das System führt selbst keine Wiederherstellungsmaßnahmen durch. Sie können die betroffenen Fabric-Ebenen jedoch wiederhergestellt werden, indem Sie die SIBs neu starten. Die Wiederherstellungsschritte hängen von der Art des Fehlers ab.

Wenn dieselbe Fabric-Ebene auf einer einzelnen oder mehreren FPCs ausfällt, starten Sie die SIB mit den ausgefallenen Ebenen mithilfe der folgenden Befehle neu:

user@host> request chassis sib slot slot-number offline

user@host> request chassis sib slot slot-number online

Wenn eine zufällige Fabric-Ebene auf mehreren FPCs ausfällt, kann der Fehler nicht mit einer bestimmten FPC oder SIB isoliert werden. Sie können jedoch versuchen, die Ebenen wiederhergestellt zu werden, indem Sie die SIBs, die die betroffenen Ebenen enthalten, sequenziell neu starten.

Für jeden in der Fabric-OAM-Funktion erkannten Fehler wird ein Syslog generiert. Im Folgenden finden Sie ein Beispiel:

Die folgende syslog-Nachricht bedeutet, dass ein Fabric-OAM-Fehler löschen wurde.

Sie können auch die CLI show system errors active detail Befehlen verwenden und die Fehler im Zusammenhang mit Fabric show system alarms OAM anzeigen.

Die folgende Ausgabe zeigt Details sowohl für Ausfälle der einzelnen Fabric-Ebene (auf Packet Forwarding Engine 0) als auch für alle Fabric-Ebenenausfälle (auf Packet Forwarding Engine 1).

Sie können mit dem Befehl CLI show chassis fabric fpcs Fabric den OAM-Selbst-Ping-Status der einzelnen Fabric-Ebene anzeigen.

Der show chassis fabric fpcs Befehl zeigt die folgende Ausgabe an, wenn die Fabric-OAM-Funktion deaktiviert ist:

Ähnliche Dokumentation

Tabelle zum Versionsverlauf
Release
Beschreibung
14.2R6
Wenn die SIB ab Junos OS Veröffentlichungs-14.2R6 aufgrund extremen Bedingungen wie Hohespannung oder hoher Temperatur offline ist, startet der Router die Fabric-Ebene dieser SIB nicht neu, während des Wiederherstellungsprozesses.
14.2R6
Ausgehend von Junos OS Release 14.2R6 können Sie fabric-Verschlechterungen in Single-Chassis-Systemen besser verwalten, indem Sie Fabric-Selbst-Ping- und Packet Forwarding Engine-Liveness-Mechanismen integrieren.
14.1
Beginnend mit Junos OS Version 14.1 unterstützt der PTX5000 Paketübertragungs-Router neun Switch Interface Boards (SIBs).
13.3
Sie können ab Junos OS Version 13.3 die Router der PTX-Serie verwenden, um Fehlerstufen zu konfigurieren, die mit Packet Forwarding Engine (PFE) verbunden sind, und die Aktionen, die bei Erreichen eines angegebenen Grenzwerts durchgeführt werden.