This is a logical look at how the NETCONF Protocol is made up, I will get into defining some portions of this below, but wanted to give a visual look at how NETCONFIG is structured as a Protocol.
Now for a quick overview, unfortunately this does draw a bunch of comparison again to SNMP, however it may come up on Cisco Exams in new tracks so I will cover here.
Overview of NETCONF RFC #’s, Default Port #, and how it operates
NETCONF is an acronym for “Network Configuration Protocol” that is defined in RFC 4741 and 6241 for detailed information, and its counterpart RESTCONF (to be covered) describes the protocol and method of transport for Network Management Data which exactly describes what SNMP does – NETCONF kind seeming to be the next best SNMP.
NETCONF communicates securely via SSH 2.0 over TCP Port 830, which is the first distinction from SNMP that runs over UDP Ports 161 / 162 and is ‘best effort’, NETCONF creates a TCP Session to live feed the Network Management Data to whatever GUI or Tool you are using to monitor the network traffic.
It can also run over TLS and SOAP (Simple Object Access Protocol) as well, but SSH is the preferred method of Access / Transport.
When a NETCONF performs a TCP Session on Port 830, it uses YANG to speak the language between the two devices (different YANG Models), and it is for some reason important and well documented that unlike SNMP it can distinguish Config Data from Operational Data (like interface state) so that may be good to remember for exam day.
NETCONF uses paths similar to HTTP whereas SNMP uses OID (Object IDs) that are cumbersome to go find the correct OID for the function desired, whereas NETCONF encodes Data using XML or JSON Formatting, most commonly XML as can be seen by typing “show run | format” on an IOS device will produce the running-config in XML.
So to be clear NETCON talks using YANG as a Data Model structuring, but the Data within YANG is encoded using XML or JSON Encoding!
I will do an SNMP vs NETCONF comparison here
Being its like the Next-Gen SNMP, I typed this up on the page, then just took a screen snip and posted the picture on here so the formatting didn’t go all nuts:
With that I am hoping we are done with comparisons to SNMP, as that is not what I am studying, but I am posting this information in the event it pops up in any of the new Cisco Track Exams as a question of SNMP vs NETCONFIG – You and I will be set!
NETCONF Protocol Stack
I wanted to first drop in the visual again and then break down the layers of this:
In this Diagram we have a NETCONF Server and a Client (Network Device):
- The Config Datastore on the NETCONF Server is in YANG Data Model
- Communication Data Model is also YANG between Server and Client
- The top layer (Content) will use XML (normally) or can use JSON
- The next layer (Operations) is what actually pushes changes like <get-config> <lock> <delete-config> <validate> and MANY more!
- The next layer RPC is “Remote Procedure Call” and RPC-Reply
- The final layer (Transport) again is SSHv2 via TCP Port 830, TLS, or SOAP
Using this Protocol Stack it can perform the following actions:
- Collect status of specific fields (interface status)
- Change config of specific field (“no shut” interface if status=false)
- Take Administrative Actions
- Send Event Notifications via Telemetry (where it streams Data / Streams Telemetry) so Telemetry is often referred to as “Streaming Telemetry because of how it works
- Backup / Restore Device Configurations
- Test Configs to be applied before finalizing the configuration
The Telemetry concept is one to really keep in mind as SNMP does Polling of Devices to gather network Data, whereas Telemetry actually streams that Data real time, and this is a big deal with Cisco DNA as it does Telemetry and is capable of doing AI / Machine Learning based on Telemetry to dynamically fix issues itself (which is a fairly huge deal).
So for exam purposes at very least, have the term and purpose of Telemetry down cold!
Some NETCONF Terminology I have not yet covered
- NETCONF Agent is the same as turning on SNMP where it is turned on directly on the device if it is NETCONF capable
- NETCONF Manager would be installed on a Server where it can reach all Agents
- Instead of a MIB (yes another SNMP Comparison) NETCONF uses Datastores to query Agents, which can use either READ or WRITE to either gather or send config change updates to devices or gather data statistics
There are 3 different types of NETCONF Datastore to be aware of
- <Running> The Running Config on a Device
- <Startup> The Startup Config for a Device
- <Candidate> This type of Datastore is not supported by many vendors (Juniper maybe?), however it is meant to be a sort of staged config change that is not yet committed to the actual running config
Speaking of Running-Config Datastore, this is actually the only Datastore that needs to exist between a NETCONF Server and Agent for them to talk back and forth, though I would imagine you will also want to grab a Startup Config Datastore as well.
One final note is that some Datastores are RW while others are RO, it does not specify which ones in the training course or from my quick googling, I personally would assume the Startup Datastore is read-only but that is pure speculation – Hopefully I find a real answer in other training materials.
That does it for this Intro to NETCONF / SNMP Comparison
I will hopefully be able to move on from the heavy SNMP Comparison soon here, I understand the reason to draw contrasts between the Protocols, but I am ready to move put this behind me here.
So next up will be some more NETCONF, then some RESTCONF, then I am changing gears to some type of coding / language such as Linux for Net Engineers or Python – It is time!
The DEVNET GRIND! 