SR Linux management overview

Configuration and state for the modular SR Linux applications are 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 the requirements of each application. The management server translates these models into protobufs for the IDB. This 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 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 System Management Guide for information about 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 System Management Guide for more information.

The gRPC-based gNMI protocol is used 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 ‟gNMI interface” chapter in the SR Linux System Management Guide for information 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 become active at the next reboot.

See the ‟Zero Touch Provisioning” chapter of the SR Linux Software Installation Guide for information about 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:

• Candidate – is used to modify a configuration. Modifications are not applied to the running system until a commit command is issued. When committed, the changes are copied to the running configuration and become active.

• Running – is used to display the currently running or active configuration. Configurations cannot be edited in this mode.

When a configuration is committed, it is first validated for YANG syntax, then tested by each application, 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:

• Shared – is the default configuration candidate for CLI sessions. Multiple users can modify the shared candidate concurrently. When the configuration is committed, the changes from all of the users are applied.

• Private – is the default configuration candidate when using JSON-RPC or gNMI clients, and can optionally be used in the CLI. With a private candidate, each user modifies their own separate instance of the configuration candidate. When a user commits their changes, only the changes from that user are committed.

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.

You can optionally create a rescue configuration, which is loaded if the startup configuration fails to load. If the startup configuration fails to load, and no rescue configuration exists, the system is started using the factory default configuration.

When you upgrade the SR Linux software image, the configuration in the startup config.json file is read into the running configuration and automatically upgraded to ensure compatibility with the new software version.

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. The SR Linux performs authentication, authorization, and accounting (AAA) functions for each user type.

Authentication can be performed for users configured within the underlying Linux OS, and for administrative users configured within the SR Linux.

Authorization is performed through role-based access control. Users can be configured with a set of one or more roles that indicate the privileges for which they are authorized in the system. You can configure the SR Linux to use information from a TACACS+ server to assign roles to an authenticated user.

The SR Linux supports command accounting, including the entire CLI string that a user enters on the command line, including any pipes or output redirects specified in the command. The accounting records can be sent to a destination such as a TACACS+ server group or the local system.

See the ‟Securing access” chapter of 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 ‟Logging” chapter of 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.