RBFS Command Line Interface

RBFS CLI Overview

RBFS command line interface is a primary user interface that enables you to interact with RBFS for monitoring, configuring, debugging, and maintaining the system. RBFS command line interface, that runs on top of the Ubuntu shell, provides a rich set of commands which allow you to execute various operations on the system.

RBFS CLI commands are organized in hierarchies based on their functionalities. Commands, which are used to execute the same type of functions, have the same hierarchy. For example, to display information, you can use commands that start with 'show'. Delete command, in RBFS, is used to remove an existing configuration.

The RBFS command-line interface has three modes: Configuration mode, Operation mode, and Debug mode.

Operational mode: This is the default mode of RBFS command line interface. Operational mode allows you to execute the operational commands such as show commands to view or monitor various system configuration and its current state.

Configuration mode: Configuration mode allows to execute various configurations for services or features. It also allows you to view the information for the existing configurations.

Debug mode: It allows you to execute troubleshooting or debugging operations in the RBFS system.

Using the CLI

The following are some of the utilities which help you working with the CLI faster and easier.

Complete Partially Typed Commands:

You can press Tab key to complete a partially typed command. It helps you work with commands faster.

Command Options and Description:

If you do not know the options available for a command and the purposes of the options, you can enter the question mark symbol (?). It displays all the available command options and descriptions for that commands.

In any of the modes, if you type the question mark symbol (?), the CLI displays a set of commands which can be executed in that particular mode.

When you execute configurations through CtrlD, and then with the Command Line Interface, it results in error when you commit the configuration through the CLI. The reason is that CtrlD directly interacts with the backend applications (BDS and CONFD) and these changes are not synced with the CLI.

Launching the RBFS CLI

The following example shows how to start the RBFS CLI.

supervisor@rtbrick>LEAF01:~$ cli
supervisor@rtbrick>LEAF01: op>
'op>' shows you are in operational mode.

CLI Prompt

The RBFS CLI prompt reflects the static hostname and host OS hostname. In RBFS, the static hostname is the container name and the dynamic hostname is derived from DHCP.

The format of the RBFS CLI prompt is as follows:

<username> @ <static_hostname> > <hostname.host-os>: <mode>

Example:

supervisor@rtbrick>LEAF01: op>

Switching CLI Modes

RBFS CLI has three modes: Configuration mode, Operation mode, and Debug mode.

You can enter switch-mode command to change the CLI mode.

For example, enter switch-mode config to switch to configuration mode.

The following example shows how to switch between modes.

supervisor@rtbrick>LEAF01: op> switch-mode
    config                Enter a given mode
    debug                 Enter a given mode
    operation             Enter a given mode

The following example shows how to switch from the operation mode to the config mode.

supervisor@rtbrick>LEAF01: op> switch-mode config
supervisor@rtbrick>LEAF01: cfg>

Turning Paging On/Off

To turn the paging on or off, use the following command:

paging [on | off]

  • off - Pagination will be turned off for the commands that span more than screen length

  • on - Pagination will be turned on for the commands that span more than screen length

Example:

supervisor@rtbrick>LEAF01: cfg>  paging on

Turning On or Off CLI Colors

To enable or disable the colors in the CLI output, use the following command:

color [on | off]

Example:

supervisor@rtbrick>LEAF01: cfg> color on

Accessing CLI Logs

RBFS supports sending command history log messages to Graylog, a log management software that enables real-time analysis of log messages.

The command history logs help you to understand which user has executed a specific command across multiple CLI sessions.

The log format for CLI command history logs is: User '%s' executed command '%s'.

System logging is implemented for RESTCONF.

For RESTCONF error logs, do not set the log level to 'info'. If you set the log level to info, logs are generated for all the restconfd requests.

Basic CLI Features

Viewing CLI Tree

The show cli tree command displays all RBFS CLI commands and command options that exist.

  • show cli tree: This command provides you the list of all RBFS CLI commands and options that are available.

  • show cli tree detail: The detail option for the command displays additional information such as minimum and maximum values allowed.

Viewing Command History

The history command enables you to view the previously executed commands. You can execute the command in any of the CLI modes.

history

Example:

supervisor@rtbrick>LEAF01: op> history
show config set
exit
show config set
load config test.json
load config obj.json
show config set
exit
show config set
load config test.json
switch-mode config
load config test.json
load config obj.json
exit
switch-mode config
show config set
load config test.josn
load config obj
load config obj.json
exit
show config set
load config obj.json
load config test.json
exit
show bd running-status
load config test.json
show config set
exit
show bd running-status
exi
show datastore confd table test index index2
exit

Setting Configuration Parameters

The set command is used to configure parameters.

supervisor@rtbrick: cfg> set system ntp server MyNTPServer ipv4-address 10.1.1.100

Deleting Configuration Parameters

The delete command is used to remove existing configuration parameters.

supervisor@rtbrick: cfg> delete system ntp server MyNTPServer ipv4-address 10.1.1.100

Viewing Core Dump Files

When a router crashes, it is useful to obtain a complete copy of the memory image, also known as core dump, to identify the cause of the crash.

The show core-dump stack-trace command displays core dump data generated by the system. It includes information such as Core Dump File Name, Process Name/ID, Time of Core Dump, Core Dump Size, Signal Information, Process State, and so on.

You can use the command in the following ways:

  • show core-dump lists the core dump files.

  • show core-dump stack-trace displays all the stack traces (list of the function calls) for all valid core files.

  • show core-dump stack-trace <file-name> displays the stack traces for a specified file.

  • show core-dump stack-trace <file-name> per-thread displays stack trace for all threads for the specified file.

  • Use the clear core-dump to clear output populated.

Viewing Hardware Resource Usage Limit Information

In RBFS, you can view the hardware resource usage limit details.

Run the following command:

show hardware limits

Example:

supervisor@rtbrick>rtbrick.net: op> show hardware limits
Hardware resources:
  Module: fib
    ASIC                            : q2c
    Role                            : accessleaf
    Model                           : agcva48s
    IPv4 route count                : 1200000
    IPv6 route count                : 250000
  Module: fib
    ASIC                            : q2c
    Role                            : accessleaf
    Model                           : as7946-74xkb
    IPv4 route count                : 1200000
    IPv6 route count                : 250000
  Module: fib
    ASIC                            : q2c
    Role                            : accessleaf
    Model                           : as7946-30xb
    IPv4 route count                : 1200000
    IPv6 route count                : 250000
  Module: fib
    ASIC                            : q2c
    Role                            : accessleaf
    Model                           : s9600-72xc
    IPv4 route count                : 1200000
    IPv6 route count                : 250000
  Module: bgp
    ASIC                            : q2c
    6PE label                       : 2
  Module: confd
    ASIC                            : q2c
    Max MTU profile                 : 8
    Max L3 MTU profile              : 3
    Max subscriber MTU profile      : 6
    Max physical MTU profile        : 8
  Module: rd
    ASIC                            : q2c

Rebooting Containers and Hosts

The reboot command allows you to restart containers and hosts.

reboot <option>

Option Description

-

Without any option, this command allows you to reboot a container (default). You are prompted to confirm rebooting the container when you enter this command. You must answer yes or no.

container

This command allows you to reboot a container. You are prompted to confirm rebooting the container when you enter this command. You must answer yes or no.

container-and-confirm

This command reboots the container without prompting yes/no.

device

This command allows you to reboot a device. You are prompted to confirm rebooting the device when you enter this command. You must answer yes or no.

device-and-confirm

This command reboots the device without prompting yes/no.

Example:

supervisor@rtbrick>LEAF01: cfg> reboot container

Viewing System Version Details

To display the version details of RBFS and its various components, use the show version command.

show version

Example:

supervisor@ixr_pe1>srv3.nbg1.rtbrick.net: op> show version
UUID        : 2abb4250-2a14-4e5c-84e2-6785eee158f8
Version     : 22.6.0-g4internal.20220620060710+Bfs0000bgpauthlatest.C3abc099d
Role        : spine
Platform    : virtual
Format      : lxd
Build date  : 2022-06-20 06:07:10 UTC
Component                         Version                                                  Timestamp                  Branch
alertmanager                      0.20.1001-internal.20220613124702+Bdevelopment....       2022-06-07 20:01:29        development
cligen                            0.1.0-internal.20220613140225+Bdevelopment.C9457c97b     2022-06-07 20:00:33        development
clixon                            4.3.1-internal.20220618124913+Bdevelopment.C85593b60     2022-06-13 11:48:32        development
<...>

Viewing Date and Time

To display system date and time, use the date command.

date

Example:

supervisor@rtbrick>LEAF01: op> date
Thu Apr 28 09:56:32 UTC 2022

Viewing the Running configuration

To display the running configurations, enter the show config command.

Example:

supervisor@rtbrick>LEAF01: cfg> show config

Viewing a Specific Hierarchy

To display the configurations under a specific hierarchy, enter the show config <hierarchy> command.

supervisor@rtbrick: cfg> show config ?
  access                Global access configuration
  daemon-options        List of daemon options
  global                Global configurations
  instance              Network instance configuration
  <...>

Viewing Configurations in a Specific Format

The show config command displays the current committed configurations of the system. By default, this command displays the configurations in a json format.

show config <format>

You can also specify the format explicitly, if needed. The available display formats are:

  • json: Display configurations in JSON format

  • set: Display configurations in CLI format (similar to commands executed)

  • netconf: Display configurations in XML format

  • text: Display configurations in textual format (similar to YANG definition)

The following example shows how configurations are displayed in the text format.

supervisor@rtbrick>LEAF01: op> show config text
daemon-options {
    instance-name *;
    afi *;
    safi *;
    bd-type bgp.appd;
    bd-name bgp.appd.1;
}
daemon-options {
    instance-name *;
    afi *;
    safi *;
    bd-type bgp.iod;
    bd-name bgp.iod.1;
}
interface {
    name lo-0/0/0;
    unit {
        unit-id 0;
        address {
            ipv4 {
                prefix4 198.51.100.75/24;
            }
            ipv6 {
                prefix6 2001:db8:0:110::/32;
            }
        }
    }
}
<...>

To view configurations in the set format, use the show config set command.

Example:

supervisor@rtbrick>LEAF01: cfg>  show config set
set interface ifp-0/0/1
set interface ifp-0/0/1 ifp-id 1
set interface ifp-0/0/2
set interface ifp-0/0/2 ifp-id 2
set instance blue
set instance blue protocol bgp address-family ipv4 multicast
set instance blue protocol bgp address-family ipv6 unicast
set instance red
set instance red protocol bgp address-family ipv4 unicast
set instance red protocol bgp address-family ipv6 unicast

Viewing Configuration in a Specified Hierarchy

To view configuration in a specified hierarchy, use the following command:

supervisor@rtbrick>LEAF01: cfg> show config set instance red protocol bgp
set instance red protocol bgp address-family ipv4 unicast
set instance red protocol bgp address-family ipv6 unicast

Committing CLI Configurations

To apply the configurations, use the commit command.

The following example shows how to commit your changes using the commit command.

supervisor@rtbrick>LEAF01:~$ cli
supervisor@rtbrick>LEAF01: op> switch-mode config
supervisor@rtbrick>LEAF01: cfg> <cli command goes here>
supervisor@rtbrick>LEAF01: cfg> commit

When you exit CLI configuration with uncommitted changes, a reminder text appears saying that you have changes to commit, as shown in the following example:

supervisor@rtbrick>LEAF01: cfg> exit
Uncommitted changes are present
1. Discard the changes and exit
2. Commit the changes and exit
3. Keep the changes and exit [Default behavior]
Enter one of the above choice to proceed :

Viewing Uncommitted Changes

To view the uncommitted changes, use the show diff command. The show diff command displays output in JSON format, whereas the the show diff set command displays the output in CLI format.

supervisor@rtbrick>LEAF01: cfg> show diff

supervisor@rtbrick>LEAF01: cfg> set interface ifp-0/0/3 ifp-id 3
supervisor@rtbrick>LEAF01: cfg> set interface ifp-0/0/4 ifp-id 4
supervisor@rtbrick>LEAF01: cfg> show diff set
+set interface ifp-0/0/3
+set interface ifp-0/0/3 ifp-id 3
+set interface ifp-0/0/4
+set interface ifp-0/0/4 ifp-id 4
supervisor@rtbrick>LEAF01: cfg> show diff
 }
+interface {
+    name ifp-0/0/3;
+    ifp-id 3;
+}
+interface {
+    name ifp-0/0/4;
+    ifp-id 4;
+}
 instance {

Adding a Configuration Description

An in-line description or comment can be added to a system configuration to describe it.

set system config-description <description>

Example:

supervisor@rtbrick>LEAF01: cfg> set system config-description "This is sample test configuration"
supervisor@rtbrick>LEAF01: cfg> commit
supervisor@rtbrick>LEAF01: cfg> show config
{
  "ietf-restconf:data": {
    "rtbrick-config:system": {
      "config-description": "This is sample test configuration"
    }
  }

Saving Configuration

To save configurations, enter the following command:

supervisor@rtbrick>LEAF01: cfg> save config my_config.json

  • Ensure that you use .json at the end of the filename.

  • The configuration will be saved to the current working directory of CLI executable.

Deleting the Entire Running Configuration

The discard command is used to discard configuration changes. To delete the entire running configurations (both committed and uncommitted configurations) at a time, use the discard all command.

Example:

supervisor@rtbrick>LEAF01: cfg> discard all

Discarding the Uncommitted Configuration

To discard the uncommitted configuration, enter the following command:

supervisor@rtbrick>LEAF01: cfg> discard

Viewing the Configuration Differences in the Current and Previous Versions

In RBFS, you can view the configuration differences between the current and the previous versions.

show diff <number>

supervisor@rtbrick>LEAF01: cfg> show diff 2
 system {
-    secure-management-status false;
+    secure-management-status true;
 }

Rolling Back to a Previously Committed Configuration

To rollback to a specific configuration prior to the most recently committed one, use the following command:

rollback <number>

number: Specifies the rollback ID. Range: 1 through 49. 0 refers to the active configuration, 1 refers to the most recent previous configuration. Default: 1

For example, to rollback to rollback ID 2, use the following command:

supervisor@rtbrick>LEAF01: cfg> rollback 2

Rolling Back to a Specific Version of Software Configuration

To rollback to a specific version of the software configuration, use the following command:

rollback commit-id <commit-hash>

Example:

supervisor@rtbrick>LEAF01: cfg> rollback commit-id 29d5db038c1920fdsdsdsdsdsd323232

Loading Configuration

To load configurations, enter the following command:

load config <filename> <option>

The options include merge and replace. You can specify merge after the file name to merge the configuration with the running configuration. Specify replace to replace the running configuration with the new one. Without any option, it replaces the running configuration, by default.

supervisor@rtbrick>LEAF01: cfg>  load config <filename>

  • Ensure that you use '.json' at the end of the filename.

  • Remember to commit your changes after loading.

Viewing Routes

The show route command displays information of routes.

Syntax:

show route <options>

Attribute Description

-

Without any option, the command displays the information for all routes for all modules.

detail

Shows detailed route information.

instance <name>

Routing table information for a specified instance.

ipv4

Shows route information for the IPv4 routing table.

ipv6

Shows route information for the IPv6 routing table.

mpls

Shows route information for the MPLS routing table.

label <value>

Shows route information for a specified destination label.

prefix <value>

Shows route information for a specified destination prefix.

prefix-length-distribution

Shows the number of routes with the same prefix length for the sources.

source

Shows routes from a specified source.

summary

Shows the number of routes selected by RIBD for each source.

Example 1: Route information

supervisor@rtbrick>LEAF01: op> show route
Instance: default, AFI: ipv4, SAFI: unicast
Prefix/Label        Source            Pref    Next Hop                Interface
11.0.0.1/32         arp-nd            6       11.0.0.1                hostif-0/0/4/1
12.1.0.0/24         ospf              10      23.0.0.2                hostif-0/0/0/1
23.0.0.0/24         direct            0       23.0.0.0                hostif-0/0/0/1
25.0.1.0/24         ospf              10      23.0.0.2                hostif-0/0/0/1
25.1.1.0/24         ospf              10      23.0.0.2                hostif-0/0/0/1
34.0.3.3/32         direct            0       34.0.3.3                hostif-0/0/2/1
56.0.1.4/30         ospf              10      23.0.0.2                hostif-0/0/0/1
56.0.2.0/31         ospf              10      34.0.2.4                hostif-0/0/1/1

Example 2: Route summary

supervisor@rtbrick>LEAF01: cfg> show route summary
Instance: default
  Source                 Routes
  bgp                         2
  direct                      4
  Total Routes                6
Instance: ip2vrf
  Source                 Routes
  bgp                         6
  direct                      2
  Total Routes                8
Instance: li-vrf
  Source                 Routes
  bgp                         4
  direct                      2
  Total Routes                6
Instance: mgmt-vrf
  Source                 Routes
  bgp                         2
  direct                      2
  Total Routes                4
Instance: radius-vrf
  Source                 Routes
  bgp                         5
  direct                      2
  Total Routes                7

Example 3: Routes with the same prefix length for IPv4

supervisor@rtbrick>LEAF01: cfg> show route prefix-length-distribution
Instance: default
  Prefix Length      Count
            /32          2
           /128          4
            Sum          6
Instance: ip2vrf
  Prefix Length      Count
             /0          2
            /24          1
            /32          2
            /64          1
           /128          2
            Sum          8
Instance: li-vrf
  Prefix Length      Count
             /0          2
            /32          2
           /128          2
            Sum          6
Instance: mgmt-vrf
  Prefix Length      Count
            /32          2
           /128          2
            Sum          4
Instance: radius-vrf
  Prefix Length      Count
             /0          2
            /24          1
            /32          2
           /128          2
            Sum          7

Viewing Route Resolution

The show route-resolution command displays the routes which were requested to be resolved for their nexthops. Otherwise, it shows the route is unresolved. Syntax:

show route-resolution <options>

- Without any option, the command displays the information for all requests and response tables side by side.

destination-instance

Displays the information for all requests and response for a destination instance.

look-up instance

Displays lookup instance routes.

prefix

Displays routes for prefix 4 or prefix 6.

resolved

Displays resolved routes.

source

Displays source of requested source.

unresolved

Displays unresolved routes.

Example:

supervisor@L1-STD-2-2008>bm08-tst.hel.rtbrick.net: op> show route-resolution
192:1::1, Source: bgp
  Destination instance: default, AFI: ipv4, SAFI: vpn-unicast
  Lookup      instance: default, AFI: ipv6, SAFI: labeled-unicast
  Covering Prefix: 192:1::1/128
    Interface        MAC Address         Nexthop
    hostif-0/0/1/10  7a:11:21:c0:00:03   fe80::7811:21ff:fec0:3
192:1::1, Source: bgp
  Destination instance: default, AFI: ipv4, SAFI: vpn-multicast
  Lookup      instance: default, AFI: ipv6, SAFI: labeled-unicast
  Covering Prefix: 192:1::1/128
    Interface        MAC Address         Nexthop
    hostif-0/0/1/10  7a:11:21:c0:00:03   fe80::7811:21ff:fec0:3
    <...>

Example:

supervisor@rtbrick>ufi07.q2c.u21.r4.nbg.rtbrick.net: cfg> show route-resolution unresolved
192.168.16.128, Source: radius
  Lookup      instance: inband_mgmt, AFI: ipv4, SAFI: unicast
  Covering Prefix: None, 7 resolution attempts
198.18.73.251, Source: pim
  Lookup      instance: ip2, AFI: ipv4, SAFI: unicast
  Covering Prefix: None, 7 resolution attempts

Managing RBFS Services

Brick Daemons

RBFS microservices architecture allows daemons to serve various complementary functions and provide services.

For example, the subscriber daemon (subscriberd) manages the current subscriber state and is responsible for authentication, authorization, and accounting. The ribd daemon is responsible for route selection, next-hop resolution, tunnel selection and recursion.

There are daemons such as CtrlD (Controller) and ApiGwD (API Gateway) which are part of the RBFS ecosystem. These daemons sit in the middle (on the ONL) and manage all the communication between the client and backend services running in the container. The API Gateway (ApiGwD) daemon provides a single point access to expose services running inside of the RBFS container.

RBFS daemons and other dependencies are packaged as an Ubuntu LXC container. The RBFS container is hosted on the Open Network Linux (ONL), an open-source operating system, which can be run on white box switches.

RBFS can perform various roles such as Spine, Leaf, and Consolidated BNG which serve different use-cases. The software images of these various roles contain daemons that are required to serve these roles for their different functions. The RBFS Consolidated BNG software image contains all the RBFS daemons packaged in a container, other roles such as Spine and Leaf include only the daemons which are required to carry out their respective functions.

For example, the Spine RBFS image includes (in addition to other daemons) the interior gateway protocol daemons such as isis.appd, isis.iod, ospf.appd, and ospf.iod which are not required in the Access Leaf image.

Similarly, the Access Leaf image should include daemons (in addition to other daemons) such as subscriberd, l2tpd, pppoed, and ipoed which are not present in the Spine image.

The daemons such as alertmanager, confd, etcd, fibd, hostconfd, ifmd and so on are present in the images of both the Spine and Leaf roles as these daemons are required in both of these roles.

Launching Microservices Dynamically

When the RBFS container starts up, it starts only relevant microservices depending on the image role and platform. This is done to minimize unnecessary resource consumption. In RBFS, there are base microservices and on-demand microservices. RBFS containers will have all microservices installed according to the platform and image role, but not all will be enabled on bootup. Only the base microservices will be enabled and started on bootup. On-demand microservices will only be started when their respective configurations are configured and will stop once all dependent configurations are deleted.

For instance, when the user configures BGP with the CLI command set instance <instance> protocol bgp local-as <as-number>, the rtbrick-bgp.appd.1 and rtbrick-bgp.iod.1 services will start. And, once the BGP configuration is deleted, "rtbrick-bgp.appd.1" and "rtbrick-bgp.iod.1" will be stopped after 5 minutes (graceful shutdown time).

By default, the following base microservices will be running in the container.

  • rtbrick-confd

  • rtbrick-etcd

  • rtbrick-fibd

  • rtbrick-hostconfd

  • rtbrick-ifmd

  • rtbrick-lldpd

  • rtbrick-mribd

  • rtbrick-opsd

  • rtbrick-poold

  • rtbrick-resmond

  • rtbrick-resmond-agent

  • rtbrick-restconfd

  • rtbrick-ribd

  • rtbrick-staticd

When you make other RBFS configurations, the required on-demand microservices will be automatically enabled.

Listing All Available Services

To list all available RBFS services, enter the following command:

sudo systemctl list-unit-files | grep "rtbrick-"

Starting or Stopping the Services

To start or stop a specific RBFS service, enter the following command:

sudo service <service> start|stop

Restarting a Service

To restart a specific RBFS service, enter the following command:

sudo service <service> restart

Example:

supervisor@onl>C-BNG.rtbrick.net:~ $ sudo service rtbrick-ctrld restart

  • In the unlikely event of a failure in a daemon, the service will restart automatically.

  • If a service has restarted too frequently within a short period, it may be blocked by the system to prevent further instability. In such cases, the service can be unblocked by resetting its failure state with the sudo systemctl reset-failed <service> command. This ensures that the service is no longer considered “failed” by the system and can be managed normally again. Including this information in the documentation will help users manage and troubleshoot their RBFS services effectively, ensuring smoother operations and reducing downtime caused by blocked or unstable services.

Verifying the Status of a Service

To verify the status of a RBFS Service, enter the following command:

sudo service <service> status

For example, to check the status of the rtbrick-pppoed.1 service, enter the following command:

supervisor@onl>C-BNG.rtbrick.net:~ $ sudo service rtbrick-pppoed.1 status

Removing the Committed/Uncommitted Configuration

To discard the both committed and uncommitted configurations, enter the following command:

supervisor@rtbrick>LEAF01: cfg> discard all
Carefully use the discard all command because it will remove your committed configurations.

Supported Platforms

Not all features are necessarily supported on each hardware platform. Refer to the Platform Guide for the features and the sub-features that are or are not supported by each platform.