ENCOR Passed!!!

Last Friday (10/2), I took one more step in my CCNP Enterprise journey by passing the Cisco 350-401 ENCOR exam! This exam is no joke…. In this post, I’m going to review my journey and some personal study tips that will hopefully help you in your journey.

I want to say up front that I will not be discussing anything that breaks NDA, such as discussing specific exam questions or hinting towards any specific subjects that you should focus on. In all honesty, the exam was very fair and stuck to the exam topics outlined by Cisco.

THE JOURNEY

I want to give a little background of how I got to test day. I began my journey about 6 months ago. With the pandemic lockdown in full swing, I figured it was a good time to begin studying for my next certification. It may be an unpopular opinion, but I was thrilled when the new certification tests were released in late February. Last year, I went after the CCNP, but it was hard for me to study because I did not “agree” with some of the archaic topics that I was studying. For example, frame relay was a topic on the Route exam. Whether you’ve studied it or read about it in another blog, it’s not exactly an applicable topic to everyone. Don’t get me wrong, you can still run into it in the field, but not exactly as much as you would have in the past. There are other topics that are and will be more relevant in the future (i.e. network programmability, automation, and SD-* technologies) that new learners should be learning and labbing. Now to quit rambling about the past, here’s how my 6 month ENCOR journey went and the resources I used.

I purchased the OCG the first week it came out, but the first two months were not very consistent. I would read maybe one to two chapters a week, skip a few days, have another wave of motivation, and read again. This was not a sustainable study plan and I knew that. I realized I never figured out my WHY or made a study plan, which brings me to my first two tips: 1) Always determine WHY you’re doing something and 2) Create a study plan that is sustainable, achievable, and has a timeline. For how cheesy it may sound, I would also add to physically write them down on paper (your why and study plan) and place it somewhere that you’ll see it everyday. There’s something about writing it down that makes you feel more accountable – Trust me, I didn’t believe it either until I did it! Once I established my WHY and study plan, I began hammering away at each topic.

Now on to studying the exam topics…

I enjoyed the variety of topics the ENCOR exam covers. With so many topics, you really need to understand the different subjects of networking: Routing, switching, security, wireless, and [the new one] automation. I used the following resources during my studies: The Cisco 350-401 OCG (Cisco Press link here), CBT Nuggets (link), and labbing with EVE-NG Community (link). More importantly, here’s the process I followed when studying:

  1. Read and highlight the entire book resource (OCG in my case)
  2. Watch video resources (CBT Nuggets) in order of the exam topics or chapters in the OCG, instead of watching the playlist straight through. This provides some guidance into what to focus on during each study session.
  3. After watching videos, review the associated chapter (with highlights) in OCG and begin taking handwritten notes.
  4. Once all chapters/exam topics are reviewed, go through your handwritten notes and research Cisco documentation on the larger topics of each chapter/topic. Mark up your notes to add additional details found in the documentation.

*It’s not really a defined step, but you should lab in between each topic/chapter. Labbing and being in the CLI can really drive home a topic.

One of the last things I want to mention about learning each topic is to compare the technology/protocols within each domain. For example, in the domain of FHRPs, why would you use GLBP vs. HSRP or HSRP vs. VRRP? By comparing each technology, you are able to better explain how it works and why you would use one versus the other in a specific situation.

CONCLUSION

I did not expect this post to be this long, but I figured it would be better to include more details, that may answer the questions you have as a reader, then not to leave enough. The next step in my journey is completing the 300-435 ENAUTO exam to achieve my CCNP Enterprise certification. I’m hoping to complete it by January 2021.

As always, please feel free to reach out to me here or via Twitter! Thanks for reading and see you in the next post!

NETCONF vs. RESTCONF

Two protocols that you hear about when you jump into the network automation world…

In this post, I’ll go over each protocol, why they are used, and a personal take on their future.

NETCONF

When I was first looking at network programmability, NETCONF was one of the first protocols I stumbled upon. NETCONF runs over SSH (port 830) and only uses XML data formatting. If you’ve never ran into XML, it’s one of the easiest data formats to comprehend. Here’s a basic example of XML representing a person:

<Person personID=1>
<name>John Doe</name>
<address>111 Hollywood Blvd</address>
<city>Los Angeles</city>
<state>CA</state>
<zip>55555</zip>
</Person>

The verbosity of XML has it’s perks and downsides: The perk is that it’s extremely easy to follow and understand. The downside is that it can produce an extremely lengthy and messy configuration file when sending data to a network device vs. another data format like JSON.

I want to go over some the different components of NETCONF. Following the RFC [6241], there are four main components: Transport, Messages, Operations, and Content. I’ve already gone over the Transport component being SSH. The Messages and Operations are how NETCONF communicates and exchanges data with the network device. RPC calls are used for both use cases. More specifically, you may see these types of tags in your calls: <rpc>, <rpc-reply>, and <notification>. As you can guess, the <rpc> tag is used to initiate the NETCONF session, while the <rpc-reply> encapsulates the device’s response. The <notification> element is initiated from the server (network device) and sent out in response to an event occurring on the device. I like to think of notifications as SNMP traps, but in a push instead of pull model. There are plenty more element tags you’ll see when sifting through NETCONF-XML responses, but I wanted to highlight a few here.

NETCONF Operations

The Operations and Content components of NETCONF are expansive and can be individual posts themselves, but I wanted to highlight them here so that you can get a more complete understanding of the protocol. Before explaining the Operations, you’ll need to understand how the data is organized on the network device so that you know how to extract the data you’re looking for. NETCONF has a concept called configuration datastores. There are many datastores defined in the RFC, some that may not be supported by every device platform, but here are the few I wanted to highlight:

  • <startup>: Startup configuration for the device
  • <candidate>: Runs in parallel with the running configuration. Changes can be made to this data store without affecting the running configuration of the device. However, those changes can be committed to be the running datastore at a later time.
  • <running>: Running configuration of the device
  • <operational>: A read-only datastore that holds all the operational (state) information (interface statistics, routing adjacencies, etc.)

These datastores are important when it comes to the type of operations that can be performed on each one. Now that you have an idea of the different datastores that you can interact with, here are the different operations that can be performed (according to RFC 6241):

  • get
  • get-config
  • edit-config
  • copy-config
  • delete-config
  • lock
  • unlock
  • close-session
  • kill-session

As you can see, there are many different operations, and this list may grow as more RFC revisions come out. For brevity, I wanted to highlight three of the operations mentioned: get, get-config, and edit-config. The get operation can be used to retrieve all device configuration and state information. Most of the time, you’ll see this used to retrieve only state information. Filters can be used to minimize the amount of data returned. The get-config operation is used to retrieve, like you can guess, all device configuration. This is the most common operation to use when gathering device configuration. Filters can also be used in this operation to minimize the amount of data returned. The edit-config operation is also literal – it’s used to edit the device configuration. One thing to note is that many of these operations have additional attributes and parameters that allow for more targeted execution. For example, the edit-config operation allows you to target a specific datastore (i.e. candidate before applying to the running config) and also include error-handing such as stopping or rolling back if an <rpc-error> message is generated by the server. These three operations will be the most common operations you’ll see when using NETCONF for the first time, but I encourage you to explore the RFC for more options!

As you can see, the Operations of NETCONF is huge and I can go on about the different datastores and operations available. However, I wanted to quickly highlight the Content portion of NETCONF.

When computers need to interact with one another, a common language needs to be established. This common language is established through data models. The current industry-standard data modeling language supported by IOS-XE devices is YANG. Like I mentioned previously, I could (and might) write an entire post on YANG alone. There are many components to YANG and I personally find the entry barrier pretty high. However, I may feel encouraged to create a separate post on YANG. For now, just know that YANG is the data modeling language used in the exchanging of data.

Now that you’ve had a brief overview of NETCONF and its operations, let’s move on to RESTCONF!

RESTCONF

After struggling through NETCONF, I was relieved to learn about RESTCONF…

RESTCONF runs over HTTPS (port 443) and provides the familiar HTTP methods when exchanging data: GET, POST, PATCH, PUT, DELETE. I say these are familiar because, being in the network automation journey, many of us are learning this new world of RESTful APIs, which use the same operations. Besides having some familiarity with the methods of exchanging data, RESTCONF also allows for another (possibly familiar) data format: JSON! Along with XML, JSON is another data formatting option available with RESTCONF.

RESTCONF Operations

Interacting with a network device via RESTCONF is essentially interacting with a REST API endpoint using HTTP methods, with the network device acting as the endpoint. RESTCONF follows REST principles including a client-server architecture, uniform interface, and being stateless. Being stateless brings up one of the big differences between NETCONF and RESTCONF: NETCONF is session-oriented and stateful, while RESTCONF is stateless. What this means is that RESTCONF interactions are one-and-done. The server will not keep an active session open with the client. This is a major security benefit since it can protect from session hijacking and other attacks that take advantage of open, consistent sessions.

So we have the transport down (HTTPS/port 443) and the different HTTP methods that can be performed against a network device (GET, POST, PATCH, PUT, DELETE). For more information on the HTTP methods, please find the link in the References section. Along with the HTTP methods, it would also be good to familiarize yourself with HTTP status codes. As part of every response, an HTTP status code will be provided to show the status of the call (find link in References section). These status codes can be crucial when learning an API or troubleshooting errors.

The last piece I want to discuss about RESTCONF is the content or payload. As with NETCONF, YANG is the data modeling language you’ll run into with RESTCONF on IOS-XE devices. For more information on YANG, please check out RFC 7950 in the References section. This is the latest RFC I could find. It specifies some additional standards for mapping with NETCONF. As mentioned previously, I may write a separate post just on YANG.

SO WHY CARE?

The biggest question I always ask myself after learning a new topic is, “How does this fit into the bigger picture of networking and why?”. This is important to note and ask yourself because if you figure out why and how each technology fits into the bigger picture, it will be easier to retain and much easier to explain to other people in the industry. If you constantly view each of these protocols/technologies in individual bubbles, you’ll never understand how they all connect or what they are used for. For example, one may ask, why wouldn’t we just keep using SNMP for monitoring and use an open-source Python library like Netmiko or pyATS/Genie to communicate and return structured output to us? Both are great questions and, depending on the use case, you may want to use those options over NETCONF or RESTCONF. That’s why it’s important to understand the how and why before assuming a newly-learned technology or protocol is the best… only because it’s new…

PERSONAL TAKE

As part of all my posts, I’ll finish each post with a personal take or opinion about the topic discussed. I prefer to do it this way, so that it hopefully sparks a thought or discussion point from you.

With network automation growing so rapidly and vendors, such as Cisco, releasing software that have built-in features that promote network programmability and automation (RESTCONF/NETCONF/On-box Python), I would not be surprised to see NETCONF disappear. I think it will disappear due to the high barrier of entry, lack of major adoption, and the complexity of XML versus JSON. Of course, it will not completely disappear, but I think RESTCONF will take over and become more prominent over time. By making every network device their own REST API endpoint, it will provide better manageability and be easier to scale and integrate into a larger SD-controller in the future. The uniformity of REST may provide more value and opportunity for both vendors and their customers by just keeping everything simple (as long as the REST API is consistent across the same family of devices (i.e. IOS-XE, NX-OS, etc.). For how obvious it sounds, many engineers would just like these vendor solutions to be simple to understand and operate. After understanding, we will then try to turn all the nerd knobs and customize it. I believe the many network automation frameworks that currently run over SSH will continue to be the de facto for the unforeseen future, since SSH is the lowest common denominator when it comes connecting to a plethora of devices (old/new, different vendors, etc.).

I hope you enjoyed my very first post and look forward to hearing from you!

References:

NETCONF
RFC 6241: https://tools.ietf.org/html/rfc6241
IETF-Revised datastores: https://tools.ietf.org/id/draft-ietf-netmod-revised-datastores-08.html#rfc.section.5.1.2
Cisco doc: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/169/b_169_programmability_cg/configuring_yang_datamodel.html

RESTCONF
RFC 8040: https://tools.ietf.org/html/rfc8040
Cisco doc: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/169/b_169_programmability_cg/restconf_programmable_interface.html
Cisco DevNet: https://developer.cisco.com/docs/ios-xe/#!enabling-restconf-on-ios-xe/restconf
HTTP Methods: https://restfulapi.net/http-methods/
HTTP Status Codes: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

YANG
RFC 7950: https://tools.ietf.org/html/rfc7950