On February 24, 2020, Cisco revamped their entire certification offering — including the CCNP. The new certification paths have been modernized to meet the demands of modern networks. One of the big changes was a stronger emphasis on network automation and programmability. This means new protocols, new technologies, and new challenges for aspiring network engineers.

Here, we'll take a closer look at the new CCNP and protocols related to network programmability including YANG, NETCONF, and RESTCONF.

The New CCNP, Automation, and Network Programmability

With the new Cisco certification paths, you'll need to pass two exams to become CCNP Enterprise-certified. The 350-401 ENCOR is the core exam that's required and you'll need to pass an additional concentration exam.

Before we look at the concentrations, we can see that Cisco is focusing on validating automation and programming skills. Based on the topic list, 15% of the ENCOR exam  is dedicated to automation. Additionally, different subtopics call out Python, YANG, RESTCONF, NETCONF, JSON, as well as tools like Ansible and Chef. This means you'll need to have solid automation and Python knowledge to do well on the CCNP exams.

If you want to specialize in automation and programmability, there is a CCNP concentration for that. The 300-435 ENAUTO focuses on enterprise-automated solutions like Python programming, APIs, and automation tools. Network device programmability alone accounts for 20% of the exam topics on 300-435 ENAUTO.

Long story short: automation and programmability are a big part of the new CCNP Enterprise.

Want to study for CCNP Enterprise Core? Check out our Cisco CCNP Enterprise Core (350-401 ENCOR) training.

Data structures: YANG, YAML, JSON, and XML

Automation and network programmability come down to getting computers to perform tasks for us. A big part of that is providing data in a format that computers can read. This is where YANG, YAML, JSON, and XML come into the network programmability picture. Let's take a quick look at each before we move on to the configuration protocols.

XML

Extensible Markup Language or XML is a very common way of formatting data. It was, as the name implies, designed to be extensible and generic enough to be used in a wide variety of applications. XML uses custom tags to define elements.  For example, an XML file may contain something like this:

Simply looking at the format, we can see why it is easy for both humans and machines to read. The < > characters to open a section and </ > to close help the machines. The human-readable plaintext helps us humans. XML is a common way to encode data for APIs, which makes being able to read it useful to IT pros looking to master automation.

JSON

Another common method for encoding API data is JavaScript Object Notation or JSON. In many cases, when you query a RESTful API using HTTP(S), the response will be in JSON format. While JavaScript is in the name, JSON works with a wide variety of languages and applications today. While the formatting is different from XML, as we can see in our example below, it is still human-readable.

0
1
2
3
4
5
6
7
8
9
10

YAML

YAML once stood for Yet Another Markup Language, but today means "YAML Ain't Markup Language". YAML is a data serialization standard and has become a very common configuration file format. It is also a big part of working with network automation tools like Ansible. Here's what our XML example looks like when converted to YAML:

0
1
2
3
4
5
6

YANG

YANG (Yet Another Next Generation) is different from YAML, XML, and JSON. YANG is a data modeling language used to define data. YANG defines data schemas that formats like XML or JSON must follow. When working with devices that support YANG data stores, a specific XML or JSON encoded message would be deemed valid or invalid based on YANG models.

While it is also used with other protocols, YANG goes hand-in-hand with NETCONF. YANG is how configurations are modeled, and NETCONF is a protocol to modify them. To get a feel for YANG formatting, you can view Cisco's YANG models on GitHub.

Because YANG has some compatibility with the SMIv2 (Structure of Management Information version 2) format used by SNMP (Simple Network Management Protocol), in many cases SNMP MIB modules can be converted to YANG modules.

NETCONF Explained

Traditionally, administrators have used protocols like SNMP for monitoring and a CLI to apply configurations. While those are still viable options on many network devices, Cisco included, they aren't optimized for automation.

NETCONF is a protocol that was designed with programmability in mind. The purpose of NETCONF is to give applications a simple, standards-based, and robust API (application programming interface) to apply and read configurations. As a result, it has become an important part of bringing automation to network infrastructure. This also means it has become an important concept for aspiring CCNPs to understand.

NETCONF follows a standard client-server model that uses RPCs (remote procedure calls). With NETCONF, server configurations are stored in a NETCONF configuration datastore that follows a YANG defined-data format. To query or change data, a client sends an XML-based remote procedure call over one of the supported secure transfer methods, and the server replies with XML-encoded data.

Like with the OSI model, understanding the different layers of NETCONF can help make it more intuitive. In NETCONF's case, there are four layers. Let's take a look at each layer and the purpose it serves:

Content layer. This is the actual content of a query or command. Valid content is defined by YANG. For example, if you were editing switch port settings, that information is found at the content layer.

Operations layer. This layer is also defined by YANG. It details the type of action or query a given NETCONF transaction is performing. For example, you can use NETCONF to edit, delete, or copy configuration data. Per RFC 6241 the supported NETCONF operations are:

• get

• get-config

• edit-config

• copy-config

• delete-config

• lock

• unlock

• close-session

• kill-session

Messages layer. This layer deals with the type of NETCONF message being sent. A message may be a rpc from a client, a rpc-reply from a server, or a hello used to determine a base protocol for a session.

Secure transport layer. As you might expect, the secure transport layer deals with the protocols used to transmit NETCONF messages. SSH, TLS, and HTTP are common protocols associated with this layer.

The NETCONF layers as displayed in RFC6241. Source: https://tools.ietf.org/html/rfc6241

RESTCONF Explained

Now that we've covered NETCONF and data structures, we can dive into RESTCONF. The RESTCONF protocol is a proposed standard defined in RFC8040. From a capabilities standpoint, NETCONF and RESTCONF are similar. They both allow administrators to query information or modify settings using a client-server model. RESTCONF is different in a few key ways:

• RESTCONF is an HTTP-based protocol

• While NETCONF uses XML encoding only, RESTCONF supports both JSON and XML

• RESTCONF does not have a 'lock' concept like NETCONF does

It's important to understand that RESTCONF is NOT a NETCONF replacement. Rather it gives us a RESTful HTTP interface that we can use to query and configure devices with NETCONF configuration datastores.

RESTCONF methods are what you would expect from a RESTful protocol. Here's how they overlap with the NETCONF operations:

RESTCONF methods and corresponding NETCONF operations from section 4 of RFC8040. https://tools.ietf.org/html/rfc8040#section-4

When you couple RESTCONF with a scripting language like Python (the first language we think you should learn), you can automate a wide variety of network administration tasks. For example, the CiscoDevNet RESTCONF sample code includes a script that can help you automate VLAN provisioning on Cisco's IOS XE.

Pro tip: if you're just getting started with Python and HTTP, check out the Requests library.

Final Thoughts

While the CLI and SNMP aren't things of the past just yet, automation is a big part of where networks are headed. Protocols like YANG, NETCONF, and RESTCONF were designed with this in mind. That's why Cisco uses them within their platforms and makes them a part of their certification paths.

Understanding these protocols and their implementations can help network pros prepare for the CCNP and keep their skill set up to date.