Cisco Blogs
Share

How a Traditional Network Engineer Got Started with Network Programmability

- August 22, 2017 - 3 Comments

When I was asked to write my experiences preparing to present in the DevNet Zone at Cisco Live 2017, the first thought that came to mind was, “The greatest trick I ever played was convincing the room I was an expert.”  Now I may be taking some artistic liberties with Kevin Spacey’s monologue from the 1995 movie ‘The Usual Suspects’ (which in turn paraphrased the 19th century philosopher Charles Baudelaire), but that phrase accurately represents my six weeks leading up to Las Vegas.

Overflow audience for my “Introduction to NETCONF, RESTCONF,
and YANG” workshop in the DevNet Zone at Cisco Live 2017

Before I provide details on how I pulled off my trick it would be helpful if I provided a little background. At the start of the year I was asked if I had any interest in presenting an “Introduction to NETCONF, RESTCONF, and YANG” with a companion lab. The thought was if the material was presented by a traditional network engineer it would be better received.

The term traditional network engineer is a pretty accurate description of my career. I would describe myself as the typical BGP/QOS/Spanning-Tree network engineer. Significant portions of my career have been spent designing, deploying and supporting large scale WAN networks.

Like many of my peers I’m just starting to dip my toes into network programmability by teaching myself a little Python. But by no means would I have considered myself anything more than a novice.

Armed with the knowledge that I had 6 months to buckle down and learn the material I signed up to present a DEVNET classroom session at CLUS, and create a couple of guided learning labs. Now this would be a much better story if I led the reader to believe that I couldn’t spell YANG when I started to create the content. In reality, I had a good understanding of what function NETCONF, RESTCONF and YANG provide. I could explain why one might use them in a network. What I didn’t have was a strong grasp of how someone would go about writing the corresponding code.

My starting point was the Network Programmability for Network Engineers learning labs on DEVNET. Specifically, I started with “Introduction to Device Level Interfaces.” The content was a perfect mix of instructional content mixed in with hands on labs. If you are just starting down the path of Network Programmability I highly suggest you start with the Learning Labs. While I’m very proud of the content of my recorded session at Cisco Live, the Learning Labs are a great resource. In fact, I may have ‘paraphrased’ some of the content. More on that later.

After building my foundation with the learning labs, it was time to get my hands dirty and start digging into some code. I don’t know about anyone else but I’ve always likened learning a programming language to learning a second language in high school. I found that I was able to read a second language much easier than I could write. To this day if someone says something to me in Spanish, provided they are speaking slowly, I can usually figure out what they are saying. My issue has always been formulating the words, so I reached out and asked someone for help.

In my case help came in the form of a couple of scripts written by a co-worker. The scripts weren’t anything overly complex. One pulled the hostname from a router. The other pulled interface statistics. By using a script for which I knew the expected output I could reverse engineer the code. More importantly I also had someone that I could practice ‘talking’ to when I tried to make code changes.

The last step to convincing Cisco Live of my expertise in writing code was the result of some bad planning. As a companion to my presentation I was asked to write some guided labs for the DevNet Zone workbench sessions. The labs were designed to use a virtual router running on the student’s laptop. Armed with my borrowed code, the students and I would walk through examples of using NETCONF to pull configuration details from the router. The students would also use Postman to get hands on experience using RESTCONF. My plan was flawless until I realized a week before Cisco Live that I still hadn’t found a way to get a startup configuration on the router.

Facing a pending deadline I decided I was going to write a Python script that would provision 2 interfaces on the router. What I found is that while I could explain in a clear concise manner how NETCONF with a YANG data model could be used to accomplish this task, my attempt at a script resulted in more errors than a 100 Mbps half-duplex link. After wasting the better part of a day without success I gave up and went back to the drawing board. It was at this point I found the magic of RESTCONF and Postman.

Screenshot above shows how easy it is to convert API calls to code using Postman

Postman is an amazing open source tool for creating and sending REST calls to a device. In the lab the students would use the tool to create REST URIs to pull various interface statistics. The final step of the lab was to use Postman to modify an interface configuration. More importantly Postman has a built in function that allows you to convert any REST call to various programming languages. With Postman I could quickly create my interface configuration, test it with the tool and convert it to Python.

After that it was a simple process of tying 3-4 basic Python scripts with a bash executable and I’ve got a fully configured router without ever touching the CLI. It was at that point that I began feeling I should be on the billboard in front of Mandalay Bay, not Chris Angel.

Tags:

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

3 Comments

    Postman is great tool to test REST API calls quickly without running a standalone client, used widely by different kinds of developers. Thank you for sharing your experience!

    The DevNet session on Sat/Sun was a great start into the CiscoLive-week. I hope for something similar next year!

      Thanks for the feedback Karsten! I'm working with the DevNet team to see about extending the session to provide more real world examples and some additional code walks.

Share