Solving Multi-vendor Network Management Complexity with OpenConfig

As the industry moves towards controller managed networks, where the operator describes what and not how to manage, configuring and maintaining networks from a single vendor remains very complex. Add in the need to manage devices from multiple vendors, and the complexity is multiplied.  Yet network operators typically have devices from multiple vendors and must use their models to configure, integrate, test, and manage those devices.

A better way to manage multi-vendor networks is here: The use of models from OpenConfig, which is fully supported in Cisco IOS XE Software.

Why use OpenConfig?

OpenConfig is an effort by network operators in collaboration with vendors to build open, software-defined, vendor-neutral, and model-driven principles for network configuration and management. OpenConfig enables the use of:

◉ Data models for configuration and management using Yang 1.0 that are vendor neutral

◉ Streaming telemetry for monitoring and obtaining incremental updates (SNMP is passé), which enables a Pub/Sub interface that alerts the collector of changes almost as soon as they occur on the device

The OpenConfig participants include large corporations and service providers like Google, British Telecom, Microsoft, Facebook, Comcast, Verizon, and Level 3.

OpenConfig also allows vendors like Cisco to add their own tweaks via extensions to the models.

Figure 1 shows the OpenConfig models, which are published on GitHub.

Figure 1. OpenConfig Models

Cisco’s Embrace of OpenConfig

Many customers with Massively Scalable Data Centers (MSDCs), such as Microsoft, are very interested in OpenConfig as they run huge data centers with devices from multiple vendors. Various other networking vendors such as Juniper and Arista also support OpenConfig models.

The Cisco IOS XE architecture in Figure 2 lends itself to implementation of OpenConfig models with little effort because Cisco IOS XE already supports the OpenConfig enabler:  streaming telemetry.

Figure 2: Cisco IOS XE – Functional Architecture

Cisco developers have tested and implemented many native models for most of the Cisco IOS XE features. Native models are specific to Cisco devices and platforms. We can implement the OpenConfig models so there is no duplication of effort. The request for an OpenConfig data element is converted to the corresponding native data element because Cisco models are typically a superset of what OpenConfig offers.

The architecture diagram in Figure 2 shows how the configuration and operational databases are common for native and OpenConfig models. We only need a way to translate between the native and the OpenConfig model elements.

Typically, we request a configuration or operational data elements, like those listed in Figure 3, and a corresponding native data element associated with it. Cisco IOS XE provides infrastructure to translate the OpenConfig data element to the corresponding native data element. So, the process of supporting OpenConfig models is typically not very hard if the native models for the corresponding OpenConfig models exist.

Figure 3. OpenConfig and Native Interfaces

Implementing Operational Telemetry with Cisco IOS XE

Cisco IOS XE provides two ways to implement operational telemetry, depending on whether the elements have performance implications, such as the number of interfaces and statistics on all the interfaces. These can be large numbers, since Cisco supports modular switching platforms with multiple line cards. Cisco IOS XE provides a way to get the data from the database using FastPath. For environments with fewer interfaces, the mapping infrastructure can be used to get the data from the corresponding native element.

Over the last few months, Cisco IOS XE developers have been actively involved in developing the OpenConfig models in multiple areas on Catalyst 9000 Series switch platforms for a customer in order to fulfill very interesting use cases which involve migration from SNMP. This entailed testing with the use of the customer’s network data platform and optimizing the implementation for scale and performance. The implementation catered to various telemetry types including on-change and periodic notification.

We engaged the customer in a co-development model where we provided an image with the new model implementation and the customer tested it in the network and gave us feedback. This ensured a quick turnaround time for any issues found at the customer site and completion of the use cases with verification in an actual deployment. The development cycle was completed once we completely automated the testing. We used Genie for operations and telemetry and an in-house tool for configuration models. This model of development eliminated the need for tradition DevTest and resulted in quicker delivery to the customer.

We have occasionally run into issues when a certain data element couldn’t be supported, due to the lack of functionality on the device. We have also encountered scenarios when the representation of a data element was inaccurate. Aside from working with the customer on that issue, Cisco is also raising the problem with the OpenConfig taskforce to make changes to the models.

Cisco continues to develop more OpenConfig models and will also upgrade the revision of the current models to the newer versions published in the upcoming releases of Cisco IOS XE. If you’re a network operator struggling with configuring and managing a multi-vendor network, struggle no more—OpenConfig is the way forward.

Source: cisco.com