Completed: ENAUTO (and CCNP)

Brief Journey Overview

My ENAUTO (and really my CCNP) journey began at least a year ago. No, I did not begin studying for these exams a year ago since the blueprints themselves didn’t exist at this time last year, but I did know they were coming due to the announcements at Cisco Live US 2019. What I mean by my journey is my shift in mindset to focus on automation and regain traction to achieve my CCNP. I’ve mentioned this in a previous post, but I attempted my CCNP a couple years ago (late 2018) and failed the Route exam. I realized that I failed because I did not agree with all the topics on the exam (i.e. Frame Relay being the biggest), which caused me to push aside studying and ultimately fail. I tried bringing myself to terms that the exam topics were what they were, but I just couldn’t shake it.

At the same time I was trying to study for the Route exam, I began experimenting and building my first Ansible playbooks, which ultimately began my network automation journey. I fell in love with network automation immediately and knew I wanted to learn more about it. I couldn’t understand why I had to spend time labbing up Frame Relay on an exam that’s supposed to set you up for a job now and provide further value in the future when there was the magic of Ansible playbooks that needed to be understood. Don’t get me wrong, I understood Frame Relay was on the exam because it’s still out in the wild, but I’d argue that at this point in its existence, it’s a whitepaper read on an as-needed basis. Luckily, I was at Cisco Live US 2019 in San Diego when they announced the revamp of the certification tests and the new DevNet certifications. I was ecstatic to hear all the changes. Finally, Cisco bringing automation to their traditionally networking exams and introducing a new lineup of DevNet exams. My goals were set, mind focused, and I knew what I had to do next… study, study, study!

My ENAUTO Experience

Now if you’ve been keeping up with my journey, you are probably wondering, “Didn’t he just take the ENCOR exam last month? This ENAUTO exam must not be too tough since he only needed a month to prep.” I want to preface and emphasize that before I began officially studying for ENAUTO, I’ve had work and personal experiences working with the topics presented on the ENAUTO blueprint. I was familiar with Netmiko and have produced Python scripts that utilized the DNAC and Meraki APIs. All my studying and prepping for the exam did not occur within the past month. I’ve had many experiences over time that have prepared me for this exam. With that being said, I still spent a good amount of time prepping for this exam. Pretty much every day (including weekends), I spent 1-3 hours a night studying. I’ve always preferred putting in consistent time on a regular basis versus shorter studying sessions during the week and long study sessions on the weekends (5+ hours). Not to say long study sessions are a bad thing, they just have just not worked effectively for me in the past. Also, I was blessed to have a pretty consistent schedule to study with minimal interruptions. I know life can get in the way a lot, but don’t let that discourage you! You can always find time by sacrificing time somewhere else in your day (i.e. watching TV or Netflix).

Let’s begin talking about the actual studying and exam experience. Overall, the exam was extremely fair and I wasn’t caught off guard by any of the topics. My exam prep helped with this, mostly due to the fact that I read each exam blueprint topic thoroughly. For example, when a blueprint topic begins with ‘Implement…’ or ‘Construct…’, you better have done that specific task in a lab environment. All of the errors and troubleshooting you go through while labbing help solidify your knowledge of the topic. For other exam topics, I would also consider labbing them up for safe measure. If you do not have a personal lab environment (physical or virtual), I would highly encourage you to use Cisco’s DevNet sandboxes. There are two types: Always-on and Reserve only. The Always-on provide a read-only environment, but are great to test most API calls. The reserved sandboxes provide a read-write environment and free reign. You can perform any necessary task, which is crucial when it comes to configuring or running code. These environments are awesome. The popular sandboxes can sometimes be tough to reserve, but you will definitely need to reserve a few during your ENAUTO studies.

I will not get into specific or technical details about the exam, but I will say that on top of knowing how each protocol or product works (i.e. RESTCONF vs. NETCONF), you should understand WHY one may be preferred over the other in a given situation. I’m not saying that an exam question is going to ask you, “Why is RESTCONF preferred over NETCONF?” or vice-versa, but by learning the WHY, you can better understand how the components of each protocol work and know their differences. Learning more about the WHY has always been stressed in my blog posts and I consider it to be a good study technique. If you know WHY a specific protocol or product was created and the challenges it solved, then you’ll gain a better understanding.

Personal Study Tips

With the lack of an official certification guide or your typical text book, the ENAUTO may be tough for some people to begin their study journey. However, the best part of the DevNet certifications is that there are a TON of free resources on the web. For me, I personally like to have one book resource, 1-2 video resources, and of course, a labbing environment. Since ENAUTO does not have an OCG, I used publicly available Cisco white papers and (mostly) DevNet documentation for my reading resources. For video content, I went to my ol’ trusty CBT Nuggets and also tried a new one: Pluralsight. While I’m not going to compare them, they both presented their content in a way that complemented one another. I watched CBT Nuggets first, so that gave me a good introduction and overview of the content. I personally love the way their content is presented, so it kept me engaged. I went through their 10 hour ENAUTO course within a week. Pluralsight has a slightly different structure from CBT Nuggets, but they ultimately have a collection of skills that make up a complete course. The ENAUTO course is taught by Nick Russo – he is awesome. He dives deep into labbing each major exam topic and really puts the onus on you to really the learn the content. He provides reference files for each course, which is great for when you go back through the content. Overall, I highly recommend both, CBT Nuggets and Pluralsight, to anyone searching for ENAUTO video training content.

One last note before I begin discussing my next steps. In the final week leading up to the exam, I had a discussion with some of the people in the The Art of Network Engineering Discord server (which you should join if you want to be surrounded by some awesome networking people!) about final prep steps. My main concerns were, “Do I know enough? Did I dive deep enough into each topic?”. This may be a common theme for everyone before a Cisco exam, but it was more difficult for me because, unlike other Cisco exams, the automation and DevNet exams are more focused on programming, which if you know programming, can be very open-ended. There are many ways to solve the same problem when it comes to programming. It’s not as straight forward as knowing the different LSA types in OSPF or some other concrete networking fact. With that being said, I received words of encouragement from many people in the Discord, which really helped! I highly encourage anyone, who hasn’t already, to join an online IT community (The Art of Network Engineering is a good place to start!). These communities can really help and make you realize that your problems are not always specific to just you.

Next Steps for Me

As I wrap this up, I want to shed some light on my future plans. After studying (pretty aggressively) for the past few months, I’m going to take a break from certification tests during the holiday season and pick back up in early 2021. My next goal is to pass the Cisco DEVCOR (350-901) exam, to ultimately achieve my DevNet Professional certification.

If you have any questions or feedback, please do not hesitate to reach out to me on here by sending an email (check the bottom of my homepage) or by hitting me up on Twitter (@devnetdan). Thanks for reading!

The ENAUTO Journey Begins

After passing the ENCOR exam last week, I decided to jump right into studying for the ENAUTO exam. To highlight my cert journey here: I plan to have my CCNP Enterprise by the end of the year and my DevNet Professional by May 2021. The ENAUTO exam will double up and satisfy a requirement for each certification (CCNP Enterprise/DevNet Professional).

This week, I completed the CBT Nuggets ENAUTO course. I think it was a great course to get your feet wet into the world of Python and Cisco APIs. The reason I say Cisco APIs specifically is because 80% of the ENAUTO is based on APIs that interact with three popular Cisco solutions: DNA Center, SD-WAN, and Meraki.

With only one week into studying, I believe the ENAUTO exam is actually going to be “fun” to take. I thought the DevNet Associate exam was also “fun” because of the exposure to all the new and trendy technologies surrounding that test: network programmability, interacting with APIs, and exposure to different Cisco solutions (ACI, DNA-C, etc.). Once you run a few successful API calls and understand how each API works, it opens up your mind to the endless possibilities that comes with network programmability. Another reason I like the ENAUTO is the limited scope of the exam. The limited scope allows you to dive deeper into each exam topic, which is exciting to me because it allows me to really get to know the APIs of some of the most popular products in Cisco’s portfolio. With the ENCOR exam, you had to study many different technologies spanning different layers of the OSI model. The ENAUTO focuses on network programmability and, more narrowly, the APIs for DNA Center, SD-WAN, and Meraki. As long as the API documentation is organized, I enjoy exploring the docs and creating calls with Postman or writing scripts with the requests library in Python or the SDK (if available).

This is a short post this week, but my upcoming posts will revolve around the ENAUTO exam topics. If you are unfamiliar with the ENAUTO exam or its topics, here’s a link. Feel free to message me on Twitter if you have questions or have feedback on which topic you’d like to read about first!

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.


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.


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!


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.


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>

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!


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.


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…


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!


RFC 6241:
IETF-Revised datastores:
Cisco doc:

RFC 8040:
Cisco doc:
Cisco DevNet:!enabling-restconf-on-ios-xe/restconf
HTTP Methods:
HTTP Status Codes:

RFC 7950: