Telemetry Deployment for VXLAN EVPN Solution€¦ · Telemetry Deployment for VXLAN EVPN Solution . This document is targeted for users who are planning to deploy the Cisco Nexus

Telemetry Deployment for VXLAN EVPN Solution

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.

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/programmability/guide/b_Cisco_Nexus_9000_Series_NX-OS_Programmability_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_Programmability_Guide_7x_chapter_011000.html

Table of Contents

1. Telemetry Solution Test Topology ........................................................................................................ 4

2. Prerequisites on the Switch .................................................................................................................. 6

3. Use Case 1: Streaming Out Complete Data for Applicable VXLAN EVPN DNs ..................................... 8

3.1 Switch Configurations ................................................................................................................... 8

4. Use Case 2: Event-Based Notification When a New BGP Peer Comes Up ......................................... 15

4.1 Switch Configurations ................................................................................................................. 15

4.1.1 Telemetry Receiver Output ....................................................................................................... 17

5 Use Case 3: Generate Event-Based Notification When a Particular BGP Peer Session Is Established 18


5.1.1 Telemetry Receiver Output ....................................................................................................... 21

6 Use Case 4: Specific Property Notification Sent to the Telemetry Receiver ...................................... 23


6.1.1 Telemetry Receiver Output ................................................................................................. 26

7 Use Case 5: Event Notification When BGP Peering with Remote Node Is Lost ................................. 28



8 Use Case 6: Event Generation When a New Host Is Learned and NVE Peering Is Established............... 33



9 Use Case 7: Telemetry Event Notification When a VLAN Goes Down ................................................ 37



10 Use Case 8: Telemetry Event Notification When VRF Is Down ....................................................... 41



11 Use Case 9: Telemetry Event Notification When ACL Packets Exceed a Threshold ....................... 44


12 Use Case 10: Telemetry Event Notification When an SVI Goes Down ........................................... 45


13 Use Case 11: Telemetry Event Generation When Number of BGP Established Peers Reaches 0 .. 47



14 Use Case 12: Telemetry Event Notification When Number of BGP L2VPN EVPN Routes Goes Below a Threshold....................................................................................................................................... 50



15 Use Case 13: Telemetry Event Notification When a Particular NVE Peer Is Up ............................. 54



16 Use Case 14: Telemetry Event Notification When Any NVE Peer Comes Up ................................. 57


17 Use Case 15: Telemetry Event Notification When NVE VNI State Changes .................................... 59



18 Use Case 16: Telemetry Event Notification When Member Link of a Port-Channel Interface Goes Down 62



19 Use Case 17: Telemetry Event Notification When a Particular VNI Goes Down ............................ 66



20 Use Case 18: Event Notification When Port-Channel Interface Goes Down .................................. 69



21 Use Case 19: Event Notification When a Physical Interface Goes Down ........................................ 73



22 Use Case 20: Event Generation When a New Host Is Learned and NVE Peering Is Established (Using the NX-API Data Collector Approach) .............................................................................................. 77



23 Use Case 21: NX-API-Based Approach to Get Node Inventory Data and Other Data ..................... 80


1. Telemetry Solution Test Topology

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).

N9500 N9300

N9K-SUP-A

VXLAN VTEPs 0 1VXLAN L2 VNIs 0 2000VXLAN L3 VNIs 0 900

VXLAN multicast groups 128 128VXLAN overlay MAC addresses 64K VXLAN overlay IP host routes 64000

OSPF Neighbors 16 4NVE peers 0 250

BGP sessions 250 1ACL 2000

CDP Neighbors 16 4

Profile : VXLAN EVPN

Target Scale

Platform N9K-C9396PX

Feature

2. Prerequisites on the Switch

Step 1: Enable this configuration on the switch.

Leaf3# sh run | inc nxapi

feature nxapi

nxapi use-vrf management

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





--- 172.27.247.72 ping statistics ---

5 packets transmitted, 5 packets received, 0.00% packet loss

round-trip min/avg/max = 0.627/0.666/0.765 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

Step 4: Verify connectivity from the external host.

$ ping 172.19.198.124

PING 172.19.198.124 (172.19.198.124) 56(84) bytes of data.






^C

--- 172.19.198.124 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 3998ms

rtt min/avg/max/mdev = 0.589/0.615/0.633/0.036 ms

3. Use Case 1: Streaming Out Complete Data for Applicable VXLAN EVPN DNs

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.

3.1 Switch Configurations

Leaf3# sh run telemetry

!Command: show running-config telemetry

!Time: Fri Apr 14 10:38:24 2017

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.

Leaf3# sh telemetry control database

Subscription Database size = 1

--------------------------------------------------------------------------------

Subscription ID Data Collector Type

--------------------------------------------------------------------------------

1 DME

Sensor Group Database size = 1

--------------------------------------------------------------------------------

Sensor Group ID Sensor Group type Sampling interval(ms) Linked subscriptions

--------------------------------------------------------------------------------

1 Timer /DME 100000(Running) 1

Collection Time in ms (Cur/Min/Max): 64450/64450/67495

Streaming Time in ms (Cur/Min/Max): 75528/75528/78634

Sensor Path Database size = 7

--------------------------------------------------------------------------------

Subscribed Linked Groups Sec Groups Retrieve level Sensor Path : Query Filter

--------------------------------------------------------------------------------

No 1 0 Full sys/bd

No 1 0 Full sys/epId-1

No 1 0 Full sys/ospf

No 1 0 Full sys/intf

No 1 0 Full sys/ipqos

No 1 0 Full sys/acl

No 1 0 Full sys/bgp

Destination group Database size = 1

--------------------------------------------------------------------------------

Destination Group ID Refcount

--------------------------------------------------------------------------------

1 1

Destination Database size = 1

--------------------------------------------------------------------------------

Dst IP Addr Dst Port Encoding Transport Count

--------------------------------------------------------------------------------

172.27.247.72 60001 GPB gRPC 1

Use the following show command to determine if the queue is filling up. The queue typically fills up if the configured sample interval is less than the streaming time. For optimal performance results, we recommend that the current size of the queue in the following output starts at 0.

Leaf3# sh telemetry pipeline stats

Main Statistics:

Timers:

Errors:

Start Fail = 0

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

Low Priority Queue:

Info:



Errors:


Data Queue:

High Priority Queue:

Info:



Errors:


Low Priority Queue:

Info:



Errors:


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.

Leaf3# sh telemetry transport

Session Id IP Address Port Encoding Transport Status

-----------------------------------------------------------------------------------

0 172.27.247.72 60001 GPB gRPC Connected

The following show commands display additional details on the streaming statistics.

Leaf3# sh telemetry transport 0

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

Leaf3# sh telemetry transport 0 stats

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.)


Spine1# sh run tele


!Time: Thu Apr 20 14:50:23 2017

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


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

Neighbor ASN Flaps LastUpDn|LastRead|LastWrit St Port(L/R) Notif(S/R)

1.1.1.1 1000 0 03:05:52|00:00:05|00:00:34 E 45198/179 0/0

2.2.2.2 1000 0 03:06:29|00:00:06|00:00:34 E 179/26575 0/0

3.3.3.3 1000 0 03:06:31|00:00:24|00:00:34 E 179/34256 0/0

4.4.4.4 1000 0 03:06:40|00:00:27|00:00:34 E 179/54795 0/0

Simulating a new BGP peer join condition

Spine1# sh bgp session

Total peers 5, established peers 5

ASN 1000

VRF default, local ASN 1000

peers 5, established peers 5, local router-id 7.7.7.7

State: I-Idle, A-Active, O-Open, E-Established, C-Closing, S-Shutdown

Neighbor ASN Flaps LastUpDn|LastRead|LastWrit St Port(L/R) Notif(S/R)

1.1.1.1 1000 0 03:14:37|00:00:50|00:00:04 E 45198/179 0/0

2.2.2.2 1000 0 03:15:14|00:00:51|00:00:04 E 179/26575 0/0

3.3.3.3 1000 0 03:15:17|00:00:09|00:00:04 E 179/34256 0/0

4.4.4.4 1000 0 03:15:26|00:00:12|00:00:04 E 179/54795 0/0

17.0.101.1 1000 0 00:00:06|00:00:04|00:00:04 E 179/35282 0/0

4.1.1 Telemetry Receiver Output

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.

data : {u'imdata': [{u'bgpPeerEntry': {u'attributes': {u'remotePort': u'unspecified', u'connAttempts': u'na', u'localPort': u'unspecified', u'localIp': u'0.0.0.0', u'maxConnRetryIntvl': u'60', u'stReason': u'none', u'persistentOnReload': u'false', u'addr': u'17.0.101.1', u'peerIdx': u'7', u'shutStQual': u'unspecified', u'advCap': u'', u'rcvCap': u'', u'operSt': u'idle', u'connIf': u'unspecified', u'modTs': u'never', u'connDrop': u'0', u'rn': u'', u'lastFlapTs': u'2017-04-20T15:07:02.406+00:00', u'updateElapsedTs': u'2017-04-18T17:02:06.088+00:00', u'holdIntvl': u'180', u'dn': u'sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1]', u'connEst': u'0', u'fd': u'4294967295', u'passwdSet': u'disabled', u'prevOperSt': u'connect', u'childAction': u'', u'status': u'created', u'name': u'', u'type': u'ibgp', u'kaIntvl': u'60', u'flags': u'cap-neg,gr-enabled', u'rtrId': u'0.0.0.0'}}}], u'subscriptionId': [u'18374686488244781057']}

data : {u'imdata': [{u'bgpPeerEntry': {u'attributes': {u'dn': u'sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1]', u'remotePort': u'35282', u'connEst': u'1', u'shutStQual': u'admin-up', u'prevOperSt': u'open-confirm', u'advCap': u'as4,dynamic,dynamic-gr,dynamic-mp,dynamic-old,dynamic-refresh,gr,l2vpn-evpn,refresh,refresh-old', u'status': u'modified', u'rcvCap': u'cap,l2vpn-evpn,refresh,refresh-old', u'operSt': u'established', u'localIp': u'17.0.0.6', u'fd': u'86', u'connIf': u'eth1/35', u'flags': u'cap-neg,direct-connect,gr-enabled', u'rn': u'', u'localPort': u'179', u'lastFlapTs': u'2017-04-20T15:07:03.156+00:00', u'rtrId': u'17.0.101.1', u'childAction': u''}}}], u'subscriptionId': [u'18374686488244781057']}

5 Use Case 3: Generate Event-Based Notification When a Particular BGP Peer Session Is Established

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”).


Spine1# sh run tele


!Time: Mon Apr 24 09:17:10 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


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


Initial state of the switch

Spine1# sh bgp l2vpn evpn sum

BGP summary information for VRF default, address family L2VPN EVPN

BGP router identifier 7.7.7.7, local AS number 1000

BGP table version is 3313598, L2VPN EVPN config peers 5, capable peers 4

7244 network entries and 7244 paths using 1564704 bytes of memory

BGP attribute entries [3639/567684], BGP AS path entries [0/0]

BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

1.1.1.1 4 1000 56495 146171 3313598 0 0 3d01h 1803

2.2.2.2 4 1000 66800 70214 3313598 0 0 3d21h 1801

3.3.3.3 4 1000 40175 89241 3313598 0 0 3d21h 1840

4.4.4.4 4 1000 40134 96836 3313598 0 0 3d00h 1800

Spine1# sh telemetry event collector stats

--------------------------------------------------------------------------------

Collection Count Latest Collection Time Sensor Path

--------------------------------------------------------------------------------

0 Not yet collect sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent- [17.0.101.1]

New BGP peering is established









1.1.1.1 4 1000 56496 146181 3313999 0 0 3d01h 1803

2.2.2.2 4 1000 66801 70224 3313999 0 0 3d21h 1801

3.3.3.3 4 1000 40177 89251 3313999 0 0 3d21h 1840

4.4.4.4 4 1000 40136 96846 3313999 0 0 3d00h 1800

17.0.101.1 4 1000 13 3643 3313999 0 0 00:00:11 400

Spine1# sh telemetry event collector stats

--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

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]


172.19.198.152 - - [24/Apr/2017 09:23:12] "POST /network/sys%2Fbgp%2Finst%2Fdom-default%2Fpeer-%5B17.0.0.0%2F16%5D%2Fent-%5B17.0.101.1%5D HTTP/1.0" 200 -


>>> URL : /network/sys%2Fbgp%2Finst%2Fdom-default%2Fpeer-%5B17.0.0.0%2F16%5D%2Fent-%5B17.0.101.1%5D

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1

>>> Content-Type : application/json

>>> Content-Length : 1004

Path => sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1]

node_id_str : Spine1

collection_id : 33693

data_source : DME

data : {u'imdata': [{u'bgpPeerEntry': {u'attributes': {u'dn': u'sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1]', u'remotePort': u'45960', u'connEst': u'1', u'shutStQual': u'admin-up', u'prevOperSt': u'open-confirm', u'advCap': u'as4,dynamic,dynamic-gr,dynamic-mp,dynamic-old,dynamic-refresh,gr,l2vpn-evpn,refresh,refresh-old', u'status': u'modified', u'rcvCap': u'cap,l2vpn-evpn,refresh,refresh-old', u'operSt': u'established', u'localIp': u'17.0.0.6', u'fd': u'86', u'connIf': u'eth1/35', u'flags': u'cap-neg,direct-connect,gr-enabled', u'rn': u'', u'localPort': u'179', u'lastFlapTs': u'2017-04-24T09:23:12.531+00:00', u'rtrId': u'17.0.101.1', u'childAction': u''}}}], u'subscriptionId': [u'18374686715878047745']}

172.19.198.125 - - [24/Apr/2017 09:23:13] "POST /network/sys%2FepId-1%2Fpeers%2Fdy_peer-17.0.101.1 HTTP/1.0" 200 -


>>> URL : /network/sys%2FepId-1%2Fpeers%2Fdy_peer-17.0.101.1

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/epId-1/peers/dy_peer-17.0.101.1

node_id_str : Leaf4

collection_id : 3

data_source : DME

data : {u'imdata': [{u'nvoDyPeer': {u'attributes': {u'dn': u'sys/epId-1/peers/dy_peer-17.0.101.1', u'rn': u'', u'upStateTransitionTs': u'2017-04-24T09:23:13.004+00:00', u'state': u'Up'}}}], u'subscriptionId': [u'18374686685813276673']}




>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1






data_source : DME

data : {u'imdata': [{u'bgpPeerEntry': {u'attributes': {u'dn': u'sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1]', u'status': u'modified', u'rn': u'', u'updateElapsedTs': u'2017-04-24T09:23:14.541+00:00', u'childAction': u''}}}], u'subscriptionId': [u'18374686715878047745']}

6 Use Case 4: Specific Property Notification Sent to the Telemetry Receiver

Using the updated option along with the filter condition

In Use Case 3, users receive a notification when new BGP peering is established. The switch sends operSt:established and streams out other properties associated with the MO (for example, the advertising capabilities, local port, and so on). In certain scenarios, users might want to limit the data being sent from the switch. In this particular example, the switch streams out only relevant data that pertains to the operSt of BGP peering. The following switch configurations indicate that users are interested only in the operSt property of the MO.


Leaf4# sh run tele


!Time: Mon Apr 24 10:30:08 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


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


Leaf4# sh telemetry event collector stats

--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]

Leaf4# sh run bgp

!Command: show running-config bgp

!Time: Mon Apr 24 10:30:31 2017

version 7.0(3)I6(1)

feature bgp

router bgp 1000

router-id 4.4.4.4

address-family ipv4 unicast

address-family l2vpn evpn

neighbor 7.7.7.7

remote-as 1000

update-source loopback1

address-family ipv4 unicast

send-community

send-community extended

address-family l2vpn evpn

send-community

Leaf4# sh bgp l2vpn evpn sum








7.7.7.7 4 1000 41985 20525 0 0 0 00:10:06 Idle









7.7.7.7 4 1000 44730 21431 1682192 0 0 00:00:15 3604


--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

1 Mon Apr 24 10:43:34.547 PST sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]


172.19.198.125 - - [24/Apr/2017 10:43:34] "POST /network/sys%2Fbgp%2Finst%2Fdom-default%2Fpeer-%5B7.7.7.7%5D%2Fent-%5B7.7.7.7%5D HTTP/1.0" 200 -

172.19.198.125 - - [24/Apr/2017 10:43:34] "POST /network/sys%2Fbgp%2Finst%2Fdom-default%2Fpeer-%5B7.7.7.7%5D%2Fent-%5B7.7.7.7%5D HTTP/1.0" 200 -

>>> URL : /network/sys%2Fbgp%2Finst%2Fdom-default%2Fpeer-%5B7.7.7.7%5D%2Fent-%5B7.7.7.7%5D

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]

node_id_str : Leaf4

collection_id : 5

data_source : DME

data : {u'imdata': [{u'bgpPeerEntry': {u'attributes': {u'dn': u'sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]', u'remotePort': u'20550', u'connEst': u'2', u'shutStQual': u'admin-up', u'prevOperSt': u'open-confirm', u'advCap': u'as4,dynamic,dynamic-gr,dynamic-mp,dynamic-old,dynamic-refresh,gr,ipv4-ucast,l2vpn-evpn,refresh,refresh-old', u'status': u'modified', u'rcvCap': u'as4,cap,dynamic,dynamic-gr,dynamic-mp,dynamic-old,dynamic-refresh,gr,ipv4-ucast,l2vpn-evpn,refresh,refresh-old', u'operSt': u'established', u'localIp':

u'4.4.4.4', u'fd': u'1887', u'rn': u'', u'localPort': u'179', u'lastFlapTs': u'2017-04-24T10:43:34.532+00:00', u'rtrId': u'7.7.7.7', u'childAction': u''}}}], u'subscriptionId': [u'18374686685813276679']}

7 Use Case 5: Event Notification When BGP Peering with Remote Node Is Lost


Spine1# sh run tele


!Time: Mon Apr 24 10:09:13 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


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










1.1.1.1 4 1000 56543 146239 3314800 0 0 3d02h 1803

2.2.2.2 4 1000 66848 70282 3314800 0 0 3d22h 1801

3.3.3.3 4 1000 40223 89309 3314800 0 0 3d22h 1840

4.4.4.4 4 1000 40182 96904 3314800 0 0 3d01h 1800

17.0.101.1 4 1000 15 3645 3314800 0 0 00:02:10 400

BGP peering is down









1.1.1.1 4 1000 56545 146245 3315200 0 0 3d02h 1803

2.2.2.2 4 1000 66850 70288 3315200 0 0 3d22h 1801

3.3.3.3 4 1000 40225 89315 3315200 0 0 3d22h 1840

4.4.4.4 4 1000 40184 96910 3315200 0 0 3d01h 1800

17.0.101.1 4 1000 16 3646 0 0 0 00:00:15 Idle









1.1.1.1 4 1000 56545 146245 3315200 0 0 3d02h 1803

2.2.2.2 4 1000 66850 70288 3315200 0 0 3d22h 1801

3.3.3.3 4 1000 40226 89315 3315200 0 0 3d22h 1840

4.4.4.4 4 1000 40185 96910 3315200 0 0 3d01h 1800





>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1






data_source : DME

data : {u'imdata': [{u'bgpPeerEntry': {u'attributes': {u'dn': u'sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1]', u'status': u'modified', u'shutStQual': u'unspecified', u'advCap': u'', u'rcvCap': u'', u'operSt': u'closing', u'connDrop': u'1', u'rn': u'', u'lastFlapTs': u'2017-04-24T10:11:28.297+00:00', u'childAction': u''}}}], u'subscriptionId': [u'18374686715878047750']}




>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1






data_source : DME

data : {u'imdata': [{u'bgpPeerEntry': {u'attributes': {u'dn': u'sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1]', u'remotePort': u'unspecified', u'localPort': u'unspecified', u'status': u'modified', u'operSt': u'idle', u'localIp': u'0.0.0.0', u'flags': u'cap-neg,gr-enabled', u'fd': u'4294967295', u'rn': u'', u'prevOperSt': u'established', u'rtrId': u'0.0.0.0', u'childAction': u''}}}], u'subscriptionId': [u'18374686715878047750']}




>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1






data_source : DME

data : {u'imdata': [{u'bgpPeerEntry': {u'attributes': {u'dn': u'sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1]', u'status': u'deleted', u'rn': u'', u'childAction': u''}}}], u'subscriptionId': [u'18374686715878047750']}

8 Use Case 6: Event Generation When a New Host Is Learned and NVE Peering Is Established




!Time: Mon Apr 24 11:01:27 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


sensor-group 1

path sys/epId-1 depth unbounded

subscription 1

dst-grp 1


Leaf4# sh nve peer

Interface Peer-IP State LearnType Uptime Router-Mac

--------- --------------- ----- --------- -------- -----------------

nve1 12.12.12.12 Up CP 00:17:45 f8c2.8887.d3a7

Leaf4# sh mac address-table vlan 2 address 0210.10bd.1020

Legend:

* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC

age - seconds since last seen,+ - primary entry using vPC Peer-Link,

(T) - True, (F) - False, C - ControlPlane MAC

VLAN MAC Address Type age Secure NTFY Ports

---------+-----------------+--------+---------+------+----+------------------

New host MAC address is learned

Leaf4# sh mac address-table vlan 2 address 0210.10bd.1020

Legend:

* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC

age - seconds since last seen,+ - primary entry using vPC Peer-Link,

(T) - True, (F) - False, C - ControlPlane MAC

VLAN MAC Address Type age Secure NTFY Ports

---------+-----------------+--------+---------+------+----+------------------

C 2 0210.10bd.1020 dynamic 0 F F nve1(17.0.101.1)

New NVE peering is established

Leaf4# sh nve peer


--------- --------------- ----- --------- -------- -----------------

nve1 12.12.12.12 Up CP 00:20:45 f8c2.8887.d3a7

nve1 17.0.101.1 Up CP 00:02:33 7056.0001.1101


172.19.198.125 - - [24/Apr/2017 11:01:56] "POST /network/sys%2FepId-1 HTTP/1.0" 200 -


>>> URL : /network/sys%2FepId-1

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/epId-1

node_id_str : Leaf4

collection_id : 6

data_source : DME

data : {u'imdata': [{u'nvoDyPeer': {u'attributes': {u'dn': u'sys/epId-1/peers/dy_peer-17.0.101.1', u'upStateTransitionTs': u'1969-12-31T17:00:00.000+00:00', u'ip': u'17.0.101.1', u'createTs': u'2017-04-24T11:01:56.897+00:00', u'state': u'Down', u'mac': u'00:00:00:00:00:00', u'firstVNI': u'4002', u'rn': u''}}}], u'subscriptionId': [u'18374686685813276682']}



>>> URL : /network/sys%2FepId-1

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/epId-1

node_id_str : Leaf4

collection_id : 7

data_source : DME





>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1






data_source : DME

data : {u'imdata': [{u'bgpPeerEntry': {u'attributes': {u'dn': u'sys/bgp/inst/dom-default/peer-[17.0.0.0/16]/ent-[17.0.101.1]', u'status': u'modified', u'rn': u'', u'updateElapsedTs': u'2017-04-24T11:01:58.642+00:00', u'childAction': u''}}}], u'subscriptionId': [u'18374686715878047750']}

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.


Leaf4# sh run tele


!Time: Tue Apr 25 11:36:15 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


sensor-group 1

path sys/bd/bd-[vlan-100] depth 0 filter-condition and(updated(l2BD.operSt),eq(l2BD.operSt,"down"))

subscription 1

dst-grp 1



--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/bd/bd-[vlan-100]

Leaf4# sh vlan id 100

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

100 VLAN0100 active Po10, Po20, Eth1/5, Eth1/6

Eth1/7, Eth1/8

VLAN Type Vlan-mode

---- ----- ----------

100 enet CE

Remote SPAN VLAN

----------------

Disabled

Primary Secondary Type Ports

------- --------- --------------- -------------------------------------------

Simulating a condition for VLAN 100 to be admin down

Leaf4# conf t

Enter configuration commands, one per line. End with CNTL/Z.

Leaf4(config)# vlan 100

Leaf4(config-vlan)# sh

Leaf4(config-vlan)# end

Leaf4# sh vlan id 100

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

100 VLAN0100 act/lshut Po10, Po20, Eth1/5, Eth1/6

Eth1/7, Eth1/8

VLAN Type Vlan-mode

---- ----- ----------

100 enet CE

Remote SPAN VLAN

----------------

Disabled

Primary Secondary Type Ports

------- --------- --------------- -------------------------------------------


--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

1 Tue Apr 25 11:37:35.941 PST sys/bd/bd-[vlan-100]


172.19.198.125 - - [25/Apr/2017 11:37:35] "POST /network/sys%2Fbd%2Fbd-%5Bvlan-100%5D HTTP/1.0" 200 -

172.19.198.125 - - [25/Apr/2017 11:37:35] "POST /network/sys%2Fbd%2Fbd-%5Bvlan-100%5D HTTP/1.0" 200 -

>>> URL : /network/sys%2Fbd%2Fbd-%5Bvlan-100%5D

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/bd/bd-[vlan-100]

node_id_str : Leaf4

collection_id : 124

data_source : DME

data : {u'imdata': [{u'l2BD': {u'attributes': {u'dn': u'sys/bd/bd-[vlan-100]', u'status': u'modified', u'rn': u'', u'operSt': u'down', u'childAction': u''}}}], u'subscriptionId': [u'18374686548374323201']}

10 Use Case 8: Telemetry Event Notification When VRF Is Down




!Time: Tue Apr 25 11:40:37 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


sensor-group 1

path sys/bgp/inst/dom-test309 depth 0 filter-condition eq(bgpDom.operSt,"down")

subscription 1

dst-grp 1



--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/bgp/inst/dom-test309

Leaf4# sh vrf test309

VRF-Name VRF-ID State Reason

test309 236 Up --

Simulating a condition for the VRF to go down

Leaf4(config)# vrf context test309

Leaf4(config-vrf)# shut

Leaf4(config-vrf)# end

Leaf4#

Leaf4# sh vrf test309

VRF-Name VRF-ID State Reason

test309 236 Down Admin Down Pending


172.19.198.125 - - [25/Apr/2017 11:42:02] "POST /network/sys%2Fbgp%2Finst%2Fdom-test309 HTTP/1.0" 200 -

172.19.198.125 - - [25/Apr/2017 11:42:02] "POST /network/sys%2Fbgp%2Finst%2Fdom-test309 HTTP/1.0" 200 -

>>> URL : /network/sys%2Fbgp%2Finst%2Fdom-test309

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/bgp/inst/dom-test309

node_id_str : Leaf4

collection_id : 125

data_source : DME

data : {u'imdata': [{u'bgpDom': {u'attributes': {u'dn': u'sys/bgp/inst/dom-test309', u'status': u'modified', u'rn': u'', u'operSt': u'down', u'childAction': u''}}}], u'subscriptionId': [u'18374686548374323202', u'18374686548374323203', u'18374686548374323204']}

11 Use Case 9: Telemetry Event Notification When ACL Packets Exceed a Threshold

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.


path sys/acl/ipv4/name-test/seq-10 depth 0 filter-condition gt(ipv4aclACE.packets,"25")


--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

1 Tue Mar 07 15:18:17.309 PST sys/acl/ipv4/name-test/seq-10

Leaf4# sh ip access-lists test

IP access list test

statistics per-entry

10 permit ip 20.20.20.102/32 20.20.20.1 0.0.0.255 [match=30]

12 Use Case 10: Telemetry Event Notification When an SVI Goes Down

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.


path sys/intf/svi-[vlan2810] depth 0 filter-condition eq(sviIf.operSt,"down")


--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/intf/svi-[vlan2810]

Leaf2# sh int vlan2810

Vlan2810 is up, line protocol is up, autostate enabled

Hardware is EtherSVI, address is f8c2.8887.d3a7

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive not supported

ARP type: ARPA

Last clearing of "show interface" counters never

L3 in Switched:

ucast: 0 pkts, 0 bytes

Leaf2# conf t


Leaf2(config)# vrf context test310

Leaf2(config-vrf)# shut

Leaf2(config-vrf)# end


--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

2 Tue Mar 07 15:33:28.172 PST sys/intf/svi-[vlan2810]

Leaf2# sh int vlan2810

Vlan2810 is down (VRF Unusable), line protocol is down, autostate enabled

Hardware is EtherSVI, address is f8c2.8887.d3a7

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,


Encapsulation ARPA, loopback not set

Keepalive not supported

ARP type: ARPA


L3 in Switched:

ucast: 0 pkts, 0 bytes

13 Use Case 11: Telemetry Event Generation When Number of BGP Established Peers Reaches 0


Leaf4# sh run tele


!Time: Tue Apr 25 13:43:47 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


sensor-group 1

path sys/bgp/inst/dom-default depth 0 filter-condition eq(bgpDom.numEstPeers,"0")

subscription 1

dst-grp 1



--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/bgp/inst/dom-default









7.7.7.7 4 1000 32387 22610 761546 0 0 1d02h 3998

Simulating a condition for BGP peering to go down









7.7.7.7 4 1000 32391 22613 0 0 0 00:00:06 Idle


--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

1 Tue Apr 25 13:46:43.662 PST sys/bgp/inst/dom-default


172.19.198.125 - - [25/Apr/2017 13:46:43] "POST /network/sys%2Fbgp%2Finst%2Fdom-default HTTP/1.0" 200 -

172.19.198.125 - - [25/Apr/2017 13:46:43] "POST /network/sys%2Fbgp%2Finst%2Fdom-default HTTP/1.0" 200 -

>>> URL : /network/sys%2Fbgp%2Finst%2Fdom-default

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/bgp/inst/dom-default

node_id_str : Leaf4

collection_id : 126

data_source : DME

data : {u'imdata': [{u'bgpDom': {u'attributes': {u'dn': u'sys/bgp/inst/dom-default', u'status': u'modified', u'rn': u'', u'numEstPeers': u'0', u'childAction': u''}}}], u'subscriptionId': [u'18374686552669290501']}

14 Use Case 12: Telemetry Event Notification When Number of BGP L2VPN EVPN Routes Goes Below a Threshold


In this use case, the switch sends an event notification when the number of BGP L2VPN EVPN accepted routes equals 3600.

Leaf1# sh run tele


!Time: Fri Mar 10 07:00:09 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


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


Leaf1# show bgp l2vpn evpn summary








7.7.7.7 4 1000 65718 37408 2635876 0 0 21:08:06 103600

Leaf1# show telemetry event collector stats

--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]/af-l2vpn-evpn

Withdrawing the routes

Leaf1# show telemetry event collector stats

--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

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


Recevied GBP RPC at: Fri Mar 10 10:19:55 2017

Data size is: 551

header {

collection_id: 426

path: sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]/af-l2vpn-evpn

hostname: Leaf1

fields {

name: keys

value:

}

fields {

name: content

value:

subfields {

name: subscriptionId

value: 18374686514014584844

}

subfields {

name: imdata

subfields { name: imdata

subfields {

name: bgpPeerAfEntry

subfields {

name: attributes

subfields {

name: acceptedPaths

value: 3600

}

subfields {

name: childAction

value:

}

subfields {

name: dn

value: sys/bgp/inst/dom-default/peer-[7.7.7.7]/ent-[7.7.7.7]/af-l2vpn-evpn

}

subfields {

name: memAccPaths

value: 460800

}

15 Use Case 13: Telemetry Event Notification When a Particular NVE Peer Is Up


Leaf4# sh run tele


!Time: Tue Apr 25 14:06:06 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


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



--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/epId-1/peers/dy_peer-17.0.101.1

Leaf4# sh nve peer


--------- --------------- ----- --------- -------- -----------------

nve1 12.12.12.12 Up CP 00:15:45 f8c2.8887.d3a7

Simulating a condition for NVE peering to occur

Leaf4# sh nve peer


--------- --------------- ----- --------- -------- -----------------

nve1 12.12.12.12 Up CP 00:19:28 f8c2.8887.d3a7

nve1 17.0.101.1 Up CP 00:00:04 7056.0001.1101


--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

1 Tue Apr 25 14:09:53.250 PST sys/epId-1/peers/dy_peer-17.0.101.1




>>> URL : /network/sys%2FepId-1%2Fpeers%2Fdy_peer-17.0.101.1

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/epId-1/peers/dy_peer-17.0.101.1

node_id_str : Leaf4

collection_id : 127

data_source : DME


16 Use Case 14: Telemetry Event Notification When Any NVE Peer Comes Up

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.


Leaf2# sh run tele


!Time: Mon Mar 20 12:48:48 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


sensor-group 1

path sys/epId-1/peers depth unbounded

subscription 1

dst-grp 1


Leaf2# sh nve peers


--------- --------------- ----- --------- -------- -----------------

nve1 34.34.34.34 Up CP 03:55:07 f8c2.88b5.de85


--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/epId-1/peers

Simulating a condition when multiple NVE peers come up


--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

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.



!Time: Thu Mar 23 10:50:50 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1




sensor-group 1

path sys/epId-1/nws depth unbounded

subscription 1

dst-grp 1


Leaf4# sh nve vni 4002

Codes: CP - Control Plane DP - Data Plane

UC - Unconfigured SA - Suppress ARP

Interface VNI Multicast-group State Mode Type [BD/VRF] Flags

--------- -------- ----------------- ----- ---- ------------------ -----

nve1 4002 225.0.0.1 Up CP L2 [2] SA

Simulating a condition for MCT link going down and checking the state for a particular VNI





--------- -------- ----------------- ----- ---- ------------------ -----

nve1 4002 225.0.0.1 Down CP L2 [2] SA


172.19.198.125 - - [25/Apr/2017 15:02:16] "POST /network/sys%2FepId-1%2Fnws HTTP/1.0" 200 -

172.19.198.125 - - [25/Apr/2017 15:02:16] "POST /network/sys%2FepId-1%2Fnws HTTP/1.0" 200 -

>>> URL : /network/sys%2FepId-1%2Fnws

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/epId-1/nws

node_id_str : Leaf4

collection_id : 128

data_source : DME

data : {u'imdata': [{u'nvoNw': {u'attributes': {u'dn': u'sys/epId-1/nws/vni-4002', u'status': u'modified', u'rn': u'', u'state': u'Down', u'childAction': u''}}}], u'subscriptionId': [u'18374686552669290507']}

18 Use Case 16: Telemetry Event Notification When Member Link of a Port-Channel Interface Goes Down

In this use case, the port channel is 20. It has two member links.


Leaf4# sh run tele


!Time: Tue Apr 25 15:48:57 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


sensor-group 1

path sys/intf/aggr-[po20]/aggrif depth 0 filter-condition ne(ethpmAggrIf.numActivePorts,"2")

subscription 1

dst-grp 1



--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

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)


Shutting down one of the member links

Leaf4# conf t


Leaf4(config)# int e1/7

Leaf4(config-if)# sh

Leaf4(config-if)# end

Leaf4# sh port

port-channel port-profile










--------------------------------------------------------------------------------


Channel

--------------------------------------------------------------------------------


20 Po20(SU) Eth LACP Eth1/7(D) Eth1/8(P)


--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

1 Tue Apr 25 15:51:19.294 PST sys/intf/aggr-[po20]/aggrif


172.19.198.125 - - [25/Apr/2017 15:51:19] "POST /network/sys%2Fintf%2Faggr-%5Bpo20%5D%2Faggrif HTTP/1.0" 200 -


>>> URL : /network/sys%2Fintf%2Faggr-%5Bpo20%5D%2Faggrif

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/intf/aggr-[po20]/aggrif

node_id_str : Leaf4

collection_id : 134

data_source : DME

data : {u'imdata': [{u'ethpmAggrIf': {u'attributes': {u'dn': u'sys/intf/aggr-[po20]/aggrif', u'status': u'modified', u'numActivePorts': u'1', u'activeMbrs': u'eth1/8,unspecified,unspecified,unspecified,unspecified,unspecified,unspecified,unspecified,unspecified,unspecified,unspecified,unspecified,unspecified,unspecified,unspecified,unspecified', u'numMbrUp': u'1', u'rn': u'', u'childAction': u''}}}], u'subscriptionId': [u'18374686552669290510']}

19 Use Case 17: Telemetry Event Notification When a Particular VNI Goes Down


Leaf4# sh run tele


!Time: Tue Apr 25 15:57:10 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


sensor-group 1

path sys/epId-1/nws/vni-4002 depth 0 filter-condition eq(nvoNw.state,"Down")

subscription 1

dst-grp 1



--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/epId-1/nws/vni-4002





--------- -------- ----------------- ----- ---- ------------------ -----

nve1 4002 225.0.0.1 Up CP L2 [2] SA

Leaf4# conf t


Leaf4(config)# vlan 2

Leaf4(config-vlan)# sh

Leaf4(config-vlan)# end





--------- -------- ----------------- ----- ---- ------------------ -----

nve1 4002 225.0.0.1 Down CP L2 [2] SA


172.19.198.125 - - [25/Apr/2017 15:58:09] "POST /network/sys%2FepId-1%2Fnws%2Fvni-4002 HTTP/1.0" 200 -

172.19.198.125 - - [25/Apr/2017 15:58:09] "POST /network/sys%2FepId-1%2Fnws%2Fvni-4002 HTTP/1.0" 200 -

>>> URL : /network/sys%2FepId-1%2Fnws%2Fvni-4002

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/epId-1/nws/vni-4002

node_id_str : Leaf4

collection_id : 136

data_source : DME

data : {u'imdata': [{u'nvoNw': {u'attributes': {u'dn': u'sys/epId-1/nws/vni-4002', u'status': u'modified', u'rn': u'', u'state': u'Down', u'childAction': u''}}}], u'subscriptionId': [u'18374686552669290514']}

20 Use Case 18: Event Notification When Port-Channel Interface Goes Down


Leaf4# sh run tele


!Time: Tue Apr 25 16:15:51 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


sensor-group 1

path sys/intf/aggr-[po20]/aggrif depth 0 filter-condition eq(ethpmAggrIf.operSt,"down")

subscription 1

dst-grp 1



--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/intf/aggr-[po20]/aggrif










--------------------------------------------------------------------------------


Channel

--------------------------------------------------------------------------------



Shutting down the port-channel 20 interface

Port-channel interface (vPC leg) on a vPC secondary goes down if the MCT link goes down.

Users can monitor this scenario.










--------------------------------------------------------------------------------


Channel

--------------------------------------------------------------------------------


20 Po20(SD) Eth LACP Eth1/7(D) Eth1/8(D)




>>> URL : /network/sys%2Fintf%2Faggr-%5Bpo20%5D%2Faggrif

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/intf/aggr-[po20]/aggrif

node_id_str : Leaf4

collection_id : 139

data_source : DME

data : {u'imdata': [{u'ethpmAggrIf': {u'attributes': {u'dn': u'sys/intf/aggr-[po20]/aggrif', u'status': u'modified', u'operStQual': u'admin-down', u'operSt': u'down',

u'lastLinkStChg': u'2017-04-25T16:18:38.290+00:00', u'rn': u'', u'childAction': u''}}}], u'subscriptionId': [u'18374686552669290517']}

21 Use Case 19: Event Notification When a Physical Interface Goes Down

This use case monitors the operational state of interface Ethernet 1/1.

When the interface goes down, a telemetry event notification is sent.


Leaf4# sh run tele


!Time: Tue Apr 25 16:25:35 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


sensor-group 1

path sys/intf/phys-[eth1/1]/phys depth 0 filter-condition eq(ethpmPhysIf.operSt,"down")

subscription 1

dst-grp 1



--------------------------------------------------------------------------------


--------------------------------------------------------------------------------

0 Not yet collect sys/intf/phys-[eth1/1]/phys

Leaf4# sh int e1/1

Ethernet1/1 is up

admin state is up, Dedicated Interface

Hardware: 1000/10000 Ethernet, address: f8c2.88b5.de85 (bia f8c2.88b5.de86)

Internet Address is 47.47.47.4/24

MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec


Encapsulation ARPA, medium is broadcast

full-duplex, 10 Gb/s, media type is 10G

Beacon is turned off

Auto-Negotiation is turned on, FEC mode is Auto

Input flow-control is off, output flow-control is off

Auto-mdix is turned off

Rate mode is dedicated

Switchport monitor is off

EtherType is 0x8100

EEE (efficient-ethernet) : n/a

Last link flapped 1d04h


1 interface resets

Shutting down the interface

Leaf4# conf t


Leaf4(config)# int e1/1

Leaf4(config-if)# shut

Leaf4(config-if)# end

Leaf4# sh int e1/1

Ethernet1/1 is down (Administratively down)

admin state is down, Dedicated Interface

Hardware: 1000/10000 Ethernet, address: f8c2.88b5.de85 (bia f8c2.88b5.de86)

Internet Address is 47.47.47.4/24

MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec


Encapsulation ARPA, medium is broadcast

auto-duplex, 10 Gb/s, media type is 10G

Beacon is turned off

Auto-Negotiation is turned on, FEC mode is Auto

Input flow-control is off, output flow-control is off

Auto-mdix is turned off

Rate mode is dedicated

Switchport monitor is off

EtherType is 0x8100

EEE (efficient-ethernet) : n/a

Last link flapped 00:00:05


1 interface resets


172.19.198.125 - - [25/Apr/2017 16:48:13] "POST /network/sys%2Fintf%2Fphys-%5Beth1%2F1%5D%2Fphys HTTP/1.0" 200 -

172.19.198.125 - - [25/Apr/2017 16:48:13] "POST /network/sys%2Fintf%2Fphys-%5Beth1%2F1%5D%2Fphys HTTP/1.0" 200 -

>>> URL : /network/sys%2Fintf%2Fphys-%5Beth1%2F1%5D%2Fphys

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => sys/intf/phys-[eth1/1]/phys

node_id_str : Leaf4

collection_id : 144

data_source : DME

data : {u'imdata': [{u'ethpmPhysIf': {u'attributes': {u'dn': u'sys/intf/phys-[eth1/1]/phys', u'status': u'modified', u'operBitset': u'4,7,35', u'operSt': u'down', u'lastLinkStChg': u'2017-04-25T16:48:13.779+00:00', u'rn': u'', u'childAction': u''}}}], u'subscriptionId': [u'18374686552669290520']}

22 Use Case 20: Event Generation When a New Host Is Learned and NVE Peering Is Established (Using the NX-API Data Collector Approach)

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.


Leaf4# sh run tele


!Time: Tue Apr 25 11:11:01 2017

version 7.0(3)I6(1)

feature telemetry

telemetry

destination-group 1


sensor-group 1

data-source NX-API

path "show nve peers" depth 0

subscription 1

dst-grp 1


Leaf4# sh telemetry data collector brief

----------------------------------------------------------------------

Collector Type Successful Failed Skipped

----------------------------------------------------------------------

NX-API 0 0 0

DME 0 0 0

Leaf4# sh nve peer


--------- --------------- ----- --------- -------- -----------------

nve1 12.12.12.12 Up CP 23:32:03 f8c2.8887.d3a7

New NVE peering is learned

Leaf4# sh nve peers


--------- --------------- ----- --------- -------- -----------------

nve1 12.12.12.12 Up CP 23:37:46 f8c2.8887.d3a7

nve1 17.0.101.1 Up CP 00:00:59 7056.0001.1101


172.19.198.125 - - [25/Apr/2017 11:16:01] "POST /network/show%20nve%20peers HTTP/1.0" 200 -

172.19.198.125 - - [25/Apr/2017 11:16:01] "POST /network/show%20nve%20peers HTTP/1.0" 200 -

>>> URL : /network/show%20nve%20peers

>>> TM-HTTP-VER : 1.0.0

>>> TM-HTTP-CNT : 1



Path => show nve peers

node_id_str : Leaf4

collection_id : 11

data_source : NX-API

data : {u'TABLE_nve_peers': {u'ROW_nve_peers': [{u'uptime': u'23:36:48', u'if-name': u'nve1', u'router-mac': u'f8c2.8887.d3a7', u'peer-state': u'Up', u'peer-ip': u'12.12.12.12', u'learn-type': u'CP'}, {u'uptime': u'00:00:01', u'if-name': u'nve1', u'router-mac': u'7056.0001.1101', u'peer-state': u'Up', u'peer-ip': u'17.0.101.1', u'learn-type': u'CP'}]}}

23 Use Case 21: NX-API-Based Approach to Get Node Inventory Data and Other Data

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


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


Leaf3# sh telemetry control database

Subscription Database size = 1

--------------------------------------------------------------------------------

Subscription ID Data Collector Type

--------------------------------------------------------------------------------

1 NX-API

Sensor Group Database size = 1

--------------------------------------------------------------------------------

Sensor Group ID Sensor Group type Sampling interval(ms) Linked subscriptions

--------------------------------------------------------------------------------

1 Timer /NX-API 750000(Running) 1

Collection Time in ms (Cur/Min/Max): 226052/225273/227374

Streaming Time in ms (Cur/Min/Max): 227127/226264/229132

Sensor Path Database size = 16

--------------------------------------------------------------------------------

Subscribed Linked Groups Sec Groups Retrieve level Sensor Path : Query Filter

--------------------------------------------------------------------------------

No 1 0 Self show environment power

No 1 0 Self show vlan counters

No 1 0 Self show policy-map vlan

No 1 0 Self show process cpu

No 1 0 Self show environment fan

No 1 0 Self show environment temperature

No 1 0 Self show version

No 1 0 Self show ip access-list test

No 1 0 Self show system internal access-list resource utilization

No 1 0 Self show system resources

No 1 0 Self show nve vni

No 1 0 Self show interface counters

No 1 0 Self show int nve 1 counters

No 1 0 Self show nve vni 4002 counters

No 1 0 Self show nve peers

Destination group Database size = 1

--------------------------------------------------------------------------------

Destination Group ID Refcount

--------------------------------------------------------------------------------

1 1

Destination Database size = 1

--------------------------------------------------------------------------------

Dst IP Addr Dst Port Encoding Transport Count

--------------------------------------------------------------------------------

172.27.247.72 60002 GPB gRPC 1

Leaf3# sh telemetry data collector br

----------------------------------------------------------------------

Collector Type Successful Failed Skipped

----------------------------------------------------------------------

DME 0 0 0

NX-API 165 0 0

Leaf3# sh telemetry data collector details

--------------------------------------------------------------------------------

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 ([email protected]). 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 ([email protected]).

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)

© 2017 Cisco Systems, Inc. All rights reserved.

Documents

Telemetry Deployment for VXLAN EVPN Solution€¦ · Telemetry Deployment for VXLAN EVPN Solution . This document is targeted for users who are planning to deploy the Cisco Nexus