The chapter describes concepts behind managing the SR Linux configuration, including configuration datastores, modes, and how to commit changes to the running configuration.
SR Linux uses a JSON configuration file, located at /etc/opt/srlinux/config.json, which is loaded when the system starts. If this file does not exist, a factory default configuration is loaded, which brings device into management, enables DHCP/v6 on the management interface, adds it to the management network-instance, enables an SSH server, and creates various system logs and applies a default set of CPM filters.
Configuration and state information reside in datastores on the SR Linux device. The following datastores are available:
Within the CLI, you can use the info command to display information from a datastore. For example, entering the info from state command (or entering the info command in state mode) displays configuration and statistics from the state datastore for the current context, and entering the info from running command (or the info command in running mode) displays configuration from the running datastore for the current context.
The candidate datastore corresponds to a configuration mode within the SR Linux CLI. In candidate mode, you can modify SR Linux configuration settings.
By default, candidate mode operates in shared mode, which allows multiple users to modify the candidate configuration concurrently. When the configuration is committed in shared mode, all of the users’ changes are applied.
You can optionally use candidate mode in exclusive mode, which locks out all other users from making changes to the candidate configuration.
When a user enters candidate mode, the system creates two copies of the running datastore: one is modifiable by the user, and the other serves as a baseline. The modifiable datastore and the baseline datastore are collectively known as a configuration candidate.
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.
After logging in to the CLI, you are initially placed in running mode. Table 5 describes the commands to change between modes.
To enter this mode: | Type this command: |
Candidate shared | enter candidate |
Candidate mode for named shared candidate | enter candidate name <name> |
Candidate private | enter candidate private |
Candidate mode for named private candidate | enter candidate private name <name> |
Candidate exclusive | enter candidate exclusive |
Exclusive mode for named candidate | enter candidate exclusive name <name> |
Running | enter running |
State | enter state |
Show | enter show |
For example, to change from running to candidate mode:
The asterisk (*) next to the mode name indicates that the candidate configuration has changes that have not yet been committed.
To switch between candidate shared and candidate exclusive modes, you must first switch to a different configuration mode (for example, running mode) before entering candidate shared or exclusive mode. For example:
To enter candidate mode for a named configuration candidate, you specify the name of the configuration candidate. For example:
Changes made during a configuration modification session do not take effect until a commit command is issued. Use the commit command in candidate mode only.
Example:
You can optionally configure the SR Linux to require explicit confirmation via a tools command for the configuration changes from a commit operation to become permanent. If the new configuration is not confirmed after a timeout period, the running datastore reverts to the previous version.
Example:
After entering configuration commands in candidate mode, use the following command to commit the configuration and start the confirmation timer:
The commit confirmed command applies the changes to the running datastore and activates them. If the configuration is committed successfully, the confirmation timer is started (default 10 minutes). If you do not confirm the commit operation before the timer expires, the configuration reverts to the previous version.
To confirm the commit operation and make the configuration changes permanent, enter the following command before the confirmation timer expires:
To revert to the previous configuration without waiting for the confirmation timer to expire, enter the following command:
You can optionally validate the configuration changes made during a commit operation before they are applied to the running datastore. The SR Linux management server checks the syntax of the changes in the candidate configuration and displays messages if validation errors are found.
Example:
Use the following command to perform a validation check for configuration changes. Note that this command only validates the changes; it does not apply them to the running datastore.
If syntax errors are found in the configuration changes, SR Linux displays error messages; if validation is successful, no output is displayed.
A configuration candidate consists of a modifiable candidate datastore and a baseline datastore, both of which are snapshots of the then-current running datastore when a user enters candidate mode.
During the lifetime of the configuration candidate, the running datastore can be modified via commits initiated from other configuration sessions. At that point, the baseline in the configuration candidate is out-of-date.
Updating the baseline datastore takes a new snapshot of the running configuration, applies the changes in the candidate datastore, and checks for configuration conflicts in the updated baseline datastore. If conflicts are found, the user is informed with a warning or error for each conflict.
A baseline datastore update is done automatically when the user commits the changes to the configuration, or can be done manually with the baseline update command.
Example:
In the following example, the baseline datastore in a configuration candidate is out of date, as indicated by the ! in the prompt. This indicates that another user has committed changes to the running datastore.
Entering the baseline update command copies the current running datastore to the baseline datastore, applies the changes in the candidate datastore, then displays any conflicts in the updated baseline datastore. If there are no conflicts, no output is returned by the command.
Use the delete command to delete configurations while in candidate mode.
Example:
The following example displays the system banner configuration, deletes the configured banner, then displays the resulting system banner configuration:
To aid in reading a configuration, you can add comments or descriptive annotations. The annotations are indicated by !!! in displayed output.
You can enter a comment either directly from the command line or by navigating to a CLI context and entering the comment in annotate mode.
Examples:
The following example adds a comment to an ACL configuration. If there is already a comment in the configuration, the new comment is appended to the existing comment.
To replace the existing comment, use !!! instead of !! in the command.
The following example adds the same comment to the ACL by navigating to the context for the ACL and entering the comment in annotate mode:
You can enter multiple lines in annotate mode. To exit annotate mode, press Esc, then the Enter key.
In CLI output, the comment is displayed in the context it was entered. For example:
To remove a comment, enter annotate mode for the context and press Esc then Enter without entering any text.
You can discard previously applied configurations with the discard command. Use the discard command in candidate mode only.
Example:
The info command displays configuration and state information. Entering the info command from the root context displays the entire configuration, or the configuration for a specified context. Entering the command from within a context limits the display to the configuration under that context. Use this command in candidate or running mode.
Examples:
To display the entire configuration, enter info from the root context:
To display the configuration for a specific context, enter info and specify the context:
From a context, use the info command to display the configuration under that context:
Use the as json option to display JSON-formatted output:
Use the detail option to display values for all parameters, including those not specifically configured:
Use the flat option to display the output as a series of set statements, omitting indentation for any sub-contexts:
Use the depth option to display parameters with a specified number of sub-context levels:
To display information from the state datastore, enter the info from state command in candidate or running mode, or the info command in state mode.
Examples:
To display state information for a specified context from candidate or running mode:
To display state information for a specified context from state mode:
You can change to a different mode (for example, from state mode to candidate mode), and remain in the previous context. For example:
Save the existing configuration to a file using the save command. Use this command in candidate or running mode.
Examples:
To save the running configuration to a file:
To save the running configuration in JSON format:
To save the running configuration to the initial (startup) configuration:
Use the load command to load a configuration. The configuration can be from a checkpoint (see Managing configuration checkpoints), a JSON-formatted configuration file, the startup configuration, the factory default configuration, or from manually entered or pasted JSON-formatted input.
Examples:
To load a configuration from a checkpoint:
To load a configuration from a file:
To load a configuration from manually entered JSON-formatted input:
You can enter or paste multiple lines at the << prompt in JSON-input mode. To exit JSON-input mode, press Esc, then the Enter key.
You can execute configuration statements from a source file consisting of set statements such as those generated by the info flat command (see Displaying configuration details). The SR Linux reads the file and executes each configuration statement line-by-line. You can optionally commit the configuration automatically after the file is read.
Example:
The following example executes a configuration from a specified file:
Use the auto-commit option to commit the configuration after the commands in the source file are executed.
You can periodically save the running configuration as a JSON-formatted checkpoint file. You can load a saved checkpoint into the candidate configuration, and revert the running configuration to a previously saved checkpoint.
The checkpoint files are saved in the /etc/opt/srlinux/checkpoint directory, and are named checkpoint-<number>.json (for example, checkpoint-0.json), with the lowest number being the most recently saved checkpoint. You can configure the maximum number of checkpoint files that are kept by the system.
Examples:
The following example generates a checkpoint from the current running configuration:
The following example loads a checkpoint into the candidate configuration:
The following example reverts the running configuration to a previously saved checkpoint:
The following example configures the system to keep a maximum of 10 checkpoint files.
In this example, if 10 checkpoint files are being kept, adding a subsequent checkpoint file causes the oldest checkpoint file to be deleted and the index for the remaining checkpoint files to be incremented by 1.