SR Linux architecture overview
The sections that follow describe components of the SR Linux architecture and how they work together.
SR Linux components
At a high level, SR Linux can be divided into three components: a mainline Linux kernel, an operating system, and a suite of modular, lightweight applications, each supporting a different protocol or function (IS-IS, BGP, AAA, and so on). These applications use gRPC and APIs to communicate with each other and external systems over TCP.
Linux kernel
The kernel is the core of a computer operating system, with complete control over everything in the system. The kernel is loaded and executed by the boot loader, then handles the system startup as well as input/output requests from software, translating them into data-processing instructions for the CPU. The kernel handles memory and peripherals, as well as interactions with the switch ASIC.
SR Linux uses a mainline Linux kernel with no modifications or customization. This allows kernel upgrades to be performed using normal upgrade mechanisms (yum on CentOS/RHEL-based systems, and aptitude on Debian-based systems).
Operating system
SR Linux uses a mainline Linux kernel without any modifications or customization. This ensures a seamless upgrade process for SR Linux users.
See the ‟Appendix: Migrating from CentOS to Debian OS” chapter of the SR Linux Software Installation Guide for information about the high-level changes in regard to migration from CentOS to Debian OS.
To follow the Linux Filesystem Hierarchy Standard (FHS), SR Linux software is distributed and laid out as a closed-source, third-party application on the OS. The FHS clearly defines where configuration and binaries should be kept; for SR Linux, all application configuration is kept in the /opt/srlinux directory.
Modular applications
SR Linux is a suite of applications running like any others would in a Linux environment. The applications communicate with the IDB to process configuration and state. SR Linux applications and IDB shows the relationship between the IDB and the applications that run in SR Linux.
Messaging between applications is controlled by IDB, and configuration via supported APIs is controlled by the management server application.
SR Linux applications describes the key SR Linux applications. Use the show system application CLI command to display information about all applications running on the system.
Application name |
Description |
|---|---|
IDB |
Controls messaging between SR Linux applications. |
mgmt_server |
Controls interaction between external APIs and the IDB, handles application-specific YANG models, and translates them into protobufs for IDB. See SR Linux management server. |
aaa_mgr |
Performs AAA for end users connecting to the system. |
fib_mgr |
Responsible for route resolution and route selection. |
lldp_mgr |
Responsible for sending and receiving LLDP packets via XDP. |
static_route_mgr |
Creates/updates/deletes static routes. |
arp_nd_mgr |
Responsible for ARP resolution for IPv4 and Neighbor Discovery for IPv6. |
bgp_mgr |
Runs the BGP control plane. |
chassis_mgr |
Monitors interface/subinterface state and synchronizes interfaces between Linux and the ASIC. |
xdp_mgr |
Handles data path programming. The xdp_mgr runs on each line card and is split into two components: platform independent and platform dependent. The platform-independent component handles communication between IDB and the ASIC, and the platform-dependent component is an extensible framework for plugging in data plane programming software. |
linux_mgr |
Creates routes and neighbors in Linux. As control packets enter the Linux host (and kernel), the Linux network stack responds to them. Synchronizing routes and neighbors to Linux stops Linux from ARPing/routing via the default gateway when routes exist at the data plane but not within Linux. |
plcy_mgr |
Enforces routing policies. |
app_mgr |
Monitors the health of the processes running SR Linux applications, and restarts them if they fail. |
net_inst_mgr |
Synchronizes VRFs between the switch ASIC and Linux. |
log_mgr |
Controls the log infrastructure, implemented by rsyslog. |
acl_mgr |
Controls ACLs in the system, both on the Linux host and on the CPM. |
bfd_mgr |
Controls BFD sessions on the system. |
IDB stores data as protobufs. Protobufs use a .proto file to define how data is structured. Protobufs are not human-readable, but an IDB client is provided with the IDB server, which allows you to read from different topics, decoding the protobuf in real time.
Application manager
The application manager is responsible for monitoring the health of the processes running each SR Linux application, and restarting them if they fail.
Each application has specific YAML configuration. The application manager reads in the application-specific YAML configuration and starts each application. It allows applications to not start if no configuration exists for them.
The application manager functions as a replacement for the Linux systemd. At boot time, systemd starts the application manager, which in turn starts SR Linux applications that it manages (based on YAML configuration). The device_mgr is the first application started, then IDB, then other applications are started based on the YAML configuration. The application manager loads the YANG model for each application into the management server.
The application manager is also responsible for restarting the entire system if a critical application cannot be restarted successfully; this restart mechanism is controlled through configuration.