This chapter describes the system management functions of SR Linux, including the role of the SR Linux management server and external management APIs (CLI, gNMI, and JSON-RPC). It describes SR Linux configuration modes, methods for securing access to the device, and logging functions.
Configuration and state for the modular SR Linux applications is driven by centralized data models (YANG) that are managed by the SR Linux management server application.
The SR Linux management server provides a central point for external clients and APIs to access the system. The supported external APIs (CLI, JSON-RPC, and gNMI) communicate with the management server via its gRPC interface.
The management server manages the YANG models, which are loaded into the management server by the application manager, based on each application’s requirements. The management server translates these models into protobufs for the IDB. These allows other applications to read their own configuration, by subscribing to the management server topic representing the configuration.
The management server owns the configuration of each application, so each application does not have write access to its own configuration.This provides a central point of configuration enforcement.
Agents built with the Nokia NetOps Development Kit (NDK) function similar to other applications provided with SR Linux. SR Linux applications share state details with each other using a publish/subscribe (pub/sub) architecture. Agents have their own table space within the IDB and can subscribe and receive a notification to events occurring on the device, or create their own table space and publish data to it. This data can be read by other applications within SR Linux, allowing route modifications by publishing routes to the IDB for selection by the FIB manager.
The SR Linux CLI is an interactive interface for configuring, monitoring, and maintaining the SR Linux via an SSH or console session. The SR Linux CLI operates as a client that communicates with the management server via gRPC. The command tree in the CLI is derived from the SR Linux YANG models.
The SR Linux CLI supports command autocompletion, aliases, annotation, and standard Linux output modifiers such as grep. Command output can be displayed in JSON format.
See the “CLI interface” chapter of the SR Linux Interface Configuration Guide for information on CLI features.
A JSON-RPC server can be enabled on the SR Linux device, which allows JSON-formatted requests to be issued to the device to retrieve and set configuration and state. You can use the JSON-RPC API to run CLI commands and standard get and set methods. The SR Linux device returns responses in JSON-format.
When the JSON-RPC server is enabled, the application passes the requests to the SR Linux management server via the gRPC interface.This JSON-RPC API uses HTTP and HTTPS for transport, and users are authenticated with the aaa_mgr application. HTTPS requests can be authenticated using TLS.
See the “JSON interface” chapter of the SR Linux Interface Configuration Guide for more information.
gNMI is a gRPC-based protocol for the modification and retrieval of configuration from a target device, as well as the control and generation of telemetry streams from a target device to a data collection system.
SR Linux can enable a gNMI server that allows external gNMI clients to connect to the device and modify the configuration and collect state information.
When the gNMI server is enabled, the SR Linux gnmi_mgr application functions as a target for gNMI clients. The gnmi_mgr application validates gNMI clients and passes Get, Set, and Subscribe RPCs to the SR Linux mgmt_svr application via the gRPC interface.
See the SR Linux Interface Configuration Guide for details about the supported RPCs.
Zero Touch Provisioning (ZTP) automates the process of booting the SR Linux device, obtaining an address on the network, then downloading and executing a Python script to configure the system.
The system ships with a operating system image and a boot file (grub.conf) installed on the SR Linux compact flash. When the system boots, if autoboot = enabled is set in the grub.conf file, it initiates the ZTP process. The system then obtains an IP address via DHCPv4 or v6, downloads a Python script to configure the device, and executes the script.
The script can contain URLs to an updated image and a new kernel. The ZTP process can download these and place them on the compact flash, where they will become active at the next reboot.
See the SR Linux Software Installation Guide for information on using ZTP to initialize the SR Linux.
SR Linux uses transaction-based configuration, which allows the operator to make changes to the configuration, and then explicitly commit the configuration to apply it.
By default, the SR Linux configuration file is located in /etc/opt/srlinux/config.json. At boot time, the management server loads the configuration and publishes content to IDB for applications to consume.
Configuration modes define how the system is running when transactions are performed. Supported modes are the following:
When a configuration is committed, it is first validated for YANG syntax, then tested by each application, and then validated by the forwarding plane. If validation fails at any stage, the configuration is not committed.
A configuration candidate can be either shared or private:
By default, there is a single unnamed global configuration candidate. You can optionally configure one or more named configuration candidates, which function identically to the global configuration candidate. Both shared and private configuration candidates support named versions.
See the “Configuration management” chapter in the SR Linux Configuration Basics Guide for more information.
The SR Linux is able to secure access to the device for users connecting via SSH or the console port, as well as for applications and FTP access. Authentication can be performed for users configured within the underlying Linux OS, and for administrative users configured within the SR Linux itself.
The SR Linux performs authentication, authorization, and accounting (AAA) functions for each user type. See the SR Linux Configuration Basics Guide for more information.
SR Linux implements logging via the standard Linux syslog libraries. The SR Linux device uses rsyslog in the underlying Linux OS to filter logs and pass them on to remote servers or other specified destinations.
The SR Linux supports configuration of Linux facilities and SR Linux subsystems as sources for log messages to filter. See the SR Linux Configuration Basics Guide for information about configuring input sources, filters, and output destinations for log messages.
See the SR Linux Log Events Guide for properties and descriptions of the log messages that can be generated by SR Linux subsystems.