SNMP compared with CLI, Netconf, Netflow

SNMP compared with CLI, Netconf, Netflow

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:

[accordion]
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.

Overview

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.

Recommendation

Monitoring

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.

Use FTP and Netflow to collect performance data if the Network Element supports it.

Configuration

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.

If you do not see SNMP support for a device, try HTTP and CLI. Most devices will support CLI or HTTP for configuration. If NetConf is available try to see if it is fully supported

Image copyright: HP

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

2016-10-25T07:40:04+00:00 Feb 18th, 2013|Categories: SNMP|Tags: , , , , , |12 Comments

About the Author:

Christos Rizos is a Network, Systems and Applications Management expert with 20+ years experience in the technology domain, providing consulting services to Vendors and Operators around the world.

12 Comments

  1. Sham March 30, 2014 at 11:29 pm

    Hello Sir,
    Currently our NMS product is using SNMP/CORBA/CLI access methods to configure and monitor devices.

    Do you think introducing
    Netconf for Config mgmt of Network device
    and
    Netflow v10 for Network Device performance monitoring
    will add value?

    1) How frequently does a customer configure who has 10-15 K network devices?
    2) Are the new generation devices that support Netflow/Netconf protocols also have SNMP?

    • admin May 17, 2014 at 7:37 pm

      Hello Sham,
      introducing Netconf and Netflow can indeed add value, but this is also related with the type of network you are managing.

      Regarding your 1st question, 10-15k network devices is a big number, so normally I would expect configuration changes to take place frequently. But note, some types of devices (e.g. simple IP switches or legacy wireless backhaul PtP radio links) are rarely re-configured after their installation and commissioning. Other types of devices, like ADSL/VDSL equipment may be configured very frequently, in order to allow provisioning of new services ordered by customers. So, there is no single answer. Everything depends on the network type and the application.

      Regarding your second question, yes SNMP is here to stay. Even the new generation devices that support Netflow and Netconf still support SNMP. What has evolved is what management functions are supported. New generation devices that support Netconf/Netflow, support usually only Fault management over SNMP. Configuration and Performance management is performed with the new protocols.

      Hope this helps,
      admin

  2. Mayank Kansal January 19, 2015 at 9:59 am

    Hello Sir,
    As you mentioned in the description that operators are using CLI for configuration. But in case of operator is using some NMS system which is based on SNMP. Operator will use NMS to configure and performance management. In this case, is there any benefit of changing the NMS protocol from SNMP to netconf. if yes, please try to identify some.

    • admin April 7, 2015 at 5:41 pm

      Hi Mayank Kansal,
      there many benefits in using netconf and other new technologies. Lately, we see a clear trend towards SDN (Software Defined Networking) that promises to change and simplify the way we configure networks. Articles are being prepared for these topics and will be published soon to give you more information.
      – Chris
      SNMPCenter.com

  3. Sai Krishna Thaniparthi October 17, 2015 at 2:46 pm

    What are the Benefits of SNMP over other protocols.?

    • admin September 22, 2016 at 6:50 am

      Hi,
      please check the below article
      SNMP vs. other protocols

      A quick summary of benefits is following:
      – Wide spread adoption by vendors of devices (Network Element). Almost any device supports SNMP, at least for Alarms (and most times Performance)
      – Wide spread adoption by vendors of management systems (NMS). This means that it will be easy to use SNMP to manage a device.
      – De-facto standard for Fault Management. Almost everybody uses it…

      Christos

  4. Andy McBride February 3, 2016 at 8:35 pm

    Hello,

    I see the advantage to using NETCONF for config management but is NETCONF applicable for performance management other that notifies? in other words, is there an SNMP polling equivalent using NETCONF? Are vendors building XML accessible performance counters into equipment?

    • admin September 22, 2016 at 6:39 am

      Hi Andy,
      NETCONF was designed to be a better solution for Configuration Management compared to SNMP, CLI, etc. Although NETCONF with YANG provides the capability to be used for notifications (i.e. Fault Management), no work has been done to cover Performance Management so far, and personally I do not see it happening any time soon.
      – Christos

  5. Rajesh October 19, 2016 at 6:16 am

    Hello Sir,

    May I know the use cases for NETCONF over CLI and SNMP. As i know snmp mainly for Managemnt and Monitoring.

    1. Why we need NETCONF?
    2. Where we need NETCONF?
    3. How it adds an advantages over CLI?

    • admin October 25, 2016 at 1:47 pm

      Hi Rajesh,
      NETCONF development started around 2003, when network operators realized the limitations and disadvantages of SNMP and CLI. Currently, most vendors use CLI for configuration management, but the lack of transactions and the always changing structure of CLI has proven to be a big problem, especially when aiming for programmability and elasticity.
      The emergence of SDN/NFV has finally made vendors and operators realize that CLI needs to be replaced by NETCONF and this will happen in the following years.

      You can read some more in a recent article published here in SNMPcenter here

      -Chris

  6. Ranjith Kumar. R November 24, 2016 at 6:41 am

    Hi Sir

    Would like to understand the problem in using CLI and how NETCONF over come those issue ?

    Thanks
    Ranjith

    • admin November 24, 2016 at 8:08 am

      Hi Ranjith,
      The problem with Command Line Interface (CLI) is that it is not a standardized protocol. That means that each vendor creates his own commands, i.e. it is proprietary. So:
      – CLI commands and their output tend to change over time. Imagine the scenario of the vendor’s software programmer doing a very minor change in the output of a command, that adds just an additional space character. Even this minor change will “break” any integration that has been done with other systems.
      – There is now way for a software to discover the commands and the outputs, i.e. these is no formal definition of what to expect for every command.

      NetCONF overcomes these two problems because:
      1. it is standardized
      2. Using YANG you can let software programs discover the structure of the protocol.

      Hope that helps,
      Christos

Comments are closed.