System administrators in organizations that are constantly upgrading, reassigning, and managing thousands of switches, listen! Starting with Cisco IOS XE Release 17.7, support for a suite of microservices based on Google Remote Procedure Call (gRPC) that will simplify and lighten your workloads.
The evolution of remote procedure calls
In 2015, the RPC protocol underwent a major update with gRPC. This open source framework is accessible to a wide variety of programming languages. It was developed to connect services within and between data centers to achieve pluggable support for features such as load balancing, health checks, authentication and for connecting devices. distributed, from mobile applications and browsers to core services.
gRPC provides the infrastructure to create a device management service to exchange configuration and operational data between a client and a server. gRPC Network operating 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 microserviceswhich have been defined cover a wide range of operational tasks. gNOI works in conjunction with another unified management protocolto model the data for network configuration and for telemetry: GRPC network management interface (gNMI).
The gNMI and gNOI workflow
Cisco IOS XE support gNOI will allow administrators tomanage by program Cisco Enterprise devices. An example of typical administrative management workflowwhich can be automated using gNOIis show in Figure 1. This starts with identifying a device for reuse, then resetting the device to its factory settings and putting it back into service with a new onecoded base (or Day 0) configuration,then install a newsoftware, security and other features.
In step 1, the target device is reset to its factory default settings using the boot RPC set in the Factory Reset service. Previously, this was done manually via a CLI, which added time, complexity and risk of error. Admins may also have had to manage different CLI commands from different devices and vendors, further complicating matters. After step 1, the device starts up with software image V1.
Step 2 is generally referred to as the “priming” step. The result of step 2 is to provide the device with the security certificates necessary for secure management. Once this is done, the device will still run the V1 image, but will now be in a state where it can be safely configured and managed using other gNMI and gNOI services. Here is more information about primingcompared to gNOI.
In step 3, the Install RPC function set is used to install the desired software image which becomes V2. Upon completion, the device is in a secure state running the V2 software image and is now ready to install the desired configuration.
In step 4, the device is in a state where the configuration can be changed using the gNMI service. Using one or more gNMI Set RPCs, the device configuration can be changed to bring it to the desired configuration on day 1 which 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 operational, the device status will need to be changed or updated. Configuration updates can be performed with other gNMI Set RPCs. Modified device configurations have been considered the day 2 configuration. Additionally, security certificates on the device can be updated using Rotate RPC in cert.proto (as shown in step 5) .
If a device needs to be reused or taken out of service, the entire workflow can be repeated, starting with resetting the device to its factory default settings.
Simplicity and automation versus complexity and manual labor
Standardization can be a very good thing and the addition of gNOI support in Cisco IOS XE for Cisco enterprise devices is a perfect example. With this automated and programmatic functionality, manual processes are obsolete. The gRPC, gNOI, and gNOI features that work with all vendors were Google’s attempt to avoid having to customize vendor device support. It’s a network-centric approach that Cisco wholeheartedly supports that allows us to spend more time innovating in other ways.
Don’t miss other current blogs from the Cisco IOS XE developer team:
Accelerate and Simplify – Guiding Principles in Designing New Software Image and Patch Upgrade Solutions
Cisco IOS XE – Past, Present and Future
How Cisco IOS XE Developers Work Remotely and Consistently on a 190 Million Line Code Base
Native or open source data models? Use both for software-defined corporate networks
Discover our Cisco Networking video channel
Subscribe to the Networking blog