OpenConfig - a standardized approach to configuring network equipment

Original author: Ethan Banks
  • Transfer

We want to share with you a free translation of an article from the Packet Pushers website about the complexities of configuring multi-vendor networks. First of all, they are faced by telecom operators. As the provider develops (including absorbing other operators), its network grows and turns into a complex ecosystem of various equipment. In small networks, this problem, as a rule, is not so acute. Which, however, is due to it - companies are trying, without good reason, not to buy iron from various manufacturers in their network. The complexities of the settings here tend to gravitate towards mono-vending.

Operator dilemma

One of the problems with network automation is that we do not have standardized interfaces for configuring network equipment from various manufacturers. In other words, it is difficult to configure a multi-vendor network using software when this process is different on each device.

When managed through the command line (Command Line Interface - CLI), network operators encounter significant differences in its syntax on equipment from different manufacturers. For example, the commands that configure BGP on a Cisco device running an IOS operating system are not suitable for the same task on a Juniper device running JUNOS. Switching from the command line to configuring equipment through application programming interfaces (APIs) does not solve the problem. Interfaces offered by manufacturers of network equipment differ in implementation and functionality no less than CLI. This is partly due to the specifics of network operating systems. Not all network operating systems were able to use the API, and it is not easy for manufacturers to integrate their support into their products.

Configuration models

One of the options for implementing software configuration of network equipment is configuration models. A data model defines the structure, syntax, and semantics of the data that we upload to network equipment. When transmitting them, in conjunction with the data model, a protocol is in effect that determines their encoding and the mechanism of transfer to the device itself. In other words, the model defines the rules by which we set the configuration parameters of network equipment. And the transport protocol transfers this data to the equipment. The configuration model can be compared with the SNMP protocol, which was originally developed for managing network devices, but for a number of reasons it is used mainly for monitoring. - approx. ed.

For us, accustomed to looking at any network device based on its command line interface, the “model” is represented as configuration lines. For example, “interface gigabitethernet 0/1” or “router bgp 65432” opens the Cisco IOS user to the configuration mode of the Ethernet interface or the BGP routing process. And transport in this case is the SSH protocol.

Many people realize that the future of network device configuration remains with the application programming interfaces. But moving away from the command line, we did not get away from the main problem: the unification of hardware configuration is now hampered not by command-line syntax, but by data models for protocols like NETCONF , created on the basis of descriptive modeling languages. These models are often written in YANGand they, like the command line syntax, vary greatly from manufacturer to manufacturer. As a result, users are still left with the same problem: on different hardware, the process of performing the same task is still different.

Diversity - not at all a highlight The

industry is faced with a problem: we want to automate the process of network configuration, but we cannot predict which models and interfaces will be needed for this. It sounds very familiar. Recall the SNMP protocol. SNMP is a generally accepted standard. All network devices support certain elements of the MIB. However, the most important parameters are unique to each equipment manufacturer and require the use of specific MIBs.

Can we alleviate this configuration nightmare by switching from CLI and SNMP to NETCONF (or any other way to transfer configuration) with YANG models?

Manufacturers, of course, will defend the uniqueness of their solutions, as well as the absolute need to use models that match their specific capabilities. And they can be understood. It would be unfair to criticize manufacturers for their desire to differ from competitors.

In turn, network operators have the same right to uphold the idea that networks are networks. BGP is BGP, ISIS is ISIS, OSPF is OSPF, and the Ethernet interface (for the most part) is the Ethernet interface, etc. And what's the difference, we configure the piece of hardware Cisco, Juniper, Brocade or something else. If you need to configure the same function on each of them, it is easy to guess that we would like it to be configured the same everywhere! How can we automate the network configuration when, we just have to turn away, somewhere we already need to correct the script, add a module, wait until the automation tool receives a patch from the manufacturer, or do you need some more dances with a tambourine?

OpenConfig and IETF come to standard network models

The current situation worries not only the author. The IETF has several projects of varying degrees of completeness aimed at developing standard network models based on YANG. For example: a model for managing RFC7223 network interfaces , a model for inventorying and managing RFC7317 , a model for configuring the SNMP RFC7407 protocol , and a model for configuring the OSPF protocol . But for some, the work of the IETF is moving too slowly, but for some, the models that they offer are simply not suitable.

In this regard, several large companies decided to bring the transition to standard network models closer by organizing the OpenConfig project . On the main page, OpenConfig writes about itself like this:

“OpenConfig is an informal working group of network operators united by a common goal - to transfer networks to a more dynamic programmable infrastructure by implementing the principles of software-defined networks, such as declarative configuration and model-based management. The main direction of our work is the development of unified data models for configuration and management, the support of which was originally built into the software and hardware platforms of various equipment manufacturers ”

Who are these companies? As of January 2016, among the participants on the OpenConfig page were: Google, AT&T, British Telecom, Microsoft, Facebook, Comcast, Verizon, Level3, Cox Communications, Yahoo !, Apple, Jive Communications, Deutsche Telekom / TeraStream, and Bell Canada. In other words, LARGE service providers with huge networks and data centers who need to maintain constant growth and ensure dynamic changes in their networks, preferably with minimization of various obstacles in their work.

At the dawn of its activities, the “informal working group” OpenConfig worked very productively, creating models for BGP, MPLS, and interface management. Now there are different models available (for example, a model for network telemetry) All of them are published on Github , and they are rapidly evolving, because it was for the rapid evolution that OpenConfig was created. On the OpenConfig FAQ page, they write: “At the moment, the project has no formal guidance. We rely on the fact that the participants here have common goals and visions, their actions are transparent and they try to maintain agreement on common issues. ”

Of course, if you start thinking about a project like OpenConfig, you will find two main concerns:
  1. Will network equipment manufacturers support OpenConfig?
  2. Does OpenConfig neglect IETF standards?

Consider the first - support by manufacturers. For network equipment manufacturers, the main question here is how difficult it will be for them to adapt existing network operating systems to work on the basis of models. For example, for Juniper, supporting IETF and OpenConfig models is easy. JUNOS is already essentially model driven. In addition, Juniper hints (unfortunately, the author does not give references to these hints - Ed.) That OpenConfig support will be in the next versions of JUNOS (possibly even in 16.1). Cisco announced support for OpenConfig for IOS-XR (NCS, ASR, CRS, XR) back in November 2015 (support for two OpenConfig models is already available - BGP and Route Policy - approx.ed.).

Will other manufacturers add support for OpenConfig models? Time will tell. But there are strong suspicions that this will be so. Remember who is behind this initiative. Money in the network industry is voting. A consumer who can pay, as a rule, gets what he wants.

What about the IETF? Is OpenConfig on its way? Yes and no. Everything is a bit more complicated. The OpenConfig project began in part as a reaction to the loosely ordered and unhurried work of the IETF. However, OpenConfig has partnered with the IETF to help them develop different standards. OpenConfig 2015 Annual Report PageBelow are the projects created by the OpenConfig working group for the IETF. So, although OpenConfig does not want to wait for the IETF to deal with its models, it recognizes the importance of the IETF and even makes its own contribution to their business.

What can OpenConfig give?

The main idea is that OpenConfig focuses only on models, paying less attention to finished APIs, which include both the model and the transport (for more details, see the articleJason Edelman). After all, our main goal is to achieve the integrity and predictability of the model on all network devices. The tools (transport) with which we load models onto equipment are important, but in their case the problem of selection and unification is not as acute as with the presentation and modeling of data. By and large, we don’t care how the data was uploaded. But it is very important that they are presented in the format we need - so that we can understand them, that is, so that our tools can easily analyze them and work with them.

When standard network models begin to be ubiquitous, the world will open up to develop tools, orchestration platforms, monitoring software and SDN controllers, and great tools for configuration and reporting will appear on the market. Software manufacturers will no longer need to focus on the most common vendors, deciding whose equipment to support, because the market for them will be the whole world of networks.

Ethan Banks, January 2016

The question of the availability of standard approaches for configuring network equipment from different manufacturers arose a long time ago. The same SNMP protocol was one of the attempts to solve it. He remained unresolved for so long that everyone seemed to get used to the situation. The advent of software-defined networks has raised it to the surface once again. The idea of ​​connecting any network equipment to the controller implies standard means of communication between the controller and the device. In parallel with this, a need arose to provide means for automating the configuration of networks — their programmability. Previously, the command line and the Web interface were most often used to configure network equipment, but now many manufacturers are actively adding support for various application programming interfaces (OpenFlow, OpenStack, JSON, XML, NETCONF / YANG, etc.). And even within the framework of one vendor we are offered a whole bunch of such funds. In this regard, the idea of ​​OpenConfig is quite robust and appropriate in terms of time of appearance.

The article turned out, in our opinion, a little utopian due to the huge desire of network equipment manufacturers to be unique. By agreeing to full standardization, they risk turning their devices into faceless boxes. Most likely, support for OpenConfig will be limited to programming certain functions. As usual, time will put everything in its place.

Also popular now: