SNMP is currently the most popular management protocol and this is for good reason. But how does SNMP compares with other protocols, and why would somebody choose to use SNMP? Are there any cases where other protocols should be used or are being used?

These are questions that most of us ask from time to time. This is why I will try to answer them now, based on my 20+ years experience in Element, Network and Service Management. Note that despite my experience, this article should be used as food for thought, so if you disagree with something included here, please leave a comment which I will surely read and reply.

Now, this article will focus on the characteristics and benefits of each protocol, their adoption by the industry, the current trends and will recommend a set of protocols for network elements. The paragraphs are:

Overview gives a short history of management protocols, explains how SNMP is rarely used to configure devices and how that lead to the introduction of NetConf. It also discusses CISCOs innovations for Performance data collection with Netflow.
Describes  the current options available:

    • SNMP, giving a quick summary of SNMP three versions and discusses security
    • CLI, describing CLI usage
    • NetConf, giving a quick summary of protocols characteristics
    • Netflow/IPFIX, giving a quick summary of CISCOs and ITF protocols characteristics
Recommendation gives the authors opinion about the best fit for every protocol, based on industry adoption, trends, and personal experience.
[/fusion_accordion] Read below for more.


The IETF developed SNMP in the late 1980s and it proved to be a very popular network management protocol. In the early part of the 21st century it became apparent that in spite of what was originally intended, SNMP was not being used to configure network equipment, but was mainly being used for network monitoring, i.e. Fault and Performance Management.

In 2002, the Internet Architecture Board and key members of the IETF’s network management community got together with network operators to discuss the situation. The results of this meeting are documented in RFC 3535. It turned out that operators were primarily using proprietary Command Line Interfaces (CLI) to configure their boxes. This had a number of features that the operators liked, including the fact that it was text-based, as opposed to the BER-encoded SNMP. In addition, many equipment vendors did not provide the option to completely configure their devices via SNMP.

As operators generally liked to write scripts to help manage their boxes, they did find the CLI lacking in a number of ways. Most notably was the unpredictable nature of the output. The content and formatting of output was prone to change in unpredictable ways. Around this same time, Juniper Networks had been using an XML-based network management approach. This was brought to the IETF and shared with the broader community. Collectively, these two events led the IETF to the creation of the NetConf protocol which is expected to be better aligned with the needs of network operators and equipment vendors.

Regarding Performance Management on routers/switches for IP, CISCO soon realized that a more compact protocol than SNMP was needed to scale better for performance collection on IP networks.  Netflow originally introduced by CISCO has become a standard now (named IPfix) that has been implemented by many routers/switches Vendors.


Management Protocols

Simple Network Management Protocol (SNMP) is an interoperable standards-based protocol that allows for external monitoring of the Content Engine through an SNMP agent.

  • Version 1 (SNMPv1, described in RFC 1157) is the initial implementation of SNMP.
  • Version 2 (SNMPv2c, described in RFC 1902) is the second release of SNMP. It provides additions to data types, counter size, and protocol operations.
  • Version 3 (SNMPv3, described in RFC 2271 through RFC 2275) is the most recent version of SNMP. It became a full IETF standard, making SNMPv1 and v2c historical.

SNMP version 1, or SNMPv1, has enjoyed unparalleled success as an interoperable management solution. However, it had multiple shortcomings, the most notable of which was its lack of strong security.

The standardization process of SNMPv2 was stuck with two competing proposals: SNMPv2u, SNMPv2* which both had a user-based security model. Unfortunately, a compromise was made and a proposal named SNMPv2c was standardized. Why the SNMPv2 has a weak security? The answer is easy: The fruit of the standardization, the SNMPv2c, has no change to basic SNMP in terms of security – it relies completely on the familiar community strings.

SNMPv3 solved all security issues of SNMP v1 and v2c.

Command Line Interface (CLI) is used whenever a large vocabulary of commands or queries, coupled with a wide (or arbitrary) range of options, can be entered more rapidly as text than with a pure GUI. This is typically the case with:

  • Operating system command shells
  • Local Craft applications in telecom networks.

CLIs are also used by

  • Systems with insufficient resources to support a graphical user interface.
  • Programmers and system administrators, in engineering and scientific environments
  • Technically advanced personal computer users.

The content of NETCONF operations is well-formed XML. Most content is related to network management. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple Remote Procedure Call (RPC) layer. The NETCONF protocol uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. This in turn is realized on top of the transport protocol (BEEP, SSH, SSL, Console).

The NETMOD working group has completed work to define a “human-friendly” modeling language for defining the semantics of operational data, configuration data, notifications, and operations, called YANG. YANG is defined in RFC 6020, and is accompanied by the “Common YANG Data Types” found in RFC 6021.

During the summer of 2010, the NETMOD working group was re-chartered to work on core configuration models (system, interface, and routing) as well as work on compatibility with the SNMP modeling language.

Routers and switches that support NetFlow can collect IP traffic statistics on all interfaces where NetFlow is enabled, and later export those statistics as NetFlow records, toward at least one NetFlow collector – typically a server that does the actual traffic analysis. Netflow supports MPLS and Ethernet flows. NetFlow is usually enabled on a per-interface basis to limit load on the router components involved in NetFlow, or to limit the amount of NetFlow records exported.

NetFlow was initially implemented by Cisco, and described in an “informational” document that was not on the standards track: RFC 3954 – Cisco Systems NetFlow Services Export Version 9. The NetFlow protocol itself has been superseded by Internet Protocol Flow Information eXport (IPFIX). Based on the NetFlow Version 9 implementation, IPFIX is on the IETF standards track with RFC 5101, RFC 5102, etc. which were published in 2008 and is considered Netflow v10.



Use SNMP for monitoring (alarms, performance). Alarms and events reception via SNMP traps, while performance collection via SNMP get or multi-get. For traffic-intensive devices, such as routers and switches, check the manufacturers documentation to see if performance-specific protocols such as Netflow are supported.


Try to use SNMP for configuration (provisioning, setup) if SNMP is well documented. Otherwise try manufacturers proprietary protocols and interfaces, they may be more efficient.

Image copyright: HP

Do you agree with the above? Use the comment box below to give me your opinion!