Cisco Blogs

Why is Cisco Teaching Me Python? 

- March 8, 2018 - 12 Comments

At a recent network programmability workshop one of the attendees asked, “Why is Cisco teaching me Python?

I was leading a workshop for a group of senior network engineers at a large financial company that was organized and sponsored by a member of their cloud leadership team.  This made the workshop and audience a bit different than most of the DevNet Express, Cisco Live, and DevNet Zone events I had been supporting for the last year.

Hank Preston presenting about programmable networks at Cisco Live in Melbourne, Australia

Hank Preston presenting about programmable networks at Cisco Live in Melbourne, Australia

It was different because at the Cisco events the audience “self-selected” to attend the workshop or presentation.  The audience in those events was already convinced of the importance of learning topics related to programmable networks – like Python, JSON, REST APIs, etc.  However, in the case of the financial company sponsored event, the audience was in attendance because their management TOLD them to attend.  Or at least that was the case for several of the audience members.  To be fair, at least half this audience was excited to be there and had already been experimenting with many of the topics.  Nonetheless, it struck me that this was an entirely fair question

As you might expect, a question like that generated quite a bit of discussion on the topic.  We may have fallen a bit off schedule, however I think the time was well spent.

Well… Why Is Cisco Teaching You Python You Ask?

So what is the answer you wonder… well simply put (and this is exactly how I answered it in the workshop), Cisco is teaching you Python for the same reason Cisco taught you subnetting, the OSI model, and fundamentals of spanning-tree and routing.  Because understanding Python is critical to your success as a network engineer, and Cisco wants to help network engineers be successful.  

Now, not everyone in the audience bought the answer immediately.  “Why is it critical?” was asked several times.  “I didn’t become an network engineer to become a programmer” may have been said a few times as well.

The argument was made that even though network automation was clearly the direction of the industry (no real disagreement on that front) there were many many tools available for them to use to automate the network without writing any code.  And if the time came when they DID need to code something directly, their organization had software developers that could do that work for them.  Those points are definitely true, and for some engineers that maybe an approach that works for them and their company.

However, I feel I’m a much better engineer because I learned the details behind subnetting rather than rely on “The Subnet Calculator” online to explain the difference between Layer 2 and 3 communications. I understood WHY I configured portfast and BPDU guard.  In the same way, I believe the best network engineers in the future will be able to:

  • build their own Python scripts (or curate and modify scripts they find)
  • query the APIs for their network devices, controllers, and management systems
  • contribute to key Open Source projects that are becoming the foundation of network automation

For those reasons I’ll continue to lead programmability workshops with customers, make network programming basics videos, as well as build and deliver all the amazing NetDevOps content on DevNet, at Cisco Live, and at other events around the world.

What do you think?

Are you on “Team Python” as you look to build your own career?  Or do you think all this focus on programmability skills is a flash in the pan?  Tell me in the comments or on Twitter/LinkedIn.  Let’s keep the discussion going.

Leave a comment

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed and HTML formatting will not appear.


    Python is a handy application to have in my tool belt. I would like to see better documentation of the modules that Cisco imports into the python environments embedded in their equipment. I'm using Nexus 5K gear running version 5 NX-OS software, but the website referenced in the "help()" documentation,, doesn't exist. Difficult to use the module and it's various classes w/out a roadmap.

    Great article. Shows what direction the network community is moving, and moving fast. Not claiming we have put CLI to bed in the next 2-3 years, but it will happen :D

      Thanks Henrik! I'm not sure the CLI will ever go completely away. That would indicate that direct network engineer interaction with devices is no longer needed, and I doubt we'll ever go quite that far. There will still be a need for troubleshooting, exploring status, verification, etc... all of that is much easier to do via CLI than having to craft an API call each time..

    In the beginning I hoped all the controllers and tools would give me all the solutions I want without programming. But I figured out at least in the moment there is a lot you can't get without at least manipulating some python scripts. In the moment one of my topics is to convince my colleagues that at least they should be able to understand the python scripts and use them instead of the cli and the copy & paste approach they are used to for such a long time.

      Christoph.. I think a lot of us had big expectations for some of the new SDN tools and features that they would fit all our needs and use cases, and have come to a similar conclusion as yourself. I'm not sure we'll ever get to the point where the majority of engineers and their problems can fit neatly into packaged solutions from Open Source of vendors.. I expect it will always be a bit of both...

  1. I have been scripting for years. Typically a few lines of code for filtering log files or automatically generating config files. I'm happy to learn Python or Perl because, despite the learning curve it does pay you back. HOWEVER Networks are progressively more sophisticated, evolving from relatively small flat topologies the average enterprise could now run converged services in parallel with interior and exterior protocols facing multiple service / cloud providers. Getting skilled engineering help is tough at the moment and the complexity of current solutions risks configuration error through misunderstanding or genuine mistake. Adding code on top of this complexity, to me, seems like a significant mistake. Tunability of traffic flows across the control plane using mature APIs obviously adds value. But done badly this is likely to increase instability, not reduce it.

      Alexis, Just like anything new, scripting with Python and using new APIs for automation will require engineers to learn and master the skills before deploying widely across their network. Anything "done badly" will cause problems as I'm sure can all relate to and share anecdotes of network changes gone wrong. But the fact is that the ability for network engineers to keep up with the rate of change, scale of networks, and processing of requirements is already over extended, and without automation and programmability we will continue to see cases of human error induced outages and errors. We must all learn the skills needed so engineers can once again focus on design and engineering solutions, then leveraging these new tools (one of which is Python) to first test and then deploy widely at scale. Done correctly, this will have massive positive impact to stability. Thanks! Hank

    Python is without any question a must have tool. Agree 100%.

  2. I am new to the networking field. But I strongly believe that Programming is the new way to go. I was able to exercise more control over the virtually simulated GNS3 network than I ever did in the CLI. Simply, I vote for Team Python.

    Great Article. I am a big believer that all traditional network, voice, security engineers should know some programming. Yes, there will be tools to make this easier for those that are not developers, myself included, but understanding how devices communicate with each other and controllers via APIs is very important. There will be a big opportunity for those who can understand programming and can also apply it to traditional networking practices for the purposes of automation, alerting, and self-healing. Those that plan to cling to their CLI and not ascend to the way of IT will soon find themselves obsolete.

      Couldn't agree more Jonathon!

    Good work with that article. A really nice and fresh theme. :)