Have you ever wondered?: The similarities and differences between SNMP and Telemetry.

September 28^th 2022, Würzburg

For StableNet^®, we typically tend to look at telemetry as yet another means by which device attributes and states can be consolidated in an over-arching network management platform. Whether telemetry will eventually be seen as a paradigmatic shift that replaces SNMP has yet to be seen and is too far down the road to even hazard a guess at this point. Instead, we see a successful multi-technology network and service management solution as needing to integrate both standards (although one might argue that there is no standard for telemetry as of yet).

To give ourselves and our readers a deeper understanding, we had an external, IT specialist sit down and give us an overview on his take of just where the differences and similarities lie. We hope you enjoy.

– Dr. David Toumajian, Director of Marketing

What is Simple Network Management Protocol (SNMP)?

SNMP is not a product but a set of rules. It is defined by the Internet Architecture Council and is part of the TCP/IP package. SNMP is managed and maintained by the Internet Engineering Task Force (IETF).

The protocol allows system administrators to monitor and control network performance and change the configuration of connected devices. SNMP is used in networks of any size: the larger the network, the more the advantages of the protocol are revealed.

It allows you to view, monitor, and manage nodes through a single interface with batch commands and automatic notification features.
Thus, SNMP relieves the administrator of the need to enter commands manually. A total of three versions were developed and deployed. All are still in use, and the second one, SNMPv2c, has become the most common.

The SNMP architecture

The components that make up the SNMP architecture are:

• • a network management station including a network manager;
  • agents;
  • master agents;
  • Managed components.

Network Management Station – NMS

Agents

Subagent: It is a program supplied by the vendor along with the network device. The subagent forwards the collected information to the master agent. Each managed device has a corresponding subagent.

Managed Component: It is a network-connected device or software with an embedded subagent.
Such devices include not only routers, switches, and servers. But also IP video cameras, MFPs, and IP phones. Software with subagents also includes anti-virus programs, backup systems, and software for UPS systems.

Management Information Base – MIB

Object identifier – OID

Theory and logic of the SNMP protocol

Purpose

Protocol Data Unit (PDU)

There are seven PDUs in SNMP:

• • GET – request the NMS manager to receive data from the device.
  • GETNEXT is a request similar to
  • GET. The only difference is that the manager requests data that is at the next level of the OID hierarchy in the MIB.
  • SET – with this request, the manager changes or assigns new data to the device.
  • RESPONSE – a message from the agent sent in response to a request for data.
  • TRAP – notification of an event or error that has occurred. The agent sends it immediately after the event occurs without waiting for the manager’s request. The manager does not acknowledge receipt of the message in any way, which can be a problem.
  • GETBULK – a request to the agent to retrieve an array of data from the device. It is an improved version of the GETNEXT query.
  • INFORM – a message similar to TRAP, but with an acknowledgment of receipt.

INFORM and GETBULK are only available in the second and third versions of the SNMP protocol.

SNMP Protocol Versions

SNMPv2c: The second version of the SNMP protocol appeared in 1993. The developers have added a new GetBulk request and an Inform hook, as well as improved security. This version has two ways to communicate with devices that support SNMPv1: a bilingual network management system and proxy agents. Proxy agents act as master agents, and in a bilingual management system, the manager determines which version of SNMP an agent supports and communicates with it via SNMPv1 or SNMPv2c.

SNMPv3: The third version was released in 1998. The developers added cryptographic protection to SNMP and facilitated remote configuration and administration of objects. It was achieved by defining a set of standardized management objects called Remote Network Monitoring MIBs, the RMON MIB.

In network operation, monitoring technology is important for fault detection and performance analysis.

Conventional networks widely use a technology called SNMP.

SNMP is a UDP-based network monitoring technology. The data model is defined in a database called MIB (Management Information Base), and there are standard MIBs common to all vendors and unique extension MIBs.

The SNMP information acquirer is called SNMP Manager, and the information issuer is called SNMP Agent. As information acquisition methods, there are Polling, in which SNMP Manager acquires information on a request basis, and Trap, in which SNMP Agent sends information on a trigger basis.

The following three points can be cited as problems with conventional SNMP.

• • High-load processing structure
  • The complexity of management in a multi-vendor environment
  • Limitation of scalability in N-to-N configuration

Network monitoring requires the acquisition of traffic volume and device load information (memory, CPU, temperature, etc.). However, since SNMP polling is request-based, narrowing the interval to obtain high-definition information will increase the CPU load and processing time.

With SNMP, there is a lack of standard MIBs. Therefore, in order to obtain the same information in a multi-vendor environment, it is necessary to specify the extended MIB OID (Object ID) unique to each model which increases management costs.

In summary, SNMP has the following three problems.

• • Decrease in obtainable information accuracy and loss of real-time performance due to high-load protocol structure
  • The complexity of management in a multi-vendor environment due to the lack of standard MIBs
  • Scale issues when constructing an N-to-N configuration

Telemetry technology is expected as a monitoring technology to solve these problems.

What is Telemetry?

Telemetry is a next-generation network monitoring technology, and it is being studied and implemented by various companies and standardized by OpenConfig.

Telemetry is generally designed to have three characteristics:

• • Acquisition of high-definition, real-time information by low-load protocol design compared to SNMP
  • Vendor-free information acquisition by OpenConfig
  • High scalability due to easy-to-deploy Pub/Sub model design

Based on these characteristics, it is expected to be a technology that can solve the problems of SNMP mentioned in the previous section.

Telemetry employs a data transmission/reception model called the Pub/Sub model.

The Pub/Sub model consists of the following three elements.

• • Publisher: Publisher (sender). publish a message
  • Broker: an intermediary. mediate messages
  • Subscriber: Subscriber (recipient). Get and use messages

Advantages of the Pub/Sub model include: (1) message senders and receivers do not need to recognize each other directly and are asynchronous and loosely coupled; One of the reasons is its large scale. Information is managed by an attribute called Topic, and Publishers/Subscribers send/receive data by specifying the Topic.

Publisher

A Publisher is the publisher of a message and consists of three elements:

• • Network equipment to be monitored
  • Transport part that connects the monitored device and the Collector
  • Collector to receive data from Publisher.

As concepts related to monitored devices, I will explain the information model and the classification of connection methods.

There are mainly two types of device information models: OpenConfig and vendor native. OpenConfig is a network configuration model that is being standardized assuming vendor-neutral use and is defined according to YANG. On the other hand, vendor-native is an information model specific to each product. It generally has better support than OpenConfig and tends to have a wealth of information that can be handled.

The information issued by the device is specified in advance by a data path called Sensor-Path. And it issues messages at predetermined intervals and sends them to the Collector.

Broker

Message Queue is an element that relays messages, and the main implementations include Apache Kafka and Cloud Pub/Sub/SQS in Public Cloud. Common implementations often have mechanisms for redundancy, such as clustering and mirroring.

Subscriber

Background of Telemetry

Telemetry is an old term coined from Tele = Remote and Metry = Measure. In that sense, SNMP and xFlow can also be considered a type of Telemetry. But it may be easier to understand if you understand “Telemetry” introduced in this column as the next-generation version of SNMP.

SNMP challenges

When legacy SNMP is applied to a Hyper-Scale environment, there are performance issues, narrowing the polling interval (because it requires a lot of resources on the network device side), and when multiple Pollers exist, the processing on the device side becomes stuck. It leads to a loss of real-time performance. In addition, there are limitations in terms of flexibility, and it is not possible to apply new data models (YANG, etc.) that are used in various applications and are becoming mainstream in recent years. It is difficult to say that SNMP is suitable for current and future network operations, as it does not support new transport protocols such as SNMP.

In the case of SNMP, the exchange of statistical information via OID is request-based, so the device side is burdened with request processing. Each time there is a request, the device retrieves the information in the same lexicographical order and processes the response. In terms of SNMP, SNMP is equivalent to telephony (answers calls if they are made, calls are not completed, and no new calls are accepted and put on hold).

On the other hand, Telemetry differs from SNMP in that it is not based on request/response format but on a Subscription (subscription declaration) basis. For a particular statistic, the device distributes the statistic to subscribers on a regular basis rather than calling multiple subscribers when they need the information.

Telemetry Explanation

Against this background, a concept called Telemetry was born as a new means to replace SNMP. Google, the center of development, lists the following as Telemetry’s Framework Requirements:

• • Network device sends Data to Collector in stream format (Push model)
  • Publish/Subscribe model, select arbitrary Data, and declare Subscribe
  • Data model is Vendor neutral or Open-config
  • Technology that can withstand data increase in the next 10 years

Telemetry Data type

• • Periodic transmission type: “Example” Send all interface information every 10 seconds
  • Event trigger type: “Example ” When a specific LSP goes down, the status is sent.
  • Operator request type: [Example] Any request on the operator’s side is used as a trigger to send

Now, let’s take a look at some of the technical elements that are important in meeting the above requirements.

gRPC (Google Remote Procedure Call)

gRPC is a multi-platform RPC Framework with the following features.

• • Load balance, application-level flow control, call canceling
  • Supports bi-directional streams and server push
  • Multi-platform (supports multiple languages)
  • Stream connection multiplexing
  • Open source

From these functions, it is possible to use HTTP/2 as if it were a transport layer that operates independently (by using gRPC), and on top of that, information can be obtained by RPC (Remote Procedure Call) increase. In addition, since it was originally a protocol aimed at improving the efficiency of communication between components in a distributed computing environment, weight reduction as a protocol and rapid response is emphasized.

* These days, when Micro-Service is attracting attention, rapid communication between components is very important.

GPB (Google Protocol Buffers)

OpenConfig

Final comparison of Telemetry and SNMP

Now, let’s take a last look at the differences between Telemetry and SNMP.

SNMP uses the polling method, which requests information each time information is acquired, but Telemetry uses the subscription method. Regarding transport, SNMP is a UDP-only implementation, but Telemetry uses gRPC in addition to UDP/TCP and uses a flow-controlled transport layer. SNMP uses ASN.1 BER for encoding, but Telemetry uses GPB, which is much lighter. In addition, by adopting OpenConfig for the data model, it is possible to obtain various information from the device with a common data model that does not depend on the vendor. Performance-wise, there are also noticeable differences between SNMP and Telemetry.