Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Chassis Management Module (CMM)

    CMM Overview

    The Chassis Management Module (CMM) provides management and control of the chassis, and is responsible for the following functions:

    • Monitors, controls, and assures proper operation of the modules and other chassis components.
    • Watches over the basic health of the system, reports anomalies, and takes corrective action when needed.
    • Retrieves inventory information and sensor readings, as well as, receive event reports and failure notifications from the modules and field replaceable units (FRUs).
    • Performs basic recovery operations, such as, power cycle or reset of managed entities.
    • Provides low-level hardware management services to manage the power, cooling, and interconnect resources of a chassis.
    • Provides non-volatile storage of configuration data and software loads.
    • Enables operator control of all modules in the system.
    • Supports an industry-standard CLI, NETCONF, and SNMP.

    Figure 1: CMM Module

    CMM Module

    Table 1: CMM Ports

    Port

    Physical Interface

    Description

    Craft Serial (RS-232)

    RJ-45

    Provides local craft serial access for diagnostic and commissioning functions.

    Expansion (EXP-1 to EXP-3)

    RJ-45

    Provides management plane connectivity in a multichassis configuration.

    Management Ethernet (eth1)

    RJ-45

    Provides management network connectivity.

    Craft Ethernet (eth0)

    RJ-45

    Provides local craft Ethernet access for diagnostic and commissioning functions.

    USB-1

    USB 2.0 Standard Type-A Receptacle

    Provides the ability for the CMM to boot from a system repair drive.

    CMMs are typically deployed in pairs in a network element in an active/standby configuration. The active CMM performs all of the management and control functions in the system. If the active CMM fails, the standby CMM takes over and becomes the active CMM.

    A CMM can take on the following roles:

    CMM Role

    Description

    Active system controller module (SCM)

    The first CMM that comes up in a chassis is the active SCM. It performs all of the management and control functions in the system, and ensures that all modules (including the standby CMM) are loaded with the correct level of software. Therefore it is important that the first CMM in the chassis contain the software load that you want to run.

    Standby SCM

    The second CMM that comes up in a chassis becomes the standby SCM. The standby SCM automatically synchronizes with the active SCM so that the standby SCM can take over seamlessly if the active SCM fails. Configuration data, and operational data such as traffic module statistics, are mirrored on both SCMs.

    Management relay module (MRM)

    The role of the MRM applies to multichassis systems only. A multichassis system consists of a hub chassis and a satellite chassis. The CMMs in the hub chassis act as active and standby SCMs, similar to a single chassis system. The CMMs in the satellite chassis act as MRMs, relaying management commands and information between the active SCM in the hub chassis and the various modules in the satellite chassis. For more information on multichassis systems and MRMs, see Multichassis System Configuration.

    When using out-of-band management, both CMMs in a chassis should be physically connected to the management network. If the management Ethernet link to the active CMM fails, the standby CMM becomes the active CMM. In a multichassis system, only the SCMs (in the hub chassis) are connected to the management network.

    CMM Failure or Removal

    CMMs are typically deployed in pairs in a network element in an active/standby configuration. The active CMM performs the management and control functions in the system. If the active CMM fails or if the active CMM is removed or if the management Ethernet link to the active CMM goes down, the standby CMM takes over and becomes the active CMM. This is performed seamlessly without affecting traffic on the service modules.

    If both CMMs fail or if both CMMs are removed in a dual CMM system, or if the sole CMM fails or if the sole CMM is removed in a single CMM system, the behavior is as follows:

    • Management connectivity (CLI, SNMP, NETCONF) is lost.
    • Alarms are no longer raised and PM collection stops.
    • Chassis fans operate at full speed.
    • Modules subsequently inserted into the chassis will not boot up. This includes modules that you remove and reinsert.
    • Service is not affected.
      • In releases lower than 4.2, all service modules are warm reloaded and do not boot back up until the CMM recovers. Service modules continue to carry traffic but software-based features on the service modules (such as PM collection, APSD, APR, FPSD) are disabled until the service modules boot up.
      • Starting with release 4.2, service modules run normally and continue to carry traffic. Software-based features on the service modules (such as PM collection, APSD, APR, FPSD) continue to run normally.
    • If the CMM that went down comes back up, it performs a warm reload of all service modules. This ensures that the CMM is synchronized with the service modules and that the service modules are in a known state. Service is not affected. Software-based features on the service modules (such as PM collection, APSD, APR, FPSD) are disabled temporarily while the service module reloads.

    CMM Replacement

    CMM replacement differs depending on whether you are replacing a CMM in a dual CMM system or in a single CMM system.

    Note: You can always remove and reinsert a CMM with no impact to traffic as long as you reinsert the same CMM (that is, the same physical module with the same configuration).

    Always uncommission a CMM before removing it from a chassis. This way, the CMM is in an uncommissioned state and cannot assume control of a chassis until it is recommissioned. This guards against situations where a CMM is placed into storage and then later reused in the same chassis in which it was originally commissioned. In that situation, the CMM might assume control and impose its old database onto the chassis.

    Dual CMM System

    CMM replacement in a dual CMM system behaves as follows:

    • You can remove and replace the standby CMM with no impact to traffic. When you insert the replacement CMM, the replacement CMM automatically synchronizes with the active CMM.
    • You can remove and replace the active CMM with no impact to traffic. When you remove the active CMM, the standby CMM becomes the active CMM. When you subsequently insert the replacement CMM, the replacement CMM becomes the standby CMM and automatically synchronizes with the newly active CMM.

    Single CMM System

    When you replace the sole CMM in a chassis, the replacement CMM has no active CMM to synchronize with. Therefore, you will need to commission the replacement CMM.

    • If you previously backed up the configuration database, you can commission the replacement CMM to use the backed-up database, resulting in no impact to traffic:
      • A configuration database is specific to a software version. In order to restore a backed-up database onto a replacement CMM, you must ensure that the replacement CMM is running the same software version as the software version running when the backup was created.
      • In releases lower than 4.2, a configuration database is also specific to a chassis. You can only restore a backed-up database to a replacement CMM on a chassis if the database was backed up from that chassis. You cannot restore a database to a CMM on a chassis if the database was backed up from another chassis.

        Starting with release 4.2, this restriction is relaxed. You can restore a backed-up database to any chassis of the same chassis type (BTI7801 to BTI7801, BTI7802 to BTI7802, BTI7814 to BTI7814).

    • If you did not back up the configuration database and cannot do so now, you will need to commission the replacement CMM to use the factory-default configuration, which results in traffic loss and which requires subsequent reconfiguration.

      Note: On the BTI7801, you do not need to reset the database to factory defaults if you neglected to back up the database explicitly. The database is automatically backed up to local chassis storage at regular intervals.

    The existing configuration database residing on the replacement CMM is not used and does not take effect when you insert the replacement CMM into the chassis. The system checks to see if the CMM is commissioned for the chassis in which it is inserted. If it is not, you will need to commission the CMM before the replacement CMM can be used. During commissioning, the existing configuration database is erased. This prevents the CMM from changing configuration on all the modules and affecting services if you remove a CMM from one chassis and accidentally insert it into another chassis.

    Table 2 shows the different CMM replacement scenarios in single CMM systems.

    Table 2: CMM Replacement Scenarios in Single CMM Systems

    Replacement Scenario

    General Replacement Procedure

    The replacement CMM is running the same software load as the CMM being replaced, and a backed-up configuration database of the original CMM exists.

    Commission the CMM for this chassis.

    As part of commissioning, restore the configuration database from the original CMM. Once the CMM has been commissioned, it performs a warm reload of all service modules.

    Service is not affected but software-based features on the service modules (such as PM collection, APSD, APR, FPSD) are disabled temporarily. See CMM Failure or Removal.

    The replacement CMM is running a software load that is different from the software currently running on the chassis, and a backed-up configuration database of the original CMM exists.

    Install the software version that was running on the original CMM onto the replacement CMM.

    Commission the CMM for this chassis.

    As part of commissioning, restore the configuration database from the original CMM. Once the CMM has been commissioned, it performs a warm reload of all service modules.

    Service is not affected but software-based features on the service modules (such as PM collection, APSD, APR, FPSD) are disabled temporarily. See CMM Failure or Removal.

    Any replacement situation where a backed-up configuration database of the original CMM does not exist.

    Since the configuration cannot be restored, all configuration is lost and service is affected.

    For the detailed CMM replacement procedure, see Replacing the CMM in a Single CMM System.

    Release History Table

    Release
    Description
    Starting with release 4.2, service modules run normally and continue to carry traffic. Software-based features on the service modules (such as PM collection, APSD, APR, FPSD) continue to run normally.
    Starting with release 4.2, this restriction is relaxed. You can restore a backed-up database to any chassis of the same chassis type (BTI7801 to BTI7801, BTI7802 to BTI7802, BTI7814 to BTI7814).

    Modified: 2017-08-04