Professional Documents
Culture Documents
This document is targeted for users who are planning to deploy the Cisco Nexus 9000 telemetry
solution along with their VXLAN EVPN deployment. Users should be familiar with the concept of
telemetry and are encouraged to read the Telemetry Document.
Users should also be familiar with the VXLAN EVPN solution.
Table of Contents
This section presents a test topology to describe telemetry usage. In this topology, four Cisco
Nexus 9300 switches are connected to a Cisco Nexus 9504 spine switch using ECMP links. The
telemetry receiver is started on an external Linux device. There is connectivity from each of the
Cisco Nexus devices to the telemetry receiver using the switch management ports. In this vPC
setup, hosts are deployed on servers, which are located behind the vPC peers. (IXIA is used to
simulate the hosts on the servers. Simulation has been used to scale up to 250 NVE peers, along
with route injection.)
Cisco NX-OS Release 7.0(3)I6(1) supports two types of protocol/encoding for telemetry usage:
GRPC/GPB and HTTP/JSON. Users need to start the corresponding type of receiver on the
external device to consume the telemetry data streamed from the switches.
There are two ways to collect telemetry data from the switches. One is DME based, and the
other is NX-API based. Cisco NX-OS Release 7.0(3)I5(1) supports DME-based collection and
GRPC/GPB protocol/encoding. Cisco NX-OS Release 7.0(3)I6(1) adds support for HTTP/JSON
protocol/encoding. DME-based telemetry data collection expects the sensor path to be a valid
Distinguished Name (DN) path. DME-based data collection supports both cadence-based and
event-based telemetry.
Cisco NX-OS Release 7.0(3)I6(1) also supports NX-API-based collection with cadence-based
telemetry. NX-API-based telemetry is simple to use and similar to using Cisco NX-OS show
commands.
If the amount of data streamed from a single show command exceeds 25 MB, users should use
DME-based telemetry. For components that do not have managed objects (MOs), users can rely
on NX-API-based telemetry.
We recommend that first-time telemetry users start with NX-API-based collection and
eventually move to DME-based collection.
This table provides the scale numbers for which the telemetry solution was validated using
Cisco NX-OS Release 7.0(3)I6(1).
VXLAN VTEPs 0 1
VXLAN L2 VNIs 0 2000
VXLAN L3 VNIs 0 900
VXLAN multicast groups 128 128
VXLAN overlay MAC addresses 64K
VXLAN overlay IP host routes 64000
OSPF Neighbors 16 4
NVE peers 0 250
BGP sessions 250 1
ACL 2000
CDP Neighbors 16 4
2. Prerequisites on the Switch
Step 2: Verify connectivity to the host where the receiver is up and running.
172.27.247.72 is the Linux host, which is used for the telemetry receiver.
Leaf3# ping 172.27.247.72 vrf management
PING 172.27.247.72 (172.27.247.72): 56 data bytes
64 bytes from 172.27.247.72: icmp_seq=0 ttl=62 time=0.765 ms
64 bytes from 172.27.247.72: icmp_seq=1 ttl=62 time=0.627 ms
64 bytes from 172.27.247.72: icmp_seq=2 ttl=62 time=0.68 ms
64 bytes from 172.27.247.72: icmp_seq=3 ttl=62 time=0.627 ms
64 bytes from 172.27.247.72: icmp_seq=4 ttl=62 time=0.632 ms
Step 3: Verify connectivity from the external host to the switch (provided this is the host
where the telemetry receiver will be hosted).
Users must configure a management IP address on the switch, and the switch should be
reachable from an external device.
Leaf3# sh run int mg0
!Command: show running-config interface mgmt0
!Time: Tue Apr 18 15:01:25 2017
version 7.0(3)I6(1)
interface mgmt0
vrf member management
ip address 172.19.198.124/24
This use case is cadence based, which implies that the configured sample interval is greater
than 0. For event-based telemetry, the configured sample interval must be 0 (zero).
When streaming out large size data, users should make sure that the receiver is capable of
handling the received data. For example, if the default open source GRPC receiver can support
a data size < 4 MB and the data being streamed out of the switch is > 4 MB, the receiver has to
be updated to handle such data.
The configurations in this section stream out all the MOs (self, children) along with the
properties associated with the configured sensor paths.
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 172.27.247.72 port 60001 protocol gRPC encoding GPB
sensor-group 1
path sys/bgp depth unbounded
path sys/epId-1 depth unbounded
path sys/bd depth unbounded
path sys/ospf depth unbounded
path sys/intf depth unbounded
path sys/acl depth unbounded
path sys/ipqos depth unbounded
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 100000
Use the following show command to determine the streaming time along with the sensor paths
configured on the switch. We recommend configuring the sample interval based on the
following output.
Data Collector:
Errors:
Node Create Fail = 0
Event Collector:
Errors:
Node Create Fail = 0 Node Add Fail = 0
Invalid Data = 0
Queue Statistics:
Request Queue:
High Priority Queue:
Info:
Actual Size = 50 Current Size = 0
Max Size = 0 Full Count = 0
Errors:
Enqueue Error = 0 Dequeue Error = 0
Errors:
Enqueue Error = 0 Dequeue Error = 0
Data Queue:
High Priority Queue:
Info:
Actual Size = 50 Current Size = 0
Max Size = 0 Full Count = 0
Errors:
Enqueue Error = 0 Dequeue Error = 0
Errors:
Enqueue Error = 0 Dequeue Error = 0
Use the following show command to determine the transport status with the receiver. If the
connection with the receiver is not successful or the connection times out, the status changes
to Disconnected.
The following show commands display additional details on the streaming statistics.
Session Id: 0
IP Address:Port 172.27.247.72:60001
Encoding: GPB
Transport: GRPC
Status: Connected
Last Connected: Fri Apr 14 10:25:32.893 PST
Last Disconnected: Never
Tx Error Count: 0
Leaf3# Error: None
Leaf3# sh telemetry transport 0 error
Session Id: 0
Connection Errors
Connection Error Count: 0
Last Connection Error: Wed Dec 31 17:00:00.000 PST
Transmission Errors
Tx Error Count: 0
Last Tx Error: None
Leaf3# Tx Return Code: OK
Session Id: 0
Connection Stats
Connection Count 1
Last Connected: Fri Apr 14 10:25:32.893 PST
Disconnect Count 0
Last Disconnected: Never
Transmission Stats
Transmit Count: 70
Last TX time: Fri Apr 14 10:40:42.460 PST
Min Tx Time: 6 ms
Max Tx Time: 1674 ms
Avg Tx Time: 552 ms
4. Use Case 2: Event-Based Notification When a New BGP Peer
Comes Up
This use case covers scenarios when users do not know the IP address of the remote BGP peer.
The configurations remain the same irrespective of the number of BGP peers with which BGP
peering is formed. If users know the IP address of the BGP peer for which a notification needs
to be streamed out, the configuration can be modified to point to the particular BGP peer. (Use
Case 3 covers this configuration.)
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/bgp depth unbounded
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
Existing BGP peering on the device
Spine1# sh bgp session
Total peers 4, established peers 4
ASN 1000
VRF default, local ASN 1000
peers 4, established peers 4, local router-id 7.7.7.7
State: I-Idle, A-Active, O-Open, E-Established, C-Closing, S-Shutdown
This section shows telemetry data received on the receiver when the new BGP peer is learned.
The following data shows the IP address of the remote peer, the initial state and the final state,
along with other properties of the MO.
For this use case, the filter condition needs to be used in the switch configuration.
This use case requires users to apply configurations specific to the BGP peer in which they are
interested. By observing the telemetry receiver output from Use Case 2, users can derive the
configuration for this use case. The objective is to receive a notification when BGP peering with
IP address 17.0.101.1 is established. Users need to specify what they are trying to monitor. The
following switch configurations show that a notification is sent when a session is established.
Users specify the MO in which they are interested and monitor the particular property (for
example, the operSt property of the MO is set to a value of “established”).
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1] depth 0 fi
lter-condition eq(bgpPeerEntry.operSt,"established")
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
1 Mon Apr 24 09:23:12.549 PST sys/bgp/inst/dom-default/peer-[17.
0.0.0/16]/ent-[17.0.101.1]
5.1.1 Telemetry Receiver Output
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7] depth 0 filter-condition
and(updated(bgpPeerEntry.operSt),eq(bgpPeerEntry.operSt,"established"))
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
Leaf4# sh telemetry event collector stats
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]
version 7.0(3)I6(1)
feature bgp
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
1 Mon Apr 24 10:43:34.547 PST sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1] depth 0
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/epId-1 depth unbounded
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
Note: If minimal telemetry data output is required, follow the switch configuration pattern as
indicated in Use Case 4.
9 Use Case 7: Telemetry Event Notification When a VLAN Goes Down
In this use case, users monitor VLAN 100, and an event notification is sent when VLAN 100 is
admin down.
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/bd/bd-[vlan-100]
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
1 Tue Apr 25 11:37:35.941 PST sys/bd/bd-[vlan-100]
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/bgp/inst/dom-test309 depth 0 filter-condition eq(bgpDom.operSt,"down")
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/bgp/inst/dom-test309
Leaf4# sh vrf test309
VRF-Name VRF-ID State Reason
test309 236 Up --
The remaining use cases limit the telemetry configurations to the sensor-path configuration
under the sensor-group. Many previous examples show other configurations, such as
destination-group, subscription, and so on.
These use cases also do not show the output on the telemetry receiver, as it follows a similar
pattern.
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
1 Tue Mar 07 15:18:17.309 PST sys/acl/ipv4/name-test/seq-10
In this use case, SVI 2810 is associated with VRF test309. When users shut down the VRF, the
SVI associated with the VRF also goes down, and an event notification is sent.
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/intf/svi-[vlan2810]
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
2 Tue Mar 07 15:33:28.172 PST sys/intf/svi-[vlan2810]
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/bgp/inst/dom-default depth 0 filter-condition eq(bgpDom.numEstPeers,"0")
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/bgp/inst/dom-default
Leaf4# sh bgp l2vpn evpn sum
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 4.4.4.4, local AS number 1000
BGP table version is 761546, L2VPN EVPN config peers 1, capable peers 1
6398 network entries and 9995 paths using 1305040 bytes of memory
BGP attribute entries [2703/421668], BGP AS path entries [0/0]
BGP community entries [1/32], BGP clusterlist entries [3/12]
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
1 Tue Apr 25 13:46:43.662 PST sys/bgp/inst/dom-default
In this use case, the switch sends an event notification when the number of BGP L2VPN EVPN
accepted routes equals 3600.
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 65534 protocol gRPC encoding GPB
sensor-group 1
path sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]/af-l2vpn-evpn depth 0 filter-
condition eq(bgpPeerAfEntry.acceptedPaths,"3600")
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
Leaf1# show bgp l2vpn evpn summary
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 1.1.1.1, local AS number 1000
BGP table version is 2635876, L2VPN EVPN config peers 1, capable peers 1
330217 network entries and 333817 paths using 52126872 bytes of memory
BGP attribute entries [7201/1123356], BGP AS path entries [0/0]
BGP community entries [1/32], BGP clusterlist entries [252/1008]
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]/af-
l2vpn-evpn
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
1 Fri Mar 10 10:19:55.370 PST sys/bgp/inst/dom-default/peer-[7.7.7.7
]/ent-[7.7.7.7]/af-l2vpn-evpn
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/epId-1/peers/dy_peer-17.0.101.1 depth 0 filter-condition eq(nvoDyPeer.state,"Up")
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/epId-1/peers/dy_peer-17.0.101.1
Leaf4# sh nve peer
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 12.12.12.12 Up CP 00:15:45 f8c2.8887.d3a7
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
1 Tue Apr 25 14:09:53.250 PST sys/epId-1/peers/dy_peer-17.0.101.1
This use case shows configurations when users do not have information about the IP address of
the NVE peer. An event notification is sent when any NVE peer comes up.
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 65534 protocol gRPC encoding GPB
sensor-group 1
path sys/epId-1/peers depth unbounded
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
Leaf2# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 34.34.34.34 Up CP 03:55:07 f8c2.88b5.de85
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/epId-1/peers
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
1000 Mon Mar 20 12:59:40.058 PST sys/epId-1/peers
17 Use Case 15: Telemetry Event Notification When NVE VNI State
Changes
In the case of vPC setup, when the MCT link goes down, all the VNIs configured on the vPC
secondary node transition from up to down. The following configurations are applied on the
vPC secondary node. Event notifications are sent when the VNI state changes to down.
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 6000 protocol HTTP encoding JSON
ip address 172.27.247.72 port 9001 protocol HTTP encoding JSON
ip address 172.27.247.72 port 50001 protocol gRPC encoding GPB
sensor-group 1
path sys/epId-1/nws depth unbounded
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
Leaf4# sh nve vni 4002
Codes: CP - Control Plane DP - Data Plane
UC - Unconfigured SA - Suppress ARP
Simulating a condition for MCT link going down and checking the state for a particular VNI
Leaf4# sh nve vni 4002
Codes: CP - Control Plane DP - Data Plane
UC - Unconfigured SA - Suppress ARP
In this use case, the port channel is 20. It has two member links.
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/intf/aggr-[po20]/aggrif depth 0 filter-condition ne(ethpmAggrIf.numActivePorts,"2")
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
Leaf4# sh telemetry event collector stats
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/intf/aggr-[po20]/aggrif
Leaf4# sh port
port-channel port-profile
Leaf4# sh port-channel summary
Flags: D - Down P - Up in port-channel (members)
I - Individual H - Hot-standby (LACP only)
s - Suspended r - Module-removed
b - BFD Session Wait
S - Switched R - Routed
U - Up (port-channel)
p - Up in delay-lacp mode (member)
M - Not in use. Min-links not met
--------------------------------------------------------------------------------
Group Port- Type Protocol Member Ports
Channel
--------------------------------------------------------------------------------
10 Po10(SU) Eth LACP Eth1/5(P) Eth1/6(P)
20 Po20(SU) Eth LACP Eth1/7(P) Eth1/8(P)
Shutting down one of the member links
Leaf4# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Leaf4(config)# int e1/7
Leaf4(config-if)# sh
Leaf4(config-if)# end
Leaf4# sh port
port-channel port-profile
Leaf4# sh port-channel summary
Flags: D - Down P - Up in port-channel (members)
I - Individual H - Hot-standby (LACP only)
s - Suspended r - Module-removed
b - BFD Session Wait
S - Switched R - Routed
U - Up (port-channel)
p - Up in delay-lacp mode (member)
M - Not in use. Min-links not met
--------------------------------------------------------------------------------
Group Port- Type Protocol Member Ports
Channel
--------------------------------------------------------------------------------
10 Po10(SU) Eth LACP Eth1/5(P) Eth1/6(P)
20 Po20(SU) Eth LACP Eth1/7(D) Eth1/8(P)
Leaf4# sh telemetry event collector stats
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
1 Tue Apr 25 15:51:19.294 PST sys/intf/aggr-[po20]/aggrif
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/epId-1/nws/vni-4002 depth 0 filter-condition eq(nvoNw.state,"Down")
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/epId-1/nws/vni-4002
Leaf4# sh nve vni 4002
Codes: CP - Control Plane DP - Data Plane
UC - Unconfigured SA - Suppress ARP
Leaf4# conf t
Enter configuration commands, one per line. End with CNTL/Z.
Leaf4(config)# vlan 2
Leaf4(config-vlan)# sh
Leaf4(config-vlan)# end
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/intf/aggr-[po20]/aggrif depth 0 filter-condition eq(ethpmAggrIf.operSt,"down")
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/intf/aggr-[po20]/aggrif
Leaf4# sh port-channel summary
Flags: D - Down P - Up in port-channel (members)
I - Individual H - Hot-standby (LACP only)
s - Suspended r - Module-removed
b - BFD Session Wait
S - Switched R - Routed
U - Up (port-channel)
p - Up in delay-lacp mode (member)
M - Not in use. Min-links not met
--------------------------------------------------------------------------------
Group Port- Type Protocol Member Ports
Channel
--------------------------------------------------------------------------------
10 Po10(SU) Eth LACP Eth1/5(P) Eth1/6(P)
20 Po20(SU) Eth LACP Eth1/7(P) Eth1/8(P)
This use case monitors the operational state of interface Ethernet 1/1.
When the interface goes down, a telemetry event notification is sent.
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
path sys/intf/phys-[eth1/1]/phys depth 0 filter-condition eq(ethpmPhysIf.operSt,"down")
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 0
Leaf4# sh telemetry event collector stats
--------------------------------------------------------------------------------
Collection Count Latest Collection Time Sensor Path
--------------------------------------------------------------------------------
0 Not yet collect sys/intf/phys-[eth1/1]/phys
Using the NX-API collector approach, users can specify the show command in the telemetry
configuration. Doing so enables the telemetry data for the specific show command to be
streamed out. Users can use this approach for any path that is not yet DME’ized as well as for
DME’ized paths, if they prefer only cadence-based streaming.
To use the NX-API collector approach, the show command should be XMLi’zed. The NX-API
collector approach supports only cadence-based streaming and not event-based streaming.
Note: While using the cadence-based approach, the sample interval must be greater than 0.
In this example, the sample interval is 10 seconds.
version 7.0(3)I6(1)
feature telemetry
telemetry
destination-group 1
ip address 171.70.59.235 port 5000 protocol HTTP encoding JSON
sensor-group 1
data-source NX-API
path "show nve peers" depth 0
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 10000
----------------------------------------------------------------------
Collector Type Successful Failed Skipped
----------------------------------------------------------------------
NX-API 0 0 0
DME 0 0 0
When using an NX-API-based approach, users need to configure the data source as NX-API. The
default data source is DME.
telemetry
destination-group 1
ip address 172.27.247.72 port 60001 protocol gRPC encoding GPB
sensor-group 1
data-source NX-API
path "show system resources" depth 0
path "show version" depth 0
path "show environment power" depth 0
path "show environment fan" depth 0
path "show environment temperature" depth 0
path "show process cpu" depth 0
path "show nve peers" depth 0
path "show nve vni" depth 0
path "show nve vni 4002 counters" depth 0
path "show int nve 1 counters" depth 0
path "show policy-map vlan" depth 0
path "show ip access-list test" depth 0
path "show system internal access-list resource utilization" depth 0
path "show interface counters " depth 0
path "show vlan counters" depth 0
subscription 1
dst-grp 1
snsr-grp 1 sample-interval 750000
----------------------------------------------------------------------
Collector Type Successful Failed Skipped
----------------------------------------------------------------------
DME 0 0 0
NX-API 165 0 0
--------------------------------------------------------------------------------
Successful Failed Skipped Sensor Path
--------------------------------------------------------------------------------
11 0 0 show vlan counters
11 0 0 show policy-map vlan
11 0 0 show environment power
11 0 0 show nve vni
11 0 0 show ip access-list test
11 0 0 show process cpu
11 0 0 show version
11 0 0 show environment fan
11 0 0 show nve vni 4002 counters
11 0 0 show interface counters
11 0 0 show environment temperature
11 0 0 show system resources
11 0 0 show nve peers
11 0 0 show int nve 1 counters
11 0 0 show system internal access-list resource utilization
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product
includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit.
(http://www.openssl.org/). This product includes software written by Tim Hudson (tjh@cryptsoft.com).
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and
other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party
trademarks mentioned are the property of their respective owners. The use of the word partner does not
imply a partnership relationship between Cisco and any other company. (1110R)