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.