Table 1. Feature History Table
Feature Name
|
Release Information
|
Description
|
Stream Digital Optical Monitoring (DOM) Data
|
Release 7.3.1
|
This feature streams fiber optic transceiver parameters such as optical input or output levels, temperature, laser bias current,
supply voltage, receiver power, bias threshold in real-time. This helps network operators to easily locate a fiber link failure,
thereby simplifying the maintenance process, and improving overall system reliability.
Sensor paths introduced for this feature are:
Cisco-IOS-XR-dwdm-ui-oper:dwdm/ports/port/info/optics-info
Cisco-IOS-XR-controller-optics-oper:optics-oper/optics-ports/optics-port/optics-info
|
The sensor path describes a YANG path or a subset of data definitions in a YANG data model within a container. In a YANG model,
the sensor path can be specified to end at any level in the container hierarchy.
A YANG module defines a data model through the data of the router, and the hierarchical organization and constraints on that
data.
YANG defines four node types. Each node has a name. Depending on the node type, the node either defines a value or contains
a set of child nodes. The nodes types for data modeling are:
-
leaf node - contains a single value of a specific type
-
leaf-list node - contains a sequence of leaf nodes
-
list node - contains a sequence of leaf-list entries, each of which is uniquely identified by one or more key leaves
-
container node - contains a grouping of related nodes that have only child nodes, which can be any of the four node types
For more information about data models, see the
Programmability Configuration Guide for Cisco NCS 560 Series Routers.
The following table shows few examples of sensor paths:
Table 2. Sensor Paths
Feature
|
Sensor Path
|
CPU
|
Cisco-IOS-XR-wdsysmon-fd-oper:system-monitoring/cpu-utilization
|
Memory
|
Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/summary
|
Interface
|
Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate
openconfig-interfaces:interfaces/interface
|
Optical power levels
|
Cisco-IOS-XR-dwdm-ui-oper:dwdm/ports/port/info/optics-info
Cisco-IOS-XR-controller-optics-oper:optics-oper/optics-ports/optics-port/optics-info
|
Node summary
|
Cisco-IOS-XR-nto-misc-oper:memory-summary/nodes/node/summary
|
Forwarding information base (FIB)
|
Cisco-IOS-XR-fib-common-oper:fib-statistics/nodes/node/drops
Cisco-IOS-XR-fib-common-oper:fib/nodes/node/protocols/protocol/vrfs/vrf/summary
|
MPLS Traffic engineering (MPLS-TE)
|
Cisco-IOS-XR-mpls-te-oper:mpls-te/tunnels/summary
Cisco-IOS-XR-ip-rsvp-oper:rsvp/interface-briefs/interface-brief
Cisco-IOS-XR-mpls-te-oper:mpls-te/fast-reroute/protections/protection
Cisco-IOS-XR-mpls-te-oper:mpls-te/signalling-counters/signalling-summary
Cisco-IOS-XR-mpls-te-oper:mpls-te/p2p-p2mp-tunnel/tunnel-heads/tunnel-head
|
MPLS Label distribution protocol (MPLS-LDP)
|
Cisco-IOS-XR-mpls-ldp-oper:mpls-ldp/nodes/node/bindings-summary-all
Cisco-IOS-XR-mpls-ldp-oper:mpls-ldp/global/active/default-vrf/summary
Cisco-IOS-XR-mpls-ldp-oper:mpls-ldp/nodes/node/default-vrf/neighbors/neighbor
|
Routing
|
Cisco-IOS-XR-clns-isis-oper:isis/instances/instance/statistics-global
Cisco-IOS-XR-clns-isis-oper:isis/instances/instance/neighbors/neighbor
Cisco-IOS-XR-ip-rib-ipv4-oper:rib/rib-table-ids/rib-table-id/summary-protos/summary-proto
Cisco-IOS-XR-clns-isis-oper:isis/instances/instance/levels/level/adjacencies/adjacency
Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/process-info
Cisco-IOS-XR-ip-rib-ipv6-oper:ipv6-rib/rib-table-ids/rib-table-id/summary-protos/summary-proto
|
Note |
Use specific paths to avoid streaming data that you may not be interested. For example, if you want to stream information
about only the summary of MPLS-TE, use sensor-path Cisco-IOS-XR-mpls-te-oper:mpls-te/autotunnel/mesh/summary instead of sensor-path Cisco-IOS-XR-mpls-te-oper:mpls-te sensor path.
|
The router streams telemetry data at predefined gather points in the data model even if sensor-path configuration is to an
individual leaf. The gather points are collection units; collection always happens at that level for operational data.
Starting from release 7.2.1, the router supports the following sensor-path resolutions:
-
Streaming data at the leaf-level or at the container-level under a gather point for cadence-based subscriptions.
If a subscritpion has multiple sensor-paths that resolve to the same gather point and have the same cadence and encoding,
data is pushed in a single collection stream for all the leaves. For example:
telemetry model-driven
sensor-group intf-stats
sensor-path Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/bytes-sent
sensor-path Cisco-IOS-XR-pfi-im-cmd-oper:interfaces/interface-xr/interface/interface-statistics/full-interface-stats/bytes-received
!
subscription intf-stats
sensor-group-id intf-stats sample-interval 10000
!
!
end
This subscription pushes one message with two leaves because the gather point full-interface-stats
is same for both the sensor-paths bytes-sent
and bytes-received
. This grouping of the leaves happens at the subscription level. If these paths are configured under different subscriptions,
data is streamed as different collections with separate messages each including one leaf bytes-sent
or bytes-received
.
-
For event-driven subscriptions, streaming is always at the gather point in the model, even if specific leaves or leaf is configured
as sensor-path. There is configuration to restrict streaming specific leaves for event-driven subscriptions. If this configuration
is used, the sensor-path of the configured leaf streams data even if there is a change in one of its adjacent leaves. This
indicates that even if there is no change in value of the configured leaf, data can stream out to the collector. The collector
must be set to check if the leaf value changed before taking action on the streamed data.
telemetry model-driven
include select-leaves-on-events
Note |
It is not recommended to configure sensor-paths with the same gather point into different subscriptions.
|
An MDT-capable device, such as a router, associates the sensor path to the nearest container path in the model. The router
encodes and streams the container path within a single telemetry message. A receiver receives data about all the containers
and leaf nodes at and below this container path. The router streams telemetry data, for one or more sensor-paths, at the configured
frequency (Cadence-driven Telemetry), or when an event occurs (Event-driven Telemetry), to one or more collectors through subscribed sessions.
Hardware Timestamp
Table 3. Feature History Table
Feature Name
|
Release Information
|
Description
|
Hardware Timestamp
|
Release 7.3.1
|
Whenever periodic statistics are streamed, the collector reads the data from its internal cache, instead of fetching the data
from the hardware.
When the data is read from the cache, the rate at which data is processed shows spikes because the timestamp from the collector
is off by several seconds. With hardware timestamping, the inconsistencies that are observed when reading data from the cache
file is removed.
|
Whenever periodic stats are streamed, the collector reads the stats from its internal cache, instead of fetching the stats
from the hardware. When the data is read from the sensor paths of Stats manager cache, the rate calculation shows spikes.
This behavior is due to the timestamp from the collector that is off by several seconds. Therefore, timestamp of some other
collector takes precedence because timestamps of collectors are not in synchronization with the current timestamp. This is
observed when there are multiple collectors providing stats updates for the same interface.
The Yang data model for Stats manager Cisco-IOS-XR-infra-statsd-oper.yang
is enhanced to enable the collector to read periodic stats data from the router using hardware timestamp.
The hardware timestamp is taken into account when a primary collector (for generic or proto stats) provides stats updates
from the hardware to the Stats manager. With hardware timestamping in rate computation while streaming periodic stats, the
spikes due to the timestamp issue is resolved.
The hardware timestamp is updated only when the collector attempts to read the counters from hardware. Else, the value remains
0
. The latest stats can be streamed at a minimum cadence of 10 seconds and periodic stats at a cadence of 30 seconds. The support
is available only for physical interfaces and subinterfaces, and bundle interface and subinterfaces.
When there is no traffic flow on protocols for an interface, the hardware timestamp for the protocols is published as 0. This
is due to non-synchronized timestamps sent by the collector for protocols in traffic as compared to non-traffic scenarios.
A non-zero value is published for protocols that have stats published by a primary collector for both traffic and non-traffic
scenarios.
Note |
The hardware timestamp is supported only for primary collectors. When the hardware has no update, the timestamp will be same.
However generic counters are computed for primary and non-primary collectors. The non-primary collectors show the latest stats,
but not the timestamp.
|
When the counters are cleared for an interface using clear counters interface command, all counter-related data including the timestamps for the interface is cleared. After all counter values are cleared
and set to 0
, the last data time is updated only when there is a request for it from a collector. For example, last data time gets updated
from a collector:
Router#:Aug 7 09:01:08.471 UTC: statsd_manager_l[168]: Updated last data time for ifhandle 0x02000408,
stats type 2 from collector with node 0x100, JID 250, last data time 1596790868.
INPUT: last 4294967295 updated 1596469986. OUTPUT: last 4294967295 updated 1596469986
All other counter values and hardware timestamp are updated when the counters are fetched from the hardware. In this case,
all counters including the hardware timestamp is 0:{"node_id_str":"MGBL_MTB_5504","subscription_id_str":"app_TEST_200000001",
"encoding_path":"Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/cache/generic-counters",
"collection_id":"7848",
"collection_start_time":"1596790879567",
"msg_timestamp":"1596790879571","data_json":
[{"timestamp":"1596790879570","keys":[{"interface-name":"FortyGigE0/1/0/11"}],
"content":{"packets-received":"0","bytes-received":"0","packets-sent":"0",
"bytes-sent":"0","multicast-packets-received":"0","broadcast-packets-received":"0",
"multicast-packets-sent":"0","broadcast-packets-sent":"0","output-drops":0,"output-queue-drops":0,
"input-drops":0,"input-queue-drops":0,"runt-packets-received":0,"giant-packets-received":0,
"throttled-packets-received":0,"parity-packets-received":0,"unknown-protocol-packets-received":0,
"input-errors":0,"crc-errors":0,"input-overruns":0,"framing-errors-received":0,"input-ignored-packets":0,
"input-aborts":0,"output-errors":0,"output-underruns":0,"output-buffer-failures":0,"output-buffers-swapped-out":0,
"applique":0,"resets":0,"carrier-transitions":0,"availability-flag":0,
"last-data-time":"1596790868","hardware-timestamp":"0",
"seconds-since-last-clear-counters":15,"last-discontinuity-time":1596469946,"seconds-since-packet-received":0,
"seconds-since-packet-sent":0}}],"collection_end_time":"1596790879571"}