cMAG-c management

The cMAG-c management features are built on top of SR Linux management with some exceptions and differences from SR Linux.

The cMAG-c management features are built on top of SR Linux management, implemented via the management pod. Key features include:

  • CLI
  • SSH server
  • NETCONF using YANG
  • user management with AAA
The cMAG-c management features are identical to those of SR Linux with the following exceptions:
  • Not all SR Linux management features are supported on the cMAG-c. See the cMAG-c Release Notes for a detailed list of supported features.
    Note: See the SR Linux Configuration Basics Guide and the SR Linux System Management Guide for information about the supported SR Linux management features.
  • Specific aspects of the cMAG-c management features differ from SR Linux. See cMAG-c-specific system management for descriptions of these differences.

cMAG-c-specific system management

Specific aspects of cMAG-c management features differ from SR Linux.

Persistent Storage

The cMAG-c management features are implemented in a management pod that is run in Kubernetes. Therefore, file changes in the pod are not persistent unless they are stored, for example, with a persistent volume claim (PVC). The following folders provide persistent storage:
  • /etc/opt/srlinux
  • /python

External client to reach the management server

The cMAG-c is a cloud-native application running on top of Kubernetes. As a result, SR Linux network instance and source address configurations do not apply to the cMAG-c. The external-facing listening addresses and ports of all management servers, including SSH and gNMI servers, are provisioned through the Kubernetes services. See the cMAG-c Installation Guide for more information.

User type

SR Linux supports the following management user types:

  • local user
  • remote user
  • Linux user

The cMAG-c does not support the Linux user type.

System time

The cMAG-c is a distributed system consisting of multiple pods that can run on multiple Kubernetes workers. To ensure correct operation, synchronized and consistent time is required across the Kubernetes nodes and pods.

Nokia recommends the following practices:
  • Synchronize the time of all nodes in the Kubernetes cluster using NTP.
  • Use the UTC time for nodes and pods.

System name

Use the following cMAG-c CLI to configure the system name for the cMAG-c, instead of the system name command for SR Linux.

 subscriber-management system name