SNMP and Streaming Telemetry

Kentik support for Streaming Telemetry is covered in the following topics:

• SNMP vs. Streaming Telemetry
• SNMP and ST KDE Support
• Streaming Telemetry Device Support

Notes:
- This article discusses Kentik's non-NMS Streaming Telemetry implementation. For information about Streaming Telemetry for Kentik NMS, see NMS via Streaming Telemetry).
- For additional information about SNMP polling, see SNMP OID Polling.

Simple Network Management Protocol (SNMP) provides a standardized protocol for remotely monitoring and managing devices on IP networks, including routers, switches, and firewalls. SNMP was designed around a pull model in which the recipient of the data (the network monitoring and/or control system) polls the device at a regular interval, typically every five minutes. All of the various types of network management information that might be available from a router (counters, information, etc.) are codified as objects represented by identifiers (OIDs; see https://tools.ietf.org/html/rfc1155). SNMP enables network managers to get and set the properties of these objects.

While SNMP has served its purpose effectively for three decades, the speed and scale of networks has changed drastically over that time, revealing some shortcomings. The pull model can require significant overhead, and the polling interval involves a compromise: if it's too long (not granular enough), spin-up and spin-down of resources may be missed; if it's too short it eats up overhead and impacts performance.

To address these issues, Streaming Telemetry (ST) was developed as an alternative to SNMP. With ST, instead of being polled the device publishes a continuous stream of data that is subscribed to by one or more network monitoring systems. An ST data model implemented on each device specifies which data to track and how frequently to publish it. Incremental updating increases efficiency by transmitting only values that have changed since the previous publication.

Despite it's advantages, the replacement of SNMP with ST will be gradual. In part that's a consequence of the extent to which SNMP is entrenched after decades of deployment. But it also reflects that so far the networking community hasn't yet coalesced around a strong unified ST standard. Instead ST has emerged as a range of non-standardized approaches, with different vendors using different techniques to define the elements and interfaces used for data collection, transmission, and extraction.

Note: For additional insight into Kentik's perspective on Streaming Telemetry, see our blog post Streaming Telemetry for Network Monitoring and Analytics.

The core backend technology behind Kentik is KDE (see About Kentik Data Engine), the scalable, columnar datastore that ingests and stores your traffic data. In addition to flow data such as NetFlow and sFlow, KDE correlates a wide variety of additional data into flow records in KDE (see What traffic data is collected?), including SNMP and Streaming Telemetry data.

If your devices are configured to accept SNMP polling from Kentik (see SNMP OID Polling), SNMP is included in the information stored in KDE flow records. Kentik currently polls two basic kinds of OIDs:

• Counter OIDs: Generally represented as SNMP Metrics in the Kentik portal, these objects are listed in the table at Counter SNMP OIDs.
• Information OIDs: Generally represented as SNMP Dimensions in the Kentik portal, these objects are listed in the table at Information SNMP OIDs.

If your devices are configured to publish ST data to Kentik, ST is included in the information stored in KDE flow records. KDE currently stores two basic kinds of ST-related data:

• The ST metrics available in the Kentik portal are listed in Streaming Telemetry Metrics. These metrics generally correspond to metrics that are also available via SNMP, and the paths to which the metrics are published are shown in the Streaming Telemetry Path column of the table at Counter SNMP OIDs.
• The dimensions that are available in the Kentik portal when querying ST-derived data are listed in Streaming Telemetry Dimensions.

Note: For information about Streaming Telemetry for Kentik NMS, see NMS via Streaming Telemetry).

While SNMP support in devices (routers, switches) is effectively universal, vendor support for streaming telemetry is still a work in progress. Kentik support for ST, which will continue to evolve as vendor support matures, is described in the following topics:

• ST Via Agent or Direct
• ST for Junos
• ST for IOS-XRv 9000

Note: For information about Streaming Telemetry device support for Kentik NMS, see NMS Device Support).

We currently make available two ways to send ST to KDE:

• ST via agent: Kentik's software proxy agent, kproxy, acts as the collector to which the device sends ST data; kproxy then forwards the data to KDE.
• ST direct: The device sends ST data directly to KDE.

The topics below explain how these two approaches are implemented for the various devices that Kentik currently supports for ST.

Routers running Juniper's Junos OS (version 18.4R2.7 or later) can send (as UDP) streaming telemetry to Kentik via kproxy or directly:

• To send ST via kproxy:
  - Configure ST on the device using the configuration information at https://github.com/kentik/config-snippets/blob/master/Juniper/MX-series/telemetry_native-agent.conf.
  - Set kproxy to collect ST data using the dialout_listener argument documented in kproxy for Streaming Telemetry.
• To send ST directly:
  - Configure ST on the device using the configuration information at https://github.com/kentik/config-snippets/blob/master/Juniper/MX-series/telemetry_native.conf.
  - Contact your Kentik Customer Support team to request implementation of ST collection on your account.

Cisco IOS-XRv 9000 routers (version 6.2.3 or later) can send (as TCP) streaming telemetry to Kentik via kproxy or directly:

• To send ST via kproxy:
  - Configure ST on the device using the configuration information at https://github.com/kentik/config-snippets/blob/master/Cisco/IOS-XR/telemetry_dialout-agent.conf.
  - Set kproxy to collect ST data using the tcp_bind argument documented in kproxy for Streaming Telemetry.
• To send ST directly:
  - Configure ST on the device using the configuration information at https://github.com/kentik/config-snippets/blob/master/Cisco/IOS-XR/telemetry_dialout.conf.
  - Contact your Kentik Customer Support team to request implementation of ST collection on your account.