NETCONF. Start
Some have heard, and some are even sure that there is a “ simple network management protocol ”, better known as the Simple Network Management Protocol ( SNMP ).
But I almost never met people who knew about NETCONF , which, as its creators hope, will be a substitute for SNMP.
What is he like? Is this an analogue SNMP? Is this the evolution of management? Or is it a dead end?
So, NETCONF is the Network Configuration Protocol (yeah, the word “simple” is not, 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 they rolled out RFC 6241 .
It appeared from the depths of the Juniper company, and more precisely it is a Junos XML API doped file.
')
And really, why reinvent NETCONF? After all, SNMP is still a completely “fresh” protocol, which appeared in the late 80s (SNMPv1 in 1988). For comparison: telnet was developed in 1969, and it is still used. Even invented 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 (paragraph 2), and so on. SNMP (clause 2.1).
I will list some of the most obvious SNMP cons in my opinion:
In my opinion, the protocol is very simple, and the RFC is very well written.
Conceptually, NETCONF looks like this:
I took the picture here .
Currently, 4 options are defined as transport:
Operations are wrapped in RPC requests represented in XML.
The following basic operations are defined:
The client-server model of the protocol is used. An established session can be held for as long as desired (as long as the connectivity is present and the “server” is still alive).
When establishing a connection, the client and server exchange supported parameters (using RPC notifications).
What can we do? And we can, for example:
I think the easiest way to understand how to work with NETCONF is an example.
Turn on NETCONF:
And try to connect:
After entering the password (or checking the key), we get hello from the “server”:
The server informed us with a list of its own capabilities.
About zombies is a joke, sometimes found in Junos. For example, there is a hidden command showing a haiku :
In response to hello, the client should respond with its hello with a list of its capabilities, for example, the same:
Everything. Now you can work with the server. For example, ask part of the current configuration:
What we get the answer:
message id = "100" specified in the request is also saved in the response. So 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 a request from a client. Example from RFC:
In the case of a successfully executed request that does not require an output (for example, commands), the server responds with OK, for example:
To finish the work, we have to close the session:
Rumor has it that on devices Juniper, Brocade, Cisco, Huawei and some others.
Not so great. Well documented and supported by NETCONF I have only met on Juniper. Unfortunately, on Huawei it did not test, because there was no need, and in the case of Brocade there were no experimental subjects. But Cisco ...
About the work of NETCONF on the Catalyst lineup at least up to version 15 of the IOS:
In my opinion, the Cisco implementation is more likely to be checked, rather than to work.
I would like to briefly tell you about NETCONF, because on Habré did not even find a mention of him.
I think the protocol is quite capable of living and benefiting.
I would also like to hear other opinions in the comments, the performance with different equipment is especially interesting.
But I almost never met people who knew about NETCONF , which, as its creators hope, will be a substitute for SNMP.
What is he like? Is this an analogue SNMP? Is this the evolution of management? Or is it a dead end?
NETCONF in brief
So, NETCONF is the Network Configuration Protocol (yeah, the word “simple” is not, 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 they rolled out RFC 6241 .
It appeared from the depths of the Juniper company, and more precisely it is a Junos XML API doped file.
')
What's wrong with SNMP?
And really, why reinvent NETCONF? After all, SNMP is still a completely “fresh” protocol, which appeared in the late 80s (SNMPv1 in 1988). For comparison: telnet was developed in 1969, and it is still used. Even invented 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 (paragraph 2), and so on. SNMP (clause 2.1).
I will list some of the most obvious SNMP cons in my opinion:
- In most implementations, UDP is used as the transport protocol. If something is lost along the way, well, what to do.
- You can write / read only one specific value at a time. You cannot send multiple values in a single transaction.
- No configuration rollbacks / backups available: snmp set makes the change immediately in the active configuration.
- Restrictions in SMI (for example, the length of some fields).
- Zoo MIB even one vendor, even in one type of devices, for example, switches.
- There are delays with the support of new features in the old MIB. For example, CISCO-BGP-MIB, as far as I know, still does not know about IPv6.
Dissecting NETCONF
In my opinion, the protocol is very simple, and the RFC is very well written.
Conceptually, NETCONF looks like this:
I took the picture here .
Currently, 4 options are defined as transport:
- Ssh
- SOAP
- BEEP
- Tls
Operations are wrapped in RPC requests represented in XML.
The following basic operations are defined:
< get > , < get-config > , < edit-config > , < copy-config > , < delete-config > , < lock > , < unlock > , < close-session > , < kill-session > .The client-server model of the protocol is used. An established session can be held for as long as desired (as long as the connectivity is present and the “server” is still alive).
When establishing a connection, the client and server exchange supported parameters (using RPC notifications).
What can we do? And we can, for example:
- open several sessions
- work with different configurations (for example: running or startup)
- request configuration and status with one search query
- configure several parameters in one request
- receive the results of operations in the form of responses (rpc-reply)
- commit and rollback (apply and rollback configurations)
I think the easiest way to understand how to work with NETCONF is an example.
NETCONF workflow 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”:
<!-- No zombies were killed during the creation of this user interface -->
<!-- user test, class j-super-user -->
< hello >
< capabilities >
< capability > urn:ietf:params:xml:ns:netconf:base:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:validate:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file </ capability >
< capability > xml.juniper.net/netconf/junos/1.0 </ capability >
< capability > xml.juniper.net/dmi/system/1.0 </ capability >
</ capabilities >
< session-id > 666 </ session-id >
</ hello >
]] > ]] >
* This source code was highlighted with Source Code Highlighter .The server informed us with a list of its own capabilities.
About zombies is a joke, sometimes found in Junos. For example, there is 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:
< hello >
< capabilities >
< capability > urn:ietf:params:xml:ns:netconf:base:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:validate:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file </ capability >
< capability > xml.juniper.net/netconf/junos/1.0 </ capability >
< capability > xml.juniper.net/dmi/system/1.0 </ capability >
</ capabilities >
</ hello >
]] > ]] >
* This source code was highlighted with Source Code Highlighter .Everything. Now you can work with the server. For example, ask part of the current configuration:
< rpc message-id ="100" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" >
< get-config >
< source >
< running />
</ source >
< filter type ="subtree" >
< configuration >
< protocols />
</ configuration >
</ filter >
</ get-config >
</ rpc >
* This source code was highlighted with Source Code Highlighter .What we get the answer:
< rpc-reply message-id ="100" xmlns:junos ="http://xml.juniper.net/junos/11.2R5/junos" >
< configuration junos:commit-seconds ="1311003260" junos:commit-localtime ="2012-06-06 11:21:40 UTC" junos:commit-user ="test" >
< protocols >
SKIPPED
</ protocols >
</ configuration >
</ rpc-reply >
* This source code was highlighted with Source Code Highlighter .message id = "100" specified in the request is also saved in the response. So 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 a request from a client. Example from RFC:
< rpc-reply message-id ="110" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" >
< rpc-error >
< error-type > rpc </ error-type >
< error-tag > missing-attribute </ error-tag >
< error-severity > error </ error-severity >
< error-info >
< bad-attribute > message-id </ bad-attribute >
< bad-element > rpc </ bad-element >
</ error-info >
</ rpc-error >
</ rpc-reply >
* This source code was highlighted with Source Code Highlighter .In the case of a successfully executed request that does not require an output (for example, commands), the server responds with OK, for example:
< rpc-reply message-id ="201" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" >
< ok />
</ rpc-reply >
* This source code was highlighted with Source Code Highlighter .To finish the work, we have to close the session:
< rpc message-id ="100500" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" >
< close-session />
</ rpc >
* This source code was highlighted with Source Code Highlighter .Where does NETCONF work?
Rumor has it that on devices Juniper, Brocade, Cisco, Huawei and some others.
... BUT
Not so great. Well documented and supported by NETCONF I have only met on Juniper. Unfortunately, on Huawei it did not test, because there was no need, and in the case of Brocade there were no experimental subjects. But Cisco ...
About the work of NETCONF on the Catalyst lineup at least up to version 15 of the IOS:
- Responses to requests very much devour the CPU. running-config with XML formatting can wait 5 minutes when the CPU is loaded at 100%.
- get states is not implemented by RFC (sic!): in response to, for example, “show int status” Cisco always adds a full running-config.
- There are no XML schemas and sometimes the output is strangely cropped. For example, Cisco responds to the “sh run int vlan777” request as follows:
<? xml version ="1.0" encoding ="UTF-8" ? >< rpc-reply message-id ="101" xmlns =" urn:ietf:params:netconf:base:1 . 0 &# 60 ;/ cmd > a >< cli-config-data >< cmd > !
</ cmd > nterface Vlan777
</ cmd > description TEST
</ cmd > ip address 192.168.0.1 255.255.255.0
</ cmd ></ cli-config-data ></ data ></ rpc-reply > ]] > ]] >
* This source code was highlighted with Source Code Highlighter .
The first letter in the word “Interface” disappeared somewhere.
In my opinion, the Cisco implementation is more likely to be checked, rather than to work.
Conclusion
I would like to briefly tell you about NETCONF, because on Habré did not even find a mention of him.
I think the protocol is quite capable of living and benefiting.
I would also like to hear other opinions in the comments, the performance with different equipment is especially interesting.
Source: https://habr.com/ru/post/135259/
All Articles