Platform Overview

The RtBrick FullStack (RBFS) software runs as a LXC container on a Linux host operating system in the bare-metal switches, which are capable of Layer 2 and Layer 3 switching. Multiple switches can be combined to support several subscribers using a leaf and spine architecture or deployed as a standalone unit using the consolidated BNG approach. Additionally, the ZTP (Zero-Touch-Provisioning) and REST-based APIs that expose the state of the system are also supported.

The image below shows a high-level overview of the platform architecture.

platform overview

Platform hardware consists of forwarding ASICs and an Open Network Linux (ONL) operating system. A RBFS container that resides on top of this software includes all necessary packages to deliver access and routing protocols.

This guide looks at the platform features, the different supported hardware platforms, and features that are supported on each hardware platform.

Supported Platforms

RtBrick’s software has been validated on the following hardware platforms.

  • Edgecore CSR320 (AS7316-26XB)

  • Edgecore CSR440 (AS7535-28XB)

  • Edgecore AGR400 (AS7946-30XB)

  • Edgecore AGR420 (AS7946-74XKSB)

  • Delta AGCVA48S

  • UfiSpace S9510-28DC

  • UfiSpace S9500-22XST

  • UfiSpace S9600-32X

  • UfiSpace S9600-72XC

For a list of features and sub-features supported by each platform, see the [feature_support_matrix] section.

Guidelines and Limitations

QAX-based Platforms
  • An additional restriction applies to ports belonging to a port group on QAX-based platforms. For more information, see section "1.9. Guidelines & Limitations" of the Interfaces User Guide.

Brick Daemon (BD)

RBFS runs multiple Brick Daemons (BD). Every application that runs within RBFS is fundamentally a brick daemon. For example, forwarding daemon (fibd), configuration daemon (confd), BGP (bgp.iod or bgp.appd), or interface management daemon (ifmd).

Brick Daemon (BD) Restartability

If a brick daemon fails (for a limited number of times), RBFS will restart it automatically. If the automatic restart does not succeed, you can use the Ubuntu system control to start a daemon.

For more information about troubleshooting the Brick Daemons, see section "2.2. Brick Daemons" of the RBFS NOC Troubleshooting Guide.

CPU Watchdog Timer Utility for Hardware Platforms

The CPU watchdog timer utility is located in BMC helps to detect any CPU failure. It also enables the CPU to recover from faults. By default, Watchdog Timer functionality is in enabled state and it does not require any configuration from users. However, you can configure if you want to change the default settings.

Enable CPU Watchdog Timer in Hardware

Use the following command to enable watchdog timer on the hardware.

Syntax:

set system platform-management watchdog CPU <attribute> <value>

Attribute Description

action

Specifies the possible timeout actions:

  • hard-reset: A reset will take place based on the configured settings.

  • no-action: No action will be taken.

  • power-cycle: The watchdog timer will power cycle the device.

  • shutdown: The device will shut down per the configured setting.

Default value: power-cycle.

interval

Specifies the watchdog timer interval in seconds. Default value: 1800 seconds.

Example: Enable CPU Watchdog Timer

supervisor@rtbrick: op> show config system platform-management watchdog
{
    "rtbrick-config:watchdog": [
      {
        "type": "CPU",
        "action": "hard-reset",
        "interval": 3600
      }
    ]
  }
supervisor@rtbrick: op>

You can use the ipmitool utility to view the status of the CPU watchdog timer.

Log into the ONL and enter the command as shown below to validate CPU watchdog timer functionality.

supervisor@onl>rtbrick:~ $ sudo ipmitool mc watchdog get
Watchdog Timer Use:     OS Load (0x43)
Watchdog Timer Is:      Started/Running
Watchdog Timer Actions: Power Cycle (0x03)
Pre-timeout interval:   0 seconds
Timer Expiration Flags: 0x00
Initial Countdown:      1800 sec
Present Countdown:      1795 sec