SNMP-Migration zu Telemetrie auf IOS XR
Inhalt
Einleitung
In diesem Artikel werden SNMP-Komponenten (Simple Network Management Protocol) vorgestellt. Außerdem wird eine Korrelation zwischen aktuellen Implementierungen auf Basis der SNMP-Überwachung und dem MDT-Ansatz (Model Driven Telemetry) beschrieben.
SNMP
SNMP ist ein Protokoll auf Anwendungsebene, das ein Nachrichtenformat für die Kommunikation zwischen SNMP-Managern und -Agenten bereitstellt. SNMP stellt ein standardisiertes Framework und eine gemeinsame Sprache zur Überwachung und Verwaltung von Geräten in einem Netzwerk bereit
Komponenten des SNMP
Das SNMP-Framework umfasst die folgenden Komponenten, die in den folgenden Abschnitten beschrieben werden:
SNMP-Manager
Der SNMP-Manager ist ein System, das die Aktivitäten von Netzwerk-Hosts mithilfe von SNMP steuert und überwacht. Das am häufigsten verwendete Verwaltungssystem ist ein Netzwerkmanagementsystem (Network Management System, NMS). Der Begriff NMS kann entweder auf ein dediziertes Gerät für die Netzwerkverwaltung oder auf die auf einem solchen Gerät verwendeten Anwendungen angewendet werden.
SNMP-Agent
Der SNMP-Agent ist die Softwarekomponente innerhalb eines verwalteten Geräts, das die Daten für das Gerät verwaltet und diese Daten nach Bedarf an die verwalteten Systeme meldet. Der Agent befindet sich auf dem Routing-Gerät (Router, Zugriffsserver oder Switch).
SNMP-MIB
Ein SNMP-Agent enthält MIB-Variablen, deren Werte vom SNMP-Manager durch die Vorgänge 'Get' oder 'Set' angefordert oder geändert werden können. Ein Manager kann einen Wert von einem Agenten abrufen oder einen Wert in diesem Agenten speichern. Der Agent sammelt Daten aus der SNMP MIB, dem Repository für Informationen zu Geräteparametern und Netzwerkdaten. Der Agent kann auch auf Anfragen des Managers reagieren, um Daten abzurufen oder festzulegen.
In der folgenden Abbildung wird die Kommunikation zwischen dem SNMP-Manager und dem SNMP-Agenten dargestellt. Ein Manager sendet einem Agenten Anfragen zum Abrufen und Festlegen der SNMP MIB-Werte. Der Agent antwortet auf diese Anfragen. Unabhängig von dieser Interaktion kann der Agent dem Manager unaufgefordert Benachrichtigungen (Traps oder Informationen) senden, um ihn über Netzwerkbedingungen zu informieren.
SNMP-Betrieb
Die SNMP-Anwendungen führen die folgenden Schritte aus, um Daten abzurufen, SNMP-Objektvariablen zu ändern und Benachrichtigungen zu senden:
SNMP abrufen
Der SNMP GET-Vorgang wird von einem NMS zum Abrufen von SNMP-Objektvariablen durchgeführt. Es gibt drei Arten von GET-Prozessen:
- GET - Ruft die genaue Objektinstanz vom SNMP-Agent ab.
- GETNEXT - Ruft die nächste Objektvariable ab, die ein lexikografischer Nachfolger der angegebenen Variablen ist.
- GETBULK - Ruft eine große Menge an Objektvariablen-Daten ab, ohne dass wiederholte GETNEXT-Vorgänge erforderlich sind.
SNMP-SET
Der SNMP SET-Vorgang wird von einem NMS ausgeführt, um den Wert einer Objektvariablen zu ändern.
SNMP-Benachrichtigungen
Eine wichtige Funktion von SNMP ist die Erstellung unerwünschter Benachrichtigungen von einem SNMP-Agenten.
Unerwünschte (asynchrone) Benachrichtigungen können als Traps oder Inform Requests (Informs) generiert werden. Traps sind Meldungen, die den SNMP-Manager (Simple Network Management Protocol) auf einen Zustand im Netzwerk hinweisen. Informs sind Traps, die eine Anforderung zur Bestätigung des Empfangs vom SNMP-Manager enthalten. Benachrichtigungen können auf unsachgemäße Benutzerauthentifizierung, Neustarts, das Schließen einer Verbindung, den Verlust der Verbindung zu einem Nachbargerät oder andere wichtige Ereignisse hinweisen.
Traps sind weniger zuverlässig als Informationen, da der Empfänger beim Empfang eines Traps keine Bestätigung sendet. Der Absender weiß nicht, ob das Trap empfangen wurde. Ein SNMP-Manager, der eine Inform empfängt, bestätigt die Nachricht mit einer SNMP-Response Protocol Data Unit (PDU). Wenn der Absender keine Antwort erhält, kann die Benachrichtigung erneut gesendet werden. Daher erreichen Informationen mit höherer Wahrscheinlichkeit ihr beabsichtigtes Ziel.
Traps werden oft bevorzugt, obwohl sie weniger zuverlässig sind, da Informationen mehr Ressourcen im Gerät und im Netzwerk belegen. Im Gegensatz zu einem Trap, der verworfen wird, sobald er gesendet wird, muss eine Information gespeichert werden, bis eine Antwort empfangen wird oder die Anforderung abgelaufen ist. Außerdem werden Traps nur einmal gesendet, während eine Benachrichtigung mehrmals gesendet werden kann. Die Wiederholungsversuche erhöhen den Datenverkehr und tragen zu einem höheren Overhead im Netzwerk bei. Die Verwendung von Traps und Informationen erfordert einen Kompromiss zwischen Zuverlässigkeit und Ressourcen.
MIB und RFC
Management Information Base (MIB)-Module werden in der Regel in Request for Comments (RFC)-Dokumenten definiert, die an die Internet Engineering Task Force (IETF), eine internationale Standardisierungsorganisation, übermittelt werden. RFCs werden von Einzelpersonen oder Gruppen geschrieben, um von der Internet Society und der Internet Community als Ganzes geprüft zu werden, in der Regel mit der Absicht, einen empfohlenen Internetstandard zu etablieren. Vor der Vergabe des RFC-Status werden die Empfehlungen als Internet Draft (I-D)-Dokumente veröffentlicht. RFCs, die zu empfohlenen Standards wurden, werden auch als Standarddokumente (STDs) bezeichnet. Informationen über den Standardisierungsprozess und die Aktivitäten der IETF finden Sie auf der Website der Internet Society unter http://www.isoc.org. http:/ Den vollständigen Text aller RFCs, I-Ds und STDs, auf die in der Cisco Dokumentation verwiesen wird, finden Sie auf der IETF-Website unter /www.ietf.org.
Die Cisco SNMP-Implementierung verwendet die in RFC 1213 beschriebenen Definitionen von MIB II-Variablen und die in RFC 1215 beschriebenen Definitionen von SNMP-Traps.
Cisco bietet für jedes System eigene private MIB-Erweiterungen an. Cisco Enterprise MIBs erfüllen die in den entsprechenden RFCs beschriebenen Richtlinien, sofern in der Dokumentation nichts anderes angegeben ist. Die MIB-Moduldefinitionsdateien und die Liste der auf jeder Cisco Plattform unterstützten MIBs finden Sie auf der Cisco MIB-Website unter Cisco.com.
Versionen von SNMP
Derzeit unterstützen Cisco Geräte die folgenden SNMP-Versionen:
- SNMPv1 - Simple Network Management Protocol: ein vollständiger Internetstandard, definiert in RFC 1157. (RFC 1157 ersetzt frühere Versionen, die als RFC 1067 und RFC 1098 veröffentlicht wurden.) Die Sicherheit basiert auf Community-Strings.
- SNMPv2c - Das Community String-basierte Administrations-Framework für SNMPv2. SNMPv2c (das "c" steht für "community") ist ein experimentelles Internetprotokoll, das in RFC 1901, RFC 1905 und RFC 1906 definiert ist. SNMPv2c ist ein Update der Protokollvorgänge und Datentypen von SNMPv2p (SNMPv2 Classic) und verwendet das Community-basierte Sicherheitsmodell von SNMPv1.
- SNMPv3 - Version 3 von SNMP. SNMPv3 ist ein interoperables, standardbasiertes Protokoll, das in den RFCs 3413 bis 3415 definiert ist. SNMPv3 bietet sicheren Zugriff auf Geräte durch die Authentifizierung und Verschlüsselung von Paketen über das Netzwerk.
SNMPv3 bietet die folgenden Sicherheitsfunktionen:
- Nachrichtenintegrität - Sicherstellen, dass ein Paket während der Übertragung nicht manipuliert wurde
- Authentication (Authentifizierung): Ermitteln, dass die Nachricht von einer gültigen Quelle stammt.
- Verschlüsselung - Das Verschlüsseln des Inhalts eines Pakets, um zu verhindern, dass es von einer nicht autorisierten Quelle erfasst wird.
Sowohl SNMPv1 als auch SNMPv2c verwenden eine Community-basierte Form der Sicherheit. Die Community der SNMP-Manager, die auf die Agenten-MIB zugreifen können, wird durch einen Community-String definiert.
Die SNMPv2c-Unterstützung umfasst einen Massenabrufemechanismus und detaillierte Fehlermeldungsberichte an Verwaltungsstationen. Der Bulk-Retrieval-Mechanismus unterstützt den Abruf von Tabellen und großen Informationsmengen, wodurch die Anzahl der erforderlichen Round-Trips auf ein Minimum reduziert wird. Die verbesserte Fehlerbehandlungsunterstützung für SNMPv2c umfasst erweiterte Fehlercodes, die verschiedene Fehlertypen unterscheiden. Diese Bedingungen werden über einen einzelnen Fehlercode in SNMPv1 gemeldet. Die folgenden drei Ausnahmetypen werden ebenfalls gemeldet: kein solches Objekt, keine solche Instanz und Ende der MIB-Ansicht.
SNMPv3 ist ein Sicherheitsmodell, bei dem eine Authentifizierungsstrategie für einen Benutzer und die Gruppe, in der sich der Benutzer befindet, eingerichtet wird. Eine Sicherheitsstufe ist die zulässige Sicherheitsstufe innerhalb eines Sicherheitsmodells. Die Kombination aus Sicherheitsmodell und Sicherheitsstufe bestimmt, welcher Sicherheitsmechanismus bei der Verarbeitung eines SNMP-Pakets verwendet wird.
Drei Sicherheitsmodelle sind verfügbar: SNMPv1, SNMPv2c und SNMPv3. In der folgenden Tabelle sind die Kombinationen von Sicherheitsmodellen und -ebenen sowie deren Bedeutung aufgeführt.
| Modell |
Stufe |
Authentifizierung |
Verschlüsselung |
Was passiert? |
| V1 |
neinAuthNeinPriv |
Community-String |
Nein |
Verwendet einen Community-String-Abgleich für die Authentifizierung. |
| v2c |
neinAuthNeinPriv |
Community-String |
Nein |
Verwendet einen Community-String-Abgleich für die Authentifizierung. |
| V3 |
neinAuthNeinPriv |
Benutzername |
Nein |
Verwendet einen Benutzernamen-Abgleich für die Authentifizierung. |
| V3 |
AuthNrPriv |
Message Digest 5 (MD5) oder Secure Hash Algorithm (SHA) |
Nein |
Bietet Authentifizierung auf Basis der HMAC-MD5- oder HMAC-SHA-Algorithmen. |
| V3 |
AuthPriv |
MD5 oder SHA |
DES (Data Encryption Standard) |
Bietet Authentifizierung auf Basis der HMAC-MD5- oder HMAC-SHA-Algorithmen. DES-56-Bit-Verschlüsselung zusätzlich zur Authentifizierung nach CBC-DES (DES-56)-Standard |
Es sollte ein SNMP-Agent implementiert werden, um die von der Managementstation unterstützte SNMP-Version zu verwenden. Ein Agent kann mit mehreren Managern kommunizieren.
SNMPv3 unterstützt die RFCs 1901 bis 1908, 2104, 2206, 2213, 2214 und 2271 bis 2275. Weitere Informationen zu SNMPv3 finden Sie in RFC 2570, Introduction to Version 3 des Internetstandard Network Management Framework (dies ist kein Standarddokument).
Yang-Modelle
Yang-Modelle repräsentieren eine baumstrukturierte Abstraktion eines bestimmten Merkmals oder Hardwaremerkmale eines Systems. In Netzwerkelementen könnte ein Yang-Modell ein Routing-Protokoll darstellen, interne physische Sensoren und Arrays. Die Sprache und Terminologie von YANG werden auf RFC 6020 beschrieben und auf RFC 7950 aktualisiert. Auf hoher Ebene organisiert ein Yang-Modell die Daten, die die Hauptstruktur darstellen, in Untermodule und Container, die eine Liste von Unterknoten sind, die miteinander in Beziehung stehen. Nachfolgend werden mehrere Knotentypen erläutert.
Ein Endknoten enthält einfache Daten wie eine Ganzzahl oder eine Zeichenfolge. Es hat genau einen Wert eines bestimmten Typs und keine untergeordneten Knoten.
leaf host-name {
type string;
description "Hostname for this system";
}
Eine Endknoten-Liste ist eine Folge von Endknoten mit genau einem Wert eines bestimmten Typs pro Endknoten.
leaf-list domain-search {
type string;
description "List of domain names to search";
}
Ein Containerknoten wird verwendet, um verwandte Knoten in einer Unterstruktur zu gruppieren. Ein Container hat nur untergeordnete Knoten und keinen Wert. Ein Container kann eine beliebige Anzahl von untergeordneten Knoten beliebiger Art enthalten (einschließlich Leafs, Listen, Container und Endblattlisten).
container system {
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
}
}
Eine Liste definiert eine Folge von Listeneinträgen. Jeder Eintrag ist wie eine Struktur oder eine Datensatzinstanz und wird eindeutig durch die Werte der Schlüsselblätter identifiziert. Eine Liste kann mehrere Key-Leafs definieren und eine beliebige Anzahl von untergeordneten Knoten beliebiger Art enthalten (einschließlich Leafs, Listen, Container usw.).
Schließlich sieht ein Beispielmodell, das alle diese Notiztypen zusammenhält, wie im folgenden Beispiel aus:
## Contents of "example-system.yang"
module example-system {
yang-version 1.1;
namespace "urn:example:system";
prefix "sys";
organization "Example Inc.";
contact "joe@example.com";
description "The module for entities implementing the Example system.";
revision 2007-06-09 {
description "Initial revision.";
}
container system {
leaf host-name {
type string;
description "Hostname for this system.";
}
leaf-list domain-search {
type string;
description "List of domain names to search.";
}
container login {
leaf message {
type string;
description "Message given at start of login session.";
}
list user {
key "name";
leaf name {
type string;
}
leaf full-name {
type string;
}
leaf class {
type string;
}
}
}
}
}Die auf Yang Models verwendete Yang-Sprache gibt jedoch nicht an, wie die Daten in Containern/Listen/Blättern organisiert sind. Aus diesem Grund kann eine bestimmte Funktion auf einem Netzwerkelement mit verschiedenen Yang-Modellen dargestellt werden. Diese Herausforderung wurde mit den folgenden Yang-Modellen angegangen:
OpenConfig-Modelle
OpenConfig-Modelle wurden unter Verwendung einer unabhängigen Anbieterorganisation für das Modell entwickelt, das eine bestimmte Funktion darstellt. Der Vorteil dieses Ansatzes besteht darin, dass ein NMS diese Modelle für die Interaktion mit Netzwerkelementen in Umgebungen mit mehreren Anbietern oder sogar mit Umgebungen mit mehreren Plattformen verwenden kann.
Wie der Name schon sagt, sind diese Modelle offen und öffentlich zugänglich für die Inspektion auf Repositories wie github auf diesem Link:
https://github.com/openconfig/public/tree/master/release/models
Als Beispiel können Sie ein openconfig-Modell für Border Gateway Protocol (BGP), ein anderes für Link Aggregation Control Protocol (LACP) und ein anderes für ISIS mit verschiedenen spezifischen Modellen finden. Im Fall von BGP können Sie ein Modell für BGP-Fehler finden, ein weiteres für BGP-Richtlinien usw. Die Modelle könnten miteinander verbunden sein, und einige Modelle können ein anderes Yang-Paket nennen. Zum Beispiel gehört openconfig-bgp-neighbor.yang zu openconfig-bgp.yang:
module openconfig-bgp {
yang-version "1";
## namespace
namespace "http://openconfig.net/yang/bgp";
prefix "oc-bgp";
## import some basic inet types
import openconfig-extensions { prefix oc-ext; }
import openconfig-rib-bgp { prefix oc-bgprib; }
## Include the OpenConfig BGP submodules
## Common: defines the groupings that are common across more than
## one context (where contexts are neighbor, group, global)
include openconfig-bgp-common;
## Multiprotocol: defines the groupings that are common across more
## than one context, and relate to Multiprotocol
include openconfig-bgp-common-multiprotocol;
## Structure: defines groupings that are shared but are solely used for
## structural reasons.
include openconfig-bgp-common-structure;
## Include peer-group/neighbor/global - these define the groupings
## that are specific to one context
include openconfig-bgp-peer-group;
include openconfig-bgp-neighbor;
include openconfig-bgp-global;
Zusammenfassend lässt sich sagen, dass OpenConfig-Modelle auf Protokolle ausgerichtet sind, die allen Plattformen gemeinsam sind, wie IETF- oder RFC-standardisierte Funktionen.
Native Modelle
Im Gegensatz dazu sind Native-Modelle herstellerorientierte Modelle, die tiefgehende, auf eine bestimmte Plattform bezogene Strukturen abdecken. Modelle, die Sensoren von physischen Werten innerhalb eines Netzwerkelements gruppieren, z. B. Spannungen, Temperaturen, ASIC-Zähler, Fabric-Zähler usw. Da sie von der Plattform abhängig sind, werden häufig Modelle mit speziellen Merkmalen für NCS6K, ASR9K oder Cisco 8000 verwendet.
Als OpenConfig-Modelle sind die nativen Modelle auch im Github-Repository verfügbar:
https://github.com/YangModels/yang/tree/master/vendor/cisco/xr
Da diese Modelle tendenziell sehr viel spezifischer und umfassender sind als OpenConfig-Modelle, sind sie an bestimmte Softwareversionen gebunden und können sich je nach Softwareversion ändern.
Es gibt zwei Hauptkategorien für Native Models:
- "Oper"-Modelle zum Abrufen von Informationen aus einem Element.
Beispiel: Cisco-IOS-XR-eigrp-oper.yang
- "Cfg"-Modelle zur Konfiguration eines Netzwerkelements
Beispiel: Cisco-IOS-XR-eigrp-cfg.yang
Im Allgemeinen verwendet die modellgestützte Telemetrie "Operationsmodelle" zum Streamen von Daten aus der Infrastruktur, und NMS wie der NSO verwendet "cfg"-Modelle, um Konfigurationsänderungen an Netzwerkelementen vorzunehmen.
Native und OpenConfig Yang Modelle sind auf XR-Software auf /pkg/yang Ordner vorhanden und können aufgelistet werden, um herauszufinden, ob ein Yang Modell auf einer Plattform verfügbar ist. In diesem Beispiel wird für XRrv9k mit cXR 6.4.2 Folgendes ausgeführt:
RP/0/RP0/CPU0:xrv9k1#run ls /pkg/yang | grep isis
Tue Sep 22 14:21:27.471 CLST
Cisco-IOS-XR-clns-isis-cfg.yang
Cisco-IOS-XR-clns-isis-datatypes.yang
Cisco-IOS-XR-clns-isis-oper-sub1.yang
Cisco-IOS-XR-clns-isis-oper-sub2.yang
Cisco-IOS-XR-clns-isis-oper-sub3.yang
Cisco-IOS-XR-clns-isis-oper.yang
Cisco-IOS-XR-isis-act.yang
openconfig-isis-lsdb-types.yang
openconfig-isis-lsp.yang
openconfig-isis-policy.yang
openconfig-isis-routing.yang
openconfig-isis-types.yang
openconfig-isis.yang
RP/0/RP0/CPU0:xrv9k1#
Telemetrie
Telemetrie ist ein Prozess, mit dem Informationen von verschiedenen Remote-Elementen an einem zentralen Ort gesammelt werden können, um Transparenz und Analysefunktionen zu aggregieren.
In Netzwerkumgebungen könnten die Daten von jedem Element im Netzwerk, von Routern und Switches zwischen anderen erzeugt werden, und die Informationen könnten sich auf eine sehr große Anzahl spezifischer Protokolle, Leistungsindikatoren oder Messgrößen von physischen Sensoren beziehen.
Im Allgemeinen befinden sich die Transparenz- und Analysefunktionen an zentralen Punkten in Netzwerken. Das Streaming der Telemetrieinformationen erfolgt über Netzwerktransportmechanismen, sodass die Telemetrieinformationen schnell und skalierbar sein sollten.
Im Gegensatz zu älteren SNMP-Mechanismen verwendet Telemetrie ein Push-Paradigma, bei dem das Netzwerk bereitgestellt werden sollte, um seine eigenen Daten zu streamen, ohne in regelmäßigen Abständen abgefragt zu werden. Dies ist das Hauptmerkmal der SNMP-basierten Überwachung. Diese Bereitstellung wird häufig als Abonnement bezeichnet und basiert auf einer Reihe zu überwachender Variablen, dem regulären Intervall für das Sampling-Intervall für die Datenerfassung und dem Remote-System, um diese Daten über das Netzwerk zu senden.
Modellbasierte Telemetrie
MDT steht für Model Driven Telemetry und basiert, wie der Name schon sagt, auf Yang Models. Jeder Aspekt der Netzwerkausrüstung kann mit Yang-Modellen dargestellt werden, z. B. mit OSPF Neighbors-Tabelle, RIB oder Temperatursensoren für jede Komponente auf modularen Systemen.
Die MDT-Architektur kann in folgende Ebenen unterteilt werden:
Hinweis: Auf der Erzeugerebene gibt es in der modellgestützten Telemetrie eine Definition des Abtastintervalls, die festlegt, wie oft das Gerät die interne Datenbank auf Rohdaten überprüft und diese Daten in der Datenmodellebene organisiert.
Das Telemetrie-Abonnement definiert außerdem, welche Modelle und mit Containern/Pfaden Daten erzeugen, die in die Analytics Layer übertragen werden sollen. Diese Definition würde sich auf die für Geschäftszwecke relevanten Informationen auswirken. Die MDT-Definition dieses Sensorpfads wäre analog zur Definition der OID, die über SNMP abgerufen werden kann, da beide Methoden strukturierte Daten mit einer definierten Abtastrate erzeugen.
Ereignisgesteuerte Telemetrie
EDT steht für Event Driven Telemetry und basiert auch auf Yang-Modellen für die Struktur. Der Hauptunterschied besteht darin, dass der Auslöser für die Erfassung und den Datenstrom kein reguläres Intervall ist, sondern ein bestimmtes Ereignis, z. B. Schwellenwertüberschreitung, Verbindungsereignisse, Hardwarefehler usw.
Als Nächstes wird ein Vergleich einer Veranstaltung mit Model Driven Telemetry und Event Driven Telemetry vorgestellt:
Tipp: Diese Abbildung zeigt redundante Nachrichten mit MDT, aber nur Nachrichten mit Änderungen mit EDT.
Verkehr
Die Telemetrie sollte so zuverlässig wie möglich sein. Daher ist es sinnvoll, auf TCP (Transmission Control Protocol) basierenden Transport zu verwenden, um sitzungsorientierte Sockets zwischen der Infrastruktur und der Analytics-Ebene zu verwenden, die Collectors für die Sitzung implementieren sollte.
Beim Einsatz der Telemetrie gibt es zwei Hauptansätze, die sich beim anfänglichen Drei-Wege-Handshake unterscheiden.
Hinweis: Im Dial-Out-Modus wird die Sitzung infrastrukturseitig eingerichtet. Dies bedeutet, dass die gewünschten Sensoren für die Netzwerkelemente konfiguriert werden müssen. Im Gegensatz dazu ist beim Einwahlansatz eine einfachere Konfiguration der Netzwerkelemente möglich, da der Collector in der Einrichtungsphase bestimmte Sensorpfade anfordern muss.
TCP
TCP ist der einfachste Weg, eine verbindungsorientierte Sitzung zwischen einem Netzwerkelement und einem Telemetrie-Collector herzustellen. Der Datenstrom beginnt dabei von Router zu Collector, der die ACK aus Gründen der Zuverlässigkeit an den Router zurückgesendet hat:
gRPC
Da Google Protocol RPC (gRPC) über Hypertext Transfer Protocol/2 (HTTP/2) funktioniert, sollte sich die Sitzung selbst bei der Einrichtung bilden und ermöglicht eine Geschwindigkeitssteuerung von der Collector-Seite aus:
gNMI/gNOI
gRPC Network Management Interface (gNMI) ist ein von Google entwickeltes gRPC-Netzwerkverwaltungsprotokoll. gNMI bietet den Mechanismus zum Installieren, Bearbeiten und Löschen der Konfiguration von Netzwerkgeräten sowie zum Anzeigen von Betriebsdaten. Die über gNMI bereitgestellten Inhalte können mit YANG modelliert werden.
gNMI verwendet gRPC-HTTP/2, um eine Verbindung herzustellen, und stellt einen bidirektionalen Kanal zwischen Netzwerkelementen und einem NMS bereit, der auch ein Telemetriesammler sein kann, aber auch eine Schnittstelle zur Verwaltung der Geräte bereitstellt.
Zwischen den von diesem Protokoll unterstützten Operationen finden wir gNMI Get, gNMI Set, die die angeforderten Informationen, Erfolgs- oder Fehlermeldungen zurückgeben.
gRPC Network Operations Interface (gNOI) ist eine Sammlung von Mikrodiensten, die denselben Kommunikationskanal wie gNMI nutzen, aber generische Operationen ermöglichen, die nicht mit der Konfiguration selbst zusammenhängen, wie Ping, Neustart, Ändern von SSL-Zertifikaten, Löschen usw.
Kodierung
Yang-Modelle definieren die Struktur der Daten, ihre Hierarchie und den Typ jedes Blattknotens darauf. Die Modellierung gibt jedoch nicht an, wie diese Daten serialisiert werden sollen. Dieser Prozess regelt die Konvertierung von strukturierten Daten in einen Bytestrom, der über die TCP-Verbindung gesendet werden soll (Raw TCP, gRPC, gNMI usw.).
Hinweis: Dieser Prozess sollte mit einem entsprechenden Mechanismus im Netzwerkelement implementiert werden, der die Daten codieren sollte, und der Collector sollte diese Daten decodieren.
JSON
Der erste Kodierungsmechanismus ist das native JavaScript Object Notation (JSON)-Format, das zwar allgemein bekannt ist, aber menschlich orientiert ist, da jeder Schlüssel als String dargestellt wird, was hinsichtlich der Nachrichtengröße ineffizient ist. Der Hauptvorteil von JSON ist, dass es einfach zu analysieren ist, und wie es im nächsten Beispiel textbasiert ist:
{
“node_id_str":"test-IOSXR ",
"subscription_id_str":" if_rate",
"encoding_path":"Cisco-IOS-XR-infra-statsdoper:infra-statistics/interfaces/interface/latest/datarate", "collection_id":49,
"collection_start_time":1510716302467,
"msg_timestamp":1510716302479,
"data_json":
[
{
"timestamp":1510716282334,
"keys":{
"interface-name":"Null0”
},
"content":{
"input-data-rate":0,
"input-packet-rate":0,
"output-data-rate":0,
"output-packet-rate":0,
<>
{
"timestamp": 1510716282344,
"keys":{
"interface-name":"GigabitEthernet0/0/0/0”
},
"content":{
"input-data-rate":8,
"input-packet-rate":1,
"output-data-rate":2,
"output-packet-rate":0,
<>
"collection_end_time":1510716302372
}
GPB-KV
Google Protocol Buffers-Key Value (GPB-KV) Encoding-Format es wird auch als selbstbeschreibende GPB, weil es nutzt Protokoll-Puffer, um die Nutzung von Nachrichten, die auf bestimmte Elemente auf Yang-Modelle. Dies impliziert, dass nur eine .proto-Datei zum Codieren/Decodieren benötigt wird, und die Schlüssel selbst aus den Daten sind in selbst beschriebenen Strings.
node_id_str: “test-IOSXR"
subscription_id_str: ”if_rate"
encoding_path: "Cisco-IOS-XR-infra-statsd-oper:infrastatistics/interfaces/interface/latest/data-rate"
collection_id: 3
collection_start_time: 1485793813366
msg_timestamp: 1485793813366
data_gpbkv {
timestamp: 1485793813374
fields {
name: "keys"
fields {
name: "interface-name" string_value: "Null0"
}
}
fields {
name: "content"
fields { name: "input-data-rate" 8: 0 }
fields { name: "input-packet-rate" 8: 0 }
fields { name: "output-data-rate" 8: 0 }
fields { name: "output-packet-rate" 8: 0 }
<>
data_gpbkv {
timestamp: 1485793813389
fields {
name: "keys"
fields { name: "interface-name" string_value: "GigabitEthernet0/0/0/0" }
}
fields {
name: "content"
fields { name: "input-data-rate" 8: 8 }
fields { name: "input-packet-rate" 8: 1 }
fields { name: "output-data-rate" 8: 2 }
fields { name: "output-packet-rate" 8: 0 }
<>
}
...
collection_end_time: 1485793813405
GPB
Schließlich Google Protocol Buffers (GPB), auch als kompakte GPB bezeichnet, geht diesen Ansatz einen Schritt weiter und erfordert .proto-Dateien, um jeden Schlüssel der Struktur abzubilden, wodurch es viel effizienter in Bezug auf die Nachrichtengröße, da alles als Binärwerte gesendet wird. Der Nachteil ist jedoch die Notwendigkeit, jede .proto-Datei zu kompilieren, die jedem Yang-Modell zugeordnet ist, das von Infrastructure/Collector unterstützt wird.
node_id_str: ”test-IOSXR"
subscription_id_str: ”if_rate"
encoding_path: "Cisco-IOS-XR-infra-statsdoper:infrastatistics/interfaces/interface/latest/data-rate"
collection_id: 5
collection_start_time: 1485794640452
msg_timestamp: 1485794640452
data_gpb {
row {
timestamp: 1485794640459
keys: "\n\005Null0"
content: "\220\003\000\230\003\000\240\003\000\250\0 03\000\260\003\000\270\003\000\300\003\000\ 310\003\000\320\003\000\330\003\t\340\003\00 0\350\003\000\360\003\377\001"
}
row {
timestamp: 1485794640469
keys: "\n\026GigabitEthernet0/0/0/0"
content: "\220\003\010\230\003\001\240\003\002\250\0 03\000\260\003\000\270\003\000\300\003\000\ 310\003\000\320\003\300\204=\330\003\000\34 0\003\000\350\003\000\360\003\377\001"
}
collection_end_time: 1485794640480
MDT-Konfiguration in IOS XR
Die Kernkomponenten, die für das Streaming modellgestützter Telemetriedaten verwendet werden, sind:
- Sitzung
- Sensorpfad
- Abonnement
- Transport und Kodierung
Bei den Sitzungsoptionen kann es sich um die bereits erläuterten Ein- und Auswähloptionen handeln. Erstellung der Konfiguration in IOS XR
Dial-Out-Modus
Im Dial-Out-Modus startet der Router auf Basis des Abonnements eine Sitzung mit den Zielen. Dabei müssen folgende Schritte ausgeführt werden:
- Zielgruppe erstellen
- Erstellen einer Sensorgruppe
- Abonnement erstellen
- Validierung der DFÜ-Konfiguration
Um eine Zielgruppe zu erstellen, müssen Sie die IPv4- (Internet Protocol Version 4)/IPv6-Adresse (Internet Protocol Version 6) des Collectors und den Port kennen, der diese Anwendung bedienen würde. Außerdem müssen Sie das Protokoll und die Codierung angeben, die auf dem Netzwerkgerät und dem Collector vereinbart werden sollen.
Schließlich müssen Sie möglicherweise das Virtual Routing and Forwarding (VRF) angeben, das für die Kommunikation mit der Collector-Netzwerkadresse verwendet wird.
Als Nächstes wird ein Beispiel für eine Dial-Out-Konfiguration vorgestellt:
telemetry model-driven
destination-group DG1
vrf MGMT
address-family ipv4 192.168.122.20 port 5432
encoding self-describing-gpb
protocol tcp
!
!
Als Nächstes werden die Verschlüsselungsoptionen vorgestellt:
RP/0/RP0/CPU0:C8000-1(config-model-driven-dest-addr)#encoding ?
gpb GPB encoding
json JSON encoding
self-describing-gpb Self describing GPB encoding ← Also known as GPB-KV
RP/0/RP0/CPU0:C8000-1(config-model-driven-dest-addr)#encoding
Die Protokolloptionen:
RP/0/RP0/CPU0:C8000-1(config-model-driven-dest-addr)#protocol ?
grpc gRPC
tcp TCP
udp UDP
RP/0/RP0/CPU0:C8000-1(config-model-driven-dest-addr)#protocol grpc ?
gzip gRPC gzip message compression
no-tls No TLS
tls-hostname TLS hostname
RP/0/RP0/CPU0:C8000-1(config-model-driven-dest-addr)#protocol tcp ?
RP/0/RP0/CPU0:C8000-1(config-model-driven-dest-addr)#protocol udp ?
packetsize UDP packet size
RP/0/RP0/CPU0:C8000-1(config-model-driven-dest-addr)#protocol udp
Das TCP-Protokoll ist einfach und benötigt nur die Port-Einstellungen, die mit der IPv4-/IPv6-Adresse verknüpft sind. User Datagram Protocol (UDP) dagegen ist verbindungslos, sodass der Zielgruppenstatus immer aktiv ist.
Die Komprimierung in gRPC kann durch die Verwendung des optionalen gzip-Schlüsselworts erreicht werden. gRPC verwendet standardmäßig TLS, daher sollte lokal auf dem Router ein Zertifikat für diese Verwendung installiert werden. Dieses Verhalten kann durch die Konfiguration des no-tls-Schlüsselworts überschrieben werden. Schließlich können Sie mit dem Schlüsselwort tls-hostname einen anderen Hostnamen für Zertifikatzwecke angeben.
Als Nächstes sollte ein Abschnitt mit Sensorgruppen hinzugefügt werden, in dem die Sensorpfade von unserem Interesse aufgeführt sind. Dieser Abschnitt ist einfach, aber wichtig zu wissen, dass der Sensorpfad selbst eine Filterung ermöglicht, um mehrere Ressourcen wie die CPU (Central Processing Unit) und die Bandbreite zu optimieren.
telemetry model-driven
sensor-group SG1
sensor-path Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization
sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface[interface-name='Mgmt*']/data-rate
!
!
Hinweis: Für einen Sensorpfad wird folgendes Format benötigt: <Modellname>:<Containerpfad>
Dieses Dokument stellt die Zuordnung von SNMP-basierter Überwachung mithilfe von OID dar, die "Blätter" in diesem Legacy-Ansatz darstellt, zu YANG-Modellen, die mit XPATHs dargestellt werden, die den gleichen "Blättern" entsprechen.
Im letzten Konfigurationsschritt sollte ein Abonnement konfiguriert werden, das die Sensorgruppe mit einem Rhythmus für das Telemetrie-Streaming mit einer Zielgruppe verknüpft.
telemetry model-driven
subscription SU1
sensor-group-id SG1 sample-interval 5000
destination-id DG1
!
!
In diesem Beispiel wird ein Abtastintervall von 5000 Millisekunden (5 Sekunden) verwendet, das relativ zum Ende der vorherigen Auflistung ist. Um dieses Verhalten zu ändern, können Sie das Stichwort sample-interval mit der Option strict-timer ändern.
Zur Überprüfung können Sie den folgenden Befehl verwenden, der den Abonnementstatus abdeckt. Bei dieser Methode können auch Informationen zu Sensorgruppen und Zielgruppen erfasst werden.
RP/0/RP0/CPU0:C8000-1#sh telemetry model-driven subscription SU1
Wed Nov 18 15:38:01.397 UTC
Subscription: SU1
-------------
State: ACTIVE
Sensor groups:
Id: SG1
Sample Interval: 5000 ms
Heartbeat Interval: NA
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface[interface-name='Mgmt*']/data-rate
Sensor Path State: Resolved
Sensor Path: Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization
Sensor Path State: Resolved
Destination Groups:
Group Id: DG1
Destination IP: 192.168.122.10
Destination Port: 5432
Destination Vrf: MGMT(0x60000001)
Encoding: self-describing-gpb
Transport: tcp
State: Active
TLS : False
Total bytes sent: 636284346
Total packets sent: 4189
Last Sent time: 2020-11-18 15:37:58.1700077650 +0000
Collection Groups:
------------------
Id: 9
Sample Interval: 5000 ms
Heartbeat Interval: NA
Heartbeat always: False
Encoding: self-describing-gpb
Num of collection: 1407
Collection time: Min: 4 ms Max: 13 ms
Total time: Min: 8 ms Avg: 10 ms Max: 20 ms
Total Deferred: 0
Total Send Errors: 0
Total Send Drops: 0
Total Other Errors: 0
No data Instances: 1407
Last Collection Start:2020-11-18 15:37:57.1699545994 +0000
Last Collection End: 2020-11-18 15:37:57.1699555589 +0000
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate
Id: 10
Sample Interval: 5000 ms
Heartbeat Interval: NA
Heartbeat always: False
Encoding: self-describing-gpb
Num of collection: 1391
Collection time: Min: 178 ms Max: 473 ms
Total time: Min: 247 ms Avg: 283 ms Max: 559 ms
Total Deferred: 0
Total Send Errors: 0
Total Send Drops: 0
Total Other Errors: 0
No data Instances: 0
Last Collection Start:2020-11-18 15:37:58.1699805906 +0000
Last Collection End: 2020-11-18 15:37:58.1700078415 +0000
Sensor Path: Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization
RP/0/RP0/CPU0:C8000-1#
Einwahlmodus
Im Einwahlmodus initiiert der Collector die Verbindung zu den Netzwerkelementen. Anschließend sollte der Collector das Interesse an der Erstellung eines Abonnements angeben.
Für die Konfiguration sind folgende Schritte erforderlich:
- gRPC-Dienst aktivieren
- Sensorgruppen einrichten
- Verifizierung
Um den gRPC-Dienst zu aktivieren, wird die Konfiguration als Nächstes angezeigt:
!
grpc
vrf MGMT
port 57400
no-tls
address-family dual
!
Die Optionen sind einfach, einschließlich VRF und TCP-Port. gRPC verwendet standardmäßig TLS, kann jedoch mit dem Schlüsselwort no-tls deaktiviert werden. Schließlich ermöglicht die doppelte Option address-family Verbindungen unter Verwendung von IPv4 und IPv6.
Als Nächstes erfordert die Einwahl die lokale Definition von Sensorgruppen, die vom Collector zu einem späteren Zeitpunkt zum Definieren eines Abonnements verwendet werden.
telemetry model-driven
sensor-group SG3
sensor-path Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization
sensor-path Cisco-IOS-XR-fib-common-oper:fib-statistics/nodes/node/drops
!
!
Zu diesem Zeitpunkt ist die Konfiguration für den Einwahlmodus abgeschlossen, und der Collector kann mithilfe von gRPC ein Abonnement für den Router erstellen. Zur Verifizierung können Sie den gleichen Ansatz wie im Wählmodus verwenden:
RP/0/RP0/CPU0:C8000-1#sh telemetry model-driven subscription anx-1605878175837
Fri Nov 20 13:58:37.894 UTC
Subscription: anx-1605878175837
-------------
State: ACTIVE
Sensor groups:
Id: SG3
Sample Interval: 15000 ms
Heartbeat Interval: NA
Sensor Path: Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization
Sensor Path State: Resolved
Sensor Path: Cisco-IOS-XR-fib-common-oper:fib-statistics/nodes/node/drops
Sensor Path State: Resolved
Destination Groups:
Group Id: DialIn_1003
Destination IP: 192.168.122.10
Destination Port: 46974
Compression: gzip
Encoding: json
Transport: dialin
State: Active
TLS : False
Total bytes sent: 71000035
Total packets sent: 509
Last Sent time: 2020-11-20 13:58:32.1030932699 +0000
Collection Groups:
------------------
Id: 5
Sample Interval: 15000 ms
Heartbeat Interval: NA
Heartbeat always: False
Encoding: json
Num of collection: 170
Collection time: Min: 273 ms Max: 640 ms
Total time: Min: 276 ms Avg: 390 ms Max: 643 ms
Total Deferred: 0
Total Send Errors: 0
Total Send Drops: 0
Total Other Errors: 0
No data Instances: 0
Last Collection Start:2020-11-20 13:58:32.1030283276 +0000
Last Collection End: 2020-11-20 13:58:32.1030910008 +0000
Sensor Path: Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization
Id: 6
Sample Interval: 15000 ms
Heartbeat Interval: NA
Heartbeat always: False
Encoding: json
Num of collection: 169
Collection time: Min: 15 ms Max: 33 ms
Total time: Min: 17 ms Avg: 22 ms Max: 33 ms
Total Deferred: 0
Total Send Errors: 0
Total Send Drops: 0
Total Other Errors: 0
No data Instances: 0
Last Collection Start:2020-11-20 13:58:32.1030910330 +0000
Last Collection End: 2020-11-20 13:58:32.1030932787 +0000
Sensor Path: Cisco-IOS-XR-fib-common-oper:fib-statistics/nodes/node/drops
RP/0/RP0/CPU0:C8000-1#
Tipp: Beachten Sie, dass für den Einwahlmodus keine Rhythmus-, Kodierungs-, Collector-IP- oder Transportcodes auf dem Router hardcodiert sind.
SNMP-Migration zu MDT
Für die Migration vom herkömmlichen SNMP zum Telemetriemodell sollten die folgenden Aspekte berücksichtigt werden:
- MIB-Migration in XPATH
- Trap-Migration in Telemetrie
- Sicherheitsüberlegungen
MIB-Migration in XPATH
Zu diesem Zweck können wir MIB anhand einer eigenen Hierarchie kategorisieren, die (zumindest auf hoher Ebene) einer bestimmten Funktionalität zugeordnet werden kann.
BGP4-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen für BGP-Peering-Sitzungen eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| bgpPeerLetzterFehler |
1.3.6.1.2.1.15.3.1.14 |
Der letzte Fehlercode und Untercode, den dieser Peer auf dieser Verbindung gesehen hat. Wenn kein Fehler aufgetreten ist, ist dieses Feld 0. Andernfalls enthält das erste Byte dieses zwei Bytes OCTET STRING den Fehlercode und das zweite Byte den Subcode. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/neighbor-missing-eor-table/neighbor/last-notify-error-code |
| bgpPeerOutUpdates |
1.3.6.1.2.1.15.3.1.11 |
Die Anzahl der über diese Verbindung übertragenen BGP UPDATE-Nachrichten |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/update-messages-out |
| bgpPeerInUpdates |
1.3.6.1.2.1.15.3.1.10 |
Die Anzahl der über diese Verbindung empfangenen BGP UPDATE-Nachrichten |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/update-messages-in |
| bgpPeerNegotiatedVersion |
1.3.6.1.2.1.15.3.1.4 |
Die ausgehandelte BGP-Version, die zwischen den beiden Peers ausgeführt wird. Dieser Eintrag MUSS null (0) sein, es sei denn, der bgpPeerState befindet sich im Zustand "openconfirm" oder "established". Beachten Sie, dass die zulässigen Werte für dieses Objekt zwischen 0 und 255 liegen. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/negotiation-protocol-version |
| BGPeererzustand |
1.3.6.1.2.1.15.3.1.2 |
Der BGP-Peer-Verbindungsstatus. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-state |
| bgpPeerEntfernteAdresse |
1.3.6.1.2.1.15.3.1.7 |
Die Remote-IP-Adresse des BGP-Peers dieses Eintrags. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-remote-address |
| bgpPeerLokaleAdresse |
1.3.6.1.2.1.15.3.1.5 |
Die lokale IP-Adresse der BGP-Verbindung dieses Eintrags. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-local-address |
| bgpPeerFsmEtablierteZeit |
1.3.6.1.2.1.15.3.1.16 |
Dieser Zeitgeber gibt an, wie lange (in Sekunden) sich dieser Peer im Status "Etabliert" befand oder wie lange er sich zuletzt im Status "Etabliert" befand. Er wird auf Null gesetzt, wenn ein neuer Peer konfiguriert oder der Router gestartet wird. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-established-time |
| bgpPeerAdmin-Status |
1.3.6.1.2.1.15.3.1.3 |
Der gewünschte Status der BGP-Verbindung. Bei einem Übergang von "stop" zu "start" wird das manuelle BGP-Startereignis generiert. Bei einem Übergang von "start" zu "stop" wird das BGP Manual Stopp Event generiert. Mit diesem Parameter können BGP-Peer-Verbindungen neu gestartet werden. Es sollte vorsichtig vorgegangen werden, um Schreibzugriff auf dieses Objekt ohne angemessene Authentifizierung bereitzustellen. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-admin-status |
CISCO-BGP4-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der für modellbasierte Telemetriesensorgruppen eingerichtet werden soll, die sich auf den BGP-Sitzungsstatus und das ausgetauschte Präfix beziehen.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| cbgpPeer2RemoteAs |
1.3.6.1.4.1.9.9.187.1.2.5.1.11 |
Die Remote-Autonome-Systemnummer, die in der BGP OPEN-Nachricht empfangen wurde. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/sessions/session/remote-as |
| cbgpPeer2Vorheriger Zustand |
1.3.6.1.4.1.9.9.187.1.2.5.1.29 |
Der vorherige Status der BGP-Peer-Verbindung. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/previous-connection-state |
| cbgpPeer2Status |
1.3.6.1.4.1.9.9.187.1.2.5.1.3 |
Der BGP-Peer-Verbindungsstatus. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-state |
| cbgpPeer2Lokale Adresse |
1.3.6.1.4.1.9.9.187.1.2.5.1.6 |
Die lokale IP-Adresse der BGP-Verbindung dieses Eintrags. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-local-address |
| cbgpPeer2AnkündigtePräfixe |
1.3.6.1.4.1.9.9.187.1.2.8.1.6 |
Dieser Zähler wird erhöht, wenn ein Routenpräfix, das zu einer Adressfamilie gehört, für diese Verbindung angekündigt wird. Sie wird auf Null initialisiert, wenn die Verbindung zurückgesetzt wird. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/af-data/prefixes-advertised |
| cbgpPeer2AkzeptiertePräfixe |
1.3.6.1.4.1.9.9.187.1.2.8.1.1 |
Anzahl der akzeptierten Routen-Präfixe für diese Verbindung, die zu einer Adressfamilie gehören. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/af-data/prefixes-accepted |
| cbgpPeerPrefixLimit |
1.3.6.1.4.1.9.9.187.1.2.1.1.3 |
Max. Anzahl von Routenpräfixen, die für diese Verbindung akzeptiert werden |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/af-data/max-prefix-limit |
| cbgpPeer2PrefixThreshold |
1.3.6.1.4.1.9.9.187.1.2.8.1.4 |
Präfix-Schwellenwert (%) für eine Adressfamilie auf dieser Verbindung, bei dem eine Warnmeldung mit der Präfixanzahl den Schwellenwert überschreitet oder eine entsprechende SNMP-Benachrichtigung generiert wird. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/config-instanzen/config-instance/config-instance-default-vrf/entity-configuration/entity-configuration/af-dependent-config/max-prefix-warn-threshold |
CISCO-KLASSENBASIERTE QOS-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der für modellbasierte Telemetriesensorgruppen eingerichtet werden soll, die sich auf Statistiken in QoS-Klassen/-Richtlinien (Quality of Service) beziehen.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| cbQoCMDropBitRate |
1.3.6.1.4.1.9.9.166.1.15.1.1.18 |
Die Bitrate der Drops pro Klasse als Ergebnis aller Features, die Drops erzeugen können (z. B. Polizei, zufällige Erkennung usw.). |
Cisco-IOS-XR-qos-ma-oper:qos/interface-table/interface/input/service-policy-names/service-policy-instance/statistics/class-stats/general-stats/total-drop-rate |
| cbQoCMDropPkt64 |
1.3.6.1.4.1.9.9.166.1.15.1.1.14 |
Der 64-Bit-Zähler verworfener Pakete pro Klasse als Ergebnis aller Funktionen, die Verwerfungen erzeugen können (z. B. Polizei, zufällige Erkennung usw.). |
Cisco-IOS-XR-qos-ma-oper:qos/interface-table/interface/input/service-policy-names/service-policy-instance/statistics/class-stats/general-stats/total-drop-packages |
| cbQoCMPrePolicyPkt64 |
1.3.6.1.4.1.9.9.166.1.15.1.1.3 |
Die Anzahl der eingehenden Pakete beträgt 64 Bit, bevor QoS-Richtlinien ausgeführt werden. |
Cisco-IOS-XR-qos-ma-oper:qos/interface-table/interface/input/service-policy-names/service-policy-instance/statistics/class-stats/general-stats/pre-policy-matching-packages |
| cbQoCMName |
1.3.6.1.4.1.9.9.166.1.7.1.1.1 |
Name der Klassenzuordnung. |
Cisco-IOS-XR-qos-ma-oper:qos/interface-table/interface/input/service-policy-names/service-policy-instance/statistics/class-stats/class-name |
| cbQoCMPostPolicyByte64 |
1.3.6.1.4.1.9.9.166.1.15.1.1.10 |
Die 64-Bit-Anzahl ausgehender Oktetts nach der Ausführung von QoS-Richtlinien. |
Cisco-IOS-XR-qos-ma-oper:qos/interface-table/interface/input/service-policy-names/service-policy-instance/statistics/class-stats/child-policy/class-stats/general-stats/transmission-bytes |
| cbQoIfIndex |
1.3.6.1.4.1.9.9.166.1.1.1.1.4 |
ifIndex für die Schnittstelle, an die dieser Service angeschlossen ist. Dieses Feld ist nur sinnvoll, wenn die logische Schnittstelle über einen snmp ifIndex verfügt. Beispielsweise ist der Wert dieses Felds bedeutungslos, wenn cbQosIfType den Wert controlPlane hat. |
Cisco-IOS-XR-infra-policymgr-oper:policy-manager/global/policy-map/policy-map-types/policy-map-type/policy-maps |
| cbQoConfigIndex |
1.3.6.1.4.1.9.9.166.1.5.1.1.2 |
Ein beliebiger (vom System zugewiesener) (instanzunabhängiger) Index für jedes Object. Alle Objekte mit derselben Konfiguration verwenden denselben Konfigurationsindex. |
Cisco-IOS-XR-infra-policymgr-oper:policy-manager/global/policy-map/policy-map-types/policy-map-type/policy-maps |
| cbQoCMPerichtlinieByte64 |
1.3.6.1.4.1.9.9.166.1.15.1.1.6 |
Die 64-Bit-Anzahl eingehender Oktetts vor der Ausführung von QoS-Richtlinien. |
Cisco-IOS-XR-qos-ma-oper:qos/interface-table/interface/input/service-policy-names/service-policy-instance/statistics/class-stats/child-policy/class-stats/general-stats/pre-policy-matching-bytes |
CISCO-ENHANCED-MEMPOOL-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen für die Speichernutzung eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| cempMemPoolVerwendet |
1.3.6.1.4.1.9.9.221.1.1.1.1.7 |
Gibt die Anzahl der Bytes aus dem Speicherpool an, die derzeit von Anwendungen auf der physischen Einheit verwendet werden. |
Cisco-IOS-XR-nto-misc-oper:Zusammenfassung des Arbeitsspeichers/Knoten/Knoten/Zusammenfassung |
| cempMemPoolHCUsed |
1.3.6.1.4.1.9.9.221.1.1.1.1.18 |
Gibt die Anzahl der Bytes aus dem Speicherpool an, die derzeit von Anwendungen auf der physischen Einheit verwendet werden. Dieses Objekt ist eine 64-Bit-Version von cempMemPoolUsed. |
Cisco-IOS-XR-nto-misc-oper:Arbeitsspeicherzusammenfassung/Knoten/Knoten/Details/gesamt |
| cempMemPoolHCFree |
1.3.6.1.4.1.9.9.221.1.1.1.1.20 |
Gibt die Anzahl der Bytes aus dem Speicherpool an, die derzeit für die physische Einheit nicht verwendet werden. Dieses Objekt ist eine 64-Bit-Version von cempMemPoolFree. |
Cisco-IOS-XR-nto-misc-oper:Zusammenfassung des Arbeitsspeichers/Knoten/Details/freier physischer Speicher |
CISCO-ENTITY-FRU-CONTROL-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen eingerichtet werden soll, die sich auf die vor Ort austauschbaren Einheiten des überwachten Systems beziehen.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| cefcFRUPowerOperStatus |
1.3.6.1.4.1.9.9.117.1.1.2.1.2 |
Betriebsbereiter FRU-Stromversorgungszustand. |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/fru-info/power-operating-state |
| cefcFRUPowerAdminStatus |
1.3.6.1.4.1.9.9.117.1.1.2.1.1 |
Verwaltungstechnisch gewünschter FRU-Leistungszustand. |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/fru-info/power-administrationsstatus |
| cefcModulStatusLetzteÄnderungszeit |
1.3.6.1.4.1.9.9.117.1.2.1.1.4 |
Der Wert von sysUpTime zum Zeitpunkt der Änderung von cefcModuleOperStatus. |
Cisco-IOS-XR-invmgr-oper:inventar/entity/attribute/fru-info/last-Operational-State-Change |
| cefcModulBetriebszeit |
1.3.6.1.4.1.9.9.117.1.2.1.1.8 |
Dieses Objekt gibt die Betriebszeit für das Modul seit der letzten Neuinitialisierung an. Dieses Objekt ist nicht persistent. Wenn ein Modul zurückgesetzt, neu gestartet oder ausgeschaltet wird, beginnt die Betriebszeit bei Null. |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/fru-info/card-up-time |
| cefcModuleZurücksetzenGrund |
1.3.6.1.4.1.9.9.117.1.2.1.1.3 |
Dieses Objekt identifiziert den Grund für das letzte Zurücksetzen, das auf dem Modul durchgeführt wurde. |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/fru-info/card-reset-reason |
| cefcModuleOperStatus |
1.3.6.1.4.1.9.9.117.1.2.1.1.2 |
Dieses Objekt zeigt den Betriebsstatus des Moduls an. |
Cisco-IOS-XR-invmgr-oper:Inventory/entity/entity/attribute/fru-info/card-Operational-State |
| cefcModulAdminStatus |
1.3.6.1.4.1.9.9.117.1.2.1.1.1 |
Dieses Objekt ermöglicht die administrative Steuerung des Moduls. |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/fru-info/card-administrativstatus |
CISCO-ENTITY-SENSOR-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen eingerichtet werden soll, die mit den Sensorentitäten auf dem Knoten verknüpft sind.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| entSensorWert |
1.3.6.1.4.1.9.9.91.1.1.1.1.4 |
Diese Variable gibt die letzte Messung an, die vom Sensor beobachtet wurde. Um den Wert dieser Variablen richtig anzuzeigen oder zu interpretieren, müssen Sie auch entSensorType, entSensorScale und entSensorPrecision kennen. Sie können entSensorValue jedoch ohne semantisches Wissen mit den in entSensorThresholdTable angegebenen Schwellenwerten vergleichen. |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/env-sensor-info/value |
| entSensorThresholdAuswertung |
1.3.6.1.4.1.9.9.91.1.2.1.1.5 |
Diese Variable gibt das Ergebnis der letzten Auswertung des Schwellenwerts an. Wenn die Bedingung true ist, ist entSensorThresholdEvaluation true(1). Wenn die Bedingung false ist, ist entSensorThresholdEvaluation false(2). Schwellenwerte werden mit der durch entSensorValueUpdateRate angegebenen Rate ausgewertet. |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/threshold |
CISCO-FLASH-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen für Flash-Speicher im System eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| ciscoFlashPartitionsname |
1.3.6.1.4.1.9.9.10.1.1.4.1.1.10 |
Der Name der Flash-Partition, der verwendet wird, um vom System auf eine Partition zu verweisen. Dabei kann es sich um eine beliebige alphanumerische Zeichenfolge der Form AAAAAAAAAAnn handeln, wobei A für ein optionales Alphamerkmal und n für ein numerisches Zeichen steht. Alle numerischen Zeichen müssen immer den nachgestellten Teil der Zeichenfolge bilden. Das System entfernt die alphanumerischen Zeichen und verwendet den numerischen Teil für die Zuordnung zu einem Partitionsindex. Flash-Vorgänge werden basierend auf diesem Namen an eine Gerätepartition weitergeleitet. Das System hat das Konzept einer Standardpartition. Dies wäre die erste Partition im Gerät. Das System leitet einen Vorgang an die Standardpartition weiter, wenn kein Partitionsname angegeben wird. Der Partitionsname ist daher obligatorisch, außer wenn die Operation auf der Standardpartition durchgeführt wird oder das Gerät nur eine Partition hat (nicht partitioniert ist). |
Cisco-IOS-XR-shellutil-filesystem-oper:Dateisystem/Knoten/Dateisystem/Typ |
| ciscoFlashPartitionSizeExtended |
1.3.6.1.4.1.9.9.10.1.1.4.1.1.13 |
Größe der Flash-Partition. Es sollte ein ganzzahliges Vielfaches von ciscoFlashDeviceMinPartitionSize sein. Wenn es eine einzelne Partition gibt, entspricht diese Größe ciscoFlashDeviceSize. Dieses Objekt ist eine 64-Bit-Version von ciscoFlashPartitionSize |
Cisco-IOS-XR-shellutil-filesystem-oper:Dateisystem/Knoten/Dateisystem/Größe |
| ciscoFlashPartitionFreeSpaceErweitert |
1.3.6.1.4.1.9.9.10.1.1.4.1.1.14 |
Freier Speicherplatz innerhalb einer Flash-Partition. Beachten Sie, dass die tatsächliche Größe einer Datei in Flash einen kleinen Overhead enthält, der den Dateikopf des Dateisystems darstellt. Bestimmte Dateisysteme können auch einen Partitions- oder Geräte-Header-Overhead haben, der bei der Berechnung des freien Speicherplatzes berücksichtigt werden muss. Der freie Speicherplatz wird berechnet als die gesamte Partitionsgröße abzüglich der Größe aller vorhandenen Dateien (gültige/ungültige/gelöschte Dateien und einschließlich Dateiheader jeder Datei), abzüglich der Größe eines Partitionsheaders, abzüglich der Größe des Headers der nächsten zu kopierenden Datei. Kurz gesagt, dieses Objekt gibt die Größe der größten Datei an, in die kopiert werden kann. Von der Verwaltungseinheit wird nicht erwartet, dass sie Overheads wie die Länge von Datei- und Partitionsheadern kennt oder verwendet, da diese Overheads von Dateisystem zu Dateisystem variieren können. Gelöschte Dateien in Flash geben keinen Speicherplatz frei. Eine Partition muss möglicherweise gelöscht werden, um den von Dateien belegten Speicherplatz freizugeben. Dieses Objekt ist eine 64-Bit-Version von ciscoFlashPartitionFreeSpace. |
Cisco-IOS-XR-shellutil-filesystem-oper:Dateisystem/Knoten/Dateisystem/frei |
CISCO-PROZESS-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen für die CPU-Auslastung und die Ressourcenzuordnung für Prozesse eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| cpmCPUTotal1minRev |
1.3.6.1.4.1.9.9.109.1.1.1.1.7 |
Der prozentuale Gesamtanteil der CPU-Auslastung in der letzten Minute Dieses Objekt verwirft das Objekt cpmCPUTotal1min und erhöht den Wertebereich auf (0..100). |
Cisco-IOS-XR-wdsysmon-fd-oper:Systemüberwachung/CPU-Auslastung/gesamt-cpu-one-minute |
| cpmCPUTotal5minRev |
1.3.6.1.4.1.9.9.109.1.1.1.1.8 |
Der prozentuale Gesamtanteil der CPU-Auslastung in den letzten fünf Minuten. Dieses Objekt verwirft das Objekt cpmCPUTotal5min und erhöht den Wertebereich auf (0..100). |
Cisco-IOS-XR-wdsysmon-fd-oper:Systemüberwachung/CPU-Auslastung/total-cpu-five-minute |
| cpmCPUTotal15minRev |
1.3.6.1.4.1.9.9.109.1.1.1.1.31 |
Der prozentuale Gesamtanteil der CPU-Auslastung in den letzten 15 Minuten Dieses Objekt verwirft das Objekt cpmCPUTotal15min und erhöht den Wertebereich auf (0..100). |
Cisco-IOS-XR-wdsysmon-fd-oper:Systemüberwachung/CPU-Auslastung/total-cpu-fifteen-minute |
| cpmProzessname |
1.3.6.1.4.1.9.9.109.1.2.1.1.2 |
Der diesem Prozess zugeordnete Name. Wenn der Name länger als 32 Zeichen ist, wird er auf die ersten 31 Zeichen gekürzt, und ein '*' wird als letztes Zeichen angefügt, um anzudeuten, dass es sich um einen gekürzten Prozessnamen handelt. |
Cisco-IOS-XR-wdsysmon-fd-oper:Systemüberwachung/CPU-Auslastung/Prozess-CPU/Prozessname |
| cpmProzessTextSegmentGröße |
1.3.6.1.4.1.9.9.109.1.2.3.1.15 |
Dies gibt den Textspeicher eines Prozesses und alle zugehörigen gemeinsam genutzten Objekte an. |
Cisco-IOS-XR-procmem-oper:processes-memory/nodes/node/process-ids/process-id/text-seg-size |
| cpmProzessDynamischeSpeichergröße |
1.3.6.1.4.1.9.9.109.1.2.3.1.18 |
Dies gibt die Menge an dynamischem Speicher an, die vom Prozess verwendet wird. |
Cisco-IOS-XR-procmem-oper:processes-memory/nodes/node/process-ids/process-id/dyn-limit |
| cpmProcessDataSegmentSize |
1.3.6.1.4.1.9.9.109.1.2.3.1.16 |
Dies gibt das Datensegment eines Prozesses und alle zugehörigen freigegebenen Objekte an. |
Cisco-IOS-XR-procmem-oper:processes-memory/nodes/node/process-ids/process-id/data-seg-size |
| cpmProcExtMemZugewieseneRev |
1.3.6.1.4.1.9.9.109.1.2.3.1.1 |
Die Summe aller dynamisch zugewiesenen Speicher, die dieser Prozess vom System erhalten hat. Dies schließt auch Speicher ein, der möglicherweise zurückgegeben wurde. Die Summe des freigegebenen Speichers wird von cpmProcExtMemFreedRev bereitgestellt. Dieses Objekt verwirft cpmProcExtMemAllocations. |
Cisco-IOS-XR-procmem-oper:process-memory/nodes/node/process-ids/process-id |
| cpmProcExtMemFreedRev |
1.3.6.1.4.1.9.9.109.1.2.3.1.2 |
Die Summe des gesamten Speichers, der von diesem Prozess an das System zurückgegeben wurde. Dieses Objekt verwirft cpmProcExtMemFreed. |
Cisco-IOS-XR-procmem-oper:process-memory/nodes/node/process-ids/process-id |
ENTITY-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen für physische Einheiten im System eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| entPhysischerName |
1.3.6.1.2.1.47.1.1.1.1.7 |
Der Textname der physischen Entität. Der Wert dieses Objekts sollte der vom lokalen Gerät zugewiesene Name der Komponente sein und für die Verwendung in Befehlen geeignet sein, die an der Gerätekonsole eingegeben werden. Dies kann ein Textname sein, z. B. "console" oder eine einfache Komponentennummer (z. B. Port- oder Modulnummer), z. B. "1", abhängig von der Syntax für die Benennung der physischen Komponente des Geräts. Wenn es keinen lokalen Namen gibt oder dieses Objekt anderweitig nicht anwendbar ist, enthält dieses Objekt eine Zeichenfolge der Länge Null. Beachten Sie, dass der Wert von entPhysicalName für zwei physische Einheiten derselbe sein wird, falls die Konsolenschnittstelle nicht zwischen ihnen unterscheidet, z. B. Steckplatz-1 und die Karte in Steckplatz-1. |
Cisco-IOS-XR-snmp-entitymib-oper:entity-physical-index |
| entLogischeBeschreibung |
1.3.6.1.2.1.47.1.2.1.1.2 |
Eine Textbeschreibung der logischen Einheit. Dieses Objekt sollte eine Zeichenfolge enthalten, die den Herstellernamen für die logische Entität identifiziert, und auf einen eindeutigen Wert für jede Version der logischen Entität festgelegt werden. |
Cisco-IOS-XR-snmp-agent-oper:snmp/information/systemname/ |
| entPhysischeBeschreibung |
1.3.6.1.2.1.47.1.1.1.1.2 |
Eine Textbeschreibung der physischen Einheit. Dieses Objekt sollte eine Zeichenfolge enthalten, die den Herstellernamen für die physische Entität identifiziert, und auf einen eindeutigen Wert für jede Version oder jedes Modell der physischen Entität festgelegt werden. |
Cisco-IOS-XR-snmp-agent-oper:snmp/Cisco-IOS-XR-snmp-entitymib-oper:entity-mib/entity-physical-indexes/ |
| entPhysischEnthaltenIn |
1.3.6.1.2.1.47.1.1.1.1.4 |
Der Wert von entPhysicalIndex für die physische Entität, die diese physische Entität 'enthält'. Ein Wert von Null gibt an, dass diese physische Einheit in keiner anderen physischen Einheit enthalten ist. Beachten Sie, dass der Satz von 'Containment'-Beziehungen eine strenge Hierarchie definiert, d. h., Rekursion ist nicht zulässig. Wenn eine physische Entität in mehr als einer physischen Entität enthalten ist (z. B. Module mit doppelter Breite), sollte dieses Objekt die enthaltende Entität mit dem niedrigsten Wert von entPhysicalIndex identifizieren. |
Cisco-IOS-XR-invmgr-oper:Inventory/entity/entity/attribute/inv-basic-bag/unique-id |
| entPhysicalClass |
1.3.6.1.2.1.47.1.1.1.1.5 |
Angabe des allgemeinen Hardwaretyps der physischen Einheit. Ein Agent sollte dieses Objekt auf den standardmäßigen Enumerationswert festlegen, der die allgemeine Klasse der physischen Entität oder, falls mehrere vorhanden sind, die primäre Klasse am genauesten angibt. Wenn für diese physische Einheit keine geeignete Standard-Registrierungs-ID vorhanden ist, wird der Wert "other(1)" zurückgegeben. Wenn der Wert von diesem Agent unbekannt ist, wird der Wert "unknown(2)" zurückgegeben. |
Cisco-IOS-XR-invmgr-oper:inventar/einheiten |
| entPhysischeHardwareRev |
1.3.6.1.2.1.47.1.1.1.1.8 |
Die anbieterspezifische Hardware-Revisionszeichenfolge für die physische Einheit. Der bevorzugte Wert ist der Hardware-Revisionsbezeichner, der tatsächlich auf die Komponente selbst gedruckt wurde (falls vorhanden). Wenn Revisionsinformationen intern in einem nicht druckbaren (z. B. binären) Format gespeichert werden, muss der Agent diese Informationen implementierungsspezifisch in ein druckbares Format umwandeln. Wenn der physischen Komponente keine spezielle Hardware-Revisionszeichenfolge zugeordnet ist oder diese Information dem Agenten unbekannt ist, enthält dieses Objekt eine Zeichenfolge der Länge 0 (null). |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/inv-basic-bag/hardware-revision |
| entPhysischeFirmwareRev |
1.3.6.1.2.1.47.1.1.1.1.9 |
Die herstellerspezifische Firmware-Revisionszeichenfolge für die physische Einheit. Wenn Revisionsinformationen intern in einem nicht druckbaren (z. B. binären) Format gespeichert werden, muss der Agent diese Informationen implementierungsspezifisch in ein druckbares Format umwandeln. Wenn der physischen Komponente keine spezifischen Firmware-Programme zugeordnet sind oder diese Informationen dem Agenten nicht bekannt sind, enthält dieses Objekt eine Zeichenfolge der Länge Null. |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/inv-basic-bag/firmware-revision |
| entPhysischeSoftwareRev |
1.3.6.1.2.1.47.1.1.1.1.10 |
Die herstellerspezifische Softwarerevisionszeichenfolge für die physische Einheit. Wenn Revisionsinformationen intern in einem nicht druckbaren (z. B. binären) Format gespeichert werden, muss der Agent diese Informationen implementierungsspezifisch in ein druckbares Format umwandeln. Wenn der physischen Komponente keine spezifischen Softwareprogramme zugeordnet sind oder diese Informationen dem Agenten nicht bekannt sind, enthält dieses Objekt eine Zeichenfolge der Länge Null. |
Cisco-IOS-XR-invmgr-oper:Inventory/entity/entity/attribute/inv-basic-bag/software-revision |
| entPhysischeSeriennummer |
1.3.6.1.2.1.47.1.1.1.1.11 |
Die herstellerspezifische Seriennummer-Zeichenfolge für die physische Einheit. Der bevorzugte Wert ist die Seriennummernfolge, die auf der Komponente selbst ausgegeben wird (falls vorhanden). Bei der ersten Instanziierung einer physischen Einheit wird der Wert von entPhysicalSerialNum, der dieser Einheit zugeordnet ist, auf die richtige vom Anbieter zugewiesene Seriennummer festgelegt, wenn diese Informationen dem Agenten zur Verfügung stehen. Wenn eine Seriennummer unbekannt oder nicht vorhanden ist, wird stattdessen "entPhysicalSerialNum" auf eine Zeichenfolge der Länge Null gesetzt. Beachten Sie, dass Implementierungen, die die Seriennummern aller installierten physischen Einheiten korrekt identifizieren können, keinen Schreibzugriff auf das entPhysicalSerialNum-Objekt bereitstellen müssen. Agenten, die keinen nichtflüchtigen Speicher für die entPhysicalSerialNum-Zeichenfolgen bereitstellen können, sind nicht erforderlich, um den Schreibzugriff für dieses Objekt zu implementieren. Nicht jede physische Komponente verfügt über eine Seriennummer oder benötigt eine Seriennummer. Physische Einheiten, deren zugeordneter Wert des entPhysicalIsFRU-Objekts 'false(2)' entspricht (z. B. die Repeater-Ports innerhalb eines Repeater-Moduls), benötigen keine eigene eindeutige Seriennummer. Ein Agent muss keinen Schreibzugriff für diese Entitäten bereitstellen und kann eine Zeichenfolge der Länge 0 zurückgeben. Wenn Schreibzugriff für eine Instanz von entPhysicalSerialNum implementiert ist und ein Wert in die Instanz geschrieben wird, muss der Agent den angegebenen Wert in der entPhysicalSerialNum-Instanz beibehalten, die derselben physischen Entität zugeordnet ist, solange diese Entität instanziiert bleibt. Dies umfasst Instanziierungen für alle Neuinitialisierungen/Neustarts des Netzwerkmanagementsystems, einschließlich solcher, die zu einer Änderung des entPhysicalIndex-Werts der physischen Einheit führen. |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/inv-basic-bag/seriennummer |
| entPhysischerMfgName |
1.3.6.1.2.1.47.1.1.1.1.12 |
Der Name des Herstellers dieser physischen Komponente. Der bevorzugte Wert ist die Herstellername-Zeichenfolge, die tatsächlich auf die Komponente selbst gedruckt wird (falls vorhanden). Beachten Sie, dass Vergleiche zwischen Instanzen des entPhysicalModelName-Objekts, des entPhysicalFirmwareRev-Objekts, des entPhysicalSoftwareRev-Objekts und des entPhysicalSerialNum-Objekts nur bei entPhysicalEntries mit dem gleichen Wert von entPhysicalMfgName sinnvoll sind. Wenn die der physischen Komponente zugeordnete Zeichenfolge des Herstellernamens für den Agenten unbekannt ist, enthält dieses Objekt eine Zeichenfolge der Länge 0 (null). |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/inv-basic-bag/Herstellername |
| entPhysischerModellname |
1.3.6.1.2.1.47.1.1.1.1.13 |
Die herstellerspezifische Modellnamenbezeichner-Zeichenfolge, die dieser physischen Komponente zugeordnet ist. Der bevorzugte Wert ist die vom Kunden sichtbare Teilenummer, die auf das Bauteil selbst aufgedruckt sein kann. Wenn die Modellnamenszeichenfolge, die mit der physischen Komponente verknüpft ist, für den Agenten unbekannt ist, enthält dieses Objekt eine Zeichenfolge der Länge 0 (null). |
Cisco-IOS-XR-invmgr-oper:inventar/entity/entity/attribute/inv-basic-bag/modellname |
IF-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen in Bezug auf Schnittstelleneigenschaften und Zähler eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| ifMtu |
1.3.6.1.2.1.2.2.1.4 |
Die Größe des größten Pakets, das über die Schnittstelle gesendet/empfangen werden kann, angegeben in Oktetten. Bei Schnittstellen, die für die Übertragung von Netzwerkdatagrammen verwendet werden, ist dies die Größe des größten Netzwerkdatagramms, das auf der Schnittstelle gesendet werden kann. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/mtu |
| ifPhysAdresse |
1.3.6.1.2.1.2.2.1.6 |
Die Adresse der Schnittstelle auf der untergeordneten Protokollschicht. Bei einer 802.x-Schnittstelle enthält dieses Objekt normalerweise eine MAC-Adresse. Die medienspezifische MIB der Schnittstelle muss die Bit- und Bytereihenfolge sowie das Format des Werts dieses Objekts definieren. Bei Schnittstellen, die keine solche Adresse haben (z. B. eine serielle Leitung), sollte dieses Objekt eine Oktettzeichenfolge von Null Länge enthalten. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface/interface-type-information/bundle-information/member/mac-address |
| ifType |
1.3.6.1.2.1.2.2.1.3 |
Der Schnittstellentyp. Zusätzliche Werte für ifType werden von der Internet Assigned Numbers Authority (IANA) zugewiesen, indem die Syntax der IANAifType-Textkonvention aktualisiert wird. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-type |
| ifOutUcastPakete |
1.3.6.1.2.1.2.2.1.17 |
Die Gesamtzahl der Pakete, die von übergeordneten Protokollen angefordert wurden und die nicht an eine Multicast- oder Broadcast-Adresse auf dieser Unterebene adressiert waren, einschließlich der Pakete, die verworfen oder nicht gesendet wurden Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/packages-sent |
| ifHCOutUcastPakete |
1.3.6.1.2.1.31.1.1.1.11 |
Die Gesamtzahl der Pakete, die von übergeordneten Protokollen angefordert wurden und die nicht an eine Multicast- oder Broadcast-Adresse auf dieser Unterebene adressiert waren, einschließlich der Pakete, die verworfen oder nicht gesendet wurden Dieses Objekt ist eine 64-Bit-Version von ifOutUcastPkts. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/packages-sent |
| ifInUcastPkts |
1.3.6.1.2.1.2.2.1.11 |
Die Anzahl der Pakete, die von dieser Subschicht an eine höhere (Sub-)Schicht übermittelt wurden und die auf dieser Subschicht nicht an eine Multicast- oder Broadcast-Adresse adressiert waren. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/packages received |
| ifHCInUcastPakete |
1.3.6.1.2.1.31.1.1.1.7 |
Die Anzahl der Pakete, die von dieser Subschicht an eine höhere (Sub-)Schicht übermittelt wurden und die auf dieser Subschicht nicht an eine Multicast- oder Broadcast-Adresse adressiert waren. Dieses Objekt ist eine 64-Bit-Version von ifInUcastPkts. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/packages received |
| ifOutErrors |
1.3.6.1.2.1.2.2.1.20 |
Bei paketorientierten Schnittstellen die Anzahl ausgehender Pakete, die aufgrund von Fehlern nicht übertragen werden konnten. Bei zeichenorientierten oder Schnittstellen mit fester Länge die Anzahl der ausgehenden Übertragungseinheiten, die aufgrund von Fehlern nicht übertragen werden konnten. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/output-errors |
| ifOutDiscards |
1.3.6.1.2.1.2.2.1.19 |
Die Anzahl der ausgehenden Pakete, die verworfen werden sollten, obwohl keine Fehler erkannt wurden, die ihre Übertragung verhindern. Ein möglicher Grund für das Verwerfen eines solchen Pakets könnte darin bestehen, Pufferspeicher freizugeben. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/output-drops |
| ifOutMulticastPakete |
1.3.6.1.2.1.31.1.1.1.4 |
Die Gesamtzahl der Pakete, die von übergeordneten Protokollen angefordert wurden und die an eine Multicast-Adresse auf dieser Unterebene adressiert wurden, einschließlich der Pakete, die verworfen oder nicht gesendet wurden Für ein MAC-Schicht-Protokoll umfasst dies sowohl Gruppen- als auch Funktionsadressen. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/multicast-packages-sent |
| ifHCOutMulticastPakete |
1.3.6.1.2.1.31.1.1.1.12 |
Die Gesamtzahl der Pakete, die von übergeordneten Protokollen angefordert wurden und die an eine Multicast-Adresse auf dieser Unterebene adressiert wurden, einschließlich der Pakete, die verworfen oder nicht gesendet wurden Für ein MAC-Schicht-Protokoll umfasst dies sowohl Gruppen- als auch Funktionsadressen. Dieses Objekt ist eine 64-Bit-Version von ifOutMulticastPkts. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/multicast-packages-sent |
| ifInMulticastPakete |
1.3.6.1.2.1.31.1.1.1.2 |
Die Anzahl der Pakete, die von diesem Sublayer an einen höheren (Sub-)Layer übermittelt wurden und die an eine Multicast-Adresse in diesem Sublayer adressiert wurden. Für ein MAC-Schicht-Protokoll umfasst dies sowohl Gruppen- als auch Funktionsadressen. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/multicast-packages-received |
| ifHCInMulticastPakete |
1.3.6.1.2.1.31.1.1.1.8 |
Die Anzahl der Pakete, die von diesem Sublayer an einen höheren (Sub-)Layer übermittelt wurden und die an eine Multicast-Adresse in diesem Sublayer adressiert wurden. Für ein MAC-Schicht-Protokoll umfasst dies sowohl Gruppen- als auch Funktionsadressen. Dieses Objekt ist eine 64-Bit-Version von ifInMulticastPkts. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/multicast-packages-received |
| ifInErrors |
1.3.6.1.2.1.2.2.1.14 |
Bei paketorientierten Schnittstellen die Anzahl eingehender Pakete, die Fehler enthielten und die Übermittlung an ein Protokoll einer höheren Ebene verhinderten. Bei zeichenorientierten Schnittstellen oder Schnittstellen mit fester Länge die Anzahl der eingehenden Übertragungseinheiten, die Fehler enthielten, durch die verhindert wurde, dass sie an ein Protokoll einer höheren Ebene übermittelt werden können. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/input-errors |
| ifInDiscards |
1.3.6.1.2.1.2.2.1.13 |
Die Anzahl der eingehenden Pakete, die verworfen werden sollten, obwohl keine Fehler erkannt wurden, die ihre Zustellung an ein Protokoll einer höheren Schicht verhindern. Ein möglicher Grund für das Verwerfen eines solchen Pakets könnte darin bestehen, Pufferspeicher freizugeben. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/input-drops |
| ifAusOktette |
1.3.6.1.2.1.2.2.1.16 |
Die Gesamtzahl der von der Schnittstelle übertragenen Oktetts, einschließlich Framing-Zeichen Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/bytes-sent |
| ifHCOutOktette |
1.3.6.1.2.1.31.1.1.1.10 |
Die Gesamtzahl der von der Schnittstelle übertragenen Oktetts, einschließlich Framing-Zeichen Dieses Objekt ist eine 64-Bit-Version von ifOutOctets. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/bytes-sent |
| ifInOctets |
1.3.6.1.2.1.2.2.1.10 |
Die Gesamtzahl der auf der Schnittstelle empfangenen Oktetts, einschließlich Framing-Zeichen Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/bytes-received |
| ifHCInOctets |
1.3.6.1.2.1.31.1.1.1.6 |
Die Gesamtzahl der auf der Schnittstelle empfangenen Oktetts, einschließlich Framing-Zeichen Dieses Objekt ist eine 64-Bit-Version von ifInOctets. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/bytes-received |
| ifOutBroadcastPakete |
1.3.6.1.2.1.31.1.1.1.5 |
Die Gesamtzahl der Pakete, die von übergeordneten Protokollen angefordert wurden und die an eine Broadcast-Adresse auf dieser Unterebene adressiert wurden, einschließlich der Pakete, die verworfen oder nicht gesendet wurden Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/broadcast-packages-sent |
| ifHCOutBroadcastPakete |
1.3.6.1.2.1.31.1.1.1.13 |
Die Gesamtzahl der Pakete, die von übergeordneten Protokollen angefordert wurden und die an eine Broadcast-Adresse auf dieser Unterebene adressiert wurden, einschließlich der Pakete, die verworfen oder nicht gesendet wurden Dieses Objekt ist eine 64-Bit-Version von ifOutBroadcastPkts. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/broadcast-packages-sent |
| ifInBroadcastPkts |
1.3.6.1.2.1.31.1.1.1.3 |
Die Anzahl der Pakete, die von dieser Unterschicht an eine höhere (Unter-)Schicht übermittelt wurden und die an eine Broadcast-Adresse in dieser Unterschicht adressiert wurden. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/broadcast-packages-received |
| ifHCInBroadcastPakete |
1.3.6.1.2.1.31.1.1.1.9 |
Die Anzahl der Pakete, die von dieser Unterschicht an eine höhere (Unter-)Schicht übermittelt wurden und die an eine Broadcast-Adresse in dieser Unterschicht adressiert wurden. Dieses Objekt ist eine 64-Bit-Version von ifInBroadcastPkts. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ifCounterDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/broadcast-packages-received |
| IfIndex |
1.3.6.1.2.1.2.2.1.1 |
Ein eindeutiger Wert größer als Null für jede Schnittstelle. Es wird empfohlen, dass Werte beginnend bei 1 fortlaufend zugewiesen werden. Der Wert für jeden Schnittstellen-Sublayer muss mindestens von einer Reinitialisierung des Netzwerkmanagementsystems der Einheit bis zur nächsten Reinitialisierung konstant bleiben. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/if-index |
| ifDescr |
1.3.6.1.2.1.2.2.1.2 |
Eine Textzeichenfolge mit Informationen über die Schnittstelle. Diese Zeichenfolge muss den Namen des Herstellers, den Produktnamen und die Version der Schnittstellenhardware/-software enthalten. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/description |
| ifGeschwindigkeit |
1.3.6.1.2.1.2.2.1.5 |
Eine Schätzung der aktuellen Bandbreite der Schnittstelle in Bit pro Sekunde. Bei Schnittstellen, die sich in der Bandbreite nicht unterscheiden oder bei denen keine genaue Schätzung möglich ist, sollte dieses Objekt die nominale Bandbreite enthalten. Wenn die Bandbreite der Schnittstelle größer ist als der maximale Wert, der von diesem Objekt gemeldet werden kann, dann sollte dieses Objekt seinen maximalen Wert (4.294.967.295) melden, und wennHighSpeed verwendet werden muss, um die Geschwindigkeit der Schnittstelle zu melden. Für eine Unterschicht, die kein Bandbreitenkonzept hat, sollte dieses Objekt Null sein. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/bandwidth |
| ifOperStatus |
1.3.6.1.2.1.2.2.1.8 |
Der aktuelle Betriebsstatus der Schnittstelle. Der Status testing(3) gibt an, dass keine betrieblichen Pakete weitergeleitet werden können. Wenn ifAdminStatus down(2) ist, dann muss ifOperStatus down(2) sein. Wenn AdminStatus in up(1) geändert wird, dann sollte ifOperStatus in up(1) geändert werden, wenn die Schnittstelle zum Senden und Empfangen von Netzwerkverkehr bereit ist; in dormant(5) geändert werden, wenn die Schnittstelle auf externe Aktionen wartet (z. B. eine serielle Leitung, die auf eine eingehende Verbindung wartet); sie sollte im down(2)-Zustand bleiben, wenn und nur bei einem Fehler, der sie daran hindert, nach up(1) zu gehen -Status; er sollte im Status "notPresent(6)" bleiben, wenn die Schnittstelle fehlende Komponenten (in der Regel Hardware) aufweist. |
Cisco-IOS-XR-pfi-im-cmd-oper:Interfaces/interface-non-dynamics/interface-non-dynamic/oper-state |
| ifAdminStatus |
1.3.6.1.2.1.2.2.1.7 |
Der gewünschte Status der Schnittstelle. Der Status testing(3) gibt an, dass keine betrieblichen Pakete weitergeleitet werden können. Wenn ein verwaltetes System initialisiert wird, beginnen alle Schnittstellen mit ifAdminStatus im Zustand down(2). Wenn AdminStatus entweder in den Status "up(1)" oder "testing(3)" geändert wird (oder im Status "down(2)" verbleibt), werden entweder explizite Verwaltungsaktionen oder Konfigurationsinformationen vom verwalteten System beibehalten. |
Cisco-IOS-XR-pfi-im-cmd-oper:Schnittstellen/Schnittstelle-nicht-dynamisch/Schnittstelle-nicht-dynamisch/Verwaltungsstatus |
| ifName |
1.3.6.1.2.1.31.1.1.1.1 |
Der Textname der Schnittstelle. Der Wert dieses Objekts sollte der Name der Schnittstelle sein, der vom lokalen Gerät zugewiesen wurde, und sollte für die Verwendung in Befehlen geeignet sein, die an der Konsole des Geräts eingegeben werden. Dies kann ein Textname sein, wie z. B. `le0', oder eine einfache Portnummer, wie z. B. `1', abhängig von der Syntax für die Schnittstellennamen des Geräts. Wenn mehrere Einträge in der ifTable zusammen eine einzelne Schnittstelle darstellen, wie sie vom Gerät benannt wurde, hat jede denselben Wert wie ifName. Beachten Sie, dass für einen Agenten, der auf SNMP-Abfragen bezüglich einer Schnittstelle auf einem anderen (Proxy-Gerät) antwortet, der Wert von ifName für eine solche Schnittstelle dem lokalen Namen des Proxy-Geräts entspricht. Wenn es keinen lokalen Namen gibt oder dieses Objekt anderweitig nicht anwendbar ist, enthält dieses Objekt eine Zeichenfolge der Länge Null. |
Cisco-IOS-XR-pfi-im-cmd-oper:Schnittstellen/Schnittstellenbeschreibungen/Schnittstellenbeschreibung/Schnittstellenname |
| ifHighSpeed |
1.3.6.1.2.1.31.1.1.1.15 |
Eine Schätzung der aktuellen Bandbreite der Schnittstelle in Einheiten von 1.000.000 Bits pro Sekunde. Wenn dieses Objekt einen Wert von 'n' meldet, dann liegt die Geschwindigkeit der Schnittstelle irgendwo im Bereich von 'n-500.000' bis 'n+499.999'. Bei Schnittstellen, die sich in der Bandbreite nicht unterscheiden oder bei denen keine genaue Schätzung möglich ist, sollte dieses Objekt die nominale Bandbreite enthalten. Für eine Unterschicht, die kein Bandbreitenkonzept hat, sollte dieses Objekt Null sein. |
Cisco-IOS-XR-pfi-im-cmd-oper:Schnittstellen/Schnittstellenbeschreibungen/Schnittstellenbeschreibung/Bandbreite64-Bit |
IP-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen für IP-Statistiken und Betriebswerte eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| ICMPinZielNicht erreichbar |
1.3.6.1.2.1.5.3 |
Die Anzahl der empfangenen Nachrichten für "ICMP-Ziel nicht erreichbar". |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| ICMPinParameterProbs |
1.3.6.1.2.1.5.5 |
Die Anzahl der empfangenen ICMP-Parameterproblemmeldungen. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpInSrcQuenche |
1.3.6.1.2.1.5.6 |
Die Anzahl der empfangenen ICMP-Quench-Nachrichten |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpInEchos |
1.3.6.1.2.1.5.8 |
Die Anzahl der empfangenen ICMP-Echonachrichten (Anforderung). |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| ICMPinEchoReps |
1.3.6.1.2.1.5.9 |
Die Anzahl der empfangenen ICMP-Echoantwortmeldungen. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| ICMPinZeitstempel |
1.3.6.1.2.1.5.10 |
Die Anzahl der empfangenen ICMP-Zeitstempelnachrichten (Anforderung). |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpInAddrMasken |
1.3.6.1.2.1.5.12 |
Die Anzahl der empfangenen ICMP-Adressmaskenanforderungsnachrichten. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpInAddrMaskeReps |
1.3.6.1.2.1.5.13 |
Die Anzahl der empfangenen ICMP-Adressmaskenantwortmeldungen. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpAusNachrichten |
1.3.6.1.2.1.5.14 |
Die Gesamtzahl der ICMP-Nachrichten, die diese Entität senden wollte. Beachten Sie, dass dieser Zähler alle von icmpOutErrors gezählten Zähler enthält. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpAusZielNicht erreichbar |
1.3.6.1.2.1.5.16 |
Die Anzahl der gesendeten Nachrichten für "ICMP-Ziel nicht erreichbar". |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpAusZeitErz |
1.3.6.1.2.1.5.17 |
Die Anzahl der gesendeten ICMP-Nachrichten mit Zeitüberschreitung. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpOutParameterProbs |
1.3.6.1.2.1.5.18 |
Die Anzahl der gesendeten ICMP-Parameterproblemmeldungen. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpOutSrcQuenche |
1.3.6.1.2.1.5.19 |
Die Anzahl der gesendeten ICMP Source Quench-Nachrichten |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpOutRedirects |
1.3.6.1.2.1.5.20 |
Die Anzahl der gesendeten ICMP-Umleitungsnachrichten. Bei einem Host ist dieses Objekt immer Null, da Hosts keine Umleitungen senden. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpAusEchos |
1.3.6.1.2.1.5.21 |
Die Anzahl der gesendeten ICMP-Echo-Nachrichten (Anforderung) |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpOutEchoReps |
1.3.6.1.2.1.5.22 |
Die Anzahl der gesendeten ICMP-Echoantwortmeldungen. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpOutTimestamps |
1.3.6.1.2.1.5.23 |
Die Anzahl der gesendeten ICMP-Zeitstempel (Anforderung)-Nachrichten |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpOutAddrMasken |
1.3.6.1.2.1.5.25 |
Die Anzahl der gesendeten ICMP-Adressmaskenanforderungsnachrichten. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| icmpOutAddrMaskeReps |
1.3.6.1.2.1.5.26 |
Die Anzahl der gesendeten ICMP-Adressmaskenantwortmeldungen. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/icmp-stats |
| ipAdEntIfIndex |
1.3.6.1.2.1.4.20.1.2 |
Der Indexwert, der die Schnittstelle eindeutig identifiziert, für die dieser Eintrag gilt. Die Schnittstelle, die durch einen bestimmten Wert dieses Indexes identifiziert wird, ist dieselbe Schnittstelle, die durch denselben Wert von ifIndex von RFC 1573 identifiziert wird. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/ |
| IPadEntAddr |
1.3.6.1.2.1.4.20.1.1 |
Die IP-Adresse, zu der die Adressierungsinformationen dieses Eintrags gehören. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Schnittstellen/Schnittstelle/vrfs/vrf/detail/primäre Adresse |
| ipAdNetMask |
1.3.6.1.2.1.4.20.1.3 |
Die Subnetzmaske, die der IP-Adresse dieses Eintrags zugeordnet ist. Der Wert der Maske ist eine IP-Adresse, bei der alle Netzwerkbits auf 1 und alle Hosts auf 0 gesetzt sind. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Schnittstellen/Schnittstelle/vrfs/vrf/detail/prefix-length |
| IPadEntBcastAddr |
1.3.6.1.2.1.4.20.1.4 |
Der Wert des niederwertigsten Bits in der IP-Rundrufadresse, der zum Senden von Datagrammen auf der (logischen) Schnittstelle verwendet wird, die der IP-Adresse dieses Eintrags zugeordnet ist. Wenn z. B. die standardmäßige Internet-Rundrufadresse für alle Geräte verwendet wird, ist der Wert 1. Dieser Wert gilt sowohl für die Subnetz- als auch für die Netzwerk-Broadcast-Adressen, die von der Einheit auf dieser (logischen) Schnittstelle verwendet werden. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Schnittstellen/Schnittstelle/vrfs/vrf/detail/direct-broadcast |
| ipNetToMediaPhysAdresse |
1.3.6.1.2.1.4.22.1.2 |
Die medienabhängige physische Adresse. |
Cisco-IOS-XR-ipv4-arp-oper:arp/nodes/node/entries/entry/hardware-address |
IPMIB-COMMMON
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen für die IP-Statistik eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| ipIfStatsHCOutTransmits |
1.3.6.1.2.1.4.31.3.1.31 |
Die Gesamtzahl der IP-Datagramme, die diese Einheit den unteren Schichten zur Übertragung bereitgestellt hat. Dieses Objekt zählt dieselben Datagramme wie ipIfStatsOutTransmits, lässt jedoch größere Werte zu. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ipIfStatsDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/ipv4-Statistiken/weitergeleitete Pakete |
| ipIfStatsInReceives |
1.3.6.1.2.1.4.31.3.1.3 |
Die Gesamtzahl der empfangenen IP-Eingabedatagramme, einschließlich fehlerhaft empfangener Datagramme Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ipIfStatsDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/ipv4-Statistiken/Eingangspakete |
| ipIfStatsHCInReceives |
1.3.6.1.2.1.4.31.3.1.4 |
Die Gesamtzahl der empfangenen IP-Eingabedatagramme, einschließlich fehlerhaft empfangener Datagramme Dieses Objekt zählt dieselben Datagramme wie ipIfStatsInReceives, lässt jedoch größere Werte zu. Diskontinuitäten im Wert dieses Zählers können bei der Neuinitialisierung des Managementsystems auftreten, und zu anderen Zeiten, wie durch den Wert von ipIfStatsDiskontinuitätZeit angegeben. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-Netzwerk/Knoten/Knoten/Statistiken/Datenverkehr/ipv4-Statistiken/Eingangspakete |
LLDP-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen für LLDP-Betriebsdaten (Link Layer Discovery Protocol) auf dem überwachten Knoten eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| LDPolcPortID |
1.0.8802.1.1.2.1.3.7.1.3 |
Der Zeichenfolgenwert, der zum Identifizieren der Port-Komponente verwendet wird, die einem bestimmten Port im lokalen System zugeordnet ist. |
Cisco-IOS-XR-Ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/port-id-detail |
| lldpLocPortIdSubtyp |
1.0.8802.1.1.2.1.3.7.1.2 |
Der Typ der im zugeordneten 'lldpLocPortId'-Objekt verwendeten Port-ID-Codierung. |
Cisco-IOS-XR-Ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/mib/port-id-sub-type |
| lldpLocChassisIdUntertyp |
1.0.8802.1.1.2.1.3.1 |
Der Kodierungstyp, der zum Identifizieren des Chassis verwendet wird, das dem lokalen System zugeordnet ist. |
Cisco-IOS-XR-Ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/mib/chassis-id-sub-type |
| LDPolcSysName |
1.0.8802.1.1.2.1.3.3 |
Der Zeichenfolgenwert, der verwendet wird, um den Systemnamen des lokalen Systems zu identifizieren. Wenn der lokale Agent IETF RFC 3418 unterstützt, sollte das lldpLocSysName-Objekt den gleichen Wert wie das sysName-Objekt haben. |
Cisco-IOS-XR-Ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/detail/system-name |
| ldpRemSysName |
1.0.8802.1.1.2.1.4.1.1.9 |
Der Zeichenfolgenwert, der verwendet wird, um den Systemnamen des Fernsystems zu identifizieren. |
Cisco-IOS-XR-Ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/detail/system-name |
| LDPremChassisID |
1.0.8802.1.1.2.1.4.1.1.5 |
Der Zeichenfolgenwert, der zum Identifizieren der Chassis-Komponente verwendet wird, die dem Remote-System zugeordnet ist. |
Cisco-IOS-XR-Ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/chassis-id |
| lldpRemChassisIdUntertyp |
1.0.8802.1.1.2.1.4.1.1.4 |
Der Kodierungstyp, der zur Identifizierung des Chassis verwendet wird, das dem Remote-System zugeordnet ist. |
Cisco-IOS-XR-Ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor |
| ldpRemPortIdSubtyp |
1.0.8802.1.1.2.1.4.1.1.6 |
Der Typ der im zugeordneten 'lldpRemPortId'-Objekt verwendeten Port-ID-Codierung. |
Cisco-IOS-XR-Ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor |
| LDPremPortID |
1.0.8802.1.1.2.1.4.1.1.7 |
Der Zeichenfolgenwert, der zum Identifizieren der Port-Komponente verwendet wird, die dem Remote-System zugeordnet ist. |
Cisco-IOS-XR-Ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor |
| LLDPlocChassisID |
1.0.8802.1.1.2.1.3.2 |
Der Zeichenfolgenwert, der zum Identifizieren der Chassis-Komponente verwendet wird, die dem lokalen System zugeordnet ist. |
Cisco-IOS-XR-Ethernet-lldp-oper:lldp/nodes/node/neighbors/details/detail/lldp-neighbor/chassis-id |
MPLS-TE-STD-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen eingerichtet werden soll, die sich auf die Betriebswerte von Multiprotocol Label Switching (MPLS) Traffic Engineering auf dem verwalteten Gerät beziehen.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| mplsTunnelname |
1.3.6.1.2.1.10.166.3.2.2.1.5 |
Der kanonische Name, der dem Tunnel zugewiesen ist. Dieser Name kann für den Tunnel am Konsolen-Port des LSR verwendet werden. Wenn mplsTunnelIsIf auf true festgelegt ist, muss der ifName der Schnittstelle, die diesem Tunnel entspricht, den Wert mplsTunnelName haben. Siehe auch die Beschreibung von ifName in RFC 2863. |
Cisco-IOS-XR-mpls-te-oper:mpls-te/p2p-p2mp-tunnel/tunnel-heads/tunnel-head/tunnel-name |
| mplsTunnelBeschreibung |
1.3.6.1.2.1.10.166.3.2.2.1.6 |
Eine Textzeichenfolge mit Informationen über den Tunnel. Wenn keine Beschreibung vorhanden ist, enthält dieses Objekt eine Zeichenfolge mit der Länge Null. Dieses Objekt wird möglicherweise nicht von MPLS-Signalisierungsprotokollen signalisiert, sodass der Wert dieses Objekts bei Transit- und Ausgangs-LSRs möglicherweise automatisch generiert wird oder fehlt. |
openconfig-network-instance:Netzwerk-Instanzen/Netzwerk-Instanz/mpls/lsps/restricted-path/tunnels/tunnel/state/description |
| mplsTunnelPerfHCPackets |
1.3.6.1.2.1.10.166.3.2.9.1.2 |
Leistungsindikator für hohe Kapazität für die Anzahl der vom Tunnel weitergeleiteten Pakete |
openconfig-network-instance:network-instanzen/network-instance/mpls/lsps/restricted-path/tunnels/tunnel/state/counters/pakete |
| mplsTunnelPerfHCByte |
1.3.6.1.2.1.10.166.3.2.9.1.5 |
Leistungsindikator mit hoher Kapazität für die Anzahl der vom Tunnel weitergeleiteten Bytes. |
openconfig-network-instance:network-instanzen/network-instance/mpls/lsps/restricted-path/tunnels/tunnel/state/counters/bytes |
| mplsTunnelHopIPAddr |
1.3.6.1.2.1.10.166.3.2.4.1.5 |
Die Tunnel-Hop-Adresse für diesen Tunnelhop. Der Typ dieser Adresse wird durch den Wert des entsprechenden mplsTunnelHopAddrType bestimmt. Der Wert dieses Objekts kann nicht geändert werden, wenn der Wert des entsprechenden mplsTunnelHopRowStatus-Objekts 'active' ist. |
Cisco-IOS-XR-mpls-te-oper:mpls-te/p2p-p2mp-tunnel/tunnel-heads/tunnel-head/destination/destination-address |
RFC 2465-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetrie-Sensorgruppen für globale IPv6-Werte eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| IPv6AdrPfXlength |
1.3.6.1.2.1.55.1.8.1.2 |
Die Länge des Präfix (in Bit), das der IPv6-Adresse dieses Eintrags zugeordnet ist. |
Cisco-IOS-XR-ipv6-ma-oper:ipv6-Netzwerk/Knoten/Knoten/Schnittstellendaten/vrfs/vrf/briefs/brief/address/prefix-length |
| IPv6AdrAnycastFlag |
1.3.6.1.2.1.55.1.8.1.4 |
Dieses Objekt hat den Wert 'true(1)', wenn diese Adresse eine Anycast-Adresse ist und andernfalls den Wert 'false(2)'. |
Cisco-IOS-XR-ipv6-ma-oper:ipv6-Netzwerk/Knoten/Knoten/Schnittstellendaten/vrfs/vrf/briefs/brief/address/is-anycast |
SNMP-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetrie-Sensorgruppen eingerichtet werden soll, die sich auf den SNMP-Agenten selbst beziehen, sofern verfügbar.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| sysBetriebszeit |
1.3.6.1.2.1.1.3 |
Zeichenfolge für die Systemverfügbarkeit |
Cisco-IOS-XR-snmp-agent-oper:snmp/information/system-up-time/ |
| sysObjektID |
.1.3.6.1.2.1.1.2.0 |
Zeichenfolge für die System-OID |
Cisco-IOS-XR-snmp-agent-oper:snmp/information/system-oid/ |
| sysBeschreibung |
1.3.6.1.2.1.1.1 |
Zeichenfolge, die die Systembeschreibung darstellt |
Cisco-IOS-XR-snmp-agent-oper:snmp/information/system-descr |
TCP-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen für TCP-spezifische Zähler eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| TCPinErr |
1.3.6.1.2.1.6.14 |
Die Gesamtzahl der fehlerhaft empfangenen Segmente (z. B. ungültige TCP-Prüfsummen) |
Cisco-IOS-XR-ip-tcp-oper:tcp/nodes/node/statistics/ipv4-traffic/tcp-checksum-error-packages |
| TCPinSegmente |
1.3.6.1.2.1.6.10 |
Die Gesamtzahl der empfangenen Segmente, einschließlich fehlerhaft empfangener Segmente. Diese Anzahl umfasst Segmente, die auf aktuell eingerichteten Verbindungen empfangen wurden. |
Cisco-IOS-XR-ip-tcp-oper:tcp/nodes/node/statistics/ipv4-traffic/tcp-input-packages |
| TcpAusSegmente |
1.3.6.1.2.1.6.11 |
Die Gesamtzahl der gesendeten Segmente, einschließlich der Segmente für aktuelle Verbindungen, jedoch ohne Segmente, die nur erneut übertragene Oktetts enthalten. |
Cisco-IOS-XR-ip-tcp-oper:tcp/nodes/node/statistics/ipv4-traffic/tcp-output-pakete |
UDP-MIB
Die nächste Tabelle enthält den OID-Namen und die OID-Nummer sowie den entsprechenden XPATH, der auf modellbasierten Telemetriesensorgruppen für UDP-spezifische Zähler eingerichtet werden soll.
| OID-Name |
OID-Nummer |
OID-Beschreibung |
XPATH |
| udpOutDatagramme |
1.3.6.1.2.1.7.4 |
Die Gesamtzahl der von dieser Entität gesendeten UDP-Datagramme |
Cisco-IOS-XR-ip-udp-oper:/udp/nodes/node/statistics/ipv4-traffic/udp-output-packages |
| udpKeinePorts |
1.3.6.1.2.1.7.2 |
Die Gesamtzahl empfangener UDP-Datagramme, für die am Zielport keine Anwendung vorhanden war. |
Cisco-IOS-XR-ip-udp-oper:/udp/nodes/node/statistics/ipv4-traffic/udp-no-ports-packages |
| udpInErrors |
1.3.6.1.2.1.7.3 |
Die Anzahl der empfangenen UDP-Datagramme, die aus anderen Gründen als dem Fehlen einer Anwendung am Zielport nicht zugestellt werden konnten |
Cisco-IOS-XR-ip-udp-oper:/udp/nodes/node/statistics/ipv4-traffic/udp-checksum-error-packages |
| udpInDatagramme |
1.3.6.1.2.1.7.1 |
Die Gesamtzahl der UDP-Datagramme, die an UDP-Benutzer übermittelt wurden. |
Cisco-IOS-XR-ip-udp-oper:/udp/nodes/node/statistics/ipv4-traffic/udp-input-packages |
Migration von SNMP-Traps
SNMP-Traps sind Meldungen, die durch dynamische Ereignisse auf dem verwalteten Gerät ausgelöst werden. Daher verhalten sich diese Meldungen analog zum zuvor behandelten EDT-Konzept.
Auf der Konfigurationsseite ermöglicht MDT dieselbe Struktur für EDT, die von der Implementierung des Telemetriesammlers in Bezug auf die Auswahl oder die Funktionen für Ein- und Auswahl abhängt.
Sicherheitsüberlegungen
SNMPv2 verwendet nur die Community als Authentifizierungs-/Autorisierungsmechanismus. SNMPv3, wie bereits im Abschnitt zu SNMP beschrieben, die Anmeldeinformationen für die Authentifizierung und das AES-Verschlüsselungsmodell zum Schutz der Informationen verwenden könnten.
Beim Telemetrie-Ansatz ermöglicht IOS XR die Verwendung von gRPC/TLS-Techniken, die auf Zertifikaten basieren, um die Authentifizierung durchzuführen. Diese Zertifikate können mit einem zentralen Vertrauenspunkt (z. B. einem Zertifizierungsstellenserver) verwendet werden. Nach dem Aufbau einer Vertrauensbeziehung werden alle Telemetriemeldungen innerhalb einer gRPC-Sitzung gesendet, die mit TLS verschlüsselt wird und somit die gleichen Vorteile von SNMPv3 bietet.
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
16-Mar-2021 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)