4. SR Linux architecture overview
This chapter describes components of the SR Linux architecture and how they work together.
4.1. 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.
4.1.1. Linux kernel
The kernel is the core of a computer’s operating system, with complete control over everything in the system. The kernel is loaded and executed by the boot loader, and 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).
4.1.2. Operating system
SR Linux is designed to be OS-agnostic, with support for all enterprise-class Linux operating systems, with current deployments focused on CentOS.
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.
4.1.3. Modular applications
SR Linux is a suite of applications running like any others would in a Linux environment. The applications communicate with the impart database (IDB) to process configuration and state. Figure 5 shows the relationship between the IDB and the applications that comprise SR Linux.
Figure 5: SR Linux applications and IDB
Messaging between applications is controlled by IDB, and configuration via supported APIs is controlled by the management server application. Table 5 lists the SR Linux applications.
Table 5: SR Linux applications
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, translating them into protobufs for IDB. |
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 syncs 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 actually enter the Linux host (and kernel), the Linux network stack responds to them. Syncing 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 | Syncs 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 protocol buffers (protobufs). Protobufs are a language-neutral, platform-neutral mechanism for serializing structured data. Each protocol buffer message is a small logical record of information, containing a series of name-value pairs. 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.
4.1.4. Management server application
The management server application controls interaction between external APIs and the IDB. The external APIs (CLI, gNMI, and JSON-RPC) communicate with the management server using gRPC.
The management server is responsible for owning YANG models. These models 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. This allows other applications to read their own configuration by subscribing to the management server topic representing the configuration.
4.1.5. 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, and 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 manger is also responsible for restarting the entire system in the event a critical application cannot be restarted successfully, this restart mechanism is controlled through configuration.