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.

The gRPC Network Operations Interface (gNOI) defines a set of gRPC-based services for executing operational commands on network devices. The individual RPCs and messages that perform the operations required for certificate management on the node are defined at the following location: https://github.com/openconfig/gnoi.

The gNOI file service on SR Linux allows a client to transfer files to and from a target node. This service can be used to extract debugging information through the transfer of system logs and core files.

See the ‟gNOI” chapter of the SR Linux System Management Guide for more information.

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.

Programming Protocol-Independent Packet Processors (P4) is an open-source language for programming the data plane on networking devices. P4Runtime is an API for controlling the data plane on devices defined in a P4 program. The P4 language and P4Runtime specification are maintained at p4.org.

The SR Linux eXtensible Data Path (XDP) is not programmed in P4, and no programming of the data path is done using P4. However, SR Linux supports using P4 programs and P4Runtime for some use cases that involve packet input/output. These include the following:

• Packet injection/reception, where a P4Runtime client injects packets on one side of a link and receives them on the other. The P4Runtime client then builds a topology based on embedded data within the payload of each packet.

• Redirecting traceroute packets with TTL=0, TTL=1, and TTL=2 to a P4Runtime client, so they can be enriched with information that is not visible to the device.

See the SR Linux P4Runtime Guide for configuration information.

Event Handler is a framework that enables SR Linux to react to specific system events, using programmable logic for the actions to take in response to the events.

The Event Handler framework allows you to write a custom script and have the script be invoked when specific events occur, such as when a port goes operationally down. The script can generate a list of actions to be executed on the SR Linux device. The actions can include updating the SR Linux configuration, changing the operational state of a group of ports, executing a tools command, or running another script.

A primary use for Event Handler is the ability to change the operational state of one group of ports based on the state of another group of ports. This type of usage is known as operational groups. See the SR Linux Event Handler Guide for more information.

The gRIBI (gRPC Routing Information Base Interface) is a gRPC-based protocol that allows external clients to inject routes into the RIB of a network device. The gRIBI clients add and remove RIB entries using an API that is defined by the gribi.proto. RIB entries are defined using the OpenConfig Abstract Forwarding Table (AFT) model, translated to protobuf.

The protobuf definition of gRIBI is maintained in the gRIBI GitHub repository: gribi.proto. The corresponding gribi_aft.proto containing the OpenConfig AFT model is available in the same repository.

See the SR Linux gRIBI Guide for more information, including a list of supported RPCs and AFTs.