Systems administrators in enterprise companies who are constantly upgrading, repurposing, and managing thousands of switches, listen up! Starting with release 17.7 of Cisco IOS XE, is support for a suite of Google Remote Procedure Call (gRPC)-based microservices that will simplify and lighten your workloads.
The Evolution of Remote Procedure Calls
In 2015, the RPC protocol got a major upgrade with gRPC. This open-source framework is accessible to a wide variety of programming languages. It was developed to connect services within and across data centers to obtain pluggable support for features like load balancing, health checks, authentication, and to connect distributed devices, mobile apps, and browsers to backend services.
gRPC provides the infrastructure to build a device management service to exchange configuration and operational data between a client and a server. gRPC Network Operations Interface (gNOI) is a suite of microservices used by gRPC, each corresponding to a set of operational commands on target devices. The current set of microservices that have been defined cover a wide range of operational tasks. gNOI works in conjunction with another unified management protocol to model data for network configuration and for telemetry: gRPC Network Management Interface (gNMI).
The gNMI and gNOI Workflow
Cisco IOS XE support for gNOI will allow administrators to programmatically manage Cisco enterprise devices. An example of a typical administrative workflow that can be automated using gNOI is shown in Figure 1. It begins with the identification of a device to be re-purposed, then resetting the device to its factory defaults and bringing it back into operation with a new code base (or Day 0) configuration, then installing new software, security, and other features.
At Step 1, the target device is reset back to its default factory setting using the Start RPC defined in the factory reset service. This used to be done manually through a CLI, adding time, complexity, and the risk of error. Administrators might also have had to deal with different CLI commands from different devices and vendors, further complicating things. After Step 1, the device boots up with software image V1.
Step 2 is generally referred to as the “bootstrapping” step. The outcome of Step 2 is to supply the device with security certificates needed for secure management. When this is completed, the device will still be running image V1 but will now be in a state where it can be securely configured and managed using other gNMI and gNOI services. Here is further information on bootstrapping in relation to gNOI.
In Step 3, the Install RPC feature defined is used to install the desired software image that becomes V2. Upon completion, the device is in a secure state running software image V2 and now is ready for installation of the desired configuration.
In Step 4, the device is in a state where the configuration can be modified using the gNMI service. Using one or more gNMI Set RPCs, the device configuration can be modified to bring it to the desired Day 1 configuration that will allow the device to perform its required functions (e.g., BGP, OSPF, AAA) using OpenConfig and/or IOS-XE native models, as discussed in a recent Cisco Networking blog.
Once the device is in operation, the device state will need to be modified or updated. Configuration updates can be performed with further gNMI Set RPCs. Modified device configurations considered the Day 2 configuration. Additionally, the security certificates on the device can be refreshed using the Rotate RPC in cert.proto (as shown in step 5).
If a device needs to be repurposed or decommissioned, the entire workflow can be repeated, beginning with resetting the device to its factory default settings.
Simplicity and Automation over Complexity and Manual Work
Standardization can be a very good thing and adding support for gNOI in Cisco IOS XE for Cisco enterprise devices is a perfect example. With this programmatic, automated functionality, manual processes are obsolete. The gRPC, gNOI, and gNOI features that work across vendors was Google’s attempt to avoid having to customize vendor device support. It’s a network-driven approach that Cisco wholeheartedly supports and lets us spend more time innovating in other ways.
Don’t miss other current blogs from the Cisco IOS XE developer team:
Cisco IOS XE – Past, Present, and Future
How IOS XE Developers at Cisco Work Remotely and Cohesively on a 190-million-line Code Base
Native or Open-source Data Models? Use both for Software-defined Enterprise Networks
Check out our Cisco Networking video channel
Subscribe to the Networking blog
CONNECT WITH US