After configuring the DHCP Relay using the Autodeployer during deployment, you can modify the dhcp block in the L3 profile file and run the AutoDeployer configuration script again to update the configuration.

Note	Rerunning AutoDeployer configuration script causes all the RPDs/SGs to be deleted and added.

In the AutoDeployer script L3 profile file, the DHCP Relay configuration is saved in the dhcp section. It is applied to all Service Groups on the Cisco cnBR. The following is an example configuration:

"Dhcp":
    {
        "ArpGlean":true,
        "ArpProxy":true,
        "ipv4Lq": false,
        "NdGlean":true,
        "NdProxy":true,
        "ipv6Lq":false,
        "dhcpServers":["80.80.80.3",
                      "81.81.81.3",
                      "2001:80:80:80::3",
                      "2001:81:81:81::3"
        ],
        "V4Nets":["90.90.90.1/24",
                  "91.91.91.1/24",
                  "92.92.92.1/24"
        ],
        "V6Nets":["2001:90:90:90::1/64",
                  "2001:91:91:91::1/64",
                  "2001:92:92:92::1/64"
        ],
        "RelayPolicies":[
          {"deviceClass": "HOST",
          "v4serverip": "80.80.80.3",
          "v6serverip": "2001:80:80:80::3",
          "giaddr": "90.90.90.1",
          "linkaddr": "2001:90:90:90::1"
          },
          {"deviceClass": "STB",
          "v4serverip": "81.81.81.3",
          "v6serverip": "2001:81:81:81::3",
          "giaddr": "91.91.91.1",
          "linkaddr": "2001:91:91:91::1"
          },
          {"deviceClass": "PS",
          "giaddr": "92.92.92.1",
          "linkaddr": "2001:92:92:92::1"
          },
          {"deviceClass": "EROUTER",
          "v4serverip": "80.80.80.3",
          "v6serverip": "2001:80:80:80::3",
          },
          {"deviceClass": "DVA",
          "giaddr": "90.90.90.1",
          "linkaddr": "2001:90:90:90::1"
          },
          {"deviceClass": "MTA",
          "giaddr": "91.91.91.1",
          "linkaddr": "2001:91:91:91::1"
          }
        ],
        "mobilityScopes":["90.90.90.1/24",
                          "91.91.91.1/24",
                          "92.92.92.1/24",
                          "2001:90:90:90::1/64",
                          "2001:91:91:91::1/64",
                          "2001:92:92:92::1/64"
        ]
    }

See Configure Cisco cnBR Using Autodeployer for additional information.

DHCPv4 dashboard displays statistics of the DHCP relay of IPv4. In all, there are 16 panels. The preceding picture shows only half the number of panels. Each panel represents the count of different states for different packet over time. There are four packet types for DHCPv4: Discover, Offer, Request, and Acknowledgment (Ack). The system processes each type of packet differently: Received, Dropped, Handled, and Injected. You can change the time span at the top-right corner. Currently, they show the count for the last six hours.

DHCPv6 dashboard displays statistics of the DHCP relay of IPv6. In all, there are 16 panels. The preceding picture shows only half the number of panels. Each panel represents the count of different states for different packet over time. There are four packet types for DHCPv6: Renew, Advertise, Request, and Reply. The system processes each type of packet differently: Received, Dropped, Handled, and Injected. You can change the time span at the top-right corner. Currently, they show the count for the last six hours.

The table displays the BGP configuration parameters, their description, type and enforcement information

When a BGP router restarts, all its neighbors detect that the BGP router went down and has come up again. It results in the deletion and adding back of the BGP routes in the neighbors. The unnecessary recomputation of routes, called a "routing flap", causes issues on both the BGP and neighbor routers. Graceful Restart allows the system to preserve the routes during BGP restart, thus minimizing the negative effects of BGP restart.

The Cisco cnBR BGP Agent allows easy modification of BGP Agent global configurations.

The Cisco cnBR BGP Agent Dashboard provides visibility into the BGP IPv4 and IPv6 routes and operation.

The Cisco cnBR Cluster US Resiliency statistics panel provides the current and historical statistics for the selected Cisco cnBR and Service Group, which includes:

• The current number of cable modems that are in partial service mode in the selected Cisco cnBR cluster.

• The current total number of cable modems detected by the selected Cisco cnBR cluster.

• The historical count of the cable modems that are in upstream partial service mode.

• The total number of cable modems over time.

• The current list of the cable modems in upstream partial service mode.

The Service Group Statistics panel provides the current and historical statistics for the selected Service Group, which includes:

• The current number of cable modems that are in partial service mode in a specific Service Group.

• The historical count of the cable modems that are in upstream partial service mode in a specific service group.

The US Channel Statistics panel provides the current and historical statistics for each upstream channel in the selected Service Group, which includes:

• The current number of cable modems that are in partial service mode for each upstream channel in the selected Service Group.

• The historical count of the cable modems that are in upstream partial service mode in each upstream channel in the selected Service Group.

When a significant number of CMs have a problem on a specific channel, there may be channel frequency interference in a certain segment of the cable plant or service neighborhood.

When a few CMs have a problem on all channels, it may indicate that there is a loose connector or deteriorating cable on certain segment of the service neighborhood, or those CMs may be close to the boundary of the supported service area. It may also indicate a cabling problem of those CMs at the customer homes.

In the preceding cases, you may need more investigation to better understand and troubleshoot the problem, and proactively implement remedies if needed (before you call the service center).

In the AutoDeployer script SG template file, you can add netDelayCfg block to rpdCfg block to enable DLM. The SG template configuration applies to all service groups on the Cisco cnBR. See Configure Cisco cnBR Using Autodeployer for additional information.

    "rpdCfg": {
        "rfTopology": {
            ......
        },
        "netDelayCfg": {
            "staticDelay": 1000,
            "dlmCfg": {
                "interval": 10,
                "updateMap": true
            }
        }
    }

After the initial DLM configuration during the deployment using the AutoDeployer, you can update the configuration by modifying the netDelayCfg block in the SG template and running the AutoDeployer configuration script again.

Note	The system first deletes all the RPDs/SGs and then adds them back when you rerun AutoDeployer configuration.

This table lists and describes DLM configuration parameters.

As shown in the following figure, the first part of Voice Main page displays the Packetcable feature enable/disable status, COPS connection status, established call status, and the alerts that are reported by system.

Detailed explanation for components in the preceding figure.

• Pie chart for CMS Connection.

  • active - The counter for CMS connections which are in active status.

  • timeout - The counter for CMS connections which are timeout.

• Pie chart for Call Established.

  • active - The counter for Established Calls which are in active status.

  • failure - The counter for Established Calls which are failure.

• Pie chart for Alert.

  • fatal - Fatal event counter.

  • error - Error event counter.

  • warning - Warning event counter.

• Table for CMS Servers.

  • CMS - Server IP address.

  • Port - Server port.

  • State - Server connection states.

  • Keepalive - Keepalive timer between CMS and Cisco cnBR.

  • Client Type - The client type value (32776 for Packetcable and 32778 for Packetcable Multimedia).

  • You can use Search... text box to do fuzzy search in the entire table.

As shown in the following figure, the second part of Voice Main page displays overall call statistics and error logs reported by cmts-app-packetcable container in Cisco cnBR side.

Legends for components in the preceding figure.

• Graph for Call Statistic

  • X-axis - Time.

  • Y-axis - Number of gates.

• Logs

  • Error messages from cmts-app-packetcable container.

The Call Status page shows current and completed call status, as shown in the following figure:

Legends for each column of tables in the preceding figure.

• Table for Ongoing Call Status

  • Modem - Modem MAC address.

  • Subscriber - Subscribe's MTA IP address.

  • Start time - The start time for the call.

  • Duration - Call duration.

  • CMS - Call Management Server IP address.

  • Gate ID - Gate identifier.

  • SFID(US) - Service flow ID for upstream.

  • SFID(DS) - Service flow ID for downstream.

• Table for Completed Call Status

  • Modem - Modem MAC address.

  • Subscriber - MTA IP address.

  • Start time - The start time for the call.

  • Stop time - The stop time for the call.

  • Duration - Call duration.

  • CMS - Call Management Server IP address.

  • Gate ID - Gate identifier.

  • SFID(US) - Service flow ID for upstream.

  • SFID(DS) - Service flow ID for downstream.

The COPS Status page shows the COPS connection status as shown in the following figure:

Legends for each table in the preceding figure.

• Table for Total list

  • CMS Address - Call Management Server IP address.

  • CMS Port - Port of the Call Management Server IP address.

  • Start - The start time for CMS connection.

  • Close - The close time for CMS connection.

  • State - The server connection states.

  • Keepalive - The keepalive time for CMS and Cisco cnBR.

  • Client Type - The client type (32776 for Packetcable and 32778 for Packetcable Multimedia).

  • KATimer - The counter for keepalive message.

  • Decision - The counter for COPS decision message.

  • Report - The counter for COPS report-type message.

  • You can use Search... text box to do fuzzy search in the entire table.

• COPS Message Tx Counters

  • X-axis - Time.

  • Y-axis - The counter for each type of COPS Tx Message.

• COPS Message Rx Counters

  • X-axis - Time.

  • Y-axis - The counter for each type of COPS Rx Message.

• COPS Object

  • X-axis - Time.

  • Y-axis - The counter for each type of COPS Object.

Four dynamic service flows are created to set up a voice path for each two-way call.

One upstream and one downstream service flow are created for each modem in the call.

You can find Service Flow Information for each modem in Downstream Service Flow List or Upstream Service Flow List dashboard.

The Downstream Service Flow List is used as an example in the following figure:

The downstream dynamic service flow created for voice call is listed under Service Flow List table.

Detailed explanations of each column in Downstream Service Flow List table in the preceding figure.

• Table for Downstream Service Flow List

  • SF ID - Service Flow ID.

  • Cable Modem - MAC Address of the modem.

  • SG - Service Group of the modem.

  • MD - MAC Domain of the modem.

  • State - State of service flow [Prov, Adm, Act].

    • Prov - Service flow is in provision state.

    • Adm - Service flow is in admit state.

    • Active - Service flow is active state.

  • Stage - Stage of service flow [PRE_REGISTRATION, REGISTRATION, DSX].

    • PRE_REGISTRATION - Service flow is provisioned before REGISTRATION.

    • REGISTRATION - Service flow is provisioned in REGISTRATION.

    • DSX - Service flow is dynamically provisioned for voice.

  • Frame Type - [PRE_D30, CCF_ON, CCF_OFF].

    • PRE_D30 - Pre-3.0 DOCSIS concatenation and fragmentation.

    • CCF_ON - Continuous Concatenation and Fragmentation is enabled.

    • CCF_OFF - Continuous Concatenation and Fragmentation is disabled.

  • Prim DS - Primary downstream channel ID.

  • Init US - Init upstream channel ID.

  • Type - [Primary, Secondary].

  • SVC Type - [Dynamic, Static].

    • Dynamic - Service flow is dynamically provisioned.

    • Static - Service flow is statically provisioned.

  • Packets - Number of packets.

  • Create Timestamp - When the service flow created.

Clicking on the SFID of dynamic flow in above table to redirect to the Downstream Service Flow Verbose page.

The voice traffic throughput data is available in that page, as shown in the following figure:

The TX Rate table in the preceding figure shows the downstream traffic throughout for voice.

Legends of relevant tables and counters in the preceding figure.

• Service Flow Traffic Rate

  • X-axis - Time

  • Y-axis - Throughput in kilobit per second

• TX byte cnt is the count of total bytes received by policer.

  • "TX Byte cnt" = "QOS Tx Byte" - "QOS Drop Bytes"

• TX packet cnt is the count of total packets received by policer.

  • "TX Packet Cnt" = "QOS Tx Pkt" - "QOS Drop Pkts"

• QOS TX byte is the count of total bytes sent to policer.

  • "QOS Tx Byte" = "TX Byte cnt" + "QOS Drop Bytes"

• QOS TX pkt is the count of total packets sent to policer.

  • "QOS Tx Pkt" = "TX Packet Cnt" + "QOS Drop Pkts"

• QOS drop bytes are the drop bytes count of policer, includes policer drops, queue full drops, and approximate Fair Drop drops.

  • "QOS Drop Bytes" = "QOS Tx Byte" - "TX Byte cnt"

• QOS drop pkts are the drop packets count of policer, includes policer drops, queue full drops, and approximate Fair Drop drops.

  • "QOS Drop Pkts" = "QOS Tx Pkt" - "TX Packet Cnt"