A quick review of some different items in Hank Preston’s free video series
First and foremost, hats off to Hank Preston on this great video series, and any notes here in are my own understanding (I try not to type verbatim for the sake of understanding the concept), so all credit to him for the information within!
(And I take full responsibility for any content that I understood / wrote incorrectly!)
These videos of Hank Prestons series can be found @ https://developer.cisco.com/video/net-prog-basics/ – Not sure how much this transfers over to the DEVASC exam but wanted to dig through the entire Basics series one more time as reading my older Intro to Network Programmability Notes from Keith Bogarts INE Series (when I was first beginning my journey) I feel my understanding has changed a bit at this time.
That said I will dive right into Model Driven Programmability starting with YANG!
A couple of high level notes:
- NETCONF, RESTCONF, and gRPC (Google RPC) are Transport Protocols like TCP / IP
- YANG is a Data Model, so it would be the Data Payload within NETCONF / RESTCONF
YANG Data Models
The structure of a YANG Data Model I pulled from a random internet image:
The ¶ in this image is just a special character from the example I founds text editor, however this is just the YANG Data Model / Architecture of how it is made up of really 5 major components in their structure outlined here:
- Module – This is the overarching descriptor / container for all the elements of a specific device or a specific protocol on that device
- Container – These are “Container Objects” that group together the higher level component that will have a subset of information
- Lists – These define the different objects within the contain such as a list of interfaces, a list of routes in an IP Route Table, Etc
- Leaf / Leaves – These are the Attributes of the objects, they contain information about the object using interface as an example you may see the key pair values such as “Status:Up” Speed:Auto” “Duplex:Auto”
- Type – This defines the Data Type that is referenced in the Leaf, such as String / Boolean / Integer / Etc
A few follow up items to include within this list:
- ? on a leaf indicates the attribute is optional
- The “List” Key Value (Citizen / City in the above example) is what is known as the “Key” much like in my Data Format posts how JSON uses Key Pair Values and the second value in the Key Pair could actually be a “List” or “Array” of more Key Pairs
- This can be either open source or vendor specific, and again this can be written in many languages including JSON, Plain Text, XML, YANG (the language), JavaScript
There is also a Python Library Pyang that will Validate and Display the YANG Data Files using different formats using either Text (Tree) or HTML (JSTree) for output.
Keep in mind this is only the YANG Data Model shown here, it appears to me it is written in JSON from what I can tell, however it still requires a Transport Protocol such as NETCONF or RESTCONF to actually send and receive the information.
For more information / examples they can be found at the YANG GitHub Repository:
https://github.com/YangModels/yang
Model Driven Programmability – NETCONF, RESTCONF, and gRPC
These are the Transport Protocols that are used with the YANG Data Model / Model Driven Programmability. YANG Data Models are used as a “template” essentially for the input and output from devices that send and receive Data in this format vs SSH or Telnet, which again can either be Configuration Driven in nature (pushing a new config / changing a config) or Operational (Getting status info [similar to SNMP] / getting device config like “sh run” / Etc), which can be either Open Source or Vendor Specific and will get Device Features such as Interface Stats / Protocols Statistics / ACL Configs / Etc
Again Google RPC is not reviewed here, but worth mentioning it IS also a Transport Protocol for Model Driven Programmability that uses YANG Data Models as well.
NETCONF Transport Protocol
NETCONF is not restricted to using just the YANG Data Model as it actually was created before the YANG Model came to be, however in modern deployment it typically use this model, and use the XML Data Language to format its Data Payload.
NETCONF does use the Transport Protocol SSH to Establish its connection over the NETCONF well know port 830 (though it can be other unique port #’s on the Agent), which will then reply back with a Hello to the Client and the Client will the Hello back to the Agent as a sort of hand shake.
Though you can use “ssh admin@22.22.22.22 -p 830 -s netconf” from a Bash shell, this is far from the ideal way of communicating via NETCONF, instead a NETCONF “Manager” application would be used for communication.
This is done by the Client (The Admin) sending an RPC via this NETCONF Manager to the Agent (Server or Device) sending and receiving something like:
Send:
<rpc message-id=”1″>
.
</rpc>
Receive:
<rpc-reply message-id=”1″>
.
</rpc-reply>
The Message ID # reply should match that sent, the “.” will be a set of configuration or operation data that will be sent then returned, and as can be seen with the </> tags this is sent via XML.
Within this Data being sent it must target what is referred to as “Data Stores” on the Server or Device, which at a very minimum must be contain “running” but can be honed down to partial pieces of the running config, however the messaging must target a Data Store on the Agent to receive a response back.
The first step is the devices say Hello to each each other via the agreed upon NETCONF port #, establish which Data Modeling is to be used for sending information, and then data can be sent and retrieved from the client until the session is ended with simply “kill session” which will work for not only your own session but also for other open sessions.
The NC Manager information that will be used in Python can be found at:
https://ncclient.readthedocs.io
The Python script I basically just copied off the website as I am not really deep diving into this but just studying for later purposes is as follows below:
Which as you can see I don’t have the right packages installed to run this, so there will be VSC errors yelling at me, however I wanted to get a visual idea of how you would connect and show the capabilities of the Agent / Server using NC Manager for Python.
The very first line “from device_info import ios_xe1” defines that we are importing data about the Agent to be used in the script lines for address / username / password / port #.
The second line tells Python that from NCClient it is importing Manager capabilities to perform all these actions, which I don’t have loaded, hence the VSC errors.
The script then pulls piece of information from the ios_xe1 file stored on the local device as has been demonstrated in my posts going through David Bombals “Python for Network Engineers” course, where I would store IP Lists of devices on the network to be logged into and have scripts run against them.
Below is an example of an actual NC Manager / Python script for “Operational” data:
As seen in Line 3 an xmltodict library is imported so that the XML information can be output into a Python Dictionary format for readability.
Line 5 is a predefined XML file that NETCONF will use to filter the output it gets, which is the data that is defined in the print statements added at the bottom of the script.
The connection info remains the same to open a connection using a username / password with no hostkey, then line 21 tells the script to parse the rpc-reply data from the returned message from XML to a Python Dictionary. The following lines print the output that is parsed in the script to a Python dictionary.
To send a “Configurational” config, you would send an “<edit-config> (Data)” in the message, I won’t demo the script for the sake of time, however I wanted to note that to wrap up NETCONF and if the config edit is accepted the <rpc-reply> will simply return an “OK” as in a 200 OK message only it will simply just say “OK” in the message.
RESTCONF Transport Protocol
RESTCONF is the newest(?) Transport Protocol that uses “Model Driven Programmability” to interface the network with other elements such as Cloud Resources and Applications, which introduces RESTCONF to scale beyond using the CLI to access network devices and the extreme lack of ability for SNMP to not just Monitor a network or retrieve information but the extreme lack of Write MIBs in vendors SNMP Libraries.
SNMPv3 does allow for Security enough to make it usable, however more common devices that use SNMPv3 also can be managed with Webhooks / REST APIs / Etc.
Speaking of REST APIs, RESTCONF is an HTTP Based protocol that provide a programmatic interface for retrieving and writing data via YANG Data Models along with XML and JSON Data Formats rather than XML only (though again XML supports SOAP).
It should also be used via HTTPS as discussed in the Week 2 Blitz of my class, the HTTPS should always be used for Secure transmission of REST APIs.
RESTCONF does not aim to replace NETCONF as NETCONF has a more robust feature set for Servers or NMS’s to utilize, however RESTCONF are more for the user / client side to integrate APIs with Software and Web Applications or to just grab more basic sets of information (or configure it).
RESTCONF uses the HTTP Verb / CRUD Model using XML or JSON with YANG Data Model:
There is a mapping of RESTCONF to NETCONF which is basically:
GET = <get> or <get-config>
Everything else = <edit-config> – Literally every other verb maps to <edit-config>
When sending RESTCONF HTTPS Message Headers you cannot just use application/json or application/xml like with other REST APIs because it does use the YANG Data Model, so the proper header would be application/yang-data+json or application/yang-data+xml.
That being said, the RESTCONF URI is also a bit different in construction:
https://<Address>/<Root>/<Data Store>/<[Yang Module:]Container>/<Leaf>/(?Option)
- Address = RESTCONF Agent
- Root = Main Entry Point for RESTCONF Requests
- Data Store = The Data Store being Queried
- YANG Module:Container – The Base Model Container used, defining the YANG Module name is optional (not entirely sure what this means)
- Leaf – The individual element being queried
- Options – This is exactly like a Query in a URI, optional parameters
An example actual URI is as follows:
https://5.5.5.5/restconf/data/ietf-interfaces/interface=GigabitEthernet1?(something)
So very very close to a REST API URI, however the header must indicate the application/yang-data+json or xml within it, whereas RESP APIs call these fields an “Schema” (Http/Https) “Authority” (FQDN / IP Address) “Path” (/resources/destinationFolder/) and finally ends with a Query which is option indicated by the “?” as is returned if you use the “Search” function for ‘devnet’ on the frontpage of this site the returned URL from that API Call to WordPresses Database for Authority “Loopedback.com” will be ‘https://loopedback.com/?s=devnet’ as the “s” indicates the “search” function was called and the Path is simply “/” that it is searching from.
REST APIs also utilize Postman which I will not go over here, but there is where you can graphically build API’s that GET / PUT / POST / PATCH / DELETE and lots of others ones that I am not focusing on at this time.
With that I will wrap up my takeaways from the NETCONF / RESTCONF module
There are about 30-40 more minutes of video on utilizing the protocols using NX-OS however I plan to just watch and soak it in, though I wanted to jog my memory from my earlier INE studies with Keith Bogart on the same subject, as my understanding becomes a bit more clear with every Iteration of understanding I type down and read again.
With that, Happy Friday! đŸ™‚
The DEVNET GRIND! 