Kafka Telemetry

Kafka Telemetry

Table 1. Feature History

Feature Name

Release Information

Feature Description

Kafka support for multiple brokers

Cisco IOS XE Dublin 17.12.1z

Starting from this release, Kafka broker cluster now provides support for monitoring the connection status of up to a maximum of two brokers. Each broker connection can be maintained independently.

Kafka support for OFDMA channel information

Cisco IOS XE Dublin 17.12.1z

The cBR-8 routers now include a new telemetry event, OFDMA-Status, which serves to identify channel configurations and monitor the upstream status of channels.

Starting with Cisco IOS XE Dublin 17.12.1x release, a new Binos process was introduced to support Kafka. This process also services the SNMP PNM TFTP requests replacing the legacy Guestshell PNM TFTP application.

Kafka Broker Connection

The Kafka broker must be specified by IPv4 address using the bootstrap-servers command:

cable telemetry broker kafka-broker
   bootstrap-servers 1.2.0.150:9092 

The following Kafka Broker configuration is required in server.properties when starting the server.

[root@kafka-server config]#bin/kafka-server-start.sh config/server.properties
# Listener name, hostname and port the broker will advertise to clients. 
# If not set, it uses the value for "listeners". advertised.listeners=PLAINTEXT://1.2.0.150:9092 

Kafka US-RxMER Telemetry Event

cBR-8 Telemetry events are published on Kakfa using Google Protocol Buffer (GPB) message format. GPB is a language-neutral, platform-neutral, extensible mechanism for serializing structured data.

Here are the details of the Cisco Telemetry GPB file:

  • Package: cisco_cable_telemetry

  • Message: PmaUsRxMer

    Sub-messages

    • OssiPnmUsRxMer

    • PmaUsRxMerHdr

Here is a sample GBP .proto file for the US-RxMER event:

/*
 *
 * file: cisco_cable_telemetry.proto
 * 
 * Upstream MER Telemetry and channel stats, Google Proto Buff format
 *
 * Copyright (c) 2022-2024 by Cisco Systems, Inc.
 * All rights reserved.
 */ 

syntax = "proto3";

package cisco_cable_telemetry;

message OssiPnmUsRxMer {
  uint32 file_type                     = 1;
  uint32 major_ver                     = 2;
  uint32 minor_ver                     = 3;
  uint32 capture_time                  = 4;
  uint32 if_index                      = 5;
  string ccap_id                       = 6;
  bytes  rpd_id                        = 7;
  uint32 rpd_port_num                  = 8;
  bytes  cm_mac_addr                   = 9;
  uint32 number_of_averages            = 10;
  uint32 preeq_on_off                  = 11;
  uint32 subcarrier_zero_center_freq   = 12;
  uint32 first_active_subcarrier_index = 13;
  uint32 subcarrier_spacing_in_khz     = 14;
  uint32 rx_mer_byte_len               = 15;
  bytes  rx_mer_data                   = 16;
}

message PmaUsRxMerHdr {
  uint32 version           = 1;
  uint32 slot              = 2;
  uint32 ctrlr             = 3;
  uint32 us_channel        = 4;
  uint32 mac_domain        = 5;
  uint32 ucid              = 6;
  uint32 ucd_cc            = 7;
  uint64 total_cws         = 8;
  uint64 good_cws          = 9;
  uint64 corr_cws          = 10;
  uint64 uncorr_cws        = 11;
}

message PmaUsRxMer {
  PmaUsRxMerHdr    header  = 1;
  OssiPnmUsRxMer   ossi    = 2;
}

Here is a sample GBP .proto file for the OFDMA-Status event:

/*
 *
 * file: cisco_docsis_ofdma_status.proto
 * 
 * DOCSIS 3.1 OFDMA channel config and status, Google Proto Buff format
 *
 * Copyright (c) 2023 by Cisco Systems, Inc.
 * All rights reserved.
 */ 

syntax = "proto3";

package cisco_docsis_ofdma_channel;


/* OFDMA channel state. ​*/
enum OfdmaState {
    OFDMA_STATE_UNSPECIFIED = 0;         // reject stage and commit​
    OFDMA_STATE_ADMIN_DOWN  = 1;         // accept stage , reject commit
    OFDMA_STATE_ADMIN_UP_OPER_DOWN = 2;  // accept stage and commit
    OFDMA_STATE_OPER_UP  = 3;
}

/* LCHA status​ */
enum LchaStatus {
    LCHA_STATUS_UNSPECIFIED = 0;
    LCHA_STATUS_PRIMARY_ACTIVE  = 1;
    LCHA_STATUS_SECONDARY_ACTIVE = 2;
}
/* See MULPI Spec table "Channel TLV Parameters" TLV 28 ​*/
enum SubcarrierSpacing {
     SC_SPACING_UNSPECIFIED = 0;
     SC_SPACING_25KHZ = 1;
     SC_SPACING_50KHZ = 2;
}
message SubcarrierBand {
    uint32 sc_start = 1;
    uint32 sc_end   = 2;
}

message MinislotGroup {
    uint32 sc_start = 1;
    uint32 minislot_start = 2;
    // Modulation bitload range: {0-12}
    //    Ref: Cablelabs MULPI spec UCD TLV 21 Table:
    uint32 modulation_bitload = 3;
    // Pilot Pattern Range: {1-14}
    //    Ref: Cablelabs MULPI spec table
    uint32 pilot_pattern = 4;
    uint32 consecutive_minislots = 5;
}

message IucBurstProfile {
    uint32 iuc = 1;
    repeated MinislotGroup minislot_groups = 2;
}
message PmaOfdmaStatus {
    uint32 major_ver       = 1;
    uint32 minor_ver       = 2;
    uint32 reporting_time  = 3;
    uint32 if_index        = 4;
    string ccap_id         = 5;
    uint32 slot            = 6;                   // primary slot ​
    uint32 ctrlr           = 7;
    uint32 us_channel      = 8;
    uint32 mac_domain      = 9;
    uint32 ucid            = 10;                  // 1-based ucid
    OfdmaState ofdma_state         = 11;
    LchaStatus lcha_status         = 12;
    SubcarrierSpacing  sc_spacing          = 13;
    uint32             sc_0_center_freq_hz = 14;

    repeated     SubcarrierBand  sc_exclusion_bands          = 15;
    repeated     SubcarrierBand  sc_unused_bands             = 16;
    repeated     IucBurstProfile base_iuc_burst_profiles     = 17;
    repeated     IucBurstProfile current_iuc_burst_profiles  = 18;
 }

Test

Table 2. Feature History

Feature Name

Release Information

Feature Description

cBR8 SNMP MIBs to convert to gRPC for Kafka Bus

Cisco IOS XE Dublin 17.15.1z

To lower cBR8 SUP IOSd CPU and offload some SNMP polling to a streaming telemetry method, this feature converts the first phase of frequently polled MIB OIDs to put on the cBR8 Kafka bus.

Table 3. Feature History

Feature Name

Release Information

Feature Description

Kafka support for channel set of a modem to be continually reassessed over time

Cisco IOS XE Dublin 17.15.1z

System level notifications for power monitoring downgrade and upgrade have been added for Kafka telemetry using “cm.event.us.dynpwr”.

Table 4. Feature History

Feature Name

Release Information

Feature Description

Channel set of a modem to be continually reassessed over time based on the power capability of the modem and current plant attenuation

Cisco IOS XE Dublin 17.15.1z

Modems with limited transmit power ceiling are assigned a single upstream OFDMA channel as their upstream bounding group. These modems continue to be close to their maximum transmit power with a single OFDMA and experience upstream data error issues. The preference is for these modems to drop its bonding group to a group of ATDMA channels instead of a single OFDMA channel.

After a modem comes online, the CMTS software will continue monitoring the modem transmit power and perform upstream bonding group (UBG) adjustment if the modem transmit power moves higher. If the modem’s transmit power moves lower, the CMTS will move the modem to use higher frequency width UBG.

Kafka Telemetry Messages for DS Resiliency Show Commands

Table 5. Feature History

Feature Name

Release Information

Feature Description

DS Resilency Commands for Google Protocol Buffer

Cisco IOS XE Dublin 17.15.1y

In this release, the output of various DS Resiliency show commands are streamed over Kafka in Google Protocol Buffer.

The DS resiliency Kafka Telemetry Messages publish event data that is related to the downstream (DS) channel status and partial service events using Kafka topics. This feature is designed for service providers to monitor and manage the health and status of cable modems and channels using streaming telemetry in GPB format.

Commands Added:

  • cable telemetry periodic-timer timer-name interval interval-time

  • cable telemetry message ds-ctrlr-status periodic-timer timer-name

  • cable telemetry message cm-partial-service periodic-timer timer-name

Information About DS Resiliency Commands for Google Protocol Buffer

The DS resiliency Kafka Telemetry Messages publish event data (DS channel status and CM partial service events) to the Kafka broker topics, namely cisco.cbr.ds.ctrlr.status and cisco.cbr.cm.partial.service. These messages are periodically sent to enable monitoring of cable modem status and channel impairments, facilitating proactive management of network health.

The DS resiliency data format is defined in Google Protocol Buffer (*.gpb) file. The event is published in a separate Kafka topic.

Google ProBuff Files

  • Here is a sample of the contents of a GPB file for cisco.cbr.ds.ctrlr.status.

    /*
     *
     * file: ds_ctrlr_status.proto
     * 
     * DS Ctrlr Status, Google Proto Buff format
     *
     * Copyright (c) 2023-2025 by Cisco Systems, Inc.
     * All rights reserved.
     */ 
    
    
    syntax = "proto3";
    
    package cisco.cbr.ds.ctrlr.status;
    
    
    message DsChannelStatus {
      uint32 ds_channel = 1;
      uint32 total_cm_online = 2;
      uint32 total_cm_reporting_down = 3;
    }
    
    message DsCtrlr {
      uint32 ctrlr = 1;
      repeated DsChannelStatus ds_channel_status = 2;
    }
    
    message DsCtrlrStatus {
      string ccap_id = 1;
      uint32 slot = 2;
      uint32 md_index                    = 3;
      uint32 md_if_index                 = 4;
      repeated DsCtrlr ds_ctrlr = 5;
    }
  • Here is a sample of the contents of a GPB file for cisco.cbr.cm.partial.service.

    *
     *
     * file: cm_partial_service.proto
     * 
     * CM PARTIAL SERVICE, Google Proto Buff format
     *
     * Copyright (c) 2023-2025 by Cisco Systems, Inc.
     * All rights reserved.
     */ 
    
    syntax = "proto3";
    
    package cisco.cbr.cm.partial.service;
    
    
    message CtrlrChannel {
        uint32 ctrlr = 1;
        repeated uint32 channel = 2;
    }
    
    enum PartialServiceType {
        PARTIAL_SERVICE_UNREPORTED          = 0;
        PARTIAL_SERVICE_OTHER               = 1;
        PARTIAL_SERVICE_NONE                = 2;
        PARTIAL_SERVICE_DS_ONLY_IMPAIRED    = 3;
    }
    
    message CmStatusPartialService {
      bytes mac_addr                               = 1;
      PartialServiceType partial_service_type      = 2;
      uint32 us_chan_count                         = 3;
      uint32 ds_chan_count                         = 4;
      repeated CtrlrChannel us_impaired_ctrlr_channels        = 5;
      repeated CtrlrChannel ds_impaired_ctrlr_channels        = 6;
    }
    
    message CmPartialService {
        string ccap_id                     = 1;
        uint32 slot                        = 2;
        uint32 md_index                    = 3;
        uint32 md_if_index                 = 4;
        repeated CmStatusPartialService cm_status_partial_service       = 5;
    }
    

Here is a sample of the contents of a GPB file for cisco.cbr.ds.ctrlr.status.

Benefits of DS Resiliency Show Commands

  • Enables monitoring of cable modem and channel status.

  • Facilitates proactive management and quick identification of network issues.

  • Uses streaming telemetry for efficient data handling and integration with existing network management systems.

  • Supports high availability and reload configurations by saving settings in the Indigo DB.

Prerequisites for DS Resiliency Show Commands

  • Kafka broker must be set up and accessible with the specified IP address.

  • Cable telemetry feature should be enabled on the network devices.

Configuration Commands

Use these commands to configure this feature:

  • Enable cable telemetry:

    router(config)# cable telemetry enable
  • Configure cable telemetry periodic timer:

    router(config)# cable telemetry periodic-timer timer-name interval interval-time

    Here timer-name refers to the name of the timer and interval-time is the number od seconds with a range of 10-1440.

  • Configure DS controller status message and telemetry broker:

    router(config)# cable telemetry message ds-ctrlr-status periodic-timer timer-name
    router(config)# cable telemetry broker kafka-broker
    router(config-cable-telemetry-broker)# bootstrap-servers IP_Address
    router(config-cable-telemetry-broker)# message ds-ctrlr-status
  • Configure CM partial service message: and telemetry broker:

    router(config)# cable telemetry message cm-partial-service periodic-timer timer-name
    router(config)# cable telemetry broker kafka-broker
    router(config-cable-telemetry-broker)# bootstrap-servers IP_Address
    router(config-cable-telemetry-broker)# message cm-partial-service

Verify DS Resiliency Show Command

To verify the configuration:

  • Check the output on the Kafka consumer to ensure that GPB messages are being printed correctly with the expected channel status and CM lists.

  • Use the show cable modem summary wb-rfs commands to verify telemetry data and view wideband RF resiliency status summary.

    router#show cable modem summary wb-rfs
    Load for five secs: 4%/0%; one minute: 4%; five minutes: 4%
    Time source is NTP, 06:05:17.628 EDT Fri Apr 25 2025
    
              Total     Total    Percent
    RF        w-online  RF down  RF down
    --------  --------  -------  -------
    1/0/0 1   16        0        0
          2   16        0        0
          3   16        0        0
          158 1         0        0
    1/0/1 2   6         0        0
          3   6         0        0
          4   6         0        0
          5   6         0        0
          6   6         0        0
          7   6         0        0
          8   6         0        0
          9   5         0        0
          10  5         0        0
          11  5         0        0
          12  5         0        0
          13  5         0        0
          14  5         0        0
          15  5         0        0
          16  5         0        0
          17  5         0        0
          18  5         0        0
          19  5         0        0
          20  5         0        0
          21  5         0        0
          22  5         0        0
          23  5         0        0
          158 5         0        0
    
  • Here is a sample of the running configuration:

    router#show run | sec telemetry
    cable telemetry periodic-timer 10mins interval 10
    cable telemetry periodic-timer interval 11
    cable telemetry enable
    cable telemetry message ds-ctrlr-status periodic-timer 10mins
    cable telemetry message cm-partial-service periodic-timer normal
    cable telemetry broker broker1
      bootstrap-servers 10.79.196.164
      message cm-partial-service
    cable telemetry broker broker2
      bootstrap-servers 10.79.196.162
      message ds-ctrlr-status
  • Here is a sample of the show cable modem partial-service ds-partial command:

    router#show cable modem partial-service ds-partial
    Load for five secs: 11%/1%; one minute: 11%; five minutes: 10%
    Time source is NTP, 17:13:25.389 CST Thu Apr 15 2025
    MAC Address    IP Address      I/F           MAC               DSxUS  Impaired    Impaired    Forwarding
                                                 State             State  DS          US          Interface
    
    c0c6.87ff.e168 104.1.106.239   C1/0/0/UB     p-online(pt)      27x4   1/0/0:12                Wi1/0/0:24          
                                                                          1/0/0:13    
                                                                          1/0/0:14    
                                                                          1/0/0:15    
                                                                          1/0/0:16    
                                                                          1/0/0:17    
                                                                          1/0/0:18    
    

Supported Scenarios

The DS Resiliency show commands are useful in scenarios where monitoring of cable modem status and channel impairments is critical, such as in large-scale service provider networks, where quick identification and resolution of network issues are necessary to maintain service quality.

Kafka Telemetry for MIB Tables

Table 6. Feature History

Feature Name

Release Information

Feature Description

Kafka Telemetry for MIB Tables

Cisco IOS XE Dublin 17.15.1z

This feature enables the streaming of Management Information Base (MIB) table data onto a Kafka bus in Google Protocol Buffer (GPB) format. It involves migrating specific MIB/OID (Object Identifier) entry values to new Kafka topics and protobuf messages. This process is handled by a dedicated process on the SUP (Supervisor Processor) that manages Kafka Event Streaming, effectively acting as a CBR (Cable Broadband Router) Telemetry system.

The Kafka Telemetry for MIB Tables feature publishes various types of data to Kafka Brokers, each with a dedicated topic and containing specific SNMP MIB information. The messages are generated in GPB form.

Table 7. OID Supported in 17.15.1z

OID Name

MIB Entry

1.3.6.1.2.1.10.127.1.3.3.1.2

docsIfCmtsCmStatusMacAddress

docsIfCmtsCmStatusEntry

1.3.6.1.2.1.10.127.1.3.3.1.21

docsIfCmtsCmStatusInetAddress

docsIfCmtsCmStatusEntry

1.3.6.1.2.1.10.127.1.3.3.1.20

docsIfCmtsCmStatusInetAddressType

docsIfCmtsCmStatusEntry

1.3.6.1.2.1.10.127.1.3.3.1.9

docsIfCmtsCmStatusValue

docsIfCmtsCmStatusEntry

1.3.6.1.4.1.4491.2.1.20.1.3.1.2

docsIf3CmtsCmRegStatusMacAddr

docsIf3CmtsCmRegStatusEntry

1.3.6.1.4.1.4491.2.1.20.1.3.1.3

docsIf3CmtsCmRegStatusIPv6Addr

docsIf3CmtsCmRegStatusEntry

1.3.6.1.4.1.4491.2.1.20.1.3.1.5

docsIf3CmtsCmRegStatusIPv4Addr

docsIf3CmtsCmRegStatusEntry

1.3.6.1.4.1.4491.2.1.20.1.3.1.6

docsIf3CmtsCmRegStatusValue

docsIf3CmtsCmRegStatusEntry

1.3.6.1.4.1.4491.2.1.20.1.3.1.7

docsIf3CmtsCmRegStatusMdIfIndex

docsIf3CmtsCmRegStatusEntry

1.3.6.1.4.1.4491.2.1.20.1.3.1.14

docsIf3CmtsCmRegStatusLastRegTime

docsIf3CmtsCmRegStatusEntry

1.3.6.1.4.1.4491.2.1.20.1.4.1.7

docsIf3CmtsCmUsStatusUnerroreds

docsIf3CmtsCmUsStatusEntry

1.3.6.1.4.1.4491.2.1.20.1.4.1.8

docsIf3CmtsCmUsStatusCorrecteds

docsIf3CmtsCmUsStatusEntry

1.3.6.1.4.1.4491.2.1.20.1.4.1.9

docsIf3CmtsCmUsStatusUncorrectables

docsIf3CmtsCmUsStatusEntry

Information About Kafka Telemetry for MIB Tables

The primary goal of this feature is to enhance system efficiency by reducing CPU usage on the SUP IOSd (Internetwork Operating System daemon) and minimizing the processing load associated with SNMP MIBs on the SUP IOSd. By converting MIB/OID data into Kafka telemetry messages, the system can offload and streamline data collection and processing.

The following Kafka messages are supported:

  • 3.1.1 - Kafka message cm-reg-status : The solution publishes cm-reg-status data to Kafka Broker. By default, this message is published within a separated kafka topic: cisco.cbr.cm.reg.status, which should include the following snmp mib information: docsIfCmtsCmStatusMacAddress/docsIf3CmtsCmRegStatusMacAddr, docsIf3CmtsCmRegStatusIPv4Addr, docsIf3CmtsCmRegStatusIPv6Addr, docsIf3CmtsCmRegStatusLastRegTime, docsIf3CmtsCmRegStatusValue/ docsIfCmtsCmStatusValue, docsIf3CmtsCmRegStatusMdIfIndex

  • 3.1.2 Kafka message cm-stats : The solution publishs cm-status data to Kafka Broker. By default, this message ispublished within a separated kafka topic: cisco.cbr.cm.stats, which should include the following snmp mib information: docsIfCmtsCmStatusMacAddress/docsIf3CmtsCmRegStatusMacAddr,docsIf3CmtsCmUsStatusUnerroreds,docsIf3CmtsCmUsStatusCorrecteds,docsIf3CmtsCmUsStatusUncorrectables and related channel information.

Benefits of Kafka Telemetry for MIB Tables

  • Optimized CPU Usage: Reduces the CPU load on the SUP IOSd.

  • Reduced SNMP Processing: Decreases the amount of SNMP MIB processing required on the SUP IOSd.

  • Efficient Data Streaming: Provides MIB data as streaming telemetry in GPB format for efficient consumption by other systems. Events are transmitted only when data changes, reducing unnecessary data transfers.

  • Decoupling of Streaming Telemetry: Separates telemetry operations from the SUP IOSd, potentially improving system stability and performance.

  • Scalability: Supports OIDs that scale with Cable Modem (CM) count, making it suitable for large deployments.

Supported Scenarios:

This feature supports streaming various MIB tables related to upstream and downstream channel status and utilization for DOCSIS (Data Over Cable Service Interface Specification) operations. It is designed to support high availability (SUPHA, LCHA) and line card power redundancy (LCPR) mechanisms. Specific use cases in the requested example format are not provided in the document.

Configure Kafka Telemetry for MIB Tables

To enable Kafka telemetry messages, use the following commands from the CMTS configuration mode:

  1. Enable Telemetry.

    router# cable telemetry enable
    
  2. Enable Periodical Timer: Configure a periodic timer for data transmission. You can use a custom name and interval (10-1440 minutes), or use a default timer.

    router# cable cable telemetry periodic-timer <Periodic timer name> interval <10-1440>
  3. Enable Messages: Enable specific messages (for example, cm-reg-status, cm-stats) to be streamed using the defined periodic timer.

    router(config)#cable telemetry message cm-reg-status periodic-timer <Periodic timer name>
    router(config)#cable telemetry message cm-stats periodic-timer <Periodic timer name>
    
  4. Enable Broker: Configure the Kafka broker, specifying the bootstrap servers and the messages to be sent.

    router(config)#cable telemetry broker <broker name >
    #bootstrap-servers <string in the format host1:port1,host2:port2,...>
    #message cm-reg-status
    #message cm-stats

Verify Kafka Telemetry for MIB Tables

You can verify the configuration and status of Kafka telemetry using the following show commands:

  • Display Kafka configuration, including remote broker, supported messages, enabled messages, and configured periodical timers.

    router# show platform software kman <R0/R1/RP> config
    
  • Display Kafka database configuration.

    router# show platform software kman <R0/R1/RP> database config_tbl
    
  • Display Kafka listener message statistics.

    router# show platform software kman <R0/R1/RP> stats telemetry
    
  • Display cable kman configuration.

    router# show cable kman config
  • Display Kafka messages enable/disable status and their mapping relationship with topic names and GPB message names.

    router# show platform software kman <R0/R1/RP> kafka messages
    

    Example:

    
    router#platform software kman r0 kafka messages 
    Load for five secs: 42%/24%; one minute: 33%; five minutes: 33%
    Time source is NTP, 10:52:09.045 CST Fri Apr 18 2025
    
    GPB Package : cisco.cbr
         Syntax : proto3
    
      Message             Status     Topic Name                    GPB Message
      ----------------------------------------------------------------------------
      us-rxmer            disabled   cisco.cbr.cm.us.ofdma.rxmer   CmUsOfdmaRxMer
      ofdma-status        disabled   cisco.cbr.us.ofdma.status     UsOfdmaStatus
      ds-ctrlr-status     disabled   cisco.cbr.ds.ctrlr.status     DsCtrlrStatus
      cm-partial-service  disabled   cisco.cbr.cm.partial.service  CmPartialService
      cm-reg-status       enabled    cisco.cbr.cm.reg.status       CmRegStatus
      cm-stats            enabled    cisco.cbr.cm.stats            CmStats
      usdynpwr-event      disabled   cisco.cbr.cm.event.us.dynpwr  CmTcsChg
  • Display Kafka publish messages statistics.

    router# show platform software kman <R0/R1/RP> kafka stats

    Example:

    
    router#show platform software kman r0 kafka stats 
    Load for five secs: 20%/3%; one minute: 29%; five minutes: 31%
    Time source is NTP, 11:00:17.826 CST Fri Apr 18 2025
    Broker: 135
    State: UP
    
    Tx Packets : 7
    Tx Bytes   : 37329
    Rx Packets : 7
    Rx Bytes   : 1057
    Cur Outq Len : 26
    Max Outq Len : 26
    
         Topic Name                Prod Msg     Prod bytes     Tx Msgs     Tx Msg bytes    Err Msgs
      ------------------------------  --------------------  --------------------  -------------------- 
      cisco.cbr.cm.reg.status        20         19398          13          12908            0
      cisco.cbr.cm.stats             22         36762          13          22815            0
    
  • Display cable telemetry periodic-timer information:

    router# show platform software kman r0 kafka messages
    Load for five secs: 42%/24%; one minute: 33%; five minutes: 33%
    Time source is NTP, 10:52:09.045 CST Fri Apr 18 2025
    
    GPB Package : cisco.cbr
         Syntax : proto3
    
      Message             Status     Topic Name                    GPB Message
      ----------------------------------------------------------------------------
      us-rxmer            disabled   cisco.cbr.cm.us.ofdma.rxmer   CmUsOfdmaRxMer
      ofdma-status        disabled   cisco.cbr.us.ofdma.status     UsOfdmaStatus
      ds-ctrlr-status     disabled   cisco.cbr.ds.ctrlr.status     DsCtrlrStatus
      cm-partial-service  disabled   cisco.cbr.cm.partial.service  CmPartialService
      cm-reg-status       enabled    cisco.cbr.cm.reg.status       CmRegStatus
      cm-stats            enabled    cisco.cbr.cm.stats            CmStats
      usdynpwr-event      disabled   cisco.cbr.cm.event.us.dynpwr  CmTcsChg

Upstream Dynamic Power Ceiling Monitoring

Table 8. Feature History

Feature Name

Release Information

Feature Description

Upstream Dynamic Power Ceiling Monitoring

Cisco IOS XE Dublin 17.15.1z

Modems with limited transmit power ceiling are assigned a single upstream OFDMA channel as their upstream bounding group. These modems continue to be close to their maximum transmit power with a single OFDMA and experience upstream data error issues. The preference is for these modems to drop its bonding group to a group of ATDMA channels instead of a single OFDMA channel. After a modem comes online, the CMTS software will continue monitoring the modem transmit power and perform upstream bonding group (UBG) adjustment if the modem transmit power moves higher. If the modem’s transmit power moves lower, the CMTS moves the modem to use higher frequency width UBG

Kafka support for channel set of a modem to be continually reassessed over time

Cisco IOS XE Dublin 17.15.1z

System level notifications for power monitoring downgrade and upgrade have been added for Kafka telemetry using cm.event.us.dynpwr.

This feature, Upstream Dynamic Power Ceiling Monitoring, enables Cisco cable systems to automatically monitor and adjust the transmit (TX) power of cable modems in real time. The system dynamically reassigns modems to suitable upstream channel groups (bounding groups) to ensure that the modem transmit power remains within configured ceilings, thereby maintaining signal quality and network reliability.

The feature works by:

  • Continuously monitoring the TX power of cable modems after they come online.

  • Automatically moving modems to smaller (narrower) or larger (wider) channel width bounding groups based on their transmit power levels.

  • Notifying users when a modem is reassigned to a different bounding group due to power ceiling violations or when the modem can be upgraded back.

  • Providing configuration controls and operational visibility through CLI, syslog, SNMP, and Kafka telemetry notifications.

Information About Upstream Dynamic Power Ceiling Monitoring

Dynamic Upstream Channel Power Ceiling Monitoring is a software-driven mechanism that supervises the transmit (TX) power levels of DOCSIS 3.1 cable modems. When a modem's TX power exceeds configurable thresholds on one or more upstream channels, the feature automatically moves the modem to a narrower bounding group (BG) with a lower frequency range, reducing the required TX power. Later, if conditions allow, the modem can be upgraded back to its full bounding group

The system is configurable, allowing operators to:

  • Enable or disable the feature.

  • Set reassessment and recovery intervals.

  • Choose notification methods (syslog, SNMP, telemetry).

  • View and clear dynamic power ceiling data for modems.

This feature applies only to DOCSIS 3.1 (D3.1) cable modems.

Prerequisites for Upstream Dynamic Power Ceiling Monitoring

  • Modems must support periodic statistics reporting.

  • The system must support DBC (Dynamic Bounding Change) operations.

Restrictions for Upstream Dynamic Power Ceiling Monitoring

  • Only applies to DOCSIS 3.1 (D3.1) modems. Not applicable to DOCSIS 3.0 (D3.0) or lower

    .
  • The default and allowed intervals for reassessment and recovery are limited as specified in the configuration overview.

  • The feature only manages channel assignments based on TX power, not other modem parameters.

Benefits of Upstream Dynamic Power Ceiling Monitoring

Excessive upstream transmit power can degrade network performance and modem reliability. This feature optimizes channel assignments automatically, ensuring that all modems operate within safe power limits and maximizing network efficiency without manual intervention.

  • Automatic Protection: Keeps modem transmit power within safe limits without manual intervention.

  • Improved Reliability: Reduces risk of degraded performance or modem failure due to excessive TX power.

  • Operational Visibility: Provides clear CLI commands and notification options (syslog, SNMP, Kafka) for monitoring and auditing events.

  • Flexible Configuration: Allows operators to tailor intervals and notifications to operational needs.

  • Targeted Application: Applies changes only to D3.1 modems, ensuring compatibility.

Supported Scenarios

  • Automatically protecting cable modems from exceeding safe upstream transmit power.

  • Managing large deployments of DOCSIS 3.1 modems to ensure network stability.

  • Providing operations teams with real-time alerts and reporting for channel power ceiling events.

  • Suitable for networks where modems may move between channel groups based on varying upstream conditions.

Upstream dynamic power ceiling show cable modem and event notifications

User can use show cable modem with “us-dyn-pwr-reassessed” keyword to find affected modems.

There are three ways system notifies upstream dynamic power ceiling changed BG:

  • Syslog

  • SNMP Notification

  • Kafka telemetry notification

Configure Upstream Dynamic Power Ceiling Monitoring

Enable or Disable the Feature:

  • Enable:

    cable upstream dynamic-power-ceil-monitor enable

  • Disable:

    no cable upstream dynamic-power-ceil-monitor enable

Set Reassessment and Recovery Intervals:

  • Set upgrade check interval (default 40 min):

    cable upstream dynamic-power-ceil-monitor reassess-interval <20-1440>

  • Set recovery interval (default 2 days):

    cable upstream dynamic-power-ceil-monitor recover-interval <1-7>

Enable/Disable Syslog or SNMP Notification:

  • Enable/disable syslog:

    [no] cable upstream dynamic-power-ceil-monitor syslog

  • Enable/disable SNMP notification:

    [no] cable upstream dynamic-power-ceil-monitor snmp-notify

Enable Telemetry Notification:

  • Enable cable telemetry messages for upstream dynamic power ceiling feature:

    [no] cable telemetry message usdynpwr-event

  • Enable generating cable telemetry messages under a broker for upstream dynamic power ceiling.

    [no] message usdynpwr-event

Clear Cached Data:

  • Clear all cached data:

    clear cable modem us-dyn-pwr-ceil-cached-data

  • Clear for a specific modem (by MAC or IP):

    clear cable modem <MAC|IP> us-dyn-pwr-ceil-cached-data

Verify Upstream Dynamic Power Ceiling Monitoring

To find the modems, which upstream power ceiling reassessed use the keyword “us-dyn-pwr-reassessed”

You can verify the configuration and status of Kafka telemetry using the following show commands:

Show Reassessed Modems:

  • All reassessed modems: Show all the modems, which reassessed and changed BG by upstream dynamic power ceiling feature.

    show cable modem us-dyn-pwr-reassessed

  • By cable interface: Show all the modems, which reassessed and changed BG by upstream dynamic power ceiling feature in a cable interface

    show cable modem cable<slot>/0<md> us-dyn-pwr-reassessed

  • By IP: Show a single modem with modem ip address, reassessed and changed BG by upstream dynamic power ceiling feature info.

    show cable modem <IP> us-dyn-pwr-reassessed

  • By IP: Show a single modem with modem ip address, reassessed and changed BG by upstream dynamic power ceiling feature detail info.

    show cable modem <IP> us-dyn-pwr-reassessed detail

  • By MAC: Show a single modem with modem MAC address, reassessed and changed BG by upstream dynamic power ceiling feature info.

    show cable modem <MAC> us-dyn-pwr-reassessed

  • Detailed info: Show a single modem with modem MAC address, reassessed and changed BG by upstream dynamic power ceiling feature detail info.

    show cable modem <IP|MAC> us-dyn-pwr-reassessed detail

Show Cable Modem:

router8#show cable modem 9058.515c.9df4 us-dyn-pwr-reassessed
MAC Address    I/F            MAC               curr   full   Trig   Reassess  Reassess         Next
                              State             tcs    tcs    chan   power     Time             Reassess
9058.515c.9df4 C8/0/0/UB      w-online(pt)      0x0080 0x00CF 1      43.75dBmV 2:08:03 ago      0:12:39 
  • curr tcs – the current BG TCS in bitmap, the numbers are us channels in mac-domain, 0 based.

  • full tcs – the bounding group TCS, if upstream dynamic power ceiling did not reassess and change the BG.

  • Trig chan – the channel, which triggered the downgrade. The number is the us channel in mac-domain, 0 based.

  • Reassess power – the power level triggered the downgrade.

  • Reassess Time – when the reassess happened.

  • Next Reassess – Next upgrade check time.

Show Cable Modem detail: This command displays the usch cached power values, P1.6hi and Neq (1.6mhz) of the current BG, current modem upstream channel TX power (similar to scm phy), upstream dynamic power ceiling related configurations, if DBC current in progress, and next recovery time.

Example Output:

router#show cable modem 9058.515c.9df4 us-dyn-pwr-reassessed detail
MAC Address    I/F            MAC               curr   full   Trig   Reassess  Reassess         Next
                              State             tcs    tcs    chan   power     Time             Reassess
9058.515c.9df4 C8/0/0/UB      w-online(pt)      0x0080 0x00CF 1      43.75dBmV 2:25:36 ago      0:15:06 

Power ceiling cached values in dBmV:
  ch0   ch1   ch2   ch3   ch4   ch5   ch6   ch7   ch8   ch9   ch10  ch11  ch12  ch13  ch14  ch15
  40.75 43.75 47.75 41.25 00.00 00.00 40.00 37.00 00.00 00.00 00.00 00.00 00.00 00.00 00.00 00.00 

Modem full tcs: 0x00CF, curent tcs: 0x0080

P1.6hi:47.30dBmV, Neq:59

CM upstream channels:
ch07 pwr:37.25 adj:-0.50 sta, 

Monitor is Enabled, Reass_intvl: 20min, Recover_intvl: 1440min, syslog_enable: 1, snmp_notif: 1,
Cable interface max-channel-power-offset: 0dBmV
DBC is Not in progress
Next recover time in 1294min

Show Dynamic Event Timeline:: Use the show cable modem <MAC> timeline dynamic command to display the dynamic power ceiling change history.

router#show cable modem 9058.515c.9f58 timeline dynamic
cable modem dynamic event timeline in clc :
TIMESTAMP               OLD STATE    EVENT                    NEW STATE    
Mar 14 19:08:37.729     w-online(pt) us dyn pwr monitor       w-online(pt)  UpG TCS from 0x0080 to 0x00CF 
Mar 14 19:08:26.534     w-online(pt) ranging request          w-online(pt)  o-init-rng-req: us 7          
Mar 14 19:08:04.514     w-online(pt) us dyn pwr monitor       w-online(pt)  DnG TCS from 0x00CF to 0x0080 

Monitor Upstream Dynamic Power Ceiling

You can monitor dynamic power ceiling events using:

  • Show Command: show cable modem 9058.515c.9df4 us-dyn-pwr-reassessed detail

  • Syslog notifications for BG (bounding group) changes.

  • SNMP traps for downgrade/upgrade events.

  • Kafka Telemetry for real-time event streaming.

Kafka Example Output:

Copy Code
Message on cisco.cbr.cm.event.us.dynpwr parition [0] at offset 99:
  UTC Timestamp: 2025-02-05 18:29:00.030000
  Headers: ccap_id="tb5-cbr8"
  operation        : Downgrade
  old_tcc          : 0x00cf
  new_tcc          : 0x0080

Note:

Monitoring and notification setup require corresponding system components (syslog server, SNMP manager, Kafka broker).

SYSLOG Format

CLC 8/0: Mar
        14 16:29:59.595 EDT: %CBR-6-US_DYN_PWR: Upstream Dynamic Power Ceil Monitor Cable8/0/0 CM:
        9058.515c.9df4 Downgrade to TCS 0x0080
CLC 8/0: Mar
        14 19:08:46.076 EDT: %CBR-6-US_DYN_PWR: Upstream Dynamic Power Ceil Monitor Cable8/0/0 CM:
        9058.515c.9df4 Upgrade to TCS 0x00CF

SNMP Notification

Received SNMPv2c Trap:
Community: public
From: 8.5.1.1
sysUpTimeInstance = 00:09:52.60
snmpTrapOID.0 = ciscoDocsExtNotifications.11
ifIndex.1290 = 1290
docsIfCmtsCmStatusMacAddress.1290 = 90 58 51 5c 9d f0 
ciscoDocsExtMIBObjects.13.1.1290 = 1
ciscoDocsExtMIBObjects.13.2.1290 = 192

Kafka Telemetry Notification

Topic Name - cisco.cbr.cm.event.us.dynpwr

enum UpDynPwrOperation {
    UP_DYN_PWR_MONITOR_OPERATE_DOWNGRADE = 0;
    UP_DYN_PWR_MONITOR_OPERATE_UPGRADE = 1;
}

message CmTcsChg {
  uint32 version              = 1;
  string ccap_id              = 2;
  uint32 slot                 = 3;
  uint32 md_index             = 4;
  uint32 md_if_index          = 5;
  bytes  cm_mac_addr          = 6;
  UpDynPwrOperation operation = 7;
  uint32 old_tcc              = 8;
  uint32 new_tcc              = 9;
}

tb5-cbr8#show platform software kman r0 kafka stats

Broker: broker-cluster
State: UP
... 
Topic Name                     Prod Msg              Prod bytes            Tx Msgs
-----------------------------  --------------------  --------------------  --------------------
cisco.cbr.cm.event.us.dynpwr   0                     0                     0