It’s common practice for service providers to automate common tasks in their network environment. In the more open network environments we see these days OpenConfig is making this possible. OpenConfig is an informal working group of network operators that are trying to move the networking world to a dynamic, programmable infrastructure. OpenConfig promotes a vendor-neutral model for network management that uses YANG, a data modeling language for data sent over the NETCONF configuration protocol.
What are the motivations behind this model-driven network automation? The motivations are three fold.
- Speed and scale are demanding automation and monitoring capabilities
- Some view it as a competitive advantage
- The cost of IT operations can be reduced
Motivations aside, organizations are interested and vendors are implementing these capabilities. But to do so requires a new way of thinking, especially if you’ve been doing networking for a long time.
The Days of Old
A familiar configuration methods among network administrators is the Command Line Interface (CLI). For many this has been a love/hate relationship. The CLI generally gives you access to all the underlying configuration capabilities of the device but there’s certainly a learning curve involved. Cisco has an entire certification program that was built around people mastering their CLI, we call it the Cisco Certified Internetworking Expert (CCIE). And while that program has changed over the years the fundamentals of it stem from the masterly of the CLI.
From there many remember the Network Management System (NMS), OpenScore, NaviScore, HP OpenView and the list goes on. These network management systems were built with bulk in mind. Network operators working for large service providers rarely have access to the CLI, but rather have access to a subset of capabilities presented in a Graphical User Interface (GUI). This models protects the organization from unintentional adds/moves/changes, and limits the scope of knowledge that most network operators need to perform their job task. One fundamental problem with these solutions of the past is that they relied on the Simple Network Management Protocol (SNMP) for communication. That was ok fifteen years ago, but networking has changed, SNMP has limitations and vulnerabilities, and programability and flexibility are now king.
SEE: System monitoring policy (Tech Pro Research)
Enter the Data Model
So I feel like its important to put this into perspective and really flesh out why you need a data model, and how OpenConfig is helping. Let’s start by talking about something simple like the configuration of a routing protocol like OSPF. At a high level you define the routing process, define neighbors, and perhaps configure authentication. Simple right? But this configuration when put into practice varies on Cisco, Juniper, Cumulus and so on. The problem we face is that if you’re trying to automate this you’d have to go through scripting each vendors CLI individually or even deal with a vendor API which could vary as well. Getting things into a consistent format is hard to do, and this is why a data model is so important.
For example, if we were to use Telnet or SSH the return data would be raw text. If we used something like a REST API then the return could be JSON. So with various types of return data and various formats we have a problem handling this at scale.
Now for me what I often relate this back to is how the Cisco MARS would normalize events that came in from many different types of devices, all having different logging formats, and then presents that data to you in a way that everything looked consistent. It’s basically the same thing. Using NETCONF which takes advantage of YANG, it doesn’t matter what device you ask for interface details, it always returns structured data that we can parse consistently. Now turn that into configuration parameters and NETCONF is taking us into the right direction.
SEE: 20 quick tips to make Linux networking easier (free PDF) (TechRepublic)
What Are The Drawbacks?
In terms of drawbacks, I believe that one of the biggest drawbacks to implementing this in my own organization was more of a holdback rather than a drawback. My concern was more about the learning curve rather than the benefit of consistency. Having a long history of working on the CLI in a Cisco environment I was concerned that I would be convolutions things more than benefiting from the use of model-driven programmability. Now, going back to OpenConfig, imagine that you have four different router vendors. Each one is going to have special vendor capabilities but at the same time they are going to have common values as well. OpenConfig makes sure that we use a model that can present standard capabilities for monitoring and configuring back to the operator. This means that we can maintain consistency across our multivendor environment. Not much of a drawback here.
What To Do Next?
Once you’re convinced that you want to invest a bit more time in OpenConfig, NETCONF and YANG here are several resources that you can begin with.
- Cisco Press book – Programming and Automating Cisco Networks: A guide to network programmability and automation in the data center, campus, and WAN
- Cisco Presentation from Tech Field Day 15 on Advanced Cisco IOS XR Programmability: Model-Driven Manageability with Santiago Alvarez
- YANG Model Tutorial on Cisco Devnet
- OpenConfig: Standardized Models For Networking written by Ethan Banks
There are so many resources out there to get going I’d recommend looking through the above resources first and then from there you can branch off into additional topics. While it might seem a daunting task it will pay off in the long run. You might put it into perspective this way. Do you need to learn the guts of programability and YANG to be a network engineer? No. However you do need to learn these things if you plan on being a good network engineer in the years to come. It’s not going anywhere. More vendors will adopt these models. It’s time we embrace it and make it our new norm in network automation and programability.
Also see:
- How to create custom dashboards with NGINX Amplify (TechRepublic)
- How to quickly install OpenNMS on Ubuntu 16.04 or Debian 8 (TechRepublic)
- 10 bad habits network administrators should avoid at all costs (TechRepublic)
- Video: Tips for designing your network to meet the needs of different sets of users (TechRepublic)
- Cisco Certified Network Associate (CCNA) & Professional (CCNP) Certification Training (TechRepublic Academy)
