SNMP Migration to Telemetry on IOS XR
Available Languages
Contents
Introduction
This article introduces Simple Network Management Protocol (SNMP) components, and provides a correlation between current implementations based on SNMP monitoring into Model Driven Telemetry (MDT) approach.
SNMP
SNMP is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language that is used for monitoring and managing devices in a network
Components of SNMP
The SNMP framework has the following components, which are described in the following sections:
SNMP Manager
The SNMP manager is a system that controls and monitors the activities of network hosts using SNMP. The most common managing system is a network management system (NMS). The term NMS can be applied either to a dedicated device used for network management or to the applications used on such a device.
SNMP Agent
The SNMP agent is the software component within a managed device that maintains the data for the device and reports this data, as needed, to managing systems. The agent resides on the routing device (router, access server, or switch).
SNMP MIB
An SNMP agent contains MIB variables, whose values can be requested or changed by the SNMP manager through 'Get' or 'Set' operations. A manager can get a value from an agent or store a value in that agent. The agent gathers data from the SNMP MIB, the repository for information about device parameters and network data. The agent can also respond to manager requests to get or set data.
The figure below illustrates the communications between the SNMP manager and agent. A manager sends an agent requests to get and set the SNMP MIB values. The agent responds to these requests. Independent of this interaction, the agent can send the manager unsolicited notifications (traps or informs) to notify the manager about network conditions.
SNMP Operations
The SNMP applications perform the following operations to retrieve data, modify SNMP object variables, and send notifications:
SNMP Get
The SNMP GET operation is performed by an NMS to retrieve SNMP object variables. There are three types of GET operations:
- GET—Retrieves the exact object instance from the SNMP agent.
- GETNEXT—Retrieves the next object variable, which is a lexicographical successor to the specified variable.
- GETBULK—Retrieves a large amount of object variable data, without the need for repeated GETNEXT operations.
SNMP SET
The SNMP SET operation is performed by a NMS to modify the value of an object variable.
SNMP Notifications
A key feature of SNMP is its capability to generate unsolicited notifications from an SNMP agent.
Unsolicited (asynchronous) notifications can be generated as traps or inform requests (informs). Traps are messages alerting the Simple Network Management Protocol (SNMP) manager to a condition on the network. Informs are traps that include a request for confirmation of receipt from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor device, or other significant events.
Traps are less reliable than informs because the receiver does not send an acknowledgment when it receives a trap. The sender does not know if the trap was received. An SNMP manager that receives an inform acknowledges the message with an SNMP response Protocol Data Unit (PDU). If the sender never receives a response, the inform can be sent again. Thus, informs are more likely to reach their intended destination.
Traps are often preferred even though they are less reliable because informs consume more resources in the device and the network. Unlike a trap, which is discarded as soon as it is sent, an inform must be held in memory until a response is received or the request times out. Also, traps are sent only once, whereas an inform may be resent several times. The retries increase traffic and contribute to higher overhead on the network. Use of traps and informs requires a trade-off between reliability and resources.
MIBs and RFCs
Management Information Base (MIB) modules typically are defined in Request for Comments (RFC) documents submitted to the Internet Engineering Task Force (IETF), an international standards body. RFCs are written by individuals or groups for consideration by the Internet Society and the Internet community as a whole, usually with the intention of establishing a recommended Internet standard. Before being given RFC status, recommendations are published as Internet Draft (I-D) documents. RFCs that have become recommended standards are also labeled as standards documents (STDs). You can learn about the standards process and the activities of the IETF at the Internet Society website at http://www.isoc.org. You can read the full text of all RFCs, I-Ds, and STDs referenced in Cisco documentation at the IETF website at http://www.ietf.org.
The Cisco implementation of SNMP uses the definitions of MIB II variables described in RFC 1213 and definitions of SNMP traps described in RFC 1215.
Cisco provides its own private MIB extensions with every system. Cisco enterprise MIBs comply with the guidelines described in the relevant RFCs unless otherwise noted in the documentation. You can find the MIB module definition files and the list of MIBs supported on each Cisco platform on the Cisco MIB website on Cisco.com.
Versions of SNMP
Currently Cisco devices support the following versions of SNMP:
- SNMPv1—Simple Network Management Protocol: a full Internet standard, defined in RFC 1157. (RFC 1157 replaces the earlier versions that were published as RFC 1067 and RFC 1098.) Security is based on community strings.
- SNMPv2c—The community string-based Administrative Framework for SNMPv2. SNMPv2c (the “c” is for “community”) is an experimental Internet protocol defined in RFC 1901, RFC 1905, and RFC 1906. SNMPv2c is an update of the protocol operations and data types of SNMPv2p (SNMPv2 Classic) and uses the community-based security model of SNMPv1.
- SNMPv3—Version 3 of SNMP. SNMPv3 is an interoperable standards-based protocol defined in RFCs 3413 to 3415. SNMPv3 provides secure access to devices by authenticating and encrypting packets over the network.
The security features provided in SNMPv3 are as follows:
- Message integrity—Ensuring that a packet has not been tampered with in transit.
- Authentication—Determining that the message is from a valid source.
- Encryption—Scrambling the contents of a packet to prevent it from being learned by an unauthorized source.
Both SNMPv1 and SNMPv2c use a community-based form of security. The community of SNMP managers are able to access the agent MIB is defined by a community string.
SNMPv2c support includes a bulk retrieval mechanism and detailed error message reporting to management stations. The bulk retrieval mechanism supports the retrieval of tables and large quantities of information, minimizing the number of round trips required. The SNMPv2c improved error handling support includes expanded error codes that distinguish different types of errors; these conditions are reported through a single error code in SNMPv1. The following three types of exceptions are also reported: no such object, no such instance, and end of MIB view.
SNMPv3 is a security model in which an authentication strategy is set up for a user and the group in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level determines which security mechanism is employed when handling an SNMP packet.
Three security models are available: SNMPv1, SNMPv2c, and SNMPv3. The table below lists the combinations of security models and levels and their meanings.
|
Model |
Level |
Authentication |
Encryption |
What Happens |
|
v1 |
noAuthNoPriv |
Community String |
No |
Uses a community string match for authentication. |
|
v2c |
noAuthNoPriv |
Community String |
No |
Uses a community string match for authentication. |
|
v3 |
noAuthNoPriv |
Username |
No |
Uses a username match for authentication. |
|
v3 |
authNoPriv |
Message Digest 5 (MD5) or Secure Hash Algorithm (SHA) |
No |
Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. |
|
v3 |
authPriv |
MD5 or SHA |
Data Encryption Standard (DES) |
Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Provides DES 56-bit encryption in addition to authentication based on the CBC-DES (DES-56) standard. |
An SNMP agent should be implemented in order to use the version of SNMP supported by the management station. An agent can communicate with multiple managers.
SNMPv3 supports RFCs 1901 to 1908, 2104, 2206, 2213, 2214, and 2271 to 2275. For additional information about SNMPv3, see RFC 2570, Introduction to Version 3 of the Internet-standard Network Management Framework (this is not a standards document).
Yang models
Yang models represent a tree-structured abstraction of a specific feature or hardware characteristics of a system. In network elements, a Yang model could represent a routing protocol, internal physical sensors arrays. YANG language and terminology is described on RFC 6020 and next updated on RFC 7950. In high-level, a Yang model organizes the data representing the main structure into submodules and containers that are a list of sub-nodes related. Several node types are explained next.
A leaf node contains simple data like an integer or a string. It has exactly one value of a particular type and no child nodes.
leaf host-name {
type string;
description "Hostname for this system";
}A leaf-list is a sequence of leaf nodes with exactly one value of a particular type per leaf.
leaf-list domain-search {
type string;
description "List of domain names to search";
}A container node is used to group related nodes in a subtree. A container has only child nodes and no value. A container may contain any number of child nodes of any type (including leafs, lists, containers, and leaf-lists).
container system {
container login {
leaf message {
type string;
description
"Message given at start of login session";
}
}
}A list defines a sequence of list entries. Each entry is like a structure or a record instance and is uniquely identified by the values of its key leafs. A list can define multiple key leafs and may contain any number of child nodes of any type (including leafs, lists, containers etc.).
Finally, a sample model that binds all these note types together looks like the following example:
## 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;
}
}
}
}
}However, the Yang language used on Yang Models does not indicate the organization of the data into containers/list/leafs. This is why a certain feature on a network element could be represented with diverse Yang models. This challenge has been addressed with the following Yang Models Types:
OpenConfig Models
OpenConfig Models were developed using agnostic vendor organization for the model representing a specific feature, the benefit of this approach is that a NMS could use these models for interacting with network elements on multi-vendor or even multi-platform environment.
As the name states, these models are open and are publicly available for inspecting on repositories like github on this link:
https://github.com/openconfig/public/tree/master/release/models
As an example, you can find an openconfig model for Border Gateway Protocol (BGP), another for Link Aggregation Control Protocol (LACP) and a different one for ISIS, with different specific model. In the case of BGP you can find a model for BGP errors, another one for BGP policy and so on. The models could be related, and some models can call another yang package. For example, openconfig-bgp-neighbor.yang belongs to 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;
<snip>To sum up, OpenConfig Models are oriented for protocols common to all platforms, like IETF or RFC standardized features.
Native Models
In contrast, Native models are vendor-oriented models that cover in depth structures specific to a particular platform. For example, models that group sensors of physical values inside a network element like voltages, temperatures, ASIC counters, Fabric counters and so on. Since they depend on the platform, it is common to find models specific for NCS6K, ASR9K or Cisco 8000.
As OpenConfig Models, Native Models are also available in Github repository:
https://github.com/YangModels/yang/tree/master/vendor/cisco/xr
As these models tend to be much more specific and complete than OpenConfig models, they are tied to specific software version, and subject to change between software releases.
There are two main categories for Native Models:
- “Oper” models, used to retrieve information from an element.
For example, Cisco-IOS-XR-eigrp-oper.yang
- “Cfg” models, used to configure a network element
For example, Cisco-IOS-XR-eigrp-cfg.yang
In general terms, Model Driven Telemetry uses “oper” models to stream data from infrastructure and NMS like NSO uses “cfg” models to make changes in the configuration on network elements.
Native and OpenConfig Yang Models are present on XR software on /pkg/yang folder and can be listed to find out if any Yang Model is available on a platform. This example is for XRrv9k running cXR 6.4.2:
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#
Telemetry
Telemetry is a process that allows collecting information from different remote elements into a central location that aggregate visibility and analytics layer.
In networking environments, the data could be produced by every element in the network, routers, swiches between others and the information could be related to a very large set of specific protocols, performance counters or measures from physical sensors.
In general, Visibility and Analytics functions are located in central points in networks, streaming of telemetry information is made using networking transport mechanisms, so telemetry information should be fast as possible allowing to scale.
As opposed to SNMP legacy mechanisms, Telemetry uses a Push paradigm, where the network should be provisioned to stream its own data without being polled at regular intervals, which is the main characteristic of SNMP based monitoring. This provision it is often called subscription, and it is based on a set of variables to be monitored, the regular interval for the sampling interval for data collection, and the remote system to send this data across the network.
Model Driven Telemetry
MDT states for Model Driven Telemetry, and as the name says, it is based on Yang Models. Every aspect in network equipment could be represented with Yang Models, for example OSPF Neighbors table, RIB or Temperature Sensors for each component on modular systems.
Regarding MDT architecture, it can be divided in the following layers:
Note: Regarding the producer layer, in model driven telemetry there is a sampling-interval definition that controls how often the device consult the internal database for raw data and organizes this data into the data-model layer.
The telemetry subscription also defines which models and with containers/path would produce data to be streamed into the Analytics Layer. This definition would impact in relevant information to business purposes. MDT definition of this sensor-path would be analogue to define OID to retrieve via SNMP, since both techinques produces structured data at defined sampling-rate.
Event Driven Telemetry
EDT stands for Event Driven Telemetry and is also based on Yang models for the structure. The main difference is that the trigger for the collection and data stream is not regular interval, but is a specific event, like threshold cross, link events, hardware failure, and so on.
A comparison from an event with Model Driven Telemetry and Event Driven Telemetry is presented next:
Tip: This figure shows redundant messages using MDT, but only messages representing changes by using EDT.
Transport
Telemetry should be reliable as possible, so makes sense using Transmission Control Protocol (TCP) based transport for using session-oriented sockets between the infrastructure and the Analytics layer, which should implement collectors for making the session.
There are two main approaches when using telemetry, and they differ between each other in the 3-way-handshake initial flow.
Note: In Dial-Out mode, the setup of the session is started on the infrastructure side, which implies that the sensors of interest should be configured on the network elements. In constrast, Dial-In approach allow a lighter configuration on network elements since the collector should ask for specific sensor paths at setup phase.
TCP
TCP is the simplest way of making a connection-oriented session between a network element and a telemetry collector, and the stream of data starts from Router to Collector who sent ACK back to the router for reliability purposes:
gRPC
Since Google Protocol RPC (gRPC) works over Hypertext Transfer Protocol/2 (HTTP/2), the session itself should form at setup, and allows speed control from the collector side natively:
gNMI/gNOI
gRPC Network Management Interface (gNMI) is gRPC network management protocol developed by Google. gNMI provides the mechanism to install, manipulate, and delete the configuration of network devices, and also to view operational data. The content provided through gNMI can be modeled using YANG.
gNMI uses gRPC-HTTP/2 to setup a connection and provides bi-directional channel between network elements and a NMS that could also be a telemetry collector, but also provides and interface to manage the devices.
Between the operations supported by this protocol, we can find gNMI Get, gNMI Set that return the information requested, success or error messages.
gRPC Network Operations Interface (gNOI) is a collection of microservices that uses the same communication channel as gNMI but allows generic operations not related to configuration itself like ping, reboot, change SSL certificates, clearing, etc.
Encoding
Yang models define the structure of the data, its hierarchy, and the type of every leaf node on it. However, modeling does not indicate how this data should be serialized. This process governate the conversion from structured data into a stream of bytes to be sent over the TCP connection (raw TCP, gRPC, gNMI, etc).
Note: This process should be implemented with an equivalent mechanism in the network element who should encode the data, and the collector should decode this data.
JSON
The first encoding mechanism is native JavaScript Object Notation (JSON) format, which is well-known but is human-oriented as it has every key represented as string which is inefficient in terms of message size. The major benefit of using JSON is that is easy to parse, and read as is text-based as the next example:
{
“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 it is also called self-describing GPB because it makes use of protocol buffers to make usage of messages that point to particular elements on Yang models. This implies that only one .proto file is needed to encode/decode purposes, and the keys itself from the data are in self-described 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
Finally, Google Protocol Buffers (GPB), also called compact GPB, takes this approach one step futher and requires .proto files to map every key of the structure making it much more efficient in terms of message size since everything is sent as binary values. However, the drawback is the need of compiling every .proto file associated to every Yang model supported by infrastructure/collector.
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 Configuration in IOS XR
The core components used in streaming model-driven telemetry data are:
- Session
- Sensor Path
- Subscription
- Transport and Encoding
The session options can be Dial-in or Dial-out as we discussed previously. In order to build the configuration in IOS XR.
Dial-Out Mode
for Dial-Out mode, the router initiates a session to the destinations based on the subscription, and the process should include following steps:
- Create a Destination Group
- Create a Sensor Group
- Create a Subscription
- Validate Dial-out configuration
In order to create a destination group, you need to know the Internet Protocol Version 4 (IPv4) / Internet Protocol Version 6 (IPv6) address of the collector and the port that would service this application. Also, you need to specify the protocol and the encoding that should be agreed on the network device and the collector.
Finally, you may need to specify the Virtual Routing and Forwarding (VRF) used to communicate to the collector network address.
Next, an example of Dial-Out configuration is presented:
telemetry model-driven
destination-group DG1
vrf MGMT
address-family ipv4 192.168.122.20 port 5432
encoding self-describing-gpb
protocol tcp
!
!
Encoding options are presented next:
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
The protocols options:
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
<cr>
RP/0/RP0/CPU0:C8000-1(config-model-driven-dest-addr)#protocol tcp ?
<cr>
RP/0/RP0/CPU0:C8000-1(config-model-driven-dest-addr)#protocol udp ?
packetsize UDP packet size
<cr>
RP/0/RP0/CPU0:C8000-1(config-model-driven-dest-addr)#protocol udp
TCP protocol is straightforward and only need the port settings attached to the IPv4/IPv6 address. User Datagram Protocol (UDP) in contrast is connectionless, so the destination group status would always be active.
Compression in gRPC can be achieved by the usage of the optional gzip keyword. gRPC uses TLS by default, so a certificate should be installed locally on the router for this usage. This behaviour can be override by configuration of no-tls keyword. Finally, you can specify a different hostname for certificate purposes using tls-hostname keyword.
Next, sensor-group section should be added listing the sensor-paths of our interest. This section is straightforward but is important to know that the sensor-path itself allows for filtering to optimize several resources like Central Processing Unit (CPU) and bandwidth.
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
!
!
Note: The format needed for a sensor path is <model-name>:<container-path>
This document presents the mapping from SNMP based monitoring using OID representing “leaves” in this legacy approach into YANG models, represented with XPATHs that matches the same “leaves”.
The final configuration stage should be configuring a subscription, which ties the sensor group with a cadence for the telemetry streaming to a destination group.
telemetry model-driven
subscription SU1
sensor-group-id SG1 sample-interval 5000
destination-id DG1
!
!
This example uses a sampling interval of 5000 milliseconds (5 seconds) which is relative to the end of the previous collection. To change this behavior, you can change sample-interval keyword with strict-timer option.
For verification, you can use the following command that covers subscription status. This method allows covering sensor-group and destination-group information also.
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#
Dial-In Mode
In Dial In mode, the collector initiates the connection to the network elements. Then, the collector should indicate the interest to build a subscription.
The configuration has the following steps:
- Enable gRPC service
- Setup Sensor groups
- Verification
To enable the gRPC service, the configuration is displayed next:
!
grpc
vrf MGMT
port 57400
no-tls
address-family dual
!
The options are straightforward, including the VRF, and the TCP port. By default, gRPC uses TLS but it can be disabled with no-tls keyword. Finally, the address-family dual option allows connection using IPv4 and IPv6.
Next, Dial-in requires the definition of sensor-groups locally, that would be used by the collector later to define a subscription.
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
!
!
At this, point the configuration for Dial-In mode, is complete, and the collector itself can make a subscription to the router using gRPC. For verification, you can make the same approach as in dial-out mode:
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#
Tip: Note that no cadence, encoding, collector IP or transport is hardcoded on the router for dial-in mode.
SNMP Migration to MDT
In order to accomplish the migration from traditional SNMP into Telemetry model, the following aspects should be covered:
- MIB migration into XPATH
- Trap migration into Telemetry
- Security considerations
MIB migration into XPATH
For this purpose, we could categorize MIB using its own hierarchy which could be mapped (at least on high level) to a particular functionality.
BGP4-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to BGP peering sessions.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
bgpPeerLastError |
1.3.6.1.2.1.15.3.1.14 |
The last error code and subcode seen by this peer on this connection. If no error has occurred, this field is zero. Otherwise, the first byte of this two byte OCTET STRING contains the error code, and the second byte contains the subcode. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/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 |
The number of BGP UPDATE messages transmitted on this connection. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/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 |
The number of BGP UPDATE messages received on this connection. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/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 |
The negotiated version of BGP running between the two peers. This entry MUST be zero (0) unless the bgpPeerState is in the openconfirm or the established state. Note that legal values for this object are between 0 and 255. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/negotiated-protocol-version |
|
bgpPeerState |
1.3.6.1.2.1.15.3.1.2 |
The BGP peer connection state. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-state |
|
bgpPeerRemoteAddr |
1.3.6.1.2.1.15.3.1.7 |
The remote IP address of this entry's BGP peer. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-remote-address |
|
bgpPeerLocalAddr |
1.3.6.1.2.1.15.3.1.5 |
The local IP address of this entry's BGP connection. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-local-address |
|
bgpPeerFsmEstablishedTime |
1.3.6.1.2.1.15.3.1.16 |
This timer indicates how long (in seconds) this peer has been in the established state or how long since this peer was last in the established state. It is set to zero when a new peer is configured or when the router is booted. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-established-time |
|
bgpPeerAdminStatus |
1.3.6.1.2.1.15.3.1.3 |
The desired state of the BGP connection. A transition from 'stop' to 'start' will cause the BGP Manual Start Event to be generated. A transition from 'start' to 'stop' will cause the BGP Manual Stop Event to be generated. This parameter can be used to restart BGP peer connections. Care should be used in providing write access to this object without adequate authentication. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-admin-status |
CISCO-BGP4-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to BGP session state and prefix interchanged.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
cbgpPeer2RemoteAs |
1.3.6.1.4.1.9.9.187.1.2.5.1.11 |
The remote autonomous system number received in the BGP OPEN message. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/sessions/session/remote-as |
|
cbgpPeer2PrevState |
1.3.6.1.4.1.9.9.187.1.2.5.1.29 |
The BGP peer connection previous state. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/previous-connection-state |
|
cbgpPeer2State |
1.3.6.1.4.1.9.9.187.1.2.5.1.3 |
The BGP peer connection state. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-state |
|
cbgpPeer2LocalAddr |
1.3.6.1.4.1.9.9.187.1.2.5.1.6 |
The local IP address of this entry's BGP connection. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/connection-local-address |
|
cbgpPeer2AdvertisedPrefixes |
1.3.6.1.4.1.9.9.187.1.2.8.1.6 |
This counter is incremented when a route prefix, which belongs to an address family is advertised on this connection. It is initialized to zero when the connection is undergone a hard reset. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/neighbor-af-table/neighbor/af-data/prefixes-advertised |
|
cbgpPeer2AcceptedPrefixes |
1.3.6.1.4.1.9.9.187.1.2.8.1.1 |
Number of accepted route prefixes on this connection, which belong to an address family. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/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 number of route prefixes accepted on this connection |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/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 |
Prefix threshold value (%) for an address family on this connection at which warning message stating the prefix count is crossed the threshold or corresponding SNMP notification is generated. |
Cisco-IOS-XR-ipv4-bgp-oper:bgp/config-instances/config-instance/config-instance-default-vrf/entity-configurations/entity-configuration/af-dependent-config/max-prefix-warn-threshold |
CISCO-CLASS-BASED-QOS-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to statistics in Quality of Service (QoS) classes/policies.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
cbQosCMDropBitRate |
1.3.6.1.4.1.9.9.166.1.15.1.1.18 |
The bit rate of the drops per class as the result of all features that can produce drops (e.g., police, random detect, etc.). |
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 |
|
cbQosCMDropPkt64 |
1.3.6.1.4.1.9.9.166.1.15.1.1.14 |
The 64 bits counter of dropped pkts per class as the result of all features that can produce drops (e.g., police, random detect, etc.). |
Cisco-IOS-XR-qos-ma-oper:qos/interface-table/interface/input/service-policy-names/service-policy-instance/statistics/class-stats/general-stats/total-drop-packets |
|
cbQosCMPrePolicyPkt64 |
1.3.6.1.4.1.9.9.166.1.15.1.1.3 |
The 64 bits count of inbound packets prior to executing any QoS policies. |
Cisco-IOS-XR-qos-ma-oper:qos/interface-table/interface/input/service-policy-names/service-policy-instance/statistics/class-stats/general-stats/pre-policy-matched-packets |
|
cbQosCMName |
1.3.6.1.4.1.9.9.166.1.7.1.1.1 |
Name of the Classmap. |
Cisco-IOS-XR-qos-ma-oper:qos/interface-table/interface/input/service-policy-names/service-policy-instance/statistics/class-stats/class-name |
|
cbQosCMPostPolicyByte64 |
1.3.6.1.4.1.9.9.166.1.15.1.1.10 |
The 64 bits count of outbound octets after executing QoS policies. |
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/transmit-bytes |
|
cbQosIfIndex |
1.3.6.1.4.1.9.9.166.1.1.1.1.4 |
ifIndex for the interface to which this service is attached. This field makes sense only if the logical interface has a snmp ifIndex. For e.g. the value of this field is meaningless when the cbQosIfType is controlPlane. |
Cisco-IOS-XR-infra-policymgr-oper:policy-manager/global/policy-map/policy-map-types/policy-map-type/policy-maps |
|
cbQosConfigIndex |
1.3.6.1.4.1.9.9.166.1.5.1.1.2 |
An arbitrary (system-assigned) config (instance independent) index for each Object. Each objects having the same configuration share the same config index. |
Cisco-IOS-XR-infra-policymgr-oper:policy-manager/global/policy-map/policy-map-types/policy-map-type/policy-maps |
|
cbQosCMPrePolicyByte64 |
1.3.6.1.4.1.9.9.166.1.15.1.1.6 |
The 64 bits count of inbound octets prior to executing any QoS policies. |
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-matched-bytes |
CISCO-ENHANCED-MEMPOOL-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to the memory usage.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
cempMemPoolUsed |
1.3.6.1.4.1.9.9.221.1.1.1.1.7 |
Indicates the number of bytes from the memory pool that are currently in use by applications on the physical entity. |
Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/summary |
|
cempMemPoolHCUsed |
1.3.6.1.4.1.9.9.221.1.1.1.1.18 |
Indicates the number of bytes from the memory pool that are currently in use by applications on the physical entity. This object is a 64-bit version of cempMemPoolUsed. |
Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/detail/total-used |
|
cempMemPoolHCFree |
1.3.6.1.4.1.9.9.221.1.1.1.1.20 |
Indicates the number of bytes from the memory pool that are currently unused on the physical entity. This object is a 64-bit version of cempMemPoolFree. |
Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/detail/free-physical-memory |
CISCO-ENTITY-FRU-CONTROL-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to the field replaceable units on the monitored system.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
cefcFRUPowerOperStatus |
1.3.6.1.4.1.9.9.117.1.1.2.1.2 |
Operational FRU power state. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/fru-info/power-operational-state |
|
cefcFRUPowerAdminStatus |
1.3.6.1.4.1.9.9.117.1.1.2.1.1 |
Administratively desired FRU power state. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/fru-info/power-administrative-state |
|
cefcModuleStatusLastChangeTime |
1.3.6.1.4.1.9.9.117.1.2.1.1.4 |
The value of sysUpTime at the time the cefcModuleOperStatus is changed. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/fru-info/last-operational-state-change |
|
cefcModuleUpTime |
1.3.6.1.4.1.9.9.117.1.2.1.1.8 |
This object provides the up time for the module since it was last re-initialized. This object is not persistent; if a module reset, restart, power off, the up time starts from zero. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/fru-info/card-up-time |
|
cefcModuleResetReason |
1.3.6.1.4.1.9.9.117.1.2.1.1.3 |
This object identifies the reason for the last reset performed on the module. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/fru-info/card-reset-reason |
|
cefcModuleOperStatus |
1.3.6.1.4.1.9.9.117.1.2.1.1.2 |
This object shows the module's operational state. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/fru-info/card-operational-state |
|
cefcModuleAdminStatus |
1.3.6.1.4.1.9.9.117.1.2.1.1.1 |
This object provides administrative control of the module. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/fru-info/card-administrative-state |
CISCO-ENTITY-SENSOR-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to sensor entities on the node.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
entSensorValue |
1.3.6.1.4.1.9.9.91.1.1.1.1.4 |
This variable reports the most recent measurement seen by the sensor. To correctly display or interpret this variable's value, you must also know entSensorType, entSensorScale, and entSensorPrecision. However, you can compare entSensorValue with the threshold values given in entSensorThresholdTable without any semantic knowledge. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/env-sensor-info/value |
|
entSensorThresholdEvaluation |
1.3.6.1.4.1.9.9.91.1.2.1.1.5 |
This variable indicates the result of the most recent evaluation of the threshold. If the threshold condition is true, entSensorThresholdEvaluation is true(1). If the threshold condition is false, entSensorThresholdEvaluation is false(2). Thresholds are evaluated at the rate indicated by entSensorValueUpdateRate. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/threshold |
CISCO-FLASH-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to flash storage on the system.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
ciscoFlashPartitionName |
1.3.6.1.4.1.9.9.10.1.1.4.1.1.10 |
Flash partition name used to refer to a partition by the system. This can be any alpha-numeric character string of the form AAAAAAAAnn, where A represents an optional alpha character and n a numeric character. Any numeric characters must always form the trailing part of the string. The system will strip off the alpha characters and use the numeric portion to map to a partition index. Flash operations get directed to a device partition based on this name. The system has a concept of a default partition. This would be the first partition in the device. The system directs an operation to the default partition whenever a partition name is not specified. The partition name is therefore mandatory except when the operation is being done on the default partition, or the device has just one partition (is not partitioned). |
Cisco-IOS-XR-shellutil-filesystem-oper:file-system/node/file-system/type |
|
ciscoFlashPartitionSizeExtended |
1.3.6.1.4.1.9.9.10.1.1.4.1.1.13 |
Flash partition size. It should be an integral multiple of ciscoFlashDeviceMinPartitionSize. If there is a single partition, this size will be equal to ciscoFlashDeviceSize. This object is a 64-bit version of ciscoFlashPartitionSize |
Cisco-IOS-XR-shellutil-filesystem-oper:file-system/node/file-system/size |
|
ciscoFlashPartitionFreeSpaceExtended |
1.3.6.1.4.1.9.9.10.1.1.4.1.1.14 |
Free space within a Flash partition. Note that the actual size of a file in Flash includes a small overhead that represents the file system's file header. Certain file systems may also have a partition or device header overhead to be considered when computing the free space. Free space will be computed as total partition size less size of all existing files (valid/invalid/deleted files and including file header of each file), less size of any partition header, less size of header of next file to be copied in. In short, this object will give the size of the largest file that can be copied in. The management entity will not be expected to know or use any overheads such as file and partition header lengths, since such overheads may vary from file system to file system. Deleted files in Flash do not free up space. A partition may have to be erased in order to reclaim the space occupied by files. This object is a 64-bit version of ciscoFlashPartitionFreeSpace |
Cisco-IOS-XR-shellutil-filesystem-oper:file-system/node/file-system/free |
CISCO-PROCESS-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related CPU Usage and resource allocation for processes.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
cpmCPUTotal1minRev |
1.3.6.1.4.1.9.9.109.1.1.1.1.7 |
The overall CPU busy percentage in the last 1 minute period. This object deprecates the object cpmCPUTotal1min and increases the value range to (0..100). |
Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization/total-cpu-one-minute |
|
cpmCPUTotal5minRev |
1.3.6.1.4.1.9.9.109.1.1.1.1.8 |
The overall CPU busy percentage in the last 5 minute period. This object deprecates the object cpmCPUTotal5min and increases the value range to (0..100). |
Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization/total-cpu-five-minute |
|
cpmCPUTotal15minRev |
1.3.6.1.4.1.9.9.109.1.1.1.1.31 |
The overall CPU busy percentage in the last 15 minute period. This object deprecates the object cpmCPUTotal15min and increases the value range to (0..100). |
Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization/total-cpu-fifteen-minute |
|
cpmProcessName |
1.3.6.1.4.1.9.9.109.1.2.1.1.2 |
The name associated with this process. If the name is longer than 32 characters, it will be truncated to the first 31 characters, and a `*' will be appended as the last character to imply this is a truncated process name. |
Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization/process-cpu/process-name |
|
cpmProcessTextSegmentSize |
1.3.6.1.4.1.9.9.109.1.2.3.1.15 |
This indicates the text memory of a process and all its shared objects. |
Cisco-IOS-XR-procmem-oper:processes-memory/nodes/node/process-ids/process-id/text-seg-size |
|
cpmProcessDynamicMemorySize |
1.3.6.1.4.1.9.9.109.1.2.3.1.18 |
This indicates the amount of dynamic memory being used by the process. |
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 |
This indicates the data segment of a process and all its shared objects. |
Cisco-IOS-XR-procmem-oper:processes-memory/nodes/node/process-ids/process-id/data-seg-size |
|
cpmProcExtMemAllocatedRev |
1.3.6.1.4.1.9.9.109.1.2.3.1.1 |
The sum of all the dynamically allocated memory that this process has received from the system. This includes memory that may have been returned. The sum of freed memory is provided by cpmProcExtMemFreedRev. This object deprecates cpmProcExtMemAllocated. |
Cisco-IOS-XR-procmem-oper:processes-memory/nodes/node/process-ids/process-id |
|
cpmProcExtMemFreedRev |
1.3.6.1.4.1.9.9.109.1.2.3.1.2 |
The sum of all memory that this process has returned to the system. This object deprecates cpmProcExtMemFreed. |
Cisco-IOS-XR-procmem-oper:processes-memory/nodes/node/process-ids/process-id |
ENTITY-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related physical entities on the system.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
entPhysicalName |
1.3.6.1.2.1.47.1.1.1.1.7 |
The textual name of the physical entity. The value of this object should be the name of the component as assigned by the local device and should be suitable for use in commands entered at the device's `console'. This might be a text name, such as `console' or a simple component number (e.g., port or module number), such as `1', depending on the physical component naming syntax of the device. If there is no local name, or this object is otherwise not applicable, then this object contains a zero-length string. Note that the value of entPhysicalName for two physical entities will be the same in the event that the console interface does not distinguish between them, e.g., slot-1 and the card in slot-1. |
Cisco-IOS-XR-snmp-entitymib-oper:entity-physical-index |
|
entLogicalDescr |
1.3.6.1.2.1.47.1.2.1.1.2 |
A textual description of the logical entity. This object should contain a string which identifies the manufacturer's name for the logical entity, and should be set to a distinct value for each version of the logical entity. |
Cisco-IOS-XR-snmp-agent-oper:snmp/information/system-name/ |
|
entPhysicalDescr |
1.3.6.1.2.1.47.1.1.1.1.2 |
A textual description of physical entity. This object should contain a string which identifies the manufacturer's name for the physical entity, and should be set to a distinct value for each version or model of the physical entity. |
Cisco-IOS-XR-snmp-agent-oper:snmp/Cisco-IOS-XR-snmp-entitymib-oper:entity-mib/entity-physical-indexes/ |
|
entPhysicalContainedIn |
1.3.6.1.2.1.47.1.1.1.1.4 |
The value of entPhysicalIndex for the physical entity which 'contains' this physical entity. A value of zero indicates this physical entity is not contained in any other physical entity. Note that the set of 'containment' relationships define a strict hierarchy; that is, recursion is not allowed. In the event a physical entity is contained by more than one physical entity (e.g., double-wide modules), this object should identify the containing entity with the lowest value of entPhysicalIndex. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/inv-basic-bag/unique-id |
|
entPhysicalClass |
1.3.6.1.2.1.47.1.1.1.1.5 |
An indication of the general hardware type of the physical entity. An agent should set this object to the standard enumeration value which most accurately indicates the general class of the physical entity, or the primary class if there is more than one. If no appropriate standard registration identifier exists for this physical entity, then the value 'other(1)' is returned. If the value is unknown by this agent, then the value 'unknown(2)' is returned. |
Cisco-IOS-XR-invmgr-oper:inventory/entities |
|
entPhysicalHardwareRev |
1.3.6.1.2.1.47.1.1.1.1.8 |
The vendor-specific hardware revision string for the physical entity. The preferred value is the hardware revision identifier actually printed on the component itself (if present). Note that if revision information is stored internally in a non-printable (e.g., binary) format, then the agent must convert such information to a printable format, in an implementation-specific manner. If no specific hardware revision string is associated with the physical component, or this information is unknown to the agent, then this object will contain a zero-length string. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/inv-basic-bag/hardware-revision |
|
entPhysicalFirmwareRev |
1.3.6.1.2.1.47.1.1.1.1.9 |
The vendor-specific firmware revision string for the physical entity. Note that if revision information is stored internally in a non-printable (e.g., binary) format, then the agent must convert such information to a printable format, in an implementation-specific manner. If no specific firmware programs are associated with the physical component, or this information is unknown to the agent, then this object will contain a zero-length string. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/inv-basic-bag/firmware-revision |
|
entPhysicalSoftwareRev |
1.3.6.1.2.1.47.1.1.1.1.10 |
The vendor-specific software revision string for the physical entity. Note that if revision information is stored internally in a non-printable (e.g., binary) format, then the agent must convert such information to a printable format, in an implementation-specific manner. If no specific software programs are associated with the physical component, or this information is unknown to the agent, then this object will contain a zero-length string. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/inv-basic-bag/software-revision |
|
entPhysicalSerialNum |
1.3.6.1.2.1.47.1.1.1.1.11 |
The vendor-specific serial number string for the physical entity. The preferred value is the serial number string actually printed on the component itself (if present). On the first instantiation of an physical entity, the value of entPhysicalSerialNum associated with that entity is set to the correct vendor-assigned serial number, if this information is available to the agent. If a serial number is unknown or non-existent, the entPhysicalSerialNum will be set to a zero-length string instead. Note that implementations which can correctly identify the serial numbers of all installed physical entities do not need to provide write access to the entPhysicalSerialNum object. Agents which cannot provide non-volatile storage for the entPhysicalSerialNum strings are not required to implement write access for this object. Not every physical component will have a serial number, or even need one. Physical entities for which the associated value of the entPhysicalIsFRU object is equal to 'false(2)' (e.g., the repeater ports within a repeater module), do not need their own unique serial number. An agent does not have to provide write access for such entities, and may return a zero-length string. If write access is implemented for an instance of entPhysicalSerialNum, and a value is written into the instance, the agent must retain the supplied value in the entPhysicalSerialNum instance associated with the same physical entity for as long as that entity remains instantiated. This includes instantiations across all re- initializations/reboots of the network management system, including those which result in a change of the physical entity's entPhysicalIndex value. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/inv-basic-bag/serial-number |
|
entPhysicalMfgName |
1.3.6.1.2.1.47.1.1.1.1.12 |
The name of the manufacturer of this physical component. The preferred value is the manufacturer name string actually printed on the component itself (if present). Note that comparisons between instances of the entPhysicalModelName, entPhysicalFirmwareRev, entPhysicalSoftwareRev, and the entPhysicalSerialNum objects, are only meaningful amongst entPhysicalEntries with the same value of entPhysicalMfgName. If the manufacturer name string associated with the physical component is unknown to the agent, then this object will contain a zero-length string. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/inv-basic-bag/manufacturer-name |
|
entPhysicalModelName |
1.3.6.1.2.1.47.1.1.1.1.13 |
The vendor-specific model name identifier string associated with this physical component. The preferred value is the customer-visible part number, which may be printed on the component itself. If the model name string associated with the physical component is unknown to the agent, then this object will contain a zero-length string. |
Cisco-IOS-XR-invmgr-oper:inventory/entities/entity/attributes/inv-basic-bag/model-name |
IF-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to interface characteristics and counters.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
ifMtu |
1.3.6.1.2.1.2.2.1.4 |
The size of the largest packet which can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/mtu |
|
ifPhysAddress |
1.3.6.1.2.1.2.2.1.6 |
The interface's address at its protocol sub-layer. For example, for an 802.x interface, this object normally contains a MAC address. The interface's media-specific MIB must define the bit and byte ordering and the format of the value of this object. For interfaces which do not have such an address (e.g., a serial line), this object should contain an octet string of zero length. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-type-information/bundle-information/member/mac-address |
|
ifType |
1.3.6.1.2.1.2.2.1.3 |
The type of interface. Additional values for ifType are assigned by the Internet Assigned Numbers Authority (IANA), through updating the syntax of the IANAifType textual convention. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-type |
|
ifOutUcastPkts |
1.3.6.1.2.1.2.2.1.17 |
The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/packets-sent |
|
ifHCOutUcastPkts |
1.3.6.1.2.1.31.1.1.1.11 |
The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. This object is a 64-bit version of ifOutUcastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/packets-sent |
|
ifInUcastPkts |
1.3.6.1.2.1.2.2.1.11 |
The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/packets-received |
|
ifHCInUcastPkts |
1.3.6.1.2.1.31.1.1.1.7 |
The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer. This object is a 64-bit version of ifInUcastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/packets-received |
|
ifOutErrors |
1.3.6.1.2.1.2.2.1.20 |
For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
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 |
The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/output-drops |
|
ifOutMulticastPkts |
1.3.6.1.2.1.31.1.1.1.4 |
The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast address at this sub-layer, including those that were discarded or not sent. For a MAC layer protocol, this includes both Group and Functional addresses. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/multicast-packets-sent |
|
ifHCOutMulticastPkts |
1.3.6.1.2.1.31.1.1.1.12 |
The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast address at this sub-layer, including those that were discarded or not sent. For a MAC layer protocol, this includes both Group and Functional addresses. This object is a 64-bit version of ifOutMulticastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/multicast-packets-sent |
|
ifInMulticastPkts |
1.3.6.1.2.1.31.1.1.1.2 |
The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/multicast-packets-received |
|
ifHCInMulticastPkts |
1.3.6.1.2.1.31.1.1.1.8 |
The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses. This object is a 64-bit version of ifInMulticastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/multicast-packets-received |
|
ifInErrors |
1.3.6.1.2.1.2.2.1.14 |
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. For character-oriented or fixed-length interfaces, the number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
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 |
The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/input-drops |
|
ifOutOctets |
1.3.6.1.2.1.2.2.1.16 |
The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/bytes-sent |
|
ifHCOutOctets |
1.3.6.1.2.1.31.1.1.1.10 |
The total number of octets transmitted out of the interface, including framing characters. This object is a 64-bit version of ifOutOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
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 |
The total number of octets received on the interface, including framing characters. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
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 |
The total number of octets received on the interface, including framing characters. This object is a 64-bit version of ifInOctets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/bytes-received |
|
ifOutBroadcastPkts |
1.3.6.1.2.1.31.1.1.1.5 |
The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/broadcast-packets-sent |
|
ifHCOutBroadcastPkts |
1.3.6.1.2.1.31.1.1.1.13 |
The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a broadcast address at this sub-layer, including those that were discarded or not sent. This object is a 64-bit version of ifOutBroadcastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/broadcast-packets-sent |
|
ifInBroadcastPkts |
1.3.6.1.2.1.31.1.1.1.3 |
The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/broadcast-packets-received |
|
ifHCInBroadcastPkts |
1.3.6.1.2.1.31.1.1.1.9 |
The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a broadcast address at this sub-layer. This object is a 64-bit version of ifInBroadcastPkts. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/broadcast-packets-received |
|
ifIndex |
1.3.6.1.2.1.2.2.1.1 |
A unique value, greater than zero, for each interface. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/if-index |
|
ifDescr |
1.3.6.1.2.1.2.2.1.2 |
A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the interface hardware/software. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/description |
|
ifSpeed |
1.3.6.1.2.1.2.2.1.5 |
An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth. If the bandwidth of the interface is greater than the maximum value reportable by this object then this object should report its maximum value (4,294,967,295) and ifHighSpeed must be used to report the interace's speed. For a sub-layer which has no concept of bandwidth, this object should be zero. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/bandwidth |
|
ifOperStatus |
1.3.6.1.2.1.2.2.1.8 |
The current operational state of the interface. The testing(3) state indicates that no operational packets can be passed. If ifAdminStatus is down(2) then ifOperStatus should be down(2). If ifAdminStatus is changed to up(1) then ifOperStatus should change to up(1) if the interface is ready to transmit and receive network traffic; it should change to dormant(5) if the interface is waiting for external actions (such as a serial line waiting for an incoming connection); it should remain in the down(2) state if and only if there is a fault that prevents it from going to the up(1) state; it should remain in the notPresent(6) state if the interface has missing (typically, hardware) components. |
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 |
The desired state of the interface. The testing(3) state indicates that no operational packets can be passed. When a managed system initializes, all interfaces start with ifAdminStatus in the down(2) state. As a result of either explicit management action or per configuration information retained by the managed system, ifAdminStatus is then changed to either the up(1) or testing(3) states (or remains in the down(2) state). |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-non-dynamics/interface-non-dynamic/admin-state |
|
ifName |
1.3.6.1.2.1.31.1.1.1.1 |
The textual name of the interface. The value of this object should be the name of the interface as assigned by the local device and should be suitable for use in commands entered at the device's `console'. This might be a text name, such as `le0' or a simple port number, such as `1', depending on the interface naming syntax of the device. If several entries in the ifTable together represent a single interface as named by the device, then each will have the same value of ifName. Note that for an agent which responds to SNMP queries concerning an interface on some other (proxied) device, then the value of ifName for such an interface is the proxied device's local name for it. If there is no local name, or this object is otherwise not applicable, then this object contains a zero- length string. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-briefs/interface-brief/interface-name |
|
ifHighSpeed |
1.3.6.1.2.1.31.1.1.1.15 |
An estimate of the interface's current bandwidth in units of 1,000,000 bits per second. If this object reports a value of `n' then the speed of the interface is somewhere in the range of `n-500,000' to `n+499,999'. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth. For a sub-layer which has no concept of bandwidth, this object should be zero. |
Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-briefs/interface-brief/bandwidth64-bit |
IP-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to Internet Protocol (IP) statistics and operational values.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
icmpInDestUnreachs |
1.3.6.1.2.1.5.3 |
The number of ICMP Destination Unreachable messages received. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpInParmProbs |
1.3.6.1.2.1.5.5 |
The number of ICMP Parameter Problem messages received. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpInSrcQuenchs |
1.3.6.1.2.1.5.6 |
The number of ICMP Source Quench messages received. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpInEchos |
1.3.6.1.2.1.5.8 |
The number of ICMP Echo (request) messages received. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpInEchoReps |
1.3.6.1.2.1.5.9 |
The number of ICMP Echo Reply messages received. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpInTimestamps |
1.3.6.1.2.1.5.10 |
The number of ICMP Timestamp (request) messages received. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpInAddrMasks |
1.3.6.1.2.1.5.12 |
The number of ICMP Address Mask Request messages received. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpInAddrMaskReps |
1.3.6.1.2.1.5.13 |
The number of ICMP Address Mask Reply messages received. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutMsgs |
1.3.6.1.2.1.5.14 |
The total number of ICMP messages which this entity attempted to send. Note that this counter includes all those counted by icmpOutErrors. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutDestUnreachs |
1.3.6.1.2.1.5.16 |
The number of ICMP Destination Unreachable messages sent. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutTimeExcds |
1.3.6.1.2.1.5.17 |
The number of ICMP Time Exceeded messages sent. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutParmProbs |
1.3.6.1.2.1.5.18 |
The number of ICMP Parameter Problem messages sent. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutSrcQuenchs |
1.3.6.1.2.1.5.19 |
The number of ICMP Source Quench messages sent. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutRedirects |
1.3.6.1.2.1.5.20 |
The number of ICMP Redirect messages sent. For a host, this object will always be zero, since hosts do not send redirects. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutEchos |
1.3.6.1.2.1.5.21 |
The number of ICMP Echo (request) messages sent. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutEchoReps |
1.3.6.1.2.1.5.22 |
The number of ICMP Echo Reply messages sent. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutTimestamps |
1.3.6.1.2.1.5.23 |
The number of ICMP Timestamp (request) messages sent. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutAddrMasks |
1.3.6.1.2.1.5.25 |
The number of ICMP Address Mask Request messages sent. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
icmpOutAddrMaskReps |
1.3.6.1.2.1.5.26 |
The number of ICMP Address Mask Reply messages sent. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/icmp-stats |
|
ipAdEntIfIndex |
1.3.6.1.2.1.4.20.1.2 |
The index value which uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of RFC 1573's ifIndex. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/ |
|
ipAdEntAddr |
1.3.6.1.2.1.4.20.1.1 |
The IP address to which this entry's addressing information pertains. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/interfaces/interface/vrfs/vrf/detail/primary-address |
|
ipAdEntNetMask |
1.3.6.1.2.1.4.20.1.3 |
The subnet mask associated with the IP address of this entry. The value of the mask is an IP address with all the network bits set to 1 and all the hosts bits set to 0. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/interfaces/interface/vrfs/vrf/detail/prefix-length |
|
ipAdEntBcastAddr |
1.3.6.1.2.1.4.20.1.4 |
The value of the least-significant bit in the IP broadcast address used for sending datagrams on the (logical) interface associated with the IP address of this entry. For example, when the Internet standard all-ones broadcast address is used, the value will be 1. This value applies to both the subnet and network broadcasts addresses used by the entity on this (logical) interface. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/interfaces/interface/vrfs/vrf/detail/direct-broadcast |
|
ipNetToMediaPhysAddress |
1.3.6.1.2.1.4.22.1.2 |
The media-dependent `physical' address. |
Cisco-IOS-XR-ipv4-arp-oper:arp/nodes/node/entries/entry/hardware-address |
IPMIB-COMMMON
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to IP statistics.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
ipIfStatsHCOutTransmits |
1.3.6.1.2.1.4.31.3.1.31 |
The total number of IP datagrams that this entity supplied to the lower layers for transmission. This object counts the same datagrams as ipIfStatsOutTransmits but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/ipv4-stats/packets-forwarded |
|
ipIfStatsInReceives |
1.3.6.1.2.1.4.31.3.1.3 |
The total number of input IP datagrams received, including those received in error. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/ipv4-stats/input-packets |
|
ipIfStatsHCInReceives |
1.3.6.1.2.1.4.31.3.1.4 |
The total number of input IP datagrams received, including those received in error. This object counts the same datagrams as ipIfStatsInReceives but allows for larger values. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime. |
Cisco-IOS-XR-ipv4-io-oper:ipv4-network/nodes/node/statistics/traffic/ipv4-stats/input-packets |
LLDP-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to Link Layer Discovery Protocol (LLDP) operational data on the monitored node.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
lldpLocPortId |
1.0.8802.1.1.2.1.3.7.1.3 |
The string value used to identify the port component associated with a given port in the local system. |
Cisco-IOS-XR-ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/port-id-detail |
|
lldpLocPortIdSubtype |
1.0.8802.1.1.2.1.3.7.1.2 |
The type of port identifier encoding used in the associated 'lldpLocPortId' object. |
Cisco-IOS-XR-ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/mib/port-id-sub-type |
|
lldpLocChassisIdSubtype |
1.0.8802.1.1.2.1.3.1 |
The type of encoding used to identify the chassis associated with the local system. |
Cisco-IOS-XR-ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/mib/chassis-id-sub-type |
|
lldpLocSysName |
1.0.8802.1.1.2.1.3.3 |
The string value used to identify the system name of the local system. If the local agent supports IETF RFC 3418, lldpLocSysName object should have the same value of sysName object. |
Cisco-IOS-XR-ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/detail/system-name |
|
lldpRemSysName |
1.0.8802.1.1.2.1.4.1.1.9 |
The string value used to identify the system name of the remote system. |
Cisco-IOS-XR-ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/detail/system-name |
|
lldpRemChassisId |
1.0.8802.1.1.2.1.4.1.1.5 |
The string value used to identify the chassis component associated with the remote system. |
Cisco-IOS-XR-ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor/chassis-id |
|
lldpRemChassisIdSubtype |
1.0.8802.1.1.2.1.4.1.1.4 |
The type of encoding used to identify the chassis associated with the remote system. |
Cisco-IOS-XR-ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor |
|
lldpRemPortIdSubtype |
1.0.8802.1.1.2.1.4.1.1.6 |
The type of port identifier encoding used in the associated 'lldpRemPortId' object. |
Cisco-IOS-XR-ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor |
|
lldpRemPortId |
1.0.8802.1.1.2.1.4.1.1.7 |
The string value used to identify the port component associated with the remote system. |
Cisco-IOS-XR-ethernet-lldp-oper:lldp/nodes/node/neighbors/devices/device/lldp-neighbor |
|
lldpLocChassisId |
1.0.8802.1.1.2.1.3.2 |
The string value used to identify the chassis component associated with the local system. |
Cisco-IOS-XR-ethernet-lldp-oper:lldp/nodes/node/neighbors/details/detail/lldp-neighbor/chassis-id |
MPLS-TE-STD-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to Multiprotocol Label Switching (MPLS) Traffic Engineering operational values on the managed device.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
mplsTunnelName |
1.3.6.1.2.1.10.166.3.2.2.1.5 |
The canonical name assigned to the tunnel. This name can be used to refer to the tunnel on the LSR's console port. If mplsTunnelIsIf is set to true then the ifName of the interface corresponding to this tunnel should have a value equal to mplsTunnelName. Also see the description of ifName in RFC 2863. |
Cisco-IOS-XR-mpls-te-oper:mpls-te/p2p-p2mp-tunnel/tunnel-heads/tunnel-head/tunnel-name |
|
mplsTunnelDescr |
1.3.6.1.2.1.10.166.3.2.2.1.6 |
A textual string containing information about the tunnel. If there is no description this object contains a zero length string. This object is may not be signaled by MPLS signaling protocols, consequentally the value of this object at transit and egress LSRs MAY be automatically generated or absent. |
openconfig-network-instance:network-instances/network-instance/mpls/lsps/constrained-path/tunnels/tunnel/state/description |
|
mplsTunnelPerfHCPackets |
1.3.6.1.2.1.10.166.3.2.9.1.2 |
High capacity counter for number of packets forwarded by the tunnel. |
openconfig-network-instance:network-instances/network-instance/mpls/lsps/constrained-path/tunnels/tunnel/state/counters/packets |
|
mplsTunnelPerfHCBytes |
1.3.6.1.2.1.10.166.3.2.9.1.5 |
High capacity counter for number of bytes forwarded by the tunnel. |
openconfig-network-instance:network-instances/network-instance/mpls/lsps/constrained-path/tunnels/tunnel/state/counters/bytes |
|
mplsTunnelHopIpAddr |
1.3.6.1.2.1.10.166.3.2.4.1.5 |
The Tunnel Hop Address for this tunnel hop. The type of this address is determined by the value of the corresponding mplsTunnelHopAddrType. The value of this object cannot be changed if the value of the corresponding mplsTunnelHopRowStatus object is 'active'. |
Cisco-IOS-XR-mpls-te-oper:mpls-te/p2p-p2mp-tunnel/tunnel-heads/tunnel-head/destination/destination-address |
RFC2465-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to IPv6 global values.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
ipv6AddrPfxLength |
1.3.6.1.2.1.55.1.8.1.2 |
The length of the prefix (in bits) associated with the IPv6 address of this entry. |
Cisco-IOS-XR-ipv6-ma-oper:ipv6-network/nodes/node/interface-data/vrfs/vrf/briefs/brief/address/prefix-length |
|
ipv6AddrAnycastFlag |
1.3.6.1.2.1.55.1.8.1.4 |
This object has the value 'true(1)', if this address is an anycast address and the value 'false(2)' otherwise. |
Cisco-IOS-XR-ipv6-ma-oper:ipv6-network/nodes/node/interface-data/vrfs/vrf/briefs/brief/address/is-anycast |
SNMP-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to the SNMP agent itself if available.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
sysUpTime |
1.3.6.1.2.1.1.3 |
String representing the system Uptime |
Cisco-IOS-XR-snmp-agent-oper:snmp/information/system-up-time/ |
|
sysObjectID |
.1.3.6.1.2.1.1.2.0 |
String representing the system OID |
Cisco-IOS-XR-snmp-agent-oper:snmp/information/system-oid/ |
|
sysDescr |
1.3.6.1.2.1.1.1 |
String representing the system description |
Cisco-IOS-XR-snmp-agent-oper:snmp/information/system-descr |
TCP-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to TCP specific counters.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
tcpInErrs |
1.3.6.1.2.1.6.14 |
The total number of segments received in error (e.g., bad TCP checksums). |
Cisco-IOS-XR-ip-tcp-oper:tcp/nodes/node/statistics/ipv4-traffic/tcp-checksum-error-packets |
|
tcpInSegs |
1.3.6.1.2.1.6.10 |
The total number of segments received, including those received in error. This count includes segments received on currently established connections. |
Cisco-IOS-XR-ip-tcp-oper:tcp/nodes/node/statistics/ipv4-traffic/tcp-input-packets |
|
tcpOutSegs |
1.3.6.1.2.1.6.11 |
The total number of segments sent, including those on current connections but excluding those containing only retransmitted octets. |
Cisco-IOS-XR-ip-tcp-oper:tcp/nodes/node/statistics/ipv4-traffic/tcp-output-packets |
UDP-MIB
The next table represents the OID name and number and the correspondent XPATH to be setup on model-driven telemetry sensor-groups related to UDP specific counters.
|
OID Name |
OID Number |
OID Description |
XPATH |
|
udpOutDatagrams |
1.3.6.1.2.1.7.4 |
The total number of UDP datagrams sent from this entity. |
Cisco-IOS-XR-ip-udp-oper:/udp/nodes/node/statistics/ipv4-traffic/udp-output-packets |
|
udpNoPorts |
1.3.6.1.2.1.7.2 |
The total number of received UDP datagrams for which there was no application at the destination port. |
Cisco-IOS-XR-ip-udp-oper:/udp/nodes/node/statistics/ipv4-traffic/udp-no-ports-packets |
|
udpInErrors |
1.3.6.1.2.1.7.3 |
The number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port. |
Cisco-IOS-XR-ip-udp-oper:/udp/nodes/node/statistics/ipv4-traffic/udp-checksum-error-packets |
|
udpInDatagrams |
1.3.6.1.2.1.7.1 |
The total number of UDP datagrams delivered to UDP users. |
Cisco-IOS-XR-ip-udp-oper:/udp/nodes/node/statistics/ipv4-traffic/udp-input-packets |
SNMP Traps migration
SNMP traps are messages triggered by dynamic events on the managed device. Therefore, these messages behave analogous to the concept of EDT that we covered before.
Configuration side, MDT allows the same structure for EDT, which depends on the implementation on the telemetry collector in terms of Dial-In or Dial-Out choice or capabilities.
Security considerations
SNMPv2 uses only community as an authentication/authorization mechanism. However, SNMPv3 as we covered before on SNMP section, could use credentials for authentication and AES encryption model for protecting the information.
In Telemetry approach, IOS XR allows for the usage of gRPC/TLS techniques based on certificates to perform authentication. These certificates could be used with a central point of trust (a CA server for example). After the process of building a trust relationship, all telemetry messages are sent inside a gRPC session which is encrypted with TLS accomplishing the same benefits of SNMPv3.
Revision History
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
16-Mar-2021 |
Initial Release |
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)