Some have heard, and some are even sure, that there is a " simple network management protocol ", better known as SNMP (Simple Network Management Protocol).
But I hardly met people who knew about NETCONF , which, as its creators hope, will become a replacement for SNMP.
What is he like? Is this an analogue of SNMP? Is this an evolution of management? Or is it a dead end branch?
Briefly about NETCONF
So, NETCONF is the Network Configuration Protocol (yeah, there is no word “simple”, apparently this is his problem). It is being developed by the IETF NETCONF Working Group . His “life” began in December 2006 with RFC 4741 , and in June 2011, RFC 6241 was rolled out .
It appeared from the bowels of the company Juniper, and more precisely is a dubbed file Junos XML API.
Why is SNMP bad?
And really, why reinvent NETCONF? Indeed, SNMP is still quite a “fresh” protocol, which appeared in the late 80s (SNMPv1 in 1988). For comparison: telnet was developed in 1969, and it is still used. They even came up with SNMPv3 with encryption.
And yet, in 2002 there was a meeting of the Internet Architecture Board (IAB) Network Management Workshop, which resulted in RFC 3535 . In particular, it lists the pros and cons of network management technologies (point 2), including SNMP (clause 2.1).
I will list a few of the most obvious in my opinion the disadvantages of SNMP:
Most implementations use UDP as the transport protocol. If something is lost along the way, well, what can you do.
Only one specific value can be written / read at a time. You cannot send multiple values in a single transaction.
There is no possibility of configuration rollbacks / backups: snmp set makes a change immediately in the active configuration.
Restrictions in SMI (for example, lengths of some fields).
MIB zoo even has one vendor, even in one type of device, for example, switches.
There are delays in supporting new features in old MIBs. For example, CISCO-BGP-MIB, as far as I know, still does not know about IPv6.
Preparing NETCONF
In my opinion, the protocol is very simple, and the RFC is very well written.
Operations are “wrapped” in RPC requests represented in XML.
The following basic operations are defined:
, , , , , , , , .
The client-server model of the protocol is applied. An established session can be kept for as long as you want (as long as there is connectivity and the server is still alive).
When a connection is established, the client and server exchange supported parameters (using RPC notifications).
What can we do? And we can, for example:
open multiple sessions
work with different configurations (for example: running or startup)
request configuration and status with a single search request
configure several parameters in one request
receive operations results in the form of answers (rpc-reply)
do commit and rollback (applying and rolling back configurations)
I think the easiest way to understand how to work with NETCONF is as an example.
NETCONF example on Juniper
Turn on NETCONF:
set system services netconf ssh
And try to connect:
ssh username @ host -s netconf
After entering the password (or checking the key) we get hello from the "server":
* This source code was highlighted with Source Code Highlighter.
The server informed us with a list of its capabilities.
About zombies - this is a joke, it happens in Junos sometimes. For example, there is also a hidden command showing a haiku :
show version and haiku
In response to hello, the client should respond with its hello with a list of its capabilities, for example, the same:
* This source code was highlighted with Source Code Highlighter.
All. Now you can work with the server. For example, ask part of the current configuration:
* This source code was highlighted with Source Code Highlighter.
What we get the answer:
SKIPPED
* This source code was highlighted with Source Code Highlighter.
message-id = "100" specified in the request is also stored in the response. T.O. You can distinguish between different answers that can be received in a different order.
In addition to rpc-reply, you can catch rpc-error when an error occurred while processing the request from the client. Example from RFC:
rpc missing-attribute error message-id rpc
* This source code was highlighted with Source Code Highlighter.
In the case of a successfully executed request that does not require output (for example, a command), the server responds with OK, for example:
* This source code was highlighted with Source Code Highlighter.
To finish the job, we must close the session:
* This source code was highlighted with Source Code Highlighter.
Where does NETCONF work?
It is rumored that on devices Juniper, Brocade, Cisco, Huawei and some others.
... BUT
Not so fine. Well-documented and maintained by NETCONF I have only seen on Juniper. Unfortunately, I did not test it on Huawei, because was not necessary, and in the case of Brocade there were no experimental subjects. But Cisco ...
About the operation of NETCONF on the Catalyst line until at least version 15 of IOS:
Answers to requests very much devour the CPU. running-config with XML formatting, you can wait 5 minutes when the CPU loads at 100%.
get statuses are not implemented using RFC (sic!): in response to, for example, “show int status”, Cisco always adds the full running-config.
There are no XML schemas and sometimes the output is strangely clipped. For example, Cisco responds to the “sh run int vlan777” request like this:
March 11, 2012 at 12:37
