Cisco Blogs
Share

Network Automation – Now!

- November 9, 2017 - 4 Comments

Why software automation support is needed in today’s networks

Anyone working in network admin today knows that the network has long since blown passed the days of being managed as a collection of devices.  The days of network admins using the CLI to configure devices, or “automating” some tasks with TCL scripts may have worked in the 1990’s or early 2000’s, but it’s simply not enough to keep up with the scale and complexity of today’s networks.  That said, the business mission for the network hasn’t changed.  If anything, in today’s world of digital transformation, that mission has become even more critical – highly reliable services, rapid remediation of issues, efficient services upgrade process, security.

Administrators must have the ability to manage all those network devices and their services thru software.  As a result, the use of traditional CLI copy-paste configurations process is going away, and being replaced by a vast usage of API’s to automate large scale networks.

This is what Cisco’s DNA Intent Based Networking is all about.

Network administrators can now build simple, yet very powerful software to manage their networks, to automatically detect and alert them for any abnormal behavior, get real time (or close to real time) network status, easily configure and maintain the deployed network devices, etc.

Programmable Networks and the New World of Intent Based Networking

This new world of the intent based, programmable network is not possible unless you have network devices that are programmable. Everything should start with a proper infrastructure management on the device itself.  That’s where Cisco’s IOS-XE comes in – a newly designed, highly programmable operating system for Cisco switches and routers in the enterprise network, which aids the network administrators to manage today’s networks.

IOS-XE has support for various popular open standard modelled API’s for ‘off-box’ automation to achieve this. (I.E: OpenConfig, NetConf/Yang):

By modeling each network element’s attributes (e.g. BGP, QoS, ACL, etc.) in a structured data structure (e.g. XML/JSON formats, network admins can leverage various parsing API’s techniques (e.g. Python’s xml.dom.minidom), to develop easy to maintain and easy to scale code.

Since we will not rely on any dedicated CLI syntax to push and/or get the device’s configurations/attributes, the API approach is much more preferred  as new features/attributes can be augmented to the modeled tree.

This modeled system representation saves a great deal of development cycles for the customers.  As long as a network vendor sticks to the models approach, customers can use the same script to automate a Cisco switch, an HP switch, a Juniper router… – Customers no longer need to spend time and money hiring people to specifically develop automation for HP CLI, or for Cisco CLI or for Brocade CLI… The same script that configures the common device’s attributes with Netconf will work on any vendor!

Network Devices, now with Linux Built In

In recent years, many network vendors push to have Linux OS based flavors on their devices’ operating systems, to allow more openness when it comes to automating processes to be executed on the devices themselves (AKA: On-box automation).
Cisco’s IOS-XE has a feature which allows network admins this capability.
It’s our IOS-XE GuestShell.
Let’s start by understanding what IOS-XE’s Guestshell feature is all about:

  • Guestshell allows admins to perform common Linux operations in a secure manner, thus enable hosting/running open Linux applications, yet still making sure that they will not harm any critical functionality on the switch.
  • One of the benefits of a Linux based guestshell is allowing admins to use any scripting language out there, to perform basic automation tasks – One of them is Python, which is supported as a built-in programming language on our IOS-XE Guestshell.

To learn more about our Guestshell capabilities, see this Cisco blog post.

Analysts Love Cisco’s GuestShell
Recently, Miercom did a report showcasing our Guestshell:

  • To demonstrate IOS-XE’s Guestshell capabilities, we executed a Python script that runs as an agent on the switch to detect any configuration changes done on the device.
  • Upon detection, the device will automatically email the admin, outlining the changes done on the device
  • In order to make this work, we seamlessly enabled the Guestshell to role as a mail server using basic Linux admin commands.
  • I didn’t have to look that far when I had to think of an automation use case to demonstrate our Guestshell. Our Cisco DevNet provides countless code samples, online tutorials, and on-demand LABS – All for free!! I edited a Python code sample via our open to the public GitHub, and implemented the above use case pretty easily.  DevNet also gives you lots of help if you want to explore Python sample code for on-box, off-box, or with network controllers.

Well, Huawei has no matching feature for Cisco’s Linux Guestshell in their S5720HI.

Another point about NetConf support for off-box automation

When it comes to off-box automation, NetConf ( an open-standard models protocols) has become highly popular, due to the rise of software and automation in the networking world. This is where the future of the network automation is going…

Let’s see what NetConf is in a nutshell:

  • NetConf is an industry standard (IETF) network management protocol (RFC6241)
  • It’s probably the closest thing we can see that could be a unified, multi-vendor API (with some vendors’ specific extensions – AKA: the “secret sauce”)
  • It allows customers to re-use the basic network configuration and management API’s across various vendors that support this protocol

As mentioned above, Cisco’s IOS-XE supports NetConf’s standards, which allow customers to automate Cisco devices using any client that can SSH to our devices via NetConf’s port (port 830).

What about the Competition?

And what about Huawei you may ask? While claiming to have NetConf support on their S5720’s, Huawei was not completely clear in their tutorials. In order to use NetConf on their S5720HI’s, customers are required to purchase their Agile controller which will role as the NMS (Network Management System – see the below diagram taken from their public tutorial)

Additionally, they recommend that customers should avoid using CLI based configurations, should they choose to go with NetConf, as it might create inconsistencies in their device’s settings!

With those caveats, Huawei “breaks” the idea of NetConf’s concept with their current support, since it requires a “special care” and more investment from the customers in order to make it work

But don’t take my word for it.  See for yourself.  Download the complete Miercom report, click here.

The bottom line is that having the network managed through software makes the network admin’s life much easier.  With tools like IOS-XE, and learning resources and sandboxes from DevNet, you have what you need to be the network admin of the future.

Tags:
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.

4 Comments

    The blog looks good. So here's a question for you: If I wrote some Python code and ran it "on-box " - would that program access things directly from the box using some sort of system call, or would you do an API call and use NETCONF/RESTCONF from there? EG: What if I wanted some code, running on the box, to just send a message whenever a port did a certain number of packets or something.

    • The best practice for an on-box Python automation use case would be to use the "cli" Python module that we provide within our built in Python interpreter on the guestshell. That will allow you to get the eth ports packets counters, and accordingly, your script's logic will take some actions - I.E: send you an e mail, write an alert in a Spark room, etc. (The sky is the limit here, really :-))

      • Or we could perhaps use something like: github.com/CiscoDevNet/ncc/blob/master/ncc-simple-poller.py And when we start making use of recent developments in IOS-XE 16.6.1, we can even leverage telemetry: github.com/CiscoDevNet/ncc/blob/master/ncc-establish-subscription.py Going in this direction gives us model-based access to operational data for these kinds of tasks, and the Linux environment of GuestShell makes this really easy. Cheers, Einar (Note, telemetry extension for ncclient are currently in an ncclient fork until the IETF drafts achieve RFC status. Code is at github.com/CiscoDevNet/ncclient)

          I absolutely agree with you on the many options we provide for our customers to automate our network gear - let's keep more of those great examples coming on our GitHub :-)

Share