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
  • /etc/ssh
  • /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.

Apply state

The cMAG-c has the following data stores:

  • running data store – contains the intended configuration
  • state data store – contains the applied configuration

The system typically applies configuration changes immediately, resulting in the running and state data store being identical. However, specific cases may prevent immediate application, causing long-lasting discrepancies between the intended and applied configurations.

Use the apply-state state to display the current apply state of the configuration node.

Only specific parts of the cMAG-c configuration have an apply state; see the cMAG-c CLI and Data Model Explorer for more information.

Discrepancy caused by the removal of an ODSA pool prefix

When an ODSA pool prefix is removed from the running data store, but existing sessions use addresses from that prefix, the prefix remains present in the state data store with to-be-removed as the apply-state. When there are no sessions anymore that use addresses from the prefix, the prefix is removed from the state data store.

SSH server

The host keys of the cMAG-c SSH server persist across management pod restarts. To rotate the host key:
  1. Delete the key files with the ssh_host prefix located in the /etc/ssh and /data/ssh folders.
  2. Restart the management pod.

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

Events and logging

The cMAG-c logs events to the following locations:
  • management pod
  • stdout of a specific pod

The log messages can be processed via the management pod.

Use the following CLI to inspect the log messages on a specific pod.
kubectl -n cmag-c log pod-name

Use CLI in the /system/logging context to configure logging on the management pod, similar to SR Linux.

The cMAG-c differs from SR Linux in that it supports:

  • no local persistence logging
  • only memory buffer and remote server for logging destinations
  • no persistent leaf in the buffer node
  • only RSYSLOG_FileFormat for the format of the memory buffer