Grundlegendes zu OpenConfig und gRPC auf der Junos-Telemetrieschnittstelle

Software für Administrationsagenten

Für die Implementierung von OpenConfig mit gRPC für die Telemetrieschnittstelle von Junos müssen Sie ein Paket namens Administrationsagenten herunterladen und installieren, wenn auf Ihrem Gerät von Juniper Networks eine Version von Junos OS mit aktualisiertem FreeBSD ausgeführt wird. Bei allen anderen Versionen von Junos OS ist die Funktionalität des Administrationsagenten in die Software integriert. Der Administrationsagent fungiert als gRPC-Server und beendet die OpenConfig-RPC-Schnittstellen. Es ist auch für das Streaming der Telemetriedaten gemäß der OpenConfig-Spezifikation verantwortlich. Informationen zum Anzeigen der OpenConfig-Spezifikation für Telemetrie finden Sie unter OpenConfig-Telemetriespezifikation. Weitere Informationen zu OpenConfig für Junos OS finden Sie im OpenConfig-Benutzerhandbuch.

Die Komponente des Administrationsagenten unterstützt auch die serverbasierte SSL-Authentifizierung (Secure Sockets Layer). Die clientbasierte SSL-Authentifizierung wird nicht unterstützt. Sie müssen SSL-Zertifikate auf Ihrem Gerät von Juniper Networks installieren.

Informationen über die Installation des Pakets des Administrationsagenten finden Sie unter Installieren des Pakets des Administrationsagenten.

Verwenden von OpenConfig für Junos OS zum Aktivieren der Junos-Telemetrieschnittstelle

OpenConfig für Junos OS gibt ein RPC-Modell an, um die Junos-Telemetrieschnittstelle zu aktivieren. Sie müssen das OpenConfig für Junos OS-Paket herunterladen und auf Ihrem Juniper Networks-Gerät installieren. In diesem Paket sind auch die benötigten YANG-Modelle enthalten.

Sie können alle YANG-Datenmodelle in einem GitHub-Repository für ein bestimmtes Betriebssystem und eine bestimmte Version in einem einzigen Downloadpaket finden. Das Paket und das Repository enthalten die nativen Konfigurations-, Status- und RPC-Datenmodelle sowie die OpenConfig- und IETF-Datenmodelle, die von diesem Betriebssystem unterstützt werden. Sie können auch über die Download-Site von Juniper Networks auf die YANG-Datenmodelle zugreifen.

Navigieren Sie mit einem Webbrowser auf der Webseite von Juniper Networks zur Download-URL für die Software All Junos Platforms: https://www.juniper.net/support/downloads/. Scrollen Sie auf der Registerkarte Netzwerkverwaltung nach unten, um OpenConfig auszuwählen. Wählen Sie die Registerkarte Software aus. Wählen Sie die entsprechende Version des OpenConfig-Moduls aus. Es stehen zwei Versionen zur Verfügung, eine für Geräte mit Junos OS mit aktualisiertem FreeBSD und eine weitere für Geräte, auf denen alle anderen Versionen von Junos OS ausgeführt werden. Weitere Informationen finden Sie unter Installieren des OpenConfig-Pakets und Grundlegendes zu Junos OS YANG-Modulen.

Die programmgesteuerte Schnittstelle OpenConfigTelemetry , die vom Paket des Administrationsagenten installiert wird, definiert den gRPC-Telemetriedienst. Der telemetrySubscribe RPC gibt die folgenden Abonnementparameter an:

• OpenConfig-Pfad, der die Systemressource zum Streamen von Telemetriedaten angibt, z. B.:/interfaces/interface/state/counters/

• Intervall, in dem Daten gemeldet und an den Collector-Server gestreamt werden, in Millisekunden, z. B.: sample_frequency = 4000

Der telemetrySubscribe RPC wird von einem Streamingserver oder -sammler verwendet, um ein Inlineabonnement für Daten im angegebenen Pfad anzufordern. Das Gerät sollte dann Telemetriedaten über dieselbe Verbindung wie die Abonnementanforderung zurücksenden.

GitHub-Ressourcen

GitHub ist eine Code-Hosting-Plattform für Versionskontrolle und Zusammenarbeit. Damit können Sie und andere von überall aus gemeinsam an Projekten arbeiten. Juniper Networks ist Teil der OpenConfig-Community, die GitHub verwendet, um Telemetriecode zu entwickeln und Dokumente zu speichern. Tragen Sie zur Entwicklung der Telemetriedaten von Juniper bei, indem Sie ein Konto auf GitHub erstellen.

Verwenden von gRPC zum Streamen von Daten

Gemäß der OpenConfig-Spezifikation wird nur gRPC-basierter Transport für Streamingdaten unterstützt. Der gRPC-Server, der vom Paket des Administrationsagenten installiert wird, beendet die gRPC-Sitzungen von dem Verwaltungssystem, auf dem der Client ausgeführt wird. RPC-Aufrufe lösen die Erstellung von Junos OS-Sensoren aus, die entweder regelmäßig Daten streamen oder Ereignisse melden, die dann vom Administrationsagenten an den entsprechenden gRPC-Kanal weitergeleitet werden.

In Tabelle 2 finden Sie eine Liste und Beschreibungen der RPCs, die zur Unterstützung der Junos-Telemetrieschnittstelle implementiert wurden.

Daten, die über gRPC gestreamt werden, werden in OpenConfig-Schlüssel-Wert-Paaren in Protokollpuffer-Nachrichten (gpb) formatiert. In diesem universellen Format sind Schlüssel Zeichenfolgen, die dem Pfad der Systemressourcen im OpenConfig-Schema für das überwachte Gerät entsprechen. Die Werte entsprechen ganzen Zahlen oder Zeichenfolgen, die den Betriebszustand der Systemressource, z. B. Schnittstellenindikatoren, und den Zustand der Ressource angeben.

Im Folgenden wird das universelle Schlüssel/Wert-Format veranschaulicht:

Das folgende Beispiel zeigt, wie ein Satz von Leistungsindikatoren für eine Schnittstelle dargestellt werden kann:

Das Administrationsagentenpaket stellt eine Zuordnungstabelle bereit, die Feldnamen den OpenConfig-Schlüsselzeichenfolgen zuordnet.

Exportieren von Datenverkehrssensordaten der Packet Forwarding Engine

Ab Junos OS Version 17.4R1 können Sie Datenverkehrsstatistiken der Packet Forwarding Engine über die Junos-Telemetrieschnittstelle für Router der MX- und PTX-Serie exportieren. Sowohl UDP als auch gRPC werden unterstützt.

Dieser Sensor verfolgt die Berichterstellung von Statistikzählern der Packet Forwarding Engine und bietet Einblicke in die Fehler- und Ausfallstatistiken der Packet Forwarding Engine. Der Ressourcenname für den Sensor lautet /junos/system/linecard/packet/usage/. Die OpenConfig-Pfade melden CPU-, NPU- und Center-Chip-Daten (CC). Die folgenden Pfade werden unterstützt:

• /components/component[name='FPCid:NPUid']/properties/property[name='counter']/state/value, wobei sich FPC auf den flexiblen PIC-Konzentrator und NPU auf die Netzwerkverarbeitungseinheit (Paketweiterleitungs-Engine) bezieht. Ein Beispiel für einen Ressourcenpfad ist /components/component[name='FPC0:NPU3']/properties/property[name='ts-output-pps']/state/value , wobei hwds-data-error der Zähler für Hardware Discards: Data Error.

• /components/component[name='FPCid:CCid’]/properties/property[name='counter’]/state/value , wobei sich FPC auf den flexiblen PIC-Konzentrator und CC auf den mittleren Chip bezieht. Ein Beispielressourcenpfad ist /components/component[name='FPC0:CC1']/properties/property[name='lpbk-packets’']/state/value , wobei lpbk-packets die Anzahl von Forward packets spezifisch für FPC0, Mittelchip 1, ist.

• /components/component[name='FPCid’]/properties/property[name='counter’]/state/value , wobei sich FPC auf den flexiblen PIC-Konzentrator bezieht. Ein Beispiel für einen Ressourcenpfad ist /components/component[name='FPC0']/properties/property[name='lts-input-packets’']/state/value , wo lts-input-packets der CPU-Zähler Local packets inputist.

Um den Sensor zum Exportieren von Daten über gRPC bereitzustellen, verwenden Sie den telemetrySubcribe RPC, um Telemetrieparameter anzugeben. Für das Streaming über UDP werden alle Parameter auf Hierarchieebene [edit services analytics] konfiguriert.

Im Folgenden finden Sie eine Zuordnung der Zähler zu den Ausgabefeldern im Befehl oder show pfe statistics traffic detail Befehl (wird nur auf Routern der show pfe statistics traffic MX-Serie unterstützt).

Bereitstellung von Telemetriedaten für AFT-basierte Linecards auf Routern der MX-Serie

Ab Junos OS Version 20.4R1 wird eine neue Verkettung von Präfix- und Schlüsselbereitstellung für Telemetrie für MPC-Linecards (Modular Port Concentrator) implementiert, die Abstract Forwarding Table (AFT) unterstützen (z. B. MPC10E- oder MPC11E-Linecards). Der OpenConfig-Pfad wird im Vergleich zur Syntax auf anderen Linecards anders aufgeteilt.

Die folgende Ausgabe veranschaulicht die Änderungen bei der Präfix- und Schlüsselübermittlung.

Aktivieren der Unterstützung von "ON CHANGE"-Sensoren durch gNMI

Seit Junos OS Version 16.1 wird das regelmäßige Streaming von OpenConfig-Betriebszuständen und -Zählern unterstützt, wobei Telemetriedaten von Juniper-Geräten in einen externen Collector exportiert werden. Während regelmäßiges Streaming nützlich ist, um alle benötigten Informationen zu sammeln und einen grundlegenden "Snapshot" zu erstellen, ist es für zeitkritische Missionen weniger nützlich. In solchen Fällen können Sie ON_CHANGE Streaming so konfigurieren, dass ein externer Collector nur dann Informationen empfängt, wenn sich der Zustand des Betriebszustands ändert.

Zur Unterstützung ON_CHANGE Streamings wurde eine neue Spezifikation namens gRPC Network Management Interface (gNMI) für die Änderung und den Abruf von Konfigurationen von einem Netzwerkelement implementiert. Darüber hinaus kann die gNMI-Spezifikation verwendet werden, um Telemetrieströme von einem Netzwerkelement zu einem Datenerfassungssystem zu generieren und zu steuern. Mit der neuen gNMI-Spezifikation kann eine gRPC-Dienstdefinition eine einzelne Implementierung auf einem Netzwerkelement sowohl für die Konfiguration als auch für die Telemetrie sowie ein einzelnes NMS-Element für die Interaktion mit einem Gerät mithilfe von Telemetrie- und Konfigurations-RPCs bereitstellen.

Das Junos-Dateipaket (junos-telemetry-interface) enthält die Datei gnmi.proto und die Juniper-Erweiterung GnmiJuniperTelemetryHeader.proto für die gNMI-Unterstützung.

Informationen zu den RPCs, die diese Funktion unterstützen, finden Sie in der gNMI Proto-Dateiversion 0.4.0 (die unterstützte Version) und der veröffentlichten Spezifikation

• https://github.com/openconfig/reference/blob/primary/rpc/gnmi/gnmi-specification.md

• https://github.com/openconfig/gnmi/blob/primary/proto/gnmi/gnmi.proto

Der Telemetrie-RPC subscribe unter dem gNMI-Dienst unterstützt ON_CHANGE Streaming. RPC subscribe ermöglicht es einem Client, das Ziel aufzufordern, ihm Werte bestimmter Pfade innerhalb der Datenstruktur zu senden. Werte können gestreamt (STREAM), einmalig auf einem langlebigen Kanal (POLL) oder einmalig als Abruf (ONCE) gesendet werden.

Wenn ein Abonnement für einen Container der obersten Ebene mit einer Abtasthäufigkeit von 0 abgeschlossen wird, werden Blätter mit ON_CHANGE Unterstützung basierend auf Ereignissen gestreamt. Andere Blätter werden nicht gestreamt.

Aktivieren des "TARGET_DEFINED"-Abonnementmodus über gNMI

Ab Junos OS Version 20.2R1 wird TARGET_DEFINED Abonnementmodus mit gRPC Network Management Interface (gNMI)-Services für JTI auf MX5-, MX10-, MX40-, MX80-, MX104-, MX150-, MX204-, MX240-, MX480-, MX960-, MX2008-, MX2010-, MX2020-, MX10003-, MX10008- und MX10016-Routern unterstützt.

Über ein gNMI-Abonnement legt ein externer Collector fest, wie Sensordaten geliefert werden sollen:

• Im STREAMING-Modus werden in regelmäßigen Abständen Sensordaten vom Prüfling in einem bestimmten Intervall gestreamt.

• ON_CHANGE-Modus sendet nur dann Aktualisierungen für Sensordaten vom Prüfling an, wenn sich die Datenwerte ändern.

• Der neu unterstützte TARGET_DEFINED-Modus (Submode 0) weist den Prüfling an, den entsprechenden Modus (STREAMING oder ON_CHANGE) auszuwählen, um jedes Element (Blatt) der Sensordaten an den externen Kollektor zu liefern. Wenn ein Abonnement für einen Sensor mit Submode 0 vom externen Kollektor an den Prüfling gesendet wird, antwortet der Prüfling und aktiviert das Sensorabonnement, sodass regelmäßiges Streaming keine der ON_CHANGE Updates enthält. Der Prüfling benachrichtigt den Sammler jedoch, wenn qualifizierende ON_CHANGE Ereignisse eintreten.

Für Abonnements wird standardmäßig eine regelmäßige Streamingfrequenz von 30 Sekunden verwendet, sofern der Collector in der Abonnementanforderung nichts anderes angegeben hat.

Die folgende JSON-Datei (Java Script Object Notification) zeigt ein Beispiel für ein gNMI-Abonnement. TARGET_DEFINED Modus wird mit für submode=0 den Ressourcenpfad (Sensor) / interfaces/interface[name='lo0']/state eingestellt.

Das Junos-Dateipaket (junos-telemetry-interface) enthält die Datei gnmi.proto und die Juniper-Erweiterung GnmiJuniperTelemetryHeader.proto für die gNMI-Unterstützung.

Weitere Informationen finden Sie in den gNMI-Spezifikationen und in der gNEMI-Protokolldatei hier:

• gNEMI-Spezifikation: STREAM-Abonnement

• gNEMI-Spezifikation: gNEMI-Protokoll

Aktivieren des "INITIAL_SYNC"-Abonnementmodus über gNMI

Ab Junos OS Version 20.2R1 werden INITIAL_SYNC Statistiken von Packet Forwarding Engine-Sensoren mithilfe von gNMI-Services auf MX960, MX2008, MX2010, MX2020, PTX1000, PTX5000-Routern, PTX10000 Routern sowie QFX5100- und QFX5200-Switches unterstützt.

Ab Junos OS Evolved Version 20.4R1 werden INITIAL_SYNC Statistiken von Packet Forwarding Engine-Sensoren mithilfe von gNMI-Services auf QFX5130-32CD-Switches unterstützt.

Wenn ein externer Collector eine Subskriptionsanfrage für einen Sensor mit INITIAL_SYNC (gnmi-submode 2) sendet, sendet der Host alle unterstützten Zielblätter (Felder) unter diesem Ressourcenpfad mindestens einmal an den Collector mit dem aktuellen Wert. Dies ist aus folgenden Gründen wertvoll:

• Der Kollektor hat einen vollständigen Überblick über den aktuellen Zustand jedes Feldes auf dem Gerät für diesen Sensorpfad.

• Ereignisgesteuerte Daten (ON_CHANGE) werden vom Collector mindestens einmal empfangen, bevor das nächste Ereignis angezeigt wird. Auf diese Weise ist der Collector über den Datenstatus informiert, bevor das nächste Ereignis eintritt.

• Sensoren der Paketweiterleitungs-Engine, die Null-Zählerwerte (Null unterdrückt) enthalten, die normalerweise nicht in gestreamten Daten angezeigt werden, werden gesendet, um sicherzustellen, dass alle Felder von jeder Linecard (auch als Quelle bezeichnet) dem Collector bekannt sind.

INITIAL_SYNC Untermodus erfordert, dass mindestens eine Kopie an den Collector gesendet wird. Es ist jedoch akzeptabel, mehr als eine zu senden.

Für Abonnements wird standardmäßig eine regelmäßige Streamingfrequenz von 30 Sekunden verwendet, sofern der Collector in der Abonnementanforderung nichts anderes angegeben hat.

Die folgende JSON-Datei (Java Script Object Notification) zeigt ein Beispiel für ein gNMI-Abonnement. INITIAL_SYNC Modus wird mit für gnmi_submode 2 den Ressourcenpfad (Sensor) / interfaces/ eingestellt. Die gnmi_mode ist auf festgelegt. 0 Die Protokollkodierung ist auf 2 GBP festgelegt.

Das Junos-Dateipaket (junos-telemetry-interface) enthält die Datei gnmi.proto und die Juniper-Erweiterung GnmiJuniperTelemetryHeader.proto für die gNMI-Unterstützung.

Weitere Informationen finden Sie in den gNMI-Spezifikationen und in der gNEMI-Protokolldatei hier:

gNEMI-Telemetriespezifikation gNMI-Protokolldefinition

• https://github.com/openconfig/reference/blob/primary/rpc/gnmi/gnmi-specification.md#35152-stream-subscriptions

• https://github.com/openconfig/gnmi/blob/primary/proto/gnmi/gnmi.proto

Aktivieren von Client-Streaming und bidirektionalem Streaming von Telemetrie-Sensorinformationen

Ab Junos OS Version 18.1R1 wird die OpenConfig-Unterstützung über Remote Procedure Calls (gRPC) und JTI erweitert, um Client-Streaming und bidirektionales Streaming von Telemetriesensorinformationen auf Routern der MX- und PTX-Serie zu unterstützen.

APIs werden in Junos basierend auf den Protobuf-Spezifikationen für OpenConfig implementiert. Diese APIs führen die Konfiguration, den Abruf des Betriebszustands und die Telemetrie auf Junos-Routern mithilfe von gRPC als Transportmechanismus durch.

Beim Client-Streaming sendet der Client anstelle einer einzelnen Anforderung einen Anforderungsstrom an den Server. Der Server sendet in der Regel eine einzelne Antwort zurück, die Statusdetails und optionale nachfolgende Metadaten enthält. Beim bidirektionalen Streaming senden sowohl Client als auch Server einen Strom von Anforderungen und Antworten. Der Client startet den Vorgang durch Aufrufen des RPC, und der Server empfängt die Clientmetadaten, den Methodennamen und den Stichtag. Der Server kann wählen, ob er seine ursprünglichen Metadaten zurücksendet oder wartet, bis der Client mit dem Senden von Anforderungen beginnt. Client und Server können in beliebiger Reihenfolge lesen und schreiben. Die Streams arbeiten völlig unabhängig.

Junos-Geräte können über API-Prototypen (RPC) verwaltet werden:

• RPC-Funktionen (CapabilityRequest)

  Gibt (CapabilityResponse) zurück. Ermöglicht dem Client das Abrufen der Funktionen, die vom Ziel unterstützt werden.

• rpc Abrufen (GetRequest)

  Gibt (GetResponse) zurück. Ruft eine Momentaufnahme der Daten vom Ziel ab.

• rpc Set (SetRequest)

  Gibt (SetResponse) zurück. Ermöglicht es dem Client, den Zustand der Daten auf dem Ziel zu ändern.

• rpc Subscribe (stream SubscribeRequest)

  Gibt (stream SubscribeResponse) zurück. Ermöglicht es einem Client, das Ziel aufzufordern, ihm Werte für bestimmte Pfade innerhalb der Datenstruktur zu senden. Diese Werte können gestreamt (STREAM) oder einmalig auf einem langlebigen Kanal (POLL) oder als einmaliger Abruf (ONCE) gesendet werden. Wenn ein Abonnement für einen Container der obersten Ebene mit einer Abtasthäufigkeit von 0 abgeschlossen wird, werden Blätter mit ON_CHANGE Unterstützung basierend auf Ereignissen gestreamt. Andere Blätter werden nicht gestreamt.

Die Unterstützung von Juniper Extension Toolkit (JET) bietet Benutzern Einblicke in den Status von Clients, die mit JSD verbunden sind. Die JET-Unterstützung für gRPC umfasst die Erweiterung der maximalen Anzahl von Clients, die eine Verbindung zu JSD herstellen können, von 8 auf 30 (der Standardwert bleibt 5). Um die maximale Anzahl von Verbindungen anzugeben, fügen Sie die max-connections Anweisung auf der Hierarchieebene [edit system services extension-service request-response grpc] ein.

Um Informationen zum Status von Clients bereitzustellen, die mit JSD verbunden sind, geben Sie den show extension-service client information erweiterten Befehl ein und fügen Sie die clients Optionen oder servers hinzu. Die clients Option zeigt Anforderungs-Antwort-Clientinformationen an. Die servers Option zeigt Informationen zum Anforderungs-Antwort-Server an.

Aktivieren des Streamings von Telemetriesensorinformationen für SR-TE-Richtlinien (BGP oder statisch)

Beginnend mit Junos OS Version 18.3R1 bietet die OpenConfig-Unterstützung für die MX- und PTX-Serien über gRPC und JTI kontinuierliches Statistik-Streaming über denselben Sensor, unabhängig von der Route, die für eine bestimmte Segment Routing Traffic Engineering (SR-TE)-Richtlinie aktiv ist (BGP oder statisch).

Support ist in Junos OS Evolved Version 21.4R1EVO für PTX10001-36MR-, PTX10004-, PTX10008- und PTX10016-Router verfügbar.

Diese Funktion bietet Unterstützung für BGP [DRAFT-SRTE] und statisch konfigurierte SR-TE-Richtlinien auf Eingangsroutern.

Um den Sensor zum Exportieren von Daten über gRPC-Streaming bereitzustellen, verwenden Sie telemetrySubscribe RPC, um Telemetrieparameter anzugeben. Geben Sie den Ressourcenpfad /mpls/signaling-protocols/segment-routing/ zum Exportieren dieser Statistiken an.

Zusätzlich zur Konfiguration des Sensors müssen Sie die Statistikerfassung über das Junos-Betriebssystem aktivieren. Fügen Sie dazu die statistics Konfigurationsanweisung auf der Hierarchieebene [edit protocols source-packet-routing telemetry] ein. Optional können Sie Statistiken einschränken, indem Sie den no-transit Parameter oder no-ingress einschließen.

Anweisungen zum Konfigurieren eines Sensors finden Sie unter Konfigurieren eines NETCONF-Proxy-Telemetriesensors in Junos .

Weitere Informationen zu Ressourcenpfaden finden Sie unter Richtlinien für gRPC- und gNMI-Sensoren (Junos Telemetry Interface).

Unterstützung für LSP-Statistiken

Sie können den LSP-Statistiksensor /junos/services/label-switched-path/usage/ bereitstellen, um LSP-Statistiken pro MPLS zu überwachen. Telemetriedaten werden von Junos-Geräten gestreamt und über JTI in konfigurierbaren Intervallen über gRPC an externe Collectors exportiert, ohne dass Polling erforderlich ist.

Die anfängliche Unterstützung dieser Funktion in Junos OS Version 15.1F6 unterstützte Eingangs-LSPs nur, wenn ein Abonnement für /junos/services/label-switched-path/usage/ abgeschlossen wurde. Da diese Funktion in Junos OS Version 17.4R1 um Bypass-Unterstützung erweitert wurde, streamt dieses Abonnement jetzt sowohl Eingangs-LSP- als auch Bypass-LSP-Statistiken an einen Collector.

Statistiken, die gestreamt werden, ähneln der Ausgabe, die von den Befehlen show mpls lsp bypass statistics für den Betriebsmodus und show mpls lsp ingress statisticsangezeigt wird.

Für Bypass-LSPs werden die folgenden exportiert:

• Umgehen Sie LSP, das vom Eingangsrouter des geschützten LSP ausgeht.

• Umgehen Sie LSP, das vom Transitrouter des geschützten LSP stammt.

• Umgehen Sie LSP, um sowohl den Transit-LSP als auch den lokal erstellten LSP zu schützen.

Wenn der Umgehungs-LSP aktiv ist, wird der Datenverkehr sowohl auf den Umgehungs-LSP als auch auf den (geschützten) Eingangs-LSP exportiert.

Um einen Sensor zum Exportieren von Daten über gRPC bereitzustellen, verwenden Sie telemetrySubscribe RPC, um Telemetrieparameter anzugeben. Für das Streaming von Telemetriedaten über gRPC ist außerdem das Modul OpenConfig für Junos OS erforderlich. Sowohl OpenConfig- als auch Network Agent-Pakete werden standardmäßig im Junos OS-Image gebündelt.

Weitere Informationen zur Konfiguration eines UDP-Sensors (native) finden Sie unter Konfigurieren eines Junos Telemetry Interface-Sensors (CLI-Verfahren).

In Tabelle 3 ist der Grad der Unterstützung für LSP-Sensoren nach Plattform aufgeführt.

Benachrichtigung über das Ende der Nachricht für Routing-Engine-Sensoren

Ab Junos OS Version 21.2R1 haben wir ein boolesches EoM-Flag für das Ende der Nachricht für alle JTI Routing-Engine-Sensoren eingeführt. Das Flag benachrichtigt den Kollektor, dass die aktuelle Umwicklung für einen bestimmten Sensorpfad abgeschlossen wurde. Ein Wrap ist ein vollständiges Schlüssel-Wert-Datendump für alle Leaves unter einem Sensorpfad.

Das EoM-Flag ermöglicht es dem Collector auch, zu erkennen, wann das Ende des Wraps eintritt, ohne die Zeitstempelwerte der Stream-Erstellung, die der Collector von den Paketen empfängt, vergleichen zu müssen. Der Vergleich von Zeitstempelwerten ist zeitaufwendig und verzögert die Datenaggregation.

Um diese Funktion mit gRPC Network Management Interface (gNMI)-Transport oder Remote Procedure Call (gRPC) zu verwenden, rufen Sie die Protobuf-Dateien aus der entsprechenden Zweigstelle auf der Download-Site von Juniper Networks ab:

• GnmiJuniperTelemetryHeaderExtension.proto (gNMI)
• agent.proto (für gRPC)

Beispiel: https://github.com/Juniper/telemetry/blob/master/20.3/20.3R1/protos/GnmiJuniperTelemetryHeaderExtension.proto.

Nachdem Sie die neuen protobuf-Dateien heruntergeladen und auf einem Collector installiert haben, ist das EoM-Feld in den empfangenen Paketen vorhanden.

Unterstützung dynamischer Tunnelstatistiken

Ab Junos OS Version 17.4R1 können Sie Zählerstatistiken für dynamische Tunnel der Packet Forwarding Engine mithilfe von nativen (UDP) oder OpenConfig-Telemetriesensoren über JTI in einen externen Collector exportieren.

Die Statistiken werden verwendet, um verschiedene Leistungsmetriken für Netzwerkelemente auf skalierbare und effiziente Weise zu melden und Einblicke in Fehler und Ausfälle der Packet Forwarding Engine zu bieten.

Ein Zeitstempel, der angibt, wann die Zähler zuletzt zurückgesetzt wurden, ist in allen exportierten Daten enthalten, damit Kollektoren feststellen können, ob und wann ein Zurücksetzungsereignis aufgetreten ist. Dies ist z. B. der Fall, wenn die Hardware der P acket Forwarding Engine neu gestartet wird.

Exportierte Statistiken ähneln der Ausgabe des Befehls show nhdb hw dynamic-ip-tunnelsBetriebsmodus .

Um den Statistikexport über gRPC bereitzustellen, verwenden Sie telemetrySubcribe RPC, um ein Abonnement zu erstellen und Telemetrieparameter anzugeben. Fügen Sie den Ressourcenpfad /junos/services/ip-tunnel[name='tunnel-name']/usage/counters[name='counter-name']/ in das Abonnement ein.

Für das Streaming von Telemetriedaten über gRPC ist außerdem das Modul OpenConfig für Junos OS erforderlich. Ab Junos OS Version 18.3R1 werden OpenConfig- und Administrationsagent-Pakete standardmäßig im Junos OS-Image gebündelt. Beide Pakete unterstützen JTI.

Um den Export von Statistiken über UDP zu konfigurieren, schließen Sie den Sensor /junos/services/ip-tunnel/usage/ in die Konfigurationsanweisung sensor (Junos Telemetry Interface) auf der Hierarchieebene [edit services analytics] ein. Alle Parameter für UDP-Sensoren werden auf dieser Hierarchieebene konfiguriert. MX80- und MX104-Router unterstützen nur UDP-Streaming. gRPC wird nicht unterstützt.

FPC- und Optik-Unterstützung

Ab Junos OS Version 19.2R1 unterstützt JTI das Streaming von FPC- (Flexible PIC Concentrator) und Optikstatistiken für die MX-Serie mithilfe von Remote Procedure Calls (gRPC). gRPC ist ein Protokoll zur Konfiguration und zum Abrufen von Zustandsinformationen. Die Unterstützung umfasst die Hinzufügung eines neuen Prozesses (SensorD-Daemon) zum Exportieren von Telemetriedaten für die Integration mit AFTTelementry- und LibTelemetry-Bibliotheken im OpenConfig-Modell namens AFT-Plattform.

Die folgenden Basisressourcenpfade werden unterstützt:

• /junos/system/linecard/environment/

• /junos/system/linecard/optics/

Um den Sensor zum Exportieren von Daten über gRPC bereitzustellen, verwenden Sie telemetrySubcribe RPC, um Telemetrieparameter anzugeben. Für das Streaming von Telemetriedaten über gRPC ist außerdem das Modul OpenConfig für Junos OS erforderlich. Ab Junos OS Version 18.3R1 werden OpenConfig- und Administrationsagent-Pakete standardmäßig im Junos OS-Image gebündelt. Beide Pakete unterstützen JTI.

JTI Broadband Edge Statistics Support für Junos Fusion auf der MX-Serie

Ab Junos OS Version 19.2R1 wird teilnehmerbasiertes Telemetrie-Streaming aktiviert, wenn ein MX-Router für Broadband Network Gateway (BNG) und Junos Fusion konfiguriert ist, bei dem Teilnehmer über Junos Fusion Satellite-Geräte verbunden sind. Sie können Remoteprozeduraufrufe (Remote Procedure Calls, gRPC) verwenden, um BBE-Telemetriestatistiken (Broadband Edge) in externe Collectors zu exportieren.

Sie können alle BBE-Ressourcenpfade streamen, mit Ausnahme der folgenden:

• /junos/system/subscriber-management/access-network/ancp

• /junos/system/subscriber-management/client-protocols/l2tp

• /junos/system/subscriber-management/infra/network/l2tp/

Um BBE-Statistiken zu streamen, fügen Sie Ihrem gRPC-Abonnement einen Ressourcenpfad ein, der mit /junos/system/subscriber-management/ beginnt.

Um den Sensor zum Exportieren von Daten über gRPC bereitzustellen, verwenden Sie den telemetrySubscribe RPC, um Telemetrieparameter anzugeben.

CPU- und NPU-Sensorunterstützung für Router der MX-Serie mit MPC10E-15C-MRATE-Linecards

Junos OS Version 19.3R1 unterstützt CPU- und NPU-Sensoren (Network Processing Unit) auf Routern der MX-Serie mit MPC10E-10C-MRATE- und MPC10E-15C-MRATE-Linecards. JTI ermöglicht den Export von Statistiken von diesen Sensoren an externe Kollektoren in konfigurierbaren Intervallen mithilfe von gRPC-Services.

Im Gegensatz zur Junos-Kernel-Implementierung für die CPU- und NPU-Sensoren in früheren Junos-Versionen verwendet diese Funktion das OpenConfig AFT-Modell. Aus diesem Grund unterscheiden sich der Ressourcenpfad und die Ausgabe des Schlüssel-Wert-Paares (kv) im Vergleich zur Ausgabe des Junos-Kernels.

Verwenden Sie den folgenden Ressourcenpfad zum Exportieren von Statistiken:

/junos/system/linecard/cpu/memory/

/junos/system/linecard/npu/memory/

/junos/system/linecard/npu/utilization/

Um den Sensor zum Exportieren von Daten über gRPC-Dienste bereitzustellen, verwenden Sie den telemetrySubcribe RPC, um Telemetrieparameter anzugeben. Für das Streaming von Telemetriedaten über gRPC ist außerdem das Modul OpenConfig für Junos OS erforderlich. Ab Junos OS Version 18.3R1 werden OpenConfig- und Administrationsagent-Pakete standardmäßig im Junos OS-Image gebündelt. Beide Pakete unterstützen JTI.

Weitere Informationen zu gRPC-Ressourcenpfaden finden Sie unter Richtlinien für gRPC-Sensoren (Junos-Telemetrieschnittstelle).

Schnittstelle Express-Sensor

Der Schnittstellen-Express-Sensor wird von JTI unterstützt, um den Betrieb UP und DOWN Status der Schnittstelle mit einer vom Benutzer konfigurierbaren Rate zu exportieren. Dieser Sensor nutzt die Statistiken des physischen Schnittstellensensors und liefert so schnellere und häufigere Betriebsstatusstatistiken. Es wird nur der Betriebsstatus der physischen Schnittstellen vom Flexible PIC Concentrator (FPC) erfasst und gemeldet. Statistiken von der Routing-Engine-Schnittstelle werden nicht gemeldet.

Sie können den Sensor verwenden, um Statistiken entweder über den UDP-Export (nativ) oder über gRPC-Dienste zu exportieren.

Geben Sie für beide Exportmethoden den folgenden Ressourcenpfad an:

• /junos/system/linecard/intf-exp/

Junos OS Version 18.1R1 unterstützt Schnittstellen-Express-Sensoren für PTX1000-, PTX3000-, PTX5000- und PTX10000-Router.

Junos OS Version 19.3R1 unterstützt Schnittstellen-Express-Sensoren für MX960-, MX2010- und MX2020-Router.

Weitere Informationen zu gRPC-Ressourcenpfaden finden Sie unter Richtlinien für gRPC- und gNMI-Sensoren (Junos Telemetry Interface).

Standby-Routing-Engine-Sensoren für Anwender

JTI unterstützt Streaming-Standby-Routing-Engine-Statistiken mithilfe von gRPC-Services. Diese Funktion wird, sofern nicht anders angegeben, sowohl auf Einzel- als auch auf virtuellen Chassis unterstützt. Verwenden Sie diese Funktion, um den Status von Softwarekomponenten, die auf einer Standby-Routing-Engine ausgeführt werden, besser zu verfolgen. Statistiken, die über die folgenden Sensoren (hauptsächlich unter der Abonnentenverwaltung) an einen externen Collector exportiert werden, bieten einen vollständigeren Überblick über den Systemzustand und den Ausfallsicherheitsstatus:

• Chassis-Rolle (Backup- oder primärer Sensor) /junos/system/subscriber-management/chassis und /junos/system/subscriber-management/chassis[chassis-index=chassis-index] (zum Angeben eines Index für ein Virtual Chassis der MX-Serie)

• Routing-Engine-Status und GRES-Benachrichtigungssensor /junos/system/subscriber-management/chassis/routing-engines/routing-engine und /junos/system/subscriber-management/chassis/routing-engines/routing-engine[re-index=RoutingEngineIndex] (zum Angeben einer Indexnummer für eine bestimmte Routing-Engine)

• Abonnentenverwaltungsprozesssensor /junos/system/subscriber-management/chassis/routing-engines/process-status/subscriber-management-processes/subscriber-management-process und /junos/system/subscriber-management/chassis/routing-engines/process-status/subscriber-management-processes/subscriber-management-process[pid=ProcessIdentifier] (um eine PID für einen bestimmten Prozess anzugeben)

• DHCP-Bindungsstatistiken pro Routing-Engine für Server- oder Relaissensor /junos/system/subscriber-management/chassis/routing-engines/routing-engine/dhcp-bindings/dhcp-element[dhcp-type-name=RelayOrServer/v4] und /junos/system/subscriber-management/chassis/routing-engines/routing-engine/dhcp-bindings/dhcp-element[dhcp-type-name=RelayOrServer/v6]

• Virtual Chassis-Portzählersensor /junos/system/subscriber-management/chassis/virtual-chassis-ports/virtual-chassis-port und /junos/system/subscriber-management/chassis/virtual-chassis-ports/virtual-chassis-port[vcp-interface-name=vcp-interface-port-string] (zum Angeben des Schnittstellennamens). Dieser Ressourcenpfad wird nur auf einem virtuellen Chassis unterstützt.

Junos OS Version 20.2R1 unterstützt Standby-Routing-Engine-Sensoren für MX480-, MX960-, MX10003-, MX2010- und MX2020-Router.

Weitere Informationen zu gRPC- und gNMI-Ressourcenpfaden finden Sie unter Richtlinien für gRPC- und gNMI-Sensoren (Junos Telemetry Interface).

Diameter-Anwendungsprotokoll und Diameter-Peer-Sensoren für Anwender

JTI unterstützt Streaming-Statistiken für Abonnenten für die Diameter-Anwendungsprotokolle Network Access Server Application (NASREQ), Policy and Charging Rules Function (PCRF) und Online Charging System (OCS). Es gibt auch neue Diameter-Peer-Sensoren, die Reaktionszeitmessungen für Nachrichten liefern, die zwischen einem MX-Router und dem Peer für jede der Diameter-Anwendungen ausgetauscht werden. Statistiken werden mit JTI und dem AAA-Modell von Juniper exportiert, das den Telemetrieexport mit gRPC, gNMI oder proprietärem RPC oder UDP von Juniper abdeckt.

Um Anwendungsstatistiken mit Streamdurchmesser zu erstellen, schließen Sie die Ressourcenpfade ein:

• Für NASREQ-Statistiken: /junos/system/subscriber-management/aaa/diameter/clients/nasreq

• PCRF-Statistiken: /junos/system/subscriber-management/aaa/diameter/clients/gx

• Für OCS-Statistiken: /junos/system/subscriber-management/aaa/diameter/clients/gy

Um Antwortzeitmessungen für die Diameter-Anwendungen zu streamen, schließen Sie die Ressourcenpfade in ein Abonnement oder mithilfe der sensor configuration-Anweisung ein:

• Für NASREQ-Messungen verwenden Sie /junos/system/subscriber-management/aaa/diameter/peers/peer[peer_address='peer-address']/nasreq/response-time

• Für PCRF-Messungen verwenden Sie /junos/system/subscriber-management/aaa/diameter/peers/peer[peer_address='peer-address']/gx/response-time

• Für OCS-Messungen /junos/system/subscriber-management/aaa/diameter/peers/peer[peer_address='peer-address']/gy/response-time

Um diese Statistiken für einen Router der MX-Serie für den nativen Export (UDP) zu aktivieren, fügen Sie die sensors Anweisung auf der Hierarchieebene [edit services analytics] ein.

Um den Sensor für den Export von Daten über gNMI bereitzustellen, verwenden Sie den in gnmi.proto definierten Subscribe-RPC, um Anforderungsparameter anzugeben.

Um den Sensor zum Exportieren von Daten über gRPC bereitzustellen, verwenden Sie den telemetrySubscribe RPC, um Telemetrieparameter anzugeben. Für das Streaming von Telemetriedaten über gRPC ist außerdem das Modul OpenConfig für Junos OS erforderlich. Ab Junos OS Version 18.3R1 werden OpenConfig- und Administrationsagent-Pakete standardmäßig im Junos OS-Image gebündelt. Beide Pakete unterstützen JTI.

Junos OS Version 19.3R1 unterstützt Diameter-Anwendungsprotokollsensoren für MX5-, MX10-, MX40-, MX150-, MX204-, MX240-, MX480-, MX960-, MX2008-, MX2010-, MX2020-, MX10003-, MX10008- und MX100016-Router.

Weitere Informationen zu gRPC- und gNMI-Ressourcenpfaden finden Sie unter Richtlinien für gRPC- und gNMI-Sensoren (Junos Telemetry Interface).

Überwachung von Schnittstellen-Bursts

Junos OS Evolved Version 19.3R1unterstützt die Überwachung von Schnittstellen-Bursts auf der Junos Telemetry Interface (JTI), um physische Schnittstellen auf Bursts auf QFX5220-128C- und QFX5220-32CD-Switches zu überwachen. Verwenden Sie die Überwachung von Schnittstellen-Bursts, um Probleme zu beheben, Entscheidungen zu treffen und Ressourcen nach Bedarf anzupassen.

Das Sampling erfolgt in der Millisekunden-Granularität während des Exportintervalls (Fenster). Das Exportintervall wird im Sensor mit dem Abonnement vom Collector konfiguriert. Wenn der Sensor installiert ist, wird in der Packet Forwarding Engine ein Timer gestartet, um die Hardware in Intervallen von 30 bis 100 ms abzufragen. Die Raten in der ersten Exportcharge sind 0.

Das Spitzenbyte ist der Durchschnitt der Anzahl von Bytes, die in einem Samplingintervall angezeigt werden. Bei Bursts, die kürzer als das Abtastintervall dauern, wird das Spitzenbyte über das Intervall gemittelt. Exportierte Statistiken enthalten auch den Zeitpunkt, zu dem Spitzenbytes erkannt werden, sowie die Richtung (Senden oder Empfangen). Die maximale Byterate, die während des Exportintervalls unter allen Samples erkannt wird, wird als Burst betrachtet. Wenn es im Intervall mehrere Bursts mit der gleichen Anzahl von Bytes gibt, wird der erste auftretende Burst als maximaler Burst und der Zeitstempel dieses Bursts als Burst-Zeitstempel betrachtet.

Die Daten für alle physischen Schnittstellen, bei denen es sich um UP-Schnittstellen handelt, werden exportiert. Aggregatschnittstellen werden nicht unterstützt.

Sie können Schnittstellen-Burst-Statistiken vom Juniper-Gerät an einen externen Collector exportieren, indem Sie den Sensor /junos/system/linecard/bmon-sw/ mithilfe von gRPC-Diensten (Remote Procedure Call) in ein Abonnement aufnehmen. Mit diesem Sensor wird nur ein Kollektor unterstützt.

Um den Sensor zum Exportieren von Daten über gRPC-Dienste bereitzustellen, verwenden Sie den telemetrySubcribe RPC, um Telemetrieparameter anzugeben. Für das Streaming von Telemetriedaten über gRPC ist außerdem das Modul OpenConfig für Junos OS erforderlich.

Transceiver-Diagnose

Junos OS Version 19.4R1 unterstützt Transciever-Diagnosesensoren für ON_CHANGE- und Streaming-Statistiken mithilfe von JTI- und gRPC-Services oder gNMI-Services auf MX960, MX2010, MX2020, PTX1000, PTX5000 und der PTX10000-Router-Reihe. Verwenden Sie die Transceiver-Diagnose, um Probleme zu beheben, Entscheidungen zu treffen und Ressourcen nach Bedarf anzupassen.

Diese Funktion unterstützt das OpenConfig-Transceiver-Modell openconfig-platform-transceiver.yang 0.5.0.

Verwenden Sie den Basisressourcenpfad /components/component/transceiver/ in einem gRPC- oder gNMI-Abonnement, um Statistiken vom Juniper-Gerät in einen externen Collector zu exportieren.

Felder, die sich kontinuierlich ändern, wie z. B. Temperatur, Eingangs- und Ausgangsleistung sowie Laser-Bias-Strom, werden für ON_CHANGE nicht unterstützt.

Sensor für physische Ethernet-Schnittstelle

Junos OS-Version 19.4R1 unterstützt physische Ethernet-Schnittstellenstatistiken für ON_CHANGE- und Streaming-Statistiken mithilfe von JTI- und gRPC-Services oder gNMI-Services auf MX960-, MX2020-, PTX1000- und PTX5000-Routern.

Diese Funktion unterstützt das OpenConfig-Modell openconfig-if-ethernet.yang (physische Schnittstellenebene) Version 2.6.2 (keine Konfiguration).

Verwenden Sie den Basisressourcenpfad /interfaces/interface/ethernet/state/ in einem gRPC- oder gNMI-Abonnement, um Statistiken vom Juniper Gerät in einen externen Collector zu exportieren.

VLAN-Sensoren

Junos OS Version 19.4R1 unterstützt das Streaming von VLAN-Statistiken für ON_CHANGE mit JTI- und gRPC-Services auf EX4650- und QFX5120-Switches.

Diese Funktion unterstützt die OpenConfig-Modellkonfigurationsversion 1.0.2 des OpenConfig-Modells openconfig-vlan.yang .

Verwenden Sie den Basisressourcenpfad /vlans/ in einem gRPC-Abonnement, um Statistiken vom Juniper-Gerät in einen externen Collector zu exportieren.

Weitere Endpunkte, die Sie in einem Abonnement verwenden können, sind:

• /vlans/vlan/state/name

• /vlans/vlan/state/vlan-id

• /vlans/vlan/members/

• /vlans/vlan/members/member/interface-ref/state/interface/

• /vlans/vlan/members/member/interface-ref/state/interface/switched-vlan/state/interface-mode

• /vlans/vlan/members/member/interface-ref/state/interface/switched-vlan/state/native-vlan

• /vlans/vlan/members/member/interface-ref/state/interface/switched-vlan/state/access-vlan

• /vlans/vlan/members/member/interface-ref/state/interface/switched-vlan/state/trunk-vlan

• /vlans/vlan/members/member/interface-ref/state/interface/vlan/state/vlan-id