CLI interface

The CLI is an interface for configuring, monitoring, and maintaining the SR Linux. This chapter describes basic features of the CLI and how to use them.

CLI access and use

The following sections describe how to access and use the CLI.

Accessing the CLI

After the SR Linux device is initialized, you can access the CLI using a console or SSH connection. See the SR Linux hardware documentation for information about establishing a console connection and enabling and connecting to an SSH server.

Use the following command to connect to the SR Linux and open the CLI using SSH:

ssh admin@<IP Address>

$ ssh admin@172.16.0.3
Hello admin,
Welcome to the srlinux CLI.
Type 'help' (and press <ENTER>) if you need any help using this.
--{ running }--[ ]--

Using the CLI help functions

The CLI help functions (? and help) can assist in understanding command usage and indicate which configuration mode you are in.

Enter a question mark (?) after a command to display the command usage.

Enter help at the top level to show the current configuration mode and details on other configuration modes.

?

In this example, entering a question mark after the command network-instance, shows its usage.

# network-instance ?
usage: network-instance <name>
Network instances configured on the local system
Positional arguments:
  name              [string] A unique name identifying the network instance

help

The following example shows the system output from the help command

# help
--------------------------------------------------------------------------------
You are now in the running mode.
Here you can navigate and query the running configuration.
This configuration has been validated, committed and send to the applications.
There are multiple modes you can enter while using the CLI.
Each mode offers its own set of capabilities:
    - running mode: Allows traversing and inspecting of the running configuration.
    - state mode: Allows traversing and inspecting of the state.
    - candidate mode: Allows editing and inspecting of the configuration.
    - show mode: Allows traversing and executing of custom show routines.
To switch mode use 'enter <mode-name>', e.g. 'enter candidate'
To navigate around, you can simply type the node name to enter a context, while
'exit [all]' is used to navigate up.
'{' and '}' are an alternative way to enter and leave contexts.
'?' can be used to see all possible commands, or alternatively,
'<TAB>' can be used to trigger auto-completion.
'tree' displays the tree of possible nodes you can enter.
--------------------------------------------------------------------------------
--{ * running }--[  ]--

Using the CLI auto-complete function

To reduce keystrokes or aid in remembering a command name, use the CLI auto-complete function.

Enter a tab at any mode or level to auto-complete the next command level.

When a command is partially entered, the remainder of the command appears ahead of the prompt in lighter text. Press the Tab key to complete the command.

When the Tab key is pressed and there are multiple options, the options are shown in a popup:

Wildcards and ranges

Rather than define a single value for a parameter, the SR Linux CLI allows you to enter a wildcard or a range to substitute for one or more values, such as a list of interfaces. The CLI engine automatically expands the specified wildcard or range into a list of individual values and executes the command for each value in that list.

Wildcards

In the SR Linux CLI, you can enter an asterisk (*) to serve as a wildcard character in commands. You can use wildcards to represent any predefined values for a parameter. Note the following considerations when you use wildcards:

  • Wildcards are valid in both info and configuration commands.
  • Multiple wildcards are allowed in one command.
  • Wildcards apply only to existing pre-configured objects (for non-configured objects, use ranges).
  • Wildcards expand to YANG list keys, which must be valid in the context in which the wildcard is entered.
  • Wildcards and ranges can be entered in the same command.

The following sections provide some examples of wildcards.

Wildcards in info commands

The following example uses a wildcard character as a substitute for the subinterface value in the info interface command to display all subinterfaces of ethernet-1/1:

Display all subinterfaces using a wildcard
--{ * candidate shared default }--[  ]--
# info interface ethernet-1/1 subinterface *
    interface ethernet-1/1 {
        subinterface 0 {
            admin-state enable
        }
        subinterface 1 {
            admin-state enable
        }
        subinterface 2 {
            admin-state enable
        }
    }

You can also enter multiple wildcards to substitute for multiple parameters. The following example checks the active status for all IPv4 unicast BGP routes in the default network instance:

Display state for all IPv4 unicast BGP routes using wildcards
--{ * candidate shared default }--[  ]--
# info from state network-instance default route-table ipv4-unicast route * id * route-type bgp route-owner * origin-network-instance * active
    network-instance default {
        route-table {
            ipv4-unicast {
                route 10.0.0.2/32 id 0 route-type bgp route-owner bgp_mgr origin-network-instance default {
                    active true
                }
                route 10.0.0.3/32 id 0 route-type bgp route-owner bgp_mgr origin-network-instance default {
                    active true
                }
                route 10.0.0.4/32 id 0 route-type bgp route-owner bgp_mgr origin-network-instance default {
                    active true
                }
            }
        }
    }
Wildcards in configuration commands

You can also use wildcards in configuration commands. The following example adds subinterface 0 to every configured interface in the system:

Add subinterface 0 to all configured interfaces
--{ + candidate shared default }--[  ]--
# /interface * subinterface 0 description "created with a wildcard"
Wildcards in interface commands

Wildcards can expand YANG list keys, with the exception of interface names. However, within the interface name, you can use wildcards for either the linecard or port elements.

The following example uses a wildcard for the port value to display the admin-state for all interfaces on linecard 1:

Display admin-state for all interfaces on linecard 1
--{ + candidate shared default }--[  ]--
# info interface ethernet-1/* admin-state
    interface ethernet-1/1 {
        admin-state enable
    }
    interface ethernet-1/3 {
        admin-state enable
    }
    interface ethernet-1/8 {
        admin-state enable
    }

Similarly, you can include a wildcard to specify one port on all linecards (for example: interface ethernet‑*/2).

Wildcards in expanded contexts

Wildcards support the ability to enter an expanded context. Context-based configuration workflows with wildcards can eliminate copying and pasting by applying the configuration commands to all existing objects.

For example, to analyze the state of the configured interfaces, you can enter the context of all interfaces at once, as shown in the following example:

Enter state mode for all interfaces
--{ + running }--[  ]--
# enter state
--{ + state }--[  ]--
# interface *
--{ + state }--[ interface * ]--

From the wildcarded context, you have access to a range of commands that are executed across all applicable interfaces. The following example lists the number of incoming unicast packets on all interfaces:

List the number of incoming unicast packets on all interfaces
--{ + state }--[ interface * ]--
# info statistics in-unicast-packets
    interface ethernet-1/1 {
        statistics {
            in-unicast-packets 0
        }
    }
    interface ethernet-1/3 {
        statistics {
            in-unicast-packets 0
        }
    }
    ...
    interface mgmt0 {
        statistics {
            in-unicast-packets 919
        }
    }

You can also use wildcards in the context mode for configuration tasks. The following example adds VLAN tagging for subinterface 0 on all applicable interfaces:

Add VLAN tagging for subinterface 0 on all interfaces
# switching to candidate datastore
--{ + state }--[ interface * ]--
A:srl# enter candidate

# entering the wildcarded context
# of subinterface 0 of all interfaces
--{ + candidate shared default }--[  ]--
A:srl# interface * subinterface 0

# adding vlan tagging on all of them
--{ + candidate shared default }--[ interface * subinterface 0 ]--
A:srl# vlan encap single-tagged vlan-id any

As a result, the VLAN tagging configuration is applied to all subinterfaces:

Confirm the VLAN tagging is applied (diff) 
--{ +* candidate shared default }--[ interface * subinterface 0 ]--
# diff
      interface ethernet-1/1 {
          subinterface 0 {
              vlan {
                  encap {
+                     single-tagged {
+                         vlan-id any
+                     }
                  }
              }
          }
      }
      interface ethernet-1/3 {
          subinterface 0 {
              vlan {
                  encap {
+                     single-tagged {
+                         vlan-id any
+                     }
                  }
              }
          }
      }
...
Wildcards and strings

Wildcards can also be used with string-based keys. You can add a wildcard character anywhere in the string key to match any number of characters in that position. For example, on a system that has several VRFs with names beginning with red, you can match multiple VRFs as in the following example:

Match multiple VRFs
--{ +* candidate shared default }--[  ]--
A:srl# info network-instance red*
    network-instance red {
        admin-state enable
    }
    network-instance red-a {
        admin-state enable
    }
    network-instance red-b {
        admin-state enable
    }
    network-instance red1 {
        admin-state enable
    }

In this case, red* expands to the red, red-a, red-b, and red1 keys.

Wildcard expansion with string keys also provides a means to filter out objects that match a particular pattern, such as a customer name or location code.

Wildcard applicability and scope

It is important to note that wildcards expand to existing objects only. For example, if your candidate or running datastore has only two interfaces ethernet-1/1 and ethernet-1/5, then the wildcard ethernet-1/* only matches these existing interfaces.

Also, to expand a list key, the list key must pertain to the context in which the wildcard is employed.

Consider the case where three interfaces are configured and you want to enable LLDP. First, you can ensure that the interfaces exist:

List interface state
--{ + candidate shared default }--[  ]--
# info from running interface ethernet-1/* admin-state
    interface ethernet-1/1 {
        admin-state enable
    }
    interface ethernet-1/3 {
        admin-state enable
    }
    interface ethernet-1/8 {
        admin-state enable
    }

But if you try to enable LLDP on all interfaces using a wildcard, the operation fails:

Attempt to enable LLDP using a wildcard
--{ + candidate shared default }--[  ]--
# system lldp interface ethernet-1/* admin-state enable
Error: Path '.system.lldp.interface{.name==ethernet-1/*}' does not specify any existing objects

This error occurs because the /system/lldp/interface list does not contain these interfaces within its own context. These interfaces are instead contained in the /interface list context, which the /system/lldp/interface list references. As a result of this referencing structure, these interfaces are not eligible for wildcard expansion in the /system/lldp/interface context.

In this case, ranges can be useful as they can create objects that do not exist yet.

Ranges

CLI ranges allow you to define a series of values for a particular list key. Unlike wildcards, ranges can generate new objects within the system, allowing for bulk object creation.

To express a range, enter a list of values separated by commas. Each value can be a single scalar value. You can also specify a continuous range of values using the double-dot (..) delimiter, or mix both formats within the same range specification.

Note the following considerations when you use ranges:

  • Ranges are valid in both info and configuration commands.
  • Multiple ranges are allowed in one command.
  • Ranges apply to both existing and new objects.
  • In a configuration command, if a range includes an object that already exists, the command overwrites the existing object.
  • Wildcards and ranges can be entered in the same command.

The following table provides a few examples showing the syntax of different range patterns and how they translate to the list of elements:

Syntax Result
{1,3} 1, 3
{2..5} 2, 3, 4, 5
{1,3..5,8} 1, 3, 4, 5,8

The following example shows how to display the administrative state of interfaces 1, 3, and 5 using a comma-separated list of elements in just one command:

Display admin-state of interfaces 1,3, and 5
--{ + running }--[  ]--
# info interface ethernet-1/{1,3,5} admin-state
    interface ethernet-1/1 {
        admin-state enable
    }
    interface ethernet-1/3 {
        admin-state enable
    }
    interface ethernet-1/5 {
        admin-state enable
    }

To create a consecutive range of integer values, you can use double-dot (..) notation. The following example uses a range of ethernet-1/{2..4} to list all interfaces in the range between 2 and 4 (the range boundaries are included).

Display consecutive range of interfaces
--{ + running }--[  ]--
# info interface ethernet-1/{2..4} admin-state
    interface ethernet-1/2 {
        admin-state enable
    }
    interface ethernet-1/3 {
        admin-state enable
    }
    interface ethernet-1/4 {
        admin-state enable
    }

The following example mixes the two range patterns, providing greater flexibility:

Mix ranges and scalars
--{ + running }--[  ]--
# info interface ethernet-1/{1,3..5,8} admin-state
    interface ethernet-1/1 {
        admin-state enable
    }
    interface ethernet-1/2 {
        admin-state enable
    }
    interface ethernet-1/3 {
        admin-state enable
    }
    interface ethernet-1/4 {
        admin-state enable
    }
    interface ethernet-1/5 {
        admin-state enable
    }
    interface ethernet-1/8 {
        admin-state enable
    }
Objects and scoping

Ranges can generate new objects within the system, which is useful for bulk object creation. However, if the CLI range includes an object that already exists, the configuration command overwrites the existing object as well.

Conversely, in the case of an info command, if a range expands to a non-existing object, it is skipped.

To demonstrate this behavior, consider a freshly deployed system, where no ethernet-1/* interfaces are configured:

Confirm no interfaces configured
--{ + running }--[  ]--
# info interface ethernet-1/*
--{ + running }--[  ]--
#

To create a set of interfaces, wildcards are not helpful because they cannot expand to undefined objects. Instead, you can define a range:

Create new objects with ranges
--{ + running }--[  ]--
# enter candidate

--{ + candidate shared default }--[  ]--
# interface ethernet-1/{1..4} admin-state enable

By using ranges in candidate mode, four new interfaces are created on the system with a single command:

Display configuration changes (diff)
--{ +* candidate shared default }--[  ]--
# diff
+     interface ethernet-1/1 {
+         admin-state enable
+     }
+     interface ethernet-1/2 {
+         admin-state enable
+     }
+     interface ethernet-1/3 {
+         admin-state enable
+     }
+     interface ethernet-1/4 {
+         admin-state enable
+     }

Because ranges can create new list elements, you can also successfully enable LLDP on multiple interfaces (unlike the LLDP example that failed with wildcards).

Enable LLDP on multiple interfaces
--{ +* candidate shared default }--[  ]--
# system lldp interface ethernet-1/{1,2} admin-state enable
String key ranges

All the preceding range examples use integer keys, such as interface numbers or VLAN IDs. But ranges also support string-based keys, such as creating multiple named VRFs or ACLs.

Syntax Result
{red,blue} "red", "blue"
{red{1..2}} "red1", "red2"
{red-{a..c}} "red-a", "red-b", "red-c"

In its simplest form, string-based ranges operate on comma-separated list of strings. In the following example, two strings red and blue are included in the command to create two network instances.

Create network instances red and blue
--{ +* candidate shared default }--[  ]--
A:srl# network-instance {red,blue} admin-state enable

The defined range expands to two elements and as a result two VRFs are created:

Display configuration changes (diff)
--{ +* candidate shared default }--[  ]--
# diff
+     network-instance blue {
+         admin-state enable
+     }
+     network-instance red {
+         admin-state enable
+     }

Advanced templating syntax that involves nested ranges and a combination of both integer and string values is also supported:

Create multiple red and blue VRFs
--{ +* candidate shared default }--[  ]--
# network-instance {red{1..2},blue{1..2}} admin-state enable

In this case, the defined range expands to two red and two blue VRFs:

Display configuration changes (diff)
--{ +* candidate shared default }--[ network-instance {red{1..2},blue{1..2}} ]--
# diff
+     network-instance red1 {
+         admin-state enable
+     }
+     network-instance red2 {
+         admin-state enable
+     }
+     network-instance blue1 {
+         admin-state enable
+     }
+     network-instance blue2 {
+         admin-state enable
+     }

String-based ranges can create multiple named objects at once, and with nesting, you can construct even more intricate structures.

The info command can also take advantage of string-based ranges. The following example displays all ACLs that adhere to a specific naming pattern:

Display ACL filters cust1-* and cust2-*
--{ * candidate shared default }--[  ]--
# info acl acl-filter {cust1-*,cust2-*} type ipv4 description
    acl {
        acl-filter cust1-filter1 type ipv4 {
            description somefilter
        }
        acl-filter cust1-filter2 type ipv4 {
            description somefilter
        }
        acl-filter cust2-filter1 type ipv4 {
            description somefilter
        }
        acl-filter cust2-filter2 type ipv4 {
            description somefilter
        }
    }

String-based ranges can also be useful in large scale deployments where for example named objects can encode customer or facility information.

Using wildcards and ranges in show route-table

You can use ranges and wildcards in the show network-instance route-table command to display routes for a subset of prefixes or prefix lengths in one or more network instances.

For example, any of the following expressions can match route 192.168.0.1/32:

Table 1. Wildcard and range expressions to match 192.168.0.1/32
Expression Description
*​ Full wildcard
*.168.0.1/32 Wildcard for first octet
*.168.0.1/* Wildcards for first octet and prefix length
1*.168.0.1/32 Partial wildcard in first octet
{190..192}.*​ Range for first octet and wildcard for final octets and prefix length

The following example displays routes for 172.18.0.x prefixes that have a prefix length of /24 (172.18.0.*/24) and for any prefixes that have a prefix length of /32 (*32) in either the management (m*) or default (def*) network instances.

Filtering route table output 
--{ candidate shared default }--[  ]-- 
A:dut1# show network-instance {m*,def*} route-table ipv4-unicast prefix {172.18.0.*/24,*32}
------------------------------------------------------------------------------------------------------
IPv4 unicast route table of network instance mgmt
------------------------------------------------------------------------------------------------------
+-----------------+--+-----+--------+------+--------+------+----+-----------+----------+------+------+
| Prefix          |ID|Route| Route  |Active|Origin  |Metric|Pref|Next-hop   |Next-hop  |Backup|Backup|
|                 |  |Type | Owner  |      |Network |(Type)|    |           |Interface |Nexthp|Nexthp|
|                 |  |     |        |      |Instance|      |    |           |          |(Type)| If   |
+=================+==+=====+========+======+========+======+====+===========+==========+======+======+
| 172.18.0.9/32   |5 |host |net_inst| True | mgmt   | 0    | 0  |None       | None     |      |      |
|                 |  |     |_mgr    |      |        |      |    |(extract)  |          |      |      |
| 172.18.0.255/32 |5 |host |net_inst| True | mgmt   | 0    | 0  |None       |          |      |      |
|                 |  |     |_mgr    |      |        |      |    |(broadcast)|          |      |      |
| 172.18.0.0      |0 |linux|linux   | False| mgmt   | 0    | 5  |172.18.0.0 | mgmt0.0  |      |      |
|                 |  |     |_mgr    |      |        |      |    |(direct)   |          |      |      |
| 172.18.0.0      |5 |local|net_inst| True | mgmt   | 0    | 0  |172.18.0.9 | mgmt0.0  |      |      |
|                 |  |     |_mgr    |      |        |      |    |(direct)   |          |      |      |
+-----------------+--+-----+--------+------+--------+------+----+-----------+----------+------+------+
------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------
IPv4 unicast route table of network instance default
------------------------------------------------------------------------------------------------------

+-----------------+--+-----+--------+------+--------+------+----+-----------+----------+------+------+
| Prefix          |ID|Route| Route  |Active|Origin  |Metric|Pref|Next-hop   |Next-hop  |Backup|Backup|
|                 |  |Type | Owner  |      |Network |(Type)|    |           |Interface |Nexthp|Nexthp|
|                 |  |     |        |      |Instance|      |    |           |          |(Type)| If   |
+=================+==+=====+========+======+========+======+====+===========+==========+======+======+
| 10.1.1.1/32     |4 |host |net_inst| True |default | 0    | 0  |None       | None     |      |      |
|                 |  |     |_mgr    |      |        |      |    |(extract)  |          |      |      |
| 10.10.1.2/32    |2 |host |net_inst| True |default | 0    | 0  | None      | None     |      |      |
|                 |  |     |_mgr    |      |        |      |    |(extract)  |          |      |      |
| 10.1.1.255/32   |2 |host |net_inst| True |default | 0    | 0  | None      |          |      |      |
|                 |  |     |_mgr    |      |        |      |    |(broadcast)|          |      |      |
| 10.2.1.2/32     |3 |host |net_inst| True |default | 0    | 0  | None      | None     |      |      |
|                 |  |     |_mgr    |      |        |      |    |(extract)  |          |      |      |
| 10.2.1.255/32   |3 |host |net_inst| True |default | 0    | 0  |None       |          |      |      |
|                 |  |     |        |      |        |      |    |(broadcast)|          |      |      |
+-----------------+--+-----+--------+------+--------+------+----+-----------+----------+------+------+
------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------

CLI keyboard shortcuts

Use shortcuts to move the cursor on the command line, complete commands, and recall commands previously entered. Shortcuts can also make syntax correction easier. The following table lists common shortcuts.

Table 2. CLI keyboard shortcuts

Task

Keystroke

Move cursor to the beginning of the line

Ctrl-A

Move cursor to the end of the line

Ctrl-E

Move cursor one character to the right

Ctrl-F or Right arrow

Move cursor one character to the left

Ctrl-B or Left arrow

Move cursor forward one word

Esc+F

Move cursor back one word

Esc+B

Transpose the character to the left of the cursor with the character the cursor is placed on

Ctrl-T

Complete a partial command

Enter the first few letters, then press the Tab key

Recall previous entry in the buffer

Page up

Navigate one level up within a context. For example:

--{running}--[interface ethernet-1/1 subinterface 1]--
# exit
--{running}--[interface ethernet-1/1]--

Type: exit

Return to the root context. For example:

--{running}--[interface ethernet-1/1 subinterface 1]--
# exit all
--{running}--[ ]--

Type: exit all

Closing the CLI

Close the CLI using one of the following methods:

  • Press Ctrl+D.

  • Enter the quit command at the CLI prompt.

Configuration modes

Configuration modes define how the system is running when transactions are performed. Supported modes are the following:

  • Candidate – Use this mode 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.

    There are different types of configuration candidates. See Configuration candidates.

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

  • State – Use this mode to display the configuration and operational states. The state mode displays more information than show mode.

  • Show – Use this mode to display configured features and operational states. The show mode displays less information than state mode.

Configuration candidates

You can modify the candidate configuration in different modes:

  • Exclusive

  • Shared

  • Private

  • Name

Exclusive mode

When entering candidate mode, if you specify the exclusive keyword, it locks out other users from making changes to the candidate configuration.

You can enter candidate exclusive mode only under the following conditions:

  • The current shared candidate configuration has not been modified.

  • There are no other users in candidate shared mode.

  • No other users have entered candidate exclusive mode.

Shared mode

By default, the candidate configuration is in shared mode. This allows multiple users to modify the candidate configuration concurrently. When the configuration is committed, the changes from all of the users are applied.

A default candidate is defined per user (see Name mode).

Use caution when allowing multiple users access to the candidate configuration at the same time. If one user commits the configuration, that commits the changes made by any other users who have modified the current candidate configuration.

Private mode

A private candidate allows multiple users to modify a configuration; however when a user commits their changes, only the changes from that user are committed. When a private candidate is created, private datastores are created and a snapshot is taken from the running database to create a baseline.

When starting a private candidate, a default candidate is defined per user with the name ‛private-<username>’ unless a unique name is defined (see Name mode).

Name mode

Candidate types support an optional name. This allows multiple users to share environments.

When a candidate is created with a name specified, a new entry is created in the /system/configuration/candidate[] list. Other users can enter the same candidate (if the candidate type is shared) using this name.

If no name is specified, then the name default is used. This means the global shared candidate can be accessed by entering enter candidate name default or just enter candidate, For private candidates the name default is not used (because private candidates share a list with shared candidates). Instead, private candidates are created with the name private-<username>.

Named candidates are automatically deleted when there are no active sessions present and they are empty, or after 7 days of no session activity. This 7-day default is configurable in the /system/configuration/idle-timeout field.

Setting the configuration mode

After logging in to the CLI, you are initially placed in running mode. To change between modes, use one of the commands in the following table.

Table 3. Commands to change configuration mode

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

Change from running to shared mode

To change from running to a shared candidate mode (using the default)’:

--{ running }--[  ]--
# enter candidate
--{ * candidate shared default}--[  ]--

The asterisk (*) next to the mode name indicates that the candidate configuration has changes that have not yet been committed.

Switch between shared and candidate exclusive modes

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: 

--{ running }--[  ]--
# enter candidate exclusive
--{ candidate exclusive }--[  ]--
Are you sure? (y/[n]):
# enter running
--{ running }--[  ]--
# enter candidate
--{ candidate shared default}--[  ]--

Enter candidate mode for named candidate

To enter candidate mode for a named configuration candidate, you specify the name of the configuration candidate. For example: 

--{ running }--[  ]--
# enter candidate name cand1
--{ candidate shared cand1}--[  ]--

Managing configuration conflicts

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.

You can use the baseline command to assist in managing conflicts. It uses the following arguments:

  • baseline update - Performs an update of the complete baseline datastore, pulling in any changes that occurred in the running datastore since the baseline snapshot was taken.

  • baseline diff- Shows baseline configuration changes with options to refine by area.

  • baseline check - Performs a dry-run baseline check, and if conflicts are detected, an informational or warning message is generated.

Committing a configuration in candidate mode

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.

  1. Enter candidate mode:
    # enter candidate
  2. Enter configuration commands.
  3. Enter the commit command when with the required option.
    Table 4. commit command options

    Option

    Action

    Permitted additional arguments

    commit now

    Apply the changes, exit candidate mode, and enter running mode.

    NA

    commit stay

    Apply the changes and then remain in candidate mode.

    commit stay [save] [comment] [confirmed]

    commit save

    Apply the changes and automatically save the commit to the startup configuration. Can be used other arguments except now (for example, commit stay save).

    commit [stay] [checkpoint] save [confirmed] [comment]

    commit checkpoint

    Apply the changes and cause an automatic checkpoint after the commit succeeds.

    commit [stay] [now] checkpoint [save] [confirmed]

    commit validate

    Verify that a propose configuration change passes a management server validation.

    NA

    commit comment <comment>

    Use with other keywords (except validate) to add a user comment (for example, commit stay comment <comment> where <comment> is a quoted string, 1-255 characters.

    commit [stay] [save] [checkpoint] [confirmed] comment

    commit confirmed

    commit confirmed [timeout]

    commit confirmed [accept | reject]

    Apply the changes, but requires an explicit confirmation to become permanent. If the explicit confirmation is not issued within a specified time period, all changes are automatically reverted.

    The timeout period default is 600 seconds (10 mins.), or can be provisioned with a value of 1-86400 sec.). The timeout parameter cannot be used with the accept or reject parameter.

    Before the timer expires, the accept parameter explicitly confirms and applies the changes. With no timer running, the reject parameter explicitly rejects the changes.

    commit [checkpoint] [save] [stay] [comment] confirmed

commit stay and commit confirmed

This example shows the commit stay option:

# enter candidate
--{ candidate shared default}--[  ]--
# interface ethernet-1/1 subinterface 1
--{ * candidate shared default}--[ interface ethernet-1/1 subinterface 1 ]--

# commit stay
All changes have been committed. Starting new transaction.

--{ candidate shared default}--[ interface ethernet-1/1 subinterface 1 ]--

This example shows the commit confirmed option with a custom timeout followed by an accept action.

--{ * candidate shared default}--[  ]--
# commit confirmed timeout 86400
Commit confirmed (automatic rollback in a day)
All changes have been committed. Leaving candidate mode.
--{ running }--[  ]--

# commit confirmed accept
Info: Commit confirmed, automatic rollback cancelled
--{ candidate shared default}--[  ]--
#

Deleting configurations

Use the delete command to delete configurations while in candidate mode.

Delete configuration

The following example displays the system banner configuration, deletes the configured banner, then displays the resulting system banner configuration:

--{ candidate shared default}--[  ]--
# info system banner
    system {
        banner {
            login-banner "Welcome to SRLinux!"
        }
    }
--{ candidate shared default}--[  ]--
# delete system banner
--{ candidate shared default}--[  ]--
# info system banner
    system {
        banner {
        }
    }

Annotating the 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.

Add a comment

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.

--{ candidate shared default}--[  ]--
# acl acl-filter ip_tcp type ipv4 !! "Filter TCP traffic"

To replace the existing comment, use !!! instead of !! in the command.

Add a comment in annotate mode

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:

--{ * candidate shared default}--[  ]--
# acl acl-filter ip-tcp type ipv4
--{ * candidate shared default}--[ acl acl-filter ip-tcp type ipv4  ]--
# annotate
Press [Meta+enter] or [Esc] followed by [Enter] to finish
-> Filter TCP traffic

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:

--{ running }--[  ]--
# info acl
    acl {
        acl-filter ip-tcp type ipv4 {
            !!! Filter TCP traffic
            entry 100 {
                action {
                    log true
                    drop {
                    }
                }
            }
            entry 110 {
                action {
                    log true
                    accept {
                    }
                }
            }
        }
    }

To remove a comment, enter annotate mode for the context and press Esc then Enter without entering any text.

Discarding a configuration in candidate mode

You can discard previously applied configurations with the discard command. Use the discard command in candidate mode only.

  • To discard the changes and remain in candidate mode with a new candidate session, enter discard stay.

  • To discard the changes, exit candidate mode, and enter running mode, enter discard now.

Discard changes and remain in candidate mode

All changes have been committed. Starting new transaction.

--{ candidate shared }--[ interface ethernet-1/1 subinterface 1 ]--
# discard stay
--{ candidate shared }--[ interface ethernet-1/1 subinterface 1 ]--

Administrative commands

The common administrative CLI commands in this section can help you understand a current configuration and perform routine configuration tasks.

Pinging a destination IP address

Use the ping (IPv4) or ping6 (IPv6) command to contact an IP address. Use this command in any mode.

ping for IPV4

--{ running }--[  ]--
# ping 192.168.1.1 network-instance default
Pinging 192.168.1.1 in srbase-default
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.027 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.032 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.030 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6165ms
rtt min/avg/max/mdev = 0.027/0.030/0.033/0.005 ms

Tracing the path to a destination

To display the path a packet takes to a destination, use the traceroute (IPv4) or traceroute6 (IPv6) command.

To trace the route using TCP SYN packets instead of UDP or ICMP echo packets, use the tcptraceroute command.

traceroute for IPv4

--{ running }--[  ]--
# traceroute 1.1.1.1  network-instance mgmt
Using network instance srbase-mgmt
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  172.18.18.1 (172.18.18.1)  1.268 ms  1.260 ms  1.256 ms
 2  172.21.40.1 (172.21.40.1)  1.253 ms  1.848 ms  1.851 ms
 3  172.22.35.230 (172.22.35.230)  1.835 ms  1.834 ms  1.828 ms
 4  66.201.62.1 (66.201.62.1)  3.222 ms  3.222 ms  3.216 ms
 5  66.201.34.17 (66.201.34.17)  5.474 ms  5.475 ms  5.480 ms
 6  * * *
 7  206.81.81.10 (206.81.81.10)  32.577 ms  32.542 ms  32.400 ms
 8  1.1.1.1 (1.1.1.1)  22.627 ms  22.637 ms  22.638 ms

Configuring the network-instance environment variable

When you enter administrative commands such as ping and traceroute, you can specify the network-instance to be used with the command. If you do not specify a network-instance, then the network-instance configured in the network-instance environment variable is used.

If you do not specify a network-instance, or the network-instance cannot be inferred from the CLI context, then the <base> network instance is used when no network-instance is specified in a ping or traceroute command.

To configure the network-instance environment variable, use the environment network-instance command

ping with no network-instance specified

--{ running }--[  ]--
# ping 192.168.1.1
Using network instance <base>
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.027 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.032 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.030 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6165ms
rtt min/avg/max/mdev = 0.027/0.030/0.033/0.005 ms

Configure the environment network-instance

--{ candidate shared default }--[  ]--
# environment network-instance red

ping using implied network-instance

In this example, the network-instance environment variable is set to red, so network instance red is implied when the ping or traceroute command is entered without a network-instance name; for example:

--{ running }--[  ]--
# ping 192.168.1.1
Using network instance srbase-red
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.027 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.032 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.030 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6165ms
rtt min/avg/max/mdev = 0.027/0.030/0.033/0.005 ms

Using bash mode

From any mode in the CLI, use the bash command to enter the bash shell. To exit the bash shell and return to the CLI, enter exit.

You can use the bash command to enter Linux commands directly from the SR Linux CLI prompt.

Using bash shell

--{ running }--[  ]--
# bash
[root@3-node_srlinux-A /]# ls
anaconda-post.log  dev            etc   lib    media  opt   root  sbin  sys   tmp  var
bin                entrypoint.sh  home  lib64  mnt    proc  run   srv   tini  usr
[root@3-node_srlinux-A /]# exit
logout
--{ running }--[  ]--
#

Enter Linux commands using bash

--{ running }--[  ]--
# bash cat /etc/hosts
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.18.18.5     3-node-srlinux-A
### SRLINUX - ANYTHING MODIFIED BEYOND THIS POINT WILL BE OVERWRITTEN ###
127.0.0.1 3-node-srlinux-A
### SRLINUX FOOTER ###

Setting commands to execute periodically

To set a command to execute periodically, use the watch command. The watch command can be used with any valid command with the exception of interactive commands (for example, ping, monitor, packet-trace, bash, and bash oneliners such as bash cat /etc/hosts ). An error message is generated if an interactive command is used. Output redirection is supported.

When used, the first page of output displays. The command then re-executes every 2 seconds by default.

The watch command uses the following format:

watch <arguments> <command to watch>

All arguments must precede the command being watched. Arguments for the watch command are:

Arguments

Definition

interval

Sets an interval for the command to re-execute. Range: 1 - 3600 seconds. Default: 2 seconds

differences

For output that is actively changing, highlights the differences between the previous and current execution

cumulative-differences

For output that is actively changing, highlights the differences between the first execution and the current execution

no-colors

When used with differences or cumulative-differences, markers are used to show differences (verses colors)

no-limit

Allows the full output of each execution to display (verses limiting to the height of the terminal)

no-paging

Provides continuous output (verses redrawing the terminal with each execution)

no-title

Turns off the header that shows the interval, command, number of executions that have occurred, and the time

The command being watched does not require double quotes. In addition, the auto complete function can be used to complete a valid command.

To exit the watch command, enter Ctrl-C.

Watch interface statistics

In the following example, the watch command is used to show interface statistics (showing in-octets and out-octets in table format). The interval is modified to 10 seconds.

# watch interval 10 info from state interface * statistics | as table |filter fields in-octets out-octets

Every 10.0s: info from state interface * statistics | as table | filter fields in-octets out-octets (Executions 2,
Thu 04:47:34PM)
+---------------------+----------------------+----------------------+
|      Interface      |      In-octets       |      Out-octets      |
+=====================+======================+======================+
| ethernet-1/1        |               812755 |               812626 |
| ethernet-1/2        |               811411 |               810362 |
| ethernet-1/3        |                      |                      |
| ethernet-1/4        |                      |                      |
| ethernet-1/5        |                      |                      |
| ethernet-1/6        |                      |                      |
| ethernet-1/7        |                      |                      |
| ethernet-1/8        |                      |                      |
| ethernet-1/9        |                      |                      |
| ethernet-1/10       |                      |                      |
| ethernet-1/11       |                      |                      |
| ethernet-1/12       |                      |                      |
| ethernet-1/13       |                      |                      |
| ethernet-1/14       |                      |                      |
| ethernet-1/15       |                      |                      |

Show differences in interface statistics

In the following example, the watch command is used to show differences in interface statistics (with in-octets and out-octets in table format). In addition, the no-color argument is used to show the differences between previous and current execution with markers verses color indicators.

# watch differences no-colors info from state interface * statistics | as table |filter fields in-octets out-octets

Every 10.0s: info from state interface * statistics | as table | filter fields in-octets out-octets (Executions 4,
 Thu 04:54:48PM)
  +---------------------+----------------------+----------------------+
  |      Interface      |      In-octets       |      Out-octets      |
  +=====================+======================+======================+
- | ethernet-1/1        |               817889 |               817760 |
?                                          --                     ^ ^
+ | ethernet-1/1        |               817975 |               817865 |
?                                           ++                    ^ ^
- | ethernet-1/2        |               816328 |               815088 |
?                                          ^^                     ^^
+ | ethernet-1/2        |               816585 |               815278 |
?                                          ^ +                    ^^
  | ethernet-1/3        |                      |                      |
  | ethernet-1/4        |                      |                      |
  | ethernet-1/5        |                      |                      |
  | ethernet-1/6        |                      |                      |
  | ethernet-1/7        |                      |                      |
  | ethernet-1/8        |                      |                      |
  | ethernet-1/9        |                      |                      |

Using the diff command

Use the diff command to get a comparison of configuration changes. Optional arguments can be used to indicate the source and destination datastore. The following use rules apply:

  • If no arguments are specified, the diff is performed from the candidate to the baseline of the candidate.

  • If a single argument is specified, the diff is performed from the current candidate to the specified candidate.

  • If two arguments are specified, the first is treated as the source, and the second as the destination.

Global arguments include: baseline, candidate, checkpoint, factory, file, from, rescue, running, and startup.

The diff command can be used outside of candidate mode, but only if used with arguments.

Basic diff command with no arguments

The following shows a basic diff command without arguments. In this example, the description and admin state of an interface are changed and the differences shown:

--{ candidate shared default }--[  ]--
# interface ethernet-1/1 admin-state disable
--{ * candidate shared default }--[  ]--
# interface ethernet-1/2 description "updated"
--{ * candidate shared default }--[  ]--
# diff
      interface ethernet-1/1 {
+         admin-state disable
      }
+     interface ethernet-1/2 {
+         description updated
+     }

diff command with single argument

The following shows a diff with a single argument. In this example, the comparison occurs to and from a factory configuration.

--{ * candidate shared default }--[  ]--
# diff factory
      acl {
+         acl-filter allow_sip_dip type ipv4 {
+             subinterface-specific output-only
+             entry 10 {
+                 match {
+                     ipv4 {
+                         destination-ip {
+                             prefix 100.1.2.2/32
+                         }
+                         source-ip {
+                             prefix 100.1.1.1/32
+                         }
+                     }
+                 }
+                 action {
+                     accept {
+                     }
+                 }
+             }
+             entry 100 {
+                 action {
+                     accept {
+                     }
+                 }
+             }
+         }
      }

diff between two checkpoints

The following shows an example where the comparison occurs between two checkpoints.

--{ candidate shared default }--[  ]--
# save checkpoint name current
/system:
    Generated checkpoint '/etc/opt/srlinux/checkpoint/checkpoint-0.json' with name 'current' and comment ''
 
--{ candidate shared default }--[  ]--
# interface ethernet-1/1 description "changed-in-next-checkpoint"
--{ candidate shared default }--[  ]--
# commit stay
All changes have been committed. Starting new transaction.
--{ candidate shared default }--[  ]--
# save checkpoint name newer
/system:
    Generated checkpoint '/etc/opt/srlinux/checkpoint/checkpoint-0.json' with name 'newer' and comment ''
 
--{ candidate shared default }--[  ]--
# diff checkpoint newer checkpoint current
      interface ethernet-1/1 {
-         description changed-in-next-checkpoint
+         description dut1-dut2-1
      }

Using the copy command

Use the copy command to copy a specific context to another context. For example, you can use this command to copy a container or any configuration hierarchy and give it another name (such as an interface).

The copy command merges the existing context instead of replacing it. If a replace is required, you can delete the target node first. When using the copy command, matching fields populate to the destination node; fields that do not match are ignored. The use of ranges for both source and destination is permitted.

Use this command in candidate mode. Nokia also recommends that you use the diff command to verify changes when using complex copy operations such as multiple ranges in both the source and destination.

Copy context of one interface to another

The following shows the context of two existing interfaces (ethernet-1/1 and ethernet-2/1):

--{ candidate shared default }--[  ]--
# info interface ethernet-1/1
    interface ethernet-1/1 {
        description dut1-dut2-1
        ethernet {
            aggregate-id lag1
        }
    }
--{ candidate shared default }--[  ]--
# info interface ethernet-2/1
    interface ethernet-2/1 {
        description dut2-dut4-1
        subinterface 1 {
            ipv4 {
                admin-state enable
                address 1.2.4.2/24 {
                }
            }
            ipv6 {
                admin-state enable
                address 3ffe:0:2:4::2/64 {
                }
            }
        }
    }

To copy the context of ethernet-1/1 to ethernet-2/1, enter the following:

--{ candidate shared default }--[  ]--
# copy interface ethernet-1/1 to interface ethernet-2/1
--{ * candidate shared default }--[  ]--
# diff
      interface ethernet-2/1 {
-         description dut2-dut4-1
+         description dut1-dut2-1
          ethernet {
+             aggregate-id lag1
          }
      }

Copy matching fields only

The following shows an example where only some fields match. Fields that do not match are ignored:


--{ +* candidate shared default }--[  ]--
# info acl acl-filter cpm type ipv4 entry 10
    acl {
        acl-filter cpm type ipv4 {
            entry 10 {
                description "cpm-filter description"
                match {
                    ipv4 {
                        protocol icmp
                        icmp {
                            type dest-unreachable
                            code [
                                0
                                1
                                2
                                3
                                4
                                13
                            ]
                        }
                    }
                }
                action {
                    accept {
                    }
                }
            }
        }
    }

--{ * candidate shared default }--[  ]--
# copy acl cpm-filter ipv4-filter entry 10 to interface ethernet-2/1
--{ +* candidate shared default }--[  ]--
# diff
+     interface ethernet-2/1 {
+         description "cpm-filter description"
+     }

Copy with ranges

The following shows an example that uses ranges. The system expands both the source and destination to determine which set has the largest number of keys, and copies 1-to-1 until the larger of the two ranges finishes. 

--{ * candidate shared default }--[  ]--
# copy interface ethernet-1/{1,2} to interface ethernet-{2,3}/{1..10}
--{ * candidate shared default }--[  ]--
# diff
      interface ethernet-2/1 {
-         description dut2-dut4-1
+         description dut1-dut2-1
+         ethernet {
+             aggregate-id lag1
+         }
      }
      interface ethernet-2/2 {
-         description dut2-dut3-1
+         description "second description"
+         mtu 9000
+     }
+     interface ethernet-2/3 {
+         description dut1-dut2-1
+         ethernet {
+             aggregate-id lag1
+         }
      }

+     interface ethernet-3/1 {
+         description dut1-dut2-1
+         ethernet {
+             aggregate-id lag1
+         }
+     }
+     interface ethernet-3/2 {
+         description "second description"
+         mtu 9000
+     }
+     interface ethernet-3/3 {
+         description dut1-dut2-1
+         ethernet {
+             aggregate-id lag1
+         }
+     }
+     interface ethernet-3/4 {
+         description "second description"
+         mtu 9000
+     }

+     interface ethernet-3/9 {
+         description dut1-dut2-1
+         ethernet {
+             aggregate-id lag1
+         }
+     }
+     interface ethernet-3/10 {
+         description "second description"
+         mtu 9000
+     }

Using the replace command

Use the replace command to replace a source context with a destination context (including all of its children). Both the source and destination can be text. This command can also be used to create a destination that does not currently exist by creating a new key that uses the source configuration.

The replace command has the following usage: replace <original text> with <replacement text>

Use this command in candidate mode.

replace network-instance

The following example replaces all instances of the "mgmt" network-instance with a "test" network-instance:

--{ candidate shared default }--[  ]--
# replace "network-instance mgmt" with "network-instance test"
--{ * candidate shared default }--[  ]--
# diff      system {
          ssh-server mgmt {
-             network-instance mgmt
+             network-instance test
          }
          grpc-server mgmt {
-             network-instance mgmt
+             network-instance test
          }
          json-rpc-server {
-             network-instance mgmt {
+             network-instance test {
              }
          }
      }

replace interface

The following example shows a command line that can be used to replaces all instances of "interface lag3" or "aggregate-id lag3" with "interface lag2" or "aggregate-id lag2":

--{ candidate shared default }--[  ]--
# replace "(interface |aggregate-id )lag3" with \1lag2

replace with environment alias

The replace command can also be used with the environment alias command so that multiple arguments can be used. In the following, an alias named ‛ifrename’ is created to replace the name of an interface:

--{ candidate shared default }--[  ]--
# environment alias ifrename "replace \"(interface |aggregate-id ){}\b\" with \1{} /"

When the alias is created, the alias with the arguments is entered. 

--{ candidate shared default }--[  ]--
# ifrename lag2 lag9

Displaying configuration details

Use the info command to display the configuration. 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.

info from root context

To display the entire configuration, enter info from the root context:

--{ candidate shared default}--[  ]--
# info
<all the configuration is displayed>
--{ candidate }--[  ]--

info for specific context

To display the configuration for a specific context, enter info and specify the context:

--{ candidate shared default}--[  ]--
# info system lldp
    system {
        lldp {
            admin-state enable
            hello-timer 600
            management-address mgmt0.0 {
                type [
                    IPv4
                ]
            }
            interface mgmt0 {
                admin-state disable
            }
        }
    }
--{ candidate }--[  ]--

info within specific context

From a context, use the info command to display the configuration under that context:

--{ candidate shared default}--[  ]--
# system lldp
--{ candidate }--[ system lldp ]--
# info
    admin-state enable
    hello-timer 600
    management-address mgmt0.0 {
        type [
            IPv4
        ]
    }
    interface mgmt0 {
        admin-state disable
    }
--{ candidate }--[ system lldp ]--

info within specific context with JSON-formatted output

Use the as-json option to display JSON-formatted output:

--{ candidate }--[ system lldp ]--
# info | as json
{
  "admin-state": "enable",
  "hello-timer": "600",
  "management-address": [
    {
      "subinterface": "mgmt0.0",
      "type": [
        "IPv4"
      ]
    }
  ],
  "interface": [
    {
      "name": "mgmt0",
      "admin-state": "disable"
    }
  ]
}

info detail

Use the detail option to display values for all parameters, including those not specifically configured:

--{ candidate shared default}--[ system lldp ]--
# info detail
    admin-state enable
    hello-timer 600
    hold-multiplier 4
    management-address mgmt0.0 {
        type [
            IPv4
        ]
    }
    interface mgmt0 {
        admin-state disable
    }

info flat

Use the flat option to display the output as a series of set statements, omitting indentation for any sub-contexts:

--{ candidate shared default}--[ system lldp ]--
# info flat
set / system lldp admin-state enable
set / system lldp hello-timer 600
set / system lldp management-address mgmt0.0
set / system lldp management-address mgmt0.0 type [ IPv4 ]
set / system lldp interface mgmt0
set / system lldp interface mgmt0 admin-state disable

info depth

Use the depth option to display parameters with a specified number of sub-context levels:

--{ candidate shared default}--[ system lldp ]--
# info depth 0
    admin-state enable
    hello-timer 600

--{ candidate shared default}--[ system lldp ]--
# info depth 1
    admin-state enable
    hello-timer 600
    management-address mgmt0.0 {
        type [
            IPv4
        ]
    }
    interface mgmt0 {
        admin-state disable
    }

Displaying the command tree hierarchy

Use the tree command to display the tree hierarchy for all available nodes you can enter. Entering the tree command from the root context displays the entire tree hierarchy. Entering the command from a context limits the display to the nodes under that context. Use this command in candidate or running mode.

tree command

--{ candidate shared default}--[ ]--
# tree
<root>
acl
+-- egress-mac-filtering
+-- acl-filter
|  +-- description
|  +-- subinterface-specific
|  +-- statistics-per-entry
|  +-- entry
|     +-- description
|     +-- match
|     |  +-- l2
|     |  |  +-- ethertype
|     |  |  +-- destination-mac
|     |  |  |  +-- address
|     |  |  |  +-- mask
|     |  |  +-- source-mac
|     |  |  |  +-- address
|     |  |  |  +-- mask
.
.
.
.

Displaying the state of the configuration

To display the state of the configuration, enter the info from state command in candidate or running mode, or the info command in state mode.

info from state command

To display state information for a specified context from modes that are not state mode:

--{ candidate shared default}--[  ]--
# info from state routing-policy policy bgp-export-policy
    routing-policy {
        policy bgp-export-policy {
            statement 999 {
                action {
                    accept {
                    }
                }
            }
        }
    }
--{ candidate }--[  ]--

info command from state mode

To display state information for a specified context from state mode:

--{ candidate shared shared default}--[  ]--
# enter state
--{ state }--[  ]--
# info routing-policy policy bgp-export-policy
    routing-policy {
        policy bgp-export-policy {
            statement 999 {
                action {
                    accept {
                    }
                }
            }
        }
    }
--{ state }--[  ]--

Executing configuration statements from a file

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). 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.

Execute configuration from a file

The following example executes a configuration from a specified file:

--{ running }--[  ]--
# source config.cfg
Sourcing commands from 'config.cfg'
Executed 20 lines in 1.6541 seconds from file config.cfg

Use the auto-commit option to commit the configuration after the commands in the source file are executed.

Collecting technical support data

Collect technical support data using the tech-support command. Use this command in any configuration mode.

Collect technical support data

--{ candidate shared default}--[  ]--
# tech-support
Waiting 5 seconds for apps to dump the reports in /tmp/admintech-report-2019_06_19_20_26_05.zip
Finished collecting in 5s
Admin tech report has been generated at /tmp/admintech-report-2019_06_19_20_26_05.zip
--{ candidate }--[  ]--

Access technical support file from bash shell

You can access the saved file from the bash shell. For example:

--{ running }--[  ]--
# bash
[root@3-node_srlinux-A /]# cd /tmp
[root@3-node_srlinux-A tmp]# ls -l
total 6012
-rw-r--r-- 1 root root 6110160 Jun 19 20:26 admintech-report-2019_06_19_20_26_05.zip
[root@3-node_srlinux-A tmp]# exit
logout
--{ running }--[  ]--

CLI output formatting and filtering

Several ways exist to format and filter CLI output. These include:

  • Specifying the display output (text, JSON, or table format)

  • Filtering the output using Linux tools such as grep

  • Using an output filter

  • Directing filtered output to a specified file in a specified format

Specifying output format

You can display output from SR Linux CLI commands as lines of text, in JSON format, or in a table. By default, output is displayed as lines of text, but you can configure output to be displayed in JSON format by default. See Configuring the CLI output format.

show version | as text

The following example displays the output of the show version command as lines of text:

--{ running }--[  ]--
# show version | as text
--------------------------------------------------------------------------------
Hostname          : 3-node-srlinux-A
Chassis Type      : 7250 IXR-10
Part Number       : Sim Part No.
Serial Number     : Sim Serial No.
System MAC Address: 12:12:02:FF:00:00
Software Version  : v19.11.1
Build Number      : 291-g4664705
Architecture      : x86_64
Last Booted       : 2019-12-07T00:34:48.942Z
Total Memory      : 16396536 kB
Free Memory       : 5321932 kB
--------------------------------------------------------------------------------

show version | as json

The following example displays the output of the show version command in JSON format:

--{ running }--[  ]--
# show version | as json
{
  "basic system info": {
    "Hostname": "3-node-srlinux-A",
    "Chassis Type": "7250 IXR-10",
    "Part Number": "Sim Part No.",
    "Serial Number": "Sim Serial No.",
    "System MAC Address": "12:12:02:FF:00:00",
    "Software Version": "v19.11.1",
    "Build Number": "291-g4664705",
    "Architecture": "x86_64",
    "Last Booted": "2019-12-07T00:34:48.942Z",
    "Total Memory": "16396536 kB",
    "Free Memory": "5319448 kB"
  }
}

show version | as table

The following example displays the output of the show version command as a table:

--{ running }--[  ]--
# show version | as table
+----------+----------+-------+--------+--------+----------+----------+----------+
| Hostname | Chassis  | Part  | Serial | System | Software | Architec |   Last   |
|          |   Type   | Number| Number |  MAC   | Version  |   ture   |  Booted  |
|          |          |       |        | Address|          |          |          |
+==========+==========+=======+========+========+==========+===========+=========+
| 3-node-s | 7250     | Sim Pa| Sim    |12:12:05| v19.11.1 | x86_64   | 2019-12- |
| rlinux-A | IXR-10   |rt No. | Serial |:FF:00:0|          |          | 07T00:34 |
|          |          |       | No.    |0       |          |          | :48.942Z |
+----------+----------+-------+--------+--------+----------+----------+----------+

Using Linux output modifiers

You can pipe output from SR Linux CLI commands to standard Linux tools using grep, more, head, and tail.

show interface | grep

The following example pipes the output of the show interface command to grep so that only lines with mgmt0 appear in the output:

--{ running }--[  ]--
# show interface | grep mgmt0
mgmt0 is up, speed None, type None
  mgmt0.0 is up

show interface | more

The following example pipes the output of the show interface command to more to display one page of output at a time:

--{ running }--[  ]--
# show interface | more
===================================================================================
ethernet-1/10 is up, speed 100G, type 100GBASE-CR4 CA-L
  ethernet-1/10.1 is up
    Encapsulation: null
    IPv4 addr    : 192.35.1.0/31 (static)
    IPv6 addr    : 2001:192:35:1::/127 (static, preferred)
    IPv6 addr    : fe80::22e0:9cff:fe78:e2ea/64 (link-layer, preferred)
-----------------------------------------------------------------------------------
ethernet-1/21 is up, speed 100G, type 100GBASE-CR4 CA-L
  ethernet-1/21.1 is up
    Encapsulation: null
    IPv4 addr    : 192.45.1.254/31 (static)
    IPv6 addr    : 2001:192:45:1::fe/127 (static, preferred)
    IPv6 addr    : fe80::22e0:9cff:fe78:e2f5/64 (link-layer, preferred)
-----------------------------------------------------------------------------------
ethernet-1/22 is up, speed 100G, type 100GBASE-CR4 CA-L
  ethernet-1/22.1 is up
    Encapsulation: null
    IPv4 addr    : 192.45.3.254/31 (static)
    IPv6 addr    : 2001:192:45:3::fe/127 (static, preferred)
    IPv6 addr    : fe80::22e0:9cff:fe78:e2f6/64 (link-layer, preferred)
-----------------------------------------------------------------------------------
ethernet-1/3 is up, speed 100G, type 100GBASE-CR4 CA-L
  ethernet-1/3.1 is up
    Encapsulation: null
    IPv4 addr    : 192.57.1.1/31 (static)
    IPv6 addr    : 2001:192:57:1::1/127 (static, preferred)
    IPv6 addr    : fe80::22e0:9cff:fe78:e2e3/64 (link-layer, preferred)
-----------------------------------------------------------------------------------
--More--

show interface | head

The following example pipes the output of the show interface command to head to display only the first 8 lines:

--{ running }--[  ]--
# show interface | head --lines 8
===================================================================================
ethernet-1/10 is up, speed 100G, type 100GBASE-CR4 CA-L
  ethernet-1/10.1 is up
    Encapsulation: null
    IPv4 addr    : 192.35.1.0/31 (static)
    IPv6 addr    : 2001:192:35:1::/127 (static, preferred)
    IPv6 addr    : fe80::22e0:9cff:fe78:e2ea/64 (link-layer, preferred)
-----------------------------------------------------------------------------------

Using output filters

You can use the filter option to limit the output of show and info from state commands. Filter options include:

  • node - Defines a specific node to filter on

  • depth - Filters out sub-nodes that are deeper than the specified depth

  • fields - Specifies a specific field or fields to filter on

  • keys-only - Hides all fields

  • non-zero - Filters integer fields set to 0 and empty strings

The show or info from state command is piped to the filter command with the following usage: filter [<node>] [depth <value>] [fields <value>] [keys-only] [non-zero]

Filter info from state command

The following example directs the output of the info from state command to filter on the Ethernet node.

--{ running }--[  ]--
# info from state interface ethernet-1/1 | filter ethernet
    interface ethernet-1/1 {
        description dut1-dut2-1
        admin-state enable
        mtu 9232
        loopback-mode false
        ifindex 54
        oper-state up
        last-change "an hour ago"
        linecard 1
        forwarding-complex 0
        vlan-tagging false
        ethernet {
            port-speed 10G
            hw-mac-address 00:01:02:FF:00:00
            flow-control {
                receive false
            }
            statistics {
                in-mac-pause-frames 0
                in-oversize-frames 0
                in-jabber-frames 0
                in-fragment-frames 0
                in-crc-error-frames 0
                out-mac-pause-frames 0
                in-64b-frames 0
                in-65b-to-127b-frames 0
                in-128b-to-255b-frames 0
                in-256b-to-511b-frames 0
                in-512b-to-1023b-frames 0
                in-1024b-to-1518b-frames 0
                in-1519b-or-longer-frames 0
                out-64b-frames 0
                out-65b-to-127b-frames 0
                out-128b-to-255b-frames 0
                out-256b-to-511b-frames 0
                out-512b-to-1023b-frames 0
                out-1024b-to-1518b-frames 0
                out-1519b-or-longer-frames 0
            }
        }
    }

Apply filter to a specific field

Specify the field option to further filter the output to a specific field. For example:

--{ running }--[  ]--
# info from state interface ethernet-1/1 | filter fields ethernet/port-speed
    interface ethernet-1/1 {
        ethernet {
            port-speed 10G
        }
    }

Apply non-zero filter

The following example shows how you can use the non-zero option to display only non-zero values to eliminate non-useful information. The use of the non-zero option only filters integer fields that are currently set to 0 and empty strings.

--{ running }--[  ]--
# info from state interface ethernet-1/* statistics | filter non-zero
    interface ethernet-1/1 {
        statistics {
            in-octets 1106761
            in-unicast-packets 1592
            in-broadcast-packets 32
            in-multicast-packets 10736
            in-error-packets 5
            out-octets 2859625
            out-unicast-packets 31576
            out-broadcast-packets 18
            out-multicast-packets 243
            carrier-transitions 3
        }
    }
    interface ethernet-1/2 {
        statistics {
            in-octets 1399961
            in-unicast-packets 129
            in-broadcast-packets 11
            in-multicast-packets 14772
            in-error-packets 1
            out-octets 2474023
            out-unicast-packets 26126
            out-broadcast-packets 19
            out-multicast-packets 173
            carrier-transitions 3
        }
    }
    interface ethernet-1/20 {
        statistics {
            in-octets 1443012
            in-unicast-packets 350
            in-broadcast-packets 12
            in-multicast-packets 15639
            in-error-packets 3
            out-octets 2319629
            out-unicast-packets 25558
            out-broadcast-packets 17
            out-multicast-packets 199
            carrier-transitions 3
        }
    }

Using the jq output modifier

The jq output modifier (see https://jqlang.github.io/jq/) is a JSON processor that can manipulate SR Linux show, info, and info from state output, provided the output is displayed in JSON format (using the | as json option). You can use jq to filter, extract, combine, and modify the JSON output. You can also use piping to combine jq arguments in various ways, such as feeding the results of one filter into another, or collecting the output into an array. The jq processor is supported as a CLI plug-in that is enabled by default.

To modify the show or info output with the jq output modifier, include the | as json parameter in the command, followed by | jq and one or more jq arguments.
Note: SR Linux uses double quotes (") rather than single quotes (') to define jq filter expressions in the jq output modifier. Therefore, if a jq expression contains double quotes, they must be escaped using a backslash (\").

Modify info from state output

The following example modifies the output of the info from state command to list applications that have a status of waiting-for-config.

--{ running }--[  ]--
# info from state system app-management application * state | as json | jq ".system.\"app-management\".application[] | select(.state == \"waiting-for-config\") | .name"
"dhcp_relay_mgr"
"dhcp_server_mgr"
"ethcfm_mgr"
"event_mgr"
"fhs_mgr"
"gribi_server"
"igmp_mgr"
"isis_mgr"
"l2_proxy_arp_nd_mgr"
"l2_static_mac_mgr"
"label_mgr"
"ldp_mgr"
"macsec_mgr"
"mirror_mgr"
"mpls_mgr"
"oam_mgr"
"oc_mgmt_server"
"ospf_mgr"
"p4rt_server"
"pim_mgr"
"segrt_mgr"
"static_route_mgr"
"te_mgr"
"tepolicy_mgr"
"twamp_mgr"
"vrrp_mgr"

Directing output to a file

You can direct the output of SR Linux CLI commands to a specified file. The output can be saved as text, in table format, or in JSON format.

Direct show interface output to file

The following example directs the output of the show interface command to a file. The output is saved in JSON format.

--{ running }--[  ]--
# show interface | as json > show_interface.json

Use > to create a new file with the specified filename; if the file already exists, it is replaced. Use > to append the output to the specified file if it exists.

Access output file in bash mode

You can access the file using bash mode. For example:

--{ * running }--[  ]--
# bash
[bob@3-node-srlinux-A /]# more show_interface.json
{
  "interfaces": [
    {
      "Interface": "ethernet-1/1",
      "subinterfaces": [
        {
          "Subinterface": "ethernet-1/1.1",
          "Oper": "up",
          "IPv4 Addresses": "192.168.11.1/30",
          "IPv6 Addresses": "2001:1::192:168:11:1/126, fe80::1012:5ff:feff:0/64"
        }
      ]
    },
    {
--More--(42%)

CLI environment customization

You can optionally configure the SR Linux CLI environment to change settings such as the command prompt, contents of the bottom toolbar, and the default format for displayed output. You can create aliases for CLI commands. The CLI environment settings can be saved to the default SR Linux configuration or to a specified file and subsequently loaded and applied to the current CLI session.

Configuring the CLI prompt

By default, the SR Linux CLI prompt consists of two lines of text, indicating with an asterisk whether the configuration has been modified, the current mode and session type, the current CLI context, and the host name of the SR Linux device, in the following format:

--{ modified? mode_and_session_type }--[ context ]--
hostname#

For example:

--{ * candidate shared }--[ acl ]--
3-node-srlinux-A#

You can configure the SR Linux prompt to include information such as the username or session ID of the CLI session, the number of changes made to the configuration, and the current local time.

Add local time and session username to CLI prompt

The following example adds the local time and session username to the SR Linux CLI prompt. 

--{ candidate shared default}--[  ]--
# environment prompt "--{{ {modified}{mode_and_session_type} }}--[ {pwc} ]--{time}--\n{user}@{host}# "

In the example, the local time is configured with the {time} keyword, and the session username is configured with the {user} keyword. The line break is configured with \n. Use the environment prompt ? command to display the keywords that you can configure in the SR Linux CLI prompt.

After you enter this command, the CLI prompt looks like the following:

--{ * candidate shared default}--[ acl ]--Wed 03:07PM--
bob@3-node-srlinux-A#

Configuring the bottom toolbar text

By default, the text that appears at the bottom of the terminal window in SR Linux CLI sessions displays the current mode and session type, whether the configuration has been modified, the username and session ID of the current AAA session, and the local time, in the following format:

Current mode: modified? mode_and_session_type aaa_user (aaa_session_id) time

For example:

Current mode: * candidate shared                          root (36)  Wed 09:52PM

You can configure the bottom toolbar using the environment bottom-toolbar command to include information such as the number of changes made to the configuration and the host name.

Add number of changes and host name to toolbar

The following example adds the number of changes made to the configuration and the host name to the bottom toolbar. 

--{ candidate shared default}--[  ]--
# environment bottom-toolbar "Current mode: {modified_with_change_count}{mode_and_session_type} | {aaa_user}@{host} ({aaa_session_id})  {time}"

In the example, the number of configuration changes is configured with the {modified_with_change_count} keyword, and the host name is configured with the {host} keyword. Use the environment bottom-toolbar ? command to display the keywords that you can configure in the bottom toolbar.

After you enter this command, the bottom toolbar looks like the following:

Current mode: *10 candidate shared       root@3-node-srlinux-A (36)  Wed 10:18PM

Configuring the SR Linux CLI engine type

SR Linux features two versions of the CLI engine: advanced and basic. The advanced CLI engine is enabled by default; it includes the following features:

  • Displays a toolbar at the bottom of the terminal window.

  • Includes the command auto-complete feature.

  • Allows you to select command options by pressing the Tab key to display the options in a popup, then using the arrow keys to select an option.

  • Displays descriptions of command options when you press the ? key.

The basic CLI engine includes a limited set of features compared to the advanced version:

  • Omits the bottom toolbar.

  • Does not present a selectable list of options when you press the Tab key.

  • Displays descriptions of command options when you press the ? key (and press Enter), but only at the # prompt for the current context.

If necessary, you can use the environment cli-engine type basic command to configure SR Linux to use the basic CLI engine instead of the advanced CLI engine for CLI sessions.

Set CLI engine type to basic

The following example configures the SR Linux to use the basic CLI engine for CLI sessions:

--{ candidate shared default}--[  ]--
# environment cli-engine type basic

Configuring the SR Linux CLI completion type

When you enter a partial command at the CLI prompt and press the Tab key, SR Linux auto-completes the command if no other command at that level starts with those letters.

If multiple commands at that level start with the letters you typed, SR Linux displays a list of options that can complete the command.

  • When the basic CLI engine type is configured, SR Linux displays the command options as a non-selectable list. For example:
  • When the advanced CLI engine type is configured, SR Linux displays a popup with possible commands that are valid at that level. You can press the up or down arrows to select a command in the list. For example:

The command options that appear when you press the Tab key depend on the SR Linux CLI completion type setting, which can be one of the following:

CLI completion type

Definition

prefix

The displayed options start with the letters you typed before pressing Tab.

This is the only valid CLI completion type for the basic CLI engine.

smart
The displayed options contain the letters you typed before pressing Tab. Preference is given to the following:
  • Options that start with the letters you typed
  • Multi-word options where each word in the option starts with a letter you typed; for example, typing ni displays network-instance as an option.
  • Options that contain the letters you typed; for example, typing inst displays network-instance as an option.
  • Options that exist only at the current CLI level, rather than those that exist at every CLI level.

This is the default CLI completion type for the advanced CLI engine.

substring

The displayed options contain the letters you typed as a string within the option name; for example, typing stat displays modules-state, netconf-state, and statistics as options.

fuzzy

SR Linux displays options that contain the letters you typed as a string, as well as options that are close; for example, typing ntw displays network-instance as an option.

To configure the SR Linux CLI completion type, use the environment cli-engine completion-type command.

Set CLI completion type to prefix

The following example configures SR Linux to use prefix as the CLI completion type.

In this example, if you type system net and press Tab, SR Linux displays the command options at the system level that start with net.

Set CLI completion type to smart

The following example configures SR Linux to use smart as the CLI completion type.

In this example, if you type system net and press Tab, SR Linux displays the command options at the system level that start with net, as well as those that include the letters n, e, and t.

Set CLI completion type to substring

The following example configures SR Linux to use substring as the CLI completion type.

In this example, if you type system ne and press Tab, SR Linux displays the command options at the system level that include the text string ne.

Set CLI completion type to fuzzy

The following example configures SR Linux to use fuzzy as the CLI completion type.

In this example, if you type system nework and press Tab, SR Linux corrects the spelling of the command to system network, since system network-instance is a valid command at this CLI level.

Configuring the CLI output format

You can configure the output of CLI commands using the output-format command to be displayed as either text or in JSON format.

Set output to JSON format

The following example configures CLI command output to be displayed in JSON format.

--{ candidate shared default}--[  ]--
# environment output-format json

Subsequent command output is displayed in JSON format by default. For example:

--{ running }--[  ]--
# show version
{
  "basic system info": {
    "Hostname": "3-node-srlinux-A",
    "Chassis Type": "7250 IXR-10",
    "Part Number": "Sim Part No.",
    "Serial Number": "Sim Serial No.",
    "System MAC Address": "12:12:02:FF:00:00",
    "Software Version": "v19.11.1",
    "Build Number": "291-g4664705",
    "Architecture": "x86_64",
    "Last Booted": "2019-12-07T00:34:48.942Z",
    "Total Memory": "16396536 kB",
    "Free Memory": "5319448 kB"
  }
}

Configuring CLI command aliases

As a shortcut for entering commands in the CLI, you can configure CLI command aliases using the environment alias command. The alias can include one or more CLI command keywords and arguments.

Set alias for info interface command

The following example configures the alias display interface for the SR Linux command info interface <name>subinterface <index> | as table:

--{ candidate shared default}--[  ]--
# environment alias "display interface" "info / interface {} subinterface {subinterface} | as table"

In the example, the display interface alias consists of the keywords info interface, arguments to specify an interface name and subinterface number, and keywords to display the output as a table. The alias name and aliased command are each enclosed in quotes. The arguments are enclosed in braces ({ }). The argument {} creates an optional unnamed variable for the interface name, and the argument {subinterface} creates an optional parameter named subinterface.

When you enter the alias at the CLI prompt, the output of the aliased command is displayed. For example: 

# display interface ethernet-1/1 subinterface 1
+---------------------+-------+-------------+
|      Interface      | Index | Admin-state |
+=====================+=======+=============+
| ethernet-1/1        |     1 | enable      |
+---------------------+-------+-------------+

If you omit the optional parameters for the interface and subinterface names, they are treated as wildcards. For example:

# display interface
+---------------------+-------+-------------+
|      Interface      | Index | Admin-state |
+=====================+=======+=============+
| ethernet-1/1        |     1 | enable      |
| ethernet-1/2        |     1 | enable      |
| lo0                 |     1 | enable      |
| mgmt0               |     0 | enable      |
+---------------------+-------+-------------+

Configuring command auto-completion

By default, if you enter a tab at any mode or level to auto-complete the next command level, a popup appears that displays the available options for that command.

You can optionally configure the space bar to provide the same function as the Tab key, so that pressing the space bar auto-completes the command.

To configure command auto-completion using the space bar, set the environment complete-on-space command to true.

Set space bar to auto-complete commands

--{ candidate shared default}--[  ]--
# environment complete-on-space true

Displaying the CLI environment configuration

To display the CLI environment configuration, including any CLI command aliases, use the environment show command.

environment show

--{ candidate shared default}--[  ]--
# environment show
[alias]
"show system configuration session" = "info from state / system configuration session {} | as table | filter fields username type started"
"show system configuration checkpoint" = "info from state / system configuration checkpoint {} | as table | filter fields name comment username created"
"display interface" = "info / interface {} subinterface {subinterface} | as table

[bottom-toolbar]
value = "Current mode: {modified}{mode_and_session_type} | {aaa_user} ({aaa_session_id})  {time}"

[cli-engine]
type = "advanced"

[output-display-format]
value = "text"

[prompt]
value = "--{{ {modified}{mode_and_session_type} }}--[ {pwc} ]--\n{host}# "

[space-completion]
enabled = false

Managing CLI environment settings

You can save the current CLI environment settings to the default SR Linux configuration using the environment save home command, and you can load those settings using the environment load home command.

Alternatively, you can save the CLI environment settings to a file using the environment save file command and you can load those settings from the file using the environment load file command.

Save CLI environment settings to default configuration

The following example saves the current CLI environment settings to the default SR Linux configuration:

--{ candidate shared default}--[  ]--
# environment save home
Saved configuration to /root/.srlinuxrc

Load CLI environment settings from default

The following example loads CLI environment settings from the default SR Linux configuration:

--{ candidate shared default}--[  ]--
# environment load home
Loaded configuration from /root/.srlinuxrc

Save CLI environment settings to file

The following example saves the current CLI environment settings to a file:

--{ candidate shared default}--[  ]--
# environment save file env.cfg
Saved configuration to env.cfg

Load CLI environment settings from file

The following example loads CLI environment settings from a file:

--{ candidate shared default}--[  ]--
# environment load file env.cfg
Loaded configuration from env.cfg