Command Line Interface

Module Introduction

Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:

student@tour:~/trainings_resources/robot$ robot basics/basics_setup.robot

Logging into the System

The standard way to access a RBFS is by means of secure shell. By default, the username is supervisor and the corresponding password is also supervisor.

student@tour:~/tour$ ssh r1
supervisor@r1's password:
Last login: Fri Jun 26 12:42:11 2026 from 10.0.3.1

+--------------------------------------------------------------------+
|                                                                    |
    RBFS container R1 running on rtbrick:
        Date:       Fri Jun 26 12:43:03 UTC 2026
        Uptime:     up 1 hour, 36 minutes

    Image metadata:
        UUID:       280b6012-d9db-4677-82a2-98f2b62e4549
        Version:    26.1.1.1
        Role:       multiservice-edge
        Platform:   virtual
        Model:
        Format:     lxd
        Build date: 2026-05-27 06:44:55 UTC
        Based on:   Debian GNU/Linux 12 (bookworm)

    RBFS License:
        No license found
|                                                                    |
+--------------------------------------------------------------------+

supervisor@R1>tour:~ $

After successfully logging into the system, you will first see some practical information. In this lab we use a virtual system as you can see in the corresponding platform parameter.

Exercise 1: Version and Roles

Which version and role is your system, and OS is it based on?

Click to reveal the answer 
The version in this example is *26.1.1.1* and the role is *multiservice-edge*, running on *virtual* platform. +
You can also see that this node is based on Debian GNU/Linux 12 (bookworm).

We will now start the RBFS command line interface (CLI) that enables you to interact with RBFS for monitoring, configuring, debugging, and maintaining the system.

supervisor@R1>tour:~ $ cli
op>

Once you have started the CLI, the command prompt will change to op>. The CLI provides some features that help you working with the CLI, e.g., automatic command completion using the TAB key or list of available options using the kbd:? key.

Exercise 2: CLI Help

What happens if you type the ? key? Which command allows you to set the mode for CLI operation?

Click to reveal the answer 
op>
<...>
  show                  Show a particular state of the system
  switch-mode           Set a mode for CLI operation
  switch-over           Initiate redundancy switch-over
<...>

The correct command is switch-mode which allows you to set the mode to operation (default), config and debug.

Exploring the System

For monitoring the system and troubleshooting the various show commands are very useful. If you enter show followed by the ? key again, you get a list of options for this new command hierarchy.

Exercise 3: Displaying Interfaces

What is the output of the command show interface summary? How many interfaces does your switch have?

Click to reveal the answer 
op> show interface summary
Interface                Admin    Link     Oper          IPv4 Address             IPv6 Address
hostif-0/0/0             Up       Up       Up
hostif-0/0/1             Up       Up       Up
hostif-0/0/2             Up       Up       Up
hostif-0/0/4             Up       Up       Up
hostif-0/0/11            Up       Up       Up

There are five interfaces available on the switch.

By default, RBFS is running Link Layer Discovery Protocol (LLDP) on all active interfaces. LLDP is a media-independent link layer protocol used by network devices for advertising their identity, capabilities to neighbors on a LAN segment. LLDP runs over the data-link layer only, allowing two systems running different network layer protocols to learn about each other.

Exercise 4: LLDP Neighbors

What is the output of the command show lldp neighbor? How many neighbors do you have?

Click to reveal the answer 
op> show lldp neighbor
Neighbor name      Status  Remote port ID     Local port ID      Neighbor MAC address  Last received     Last sent
R2                 Up      hostif-0/0/1       hostif-0/0/1       7a:fc:da:00:00:00     0:00:20 ago       0:00:11 ago
R2                 Up      hostif-0/0/11      hostif-0/0/11      7a:fc:da:00:00:00     0:00:30 ago       0:00:11 ago
R3                 Up      hostif-0/0/2       hostif-0/0/2       7a:00:3f:01:00:00     0:00:20 ago       0:00:11 ago

Like any other computer, the switch consists of a CPU, RAM, and disks which are needed to run the control and management plane. Similar to a standard Linux system, you can monitor the utilization of these resources using the show process usage summary, show memory usage and show disk usage commands.

op> show process usage summary
Name             PID         VIRT              Resident Memory       Sharable Memory     CPU Percentage   Memory Percentage   CPU Affinity
op> show process usage summary
Name                    PID    Virtual Memory   Resident Memory     Shared Memory     CPU %     Mem %  CPU Core
confd                   122         99.35 MiB         73.72 MiB         20.75 MiB      1.05      0.47  0-3
etcd                    106         52.15 MiB         38.52 MiB         14.30 MiB      0.00      0.25  0-3
fibd                    351         10.68 GiB        863.85 MiB         29.35 MiB     18.26      5.50  0-3
ifmd                    316        201.41 MiB         44.48 MiB         14.57 MiB      0.00      0.28  0-3
lldpd                   287         53.34 MiB         38.65 MiB         14.68 MiB      0.00      0.25  0-3
...
<output omitted>

op> show memory usage
Name     Total            Used             Free         Shared       Buffers      Cached
RAM      31.39 GiB        2.48 GiB         27.94 GiB    100.74 MiB   0 bytes      980.73 MiB
SWAP     0 bytes          0 bytes          0 bytes      n/a          n/a          n/a

op> show disk usage
Filesystem               Type             Size         Used         Available    Mountpoint          Usage %
none                     tmpfs            492 KiB      4 KiB        488 KiB      /dev                0.81
tmpfs                    tmpfs            15.69 GiB    16.25 MiB    15.68 GiB    /run                0.1
/dev/sda4                ext4             40.06 GiB    24.22 GiB    13.77 GiB    /shm                63.75
tmpfs                    tmpfs            15.69 GiB    19.49 MiB    15.67 GiB    /dev/shm            0.12
tmpfs                    tmpfs            5 MiB        0 bytes      5 MiB        /run/lock           0.0
udev                     devtmpfs         15.64 GiB    0 bytes      15.64 GiB    /dev/net/tun        0.0
tmpfs                    tmpfs            3.14 GiB     0 bytes      3.14 GiB     /run/user/1000      0.0
/var/cache/rtbrick/imag  overlay          40.06 GiB    24.22 GiB    13.77 GiB    /                   63.75

If you suspect any environmental issues, the system allows you to display information about some of the hardware components including power supplies, fans, and temperature using the show sensor power-supply | fan | temperature command. It is also possible to view information about interface plugins using the show optics inventory command.

The lab setup is based on virtual RBFS nodes, which do not provide any hardware related information, i.e., executing commands like show sensor power-supply detail or show optics inventory will produce no output.

Basic Configuration

In order to modify the configuration of the system, we need to enter the configuration mode. After starting the CLI, the operational mode is used by default. The mode is also part of the command prompt, so when switching from one mode to another you can see how the prompt changes:

op> switch-mode config
Activating syntax mode : cfg [config]
cfg>

INFO: In addition to operational and config mode, RBFS also has a debug mode, which allows you to execute troubleshooting or debugging operations.

The configuration is prodefined and stored in JSON format, and is defined by a YANG data model. Configuration changes can be applied manually using the CLI or via the RESTCONF interface.
The system maintains two configuration databases:

  • Running configuration which is currently used by the system

  • Candidate configuration which contains changes that are not yet activated

Running Configuration

The running configuration can be displayed using the show config command.

cfg> show config
## Last commit : 2026-06-26T11:10:13.776158+0000 by anonymous
{
  "ietf-restconf:data": {
    "rtbrick-config:system": {
      "load-last-config": "true"
    },
    "rtbrick-config:interface": [
      {
        "name": "hostif-0/0/0",
        "host-if": "R1-SN-0"
      },
      {
        "name": "hostif-0/0/1",
        "host-if": "R1-R2-0"
      },
      {
        "name": "hostif-0/0/11",
        "host-if": "R1-R2-1"
      },
      {
        "name": "hostif-0/0/2",
        "host-if": "R1-R3-0"
      },
      {
        "name": "hostif-0/0/4",
        "host-if": "R1-SN-1"
      }
    ]
  }
}

The RBFS system is able to convert and output the configuration in other formats, for example in NETCONF format or set format. The set syntax is also used to modify the configuration. The show config command provides the possibility to restrict the configuration output to a certain area, e.g., if you are only interested in a specific interface configuration you can use

cfg> show config interface hostif-0/0/2
{
  "rtbrick-config:interface": [
    {
      "name": "hostif-0/0/2",
      "host-if": "R1-R3-0"
    }
  ]
}

or in set format

cfg> show config set interface hostif-0/0/2
set interface hostif-0/0/2
set interface hostif-0/0/2 host-if R1-R3-0

Candidate Configuration

Adding and removing configuration statements is done by the set and delete commands.

Exercise 5: Configuring LLDP Descriptions

We have already seen that a RBFS system automatically establishes LLDP neighborship by default. Additional LLDP parameters can be configured using the set lldp command hierarchy. Configure an LLDP system-description as well as port-description for each interface.

Also set the element-name to R1 using the set system host command syntax.

Then, use show config lldp to check. Did the configuration really change?

Click to reveal the answer 
set system host element-name R1
set lldp system-description "Virtual Switch R1"
set lldp interface hostif-0/0/1 port-description "Link to R2, hostif-0/0/1"
set lldp interface hostif-0/0/2 port-description "Link to R3, hostif-0/0/2"
set lldp interface hostif-0/0/11 port-description "Link to R2, hostif-0/0/11"

We can now check if the configuration has changed with show config lldp

show config lldp
The configuration has not changed at all, because the configuration changes are made to the candidate configuration, while the show config command displays the running configuration.

We have already mentioned that configuration changes are not automatically activated. They are stored in the candidate configuration. Before we activate the configuration changes, let’s have a look at the changes first:

cfg> show diff
     "rtbrick-config:system": {
-      "load-last-config": "true"
+      "load-last-config": "true",
+      "host": {
+        "element-name": "R1"
+      }
     },
       }
-    ]
+    ],
+    "rtbrick-config:lldp": {
+      "system-description": "Virtual Switch R1",
+      "interface": [
+        {
+          "interface-name": "hostif-0/0/1",
+          "port-description": "Link to R2, hostif-0/0/1"
+        },
+        {
+          "interface-name": "hostif-0/0/11",
+          "port-description": "Link to R2, hostif-0/0/11"
+        },
+        {
+          "interface-name": "hostif-0/0/2",
+          "port-description": "Link to R3, hostif-0/0/2"
+        }
+      ]
+    }
   }

The show diff [set] command provides a summary of all the changes that have not been activated yet. The plus-sign indicates the configuration lines that have been added, while the minus-sign indicates the lines which have been removed. The command commit activates the configuration and updates the running configuration:

cfg> commit
cfg> show diff

As you can see from the output, after committing the configuration there is no difference between running and candidate configuration anymore. The RBFS system stores the previous configurations making it easier to return to a previous configuration in case the current configuration is faulty. You can view a commit history with the command:

cfg> show commit log
Rollback ID     User Name      Timestamp                           Commit Message
0               anonymous      2026-06-26T11:10:13.776158+0000     No commit message
1               anonymous      2026-06-26T11:07:50.509670+0000     No commit message
2               clixon         2026-06-26T11:07:38.593680+0000     Boot up commit
<...>

The rollback ID 0 refers to currently running configuration. If you want to revert to an older version, you can use the rollback <id> command, e.g.,

cfg> rollback 1

If you have made some configuration changes, but decide that you do not want to commit them, then you can reset the candidate configuration to the running configuration with the discard command.

By default, the system configuration is not preserved on reboot. In order to use the last committed configuration after a reboot, the option set system load-last-config true needs to be configured.

Write and Read Configuration To/From Files

Sometimes it is useful to store the configuration in a file. In RBFS, the save command command performs this task:

cfg> save config myconfig.json
The configuration is always stored in json format. In addition, only the running configuration is stored, not the candidate configuration.

If you want to use a previously stored configuration, you can load it into the system with the load config command:

cfg> load config myconfig.json replace
The configuration is loaded into the candidate configuration, i.e., it must be explicitly committed. There are two options how to load a configuration: replace (override the existing running configuration with this one) and merge (add the configuration from the file to the existing configuration).

License Management

A RBFS license allows you to access the full functionality of your system. RtBrick provides a 28-day evaluation license on request. However, It is not allowed to be used evaluation licenses in production. Without any license installed on your system, you can evaluate RBFS for 7 days.

cfg> show system license
No license found

In order to install a permanent or subscription license, the set system license command is used.

Exercise 6: Configuring System License

Configure the license that was provided to you by RtBrick on your node.

Click to reveal the answer 
cfg> set system license <...>
cfg> show system license
License Validity:
  License index 1:
    Start date : Tue Feb 28 09:44:27 GMT +0000 2023
    End date   : Mon Mar 04 09:44:27 GMT +0000 2024

Summary

If you have completed the exercise, you can check the results by executing

student@tour:~/trainings_resources/robot$ robot basics/basics_verify.robot