Operations and Administration Guide: For Casa Software Releases To 8.2.2

CMTS
Operations and Administration

Guide
For Casa Software Releases to 8.2.2
DOC-3010-01
Document Revision 08.02.02
March 2017
© 2017 Casa Systems, Inc.
All rights reserved. Licensed software products are owned by Casa Systems or its suppliers and are protected
by United States copyright laws and international treaty provisions.
The information regarding the product in this manual is subject to change without notice. All statements,
information, and recommendations in this manual are believed to be accurate but are presented without
warranty of any kind, express of implied. Users must take full responsibility for their application of the product.
In no event shall Casa or its suppliers be liable for any indirect, special, consequential, or incidental damages,
including, without limitation, lost profits or loss or damage to data arising out of the use or inability to use this
manual, even if Casa or its suppliers have been advised of the possibility of such damages.
iii
Contents
Preface
Chapter 1. CMTS operations overview

About this chapter ............................................................................................. 1-1
.
CMTS installation in the network topology ........................................................ 1-1 .
About the Casa CMTS as a headend device .............................................. 1-2 .
Understanding the CMTS as a DOCSIS MAC domain ............................... 1-3 .
Cable modem initialization and learning ........................................................... 1-4 .
Cable modem initial ranging and registration .................................................... 1-5 .
Cable modem provisioning and configuration ................................................... 1-6 .
Upstream channel descriptors and MAPs ......................................................... 1-8 .
UCD and MAP operations ........................................................................... 1-8 .
Upstream timeline ....................................................................................... 1-9 .
Channel bonding and service group operations ..............................................1-11 .
Load balancing CMTS traffic ........................................................................... 1-12 .
Dynamic channel and bonding changes ................................................... 1-13 .
Load balancing policies ............................................................................. 1-14 .
Static vs. dynamic load balancing ............................................................. 1-14 .
Applying exclusion lists ............................................................................. 1-15 .
Terminology covered in this guide ................................................................... 1-15 .
Chapter 2. Using the Casa command line interface

.
Getting started with the CLI .............................................................................. 2-1 .
Accessing the CLI ....................................................................................... 2-2 .
Casa Systems CMTS

iv Operations and Administration Guide
Contents
Entering privileged mode ............................................................................ 2-4 .
Entering configuration mode ....................................................................... 2-4 .
Exiting and logging out of the CLI ............................................................... 2-4 .
CLI basic concepts ............................................................................................ 2-5 .
Startup configuration ................................................................................... 2-5 .
Running configuration ................................................................................. 2-5 .
CLI structure summary ................................................................................ 2-6 .
CLI hierarchies ............................................................................................ 2-7 .
Moving up and down through the hierarchy ................................................ 2-7 .
CLI operations ................................................................................................... 2-8

.
Displaying available objects and parameters .............................................. 2-8 .
Entering parameters ................................................................................... 2-9 .
Displaying help text ....................................................................................2-11 .
Using show commands ..............................................................................2-11 .
Filtering show command output ................................................................ 2-13 .
Using command auto-completion ............................................................. 2-15 .
Displaying and executing from command line history ............................... 2-15 .
String requirements for the CLI ................................................................. 2-16 .
Setting date and time intervals .................................................................. 2-16 .
Common CLI error messages ................................................................... 2-17 .
Changing the CLI prompt ................................................................................ 2-18 .
Creating command aliases ............................................................................. 2-18 .
Deleting existing settings ................................................................................ 2-19 .
Chapter 3. Administering CMTS security

About this chapter ............................................................................................. 3-1 .
CMTS administration overview ......................................................................... 3-2 .
Configuring the CMTS management port ......................................................... 3-2 .
Changing the default CMTS password ............................................................. 3-3 .
Encrypting passwords ....................................................................................... 3-4 .
User management and security control ............................................................ 3-4 .
Adding user command execution privileges ..................................................... 3-5 .
Casa Systems CMTS

Operations and Administration Guide v
Contents
Enabling SSH sessions to the CMTS ................................................................3-6 .
Setting the Telnet port and other settings ..........................................................3-6 .
Configuring TACACS+ server authentication ....................................................3-7 .
Configuring RADIUS server authentication .......................................................3-8 .
Configuring TACACS+/RADIUS loopback interface ..........................................3-9 .
RF cable security settings ...............................................................................3-10 .
Enforcing TFTP transfer of the CM config file ............................................3-10 .
Configuring TFTP options .......................................................................... 3-11 .
Enforcing CPE VRFs in an IP bundle ........................................................ 3-11 .
Enabling DHCP authorization ....................................................................3-12 .
Enforcing BPI and BPI+ .............................................................................3-13 .
Configuring an encryption algorithm ..........................................................3-14 .
Changing the security association descriptor TLV length ..........................3-14 .
Configuring shared secrets to protect the CM configuration file ................3-14 .
Enabling configuration file learning ............................................................3-16 .
Configuring Source Address Verification (SAV) rules ................................3-16 .
Chapter 4. Managing the CMTS configuration file

About this chapter .............................................................................................4-1
.
CMTS configuration file overview ......................................................................4-1 .
Entering privileged mode .............................................................................4-2 .
Using the startup-config file .........................................................................4-2 .
Saving the running configuration .................................................................4-2 .
Avoiding configuration conflicts .........................................................................4-3 .
Copying the running configuration .....................................................................4-4 .
Copying the startup-config file to NVRAM .........................................................4-4 .
Copying files from FTP and TFTP servers ........................................................4-5 .
Restoring the CMTS configuration ....................................................................4-6 .
Displaying configurations ..................................................................................4-6 .
Chapter 5. Configuring DHCP, TFTP, NTP, DNS, and logging services

.
Configuring DHCP servers ................................................................................5-1 .
Casa Systems CMTS

vi Operations and Administration Guide
Contents
Configuring DHCP leasequery .......................................................................... 5-3 .
Enabling the TFTP proxy and enforcing TFTP .................................................. 5-6 .
About ToD servers ............................................................................................ 5-7 .
Synchronizing the CMTS with NTP servers ...................................................... 5-7 .
Configuring DNS servers .................................................................................. 5-8 .
Configuring local and remote logging ............................................................... 5-8 .
Logging DOCSIS event messages to SYSLOG ............................................. 5-10 .
Configuring event reporting flags for DOCSIS events .....................................5-11 .
Copying log files from fdsk2 ........................................................................... 5-13 .
Chapter 6. Creating a new CMTS configuration

.
Ensuring the CMTS preconfiguration ................................................................ 6-2 .
Configuring IP bundle interfaces ....................................................................... 6-3 .
Configuring MAC domains ................................................................................ 6-4 .
Special note on flexible licensing ...................................................................... 6-5 .
Configuring QAM downstream channels .......................................................... 6-6 .
Downstream port conventions .................................................................... 6-6 .
QAM channel configuration ......................................................................... 6-6 .
Setting QAM channel frequencies .............................................................. 6-7 .
Channel sharing in QAM modules .............................................................. 6-8 .
Configuring QAM 8x8 downstream channels ............................................ 6-25 .
Enabling and disabling QAM ports and channels ..................................... 6-28 .
Setting downstream port parameters ........................................................ 6-29 .
QAM output power levels .......................................................................... 6-30 .
Configuring upstream channels ...................................................................... 6-31 .
Upstream port conventions ....................................................................... 6-32 .
Configuring upstream channel parameters ............................................... 6-32 .
Configuring multiple upstream logical channels ........................................ 6-35 .
Binding channels to the MAC domain ............................................................. 6-40 .
Configuring service groups ............................................................................. 6-41 .
Enabling D3.0 channel bonding ...................................................................... 6-43 .
Casa Systems CMTS

Operations and Administration Guide vii
Contents
Attaining maximum throughput over channel bonded CMs .......................6-44 .
Verifying CM channel bonding ...................................................................6-44 .
Optimizing TCP window sizes at CPEs .....................................................6-45 .
Adjusting interface QAM and interface upstream settings .........................6-46 .
Tuning modulation profiles .........................................................................6-47 .
Editing the CM configuration file ................................................................6-48 .
Load balancing CM traffic ................................................................................6-48 .
Chapter 7. Load balancing CMTS traffic

.
CMTS load balancing overview .........................................................................7-2 .
Static and dynamic load balancing ..............................................................7-2 .
Load balancing restrictions and limitations ..................................................7-3 .
Load balance configuration prerequisites ....................................................7-4 .
Enabling load balancing ....................................................................................7-4 .
Load balancing configuration steps ...................................................................7-5 .
Creating load balancing groups .........................................................................7-5 .
General load balancing groups ....................................................................7-6 .
Restricted load balancing groups ................................................................7-9 .
Adding CMs to the restricted load balancing group ...................................7-12 .
Configuring policies and rules .........................................................................7-14 .
Load balancing policy decision processing ...............................................7-14 .
Defining basic load balancing rules ...........................................................7-15 .
Defining execution rules ............................................................................7-16 .
Load balancing over suspicious channels .................................................7-22 .
Using exclusion lists ........................................................................................7-22.
Load balancing configuration examples ..........................................................7-23 .
Configure static general load balancing ....................................................7-24 .
Create an execution rule to enable dynamic load balancing .....................7-25 .
Display and assess load balance statistics ...............................................7-26 .
Create special load balancing configurations ............................................7-27 .
Casa Systems CMTS

viii Operations and Administration Guide
Contents
Chapter 8. CMTS monitoring

.
Displaying system information .......................................................................... 8-2 .
Enabling system monitors ................................................................................. 8-3 .
Monitoring fan, power, and temperature status ................................................. 8-5 .
Fan subsystem messages .......................................................................... 8-7 .
Related CLI commands .............................................................................. 8-8 .
Monitoring CMTS network interfaces ................................................................ 8-8 .
Enabling the line card monitor .........................................................................8-11 .
Monitoring DOCSIS MAC interfaces ................................................................8-11 .
Displaying the system log ............................................................................... 8-13 .
Assessing redundancy failovers ..................................................................... 8-15 .
Monitoring cable modems ............................................................................... 8-16 .
Checking for flapping modems ....................................................................... 8-17 .
Configuring the CM flap list ....................................................................... 8-17 .
Setting the flap list insertion time .............................................................. 8-18 .
Setting the flap list power adjust threshold .............................................. 8-18 .
Configuring the flap list miss threshold .................................................... 8-18 .
Configuring flap list aging ......................................................................... 8-18 .
Configuring the flap list check interval ..................................................... 8-19 .
Showing the CM flap-list .......................................................................... 8-19 .
Maintaining CMTS hardware .......................................................................... 8-19 .
Replacing the chassis air filter .................................................................. 8-20 .
Locating and removing the air filter ........................................................... 8-20 .
Installing the air filter ................................................................................. 8-21.
Checking electrical and RF connections ......................................................... 8-22 .
Index
Casa Systems CMTS

vii
Preface
About this guide

The Casa Systems – CMTS Operations and Administration Guide guide is intended
for system administrators, support engineers, and operators who are responsible for
configuring and managing Casa CMTS products. Users who perform these tasks
should be familiar with the Casa CMTS hardware and cabling, as well as have
experience with the following:
• DOCSIS 1.0, 2.0, 3.0, and 3.1 cable modem technology
• MPEG-2 transport streams
• Internet Layer 2 and Layer 3 networking technologies and transports
• IETF routing protocols (IP, BGP, OSPF, RIP, IS-IS, etc.)
• RF cable plant infrastructure, including cable headend equipment servicing one or
more distribution areas
The following topics are covered in this guide:
For information about See
CMTS operations Chapter 1.

Using the Casa Command Line Interface (CLI) Chapter 2.
Configuring CMTS security Chapter 3.
Managing the CMTS configuration file Chapter 4.
TFTP, DHCP, NTP, and syslog services Chapter 5.
Creating a new CMTS configuration using the factory startup Chapter 6.
configuration
Casa Systems CMTS

viii Operations and Administration Guide
Preface
For information about See
Load balancing CMTS traffic Chapter 7.

Performing system maintenance and monitoring Chapter 8.
Revision history
This guide supports Casa CMTS software releases up to Release 6.5.2. See the Casa
Systems – CMTS Release Notes and the Casa Systems – CMTS Release 6.5 Features
Guide for information on new functionality not yet covered in this guide.
• 01.00.00 — Initial version; January 2014
• 01.01.00 — Chapter 7 update; added load balancing policy processing.
• 01.02.00 — Update to Casa software releases through 6.5.2.5.
• 01.03.00 — Update to Casa software releases through 7.1.2.
• 01.04.01 — Update to Casa software releases through 7.2.
• 01.04.02 through 7.02.03 not used — Revision level restructured; January 2017.
• 07.02.04 — February 2017; updated to Release 7.2.4.
• 08.02.02 — March 2017; updated to Release 8.2.2.1 build 5389.
Supported software releases

The following software releases are supported in this latest revision:
• CMTS Releases 5.4.21, 6.1.2, 6.1.3, 6.4.1, 6.4.2, 6.4.3, 6.5, 7.0, 7.1, 7.2, and 8.2.
Note that Release 7.0 and later software is not supported on Casa C10200, C3200,
and C2200 systems.
• 1G.1 (for Casa C1G systems with customized functionality; see the Casa Systems
– C1G CMTS Release Notes for information)
Casa Systems CMTS

Operations and Administration Guide ix
Preface
Contacting Casa
Corporate facility
Casa Systems, Inc.
100 Old River Road
Andover, MA 01810
Tel.: 978-688-6706
World Wide Web: www.casa-systems.com
Technical Support
In the United States: Tel: 978-699-3045
E-mail: support@casa-systems.com
Technical documentation
Casa Systems provides the following documentation set in PDF format, viewable
using Adobe Reader 5.0 or later. These PDF files are available from the Casa FTP site
at ftp://support.casa-systems.com.
• Casa Systems – C1G CMTS Quick Installation
• Casa Systems – C1G CMTS Hardware Installation Guide
• Casa Systems – C10G/C10200 CMTS Quick Installation
• Casa Systems – C100G CMTS Quick Installation
• Casa Systems – CMTS Operations and Administration Guide (this guide)
• Casa Systems – CMTS Network Solutions Guide
• Casa Systems – NSI Configuration Guide and Command Reference
• Casa Systems – RF Cable Configuration Guide and Command Reference
• Casa Systems – CCAP Video Edge User Guide
• Casa Systems – SNMP MIBs and Traps Reference
• Casa Systems – CMTS Troubleshooting and Diagnostics Guide
Casa Systems CMTS

x Operations and Administration Guide
Preface
• Casa Systems – CMTS Release 7.2 Features Guide

• Casa Systems – C1G CMTS Release Notes
• Casa Systems – CMTS Release Notes
Note: Casa Systems provides updates to the manuals on a regular basis. Log
on to the Casa Systems Web site at www.casa-systems.com for the latest files
in PDF format. Select customer login and enter your username and
password. If you do not have a Casa-assigned username and password, send
e-mail to support@casa-systems.com.
Effective September 1, 2013, technical documentation CD-ROMs are no

longer shipped with Casa CMTS hardware.
Conventions used in Casa documentation

Key Convention Function Example
boldface font Commands and keywords are in Enter abc

boldface.
Italic font Emphasized terminology is in italics. burst profile
brackets [ ] Elements in square brackets are [<ip_addr>]
optional.
braces {x | y | z} Indicates a required argument with a {enabled | disabled}
choice of values; choose one.
brackets [x | y | z] Indicates an optional argument with a [abc | 123]
choice of values; choose one.
vertical bar | Separates parameter values. Same as {TCP | TLS}
“or.”
string A non-quoted set of characters. Do not abc
use quotation marks (“”) around the
string as the string includes the
quotation marks.
screen font CLI sessions and information the CASA(config)#
system displays are in screen font.
boldface screen font Information you must enter is in show cable modem
boldface screen font.
Casa Systems CMTS

Operations and Administration Guide xi
Preface
Key Convention Function Example
<variable> Arguments for which you supply values <as_number>

are enclosed in angle brackets.
Multi-word arguments are indicated
with underscore-separated words.
<value:value> Arguments may include a range of <0:65535>
values, with the minimum and
maximum values separated by a colon.
^ The symbol ^ represents the key
labeled CTRL (control). The key
combination ^D in a screen display
means hold down the CTRL key while
pressing the D-key.
Acronyms
Casa Systems manuals contain the following industry-standard and product-specific
acronyms:
3DES Triple Data Encryption Standard (IPsec)
ABR Area Border Router (OSPF)
AES Advanced Encryption Standard
ARP Address Resolution Protocol
AS Autonomous System
ASN Autonomous System Number
ATDMA Asynchronous Time Division Multiple Access
BDR Backup Designated Router (OSPF)
BFD Bidirectional Forwarding Detection (RFC 5880)
BGP Border Gateway Protocol
BKPM Baseline Privacy Key Management
BPI[+] Baseline Privacy Interface [Plus]
BSR Bootstrap Router (PIM)
BW Bandwidth
CCAP Converged Cable Access Platform
CE Customer Edge
CIDR Classless Inter-Domain Routing
Casa Systems CMTS

xii Operations and Administration Guide
Preface
CLI Command Line Interface

CM Cable Modem
CMTS Cable Modem Termination System
CNR Carrier-to-noise ratio
COPS Common Open Policy Service
CPE Customer Premises Equipment
CSM Casa Spectrum Management
CSMA Carrier Sense Multiple Access
DAD Duplicate Address Detection (interfaces)
DBC Dynamic Bonding Change
DBG Downstream Bonding Group
dBmV Decibels per Millivolt
DCC Dynamic Channel Change
DCD Downstream Channel Descriptor (QAM)
DCTS Digital Cable Termination System
DES Data Encryption Standard
DNS Domain Name System/Server
DHCP Dynamic Host Configuration Protocol
DLF Destination lookup failure (packets)
DOCSIS Data Over Cable Service Interface Specification
DRFI Downstream Radio Frequency Interface (DOCSIS)
DSA Digital Signature Algorithm (SSH)
DSCP Differentiated Services Code Point
DSG DOCSIS Set-Top Gateway specification (QAM)
DSID Downstream Service Identifier (DOCSIS MAC)
DVB Digital Video Broadcasting (SimulCrypt)
EAE Early Authentication Encryption (DOCSIS MAC)
EAM Emergency Alert Message
eBGP External Border Gateway Protocol
EDIS Edge Device Interface Specification
EDRCA EuroDOCSIS Root Certificate Authority
FEC Forward Error Correction; Forwarding Equivalence Class (LDP)
Casa Systems CMTS

Operations and Administration Guide xiii
Preface
FIB Forwarding Information Base

FSM Finite State Machine
FTP File Transfer Protocol
GIADDR Gateway Interface Address
GigE Gigabit Ethernet
GLBG General Load Balancing Group
GRE Generic Routing Encapsulation (upstream interface)
IGMP Internet Group Management Protocol
IGP Interior Gateway Protocol
IKE Internet Key Exchange (IPsec)
IP Internet Protocol
IPv6 Internet Protocol Version 6
IPC Inter-process communication (error)
IPDR IP Detail Record
IPsec Internet Protocol Security
IPTV Internet Protocol Television (policies)
IS-IS Intermediate System-to-Intermediate System routing protocol
IUC Interval Usage Code
KEK Key Encryption Key (DOCSIS MAC)
L2VPN Layer 2 Virtual Private Network
LACP Link Aggregation Control Protocol
LDP Label Distribution Protocol
LSA Link State Advertisement
LSP Link-State Packet (IS-IS)
LSR Label-Switched Router (LDP)
MAC Media Access Control
MAP Bandwidth Allocation Map
MD5 Message Digest 5 algorithm
MD-CM-SG MAC Domain Cable Modem Service Group
MDD MAC Domain Descriptor (DOCSIS MAC)
MED Multi-Exit Discriminator (BGP)
MGMD Multicast Group Membership Discovery (DOCSIS MAC)
Casa Systems CMTS

xiv Operations and Administration Guide
Preface
MGPI Multiple Grants Per Interval (PacketCable)

MHz Megahertz
MIB Management Information Base
MLD Multicast Listener Discovery
MMM MAC Management Message
MMS Maximum message size (SNMP)
MPEG Moving Picture Experts Group
MPLS Multi-Protocol Label Switching
MPTS Multiple Program Transport Stream
MTA Multimedia Terminal Adapter (interfaces)
MTDMA Modified Time Division Multiple Access
MTU Maximum Transmission Unit
NET Network Entity Title (IS-IS)
NGOD Next Generation on Demand (video)
NLS Network Layer Signal
NSAP Network Service Access Point (IS-IS)
NSEL NSAP Selector (IS-IS)
NSF Non-Stop Forwarding (OSPF)
NSI Network Side Interface
NSM Network and System Management
NTP Network Time Protocol
NVRAM Non-Volatile Random-Access Memory
OCSP Online Certification Status Protocol
OFDM Orthogonal Frequency Division Multiplexing
OSI Open Systems Interconnect
OSPF Open Shortest Path First routing protocol
OUI Organizational Unique Identifier
PAP Password Authentication Protocol (AAA)
PAT Program Association Table
PCMM PacketCable Multimedia (policies)
PDP Policy Decision Point (COPS)
PDU Protocol data unit (interfaces)
Casa Systems CMTS

Operations and Administration Guide xv
Preface
PE Provider Edge
PID Packet ID (interfaces)
PIM-SM Protocol Independent Multicast in Sparse Mode
PME Privacy Mode Encryption (video)
PMT Program Mapping Table
PPS Packets per second
PS Portal Server
PSK Pre-Shared Key (IPsec)
QAM Quadrature Amplitude Modulation
QoS Quality of Service (policies)
QPSK Quadrature Phase Shift Keying
RADIUS Remote Authentication Dial In User Service
RAM Random Access Memory
RCP Receive Channel Profile
RCS Receive Channel Set
RD Route Distinguisher (VRF)
REG-REQ Registration Request (message)
REG-RSP Registration Response (message)
RFI Radio Frequency Interface
RIP Routing Information Protocol
RKS Record Keeping Server
RLBG Restricted Load Balancing Group
RNG-RSP Ranging Response (message)
RP Rendezvous Point (PIM-SM)
RPC Remote Procedure Call (SNMP)
RSA Rivest, Shamir and Adleman cryptographic algorithm (SSH)
RT Route target (BGP)
SAMIS Subscriber Account Management Interface Specification
SAV Source Address Verification
SG Service Group
SHA Secure Hash Algorithm
SI Service Information (QAM)
Casa Systems CMTS

xvi Operations and Administration Guide
Preface
SID Service Identifier (DOCSIS MAC)

SMM Switch and Management Module
SNMP Simple Network Management Protocol
SNP Sequence Number PDU
SNR Signal-to-Noise Ratio
SPD Security Policy Database (IPsec)
SPF Shortest Path First algorithm
SPI Security Policy Index (IPsec)
SPT Shortest Path Tree (PIM-SM)
SRM Session Resource Manager
SSH Secure Shell
SSM Source-Specific Multicast (PIM-SM)
TACACS Terminal Access Controller Access Control System
TCP Transmission Control Protocol
TCS Transmit Channel Set
TDM Time Division Multiplexing
TDMA Time Division Multiple Access
TEK Traffic Encryption Key (DOCSIS MAC)
TFTP Trivial File Transport Protocol
TLV Type-Length Value encoding scheme
ToD Time of Day
ToS Type of service
TPID Tag Protocol Identifier (VLAN)
UCD Upstream Channel Descriptor (DOCSIS MAC)
UDC Upstream Drop Classifier (DOCSIS MAC)
UGS Unsolicited Grant Service (policies)
URL Uniform Resource Locator
US Upstream
USM User-based Security Model (SNMP)
VLAN Virtual Local Area Network
VLSM Variable Length Subnet Mask
VPLS Virtual Private LAN Service
Casa Systems CMTS

Operations and Administration Guide xvii
Preface
VRF Virtual Routing and Forwarding

XGigE XGigabit Ethernet
Casa Systems CMTS

1-1
Chapter 1. CMTS operations overview
About this chapter

This chapter provides information on how the CMTS operates in the cable headend
network. It covers the following topics:
Topic Page
CMTS installation in the network topology 1-1

Cable modem initialization and learning 1-4
Cable modem initial ranging and registration 1-5
Cable modem provisioning and configuration 1-6
Upstream channel descriptors and MAPs 1-8
Channel bonding and service group operations 1-11
Load balancing CMTS traffic 1-12
Terminology covered in this guide 1-15
CMTS installation in the network topology

Figure 1-1 illustrates a sample cable headend network and a typical cable topology.
This example shows a Casa C3200 Cable Modem Termination System (CMTS) Data
Over Cable Service Interface Specification (DOCSIS) Media Access Control (MAC)
domain with one downstream interface and multiple upstream interfaces to a fiber
network, network accessible servers, routing to the Internet, content networks
providing modulated signals downstream, and a distribution area topology with a
single cable modem customer with attached customer premises equipment (CPE).
Casa Systems CMTS

1-2 Operations and Administration Guide
About the Casa CMTS as a headend device
Figure 1-1. Example D1.0 cable network topology with Casa CMTS
Cable headend network Servers

TFTP DHCP ToD Content networks
Internet - Streaming video/
video-on demand
servers
- News and sports feeds
- Network and satelite TV
Network edge router/ - Local TV
gateway to Internet
Hub
Modulated digital signals
Casa CMTS
CASA SYSTEMS SYS 3 4 5
Single
Multiple C3000 CCASA
ASA
ALM 0 1 2
downstream
upstream channel Forward channel lineup
channels
DOCSIS MAC domain (1 x N)

Television and
Diplexer/filter Forward combiner channel lineup
LOW | HIGH
5 to 42 MHz 50 MHz to 1 GHz
MPEG-2 Set-top box
Fiber network and transport stream
amplifier CH 851
Coaxial cable Cable modem

DS
US
D3.0, 2.0, PC
1.1, 1.0
Phone
Distribution over cable access
network to home subscribers
Note: The topology illustrated in Figure 1-1 uses the Casa C3200 CMTS as
an example. Other CMTS platforms, such and the Casa C2200, C10200,
C10G, C100G, and future Casa platforms also fit into this topology.
About the Casa CMTS as a headend device
The Casa CMTS provides both a network side interface (NSI) and a radio frequency
interface (RFI). On the NSI, the CMTS provides Ethernet 10/100 Mbps (for system
management), GigE, and 10GigE (C10G) interfaces to routing gateways and servers.
Casa Systems CMTS

CMTS operations overview 1-3
Understanding the CMTS as a DOCSIS MAC domain
On the RFI, the CMTS provides both upstream and downstream interfaces for
transmission and reception of digitized content and data services over fiber network
trunks and coaxial cable to and from the subscriber distribution areas.
Residing between the NSI and the RFI is the CMTS forwarding engine that resides in
the CMTS Switch and Management Module (SMM). As data, voice, and video traffic
is processed over both the NSI and the RFI, the forwarding engine selectively directs
the traffic over the correct interface for transmission and delivery to a destination.
Upstream Hypertext Transfer Protocol (HTTP) requests to the Internet from a
customer PC, for example, are transmitted by the cable modem (CM) over the fiber
network to the upstream CMTS channels before being forwarded to the NSI and
routing gateway to the Internet. The HTTP response (and Web page) from the Internet
destination is then returned to the CMTS and forwarded over a downstream channel to
that customer’s CM for transmission and presentation at the PC.
Understanding the CMTS as a DOCSIS MAC domain
The Casa CMTS comprises up to 96 DOCSIS MAC domains depending on the

particular model of CMTS you are integrating. The RFI, which consists of at least one
downstream channel and multiple upstream channels, is the DOCSIS MAC domain.
Today’s cable networks and CMs support the various implementations of DOCSIS
since its acceptance by cable providers in the late 1990s, including:
• DOCSIS 1.0 (D1.0) — One downstream and multiple upstream channels in 1xN
configuration. Baseline privacy interface (BPI); CM identification by service
identifier (SID).
configuration. Baseline Privacy Interface Plus (BPI+); CM identification by
service flow. Quality of Service (QoS) provisioning services for reliable voice and
video streaming. Quadrature Phase Shift Keying (QPSK) modulation only.
configuration. QAM64 modulation with downstream channel width at 6.4 MHz.
Improved performance and speed at 30 Mbps on the upstream channels.
• DOCSIS 3.0 (D3.0) — Multiple downstream and upstream channels in MxN
configuration. Channel bonding for up to 24 channels for increased downstream
bandwidth; logical bonding from the MAC domain to compatible D3.0 CMs
supporting multiple transmitters and receivers. (See Figure 1-2.)
Casa Systems CMTS

Cable modem initialization and learning
Figure 1-2. DOCSIS 3.0 topology with multiple downstream channels
DOCSIS 3.0 Multiple Modulated digital signals

MAC domain (M x N) downstream from content providers
channels
CASA SYSTEMS SYS 3 4 5
C3000 CCASA
ASA
ALM 0 1 2
Multiple
Forward channel lineup
upstream
channels
Television and
Diplexer/filter Forward combiner channel lineup
LOW | HIGH
MPEG-2 Set-top box
Fiber network and transport stream
amplifier CH 851
DS
US PC
Coaxial cable D3.0 cable modem
- Multiple tranmitters
and receivers
- Channel bonding
Phone
• DOCSIS 3.1 (D3.1) — Follows the same Evolved Telecommunication System

(ETS) development in parallel with wireless evolution. DOCSIS 3.1 supports
Orthogonal Frequency Division Multiplexing (OFDM) and Orthogonal
Frequency Division Multiple Access (OFDMA)
Note: DOCSIS versions a

Note: re backward compatible, such that a D3.0 CM is fully compatible with
prior versions D2.0, D1.1, and D1.0. However, a D1.0 CM cannot take
advantage of D3.0 channel bonding capabilities if the CMTS is configured with
multiple downstream channels.
Cable modem initialization and learning

For CMs in the subscriber distribution areas to establish two-way communication with
the CMTS, they must first initialize by listening and learning how to receive
Casa Systems CMTS

Cable modem initial ranging and registration
transmissions from the CMTS downstream channels, and then by learning how to
transmit to the CMTS over the upstream channels.
CM initialization begins when it is connected to the cable provider’s network and

powered on. The CM listens for MAC management message (MMM) broadcasts from
the CMTS. Using QAM modulated signals, the MMM carries the 188-byte Moving
Picture Experts Group version 2 (MPEG-2) transport stream for CM synchronization
with the MAC domain, as well as the upstream channel descriptors (UCDs) and their
associated Bandwidth Allocation Map (MAP) packets for establishing upstream
transmissions, and a MAC domain descriptor (MDD) for D3.0 CMs capable of
channel bonding.
Once the CM can listen for and receive the MPEG-2 transport streams that are
modulated on the downstream carrier signals, the CM begins the initial ranging
process over the upstream channels.
Cable modem initial ranging and registration

Initial ranging is a scheduled event that allows a CM to request an upstream
transmission grant from the CMTS. Initial ranging requests are carried in the UCD
burst profile with an associated MAP containing the CMTS-assigned interval usage
code (IUC). The IUC schedules the initial ranging interval in the upstream time line to
the CMTS. Once a transmission interval is set, the MAC domain then adjusts the CM
frequency, power, and delay for two-way communication.
In large networks with many CMs trying to register with the CMTS at the same time,
initial ranging requests are subject to collisions with requests from other CMs. Each
initial ranging request is considered an initial ranging opportunity. Because of the high
probability of collisions, the MAC domain uses a ranging backoff algorithm to tell the
CM how long to wait before retransmitting another initial ranging request. The
ranging backoff algorithm reschedules and increases initial ranging transmissions at
random intervals to provide a better opportunity for CMs to avoid collisions.
Ranging backoff values are expressed as an exponential value to set the number of
ranging opportunities per retry, such as 23, 24, 25, and 26. For example, configuring a
value of 3 specifies 23, or eight ranging opportunities on the first attempt. Configuring
a value of 4 specifies 24, or 16 ranging opportunities on the second attempt, and so on.
The Casa CMTS allows up to sixteen initial ranging retry attempts. When the CM
Casa Systems CMTS

Cable modem provisioning and configuration
receives an upstream transmission grant from the CMTS, the MAC domain adjusts the
CM for frequency, power, and delay. Two-way CM communication with the CMTS is
then established.
After the initial ranging request has completed, the CM is then provisioned using the
Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol
(TFTP) to complete the initialization process, as described in the next section. When
the initialization process has completed, the CM requests registration with the CMTS.
The CM can then receive transmissions on the downstream channels and transmit to
the CMTS over the upstream channels.

Provisioning servers at the headend are necessary for the CM to properly complete the
initialization process, as follows:
1. The CM initiates a request to a Dynamic Host Configuration Protocol (DHCP)

server for an IPv4 or IPv6 address assignment. DHCP Discover, Offer, Request,
and Acknowledgment packets are exchanged between the CM and the DHCP
server. The Acknowledgment (DHCPACK) message returns the offered IP
configuration to the requesting CM.
2. Once the CM is assigned an IP address, it submits a request to a target Trivial File
Transfer Protocol (TFTP) server for the DOCSIS modem configuration file. The
configuration file provides operational information to the CM using parameters
that are set by the cable service provider, including program identification to the
CMTS MAC domain. The TFTP server responds to the request by forwarding and
loading the configuration file to the CM at the DHCP-assigned address.
3. Optionally, the CM might request time information from a Time of Day (ToD)
server. In most cases, time information is returned to the CM using DOCSIS time
synchronization packets from the MAC domain that are carried in the MAC
management messages.
Figure 1-3 shows the cable modem initialization and configuration process.
Casa Systems CMTS

Figure 1-3. Cable modem initialization and configuration process

TFTP DHCP
Modem IP config MAC management message

config file to cable modem
188-byte
MPEG-2 transport
stream (42 Mbps)
Multiple Hub PID 1FFE MAC domain

upstream source
Casa CMTS Single
channels SYNC
CASA SYSTEMS
C3000 CCASA
ASA
SYS 3 4 5
ALM 0 1 2 downstream
channel UCD1
Modem initial UCD2
ranging
UCD3
and registration
Forward UCD4
combiner SYNC
Diplexer/filter
LOW | HIGH MAP1
MAP2
QAM64 or QAM256 MAP3
Fiber network and modulation
amplifier MAP4
Coaxial cable
DS
US
Cable modem frequency,
power, and delay adjustments.
Modem self-configuration using

file from TFTP server
1. Modem performs an initial ranging request with the CMTS. Transmission interval is
determined and modem is adjusted for frequency, power and delay. Modem sends
a registration request to the CMTS for two-way communication with the MAC domain.
2. Modem DCHP DISCOVER, OFFER, REQ, ACK packets exchanged with DHCP server.
3. IP configuration downloaded to cable modem.
4. Modem receives modem config file from TFTP server and configures itself. Optional
time-of-day packet exchange.
Casa Systems CMTS

Upstream channel descriptors and MAPs
Upstream channel descriptors and MAPs

As CMs continually listen for downstream MAC management messages from the
CMTS, the MPEG-2 transport stream carries the information that instructs the CM on
how to transmit over the upstream channels. A CM uses upstream channel descriptors
(UCDs) and associated Bandwidth Allocation Maps (MAPs) carried in the MPEG-2
transport stream to tell the CM “how and when” to transmit to the CMTS.
UCD and MAP operations
The CMTS MAC domain sends one UCD for every upstream channel. If there are
four upstream channels configured at the CMTS MAC domain, the MPEG-2 transport
stream contains four UCDs, as illustrated in Figure 1-3. The CM selects one UCD at
random to instruct the CM on “how” to transmit.
Each UCD describes an upstream channel with the following information:
• Frequency
• Width
• Burst profile—A set of burst descriptors, where:
– Each descriptor can be one of five burst types: initial ranging, periodic ranging,
long data, short data, and request.
– Each burst type can have up to twelve parameters, such as modulation type,
forward error correction (FEC), scrambler, preamble, and long/short data.
Each UCD has one associated MAP that instructs the CM on “when” to transmit over
an upstream timeline. Figure 1-4 illustrates the association between the UCD and the
MAP, where:
• UCD1 is the CMTS upstream channel, frequency, width and burst profile.
• MAP1 is when time zero (t0) begins on the upstream timeline, along with the
32-byte service identifier (SID) field that describes “who” is transmitting.
• IUC indicates “what” type of transmission, and the timing offset from t0 that
indicates “when” to begin the upstream transmission.
Casa Systems CMTS

Upstream timeline
Figure 1-4. UCD and MAP components

188-byte
MPEG-2 transport stream
1FFE
SYNC
“How to transmit” UCD1 Upstream channel selection, frequency, width, burst profile
UCD2
UCD3
Field of data
UCD4
SYNC
MAP
“When to transmit” MAP1 Elements 32 14 4 14 14 4 14
header
MAP2
MAP3
MAP4 “Who” “When”
Service ID (SID) t0 offset
“What”
Interval Usage Code (IUC)
Upstream timeline
The upstream timeline is comprised of intervals and minislots, where a single group of
minislots makes up one interval. These intervals vary in size starting at time zero (t0)
until the end of the interval where t0 begins again. Time Division Multiplexing (TDM)
scheduling is used to set both long and short intervals in the timeline where the
interval size is based on traffic conditions. Each minislot in each interval is 6.25
microseconds.
Figure 1-5 illustrates the upstream channel timeline, intervals, and minislots in the
network context.
Casa Systems CMTS

Upstream timeline
Figure 1-5. MAP upstream channel timeline, intervals and minislots

188-byte
MPEG-2
transport stream
Multiple 1FFE
upstream Casa CMTS Single
channels SYNC
CASA SYSTEMS
C3000 CCASA
ASA
SYS 3 4 5
ALM 0 1 2 downstream
channel UCD1
One upstream
channel selected UCD2
from UCD
UCD3
Forward UCD4
UCD1
combiner SYNC
Diplexer/filter
LOW | HIGH MAP1
MAP2
QAM64 or QAM256 MAP3
modulation
MAP4
Coaxial cable Cable modem

DS
US
Upstream timeline
Intervals Large and small intervals in timeline
IUC interval
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Minislots
(6.2 ms per minislot) 0
t0 0
MAP1
MAP
Elements 32 14 4 14 14 4 14
header
“Who” “When”
Service ID (SID) t0 offset
“What”
Interval Usage Code (IUC)
Casa Systems CMTS

Channel bonding and service group operations
Channel bonding and service group operations

Channel bonding, a DOCSIS 3.0 capability, is the CMTS process that logically
combines multiple downstream or upstream channels for extended bandwidth for
CMs with multiple transmitters and receivers. For downstream channels, the MDD in
the MPEG-2 transport stream informs the CM about the receive-channel configuration
and the RCS to be used by a registered CM.
Figure 1-6 illustrates a sample network with eight downstream channels. Even though
the CM only supports four downstream and four upstream channels, the CM learns
how to receive traffic across all eight CMTS downstream channels. The CMTS
dynamically creates a channel bonding group using four of the channels (based on
current traffic load) and creates a downstream service group (DS-SG) associated with
the assigned CM channel set. A service group (SG) is simply a group of channels.
Figure 1-6. DOCSIS 3.0 channel bonding to CMs

Eight
Four upstream Modulated digital signals
DOCSIS 3.0 downstream
channels in two from content providers
MAC domain (M x N) channels
service groups CASA SYSTEMS SYS 3 4 5
C3000 CCASA
ASA
ALM 0 1 2
A
B Forward channel lineup
C
D
Forward combiner
Multicast bus
LOW | HIGH LOW | HIGH LOW | HIGH LOW | HIGH

A B C D Diplexers/filters in
each distribution area
Fiber network 4US x 4DS
and amplifier DS-SG = CM-SG
US-SG
DS
US
D3.0 cable modem

Cable distribution areas - Channel bonding of
four DS channels based
the modem’s capability.
- Two-channel US service group.
Casa Systems CMTS

Load balancing CMTS traffic
Similarly, the set of upstream channels is called the upstream service group (US-SG).
Collectively, the upstream and downstream SGs make up the cable modem service
group (CM-SG). All upstream and downstream channels originating from the same
MAC domain are known as a MAC domain CM service group (MD-CM-SG). Note
that the CM in Figure 1-6 at the “D” distribution area endpoint uses a two-channel
upstream SG. This means that upstream traffic from the CM is assigned to one of two
channels from the MAC domain-assigned US-SG for this CM.
Cable service providers deliver voice, data, and video traffic over fiber optic trunks to
subscriber distribution areas, physical distribution areas known as physical fiber
nodes, as shown in Figure 1-6. A DOCSIS fiber node refers to a CM-SG, comprising
the upstream and downstream SGs described in the previous section.
While cable providers around the world today use the term fiber node to describe the
physical cable infrastructure to the distribution areas, it is important to understand that
the term DOCSIS fiber node is associated with a CM SG and not the physical network.
Load balancing CMTS traffic

Load balancing is the process that enables the CMTS to move a CM from one channel
to another so that traffic load is redistributed for improved bandwidth utilization and
reduced consumption of CMTS resources. When the CMTS determines that a channel
is reaching a traffic overload condition, the CMTS then moves the CM to a channel to
which that CM has access. This means that load balancing can take place only if the
affected CM has multiple and “available” downstream and upstream channels,
restricted only by the MD-CM-SG configuration.
The Casa CMTS supports two types of load balancing: general load balancing and
restricted load balancing, which are separated into groups:
• General load balancing group (GLBG) — Uses the complete set of upstream and
downstream channels in that CM’s CM-SG.
• Restricted load balancing group (RLBG) — Uses a configured subset of channels
in a CM’s SG. This means that the channels available for load balancing are
interactively selected and saved in the CMTS running configuration file.
Casa Systems CMTS

Dynamic channel and bonding changes
Note: A single CM cannot belong to more than one load balancing group at
any given time.
Both load balancing groups have the following characteristics:
• Downstream and upstream channels belong to the same MD-CM-SG.

• A CMTS policy configuration controls whether a CM or service flow can be
moved.
• A CMTS priority configuration selects which CMs to move.
At CM registration, the CMTS attempts to assign the CM to one of the two load
balancing groups. If a restricted load balancing group does not exist in the CMTS
configuration file, the CM is assigned by default to the general load balancing group
using the channels in the MD-CM-SG for that CM.
The following load balancing restrictions apply:
• A single CM can belong to only one load balancing group using only the upstream
and downstream channels in that group.
• Load balancing does not take place if the CMTS cannot determine the load
balancing group to which a registered CM belongs.
Dynamic channel and bonding changes
Dynamic channel change (DCC) and dynamic bonding change (DBC) messages from
the MAC domain instruct CMs on when to change channels or an upstream or
downstream bonding group. DCC and DBC can occur during traffic load balancing at
the CMTS when the CM has access to multiple upstream or downstream channels.
DCC moves legacy and current D3.0 CMs (not operating with a multiple receive
channel set) from one downstream channel to another using the MD-CM-SG for that
CM. On the upstream side, DCC also instructs CMs to move from one transmit
channel to another from the MD-CM-SG. DBC moves D3.0 CMs downstream service
flows to different channels in the CM’s receive channel set. It also moves D3.0
upstream service flows to different channels in the current transmit channel set.
Casa Systems CMTS

Load balancing policies
Load balancing policies
A load balancing policy is a set of rules that govern load balancing operations. There
are two types of rules that the CMTS uses when load balancing takes place: basic
rules and execution rules. The CMTS uniquely identifies each policy using an ID.
• Basic rule — Sets the time of day when the CMTS is to perform load balancing.
The configured time is during predictable traffic periods when congestion over the
downstream and upstream channels is most likely to occur. Multiple basic rules
are supported in a load balancing policy. A basic rule is a DOCSIS requirement.
• Execution rule — Defines the specific traffic conditions or parameters that enable
the load balancing algorithms of the CMTS regardless of the time of day (as set in
a basic rule). The execution rule can specify when load balancing is to occur and
to which CMs, the time interval, or how often certain CMs participate in DCC or
DBC load balancing operations, as well as other parameter settings such as static
and dynamic load balancing. Unlike basic load balancing rules, execution rules
are vendor-specific and are not mandated by DOCSIS.
At CM registration time, the CMTS assigns a load balancing policy ID to the CM

based on the default policy of the general load balancing group or the restricted load
balancing group for this CM.
Static vs. dynamic load balancing
The CMTS performs load balancing in one of two ways, or a combination of the two:
• Static load balancing — Takes place when a CM sends its initial ranging request
message to the CMTS. For D1.0, 1.1 and 2.0 CMs, the CMTS responds with a
RNG-RSP message that includes either a Downstream Frequency Override or an
Upstream Channel ID Override field that instructs the CM which channels it
should use. For D3.0 CMs, when a CM sends its REG-REQ messages, the CMTS
responds with a REG-RSP to instruct the CM to select the channels.
• Dynamic load balancing — Moves CMs among upstream and downstream
channels in the same SG when the difference between two channels exceeds a
defined percentage. The CMTS uses downstream and upstream channel change
messages to move CMs with single upstream/downstream channels, and DBC
messages to move CMs with bonded upstream/downstream channels to different
bonding groups.
Casa Systems CMTS

Applying exclusion lists
Note: For DOCSIS and EuroDOCSIS 3.0 CMs, the dynamic load balancing
software generates a downstream channel set with a minimum load to fit the
CM‘s receive channel profile (RCP). This prevents rejection of the new
channel set so that load balancing is not canceled when the assigned CM is
under load.
The CMTS does not move CMs to disconnected (idle) downstream channels where
there are no registered online CMs.
Applying exclusion lists
An exclusion list disables one or more CMs from load balancing across CMTS
downstream and upstream channels in situations where it is not feasible to load
balance particular CMs. For example, there might be cases where an older D1.0 or 2.0
CM from a specific vendor might not be a good candidate for load balancing, as well
as CMs that process particular types of traffic where moving those CMs to other
channels introduces risks. CMs in the exclusion list are specified by MAC address.
Terminology covered in this guide

burst descriptor — The single description of a burst type having up to twelve burst
description parameters, such as modulation type, forward error correction, scrambler,
preamble, and long/short data.
burst profile — The set of burst descriptors carried by UCD packets in the MPEG-2
transport stream as sent by the CMTS to a target CM. A burst profile supports up to
five upstream burst types to describe an upstream channel.
burst type — One of five possible upstream burst types that describe an upstream
channel as carried in the burst profile portion of a UCD packet. Possible upstream
burst types include initial-ranging, periodic-ranging, request, long data, and short data.
Each burst type is one burst descriptor with up to twelve burst descriptor parameters.
cable modem service group (CM-SG) — The combination of upstream (US-SG) and
downstream channels (DS-SG) at the CMTS to which a CM has access.
Casa Systems CMTS

channel bonding — The D3.0 CM feature that allows the CMTS to link a group of
channels based on the number of channels supported by the target CM. If the CMTS
creates a bonding group for a CM that has four physical downstream receivers, the
CM can receive over the four channels simultaneously in a downstream channel set.
DOCSIS fiber node — A CM service group (CM-SG) made up of the upstream

service group (US-SG) and downstream service group (DS-SG).
downstream channel — The CMTS 50-MHz to 1-GHz channel over which the CMTS
sends MPEG-2 transport streams over the cable infrastructure to the one more
distribution areas. The downstream channel operates with the forward combiner to
deliver modulated content on carrier signals to target cable subscribers.
downstream service group (DS-SG) — The group of CMTS downstream channels

over which MPEG-2 transport streams are modulated on carrier signals to a target
CM; the group of downstream channels to which a CM has access.
dynamic channel change (DCC) — The MAC management message from the CMTS
that instructs a CM to move from one channel to another within the CM-SG.
dynamic bonding change (DBC) — The MAC management that moves D3.0 CM
downstream service flows to different channels in the CM’s receive channel set
(RCS). DBC also moves D3.0 upstream service flows to different channels in the
current transmit channel set (TCS).
dynamic host configuration protocol (DHCP) — The IETF protocol for dynamically
assigning an IPv4 or IPv6 address to a requesting device, such as a CM. The CMTS
forwards a DHCP request from a CM to a dedicated DHCP server. The CMTS then
forwards the DHCP response message containing the IP address to the requesting CM.
dynamic load balancing — The CMTS traffic balancing method that moves CMs
among upstream and downstream channels within the same service group after their
initial difference between two channels exceeds a defined percentage.
exclusion list — A list of one or more CMs that the CMTS purposely excludes from
load balancing across CMTS downstream and upstream channels.
execution rule — A load balancing metric the defines the specific traffic conditions or
parameters that trigger load balancing operations at the CMTS.
Casa Systems CMTS

fiber node — The physical cable infrastructure that links the cable headend to one or
more geographical distribution areas.
forward channel lineup — Modulated digital content, such as local and satellite
television, news and sports feeds, and streaming video, that is carried on CMTS
downstream MPEG-2 transport streams to cable distribution areas.
forward combiner — The cable headend device that places modulated digital content,
such as the downstream channel lineup, onto CMTS downstream carrier signals to
cable distribution areas.
forwarding engine — The set of CMTS processes that reside between the CMTS NSI
and RFI for controlling how CMTS traffic is forwarded “through” one or more MAC
domains or routed “to” network destinations.
general load balancing group (GLBG) — The complete set of upstream and
downstream channels in a CM-SG that are available for load balancing operations.
initial ranging — The upstream burst type carried by the upstream channel descriptor
in the MPEG-2 transport stream that enables a CM to request an upstream
transmission grant from the CMTS so that the CM can register with the CMTS.
interval usage code (IUC) — The CMTS-assigned code that schedules the initial
ranging interval in the upstream time line to the CMTS. Once a transmission interval
is set, the MAC domain then adjusts CM frequency, power, and delay for two-way
communication. IUCs are carried by MAP packets in the MPEG-2 transport stream.
load balancing — The CMTS process that enables CMs to move from one channel to
another so that traffic load is redistributed for improved bandwidth utilization and
reduced consumption of CMTS resources. See dynamic channel change and dynamic
bonding change.
MAC domain — The Open Systems Interconnect (OSI) Layer 2 device through which
radio frequency traffic is forwarded to CMs over downstream channels, and received
over CMTS upstream channels. The minimum MAC domain contains one upstream
and one downstream channel. The Casa CMTS is an integrated Layer 2 MAC domain
and a Layer 3 physical routing device supported by an internal forwarding engine.
Casa CMTS systems can support up to 96 MAC domains.
Casa Systems CMTS

MAC domain CM service group (MD-CM-SG) — All CM upstream and downstream

channels originating from a single MAC domain.
MAC domain descriptor (MDD) — The D3.0 packet carried by the MPEG-2 transport
stream that defines the receive channel set for CMs that support multiple receivers and
transmitters, such as a D3.0 CM with four downstream and four upstream channels.
MAC management message (MMM) — The CMTS message that carries the MPEG-2
transport stream that includes MAC time synchronization packets, UCD and MAP
packets, and the MDD.
MAP — Bandwidth Allocation Map packet carried by the MPEG-2 transports stream
that instructs the CM when to transmit over an upstream timeline by specifying when
time zero (t0) begins. The MAP carries a 32-byte field to indicate the service identifier
(SID) to declare “who” is transmitting, the interval usage code (IUC) that indicates
“what” type of transmission, and the t0 timing offset to indicate “when” to begin the
upstream transmission interval from t0 on the timeline.
minislot — A series or group of time components that make up one upstream time
interval. These intervals vary in size starting at time zero (t0) until the end of the
interval where t0 begins again. Time Division Multiplexing (TDM) scheduling sets
both long and short intervals in the timeline where the interval size is based on traffic
conditions. Each minislot in each interval is 6.25 microseconds.
MPEG-2 transport stream — The 188-byte packet carried in the MMM that includes
MAC time synchronization packets, UCD and MAP packets, and the MDD. An
MPEG-2 transport stream with a program identifier (PID) of 1FEE indicates that the
stream originates from a MAC domain. The MPEG-2 transport stream carries
modulated digital content signals to cable distribution areas.
network side interface (NSI) — The OSI Layer 3 routing side of the CMTS. The NSI
supports the IP routing protocols such as OSPF, RIP, BGP, and IS-IS to support
routing between neighbor routers. The CMTS uses 10/100 Fast Ethernet for
out-of-band remote management, as well as GigE and 10GigE interfaces for voice,
data, and video traffic routing. The NSI uses the CMTS forwarding engine to route
network protocol traffic to network destinations.
Orthogonal Frequency Division Multiplexing (OFDM) — A downstream data

transmission method where a large number of closely spaced or overlapping
Casa Systems CMTS

very-narrow-bandwidth orthogonal (mutually exclusive) QAM signals are transmitted

in a given channel. It divides a high baud rate symbol stream into multiple parallel
lower baud rate symbol streams, each of which are modulated on a different carrier
without requiring guard bands. Spreading coding over multiple frequency-overlapping
yet nonleaking subcarriers enables a subcarrier to correct for another underperforming
one without spectral efficiency (SE) loss, with more spectrum capacity and better
throughput than legacy single-carrier QAM at a relatively low data rate.
Orthogonal Frequency Division Multiple Access (OFDMA) — OFDMA handles the

upstream function for DOCSIS 3.1. OFDMA upstream channels can span more
spectrum than TDMA or S-CDMA upstream channels and also use Low Density
Parity Check (LDPC) for Forward Error Correction (FEC) and have other attributes
specific to OFDM technology. OFDMA channels use subcarriers, some of which are
used for physical layer monitoring. Subcarriers used for transporting MAC-layer data
are grouped in sets of eight (50-KHz subcarrier spacing) or 16 (25-KHz subcarrier
spacing) contiguous subcarriers in the frequency dimension and K symbols in the time
dimension to create minislots in a frame structure.
QAM64 — A 64-state modulation method that combines phase angle and amplitude
signals over downstream channels, operating over 6-MHz channels at 30 Mbps.
QAM256 — A 256-state modulation method that combines phase angle and amplitude
signals over downstream channels, operating over 6-MHz channels at 42 Mbps.
radio frequency interface (RFI) — The combination of at least one upstream and one
downstream channel to form the DOCSIS MAC domain. The CMTS provides both
upstream and downstream interfaces for transmission and receipt of digitized content
and data services over fiber network trunks and coaxial cable to and from the
subscriber distribution areas.
ranging backoff algorithm — The CMTS process that tells a CM how long to wait
before retransmitting another initial ranging request. The algorithm reschedules and
increases initial ranging transmissions at random intervals for CMs to avoid collisions.
Ranging backoff values are expressed exponentially, such that a value of 3
corresponds to 23 (or eight retry attempts).
receive channel set (RCS) — The downstream channels over which a CM receives
traffic from the MAC domain. The MDD in the MPEG-2 transport stream informs the
CM about the receive-channel configuration and the RCS to be used by that CM.
Casa Systems CMTS

restricted load balancing group (RLBG) — A configured subset of channels in a

CM’s service group; the channels available for load balancing are interactively
selected and saved in the CMTS running configuration file.
service group (SG) — The group of downstream channels over which a CM receives
traffic from the MAC domain, or the group of upstream channels over which the CM
transmits to the CMTS. The combination of both upstream and downstream SGs is
known as the CM-SG or DOCSIS fiber node.
service identifier (SID) — The 14-byte portion of the 32-byte packet carried in the
MAP that identifies a particular CM attempting to transmit upstream to the CMTS.
static load balancing — The traffic balancing method that instructs the CM which
channels to use after initial ranging. For D3.0 CMs, when a CM sends its REG-REQ,
the CMTS responds with a REG-RSP to instruct the CM to select the channels.
transmit channel set (TCS)— The CMTS 5-MHz to 42-MHz upstream channels over
which a CM transmits traffic to the CMTS MAC domain. Upstream channel
information is determined by the UCD and MAP packets carried in the MPEG-2
transport stream from the CMTS.
trivial file transfer protocol (TFTP) — The IETF protocol used by the CMTS to
transfer a CM configuration file from a dedicated TFTP server to a target CM, so that
the CM can properly configure itself for two-way communication with the CMTS.
upstream channel — The CMTS 5-MHz to 42-MHz channel over which a CM

transmits traffic to the CMTS over a transmit channel set (TCS). Upstream channel
information is determined by the UCD and MAP packets carried in the MPEG-2
transport stream from the CMTS.
upstream channel descriptor (UCD) — The packet carried in the MPEG-2 transport
stream that describes the upstream channels over the which a CM transmits to the
CMTS. Each UCD describes a frequency, width, and burst profile with a set of burst
descriptors. Each UCD has one associated MAP that instructs the CM on “when” to
transmit over an upstream timeline.
upstream service group (US-SG) — The group of CMTS upstream channels over
which a CM transmits traffic to the CMTS over a transmit channel set (TCS); the
group of upstream channels to which a CM has access.
Casa Systems CMTS

2-1
Chapter 2. Using the Casa command

line interface
About this chapter

The Casa command line interface (CLI) allows CMTS users to configure, manage,
and monitor Casa CMTS platforms running the CMTS software. The CLI is supported
on directly-attached consoles and over Telnet and SSH sessions to the CMTS and is
similar in operation to the industry-standard command line interfaces found in
telecommunications products today.
Topic Page
Getting started with the CLI 2-1

CLI basic concepts 2-5
CLI operations 2-8
Changing the CLI prompt 2-18
Creating command aliases 2-18
Deleting existing settings 2-19
Getting started with the CLI

The CLI is a text-based interface that allows you to configure and manage all aspects
of Casa CMTS. Use the CLI to create and edit the Casa CMTS configuration file, as
well as display system status and data from a directly-attached PC or system console,
Telnet applications, or Secure Shell protocols (SSH1 and SSH2).
Casa Systems CMTS

Accessing the CLI
Accessing the CLI
You access the Casa CLI locally from a system console (serial connection) or
remotely over Telnet or SSH.
From a system console
Perform the following steps for accessing the Casa CLI over a system console
attached to Casa CMTS:
1. Connect a PC to the CMTS by connecting one end of the RJ45 cable to the serial
RJ45 console port.
— On C2200 CMTS systems, connect the other end of the cable to the
RJ-45-to-DB-9 adapter, then connect the adapter to the serial port on the PC
or terminal to complete the console port cable connection.
— On C1G, C3200, C10G, C100G, and C40G CMTS systems using the supplied
RJ45 to DB-9 serial cable, connect the DB-9 end to the serial port on the PC
or terminal to complete the console port cable connection.
Note: If you are connecting a PC laptop computer of recent manufacture that

does not have a DB-9 port, you need to create the console connection over a
terminal server or by using a special RS232 USB console adapter and cable
available from several manufacturers.
2. Power on the PC and start a terminal emulation program, such as HyperTerminal.

3. Configure the terminal with the following default settings:
115200 baud
8 data bits
No parity generation or checking
1 stop bit
No flow control
4. Press [ENTER] on the PC keyboard until the CLI login prompt appears:
CASA login:
5. Log in using the user name root and the password casa.
CASA login: root
password: casa
Casa Systems CMTS

Using the Casa command line interface 2-3
Accessing the CLI
From Telnet or SSH sessions
Perform the following steps to access the CLI over a Telnet or SSH connection.
1. With the CMTS enabled on a network, connect a network cable from Ethernet
port 0 (eth 0) on the CMTS to a network patch panel, Ethernet switch, or device
such as a PC or laptop computer.
2. For Telnet, start the Telnet client. The default Telnet port is 23. At the Telnet
prompt, enter open ipaddress, then specify the IP address of the CMTS Ethernet
port. The Casa-assigned default management port IP address is 192.168.2.100
If you are using a program such as PuTTY, set the Connection Type to Telnet to
automatically change the port number to 23, then enter the management port IP
address in the Host Name block and select Open.
3. For SSH, start the SSH client and specify the host name or address for the system.
The default SSH port is 22 and default management port IP address is
192.168.2.100. If using the password authentication method, the system prompts
you for a password. If you use a valid public key or no authentication is required,
you automatically connect to the system.
If you are using a program such as PuTTY, set the Connection Type to SSH to
change the port number to 22 automatically, then enter the management port IP
address in the Host Name block and select Open.
4. Log in using the user name root and the password casa.
login as: root
root@192.168.2.100 password: casa
CASA#
Supported SSH clients
Casa CMTS supports SSH clients such as the following:
• SecureCRT® — For Microsoft Windows platforms

• PuTTY — For Microsoft Windows platforms
• OpenSSH— For UNIX and Linux platforms
Other SSH clients may work. However, Casa has not tested all possible SSH clients
with the Casa CMTS.
Casa Systems CMTS

Entering privileged mode
Before you can make changes to the CMTS configuration, you must initiate privileged
mode using the enable command and by specifying a password. On new systems, the
default password is casa.
Example: Entering and exiting privileged mode

CASA login: root
Password: casa
CASA> enable
Password: casa
CASA#
To exit privileged mode, use the exit command.
CASA# exit
CASA>
Entering configuration mode
Use the config command to enter CMTS configuration mode. Configuration mode
allows you to make changes to the running CMTS configuration file.
Example: Entering configuration mode.

CASA login: root
Password: casa
CASA> enable
Password: casa
CASA# config
CASA(config)#
Exiting and logging out of the CLI
To exit the current CLI session with the CMTS, use the exit command to revert back
to the top level prompt, then execute the logout command to close the session.
Example: Logging out of the CLI session

login as: root
root@192.168.2.100 password: casa
Casa Systems CMTS

CLI basic concepts
CASA> enable
password: casa
CASA# exit
CASA> logout
CLI basic concepts

The Casa CMTS CLI structure consists of a command hierarchy of configuration
objects and parameters. When you use the CLI to create, edit, or modify the Casa
CMTS configuration, the software maintains the most recent changes in the running
configuration. When you complete the editing session, you can save the new running
configuration to the default file named startup-config.
It is important to understand the states of the CMTS configuration file during a

configuration session and when the edited configuration is saved.
Startup configuration
The default CMTS bootup configuration is provided in the file named startup-config.
You can have any number of startup configuration files in the main CMTS directory
from which you can boot the system. Once the system has booted and is fully
operational, the startup configuration becomes the running configuration during
editing sessions, as described in the next section.
Running configuration
The running configuration controls the current operational state of the CMTS. As you
open system configuration objects and edit specific parameters, the CMTS applies the
new settings to the system immediately. When you are finished with the editing
session, you need to save the most recent settings to the default startup-config file (or
to a uniquely named file). By default, the CMTS uses the startup-config file at the next
system restart or reboot.
Casa Systems CMTS

CLI structure summary
Example: Saving the running configuration
To save the latest configuration settings from the running configuration to the default
startup-config file, use the following command:
CASA(config)# copy running-config startup-config
To display the running configuration at any time, use the following command:
CASA(config)# show running-config
CLI structure summary
The Casa CMTS configuration file is a hierarchy of objects, parameters, and

commands that operate the configuration, as covered in Table 2-1.
Table 2-1. CLI elements
Element Description
object An object is a configuration grouping that contains a set of parameters that

belong to that object. Routing protocols, such as BGP and RIP are
considered objects in a CMTS configuration. Some objects are hierarchical
and contain sub-objects. In CMTS configuration mode, the current object
context displays in parentheses ( ). Some examples of objects are:
• router bgp
• interface vlan
• router rip
parameter A parameter is a value used by an object. Parameters are available at all
configuration levels of the CLI. For example, the BGP configuration object
includes parameters such as:
• distance
• neighbor
• redistribute
Each parameter affects how BGP operates in a given network
Casa Systems CMTS

CLI hierarchies
Table 2-1. CLI elements (continued)
Element Description
command A command is a mechanism for applying an immediate action to the CMTS
configuration. Commands are available throughout all levels of the CLI.
Global commands are those commands that are available throughout the
CLI and can operate at one or more levels. Some example commands are:
• clear
• config
• copy
• del(ete)
• ping
• show
CLI hierarchies
The CLI prompt always indicates your location in the CLI hierarchy. It does not show
a complete object path hierarchy; instead it shows the object (and instance, if
applicable) in which you are located, as covered in Table 2-2.
Table 2-2. CLI prompts
Description Example
Top-level prompt (default) CASA# show running-config

Config-level prompt CASA(config)#
Config-level prompt — object CASA(config)# router bgp 6
and (possibly) unique CASA(config-router-bgp)#
instance
Moving up and down through the hierarchy

Example: Entering the BGP object context
CASA#
CASA# config
CASA(config)# router bgp 1
CASA(config-router-bgp)#
Casa Systems CMTS

CLI operations
The exit and end commands allow you to navigate back to the previous level of the
CLI. Entering the exit command closes the current CLI session.
Example: Exiting the current CLI context

CASA(config-router-bgp)# end
CASA(config)# end
CASA# end
CASA> exit
CASA(config-router-bgp)# exit
CASA(config)# exit
CASA# exit
CLI operations
The following sections describe usage techniques for working with Casa CMTS
configurations at the command line.
Displaying available objects and parameters
At any point in the CLI you can enter the question mark character (?) to display a
listing of commands that you can execute at the current object hierarchy as well as a
list of global commands. Note that you can also type just the command, a space, and
press [TAB] to get the same result. Refer to Table 2-3.
Table 2-3. Displaying available commands
Command Function
CASA> ? Displays the list of commands available from

the top level of the CLI
CASA# ? Displays the list of commands from Casa
privileged mode after executing the enable
command and entering a valid password,
such as enable/casa (default).
CASA(config)# ? Displays the list of commands available at the
top level of the configuration mode.
Casa Systems CMTS

Entering parameters
Table 2-3. Displaying available commands (continued)
Command Function
CASA(config-context># command ? Displays the list of subcommands or

parameters available in the current context of
CASA(config-context># command [TAB] the CLI configuration mode. Entering a
question mark and pressing [TAB] provides
Example: the same results.
CASA(config-router-bgp)# distance ?
<1-255> Administrative distance
bgp BGP distance
CASA(config-router-bgp)# distance [TAB]

<1-255> Administrative distance
bgp BGP distance
Entering parameters
The CLI parameters, both required and optional, can be either a variable or one of
multiple predefined options or settings.
The following example takes a variable, a value that you supply, such as the unique IP
address 192.168.0.150:
Example: Entering an IP address

CASA(config)# interface gige 6/3
CASA(config-if-gige 6/3)# ip address ?
<ip_address> A.B.C.D
CASA(config-if-gige 6/3)#ip address 192.168.0.155
The following example takes a predefined option from a list of displayed options:
Example: Displaying a list of predefined command options

CASA(config)# system monitor ?
cpu set cpu monitor
fan set fan monitor
log set log
memory set memory monitor
power set power monitor
temperature set temperature monitor
CASA(config)# system monitor cpu enable
Casa Systems CMTS

Entering parameters
The following example takes both a user-specified variable (a password) and

predefined options. If you add the password string instead of secret, you can end there
or specify authenticate, which autocompletes to authenticate snp, in which case you
must add either the send-only or validate option before pressing [ENTER].
Example: Entering a command with variables and predefined options

CASA(config-router-isis)# area-password ?
<string> The ISIS area password (maximum 254 characters)
secret Specifies an ENCRYPTED password will follow
CASA(config-router-isis)# area-password abcXyZ ?
<cr>
authenticate Authentication
CASA(config-router-isis)# area-password abcXyZ authenticate snp ?
send-only Send but do not check PDUs on receiving
validate Send and check PDUs on receiving
CASA(config-router-isis)# area-password abcXyZ authenticate snp
validate
The following example configures logging to a SYSLOG host at the specified IP

address with additional options. After configuring the host target, the logging
command then specifies the level of log messages (in this example, alerts) that the
CMTS sends to the SYSLOG server. The level can be alerts, critical, debugging,
emergencies, errors, informational, notifications, or warnings.
CASA(config)# logging ?
facility facilityCode
host logging server vrf
non-volatile logging level for local log on non-volatile memory
(flash memory)
source-interface specify source interface
syslog logging level for syslog receiver
system logging level for console output
trap logging level for trap
volatile logging level for local log on volatile memory
(RAM FS)
CASA(config)# logging host ?
<ip-address> A.B.C.D, <port #> default is 514
<ipv6_addr> xxxx:xxxx:xxxx:...:xxxx <port #> default is 514
vrf specify the vrf name for logging host
CASA(config)# logging host 192.168.8.232
<cr>
CASA(config)# logging syslog ?
alerts emergencies and alerts events
critical emergencies, alerts and critical events
…
CASA(config)# logging syslog alerts ?
<cr>
Casa Systems CMTS

Displaying help text
Displaying help text
You can display the list of available command options and global commands from
your current position in the CLI. Use the question mark (?) to display a brief summary
of the objects or parameters available to you. For example, to show what you can
configure under the IS-IS protocol, as well as display the global commands, enter the
router isis configuration context and type the question mark character. The
predefined options are also followed by brief descriptions.
Example: Displaying context-specific objects, parameters, and global

commands
CASA(config-router-isis)# ?
address-family Enter Address Family command mode
area-password Configure the authentication password for an area
authentication authentication
domain-password Set the authentication password for a routing
domain
…
----------global commands---------------
adduser add a new user
alias alias for command
cable CMTS Configuration
clear Reset functions
…
CASA(config-router-isis)#
Using show commands
The CMTS show commands provide a mechanism for displaying all aspects of the
running configuration. When you use the show ? command from the top-level prompt
or from the config prompt, the system displays a list of objects from the running
configuration.
Example: Displaying options for available information and statistics

CASA> show ?
aliases aliases
application show application
arp arp entry
bonding-group bonding-group
bootdev system boot device
cable CMTS Configuration
channel-utilization-interval channel utilization interval
…
Casa Systems CMTS

Using show commands
The following show commands provide examples of how to display information

associated with specific configuration objects. The router isis example shows that
you can use a show command even for an unrelated object.
Example: Displaying object information and statistics

CASA(config)# show bootdev
System boot device is: net
Target IP: 192.168.8.230, Host IP: 192.168.8.2
Boot Image: casa_6000.gz.rel6.0.3_build3
CASA(config-router-isis)# show system

Product: C3000, Module: SMM
Major rev 30, Minor rev 0
serial_no = SV30B04S0006
CFE version 2.1.4
System Time: Thu Apr 14 08:43:49 EDT 2011
System Uptime: 0 d, 0 h, 43 m, 3 s
128MHz, 5 PPM Crystal Clock
…
CASA(config-router-isis)# show telnet port
telnet port 23
Table 2-4 summarizes the show command usage at the Casa CMTS.
Table 2-4. show command usage
Command Function
CASA> show ? Displays the set of valid show

commands.
CASA(config># show ? Displays the list of commands
available at the top level of
configuration mode.
CASA(config-<context>)# show <object> Displays the settings of a
specific configuration context
object from the running
configuration.
Casa Systems CMTS

Filtering show command output
Table 2-4. show command usage (continued)
Command Function
Example: The example indicates the

available PacketCable objects
CASA(config-router-isis)# show packetcable ? you can filter the output on.
cms COPS server The log object requires the
commit state of commit name of the log file.
gate gate
gateid gateid
global gate global parameters
log log file
mgpi mgpi
rks record keeping server
CASA(config-router-isis)# show packetcable log 310
Some CMTS show commands accept output modifiers that filter the display so that
only desired information appears. Use this feature when a particular show command
output might be excessively long and when you need unique aspects. Filter the output
by entering the pipe or vertical bar (|) character followed by a specified operator and
filter in a quoted string (if a space character is included) or regular expression (regex).
Pipes can also be used in the quoted string or regex to indicate multiple entries. The
following example filters an OSPF configuration by certain parameters. Only the valid
matching entries appear, while others (such as “Other settings”) are ignored.
Example: Using the vertical bar to filter output

CASA# show ip ospf | include "Process uptime|Process bound|Minimum
hold|Other settings"
Process uptime is 6 hours 56 minutes
Process bound to VRF default
Minimum hold time for LSA throttle 5 secs 0 msecs
The specified filter uses operators that control how the information is filtered from the
display. For show commands that support the output modifiers, the following
operators are available:
• begin — Displays all lines that begin with the specified filter.
Casa Systems CMTS

• include — Displays lines containing the specified filter. You can specify multiple
entries separated by pipes in the quoted (or dotted) string itself. If an entry is
invalid, it is omitted in the output, as indicated in the previous example.
• exclude — Omits lines containing the specified filter. Extended pipes can be used
in the quoted (or dotted) string to exclude multiple entries.
• count — Displays a count of the number of lines containing the specified filter at
the very end of the output.
• count-only — Displays a count of the number of lines containing the specified
filter while suppressing output.
Example: Filtering lines with a specified entry in show output

CASA# show ip-route | ?
include Include lines that match
exclude Exclude lines that match
count-only Count lines outputted while suppressing output
count Count lines outputted
begin Begin with the line that matches
CASA# show ip route | include connected

Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
C>* 10.230.1.0/24 is directly connected, docsis-mac1
C>* 10.230.2.0/24 is directly connected, docsis-mac1
C>* 127.0.0.1/32 is directly connected, loopback
O 192.168.3.0/24 [110/1] is directly connected, gige1, 02:23:31
C>* 192.168.3.0/24 is directly connected, gige1
C>* 192.168.8.0/24 is directly connected, eth0
Example: Filtering to include indented lines

CASA# show run | include "interface docsis-mac| downstream"
interface docsis-mac 1
downstream 3 interface qam 10/0/2
…
Example: Filtering using a regular expression (regex)

CASA# show interface upstream | include
^interface\s+upstream\s+.+\w+\s+$|spectrum-rule\s+1\s+$
interface upstream 1:0/0.0
spectrum-rule 1
…
Casa Systems CMTS

Using command auto-completion
Using command auto-completion
The CLI uses a command completion feature that automatically completes typing an
object or parameter name. Pressing the keyboard [TAB] executes the completion.
Note the following requirements for using command completion:
• You must type an entry until it is minimally unique on the command line before
pressing [TAB] auto-completes the entry. If there are two commands that begin
with the same spelling, the CLI cannot differentiate between the two until you
type enough letters to distinguish one from the other.
• The entry must be a valid object or parameter.
• The CLI does not auto-complete user-configured instances or values.
Example: Using the TAB key to execute command auto-completion

CASA# co[TAB]
config entering config mode
copy copy command
console-password change console login password
CASA# con[TAB]
config entering config mode
console-password change console login password
CASA# conf[ENTER]
CASA(config)#
Pressing [TAB] after entering just co or con, which are not minimally unique, results
in prompting for further characters to make the entry unique. Pressing [TAB] after
entering the full conf completes the command line so that you can press [ENTER] to
enter configuration mode.
Displaying and executing from command line history
The CLI maintains a history of commands that you entered in the current editing
session. Use the [UP-ARROW] key on your keypad to re-display commands starting
from the most recent to the least recent entry with each key press. Once the desired
command is displayed, you can edit the command line and then re-execute the
command without re-entering the entire line.
Casa Systems CMTS

String requirements for the CLI
String requirements for the CLI
When a parameter requires a string, such as user names, locations, and contact names,
the following rules apply:
• Any printable character is acceptable.

• If the string contains multiple words with blank spaces, the string must be
enclosed in double quotation marks (“”), or as a dotted sequence (such as
firstword.secondword) in show running-config commands.
• Strings are case sensitive (that is, “route” is not the same as “Route”).
Note: There are no set restrictions on string lengths, as some parameters

accept longer or shorter strings based on DOCSIS standards and CM
technologies.
Setting date and time intervals
Several configuration objects and actions require setting a date (such as a calendar day
and month) or time interval that reflects a number of hours, minutes, and seconds
(such as a system reboot timer). The CLI accepts multiple entry formats for setting
these intervals.
• hhh or hh — Hours, usually 0 to 23 for a single day, or 0 to 168 for hours over
multiple days
• mmm or mm— Minutes, usually 0 to 59 within a single hour, or 0 to 999 for
minutes over multiple hours.
• day — Numeric day in a calendar month in the range 1–31 depending on the
actual month.
• month — Month as a text string from January through December.
• YYYY-MM-DD — Specifies a date in the format year-month-day, such as
2015-05-20 (same as May 20, 2015).
Casa Systems CMTS

Common CLI error messages
Example: Specifying date and time parameters
The following command example sets a CMTS “upgrade” reboot for 11:00 p.m. on
April 30 with a reminder set for 30 minutes prior to the reboot.
CASA# system reboot reason upgrade at 23:00 30 April remind 30
Broadcast message from root (Thu Apr 14 22:53:21 2011):

System reboot scheduled for Sat Apr 30 23:00:00 2011
Broadcast message from root (Thu Apr 14 22:53:21 2011):
System reboot reason: upgrade
Common CLI error messages
Table 2-5 explains the some of the more common messages that the CLI returns in
response to user input:
Table 2-5. Common CLI error messages
Message Meaning
Syntax error The specified input is incorrect. Check for any typos.
% Command incomplete. The specified command requires additional input or
parameters. Use the ? character to display the valid
option(s) for the command.
Doesn’t match current Too many parameters were specified. Check the format
mode. of the command for the expected input.
% Unknown command. The specified command is not valid or the command does
not operate at the current level of the CLI.
% There is no matched An invalid command, followed by the ? character, was
command. entered on the command line. Check for typos.
Incomplete command. The command requires additional input or parameters.
Use the ? character to display the valid option(s).
Ambiguous command. The command was attempted at the incorrect level of the
CLI or is incomplete. Check to see if you are in
configuration mode and retry the command.
Invalid date format. The required date was not entered as expected. The date
format is YYYY:MM:DD to represent year:month:day.
Invalid metric value. The specified metric value was not in the accepted range.
Use the ? character after the metric parameter to display
the accepted input.
Casa Systems CMTS

Changing the CLI prompt
Changing the CLI prompt

By default, the system uses the prompt CASA-CMTS# as the top level prompt in the
privileged mode. To change the prompt, use the following command:
CASA-CMTS# hostname <string>
Example: Changing the CLI prompt

CASA-CMTS# hostname CASA
CASA#
The prompt supports up to 64 alphanumeric characters. If you want the prompt to

contain spaces, enclose the prompt in quotation marks.
Creating command aliases

A command alias is a user-defined shortcut to an existing command. You might want
to create aliases for commands you use frequently. The following example creates the
alias au for the Casa adduser command.
Example: Creating a command alias

CASA# alias au adduser
Note that once you create an alias, the command completion feature in the CLI
displays the alias preceded by the asterisk (*) character.
Example: Identifying a command alias

CASA# a[TAB]
*au adduser
Enclose an alias containing space characters in quotation marks. To display the

currently configured aliases, use the show aliases command.
Example: Displaying the list of current command aliases

CASA# show aliases
alias au "adduser"
Casa Systems CMTS

Deleting existing settings
Deleting existing settings

Most parameters support the no form of the command to remove previously set
values. In most cases, this cancels the current setting in the running configuration and
reverts back to the original default value (if applicable).
For example, to remove a previously set command alias, simply precede the command
with the word no. The alias will no longer appear in the list of options.
Example: Using the “no” command to remove a configured entry

CASA# alias au adduser
CASA# a[TAB]
*au adduser
CASA# no alias au
CASA# a[TAB]
Casa Systems CMTS

3-1
Chapter 3. Administering CMTS

security
About this chapter

This chapter provides information on administering the cable modem termination
system (CMTS), as covered in the following topics.
Topic Page
CMTS administration overview 3-2

Configuring the CMTS management port 3-2
Changing the default CMTS password 3-3
Encrypting passwords 3-4
User management and security control 3-4
Adding user command execution privileges 3-5
Enabling SSH sessions to the CMTS 3-6
Setting the Telnet port and other settings 3-6
Configuring TACACS+ server authentication 3-7
Configuring RADIUS server authentication 3-8
Configuring TACACS+/RADIUS loopback interface 3-9
RF cable security settings 3-10
Enforcing TFTP transfer of the CM config file 3-10
Configuring TFTP options 3-11
Enforcing CPE VRFs in an IP bundle 3-11
Enabling DHCP authorization 3-12
Casa Systems CMTS

CMTS administration overview
Topic Page
Enforcing BPI and BPI+ 3-13

Configuring an encryption algorithm 3-14
Changing the security association descriptor TLV length 3-14
Configuring shared secrets to protect the CM configuration file 3-14
Enabling configuration file learning 3-16
Configuring Source Address Verification (SAV) rules 3-16
CMTS administration overview

CMTS administrators and operators need to perform essential tasks to properly secure
the system for users who need to log in, as well as perform tasks that prepare the
system for handling live upstream and downstream traffic. For example, creating
passwords for Telnet and SSH user logins prevents unwanted intrusions to the system.
Also, setting the system clock and synchronizing with a Network Time Protocol
(NTP) server helps ensure that event logs are correctly time-stamped when diagnosing
system and network problems with other devices.
Note: Login for non-superusers is enabled to the active Switch and Management
Module (SMM) only.
Configuring the CMTS management port

The management port allows CMTS operators and users to configure the system over
an IP network. The Casa CMTS provides a separate Fast Ethernet management port
that provides an “out-of-band” connection to the system where system management
traffic is kept independent of the customer network interfaces. However, other GigE
and XGigE ports can be used for remote management over Telnet or SSH.
The Fast Ethernet interface (eth0) has the following default IP address and subnet
mask: 192.168.2.100 255.255.255.0.
Casa Systems CMTS

Administering CMTS security 3-3
Changing the default CMTS password
To change the default IP address and subnet mask, perform the following steps:
1. Log in to the CLI using the root login and the casa password.
2. Enable CMTS privileged (enable) mode to configure the CMTS, with the default
password casa.
3. Enable configuration mode using the config command.
4. Enter the show interface eth command to show the IP addresses of the Ethernet
interfaces.
5. Enter the interface eth 6/0 command to change the default IP address and
network mask of the CMTS management port.
Example: Logging in and configuring the management IP

CASA login> root
Password: casa
CASA> enable
Password: casa
CASA# config
CASA(config)# show interface eth

interface eth 6/0
ip address 172.16.8.220 255.255.255.0
interface eth 7/0

ip address 172.16.8.221 255.255.255.0
CASA(config)# interface eth 6/0

CASA(config-if-eth 6/0)# ip address 135.2.0.0 255.255.255.0
Changing the default CMTS password

After you log in to the system in privileged (enable) mode, you need to change the
Casa default password for enhanced system security. The following example changes
the Casa default password from casa to a new password. In this example, the new
password is abc123.
Example: Logging in and setting a new password

CASA login: root
Password: casa
Casa Systems CMTS

Encrypting passwords
CASA> enable
Password: casa
CASA# password abc123
To revert to the default password (casa), use the reset password command from a
locally attached console. (See the appropriate hardware installation guide for the
CMTS system you are using.) You cannot reset the password over a network
connection.
Example: Reverting to the default CMTS password

CASA# reset password
Encrypting passwords
By default, the CMTS does not encrypt passwords. To encrypt the privileged (enable)
mode password, use the password command with the encrypted option.
Example: Logging in and encrypting a password

CASA login: root
Password: casa
CASA> enable
Password: casa
CASA# password encrypted abc123
To encrypt other passwords, such as Message Digest 5 (MD5) passwords, enter

configuration mode and enable service password-encryption.
Example: Enable password encryption

CASA# config
CASA(config)# service password-encryption
User management and security control

User management and security control provides the administrative levels for
accessing and modifying aspects of the Casa CMTS. Users can be added, deleted or
Casa Systems CMTS

Adding user command execution privileges
modified. Users are assigned a privilege level during creation that can be modified
later. The privilege level is a number from 1 through 15, with 1 being the lowest and
15 the highest level. The users with privilege level 15 are called superusers.
User management and security control is possible only by superusers in privileged

(enable) mode. The privilege level of a user determines the access rights of the user to
view, monitor, change, and maintain the CMTS configuration depending on the
commands permitted for that user as determined by privilege commands. A superuser
can perform all possible functions.
While user management allows valid users to gain access to the system and maintain
the status of the users, security control governs the specific actions performed by
users.
The root user is a special superuser that cannot be deleted. The system always has the
user root and the password of this user can be changed by a superuser. Only a
superuser can perform all user management. An exception is resetting the password of
user root to a default password. This operation is permitted only from the console of
the CMTS and can be executed by any user. See the section “Changing the default
CMTS password”.
Adding user command execution privileges

Telnet and SSH users are added to the system configuration file with the adduser
command. Each configured user should have a unique username and password with an
assigned privilege level, as covered in the previous section. You can also specify
showing the password as plain text in show user output by using the
encrypted-password modifier on the command line.
Example: Add Telnet/SSH user and command privileges
The following CLI session creates the user named fred at privilege level 8. This user
must specify the configured password for access to the CMTS. A password must
contain between five and eight characters using a combination of upper and lower
case letters and number. If the privilege level is omitted, the configured user defaults
to privilege level 1.
CASA(config)# adduser fred privilege 8 encrypted-password duZK123
Casa Systems CMTS

Enabling SSH sessions to the CMTS
User fred’s allowed command execution are set based on his assigned privilege level.
Command execution can be separate for exec and configuration CLI commands. The
command for this is the privilege command, with the following example:
CASA(config)# privilege exec [all] level 8 “clear cable modem reset”

CASA(config)# privilege configure all level 8 “interface docsis-mac”
Example: Display current CMTS users
To display the current list of users configured at the CMTS where you are logged on,
execute the show user command. In this case, the user fred password is plain text.
CASA# show user

user root privilege 15 encrypted-password q7ftALg6L2pVI
user fred privilege 8 encrypted-password duZK123
Enabling SSH sessions to the CMTS

SSH clients can be either local or authentication server (TACACS+ or RADIUS)
users. SSH is enabled by default with a maximum of 64 concurrent SSH sessions. The
ssh enable command allows you to control whether SSH sessions are allowed.
If you choose to disable SSH using the no form of the command, copy the running
configuration to the startup configuration and then reboot the CMTS to disable SSH
by default. For information on copying the system configuration file, see Chapter 4,
“Managing the CMTS configuration file.”
Example: Enable and disable SSH
To enable and disable SSH at the CMTS:
CASA(config)# ssh enable

CASA(config)# no ssh enable
Setting the Telnet port and other settings

The telnet port command sets the port for Telnet sessions to the CMTS. The default
Telnet port is 23. A Telnet port can be configured in the range 1–65535.
Casa Systems CMTS

Configuring TACACS+ server authentication
Example: Configuring the Telnet port
To reconfigure, enable, and display the Telnet port number at the CMTS:
CASA# config
CASA(config)# telnet port 23
CASA(config)# show telnet port

telnet port 23
Example: Configuring the maximum number of Telnet sessions
The line vty command sets the maximum number of concurrent Telnet sessions to the
CMTS. The default setting is the maximum 31 sessions.
CASA# config
CASA(config)# line vty 12
Example: Configuring session timeouts
By default, there is no expiration time for Telnet and SSH sessions. The
telnet timeout command sets the expiration time for Telnet or SSH sessions that have
become inactive. The timeout range is 1–1440 minutes (maximum 24 hours).
The following CLI session closes an inactive Telnet session after 60 minutes.
CASA# config
CASA(config)# telnet timeout 60
Configuring TACACS+ server authentication

Terminal Access Controller Access Control System (TACACS) is a security
application that provides centralized validation of users attempting to gain access to
CMTS network side interface (NSI). Perform the following steps to configure
TACACS+ at the CMTS:
1. Configure the TACACS+ server host IP address string and set the encryption key
to be sent in authentication messages to the TACACS+ server. Specify 0 to send
the key in clear text, or specify 7 to send the key as encrypted.
Casa Systems CMTS

Configuring RADIUS server authentication
2. Set a timeout value in seconds in the range 1–60. The session between the
TACACS+ server and the CMTS times out when there is no activity detected
during this time period.
3. Configure TACACS+ login and password authentication.
4. Optional: Configure ASCII clear text authentication.
Example: Configure TACACS+ host IP, authentication key, and timeout
The following CLI session sets the TACACS+ server host IP address and server
access encrypted keyword, with encrypted indicated by the trailing 7 value.
CASA(config)# tacacs-server host 192.168.10.1 key abcdXYZ1234 7
Example: Enable TACACS+ login and password authentication
The following CLI session enables password and login authentication at the
TACACS+ server:
CASA(config)# aaa authentication enable default group tacacsplus

enable
CASA(config)# aaa authentication login default group tacacsplus
CASA(config)# aaa authentication login tacacsplus
Example: Configure ASCII clear text authentication
Clear text authentication transmits user names and passwords as unencrypted. The
following CLI session enables TACACS+ ASCII clear text authentication:
CASA(config)# aaa authentication ascii
Configuring RADIUS server authentication

The Remote Access Dial-in User Service (RADIUS) protocol provides centralized
authentication of CMTS users based on user name and password credentials.
Operating as a RADIUS client, the CMTS directs these credentials to a RADIUS
server whenever CMTS users attempt to log in. A login requests to the CMTS via a
RADIUS server is only granted or when the RADIUS protocol is able to verify the
user’s submitted information.
Casa Systems CMTS

Configuring TACACS+/RADIUS loopback interface
Perform the following steps to configure RADIUS at the CMTS:
1. Configure the RADIUS server host IP address string and the UDP authentication
port for RADIUS UDP messages. The known UDP port for RADIUS
authentication is 1812.
2. Set the RADIUS encryption key to be sent in UDP messages to the RADIUS
server. Specify 0 to send the key in clear text, or specify 7 to send the key as
encrypted.
3. Set maximum number of connection retries to the RADIUS server (up to five) and
a server timeout value in seconds (up to 60) if no transmission activity is detected.
4. Configure RADIUS login and password authentication.
5. Optional. Configure ASCII clear text authentication in which usernames and
passwords are transmitted as unencrypted.
Example: Configure RADIUS server

CASA(config)# radius-server host 6.7.8.9 auth-port 1812 key abc123 7
CASA(config)# radius-server retry-max 5
CASA(config)# radius-server timeout 30
CASA(config)# aaa authentication enable default group radius enable

CASA(config)# aaa authentication login radius
CASA(config)# aaa authentication ascii
Configuring TACACS+/RADIUS loopback interface

The CMTS uses internal logical loopback interfaces as the source interfaces for
transmitting and receiving TACACS+ and RADIUS messages between the CMTS
and the authentication servers. The logical loopback interface is configured with an
index number in the range 0–255. An IP address and mask must be configured on the
loopback interface before declaring the interface as the TACACS+ or RADIUS source
interface.
Note: One loopback interface can be configured for both TACACS+ and
RADIUS concurrently.
Casa Systems CMTS

RF cable security settings
Example: Configure TACACS+ and RADIUS loopback interfaces
The following CLI session sets the IP address and network mask for loopback
interface 10. The interface is the source interface for both TACACS+ and RADIUS
authentication messages.
CASA(config)# interface loopback 10

CASA(config-if-lo 10)# ip address 6.7.8.9 255.255.255.0
CASA(config-if-lo 10)# end
CASA(config)# aaa radius-source loopback 10
CASA(config)# aaa tacacs-source loopback 10
The following CLI session creates separate loopback interfaces for TACACS+ and
RADIUS authentication messages.

CASA(config)# aaa tacacs-source loopback 12

CASA(config)# aaa radius-source loopback 10
RF cable security settings

Security over the RF cable network ensures that provisioned cable modems (CMs) get
the expected level of service at the CMTS. Without CMTS security features enabled,
unauthorized CMs could register with the CMTS and come online.
Enforcing TFTP transfer of the CM config file
The tftp-enforce command enables the CMTS to reject registration requests from
CMs that did not download their DOCSIS configuration files from a TFTP server.
This TFTP requirement is set on a per DOCSIS MAC domain.
When TFTP is enforced, only those CMs that have had their configuration files
downloaded from a TFTP server are allowed to register with the CMTS. The default
configuration setting for tftp-enforce is disabled.
Casa Systems CMTS

Configuring TFTP options
Example: Configure TFTP enforce
The following CLI session sets TFTP enforce for all CMs registering on the DOCSIS
MAC 2 domain.
CASA(config)# interface docsis-mac 2

CASA(config-if-mac 2)# tftp-enforce
Optionally, a previously-configured source interface for TFTP traffic can be specified

at the CMTS with the tftp-enforce command. This interface can be the IP bundle
interface or an internal loopback interface.
For additional information on configuring TFTP hosts and TFTP proxy services, see
Chapter 5, “Configuring DHCP, TFTP, NTP, DNS, and logging services.”
Configuring TFTP options
Once an option for TFTP proxies is configured, the CMTS adds the corresponding
address to the TFTP message. The corresponding address can be hw-addr (hardware
address), net-addr (network address), both, or none.
Example: Configure TFTP proxy
The following CLI session configures both the hardware address and the network
address into the TFTP message:
CASA(config)# cable sec tftp-option both
Enforcing CPE VRFs in an IP bundle
You can ensure that CPEs are on the same Virtual Routing and Forwarding (VRF)
instance as the CM using the cable sec cm-vrf-enforce command in the IP bundle and
sub-bundle configurations. This addresses situations where CMs in different
sub-bundles than their multimedia terminal adapter (MTA) devices cannot come
online with the CMTS. IPv4 and IPv6 CMs are supported with this change. The cable
sec cm-vrf-enforce command change does not take effect until CMs are reset.
When enabled, CPEs are enforced to the same VRF as the CM where packets are
allowed to pass and packets from other VRFs are blocked. When the
Casa Systems CMTS

Enabling DHCP authorization
cable sec cm-vrf-enforce parameter is not configured or is disabled (by default), all
packets will pass.
Example:
CASA(conf)# interface ip-bundle 5
CASA(ip-bundle-5)# cable sec cm-vrf-enforce
For details on VRF, see the “Virtual routing and forwarding” chapter in the Casa
Systems – NSI Configuration Guide and Command Reference.
Enabling DHCP authorization
The CMTS uses DHCP to request IP addresses from a DHCP server for CMs and CPE
devices that register with the CMTS. DHCPDISCOVER, DHCPOFFER,
DHCPREQUEST, and DHCPACK messages are exchanged between the DHCP client
and server.
When DHCP authorization is enabled at the CMTS, CPE devices behind the CM get
their IP addresses from the DHCP server IP configured at the CMTS. By default, the
dhcp-authorization parameter under the DOCSIS MAC domain is set to enabled so
that unauthorized IP addresses are not allowed. When dhcp-authorization is set to
disabled, users can create their own IP addresses, which can result in IP address
conflicts, as well as IP and MAC address spoofing.
Once a CM has an assigned IP address, the CMTS uses TFTP to download the CM
configuration file from the TFTP server to the CM. Using the configuration file, the
CM configures itself with the correct parameters to operate with the CMTS.
DHCP authorization, when enabled on a MAC domain, prevents IP address and MAC
address spoofing. The dhcp-authorization property is enabled by default so that
unauthorized IP addresses are not allowed at the CMTS.
Example: Enable DHCP authorization
The following CLI session enables DHCP authorization on DOCSIS MAC 2:

CASA(config-if-mac 2)# dhcp-authorization
Casa Systems CMTS

Enforcing BPI and BPI+
For details on DHCP leasequery and configuring DHCP hosts using the cable
helper-address in the MAC domain IP-bundle, see Chapter 5, “Configuring DHCP,
TFTP, NTP, DNS, and logging services.”
Enforcing BPI and BPI+
The CMTS provides commands that enforce the Baseline Privacy Interface (BPI) and
Baseline Privacy Interface Plus (BPI+) security protocols running between the CMTS
and CMs. BPI authentication protocols protect CM data traffic by preventing
upstream and downstream eavesdropping by other users who are connected over the
same cable. Traffic between the CMTS and the CMs is encrypted using an
encapsulation protocol, as well as a key management protocol called Baseline Privacy
Key Management (BKPM) for processing authentication and authorization key
exchanges between the CM and CMTS.
BPI+ is required on all DOCSIS 1.1 (and later) compliant CMs. Earlier CMs use BPI.
• bpi-enforce — Enforces BPI-authenticated CMs and prohibits traffic for non-BPI

authenticated CMs. Data is not forwarded before a BPI-enabled CM completes
BPI initialization.
• bpi-plus-enforce — Enforces BPI-plus for DOCSIS 1.1 or later CMs. When
enabled, CMs running DOCSIS 1.1 or higher that are not running BPI-plus are
rejected.
Note: When the bpi-plus-enforce setting is enabled at the CMTS, BPI CMs
running DOCSIS 1.1 or higher that are not running BPI+ cannot register with
the CMTS. However, non-BPI CMs are allowed to register.
The following CLI session enforces BPI+:
CASA# cable privacy bpi-plus-enforce
Note that the bpi-enforce and bpi-plus-enforce parameters can be set concurrently in
the CMTS configuration, as each setting operates on different CM types.
Casa Systems CMTS

Configuring an encryption algorithm
Configuring an encryption algorithm
The Casa CMTS supports three encryption algorithms: 40-bit Data Encryption
Standard (DES), 56-bit DES, and 128-bit Advanced Encryption Standard (AES). CMs
that do not support at least 40-bit DES encryption cannot complete BPI.
Example: Configure 40-bit-des encryption algorithm

CASA(config)# cable privacy 40-bit-des
Example: Set encryption algorithm priorities
The following CLI session sets encryption algorithms with priorities, where the first
algorithm assumes the highest priority followed by the subsequent ones. The CMTS
chooses the highest priority algorithm that the CM supports for data traffic encryption.
CASA(config)# cable sec encrypt-alg-priority aes128CbcMode

des40CbcMode des56CbcMode
Changing the security association descriptor TLV length
The cable sa-des-tlvlen-2 command sets the security association type-length value
(TLV) length to two bytes as required by some BPI-authenticated CMs. These CMs
might not be able to register with the CMTS using a one-byte descriptor. Use the no
form of the command to reset the two-byte SA descriptor TLV to one byte.
Example: Set security association descriptor TLV length to two bytes

CASA(config)# cable sa-des-tlvlen-2
Configuring shared secrets to protect the CM configuration file
Because DOCSIS configuration files from an authorized TFTP server provide critical
quality of service (QoS) definitions and other data for CMs, security measures must be
applied to protect the configuration file from unauthorized intercept, theft,
substitution, and potential modification.
The DOCSIS specification supports the shared-secret and shared-secondary-secret

passwords to protect CM configuration files from possible tampering. Once
Casa Systems CMTS

Configuring shared secrets to protect the CM configuration file
configured, these passwords calculate the CMTS Message Integrity Check (MIC)
field that is attached to all DOCSIS configuration files.
The shared-secondary-secret provides a second password should a CM fail to

authenticate with the primary shared-secret. With the secondary secret configured,
the CM must authenticate using either the primary or secondary password in order for
the CM to register and come online. Using a secondary secret allows CMTS operators
to frequently revise the primary password without interrupting a currently active and
online CM with a primary password update.
The CMTS supports a maximum of 198 shared secrets (primary, secondary, and
primary/secondary extended), including those shared secrets defined under the
interface docsis-mac configuration.
Example: Configure primary shared secret
The following CLI session displays the shared secret options, then sets the primary
authentication shared-secret encryption key for non-encrypted messages or encrypted
messages:
CASA(config)# shared-secret ?
0 Specifies that an unencrypted message (clear text)
will follow
7 Specifies that an encrypted message will follow
<mic_string> authentication shared-secret encryption key
CASA(config)# shared-secret 0 DOCSIS
To set the shared-secret Message Integrity Check (MIC) globally:
CASA(config)# shared-secret DOCSIS
To set the shared-secret MIC for the extended TLVs received from Reg-Req message:
CASA(config)# shared-secret DOCSIS extend
Casa Systems CMTS

Enabling configuration file learning
Example: Configure secondary shared secret(s)
The following CLI session sets the shared-secondary-secret for non-encrypted

messages or encrypted messages. Note that the index number of the
shared-secondary-secret can be either 1 or 2, as indicated in the CLI example.
CASA(config)# shared-secondary-secret 1 0 DOCSIS
To set the shared-secondary-secret MIC for the extended TLVs received from
Reg-Req messages:
CASA(config)# shared-secondary-secret 1 0 DOCSIS extend
Enabling configuration file learning
When config-file-learning is enabled, the CMTS records the CMTS-MIC and

CM-MIC from the received configuration file. This feature is disabled by default.
Example: Enable configuration file learning

CASA(config)# cable sec config-file-learning
Configuring Source Address Verification (SAV) rules
When dhcp-authorization is disabled on a DOCSIS MAC domain, anyone can assign

their own IP address. This can cause conflicts and might not be desirable by the
service provider. One secure way to allow customers authorized by their ISPs to use
static IP addresses is to enable DHCP authorization and use the Source Address
Verification (SAV) feature of DOCSIS/CMTS/CM. To do this, the CM receives a
configuration file with a SAV Group Name Subtype encoded.
Example: For docsis -d sav_merlin.bin

Main
{
NetworkAccess 1;
VendorSpecific
{
VendorIdentifier 0xffffff;
GenericTLV TlvCode 7 TlvLength 8 TlvValue 0x01066d65726c696e;
}
MaxCPE 16;
UsServiceFlow
Casa Systems CMTS

{
UsServiceFlowRef 1;
QosParamSetType 7;
}
DsServiceFlow
{
DsServiceFlowRef 2;
QosParamSetType 7;
}
/* CmMic 49b9d8d459f9a9119f43188372a00422; */
/* CmtsMic 0dc1e7ce52cb806a57f13d9eea9c4db8; */
/*EndOfDataMkr*/
)
Example: Configure SAV
In the previous configuration file, the TLV value for SAV Group Name Subtype is
merlin (in hex format: 6d65726c696e). When the CM registers with the CMTS, the
CMTS does note the SAV for the CM. The CMTS must be configured as:
CASA(config)# cable sec sav-cfg-list merlin 1 192.168.7.77/32
192.168.7.77 is the static IP used by the CPE. The 32-bit mask specifies only this IP.
Use a mask to allow a contiguous range of IP addresses. The number “1” after the
“merlin” string is the SAV Group Name Subtype.
By default, dhcp-authorization is enabled with unauthorized IP addresses not

allowed. The CM security configuration allows authorized IPs behind a given CM. By
default, the cable sec sav-auth-enable command is enabled.
The sav-cfg-list supports up to 2048 entries to match the number of CM authorization

names.
Example: Authorize an individual CPE MAC address
To authorize an individual MAC address without changing the CM config file, use the
following command by specifying the CPE MAC and IP addresses:
CASA(config)# cable host authorization 0015.f2fe.c904 67.1.8.23
Casa Systems CMTS

To authorize an IP address or IP subnet (specified in the SAV config list) for a

specified CM using the SAV config list name, rule ID in the range 1–4294967295,
and the IPv4 or IPv6 address and network mask:
CASA(config)# cable sec sav-cfg-list host1 1 192.168.9.0/24
Casa Systems CMTS

4-1
Chapter 4. Managing the CMTS

configuration file
About this chapter

This chapter provides information on managing the CMTS configuration file, as
covered in the following topics:
Topic Page
CMTS configuration file overview 4-1

Avoiding configuration conflicts 4-3
Copying the running configuration 4-4
Copying the startup-config file to NVRAM 4-4
Copying files from FTP and TFTP servers 4-5
Restoring the CMTS configuration 4-6
Displaying configurations 4-6
CMTS configuration file overview

When you use the CLI or Simple Network Management Protocol (SNMP) to create,
edit, or modify the Casa CMTS configuration, the software maintains the most recent
changes in the running configuration. When you complete the editing session and are
satisfied with the changes that you made in the current session, you need to save the
new running configuration to the default file named startup-config.
Casa Systems CMTS

Before you can make changes to the CMTS configuration, you must initiate privileged
mode using the enable command and specifying a password. On new systems, the
default password is casa.
Example: Logging in and entering privileged mode

CASA login: root
Password: casa
CASA> enable
Password: casa
CASA#
Example: Exiting privileged mode
To exit the privileged mode, use the exit command.
CASA# exit
CASA>
For information on adding users and user privileges, see Chapter 3, “Administering
CMTS security.”
Using the startup-config file
The default CMTS boot configuration is provided in the file named startup-config.
You can have any number of startup configuration files in the main CMTS directory
from which you can boot the system. Once the system has booted and is fully
operational, the startup configuration becomes the running configuration during
editing sessions.
Saving the running configuration
The running configuration controls the current operational state of the CMTS. As you
open system configuration objects and edit specific parameters, the CMTS applies the
new settings to the system immediately. When you are finished with the editing
session, you need to save the most recent settings to the default startup-config file (or
to a uniquely named file). By default, the CMTS uses the startup-config file at the
next system restart or reboot.
Casa Systems CMTS

Managing the CMTS configuration file 4-3
Avoiding configuration conflicts
Note: It is important to capture configuration changes by executing the

copy running-config startup-config command on a frequent basis during
the configuration session. If the CMTS is rebooted during an editing session,
your most recent changes are lost, as the startup configuration file is applied at
the reboot. Channel up and down state errors can also occur as a result of not
saving the configuration.
Example: Saving the running configuration
To save the latest configuration settings from the running configuration to the default
startup-config file, use the following command:
CASA(config)# copy running-config startup-config
Example: Saving the running configuration unconditionally
If you attempt to copy the running configuration to the startup configuration when a
module is not in the running state, the following message is displayed:
One or more modules are not in running state. You might lose part of
your startup-config if you save now. You can wait or use 'copy run
start unconditional' to save your config anyway.
You can wait for the module to boot up or you can force the reboot by retyping the
command and adding the unconditional argument.
CASA(config)# copy running-config startup-config unconditional
Avoiding configuration conflicts

Be aware that the CMTS allows multiple users to be logged in at any one time. This
means that if multiple users have configuration privileges, configuration conflicts can
occur during the actual editing sessions. Casa recommends that you coordinate CMTS
sessions with other users who have access to the CMTS configuration. The last
logged-on user to save the configuration captures all edits to the running
configuration, regardless of the user who made them. Users who have the ability to
log on and monitor the CMTS, but do not have configuration editing privileges do not
cause configuration conflicts.
Casa Systems CMTS

Copying the running configuration
Copying the running configuration

The CMTS software allows you to copy and save the running configuration file to a
uniquely named file at other target locations, including:
• NVRAM (non-volatile random-access memory)

• FTP targets
• TFTP targets
Example: Display copy running-config command options
The following CLI session displays the copy running-config command options:
CASA# copy running-config ?

ftp use ftp protocol to put the file
ftp-account use ftp protocol to put the file with defined ftp
account
nvram destination file location
startup-config startup configuration
tftp use tftp protocol to put the file
Example: Copying the running-config file to an FTP target

CASA# copy run ftp myuserid 192.168.8.0 /cmtsfiles/configfile4_30_2015
Password: abc123
Example: Copying the running-config file to a TFTP target

CASA# copy run tftp 192.168.8.4 configfile4_30_15
Example: Copying the running-config file to non-volatile RAM

CASA# copy run nvram configfile4_30_15
Copying the startup-config file to NVRAM

Use the copy startup-config command to save a version of the startup-config file to
the CMTS NVRAM. Doing this makes a copy of the startup-config file available if
you need to restore an earlier configuration.
Casa Systems CMTS

Managing the CMTS configuration file 4-5
Copying files from FTP and TFTP servers
Example: Copying the startup-config to NVRAM
The following example copies the current startup-config file to the file named
configfile1 in NVRAM.
CASA# copy startup-config nvram configfile1
Copying files from FTP and TFTP servers

In most cases, you need to use FTP or TFTP to copy Casa software images to the
CMTS. Software update instructions are provided in the release notes that accompany
the specific software release that you are transferring and installing.
To transfer a Casa software image (or any file) from a TFTP server, use the copy tftp
command as follows:
CASA# copy tftp <host_ip> <file> <device>
Where:
• <host_ip> is the IP address of the host computer or server where the update image
is presently stored.
• <file> is the name of file to be transferred to the CMTS.
• <device> is the CMTS software storage device. On the C10200 or C3200 CMTS,
the storage device is flash1 or flash2. On Casa C10G and C100G systems, the
storage device is nvram or fdsk2.
Example: Copying a file via TFTP
The following CLI session copies the file named C10g.gz.rel6.1.3_build31 file from
host at IP address 192.168.3.10 to NVRAM:
CASA# copy tftp 192.168.3.10 C10g.gz.rel6.1.3_build31 nvram
The following CLI session copies the file named casa_6000.gz.rel6.1.3_build31 from
the host at 192.168.3.10 to flash1:
CASA# copy tftp 192.168.3.10 casa_6000.gz.rel6.1.3_build31 flash1
Casa Systems CMTS

Restoring the CMTS configuration
Restoring the CMTS configuration

If you need to cancel your latest configurations changes and revert to a previously
saved configuration, you can copy the latest startup-config file to the running
configuration, or you can restore the configuration from NVRAM (if the file is
available).
Example: Reverting to the startup-config file
The following example copies the stored startup-config file into the current running
configuration. The startup-config material is merged with the running-config material,
while any conflicting values are overwritten by the startup-config values.
CASA# copy startup-config running-config
Example: Reverting to a previously saved configuration
The following example restores the previously saved configuration named configfile1
from NVRAM to the destination startup-config file in NVRAM.
CASA# copy nvram configfile1 nvram startup-config
Displaying configurations
To display the running configuration at any time, use the following command:
CASA(config)# show running-config [verbose]
To display the startup-config file, use the following command:
CASA(config)# show startup-config
On a new system, or from a system that you just rebooted, there is no difference in the
displayed output.
Casa Systems CMTS

5-1
Chapter 5. Configuring DHCP, TFTP,

NTP, DNS, and logging services
About this chapter

This chapter provides information setting up DHCP, TFTP, NTP and logging services.
As covered in Chapter 1, provisioning servers at the headend are necessary for the
cable modem (CM) to properly complete the initialization process.
Topic Page
Configuring DHCP servers 5-1

Configuring DHCP leasequery 5-3
Enabling the TFTP proxy and enforcing TFTP 5-6
About ToD servers 5-7
Synchronizing the CMTS with NTP servers 5-7
Configuring DNS servers 5-8
Configuring local and remote logging 5-8
Logging DOCSIS event messages to SYSLOG 5-10
Configuring event reporting flags for DOCSIS events 5-11
Copying log files from fdsk2 5-13
Configuring DHCP servers

The CMTS uses the Dynamic Host Configuration Protocol (DHCP) to request IP
addresses from a DHCP server for CM and CPE devices that are registering with the
Casa Systems CMTS

Configuring DHCP servers
CMTS. DHCP Discover, Offer, Request, and Acknowledgment messages are

exchanged between the DHCP client and server. The DHCPACK message returns
(broadcasts) the offered IP configuration to the DHCP client.
Cable helper addresses specify the IP destinations of one or more DHCP servers for
UDP broadcasts from both CMs and CPE devices. These cable helper addresses are
specified in the IP bundle configuration in a DOCSIS MAC domain.
To create or enter an IP-bundle interface, use the interface ip-bundle command in

configuration mode.
Example: Configure cable helper address for DHCP server
The following CLI session opens the ip-bundle instance identifier and context,
displays the cable helper-address command options, and sets the IPv4 server address
to which all DHCP requests are forwarded. Note that the command options following
the DHCP server address enable filtering of DHCP broadcasts to specific device types
(CMs, MTAs, and so on). In this example, the DHCP server forwards all IP addresses
to all requesting devices:
CASA(config)# interface ip-bundle 10

CASA(ip-bundle 10)# cable helper-address 192.168.8.8 ?
<cr>
<string> user defined cpe class name
cable-modem only CM UDP broadcasts are forwarded
global global (VRF 0)
host only host UDP broadcasts are forwarded
mta only mta UDP broadcasts are forwarded
vrf vrf
Additional tasks and usage notes:
1. Configure the ip-bundle primary address using the ip address command. If only
the primary IP is configured (no secondary IP or DHCP address), all
DHCPDISCOVER messages (CM, MTA and CPE) are relayed to the DHCP
server with a source IP address of the specified primary IP.
2. Configure the ip-bundle secondary address using the ip address command with
the secondary option. If the primary IP and at least one secondary IP are
configured (with no DHCP gateway interface address GIADDR), the
DHCPDISCOVER message from the CM is relayed to the DHCP server with a
source IP address of the primary while the DHCP discovery from the MTA and
Casa Systems CMTS

Configuring DHCP, TFTP, NTP, DNS, and logging services 5-3
Configuring DHCP leasequery
CPE is relayed to the DHCP server with a source IP address of the first secondary
IP. If more than one secondary IP address is configured, the DHCP server assigns
the IP addresses in the different subnets to the CPE or MTA.
3. Configure unique cable helper addresses to destination DHCP servers as needed.
4. Create the DOCSIS MAC domain and include this ip-bundle interface in that
domain. Use the DOCSIS MAC ip bundle command to specify the instance
identifier. For details, see Chapter 6, “Creating a new CMTS configuration.”
5. Ensure that DHCP authorization is enabled on the DOCSIS MAC interface using
the dhcp-authorization property. For details on DHCP authorization, see
Chapter 3, “Administering CMTS security.”

The dhcp leasequery and the dhcpv6 leasequery commands configure the Casa
CMTS to send DHCP leasequery requests to the DHCP server. The dhcp leasequery
enforce or dhcpv6 leasequery enforce parameter must be set at the DOCSIS MAC
interface, along with the dhcp-authorization enable on the IP bundle interface, for
DHCP leasequery to work. Since leasequery uses the dhcp.conf file at the DHCP
server, do not set an IP address on CPE/PC devices. The TCP/IP properties on these
devices must be set so that IP addresses are obtained automatically from the
dhcpd.conf host setting.
Two rules apply when setting leasequery for a device:
1. If the device’s IP address is in the primary, secondary, or host range as set for the
IP bundle, the leasequery request is sent to all cable helper-addresses (except
those marked with the cable-modem keyword).
2. If the device’s IP address matches a CPE class or multimedia terminal adapter
(MTA) range, the leasequery request is sent to all the specific cable
helper-addresses that are an exact match. Otherwise, Rule 1 applies.
Example: Rule 1 – DHCP leasequery for device in address range
The device’s IP address is in the primary, secondary, or host address range configured
in the IP bundle, with one or more cable helper-addresses. The request is sent to all
cable helper-addresses except the one marked cable-modem.
Casa Systems CMTS

interface ip-bundle 1.2

dhcp-authorization
ip address 10.92.2.1 255.255.255.0
ip address 10.92.12.1 255.255.255.0 secondary
ip address 10.92.10.1 255.255.255.0 host
cable helper-address 172.16.3.6 host
cable helper-address 172.16.3.6 cable-modem
cable helper-address 172.16.3.7 a1
cable helper-address 172.16.3.7 b2
cable helper-address 172.16.3.8 c3
cable helper-address 172.16.3.8 d4
cable helper-address 172.16.3.6 mta
cable helper-address 172.16.3.6
[Tue May 17 10:01:06 2016]-DE-SYS-1: smm6: 7 leasequery sent.
Example: Rule 2 – DHCP leasequery for device in a CPE class
The device’s IP address is in CPE class b2. The request is sent to the cable
helper-address marked b2, and to any cable helper-address for an IP address matching
the host or secondary address range.
interface ip-bundle 1.2

dhcp-authorization
ip address 10.92.2.1 255.255.255.0
ip address 10.92.10.1 255.255.255.0 b2
cable helper-address 172.16.3.6 host
cable helper-address 172.16.3.6 cable-modem
cable helper-address 172.16.3.7 a1
cable helper-address 172.16.3.7 b2
cable helper-address 172.16.3.8 c3
cable helper-address 172.16.3.8 d4
[Tue May 17 10:09:22 2016]-DE-SYS-1: smm6: 1 leasequery sent.
Example: Modifying the server configuration file
At the DHCP server, modify the dhcpd.conf file as follows:
/etc/dhcpd.conf
allow leasequery; <---- Enables DHCP leasequery on the DHCP server
host cpe_lab {
Casa Systems CMTS

hardware ethernet 00:14:22:fa:87:19; <----MAC address of CPE/PC

fixed-address 10.10.9.202; <----Note this must not be a host IP in the IP
bundle range
option routers 10.10.9.1; <----IP secondary address gateway from the IP
bundle setting
}
subnet 10.10.9.0 netmask 255.255.255.0 {
default-lease-time 3000000; # 5 min

max-lease-time 31557600; # one year
option routers 10.10.9.1;
filename "cm231.cfg";
next-server 192.168.9.1;
option time-offset -18000;
option time-servers 192.168.9.1;
option log-servers 192.168.9.1;
option bootfile-name "cm231.cfg";
option tftp-server-name "192.168.9.1";
range 10.10.9.100 10.10.9.200; <-----IP bundle host range
}
Example: Leasequery additional options
You can also enable DHCPv6 lease synchronization at reboot by using the
dhcpv6 leasequery bulk command. The dhcpv6 leasequery sync-leases command
manually synchronizes leases using bulk transmission.
If dhcpv6 leasequery is set, a leasequery is sent to the DHCP server when a packet
with a source IPv6 address (that is not present in the ARP and local DHCPv6 CPE
lease table) is received.
If dhcpv6 leasequery enforce is set, a leasequery is sent when a packet with a source
IPv6 address (that is not present in the ARP table) is received.
The messages returned from the DHCP server have the following default values:
• 30 — query
• 31 — unassigned
• 32 — unknown
Casa Systems CMTS

Enabling the TFTP proxy and enforcing TFTP
• 33 — active
Example: Changing DHCP leasequery default coding
The following CLI session changes the default coding for query, unassigned,
unknown, and active to 35, 45, 55, and 65 respectively.
Press the [TAB] key to get 1-query and enter a value (up to two digits) for the message
type and a space. Again, press the [TAB] key to get 1-unassigned and type (up to two
digits) and a space. Repeat this process for 1-unknown and 1-active.
The show dhcp leasequery configuration command displays the revised settings.
CASA(config)# dhcp leasequery message-coding l-query 35 l-unassigned

45 l-unknown 55 l-active 65
CASA(config)# show dhcp leasequery configuration

DHCP leasequery message type encoding:
lease query=35
lease unassigned=45
lease unknown=55
lease active=65
Enabling the TFTP proxy and enforcing TFTP

Once a CM is assigned an IP address, the CM submits a request to a target TFTP
server for the CM configuration file. This file provides operational information to the
CM using parameters that are set by the cable service provider, including program
identification to the MAC domain. The TFTP server, as programmed into each CM,
responds to the request by forwarding and loading the configuration file to the CM at
the DHCP-assigned address.
Use the tftp-proxy command on the DOCSIS-MAC interface to allow CMs to get the
CM configuration file from a TFTP server.
The tftp-enforce command enables the CMTS to reject registration requests from
CMs on the specific MAC domain. CMs must first download their configuration files
from a TFTP server before the CMs are allowed to register with the CMTS.
Casa Systems CMTS

About ToD servers
Example: Configure TFTP proxy and TFTP enforce
The following CLI session enables the CMTS as the TFTP proxy for the DOCSIS
MAC interface and enforces CMs registering with this CMTS at this DOCSIS MAC
domain to use TFTP to get their configuration files.
Optionally, the source interface (“from” address) over which a TFTP request is sent
can be either an IP bundle interface assigned to the MAC domain or a CMTS
loopback interface in the range 0–255.
CASA(conf-if-mac 60)# tftp-proxy

CASA(conf-if-mac 60)# tftp-enforce src-interface ip-bundle
About ToD servers

Optionally, the CM might request time information from a time-of-day (ToD) server.
In most cases, time information is returned to the CM using DOCSIS time
synchronization packets from the MAC domain that are carried in the MAC
management messages.
Synchronizing the CMTS with NTP servers

To synchronize the CMTS system clock with a Network Time Protocol (NTP) server,
configure the IP address of the remote NTP server.
Example: Configure the NTP server IP address
The following CLI session configures and synchronizes the remote NTP server at IP
address 192.168.4.200.
CASA(config)# ntp server 192.168.4.200

CASA(config)# ntp sync 192.168.4.200
1 Nov 10:06:00 ntpdate[10661]:step time server 192.168.4.200 offset
0.075592
Restarting NTP server… Stopping NTP server: ntpd
Starting NTP server: ntpd
Optionally, set the CMTS source interface for NTP client traffic in the range 0–15. A
warning message is returned to the console if the loopback interface has not yet been
Casa Systems CMTS

Configuring DNS servers
configured with an interface number and IP address under the interface loopback
configuration.

CASA(config)# ntp source-interface loopback 5
Configuring DNS servers

This section covers the Domain Name System (DNS) configuration at the CMTS. In
most cases, because the GigE CMTS interfaces are in the private network, the source
interface for DNS responses over the public network is a previously configured
loopback interface in the range 0–255.
To configure a DNS name server IP address at the CMTS, or to configure a loopback

interface as the source for DNS protocol traffic, use the nameserver or the
nameserver ipv6 command from configuration mode.
Example: Configure DNS server at the CMTS
The following CLI session configures the IPv4 address for the DNS server at
192.168.4.30 and CMTS loopback interface 12 as the source interface for DNS traffic.
CASA(config)# nameserver 192.168.4.30

CASA(config)# nameserver source-interface loopback 12
Configuring local and remote logging

By default, the Casa CMTS saves logging messages (debugging output) to local flash
(non-volatile memory) as a log file. The logging command allows you to redirect
logging messages to a destination other than local flash, which can include the system
console, RAM (volatile) memory, SNMP traps, and hosts running a SYSLOG server.
Logging levels determine the severity of the information collected in the log file. The
user can set the logging levels as needed. Table 5-1 lists and briefly describes the
logging levels and corresponding keywords used to set the logging levels for these
types of messages. Level 0, emergencies, is the lowest level and logs only the most
Casa Systems CMTS

Configuring local and remote logging
serious errors. Level 7, debugging, is the highest level, which includes the most
messages, because these logs include messages from all levels.
System and console logging is Errors by default. Non-volatile and SYSLOG logging
is Warnings by default. Volatile and trap logging is off by default.
Table 5-1. Message logging keywords and levels
Level Keyword Description SYSLOG definition
0 Emergencies System unusable. LOG_EMERG

1 Alerts Immediate action necessary. LOG_ALERT
2 Critical Critical conditions exist. LOG_CRIT
3 Errors Error conditions exist. LOG_ERR
4 Warnings Warning conditions exist. LOG_WARNING
5 Notification Normal, but significant conditions LOG_NOTICE
6 Informational Information messages. LOG_INFO
7 Debugging Debugging messages. LOG_DEBUG
Example: Configure logging levels
The following CLI session configures logging levels for messages reported to the
CMTS console and SYSLOG hosts.
CASA(config)# logging system warnings

CASA(config)# logging syslog debugging
Example: Configure SYSLOG host
The following CLI session configures the target SYSLOG host at IP address
192.168.46.200. The IPv6 address can alternatively be specified.
CASA(config)# logging host 192.168.46.200
Additional tasks and usage notes
1. Enter the CLI show logging all command to display the current logging settings at
the CMTS.
Casa Systems CMTS

Logging DOCSIS event messages to SYSLOG
2. The logging facility command can be specified to configure the codes for
well-known SYSLOG services or the type of application programs that log
messages. The following local0 through local7 options are currently supported:
• local0 — PostgreSQL
• local1 — (not supported)
• local2 — Sudo
• local3 — Versions of SpamAssassin
• local4 — SLADP (OpenLDAP server)
• local5 — Snort IDS
• local7 — Boot messages on Fedora 12
3. The user log exclusion-list can be used to selectively disable logging of certain
message levels from specified users. Messages associated with the specified log
level (and all lower severity levels) for the specified user are disabled and are not
logged. This functionality keeps unnecessary messages from filling up the log file.
4. The logging source-interface loopback command specifies the loopback
interface in the range 0–255 from which log messages are forwarded to a logging
target.
Logging DOCSIS event messages to SYSLOG

To enable logging of DOCSIS event messages to a SYSLOG server, use the cable
event syslog-server command in global configuration mode.
Example: Configure cable event SYSLOG server
The following CLI session enables cable event reporting configures the target
SYSLOG server for cable events.
CASA(config)# cable event

CASA(config)# cable event syslog-server 192.168.46.200
You can also use the cable event <id> delivery command to enable forwarding of
major cable event messages to the SYSLOG server.
Casa Systems CMTS

Configuring event reporting flags for DOCSIS events
Use the show running-config | include syslog command to display and verify the
current SYSLOG server for DOCSIS events.
CASA(config)# show running-config | include syslog

!syslog server for DOCSIS events:
cable event syslog-server 192.168.46.200
Configuring event reporting flags for DOCSIS

events
To configure the event reporting flags for DOCSIS event messages (Table 5-2), which
determine how the CMTS reports these events, use the cable event priority to set the
event reporting flag for error system messages.
Table 5-2. DOCSIS event priority and flags
Priority Description
emergency Sets the event reporting flag for emergency system error
messages. (Emergency messages indicate that the system
has become unusable and requires immediate attention. This
problem might also be affecting other parts of the network.)
alert Sets the event reporting flag for alert system error messages.
(Alert messages indicate that some type of system or
connection failure has occurred and requires immediate
attention.)
critical Sets the event reporting flag for critical system error
messages. (Critical messages indicate that an error occurred
which requires immediate attention to avoid system or
connection failure.)
error Sets the event reporting flag for error system error messages.
(Error messages indicate that an error condition occurred that
requires attention to resolve. Failure to address this problem
results in some type of system or connection failure in the
near future.)
Casa Systems CMTS

Configuring event reporting flags for DOCSIS events
Table 5-2. DOCSIS event priority and flags (continued)
Priority Description
warning Sets the event reporting flag for warning system error
messages. (Warning messages indicate that a condition
occurred that indicates attention is needed in near future to
avoid potential problems. Failure to address this problem
could result in some type of system or connection failure later
on.)
notice Sets the event reporting flag for notice system error
messages. (Notice messages indicate that a situation
occurred that is normal but is significant enough that system
administrators might want to notice.)
informational Sets the event reporting flag for informational system error
messages. (Informational messages might or might not be
significant to the system administrators.)
debug Sets the event reporting flag for debug system error
messages. (Debug messages appear only when debugging
has been enabled.)
flags Sets the event reporting flags value, in hex, which specifies
how this particular type of event message should be reported.
The first value relates to the non-volatile log while the second
(optional) value relates to the volatile log and can only be
either 0x00 or 0x80. The valid values are shown as follows:
• 0x00 — DOCSIS messages are not reported.

• 0x20 — Messages reported to SYSLOG servers
• 0x40 — Messages reported to trap receivers
• 0x60 — Messages reported to SYSLOG servers and trap
receiver
• 0x80 — DOCSIS messages are saved in a local log on the
CMTS.
• 0xA0 — DOCSIS messages are reported to the local log
and SYSLOG servers
• 0xC0 — DOCSIS messages are reported to the local log
and trap receivers
• 0xE0 — DOCSIS messages are reported to the local log,
SYSLOG servers and trap receivers
Casa Systems CMTS

Copying log files from fdsk2
Example: Configure DOCSIS event reporting flags
The following CLI session sets DOCSIS event reporting priority to emergency and
sets the SYSLOG server and trap receivers flag (0x60) along with the local volatile
log reporting flag (0x80).
CASA(config)# cable event priority emergency 0x60 0x80
Example: Enable logging of DOCSIS events to SYSLOG
The following CLI session enables logging of DOCSIS event messages to a SYSLOG
server:
CASA(config)# cable event syslog-server
1. Execute the CLI show cable event notification policy command to display the
current cable event logging and priority flags.
2. To configure how the CMTS throttles the SNMP traps and SYSLOG messages it
generates for DOCSIS event messages, use the cable event throttle-adminStatus
command in global configuration mode.
3. To specify the throttle interval, which controls how often the CMTS generates
SNMP traps and SYSLOG messages for DOCSIS event messages, use the
cable event throttle-interval command in global configuration mode.
4. To set the maximum number of SNMP traps and SYSLOG messages that the
CMTS can generate for DOCSIS event messages during the throttle interval, use
the cable event throttle-threshold command in global configuration mode.

On systems running Release 6.4 and later, use the copy fdsk2 command to transfer
files from the /fdsk2 directory to target locations over TFTP, FTP, or secure copy
(SCP). The /fdsk2 directory is a non-volatile location for C10G and C100G system log
files. In earlier releases, log files stored in the /tmp directory would be lost after a
system reboot.
Casa Systems CMTS

Example: Copying a file from fdsk2 to a TFTP target
The following CLI session copies the file named logfile.bak to the TFTP host at IP
address 192.168.3.10.
CASA# copy fdsk2 logfile.bak tftp 192.168.3.10
Use the CMTS dir fdsk2 command to display the current list of files.
Casa Systems CMTS

6-1
Chapter 6. Creating a new CMTS

configuration
About this chapter

This chapter provides information on creating a new CMTS configuration starting
with the Casa startup-config file. The startup-config file contains the default “factory”
settings you need to customize as you build a unique CMTS configuration for the
cable network.
Topic Page
Ensuring the CMTS preconfiguration 6-2

Configuring IP bundle interfaces 6-3
Configuring MAC domains 6-4
Special note on flexible licensing 6-5
Configuring QAM downstream channels 6-6
Configuring upstream channels 6-31
Binding channels to the MAC domain 6-40
Configuring service groups 6-41
Enabling D3.0 channel bonding 6-43
Load balancing CM traffic 6-48
Casa Systems CMTS

Ensuring the CMTS preconfiguration
Ensuring the CMTS preconfiguration

Prior to configuring the Casa CMTS to handle CM registrations, ensure that the
following preconfiguration requirements have been met:
1. Properly installing the CMTS hardware in the cable headend according to the
specific hardware installation guide:
• Casa Systems – C2200 CMTS Hardware Installation Guide
2. Connecting a local or remote network management system over Telnet or SSH to
the default Ethernet management port (eth0) at default IP address 192.168.2.100.
See Chapter 3, Administering CMTS security for information on connecting to
the CMTS management port.
For direct console connections, see the matching Casa hardware installation guide
for information on connecting a console to the CMTS serial console port.
3. Installing all required headend networking equipment to include gateways to the
Internet, as well as connections to provisioning servers (DHCP, TFTP, ToD, DNS,
SYSLOG). See Chapter 5, Configuring DHCP, TFTP, NTP, DNS, and logging
services for information on configuring these provisioning services.
4. Enabling CM and customer premises equipment (CPE) compatibility with the
CMTS IP network and DOCSIS RF services.
5. Preparing a channel plan for assigning upstream and downstream channel
frequencies.
If you are running the Simple Network Management Protocol (SNMP) to manage the
CMTS configuration from a remote management, see the Casa Systems – SNMP MIBs
and Traps Reference for information on configuring the SNMP agent at the CMTS.
Casa Systems CMTS

Creating a new CMTS configuration 6-3
Configuring IP bundle interfaces
Configuring IP bundle interfaces

Cable helper addresses point to the destination DHCP servers from which CMs get
their IP addresses, as covered in Chapter 5, “Configuring DHCP, TFTP, NTP, DNS,
and logging services.” On the IP bundle interface, you also need to configure primary
and secondary IP addresses. The primary IP address forms the baseline
DHCP-assigned address for CMs registering with the CMTS. Secondary IP addresses
are those DHCP-assigned addresses for CPE devices residing behind each CM.
Example: Configure the IP bundle primary IP address
The following CLI session creates the IP bundle with group ID 1. Up to 16 IP bundle
group IDs can be configured. If the primary IP address is configured (with no
secondary IP or DHCP gateway address), all DHCPDISCOVER messages (CM,
MTA and CPE) are relayed to the DHCP server with a source IP address of the
primary IP.
CASA(config)# interface ip-bundle ?

<1-16> bundle group id
<X.Y> sub interface id X=1-16 Y=1-511
CASA(ip-bundle 1)# ip address 172.18.32.4 255.255.255.0
Example: Configure IP bundle secondary IP addresses
If the primary IP and at least one secondary IP is configured (with no DHCP gateway
address), the DHCPDISCOVER from the CM is relayed to the DHCP server with a
source IP address of the primary. The DHCPDISCOVER from the MTA and CPE is
relayed to the DHCP server with a source IP address of the first secondary IP. If more
than one secondary IP address is configured, the DHCP server assigns the IP
addresses in the different subnets to the CPE or MTA.

CASA(ip-bundle 1)# ip address 10.248.4.1 255.255.255.0 secondary
Example: Configure IP bundle subinterfaces
IP bundle subinterfaces allow the network to be partitioned into multiple subnets

where CMs can receive IP addresses on different subnets from the DHCP server.
Casa Systems CMTS

Configuring MAC domains
While CMs request an IP address from the same DHCP server, CPE requests are sent
to a different server. The DHCPDISCOVER from the CPE depends on the CM IP
address, where the CPE has an IP address from the subnet associated with the CM IP
address.
Example
The following CLI session creates the IP bundle subinterface 1.1 and the primary and
secondary IP addresses for CMs and CPEs.
CASA(config)# interface ip-bundle 1.1

CASA(ip-bundle 1.1)# ip address 10.0.0.3 255.255.255.0
CASA(ip-bundle 1.1)# ip address 192.168.54.25 255.255.255.0 secondary
If the CM IP address is in subnet 10.0.0.0/24, the DHCPDISCOVER has a source IP

primary address of 10.0.0.3 and the CPE has a gateway IP secondary address of
192.168.54.25. Another subinterface may have a different CPE gateway IP.
Configuring MAC domains

A DOCSIS MAC domain is a collection of upstream and downstream channels over
which CMs register and communicate with the CMTS. It is the Open Systems
Interconnect (OSI) Layer 2 device through which RF traffic is forwarded to CMs over
downstream channels and received from CMs over CMTS upstream channels. The
minimum MAC domain contains one upstream and one downstream channel. The
Casa CMTS integrates the Layer 2 MAC domain and a Layer 3 physical routing
device with an internal forwarding engine.
Casa CMTS systems can support up to 96 DOCSIS MAC domains depending on the
CMTS model.
Upstream and downstream channels operate in a shutdown state unless they are
bounded in a DOCSIS MAC domain. A MAC domain cannot be enabled without IP
address, helper address, and at least one downstream and upstream channel. As
covered in the previous sections, IP addresses must be configured in the IP bundle
interface that is assigned to the DOCSIS MAC domain.
Casa Systems CMTS

Special note on flexible licensing
The following CLI session creates DOCSIS MAC domain 10. On C10G and C100G
systems, a DOCSIS MAC domain can be configured in the number range 1–96.
Example: Create DOCSIS MAC domain

CASA(conf-if-mac 10)#
Binding the IP bundle to the MAC domain
Each DOCSIS MAC must include one previously configured IP bundle interface
containing primary and secondary IP addresses, along with the cable helper addresses
to DHCP servers. Otherwise, CMs cannot download their configuration files and
register with the CMTS over the channel bindings in the DOCSIS MAC domain. The
following CLI session uses the ip bundle command to bind the previously configured
IP bundle 6 to MAC domain 10.
Example: Apply the IP bundle interface to the MAC domain

CASA(conf-if-mac 10)# ip bundle 6
Special note on flexible licensing

Flexible channel licensing allows you to configure up to the maximum number of
channels supported by the module across all ports. The number of channels per port
remains limited to the maximum number supported on that module.
With Release 6.1.x and earlier, modules are set to use the channels-per-port number. If
your company purchases and licenses four channels per port on QAM 8x8 card, you
cannot use the fifth channel on any of the ports. With Release 6.4.1, each upstream or
downstream module is limited by the total number of channels per module.
On the QAM 8x8 with four licensed channels per port, you can configure a total of
4 (channels) * 8 (ports) to equal the total 32 channels across the eight ports. You can
also choose to configure eight channels on the first four ports, or randomly pick
channels across the eight ports to form a total of 32.
Flexible channel licensing applies to all upstream and downstream modules, including
the UPS 16x8 and the QAM 8x96 and QAM 8x192.
Casa Systems CMTS

Configuring QAM downstream channels

Downstream channels are configured per DOCSIS module. The DOCSIS MAC
downstream command binds the channel to the MAC domain.
The number of downstream channels is limited only by the specific QAM module you
are configuring and whether a certain number of channels less than that module’s
capacity was licensed to you. See the “Binding channels to the MAC domain” section
in this chapter for information.
Downstream port conventions
The downstream port is defined in the following format when issuing the
downstream or interface qam command:
X/Y/Z — Where X is the system slot number, Y is the system port number, and Z is
the channel number.
Depending on the specific CMTS model you are configuring, slot, port, and channel
numbers will vary. For example, on the C100G CMTS, valid slot numbers for a
QAM 8x192 module would be in the range 0–5 or 8–13, port numbers in the range
0–7, and narrowcast channel numbers in the range 0–79.
QAM channel configuration
The interface qam command configures a Quadrature Amplitude Modulation (QAM)

interface. QAM is the modulation scheme for digital cable and CMs for downstream
traffic and interfaces need to be configured for that traffic. The Casa QAM interface is
available in the following three versions:
• QAM 8x8—Eight QAM modules with each eight channels. QAM 8x8 modules
have two modes of operation: normal and high frequency. Normal mode requires
all channels on a given QAM module to be contained in the range 47–860 MHz.
High frequency mode requires all channels on a module in the range 295–
999 MHz. Each QAM module is completely independent of other modules in the
same chassis; some modules can be in high-frequency mode, while others are in
normal mode. The center frequencies for channels on the same port are correlated.
When any one is set, the others change accordingly. The center frequency of each
Casa Systems CMTS

Setting QAM channel frequencies
channel is separated by 6–8 MHz, depending on whether the QAM port is

configured as Annex type B, C, or A.
• QAM 8x96—Eight QAM modules with each 96 channels. The QAM 8x96
module supports both narrowcast and shared channels, where each of the eight
ports consists of 36 unicast channels and 12 shared channels. Shared channels are
RF channels that operate over any or all eight physical ports with up to 96 shared
channels across all ports. The QAM 8x96 module supports 352 QAM channels in
Annex B and Annex A modes — 256 channels are capable of both DOCSIS and
video traffic, plus 96 video channels capable of broadcasting over any of the RF
ports. In DVB SimulCrypt mode, the QAM 8x96 module supports up to 40
channels per port, 32 DOCSIS and eight DVB.
• QAM 8x192—Eight QAM modules with each 192 channels, with up to
64 multi-port shared (broadcast) and 80 narrowcast channels per port. The module
introduced for DOCSIS 3.1 supports up to 400 DOCSIS channels per module,
128 multi-port shared channels per module and broadcast channels per port,
80 single-carrier channels (DOCSIS, SDV, and VOD) across eight channel
blocks, 24 Annex A/B/C channels per port operating in DVB SimulCrypt
encryption mode configured in the upper channel range, and up to two channels (0
and 1) per port for Orthogonal Frequency Division Multiplexing (OFDM)
(SimulCrypt allows only one OFDM channel) and one channel (0) per port for
Orthogonal Frequency Division Multiple Access (OFDMA) over 10-Gbps
downstream and 1-Gbps upstream service flows. (OFDM and OFDMA are
described more fully in the Casa Systems – CMTS Network Solutions Guide.)
Note: Before hot-swapping a QAM module, use the command ha replace

linecard <module> with QAM8x192, for example. Currently the QAM 8x192
module requires the SMM 8x10G in the system chassis, and excludes the
SMM 2x10G. QAM 8x192 is not supported on the C10G platform.
Setting QAM channel frequencies
Casa QAM modules have two modes of operation: normal and high frequency.
Normal mode requires all channels on a given QAM module to be contained in the
range 47–860 MHz. High frequency mode requires all channels on a module to be in
the range 295–999 MHz.
To change the channel frequency from one mode to the other, if the module starts with
port 0 at 100 MHz, then all other ports are set at 500 MHz with the module in normal
Casa Systems CMTS

Channel sharing in QAM modules
mode. If you attempt to set port 3 to 900 MHz, the module does not accept the setting
because it requires high-frequency mode (295-999 MHz). Because port 0 is currently
in normal mode, you must first set it to at least 295 MHz before attempting to set
port 3 to 900 MHz. This means that if any channel frequency is greater than 860 MHz,
then all ports must be greater than 300 MHz.
Each QAM module is completely independent of other modules in the same chassis.
That means some modules can be in high-frequency mode and others in normal mode.
The center frequencies for channels on the same port are correlated. When any one is
set, the others change accordingly. The center frequency of each channel is separated
by 6 to 8 MHz, depending on whether the QAM port is configured as Annex type B,
C, or A. Annex B channels are separated by 6 MHz.
Example
CASA(config-if-qam 11/0)# channel 1 frequency 555000000
CASA(config-if-qam 11/0)# show interface qam 11/0
interface qam 11/0
no spectral inversion on
annex B
modulation 256qam
interleave 128x1
power 510
channel 0 frequency 549000000
channel 0 shutdown
channel 1 shutdown
…
channel 7 shutdown
shutdown
In this example, the center frequency of QAM channel 0 is then automatically

adjusted to 549 MHz, channel 1 set to 555 MHz, channel 2 to 561 MHz, channel 3 to
567 MHz, and so on, with the last channel 7 set to 591 MHz.
The QAM 8x96 and QAM 8x192 modules support both narrowcast and shared
channels, where each of the eight ports consists of 36 unicast channels and 12 shared
channels. Shared channels are RF channels that operate over any or all eight physical
ports, totaling 96 channels.
Casa Systems CMTS

QAM shared channel modes
Each shared channel must be in one of the two following modes:
• Extra narrowcast shared channel mode

• Multi-port shared channel mode
The system allows a combination of these modes over an RF port.
Extra narrowcast channel mode
In extra (sometimes called extended) narrowcast channel mode, a shared channel

emulates one of the narrowcast channels on a port. The content of this channel does
not replicate to any other port. This mode is useful in cable environments that do not
require replication, where the shared channels are used to increase the channel density
of a port. With 96 shared channels (QAM 8x96), each of the eight RF ports can get up
to 12 extra narrowcast channels; with 128 shared channels (QAM 8x192), each of the
eight RF ports can get up to 16 extra narrowcast channels. Extra narrowcast channels
configured for unicast DOCSIS are secondary-only channels by nature, meaning that
they cannot transmit MAP files, so that the MAC domain must also include at least
one primary channel in the unicast FPGA.
To configure shared channels in extra narrowcast mode, use the module command in
the following format:
CASA(config)# [no] module <id> narrowcast-channels <36:48>
This command sets the total number of narrowcast channels on the module RF
downstream ports. If the number of narrowcast channels is more than 32 as specified
by the command, the system places a set of shared channels in extra narrowcast mode
to meet the assigned number. The maximum value for narrowcast channels is 48,
which is the default setting.
The following narrowcast channel conditions apply:
• When module <id> narrowcast-channels is set to 48, all 96 channels are equally
allocated to the eight RF ports, and there is no multi-port shared channel available.
• When set to 36, all 96 shared channels are available for multi-port shared
channels. However, the number of QAM channels per RF port cannot exceed 128.
Casa Systems CMTS

• When the system is configured for Digital Video Broadcasting (DVB)

SimulCrypt, the number of shared channels is reduced to 64. See the Casa
Systems – RF Cable Configuration Guide and Command Reference for details.
Example
CASA(config)# module 0 narrowcast-channels 44
This command creates 44 narrowcast channels. Use the no form of the command to
remove the current narrowcast channels configuration setting and revert to the default
setting of 48 narrowcast channels.
Use the show narrowcast-channels command to display the current narrowcast

channels.
Multi-port shared channel mode
In multi-port shared channel mode, the content of the channel can be replicated to all
eight RF ports. The set of downstream ports on each shared channel can be selected to
allow a subset of RF ports for shared channel replication. The RF frequency of the
shared channels must be the same on all outgoing RF ports.
The shared-channel command places a shared channel in multi-port shared channel

mode. Shared channels in the range 0–95 are enabled using an assigned frequency. (A
zero frequency can be set for unused or disabled/shutdown channels to avoid possible
unexpected frequencies.) The shared channel frequency must be assigned first using
the following command format:
shared-channel <id> frequency <Hz> [1:32]
The optional range 1–32 is the number of channels to which the frequency applies
using a single command.
Example
CASA(config)# interface qam 0/0
CASA(config-if-qam 0/0)# shared-channel 0 frequency 555000000
Note: If some of the shared channels are assigned in narrowcast channel

mode, this reduces the number of channels available in multiport shared
channel mode.
Casa Systems CMTS

QAM 8x192 multi-port shared channels
Once a shared channel on one of the QAM 8x192 ports is created, this channel can
then be shared across one or more ports (up to seven additional) on the same module.
The following CLI session configures the video-only multi-port shared channels on
port 0 and shares them with port 1:
1. Configure the number of narrowcast channels on the QAM 8x192 in system

slot 4.
2. Configure the shared channel identifier on the first module and number of
channels to be shared.
3. Configure no shared-channel shutdown for all the shared port channels.
4. Execute the show module <slot> shared-channel mapping command to verify
the configuration.
Example
CASA(config)# show narrowcast-channels
module 4 narrowcast-channels 64
CASA(config)# interface video 10

CASA(conf-if-video 10)# ip address 88.88.88.88 255.255.255.0

CASA(config-if-qam 4/0)# shared-channel 0 frequency 47000000 16
CASA(config-if-qam 4/0)# no shared-channel 0 shutdown 16

…
shared-channel 0 frequency 47000000
no shared-channel 0 shutdown
Casa Systems CMTS









CASA(config)# show module 4 shared-channel mapping
PORT CHAN SH_CH FREQ(MHz) BINDP BINDC BINDM ANNEX MOD SYMB REPL-P P_MASK BLK_OFF
STATUS
0 0 0 47000000 0 64 ff A 256qam 6952 255 00 0 0 up
0 1 1 55000000 0 65 ff A 256qam 6952 255 00 0 1 up
0 2 2 63000000 0 66 ff A 256qam 6952 255 00 0 2 up
0 3 3 71000000 0 67 ff A 256qam 6952 255 00 0 3 up
0 4 4 79000000 0 68 ff A 256qam 6952 255 00 0 4 up
0 5 5 87000000 0 69 ff A 256qam 6952 255 00 0 5 up
0 6 6 95000000 0 70 ff A 256qam 6952 255 00 0 6 up
0 7 7 103000000 0 71 ff A 256qam 6952 255 00 0 7 up
0 8 8 111000000 0 72 ff A 256qam 6952 255 00 0 8 up
0 9 9 119000000 0 73 ff A 256qam 6952 255 00 0 9 up
0 10 10 127000000 0 74 ff A 256qam 6952 255 00 0 10 up
0 11 11 135000000 0 75 ff A 256qam 6952 255 00 0 11 up
0 12 12 143000000 0 76 ff A 256qam 6952 255 00 0 12 up
0 13 13 151000000 0 77 ff A 256qam 6952 255 00 0 13 up
0 14 14 159000000 0 78 ff A 256qam 6952 255 00 0 14 up
0 15 15 167000000 0 79 ff A 256qam 6952 255 00 0 15 up
Casa Systems CMTS

2 0 0 47000000 0 64 ff A 256qam 6952 255 00 0 0 up

2 1 1 55000000 0 65 ff A 256qam 6952 255 00 0 1 up
2 2 2 63000000 0 66 ff A 256qam 6952 255 00 0 2 up
2 3 3 71000000 0 67 ff A 256qam 6952 255 00 0 3 up
2 4 4 79000000 0 68 ff A 256qam 6952 255 00 0 4 up
2 5 5 87000000 0 69 ff A 256qam 6952 255 00 0 5 up
2 6 6 95000000 0 70 ff A 256qam 6952 255 00 0 6 up
2 7 7 103000000 0 71 ff A 256qam 6952 255 00 0 7 up
2 8 8 111000000 0 72 ff A 256qam 6952 255 00 0 8 up
2 9 9 119000000 0 73 ff A 256qam 6952 255 00 0 9 up
2 10 10 127000000 0 74 ff A 256qam 6952 255 00 0 10 up
2 11 11 135000000 0 75 ff A 256qam 6952 255 00 0 11 up
2 12 12 143000000 0 76 ff A 256qam 6952 255 00 0 12 up
2 13 13 151000000 0 77 ff A 256qam 6952 255 00 0 13 up
2 14 14 159000000 0 78 ff A 256qam 6952 255 00 0 14 up
7 0 0 47000000 0 64 ff A 256qam 6952 255 00 255 255 up

7 1 1 55000000 0 65 ff A 256qam 6952 255 00 255 255 up
7 2 2 63000000 0 66 ff A 256qam 6952 255 00 255 255 up
7 3 3 71000000 0 67 ff A 256qam 6952 255 00 255 255 up
7 4 4 79000000 0 68 ff A 256qam 6952 255 00 255 255 up
7 5 5 87000000 0 69 ff A 256qam 6952 255 00 255 255 up
7 6 6 95000000 0 70 ff A 256qam 6952 255 00 255 255 up
7 7 7 103000000 0 71 ff A 256qam 6952 255 00 255 255 up
7 8 8 111000000 0 72 ff A 256qam 6952 255 00 255 255 up
7 9 9 119000000 0 73 ff A 256qam 6952 255 00 255 255 up
7 10 10 127000000 0 74 ff A 256qam 6952 255 00 255 255 up
7 11 11 135000000 0 75 ff A 256qam 6952 255 00 255 255 up
7 12 12 143000000 0 76 ff A 256qam 6952 255 00 255 255 up
7 13 13 151000000 0 77 ff A 256qam 6952 255 00 255 255 up
7 14 14 159000000 0 78 ff A 256qam 6952 255 00 255 255 up
7 15 15 167000000 0 79 ff A 256qam 6952 255 00 255 255 up
5. Add multi-port shared channels to the video QAM domain and QAM group. The
qam-group command in the video qam-domain configuration supports the range
of narrowcast and multi-port shared channels.
Example
CASA(config)# video qam-domain 1
CASA(conf-qam-domain 1)# qam-group <id> shared-channel
<first> <last>
where id is the QAM group ID in the range 1–8, and first and last are the first and
last QAM channels in the block of multi-port shared channels.
CASA(conf-qam-domain 1)# qam-group 2 shared-channel 0/0 0/15
CASA(conf-qam-domain 2)# show video qam-domain

video qam-domain 1
edis 1
video service group 1
interface video 6
qam-group 1 0/0/16 0/0/31
qam-group 2 shared-channel 0/0 0/15 <<<<==== 16 multi-port
shared channels added to video qam-domain
Casa Systems CMTS

QAM 8x192 video channel ID offset
To use the maximum number of narrowcast channels per port (>64), use the
video channel-id-offset <n> command so that the number of narrowcast video
channels per port is less than or equal to 64. The command excludes DOCSIS
channels from the video channel numbering space. The specified offset indicates the
number of reserved DOCSIS channels. Video channel numbering begins following
the offset, with the first video channel number beginning at 0.
The video channel offset value depends on the largest of the

module <id> narrowcast-channels <num> settings. For a system with a module
having the largest narrowcast channel value of 70 (see the example), the offset value
must be in the range 6–69. Without an offset value, you cannot configure 64 video
channels, and a QAM group becomes invalid if the offset is removed (see the
example). The module <id> channel-id-offset <n> is a module-specific override of
the video channel-id-offset setting.
Example
CASA(config)# video channel-id-offset 1

Error: video addressing space must be
equal to or less than 64
CASA(config)# video channel-id-offset 6

CASA(conf-qam-domain 1)# qam-group 1
12/0/6 12/0/69
CASA(conf-qam-domain 1)# end
CASA(config)# no video channel-id-offset

qam-domain 1 qam-group 1 is invalid
without channel id offset configured
QAM 8x192 MPTS pass-through broadcast video
Release 7.2 supports Multiple Program Transport Stream (MPTS) processing over
QAM 8x192 ports 0–7 where one input MPTS can be output to one QAM multi-port
shared channel. Note that PID replacement (drop and add) is supported with broadcast
video.
Casa Systems CMTS

Perform the follow steps to configure the QAM for broadcast video:
1. Configure the multi-port shared channels, including the interface video,

interface qam, and video qam domain configurations.
2. Configure the broadcast video session shared channel using the video session
<id> pass-through command with the MPTS destination and source addresses.
Create a video pass-through session on one QAM 8x192 module, then repeat the
command for additional QAM 8x192 modules. In the following example, the MPTS
broadcast video stream is configured on shared channel 4/0. The MPTS is destined for
the multicast group address at IP 227.0.0.0 and the video source IP address for the
MPTS is 17.56.102.2.
Example
CASA(config)# video session 1 pass-through ip-address 227.0.0.0
qam-channels shared-channel 4/0 src-ip 17.56.102.2
Sharing channels over other QAM ports
Once a shared channel on one of the QAM ports is created, it can then be shared
across one or more ports (up to seven additional) on the same module.
Figure 6-1 shows a sample mapping of the eight QAM 8x96 ports where port 0 shares
12 SDV0 channels with 1, port 2 shares SDV1 channels with port 3, and so on.
The following CLI session configures the shared channels on port 0 and shares them
with port 1 using the following steps:
1. Configure the number of narrowcast channels on module 0 and module 1.

2. Configure the shared channel identifier on the first module and number of
channels to be shared, then configure the second and any subsequent ports using
the same shared channel identifier.
3. Execute the show module <slot> shared-channel mapping command to verify
the configuration.
4. Add multi-port shared channels to the video QAM domain and QAM group. The
qam group command in the video qam domain configuration supports the range
of narrowcast and multi-port shared channels.
Casa Systems CMTS

Figure 6-1. Sample QAM 8x96 shared channel mappings

Narrowcast channels
Multiport shared channels
Channel number
0 15 16 31 43
Port 0 DOCSIS VOD SDV0
Shared channel IDs
0 to 11; channels 32 to 43
1 DOCSIS VOD SDV0
2 DOCSIS VOD SDV1

Shared channel IDs
3 DOCSIS VOD SDV1
4 DOCSIS VOD SDV2 Shared channel IDs

5 DOCSIS VOD SDV2
6 DOCSIS VOD SDV3 Shared channel IDs

7 DOCSIS VOD SDV3
qam-group <group_id> shared-channel <first_schannel>

<last_schannel>
where <group_id> is the qam group ID in the range 1–8, and <first_schannel> and
<last_ schannel> specify the block of multiport shared channels in the range 0–44.
5. Run the show docsis channel utilization command to display multi-port shared
channel statistics.



Casa Systems CMTS

CASA(config)# show module 0 shared-channel mapping

PORT CHAN SH_CH FREQ(MHz) BINDP BINDC REPL-P P_MASK BLK_OFF STATUS
*****12 multiport shared-channels on QAM 0/0*****

*****12 multiport shared-channels on QAM 0/1*****
CASA(config)# video qam domain 1

CASA(conf-qam-domain 1)# qam-group 2 shared-channel 0/0 0/11
C10G-181(conf-qam-domain 2)# show video qam-domain

video qam-domain 1
edis 1
video service group 1
interface video 6
qam-group 1 0/0/16 0/0/31
qam-group 2 shared-channel 0/0 0/11 <<<<==== 12 multiport
shared-channels added to
video qam-domain.
CASA (config-if-qam 0/1)# show docsis channel utilization

Downstream Total-BW Utilization Online Secondary
Slot/Port/Channel (Mb/Sec) Percentage Modems Modems
Channel
Description
----------------------------------------------------------------------
<<<<==== Utilization on 12 multiport shared-channels
0/0 (723000000 Hz) 42.9 49 0 0 (shared)

0/1 (729000000 Hz) 42.9 49 0 0 (shared)
0/2 (735000000 Hz) 42.9 49 0 0 (shared)
0/3 (741000000 Hz) 42.9 49 0 0 (shared)
0/4 (747000000 Hz) 42.9 49 0 0 (shared)
0/5 (753000000 Hz) 42.9 49 0 0 (shared)
0/6 (759000000 Hz) 42.9 49 0 0 (shared)
0/7 (765000000 Hz) 42.9 49 0 0 (shared)
0/8 (771000000 Hz) 42.9 49 0 0 (shared)
0/9 (777000000 Hz) 42.9 49 0 0 (shared)
0/10 (783000000 Hz) 42.9 49 0 0 (shared)
0/11 (789000000 Hz) 42.9 49 0 0 (shared)
QAM 8x96 and QAM 8x192 channel frequency range
As in earlier Release 6.4 implementations, the configuration maintains four RF

blocks. Each block covers 192 MHz width, with the four blocks covering the
768-MHz frequency range. The frequency range might not be continuous, and
frequency gaps might exist between blocks.
Casa Systems CMTS

• In Annex B or C mode at the 6-MHz channel width, the maximum number of

channels on a single block is 32. The maximum number Annex B or C channels
on each physical port is 128 RF channels (4 blocks x 32 channels). See Figure 6-2.
Figure 6-2. QAM 8x96 channel time line frequency blocks (Annex B, C; 128 ch.)
Dynamic system-assigned default frequencies
99000000 291000000 483000000 675000000
192 MHz 192 MHz 192 MHz 192 MHz
block 0 block 1 block 2 block3
32 channels 32 channels 32 channels 32 channels
47 MHz 768 MHz 1 GHz

QAM 8x96 (Annex B/Annex C, 128 channels)
• In Annex A mode, at the 8-MHz channel width, the maximum number of channels
on a single block is 24. The maximum number of Annex A channels on each
physical port is 96 RF channels (4 blocks x 24 channels). See Figure 6-3.
Figure 6-3. QAM 8x96 channel time line frequency blocks (Annex A; 96 ch.)
99000000 291000000 483000000 675000000
192 MHz 192 MHz 192 MHz 192 MHz
32 channels 32 channels 32 channels 32 channels

QAM 8x96 (Annex B/Annex C, 128 channels)
Casa Systems CMTS

Example
C10G-181(config-if-qam 0/0)# show interface qam 0/0 block
interface qam 0/0:
block 0 frequency 93000000 map ffffffff

channel 0 freq 93000000 blk 0 off 0 intlv 32 status up
block 1 frequency 291000000 map 00000000
block 2 frequency 483000000 map 00000000
block 3 frequency 675000000 map 000fff00
<<<<==== 12 multiport shared-channels added

shared-channel 0 freq 723000000 blk 3 off 8 intlv 12801 status 01
ch 32
ch 33
Casa Systems CMTS


ch 34
ch 35
ch 36
ch 37
ch 38
ch 39
ch 40
ch 41
ch 42
ch 43
block_map: 000fff00 00000000 00000000 ffffffff
schan_id:
0 1 2 3 4 5 6 7 8 9 10 11
<<<<==== 12 multiport shared-channels added
255 255 255 255 255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255 255 255 255 255
shutdown channels:
PORT 0: annex 1 mod 4 intlv (12801, 32) nd 32 nu 32 ns 96 status up
FPGA_A: annex 1 mod 4 intlv (12801, 32) pmap 0x00 nd 32 nu 32 ns 96

status up
FPGA_B: annex 1 mod 4 intlv (12801, 12801) pmap 0x00 nd 32 nu 32 ns 96
status up
DOCSIS channels are configured with the interface qam command by specifying the
CMTS slot where a QAM module is installed and a port number on that module.
Casa Systems CMTS

Each port on the QAM supports up to 32 narrowcast channels. With Annex B (6 MHz
channel offset), each port is comprised of four 192-MHz blocks totaling 768 MHz.
Figure 6-4 shows the four 192-MHz blocks and the default starting frequencies over
the channel time line.
Figure 6-4. QAM downstream channel time line frequency blocks

99000000 291000000 483000000 675000000
192 MHz 192 MHz 192 MHz 192 MHz

QAM 8x96 (Annex B)
The following commands configure 32 QAM narrowcast channels starting with

channel 0 at frequency 405000000 with 6-MHz Annex B channel separation.
Example
CASA(config) interface qam 0/7
CASA(config-if-qam 0/7)# channel 0 frequency 405000000 32
CASA(config-if-qam 0/7)# end
CASA(config)# show interface qam 0/7

interface qam 0/7
annex B
modulation 256qam
interleave 128x1
power 510
no channel 0 shutdown
Casa Systems CMTS

Casa Systems CMTS


no shutdown
In the following example, the show interface qam <slot/port> block command shows
how the channels are distributed across the four 192-MHz blocks, numbered 0–3. The
system assigns channels 0–12 to block 1 and channels 13–31 to block 2.
Blocks 0 and 3 have no channels assigned and are available if channels are to be
moved to higher or lower frequencies. Each block indicates the suggested starting
frequency, which is dynamically assigned by the CCAP.
The offset value in the display indicates the frequency width from the starting
(default) frequency for a given block. For example, an offset of 30 indicates the
starting frequency is 30 x 6 MHz, or 180 MHz from the system-assigned start. In the
CLI output, the channel 11 frequency is offset by 180 MHz (where
291000000+180000000=471000000).
Example
CASA(config)# show interface qam 0/7 block
interface qam 0/7 block 0
block frequency 99000000 block map 00000000

block frequency 291000000 block map fff80000
channel 0 freq 405000000 block 1 offset 19 status up

block frequency 483000000 block map 0007ffff
Casa Systems CMTS



block frequency 675000000 block map 00000000
block_map: 00000000 0007ffff fff80000 00000000
port status: up
shutdown channels:
CASA(config)#
Moving selected QAM channels to other frequencies
In the following CLI session, channels 16–23 were interactively moved to new
frequencies in block 2. Similarly, channels 24–31 were also interactively moved to
new frequencies in block 3. Note that the channel command in each instance specifies
the total number of channels to move. In each case, eight channels have moved.
Use the show interface qam <slot>/<port> block command to verify the moved
channels.
Example
C10G(config-if-qam 0/7)# channel 16 frequency 609000000 8
C10G(config-if-qam 0/7)# channel 24 frequency 801000000 8
C10G(config)# show interface qam 0/7 block

block 0 frequency 225000000
channel 0 frequency 405000000 block 0 offset 30
Casa Systems CMTS

Configuring QAM 8x8 downstream channels



The QAM 8x8 module provides eight channels per port where the eight channels are
configured in two contiguous or non-contiguous banks of four channels in the 47–
999 MHZ frequency range. As in previous releases supporting four channels per port,
the software automatically adjusts the frequencies on channels 0–3 and on channels 4–
7 based on the configured Annex (A, B, or C) for frequency separation. This means
that if you specify the frequency for channel 1 (with Annex A separation at 8 MHz),
Casa Systems CMTS

channels 0, 2 and 3 are correctly separated by 8 MHz based on the specified channel 1
frequency setting. The same applies to channels 4–7.
Example
In the following example, the two four-channel banks (0–3 and 4–7) are contiguous
across the frequency spectrum using Annex A separation at 8 MHz in the range 547–
603 MHz.
CASA(config)# show interface qam 11/0

interface qam 11/0
annex A
modulation 256qam
interleave 12
power 450
no shutdown
Example
In the following example, the channel command updates the channel 0 frequency to
470 MHz. Consequently, channels 0–3 were revised based on the 470 MHz frequency
and the Annex B 6 MHz separation.

Casa Systems CMTS

interface qam 11/0

annex B
modulation 256qam
interleave 128x1
power 510
channel 0 shutdown
channel 1 shutdown
channel 2 shutdown
channel 3 shutdown
channel 4 shutdown
channel 5 shutdown
channel 6 shutdown
channel 7 shutdown
shutdown
Example
In the following example, the two four-channel banks are non-contiguous across the
frequency spectrum due to a frequency change at channel 7. The range 470–494 MHz
applies to channels 0–3, and 591 MHz to 609 MHz applies to channels 4–7. Each
four-channel bank still maintains Annex B 6-MHz frequency separation.

CASA(config-if-qam 11/0)# show this
interface qam 11/0

annex B
modulation 256qam
interleave 128x1
power 510
channel 0 shutdown
channel 1 shutdown
channel 2 shutdown
Casa Systems CMTS

Enabling and disabling QAM ports and channels
channel 3 shutdown
channel 4 shutdown
channel 5 shutdown
channel 6 shutdown
channel 7 shutdown
shutdown
Enabling and disabling QAM ports and channels
The [no] shutdown command enables and disables the specified QAM port. The
default state for all QAM ports and channels is shutdown. This prevents interference
with existing cable-channel configurations. If the QAM port remains disabled,
enabling the individual channel has no effect until the QAM port is enabled.
Example: Enabling QAM port 0 in module slot 11

CASA(config-if-qam 11/0)# no shutdown
Example: Enabling channel 0 on QAM port 0 in module slot 11

CASA(config-if-qam 11/0)# no channel 0 shutdown
CASA(config-if-qam 11/0)# no shutdown
CASA(config-if-qam 11/0)# show this
interface qam 11/0

annex B
modulation 256qam
interleave 128x1
power 510
channel 1 shutdown
channel 2 shutdown
channel 3 shutdown
channel 4 shutdown
channel 5 shutdown
channel 6 shutdown
Casa Systems CMTS

Setting downstream port parameters

channel 7 shutdown
no shutdown
Setting downstream port parameters
The following CLI session displays the QAM downstream port parameters:
Example
CASA(config-if-qam 2/0)# ?
annex set annex type
channel channel
interface interface command
interleave channel interleave
modulation channel modulation
power power management
shared-channel video session on shared channel
shutdown shutdown the interface
spectral QAM spectrum
spectrum-tilt spectrum tilt
• annex — Sets the MPEG framing format for a QAM channel: Annex A @ 8-MHz
channel separation (in Europe), Annex B @ 6-MHz channel separation (in North
America), and Annex C @ 6-MHz channel separation (in Japan).
• channel — Sets the channel properties, as described elsewhere.
• interface — Sets another QAM interface.
• interleave — Sets the QAM interleave level to minimize the effect of burst noise
by spreading data over time. The valid values are 8, 16, 32, 64, 128x1, 128x2,
128x3, 128x4, 128x5, 128x6, 128x7, and 128x8. The default is 128x1 which is the
highest amount of interleaving; 8 is the lowest. When set, all channels on the port
are set to the same interleave level automatically.
• modulation — Sets the QAM modulation scheme. Valid values are 64qam,
128qam, 256qam, and off. The default is 256qam. QAM modulation is a port
property that applies to all channels on the port. When the modulation type is set
to off, no modulation signal is transmitted to the QAM port. The RF output of the
port is a continuous wave.
• power — Sets the QAM channel downstream power output level in one tenth of
dBmV. The range is 450–620. The default setting is 510.
Casa Systems CMTS

QAM output power levels
• shared-channel — Sets the shared channel properties, as described elsewhere.

• shutdown — Shuts down or (in its no form) restarts the QAM port.
• spectral — Turns on QAM spectral inversion. Spectral inversion is the reversal of
the orientation of the signal bandwidth with respect to the carrier frequency. This
setting is turned off by default.
• spectrum-tilt — Adjusts each channel’s power based on the channel’s position in
the frequency spectrum. A channel’s power normally decreases at higher
frequencies. Spectrum tilt compensates by gradually increasing power at the
higher end. At the default tilt value of 0, all channels have the same power level.
QAM output power levels
This power setting is for the RF output port that is also the sum of all enabled QAM
channels on the same port. The actual QAM channel output level depends on how
many QAM channels are enabled on that port. For example, a setting of 550
(55 dBmV for the port) with one channel enabled sets the QAM channel level to
55 dBmv. A setting of 550 with two channels enabled sets each QAM channel to an
output level of 52 dBmV. A setting of 550 with four channels enabled sets each QAM
channel to an output level of 49 dBmV.
The maximum output level (sum total of all channels) per QAM 8x8 is:
• 60 dBmV at one channel/port

• 56 dBmV at two channels/port
• 52 dBmV at four channels/port
• 49 dBmV at eight channels/port
The maximum output level (sum total of all channels) per QAM 8x96 is:
• 60 dBmV at one channel/port

• 59 dBmV at two channels/port
• 58 dBmV at four channels/port
Casa Systems CMTS

Configuring upstream channels
The maximum output level per QAM channel per the DOCSIS Downstream Radio
Frequency Interface (DRFI) specification is:
60 - ceil[3.6*log2(N)] dBmV, where N = number of channels enabled.
The CMTS configuration allows adjustment and override of QAM power output
levels based on real measurements. Because an actual power level can vary +/- 1 dB,
the power setting can be adjusted either higher or lower to compensate for the actual
reading. If the actual reading is 1 dB lower, then the QAM power setting in the CLI
can be increased by 1 dB.
Note: Both DOCSIS and Casa Systems specify the maximum QAM power
level for four channels at 580 (58 dBmV). However, the Casa CMTS allows
you to override the setting to 620. This setting can occasionally cause bit
errors or a slight increase in adjacent channel distortion. Some customers find
this an acceptable trade-off if they need to overcome a highly attenuated cable
plant. But unless such an overdrive is necessary, Casa recommends not
exceeding the 580 setting.
Setting the QAM power level higher than 580 is not recommended unless:
1. A measurement shows the actual CMTS output is slightly lower than what is
requested in CLI, or
2. A determination is made that the cable plant is highly attenuated, and the only
solution is to force the CMTS to overdrive its output level (as opposed to
removing attenuation in the cable plant).
Configuring upstream channels

Upstream ports are physical interfaces that provide the CM return path to the CMTS.
The Casa CMTS allows up to two logical channels in each upstream port in two
different A-TDMA modes. Each upstream port and logical-channel can be enabled or
disabled independently. The default state for all upstream ports and channels is
shutdown. If an upstream port is disabled, individual logical channels cannot be
enabled.
Casa Systems CMTS

Upstream port conventions
Upstream port conventions
The upstream port is defined in the following format:
X/Y.Z/C — Where X is the module slot number, Y is the port number, Z is the
physical channel number, and C is the logical channel number.
Depending on the specific CMTS model you are configuring, slot, port, and channel
numbers will vary. For example, the C10G and C100G CMTS valid slot numbers for a
QAM 8x8 module would be in the range 0–5 and 8–13, port numbers in the range 0–7,
and channel numbers in the range 0–7.
Example
The following CLI session shows the upstream channel format when the
show upstream command is executed on a C10G CMTS. The upstream interface in
system slot 11 specifies physical channel 0 at 11/0.0/0 and 11/0.0/1, and physical
channel 1 at 11/0.1/0 and 11/0.1/1.
C10G-CMTS(config-if-ups 11/0.1# show upstream

upstream channel burst noise rate (events/sec)
11/0.0/0 0.0
11/0.0/1 0.0
11/0.1/0 0.0
11/0.1/1 0.0
Configuring upstream channel parameters
The following CLI session displays the upstream port parameters:
CASA(config)# interface upstream 13/4.0

CASA(config-if-ups 13/4.0)# ?
channel-width upstream channel width
description description of the interface
frequency frequency band
ingress-cancellation ingress-cancellation configuration
interface interface command
logical-channel config logical upstream channel
map-advance upstream channel map advance
partial-service partial-service
power-adjustment upstream channel power adjust
power-level upstream channel power-level
rate-limit perform rate-limit on the upstream
Casa Systems CMTS

shutdown shutdown the interface

small-signal-compensation upstream channel small signal compensation
spectrum-rule spectrum rule assignment
voice-bw-reserve max bandwidth reserved for total call
• channel-width — Sets the total bandwidth of the specified channel in Hertz using
the actual units. Valid values are 200000, 400000, 800000, 1600000, 3200000,
and 6400000, where 6400000 is 6.4 MHz.
• description — Specifies the optional and arbitrary text string that provides
information about the upstream channel. Up to 64 alphanumeric characters can be
specified. If the string includes embedded blank spaces, then the text string must
be enclosed in quotation marks (“”).
• frequency — Sets the upstream channel frequency in the range 5–85 MHz per the
DOCSIS specification. In the United States, 5–42 MHz is used; other countries
use up to 65 MHz.
Note: On the upstream 16x8 module, the supported frequency range is

5–100 MHz, which allows deployment of CMs capable of 85 MHz and for
DOCSIS 3.1 CMs.
• ingress-cancellation — Enables or disables ingress cancellation. Ingress

cancellation enhances upstream data transmissions by removing impulse noise
and common path distortion. An ingress-cancellation sampling interval can be in
the range 10–1000 milliseconds. The default is 100 milliseconds.
• logical channel — Specifies the logical channel number, either 0 or 1, and sets
one or more channel parameters. See the section, “Configuring multiple upstream
logical channels.”
• map-advance — Defines the amount of look-ahead time for MAPs based on the
plant characteristics. The MAP advance on the CMTS can be configured for either
dynamic or static mode.
— Dynamic MAP advance automatically tunes the look-ahead time by
calculating the offset to the farthest CM on that upstream port. You can then
specify a delay value that defines an additional look-ahead time for MAPs to
allow for internal latencies and inaccuracies in the measurement system. The
minimum delay value is 200 microseconds; the maximum is 2000
microseconds.
Casa Systems CMTS

For example, map-advance dynamic 200 sets the look-ahead time to 200
microseconds more than the time calculated by the dynamic MAP advance
algorithm for the farthest CM on that port.
— Static MAP advance uses a fixed look-ahead time specified by the user. (For
reference, a mile of coax cable has a delay of about 7 microseconds; a mile of
fiber has a delay of about 8 microseconds.) The minimum value is 200
microseconds; the maximum is 4000 microseconds.
• partial-service — Sets the discrete Forward Error Correction (FEC) and
Signal-to-Noise Ratio (SNR) percentage thresholds to put the upstream channel in
partial service mode. See the Casa Systems – RF Cable Configuration Guide and
Command Reference for details on cable partial service.
• power-adjustment — Sets the input power threshold which determines whether
the CMTS sends power adjustments to the CM. If the CM transmits power is
within the threshold, the CMTS sends no adjustment. If it is beyond the threshold,
the CMTS sends a power adjustment. After 16 failed attempts, the CMTS stops
sending ranging and the CM remains offline. For normal operation, use the default
value of 1 dBmV. The command is helpful during troubleshooting when a CM
fails to complete ranging due to attenuation in the cable plant.
The CMTS can be set to continue to adjust the CM power output during ranging
response. If the power offset is within the power set by the
power-adjustment continue command, then the CM is properly ranged in
transmit power. If it is beyond this power, the CMTS continues to send power
adjust messages. The default setting is 2 dBmV.
• power-level — Sets CM output power levels to meet the desired upstream input
power level. The nominal input power level for the upstream RF carrier is in
decibels per millivolt (dBmV). The default setting of 0 dBmV is the optimal
setting for the upstream power-level. The power-level supported range is -16–
34 dBmV.
• rate-limit — Enforces the rate limit defined in the CM configuration file. The
default is enabled; use the no rate-limit command to disable rate limiting.
• shutdown — Shuts down or (in its no form) restarts the upstream port.
• spectrum-rule — Applies a previously configured spectrum rule to a service flow
over an upstream channel. With a spectrum rule assigned to an upstream interface,
Casa Systems CMTS

Configuring multiple upstream logical channels
the actions defined in the rule take place in the specified (or default) order of
priority if:
— Plant noise level exceeds SNR threshold defined explicitly in the commands
or by default.
— Percentage of correctable Forward Error Correction (FEC) errors of total
packets received on the upstream (during the polling period) exceeds the
defined or default threshold.
— Percentage of uncorrectable FEC errors of total packets received on the
upstream (during polling period) exceeds the defined or default threshold.
A rule can be assigned to any number of upstream interfaces. However, only one
rule assignment per upstream interface is allowed.
• voice-bw-reserve — Percentage of reserved bandwidth dedicated for voice calls
on upstream channels. When the configured percentage threshold is reached, no
new voice calls are accepted on that channel. Any unused portion of the
configured percentage is available for data sessions. However, new voice calls
assumes priority and preempts any data sessions. You can also reserve a portion of
the configured voice bandwidth percentage for emergency calls.
The CMTS supports dynamic channel width switching between logical upstream
channels (0 and 1) using the same center frequency. This feature allows legacy D1.x
CMs to transmit upstream at 3.2 MHz over one logical channel, while the second
logical channel is available for D2.0 (and later) CMs to transmit upstream at 6.4 MHz.
Note: Earlier Casa software releases support one logical channel only, where
the physical channel is present in the configuration as logical channel 0.
Time-division multiplexing provides the switching between the logical channels, with
CM upstream transmission taking place over one logical channel at a time.
Supported upstream channel widths per upstream logical channel are configurable at
0.2, 0.4, 0.8, 1.6, 3.2, and 6.4 MHz. Depending on the configured upstream channel
width, a logical channel provides an SNR increase for higher QAM modulation, a
reduction of integrated noise, and an increase in total bandwidth for improved
Casa Systems CMTS

efficiency within the same spectrum. For example, dividing one 6.4-MHz logical
channel in half increases SNR by 3 dB.
Example
The following CLI session shows an upstream interface configuration with the logical
channels set at frequencies for CMs operating on this interface. Logical channel 0 is
set 6.4 MHz, and logical channel 1 is set at 3.2 MHz. The CMTS dynamically
performs Time Division Multiplexing (TDM) switching between the logical channels
when the CMTS sends upstream transmission grants to the CMs. Channel selection is
based on the requirements of the requesting CM.
C10G(config-if-ups 13/0.0)# show interface upstream 13/0

interface upstream 13/0.0
spectrum-rule 35
frequency 5000000
channel-width 3200000
power-level 0
power-adjustment continue 2
power-adjustment threshold 1
voice-bw-reserve 75 emergency 0
rate-limit
ingress-cancellation 100
logical-channel 0 prov-attr-mask 0x0
logical-channel 0 channel-width 6400000
logical-channel 0 profile 4
logical-channel 0 minislot 2
logical-channel 0 data-backoff automatic
logical-channel 0 ranging-backoff 0 4
logical-channel 0 pre-equalization
logical-channel 0 power-offset 0
logical-channel 0 ranging-priority 0x0
logical-channel 0 class-id 0x0
no logical-channel 0 shutdown
logical-channel 1 prov-attr-mask 0x0
logical-channel 1 channel-width 3200000
logical-channel 1 profile 4
logical-channel 1 minislot 8
logical-channel 1 data-backoff automatic
logical-channel 1 ranging-backoff 0 4
logical-channel 1 pre-equalization
logical-channel 1 power-offset 0
logical-channel 1 ranging-priority 0x0
logical-channel 1 class-id 0x0
no logical-channel 1 shutdown
Casa Systems CMTS

no shutdown
In addition to the dynamic channel width switching between the logical channels, an
upstream power offset level setting (relative to the physical channel power) can be
configured independently on each logical channel in the range -10–10 dB.
Note: Earlier Casa software releases support one logical channel only, where
the physical channel is present in the configuration as logical channel 0. There
is no logical channel 1.
The following CLI session displays the upstream logical-channel parameters:
CASA(config-if-ups 13/0.0)# logical-channel 0 ?

channel-width upstream channel width
class-id channel class id
data-backoff upstream channel data backoff
description description of the interface
minislot upstream channel minislot size
power-offset power-offset relative to channel power-level
pre-equalization logic_upstream equalization
profile upstream channel modulation profile
prov-attr-mask provisioned attribute mask
ranging-backoff upstream channel ranging backoff
ranging-priority ranging hold-off priority field
shutdown shutdown the logical channel
spectrum-rule spectrum rule assignment
• channel-width — Sets the total bandwidth of the specified channel in hertz using
the actual units. Valid values are 200000, 400000, 800000, 1600000, 3200000,
and 6400000, where 6400000 is 6.4 MHz.
• class-id — Specifies the ranging hold-off upstream channel description (UCD)
TLV 19 bit field identifier in the range 0x0–0xFFFFFFFF. Specifying 0x0
disables the identifier.
• data-backoff, ranging-backoff — Specifies the DOCSIS-specified method of
contention resolution for CMs requesting to transmit on the upstream channel,
truncated as a binary exponential backoff value, with the initial backoff window
and the maximum backoff window controlled by the CMTS. The CMTS specifies
backoff window values for data transmission and initial ranging. It sends these
values downstream as part of the Bandwidth Allocation Map MAC message.
The values are configurable and are “power-of-two” values. For example, a value
of 4 indicates a window between 0 and 15; a value of 10 indicates a window
Casa Systems CMTS

between 0 and 1023. You can set fixed start and end values for data backoff on the
upstream ports, or set the upstream ports for automatic data backoff. The user has
the same options for ranging backoff. For both backoff windows, the default start
value is 0; the default end value is 4. Valid values are 0–15.
Note: Automatic dynamic backoff algorithm is recommended for data

transmission. For initial ranging, use backoff values of 4 and 10.
• description — Specifies the optional and arbitrary text string that provides
information about the upstream channel. Up to 64 alphanumeric characters can be
specified. If the string includes embedded blank spaces, then the text string must
be surrounded by quotation marks (“”).
• frame — Sets the Synchronous-Code Division Multiple Access (SCDMA) frame
settings on the upstream channel. SCDMA in DOCSIS 3.0 improves the
maximum upstream bandwidth by allowing the same physical upstream channel
to receive multiple bursts simultaneously using a time and code data transmission
technique. Multiple CMs can send simultaneously using their own codes in the
same upstream time slot without interfering with each other. Data is sent using up
to 128 spreading codes. Parameters are: number of spreading intervals, codes per
minislot, and maximum number of active codes.
• minislot — Set the upstream minislot size on the channel in ticks (1, 2,4,8,16,32,
64, and 128). The minislot is a series or group of time components that make up
one upstream time interval. These intervals vary in size starting at time-zero (t0)
until the end of the interval where t0 begins again. Time-division multiplexing
(TDM) scheduling sets both long and short intervals in the time line where the
interval size is based on traffic conditions. Each minislot within each interval is
6.25 microseconds.
• power-offset — Specifies an upstream power offset level setting relative to the
physical channel power independently on each logical channel in the range -10–
10 dB. The default setting is 0, no power offset.
• pre-equalization — When enabled, this parameter compensates for the difference
in delays between the signal on the lower part of the 6-MHz channel spectrum and
the higher part caused by imperfections in the cable plant. The default state is
disabled, but Casa recommends that it be enabled.
• profile — Modulation profile identifier to be used on this logical channel. A
modulation profile is a collection of burst profiles that are sent to CMs in
Casa Systems CMTS

upstream channel descriptor (UCD) messages to configure CM transmit

parameters. Primary and secondary modulation profiles are supported in the
command. However, secondary profiles are not supported on logical channel 1.
Note: When specifying a secondary profile, both the primary and secondary
profiles must match the upstream channel type. Casa Spectrum Management
(CSM) will not change to a mismatched profile. The secondary profile also
must be less bandwidth-efficient than the primary profile.
When plant signal quality deterioration causes threshold hits, CSM changes to
the secondary modulation profile. The show running-config command shows
the transmit configuration using the secondary-profile. When signal quality
satisfies the primary profile’s SNR plus 3 dB (or to the default SNR threshold if
the threshold is not defined in the rule), CSM changes the modulation profile
back to the primary.
Multiple secondary profiles can be specified for an upstream interface, so multiple

steps can be achieved for dynamic modulation profile change.
Example
CASA(config-if-ups 13/0.0)# logical-channel 0 profile 3
secondary-profile 12,20,33
Where:
1. Modulation profile 12, 20 and 33 have compatible channel types.
2. The order of 12, 20, and 33 specifies the priority which CSM tries to use the
profiles.
3. Lower priority suggests a less bandwidth efficient modulation profile.
• prov-attr-mask — Set the provisioning attribute mask on this logical channel.
When the CMTS receives a service flow request from a CM, the CMTS compares
a TLV integer received in the service flow request with the attribute masks of all
of the available channels it manages. The CMTS assigns a requesting CM to the
channel specified by the attribute mask that represents the attributes presented in
the TLV included in the service flow request. The mask can be user-defined in the
range 0x0–0xFFFFFFFF (default 0x0), or can be set for bonding,
high-availability, or the low latency provisioning attribute masks, or all of the
above. To disable the mask, specify the default setting of 0x0.
Casa Systems CMTS

Binding channels to the MAC domain
• ranging-priority — Specifies the ranging hold-off priority bit TLV in the value
range 0x0–0xFFFFFFFF. The hold-off priority is the maximum time that a CM
can prevent transmissions on an upstream channel in response to its ranging class
ID matching a bit value in the ranging hold-off priority field in the CM
configuration file. The default timer value of 300 seconds (five minutes) per
DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification cannot be
changed. To disable the hold-off priority bit TLV, specify the default setting of
0x0.
• shutdown — Shuts down or (in its no form) restarts the logical channel.
• spectrum-rule — Applies a previously configured spectrum rule to a service flow
over an upstream logical channel, much like for a physical channel, as described
earlier.
Binding channels to the MAC domain

As covered in Chapter 1, CMTS operations overview, at least one upstream and one
downstream channel must be configured in the DOCSIS MAC in order for a CM to
perform initial ranging and registration with the CMTS. Upstream and downstream
channels are added to MAC domain using a unique channel identifier, followed by the
channel in format slot/port.channel/logical_channel for upstream interfaces, and
slot/port/channel for QAM interfaces.
The following CLI session binds a set of upstream and downstream channels to the
DOCSIS-MAC domain 30. Upstream channels are configured on CMTS slot 13,
ports 0 to 7, channel 0; downstream channels are configured on CMTS slot 11, port 0,
channels 0 to 7.
After binding channels to the MAC domain, you need to create one or more service
groups, which constitute a subset of the channels supported in the MAC domain. See
the section “Configuring service groups” for information.
Note: If an upstream or downstream channel is already assigned to a

DOCSIS MAC domain, the message <chan> already existed in MAC
domain <num> with channel id <num>, binding <chan> to mac-domain
<num> failed is displayed at the CLI. Similarly, the message chan-id is
already bound to <chan>, binding <chan> to mac-domain <num>
failed appears if the specified channel identifier is presently configured.
Casa Systems CMTS

Configuring service groups
Example: Binding upstream and downstream channels to MAC domain

CASA(conf-if-mac 30)# upstream 1 interface upstream 13/0.0/0
CASA(conf-if-mac 30)# downstream 1 interface qam 11/0/0
CASA(conf-if-mac 30)# show this
no shutdown
no early-authentication-encryption
no multicast-dsid-forward
no tftp-enforce
no tftp-proxy
upstream 1 interface upstream 13/0.0/0

A service group specifies the downstream channels (DS-SG) over which a CM
receives traffic from the MAC domain, or the upstream channels (US-SG) over which
the CM transmits to the CMTS. The combination of both upstream and downstream
Casa Systems CMTS

service groups is known as the cable modem service group (CM-SG), or DOCSIS
fiber node that supports a given service area. In most cases, one or more configured
service groups contain a subset of the same channels declared in a specific DOCSIS
MAC domain.
Note: Service groups are required for cable traffic load balancing and for
channel bonding over D3.0 CMs. Service groups are NOT required for CMs to
register and come only as long as upstream and downstream channels are
configured in the DOCSIS-MAC domain. See “Binding channels to the MAC
domain.” See also the Casa Systems – RF Cable Configuration Guide and
Command Reference for information about the RF over Glass (RFoG)
upstream scheduler feature, where the CMTS limits the number of
simultaneous upstream transmitters coupled to the same optical fiber splitter
to a single transmitter. RFoG is enabled for a service group using the
upstream rfog-scheduler property.
Service groups are created at the top level configuration mode at the CMTS.
Example: Create a named service group and specify channels
The following CLI session creates the service group Andover and adds (or binds)
previously configured upstream and downstream channels to it. In the example,
upstream channels on CMTS module 13 and downstream channels in slot 11 are
configured for Andover. An optional description is also configured. The
show service group command displays the service group configuration.
CASA(config)# service group Andover

CASA(conf-svc-grp Andover)# upstream 13/4.0
CASA(conf-svc-grp Andover)# qam 11/0/0
CASA(conf-svc-grp Andover)# description “Upstream and downstream
channels for North Andover fiber node at Exit 8”
CASA(conf-svc-grp Andover)# show service group Andover
service group Andover
description "Upstream and downstream channels for North Andover
fiber node at Exit 8"
Casa Systems CMTS

Enabling D3.0 channel bonding
qam 11/0/0
qam 11/0/1
qam 11/0/3
qam 11/0/4
qam 11/0/5
qam 11/0/6
qam 11/0/7
upstream 13/4.0
upstream 13/5.0
upstream 13/6.0
upstream 13/7.0
Using service groups vs. static bonding groups
A service group provides dynamic selection of upstream and downstream channels to

which a CM has access. For D3.0 CMs that support channel bonding operations, the
Casa CMTS automatically creates channel bonding groups by dynamically selecting
channels that belong to the same service group and docsis-mac domain.
In networks where traffic from a particular CM or service area must use a specific
downstream or upstream channel, upstream and downstream bonding groups can be
configured using the bonding-group configuration object to direct traffic streams to
specific channels configured at the CMTS. This means that the CMTS uses a
configured bonding group and only the specific channels defined in the group. The
CMTS does not make the channel selection dynamically from a group of available
channels at the MAC domain.
Casa highly recommends the dynamic service group configuration over the static
bonding-group configuration. The static bonding-group should only be used in very
specific cases where dynamic channel selection is not feasible.
Enabling D3.0 channel bonding

As covered in Chapter 1, CMTS operations overview, channel bonding is a
DOCSIS 3.0 capability that enables the CMTS to logically combine multiple
downstream or upstream channels for extended bandwidth for CMs with multiple
transmitters and receivers. For downstream channels, the MAC domain descriptor in
the MPEG-2 transport stream informs the CM about the receive channel configuration
and the receive channel set to be used by a registered CM.
Casa Systems CMTS

Attaining maximum throughput over channel bonded CMs
Channel bonding requires the CMTS service group and docsis-mac configurations,
as covered in the previous sections.
Example: Enabling channel bonding in DOCSIS MAC

CASA(conf-if-mac 30)# upstream channel bonding
CASA(conf-if-mac 30)# downstream channel bonding
Example: Enabling channel bonding in service group

CASA(config)# service group SVGP
CASA(conf-svc-grp SVGP)# downstream channel bonding
CASA(conf-svc-grp SVGP)# upstream channel bonding
Attaining maximum throughput over channel bonded CMs
This section describes how to configure the CMTS for maximum downstream and
upstream throughput over D3.0 CMs capable of channel bonding. The examples and
recommended settings are based on Casa test cases where maximum throughput was
attained. However, Casa recommends using the recommended settings as a starting
point, as additional tuning may be necessary for your particular network.
Verifying CM channel bonding
The show cable modem bonding command displays the CM MAC address, interface,
and channel set information for each CM transmitting over bonded channels. (You can
also use the show cable modem non-bonding command to show the non-bonded
channels.) The show upstream channel set displays the set of upstream channels
assigned to a CM for D3.0 channel bonding. Likewise, the show downstream
channel set displays the set of downstream channels assigned to a CM for D3.0
channel bonding.
The follow CLI session displays two CMs that are transmitting over D3.0 bonded
channels using the Casa-assigned channel set identifier 256 using the channels
configured in the service group.
CASA# show cable modem bonding

MAC Address MAC US DS US DS US CHAN and DS CHAN
id Intf Intf SET SET EXCLUDED EXCLUDED
0050.bfb9.020b 1 2/0/0 0/0/0 256 256
0050.bfb9.0220 2 2/4/0 0/1/0 256 256
Casa Systems CMTS

Optimizing TCP window sizes at CPEs
CASA# show upstream channel set

MAC Chan Channel
ID Set List
1 1 2/0/0
1 2 2/1/0
1 3 2/2/0
1 4 2/3/0
1 256 2/0/0, 2/1/0, 2/2/0, 2/3/0
2 1 2/4/0
2 2 2/5/0
2 3 2/6/0
2 4 2/7/0
2 256 2/4/0, 2/5/0, 2/6/0, 2/7/0
CASA# show downstream channel set
MAC Chan Channel
ID Set List
1 1 0/0/0
1 2 0/0/1
1 3 0/0/2
1 4 0/0/3
1 256 0/0/0, 0/0/1, 0/0/2, 0/0/3
2 1 0/1/0
2 2 0/1/1
2 3 0/1/2
2 4 0/1/3
2 256 0/1/0, 0/1/1, 0/1/2, 0/1/3
Optimizing TCP window sizes at CPEs
TCP window sizes should be adjusted on CPE devices to improve throughput.
Example: On MS-Windows-based CPEs
Microsoft Windows-based tools such as TCP Optimizer can be used to optimize the
TCP window size on CPE devices by choosing the “optimal settings” option.
Example: On Linux-based CPEs
On Linux devices, the following changes are recommended:
# increase TCP max buffer size settable using setsockopt()

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
# set max to at least 4MB, or higher if you use very high BDP paths
Casa Systems CMTS

Adjusting interface QAM and interface upstream settings
net.ipv4.tcp_rmem = 4096 87380 16777216

net.ipv4.tcp_wmem = 4096 65536 16777216
Increase the size of the interface queue using the following command:
ifconfig eth0 txqueuelen 1000
For Linux 2.6, adjust the sysctl settings as follows:
# don't cache ssthresh from previous connection

net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
# recommended to increase this for 1000 BT or higher
net.core.netdev_max_backlog = 2500
# for 10 GigE, use this
# net.core.netdev_max_backlog = 30000
Adjusting interface QAM and interface upstream settings
The CMTS should have the following configuration to get maximum throughput on
channel bonding and non-bonding CMs.
Example: Edit QAM channel interleave and modulation type
The downstream QAM interface channel modulation type should be set to 256qam
and the channel interleave should be 8. Use the following commands to set these
parameters:

CASA(config-if-qam 0/0)# interleave 8
CASA(config-if-qam 0/0)# modulation 256qam
Note: For Annex A, the QAM interleave is set at 12 and cannot be changed.
Example: Edit the upstream MAP size
Set the upstream map size to 2:
CASA(config)# upstream map size 2
Casa Systems CMTS

Tuning modulation profiles
Example: Edit the upstream channel-width and map-advance
On the upstream interfaces, set the channel-width to 6.4 MHz and the channel
map-advance to static with a maximum delay of 200 milliseconds:
CASA(config)# interface upstream 2/0

CASA(config-if-ups 2/0)# channel-width 6400000
CASA(config-if-ups 2/0)# map-advance static 200
CASA(config-if-ups 2/0)# logical-channel 0 minislot 4
Tuning modulation profiles
Making the number of FEC error correction bytes smaller in the modulation profile to
reduce overhead helps increase throughput. This new modulation profile is the same
as the predefined modulation profile 3 with the exception of the reduced number of
FEC error correction bytes. It can be configured as follows:
Example: Edit modulation profile to reduce FEC error correction bytes

CASA(config)# modulation-profile 10
CASA(config-mod-prof-10)# request atdma qpsk off 64 0 16 338 0 16 fixed
on 1 1536 qpsk0
CASA(config-mod-prof-10)# initial atdma qpsk off 640 5 34 338 0 48
fixed on 1 1536 qpsk0
CASA(config-mod-prof-10)# station atdma qpsk off 384 5 34 338 0 48
CASA(config-mod-prof-10)# a-short atdma 64qam off 104 4 75 338 6 8
CASA(config-mod-prof-10)# a-long atdma 64qam off 104 4 220 338 0 8
Execute the show modulation-profile <id> command to display the details of a given
modulation profile:
CASA(config-if-ups 2/0)# show modulation-profile 3

modulation-profile 3
request atdma qpsk off 64 0 16 338 0 16 fixed on 1 1536 qpsk0
initial atdma qpsk off 640 5 34 338 0 48 fixed on 1 1536 qpsk0
station atdma qpsk off 384 5 34 338 0 48 fixed on 1 1536 qpsk0
a-short atdma 64qam off 104 12 75 338 6 16 shortened on 1 1536 qpsk1
a-long atdma 64qam off 104 16 220 338 0 16 shortened on 1 1536 qpsk1
Casa Systems CMTS

Editing the CM configuration file
The upstream channel modulation profiles should then be modified as follows to use
the new modulation profile:
CASA(config)# interface upstream 2/0

CASA(config-if-ups 2/0)# logical-channel 0 profile 10
CASA(config-if-ups 2/0)# interface upstream 2/1
Editing the CM configuration file
Set the maximum-traffic-burst and maximum-concatenation-burst in the CM

configuration file to 24480 bytes on both upstream and downstream service flows.
Note: Enabling Baseline Privacy Interface (BPI) reduces performance and

causes fluctuations in the upstream throughput rates. For details on BPI, see
Chapter 3, “Administering CMTS security.”
Load balancing CM traffic

For information on configuring traffic load balancing over service group channels at
the CMTS, see Chapter 7, “Load balancing CMTS traffic.”
Casa Systems CMTS

7-1
Chapter 7. Load balancing CMTS

traffic
About this chapter

This chapter provides information on load balancing upstream and downstream cable
modem (CM) traffic over CMTS channels over one or more physical interfaces. Load
balancing distributes CM traffic to best utilize available bandwidth and CMTS
resources based on load balancing execution rules, groups, policies, and usage
thresholds. As a result, traffic between the CM and CMTS remains balanced during
peak traffic periods.
Topic Page
CMTS load balancing overview 7-2

Static and dynamic load balancing 7-2
Load balancing restrictions and limitations 7-3
Load balance configuration prerequisites 7-4
Enabling load balancing 7-4
Load balancing configuration steps 7-5
Creating load balancing groups 7-5
General load balancing groups 7-6
Restricted load balancing groups 7-9
Adding CMs to the restricted load balancing group 7-12
Configuring policies and rules 7-14
Load balancing policy decision processing 7-14
Defining basic load balancing rules 7-15
Defining execution rules 7-16
Load balancing over suspicious channels 7-22
Casa Systems CMTS

CMTS load balancing overview
Topic Page
Using exclusion lists 7-22

Load balancing configuration examples 7-23
Configure static general load balancing 7-24
Create an execution rule to enable dynamic load balancing 7-25
Display and assess load balance statistics 7-26
Create special load balancing configurations 7-27
CMTS load balancing overview

When a CM registers with the CMTS, traffic between the CM and the CMTS is
carried over random upstream and downstream channels. In most cases, while a CM
has access to multiple upstream and downstream channels, a CMs use the same
upstream and downstream channel. To load balance traffic on these channels, two
methods are available:
1. Load balancing based on the number of CMs on CMTS channels, or

2. Load balancing based on a configured percentage of current channel utilization.
Static and dynamic load balancing
The CMTS performs load balancing in one of two ways, or a combination of the two:
static load balancing or dynamic load balancing.
Static load balancing takes place when a CM sends its initial ranging request message
to the CMTS. For DOCSIS 1.0 1.1 and 2.0 CMs, the CMTS responds with a ranging
response (RNG-RSP) message that includes either a Downstream Frequency Override
or an Upstream Channel ID Override field that instructs the CM which channels it
should use. For DOCSIS 3.0 CMs, when a CM sends its registration request
(REG-REQ) messages, the CMTS responds with a registration response (REG-RSP)
message to instruct the CM to select the channels.
Dynamic load balancing moves CMs among upstream and downstream channels
within the same service group after their initial difference between two interfaces
exceeds a defined percentage. The CMTS uses downstream and upstream dynamic
Casa Systems CMTS

Load balancing restrictions and limitations
channel change messages (DCC) to move CMs with single upstream/downstream

channels, and dynamic bonding change (DBC) messages to move CMs with bonded
upstream/downstream channels to different bonding groups.
Note: For DOCSIS and EuroDOCSIS 3.0 CMs, the dynamic load balancing
software generates a downstream channel set with a minimum load to fit the
CM‘s receive channel profile (RCP). This prevents rejection of the new
channel set so that load balancing is not canceled when the assigned CM is
under load.
The CMTS does not move CMs to disconnected (idle) downstream channels where
there are no registered online CMs.
Load balancing restrictions and limitations
The follow restrictions and limitations apply to traffic load balancing between the
CMTS and registered online CMs:
• Load balancing can only be performed over upstream and downstream interfaces
sharing the same physical connectivity. This means that load balancing can only
be done over upstream and downstream interfaces belonging to the same service
group.
• Load balancing is not restricted to upstream and downstream channels belonging
to the same DOCSIS MAC domain interface. Load balancing crossing different
MAC domains is supported.
• Upstream and downstream interfaces with mixed single upstream/downstream
channel CMs and bonded upstream/downstream channel CMs can be load
balanced. CMs with multiple upstream/downstream channels count as one CM on
each of its upstream or downstream channels.
• Load balancing does not support a load balance group with mixed-annex
downstream channels. Downstream channels must be included in two different
service groups, each having its own annex.
Casa Systems CMTS

Load balance configuration prerequisites
Load balance configuration prerequisites
Before configuring the load balancing parameters, ensure that you have edited the
CMTS configuration file to include the following:
1. Network interfaces, such as interface gige 0, interface gige 1, etc.

2. All downstream interfaces that participate in load balancing, such as
interface qam 0/0, interface qam 0/1, etc. on the same module. Each
downstream interface should have the channel and frequency settings configured
if different from the default settings.
3. All upstream interfaces that participate in load balancing, such as
interface upstream 1/0, interface upstream 1/1, etc. Each upstream interface
should have the channel-width and frequency settings configured if different from
the default settings.
4. Any networking protocols that enable CMs to connect and register with the
CMTS.
5. DOCSIS MAC interfaces and service groups, as covered in the section “General
load balancing groups.”
Enabling load balancing

To enable load balancing at the CMTS, enter the following command:
CASA(config)# load-balance enable
Enabling static load balancing across MAC domains

The CMTS supports static load balancing across MAC domains in networks where
upstream and downstream channels are on two MAC domains, such as "docsis-mac 1"
and "docsis-mac 2." Use the load-balance enable across-mac command to specify
upstream precedence (default), or specify the downstream option for downstream
precedence.
By default, the upstream channel has precedence in load balancing across MAC
domains, where the lowest loaded (least busy) upstream channel is selected within the
service group. Then, the lowest loaded downstream channel is selected within the
Casa Systems CMTS

Load balancing configuration steps
MAC domain of the selected upstream channel. If the downstream precedence is

configured, then the downstream channel is selected first.
The CMTS uses downstream frequency override and the upstream channel ID
override in the ranging response message to move a CM to a different MAC domain if
needed. This applies to all DOCSIS 1.0, 1.1, 2.0 and 3.0 CMs. The SID in the ranging
response message is 0x3fff.
Additionally, use the load-balance enable across-mac downstream command to

specify downstream load balancing preference on channels within a MAC domain.
Example: Enable load balancing across MAC domains

CASA(config)# load-balance enable across-mac downstream
Load balancing configuration steps

Configuring load balancing requires the following steps:
1. Define the MAC domains and the service groups

2. Define the basic rules and/or the execution rules.
3. Define the load balancing policy and assign the rules to the policy.
4. Apply the policy to a load balancing group, either the default group or a restricted
load balance group.
To apply a load balancing policy globally, apply it to the default group.
To apply different load balancing policies to different MAC domain/service groups,

first define the rules and the policies. Then create a restricted load balance group, and
assign it to the MAC domain/service group.
Creating load balancing groups

A load balancing group is a set of upstream and downstream channels over which a
CMTS performs load balancing for a set of CMs. Because load balancing only
operates on upstream and downstream interfaces sharing the same physical
Casa Systems CMTS

General load balancing groups
connectivity, the upstream and downstream interfaces have to belong to the same
service group.
Both channel bonding and non-channel bonding CMs can participate in load
balancing. Channel bonding CMs count as one CM for each of its channels.
A load balancing group has the following attributes:
• A set of downstream and upstream channels in the same CM service group.

• A policy that governs if and when a CM can be moved.
• An initial technique for the CM during load balancing.
There are two types of load balancing groups:
• General load balancing group — The CMTS creates a general load balancing
group for every MAC domain CM service group (MD-CM-SG).
• Restricted load balancing group — The CMTS selects specific upstream and
downstream channels within the MD-CM-SG for a restricted load balancing
group.
During CM registration, the CMTS attempts to assign each CM to a load balancing

group under the following conditions:
1. If the CM is assigned to a service type or restricted load balancing group ID using

the CMTS management objects, or if the registration request contains a service
type TLV or a load balancing group ID TLV, the CMTS assigns a restricted load
balancing group to the CM.
2. If the CMTS determines a general load balancing group for the CM, the CMTS
then assigns the general load balancing group to the CM.
3. If the CMTS cannot determine either a restricted load balancing group or a
general load balancing group for the CM, the CMTS does not load balance traffic
on that CM.
The CMTS automatically creates one general load balancing group for each MD-SG
after the service group and MAC domain interface configuration.
Casa Systems CMTS

In the following example, the CMTS generate a general load balance group with
service group FN_A and MAC domain 1. It contains downstream channels qam 0/0/0,
qam 0/0/1, qam 0/0/2, qam 0/0/3 and upstream channels upstream 4/0.1, upstream 4/
1.1, upstream 4/2.1, and upstream 4/3.1. When a general load balance group is
created, it uses load balancing parameters from predefined general load balance group
default settings.
Example: Create the service-group and docsis-mac interfaces

CASA(config)# service group FN_A
CASA(conf-svc-grp FN_A)# qam 0/0/0
CASA(conf-svc-grp FN_A)# upstream 4/0.1/0
CASA(conf-svc-grp FN_A)# upstream 4/3.1

Example: Edit the general-group default-settings
To enter the general load balance group default, use the following command in config
mode:
CASA(config)# load-balance general-group default-settings

CASA(load-bal-general-default)#
The following commands are available under the general load balancing group
default-settings:
• enable
• initial-tech
• policy-id
Casa Systems CMTS

Example: Enable the general load balancing group
To enable or disable the load balancing function on general load balancing groups:
CASA(load-bal-general-default)# enable (default)

CASA(load-bal-general-default)# no enable
Example: Specify the initial load balancing technique
To specify the initial technique that the CMTS uses to load balance and move CMs:
CASA(load-bal-general-default)# initial-tech broadcast-ranging

CASA(load-bal-general-default)# initial-tech direct (default)
CASA(load-bal-general-default)# initial-tech period-ranging
CASA(load-bal-general-default)# initial-tech reinitialize-mac
CASA(load-bal-general-default)# initial-tech unicast-ranging
• broadcast-ranging — The CM broadcasts the full initial ranging request without
going offline and performing re-registration with the CMTS.
• direct — This is the initial technique default setting. The CM moves directly to
another channel without performing any type of ranging.
• period-ranging — The CM move to a new channel, but performs periodic
ranging requests for an improved channel opportunity.
• reinitialize-mac — The CM MAC address is reset causing the cable model to go
offline and then re-register with the CMTS on new channel.
• unicast-ranging — The CM performs an initial ranging request for a dedicated
channel from the CMTS where there is no other transmission activity.
Example: Create the policy identifier
Polices describe the rules to execute when load balancing traffic across CMTS
interfaces. To specify a previously configured policy to apply during load balancing:
CASA(load-bal-general-default)# policy-id <0:4294967295>
Refer to the section, “Configuring policies and rules” for further information.
Casa Systems CMTS

Restricted load balancing groups
Example: Specify the general-group mac-domain and service-group
To enter the general load balance group for a previously configured MAC domain and
service-group, use the following command in config mode:
CASA(config)# load-balance general-group mac-domain <1:96>

service-group <name>
CASA(config)# load-balance general-group mac-domain 1 service-group
FN_A
CASA(load-bal-general-mac-1-sg-FN_A)#
A restricted load balance group is similar to the general load balance group.
Restricted load balancing groups require that you specify unique upstream and
downstream channel set information that is not specified in the general group.
Example: Create the restricted-group identifier
To enter the load balance restricted-group context in the CLI, use the following
command in config mode:
CASA(config)# load-balance restricted-group <id>
Specify the group-id parameter in the number range 1–4294967296. This number
uniquely identifies the restricted load balancing group among other groups that you
create. The group ID must be unique within the CMTS.
CASA(config)# load-balance restricted-group 1

CASA(load-bal-restrict 1)#
The following commands are available under the restricted-group configuration:
• docsis-mac
• enable
• initial-tech
• policy-id
• qam
Casa Systems CMTS

• service-type-id
• upstream
Example: Specify the docsis-mac interface for the restricted-group
To enter the load balance restricted-group for a previously-configured MAC domain

in the range 1–32, use the following command in config mode:
CASA(load-bal-restrict 1)# docsis-mac <1:96>

CASA(load-bal-restrict 1)# docsis-mac 1
Example: Enable the restricted-group
To enable or disable the load balancing function on restricted load balancing groups:
CASA(load-bal-restrict 1)# enable (default)

CASA(load-bal-restrict 1)# no enable
Example: Specify initial load balance technique for the restricted-group
To specify the initial technique that the CMTS uses to load balance and move CMs:
CASA(load-bal-restrict 1)# initial-tech broadcast-ranging

CASA(load-bal-restrict 1)# initial-tech direct (default)
CASA(load-bal-restrict 1)# initial-tech period-ranging
CASA(load-bal-restrict 1)# initial-tech reinitialize-mac
CASA(load-bal-restrict 1)# initial-tech unicast-ranging
• broadcast-ranging — The CM broadcasts the full initial ranging request without
going offline and performing reregistration with the CMTS.
• direct — This is the initial technique default setting. The CM moves directly to
another channel without performing any type of ranging.
• period-ranging — The CM move to a new channel, but performs periodic
ranging requests for an improved channel opportunity.
• reinitialize-mac — The CM MAC address is reset causing the cable model to go
offline and then re-register with the CMTS on new channel.
• unicast-ranging — The CM performs an initial ranging request for a dedicated
channel from the CMTS where there is no other transmission activity.
Casa Systems CMTS

Example: Create the restricted-group policy identifier
Polices describe the rules to execute when load balancing traffic across CMTS
interfaces. To specify a previously configured policy to apply during load balancing:
CASA(load-bal-restrict 1)# policy-id <0:4294967295>
Refer to the section, “Configuring policies and rules” for information.
Example: Specify the restricted-group service-type-id string
The service-type-id parameter specifies the unique string that selectively controls
load balancing to CMs belonging to particular service type in this restricted-group,
such as CM device type, DOCSIS version, and service class. Only CMs that send a
matching service-type-id string to the CMTS during registration are load balancing
and moved to another channel.
Specify a string with up to 16 alphanumeric characters. If blank spaces are necessary

in the string, surround the string with quotation marks.
CASA(load-bal-restrict 1)# service-type-id <string>

CASA(load-bal-restrict 1)# service-type-id “DOCSIS 3.0”
Example: Specify the restricted-group upstream slot, port, and channel
The upstream parameter allows you to add upstream channels to restricted-group in

the current MAC domain, as configured with the docsis-mac parameter. Only the
specified upstream channels in the restricted-group are balanced.
Note: Make sure that you appropriately bind each upstream slot/port.channel/
logical channel under the interface docsis-mac configuration.
CASA(load-bal-restrict 1)# upstream <slot>/<port>.<chan>/<log_chan>

CASA(load-bal-restrict 1)# upstream 4/2.0/1
Note that the logical channel is optional. If omitted, the channel defaults to 0.
CASA(load-bal-restrict 1)# upstream <slot/port/log_chan>
CASA(load-bal-restrict 1)# upstream 4/2/1
Casa Systems CMTS

Adding CMs to the restricted load balancing group
Example: Specify the restricted-group QAM slot, port, and channel
The qam parameter allows you to add downstream channels to the restricted-group in
the current MAC domain, as configured with the docsis-mac parameter. Only the
specified downstream channels in the restricted-group are load balanced.
Note: Make sure that you appropriately bind each upstream slot/port/channel
under the interface docsis-mac configuration.
CASA(load-bal-restrict 1)# downstream <slot>/<port>/<chan>

CASA(load-bal-restrict 1)# downstream 0/1/1
Add CMs to the restricted load balancing group for known CMs that participate in
CMTS upstream and downstream load balancing. CMs are specified by CM MAC
address and an optional network mask. Specify one CM MAC address per
restricted-cm identifier, then specify the referenced restricted-load-balance-group ID
to which this CM is be associated for load balancing.
Example: Specify the restricted-cm identifier
To enter the load balance restricted-cm context in the CLI, use the following
command in config mode:
CASA(config)# load-balance restricted-cm <num>
Specify the number parameter in the number range 1–4294967296. The number
uniquely identifies the configuration of this CM among other unique CMs.
CASA(config)# load-balance restricted-cm 1

CASA(load-bal-restrict-cm 1)#
The following commands are available under the restricted-cm configuration:
• mac
• restricted-load-balance-group
• service-type-id
Casa Systems CMTS

Example: Specify the restricted-cm MAC address
Specify the MAC address of the known CM that belongs to a restricted load balancing
group. Use the show cable modem command to display active CMs and their MAC
addresses. The default mask, if not specified, is ffff.ffff.ffff.
CASA(load-bal-restrict-cm 1)# mac addr <mac_addr> [mask <netmask>]

CASA(load-bal-restrict-cm 1)# mac addr 0008.ffff.fefe
Example: Create restricted-load-balance-group for the restricted-cm
The restricted-load-balance-group parameter allow you to specify the previously

configured restricted groups to be associated with the CMs that you added with the
load-balance restricted-cm command. CMs are load balanced and moved to the
upstream and downstream channels as specified in the referenced
load-balance restricted-group.
CASA(load-bal-restrict-cm 1)# restricted-load-balance-group 1
Example: Specify the restricted-cm service-type-id string
The service-type-id parameter specifies the unique string that selectively controls
load balancing to CMs belonging to particular service type in this restricted group,
such as CM device type, DOCSIS version, and service class.
Use this parameter the same way as specified in the restricted load-balance group
where only CMs that send a matching service-type-id string to the CMTS during
registration are load balanced and moved to another channel. Specifying the
service-type-id for known CMs (by MAC address) allows you to add the service type
to CMs that have already registered with the CMTS (with no service-type-id string)
and are to be made available for load balancing to other channels (using a referenced
load-balance restricted-group, covered in the next section).
Use the show cable modem command to display the active CMs and their MAC
addresses.
Specify a string with up to 16 alphanumeric characters. If blank spaces are necessary

in the string, surround the string with quotation marks.
CASA(load-bal-restrict-cm 1)# service-type-id <string>

CASA(load-bal-restrict-cm 1)# service-type-id “DOCSIS 3.0”
Casa Systems CMTS

Configuring policies and rules
Configuring policies and rules

A load balancing policy comprises a set of rules that control load balancing operations
at the CMTS. A policy contains one or more load balancing rules in two categories:
• Basic rules — Control the period during the day when the load balancing
operates. The CMTS supports multiple basic rules per policy.
• Execution rules — Control the thresholds for moving CMs to other channels.
The CMTS supports one execution rule per policy at any one time.
Example: Create a load balancing policy
To create a load balancing policy, enter the following command and specify a number
in the range 1–4294967295.
CASA(config)# load-balance policy <number>

CASA(config)# load-balance policy 1
CASA(load-bal-policy-1)#
Load balancing policy decision processing
This section describes the CMTS decision processing and conditions when load
balancing CMs to other channels using configured policies.
1. If a load balancing group policy is disabled, the CMTS does not perform load
balancing for that group.
2. If a load balancing group policy is enabled, the CMTS checks for channels having
both the highest and the lowest bandwidth utilization.
3. The CMTS then looks for a CM on the channel with the high utilization (most
busy) and then checks the policy for that CM.
4. If the CM configuration file uses TLV43.1, the policy for CM is specified by that
TLV. If the CM does not use TLV 43.1, it uses the load balancing group policy to
which this CM is assigned, if enabled.
5. The CMTS then checks the policy in the CM configuration file to see if the CM
can be load balanced. If the policy is enabled, the CMTS moves that CM to the
most idle channel (lowest utilization). If the policy disabled, the CMTS skips that
CM.
Casa Systems CMTS

Defining basic load balancing rules
Defining basic load balancing rules
You can create as many basic rules as needed to load balance CMs during high traffic
periods. You then apply these rules to the load-balance policy.
Example: Create a basic rule
To create a basic rule, enter the following command and specify a number in the range
1–4294967295.
CASA(config)# load-balance basic-rule <number>

CASA(config)# load-balance basic-rule 1
CASA(load-bal-basic-rule 1)# ?
enable enable
suspend-load-balance suspend-load-balancing
There are two configuration options associated with a basic load balance rule:
• enable
• suspend-load-balance
Example: Enable the basic rule
To enable the basic rule for use in a load-balance policy, specify the following
command:
CASA(load-bal-basic-rule 1)# enable
Example: Suspend load balancing during a specified period
To specify a period during the day to suspend load balancing over CMTS interfaces,
enter the following command and specify the start and end time (in HH:MM:SS
format) when load balancing does not take place. In the example, load balancing is
suspended from 4:00 a.m. to 5:00 a.m.
CASA(load-bal-basic-rule 1)# suspend-load-balance from <HH:MM:SS> to

<HH:MM:SS>
CASA(load-bal-basic-rule 1)# suspend-load-balance from 04:00:00 to
05:00:00
Casa Systems CMTS

Defining execution rules
Example: Apply a basic rule to load-balance policy
To apply a basic rule to a named policy, enter the following command and specify a
number in the range 1–4294967295. The policy can have multiple basic rules.
CASA(load-bal-policy-1)# rule basic <number>

CASA(load-bal-policy-1)# rule basic 1
You can create one execution rule to load balance CMs during high traffic periods.
You then apply this rule to the load-balance policy.
Example: Create an execution rule
To create an execution rule, enter the following command and specify a number in the
range 1–16.
CASA(config)# load-balance execution-rule <1:16>

CASA(config)# load-balance execution-rule 1
CASA(load-bal-exe-rule 1)# ?
enable enable
interval minimum time between the load-balance can be load
balanced
method method to determine when to do load balanced
suspicious-channel channel without register modems
threshold threshold
upstream-interval minimum time between the load-balance can be load
balanced for upstream
upstream-method method to determine when to do load balance for
upstream
upstream-threshold upstream-threshold
The following configuration options are available in the load-balance execution-rule

configuration:
• enable
• interval
• method {modem | utilization}
• permit multicast-session modem move
• suspicious-channel retry interval
Casa Systems CMTS

• threshold load
• upstream-interval
• upstream-method {modem | utilization}
• upstream-threshold load
Example: Enable the execution rule
To enable the execution rule for use in a load-balance policy, specify the following
command:
CASA(load-bal-exe-rule 1)# enable
Example: Specify the static load balance method and threshold
The commands covered in this section allow to define the techniques that the CMTS
uses when making load balance decisions, either by the number of CMs on a channel,
or by a configured percentage of current channel utilization.
The threshold load parameter specifies the actual number of CMs, or the utilization
percentage in the range 0–100. Load value specifies the maximum load difference that
can exist between interfaces in a group before the CMTS performs static load
balancing. Setting the load value to 0 disables static load balancing.
CASA(load-bal-exe-rule 1)# method {modem | utilization}

CASA(load-bal-exe-rule 1)# threshold load <0:100>
To specify CM load balancing with a threshold of 50 CMs, enter the following

commands:
CASA(load-bal-exe-rule 1)# method modem

CASA(load-bal-exe-rule 1)# threshold load 50
To specify channel utilization load balancing with a threshold of 50 percent usage,

enter the following commands:
CASA(load-bal-exe-rule 1)# method utilization

CASA(load-bal-exe-rule 1)# threshold load 50
Casa Systems CMTS

Example: Specify the dynamic load balance method and threshold
The method command applies to both dynamic and static load balancing, as well as to
both upstream channels and downstream channels if not otherwise specified. Dynamic
load balancing takes place when the load difference between interfaces exceeds a
minimum value.
To specify the dynamic load balancing method:
CASA(load-bal-exe-rule 1)# method {modem | utilization} [dynamic]

CASA(load-bal-exe-rule 1)# method modem dynamic
CASA(load-bal-exe-rule 1)# method utilization dynamic
To specify the threshold for dynamic load balancing, enter the threshold load
command to specify the actual number of CMs, or the utilization percentage in the
range 0–100.
CASA(load-bal-exe-rule 1)# threshold load <0:100> {dynamic minimum

<2:100> | enforce <0:100> | minimum <2:100>}
• minimum and dynamic minimum <2:200> — The minimum parameter
specifies the minimum load over the channel before the CMTS begins static load
balancing. Similarly, the dynamic minimum specifies the minimum load over the
channel before the CMTS begins dynamic load balancing.
If you do not specify the dynamic-minimum, then the minimum value applies to
both static and dynamic load balancing. Otherwise, minimum parameter setting
applies to static load balancing only, while the dynamic-minimum value applies
to dynamic load balancing only. For example.
CASA(load-bal-exe-rule 1)# threshold load 10 minimum 35 dynamic
minimum 50
• enforce <0:100> — The enforce parameter enables dynamic load balancing. It

also specifies the maximum difference in utilization percentage that can exist
between interfaces in a group before the CMTS performs dynamic load balancing.
The enforce setting must be larger than the load value if the load is set to 0.
In the following example, dynamic load balancing is enabled with the CMTS
applying a CM or utilization threshold of 30 before checking other load balancing
interfaces for availability.
CASA(load-bal-exe-rule 1)# threshold load 10 enforce 30 dynamic
minimum 50
Casa Systems CMTS

Setting the enforce value to 0 disables dynamic load balancing.
Example: Specify the load balancing interval
The interval parameter specifies the minimum elapsed time (in seconds) before CMs
can be moved to the load balancing interfaces. Only one CM can be moved after each
elapsed time interval.
To specify the dynamic load balance interval, specify a number in the range 10–3600
seconds.
CASA(load-bal-exe-rule 1)# interval <10:3600>
The following example sets the dynamic load balancing interval to one CM every 60
seconds.
CASA(load-bal-exe-rule 1)# interval 60
Example: Specify the static upstream method and threshold
To selectively control or customize load balancing on the upstream channels, use the
following execution rule parameters:
• upstream-method
• upstream-threshold load
• upstream-interval
The upstream-method parameter controls load balancing based on the number of

CMs on a channel, or by a configured percentage of current channel utilization.
The upstream-threshold load parameter specifies the actual number of CMs, or the
utilization percentage in the range 0–100. Load value specifies the maximum load
difference that can exist between interfaces in a group before the CMTS performs
static load balancing. Setting the load value to 0 disables static load balancing.
CASA(load-bal-exe-rule 1)# upstream-method {modem | utilization}

CASA(load-bal-exe-rule 1)# upstream-threshold load <0:100>
Casa Systems CMTS

To specify upstream CM load balancing with a threshold of 50 CMs, enter the

following commands:
CASA(load-bal-exe-rule 1)# upstream method modem

CASA(load-bal-exe-rule 1)# upstream threshold load 50
To specify channel utilization load balancing with a threshold of 50 percent usage,

enter the following commands:
CASA(load-bal-exe-rule 1)# upstream-method utilization

CASA(load-bal-exe-rule 1)# upstream-threshold load 50
Note: If the upstream-method command is used, the original method

[modem | utilization] command only applies to downstream channel load
balancing.
Example: Specify the dynamic upstream method and threshold
When you set the upstream-method parameter, the original

method [modem | utilization] command does not apply to upstream channel
dynamic load balancing. Dynamic load balancing takes place when the load difference
between the upstream interfaces exceeds a minimum value.
To specify the upstream dynamic load balancing method:
CASA(load-bal-exe-rule 1)# upstream-method {modem | utilization}

[dynamic}
CASA(load-bal-exe-rule 1)# upstream-method modem dynamic
CASA(load-bal-exe-rule 1)# upstream-method utilization dynamic
To specify the threshold for dynamic load balancing, enter the

upstream-threshold load command to specify the actual number of CMs, or the
utilization percentage in the range 0–100.
If the upstream-threshold is not configured, the threshold configuration applies to

both downstream and upstream channels. Otherwise, the threshold configuration
applies to the downstream channels only, while the upstream-threshold applies to
the upstream channels.
CASA(load-bal-exe-rule 1)# upstream-threshold load <0:100> {dynamic

minimum <2:100> | enforce <0:100> | minimum <2:100>}
Casa Systems CMTS

• minimum and dynamic minimum <0:200> — The minimum parameter

specifies the minimum load over the channel before the CMTS begins static load
balancing. Similarly, the dynamic minimum specifies the minimum load over the
channel before the CMTS begins dynamic load balancing.
If you do not specify the dynamic-minimum, then the minimum value applies to
both static and dynamic load balancing. Otherwise, minimum parameter setting
applies to static load balancing only, while the dynamic-minimum value applies
to dynamic load balancing only. For example.
CASA(load-bal-exe-rule 1)# upstream-threshold load 50 minimum 50
dynamic minimum 50
• enforce <0:100> — The enforce parameter enables dynamic load balancing. It

also specifies the maximum difference in percentage that can exist between
interfaces in a group before the CMTS performs dynamic load balancing. The
enforce setting must be larger than the load value if the load is set to 0.
In the following example, dynamic load balancing is enabled with the CMTS
applying a CM or utilization threshold of 50 before checking other load balancing
interfaces for availability.
CASA(load-bal-exe-rule 1)# upstream-threshold load 50 enforce 50

dynamic minimum 50
Setting the enforce value to 0 disables dynamic load balancing.
Example: Specify the upstream load balancing interval
The upstream-interval command allows a custom interval value for upstream load
balancing by specifying the minimum elapsed time (in seconds) before CMs can be
moved to the load balancing interfaces. Only one CM can be moved during each time
interval. When the upstream-interval is configured, the interval setting applies to
downstream load balancing only.
To specify the dynamic load balance upstream-interval, specify a number in the

range 10–3600 seconds.
CASA(load-bal-exe-rule 1)# upstream-interval <10:3600>
Casa Systems CMTS

Load balancing over suspicious channels
The following example sets the dynamic load balancing upstream-interval to one CM
every 60 seconds.
CASA(load-bal-exe-rule 1)# upstream-interval 60
Example: Apply an execution rule to the load-balance policy
To apply an execution rule to a named policy, enter the following command and
specify a number in range 1–4294967295.
CASA(load-bal-policy-1)# rule execution <number>

CASA(load-bal-policy-1)# rule execution 1
The load balance policy can have ONLY ONE execution rule.
Load balancing over suspicious channels
Under the execution-rule configuration, you can specify whether to load balance
CMTS traffic over channels that currently have no registered CMs. These channels
over which there are no registered CMs are known as suspicious channels. A
suspicious channel might result from a line card redundancy failover, a line card reset,
a redundancy revert, or other reason that creates a condition where a load balancing
interface is available and currently unused. The suspicious-channel command allows
to specify whether to attempt load balancing on empty channels at configured time
intervals.
Example: Specify suspicious channel retry interval
To specify if the CMTS should retry load balancing to channels where there are no
registered CMs, enter the retry interval in the range 0–86400 seconds. The default
setting is 3600 seconds. Enter 0 to disable load balancing to suspicious channels.
CASA(load-bal-exe-rule 1)# suspicious-channel retry interval <8:86400>

CASA(load-bal-exe-rule 1)# suspicious-channel retry interval 1800
Using exclusion lists

An exclusion list disables one or more CMs from load balancing across CMTS
interfaces. Use the exclusion list in situations where it is not feasible to load balance
Casa Systems CMTS

Load balancing configuration examples
particular customer CMs. For example, there can be cases where an older DOCSIS 1.0
or 2.0 CM from a specific vendor might not be a good candidate for load balancing.
You might also want to exclude CMs that process particular types of traffic where
moving those CMs to other channels might introduce unpredictable results.
CMs in the exclusion list are specified by MAC address, as displayed with the
show cable modem command.
Example: Create an exclusion list
To create an exclusion list, enter the following command:
CASA(config)# load-balance exclusion list

CASA(load-bal-exclusion-list)#
Example: Add CMs to the exclusion list
A CM with a MAC address matching the MAC address/mask criteria specified in the
exclusion list are excluded from load balancing. By default, these CMs are disabled
from dynamic load balancing using he following rules:
• If the static parameter is specified, the CMs are disabled from static load
balancing only.
• If the dynamic parameter is specified, the CMs are disabled from dynamic load
balancing only.
• If the both parameter is specified, the listed CMs are disabled from both static and
dynamic load balancing.
CASA(load-bal-exclusion-list)# mac addr xxxx.xxxx.xxxx mask
xxxx.xxxx.xxxx [both | dynamic | static]
CASA(load-bal-exclusion-list)# mac addr 0001.56ff.fefe mask
0000.0000.0000 both
Load balancing configuration examples

After the CMTS load balances CMs upon registration and initial channel selection,
you need to create one or more policies with execution rules to define how the CMTS
balances traffic dynamically based on utilization. In some cases, you need to create
Casa Systems CMTS

Configure static general load balancing
one or more additional configurations to address special conditions, such as declaring

CMs to be excluded from load balancing at the CMTS.
Casa recommends that you use the show load balance static and
show load balance dynamic commands at times when CMTS traffic loads tend to be
higher. The displayed information from the show load balance command allows you
to further tune the load balancing configuration for better channel utilization so that
moving CMs to other channels in the service group occurs less frequently.
Note: The show load balance static command displays log information for
D1.X and D2.0 CMs only. Log information for D3.0 CMs are not included in the
output of this command.
Configure static general load balancing

1. Create service group and docsis-mac interfaces to which load balancing are
applied.
In the following CLI session, the CMTS load-balances traffic on the QAM in
system slot 0, port 0, and across channels 0 – 3. On the upstream, the CMTS
load-balances traffic on system slot 4, interfaces 0 – 4, and on channel 1.
CASA(config)# service group FN_A

CASA(conf-if-mac 1)# upstream 1 interface upstream 4/0.1
Casa Systems CMTS

Create an execution rule to enable dynamic load balancing
2. Enable load balancing at the CMTS.

CASA(config)# load-balance enable
3. Enable the load-balance general-group default.

CASA(config)# load-balance general-group default-settings
CASA(load-bal-general-default)# enable
4. Specify the initial technique that the CMTS uses to load balance and move CMs
without performing any type of ranging.
CASA(load-bal-general-default)# initial-tech direct
Create an execution rule to enable dynamic load balancing

1. Create service group and docsis-mac interfaces, then enable load balancing at the
CMTS, as covered in Solution 1.
2. Create and enable an execution rule.
CASA(config)# load-balance execution-rule 1
CASA(load-bal-exe-rule 1)# enable
3. Specify the dynamic load balancing method.

CASA(load-bal-exe-rule 1)# method utilization dynamic
4. Enable dynamic load balancing.

Use the threshold load command (for static) and the enforce parameter to enable
dynamic load balancing based on channel utilization.
An enforce value of 30 indicates the 30% maximum percentage of utilization
difference between interfaces listed in the service group before the CMTS
performs dynamic load balancing. The dynamic minimum specifies the
minimum load over the channel before the CMTS begins dynamic load balancing.
CASA(load-bal-exe-rule 1)# threshold load 10 enforce 30 dynamic
minimum 80
5. Specify the dynamic load balance time interval.

The interval is the minimum elapsed time (in seconds) before CMs can be moved
to the load balancing interfaces. Only one CM can be moved after each elapsed
time interval.
CASA(load-bal-exe-rule 1)# interval 60
Casa Systems CMTS

Display and assess load balance statistics
6. Apply the execution-rule to a named policy.

CASA(config)# load-balance policy 1
CASA(load-bal-policy-1)# rule execution 1
Display and assess load balance statistics

1. Display load balance statistics.
Run the show load-balance dynamic command to display current statistics (if
available), or over an optionally specified period using a beginning and end time.
For example:
CASA# show load-balance dynamic
Mac address: 0015.f2fe.c643
Mac_id: 0
upstream-channel 3
downstream-channel 1
initial_tech
cmd dcc
status WaitToSendMsg
type RGLB
time 2008-04-06 23:28:41
--------------------------------------
total: 1; success:1; other:0
(Note that the command output is shown in “list” format and not in the format
displayed by the CLI on a computer screen.)
The output shows the MAC address of the CM and the new upstream and
downstream channels to which the CM was moved. The type field shows one of
the following states:
• BAL — Balancing done by the system.
• MLT — DCC by limit replication multicast.
• CLI — Load balancing done manually from the CLI.
• MIB — Load balancing done manually from SNMP.
• CSM — DCC done by CSM per CM.
• DSA — DCC done by voice.
• RSLB — DCC moved a CM into a restricted load-balance group.
• RGLB — General load balancing done until registration.
Casa Systems CMTS

Create special load balancing configurations
• SG — Channel is not in the channel set of the configured service group.

2. Assess the load balance statistics over higher traffic periods.
If you find that the CMTS is performing load balancing on a frequent basis, with
the show load-balance dynamic command showing increased statistics, you might
need to fine tune the execution-rule with a new threshold, enforce and
dynamic minimum settings for improved utilization of channels. You can also
add docsis-mac interfaces to the service-group to increase the number of
interfaces for wider load balancing distribution.
Create special load balancing configurations
There might be special cases where you need to restrict load balancing to upstream
and downstream channels over certain docsis-mac interfaces (using the
restricted-group configuration) and or to even exclude some CMs from load
balancing operations all together (using an exclusion list).
For older DOCSIS 1.0 CMs where load balancing is not supported, run the CMTS
show cable modem command to display the D1.0 CMs, and them add them to the
load balance exclusion list.
1. Execute the show cable modem verbose command. Note the MAC Version field.
CASA# show cable modem verbose
MAC Address :0013.f79e.0d6a
IP Address :10.213.1.246
CM-ID :5
Prim Sid :10
MAC Domain :3
Upstream :4/0.0/0
Downstream :0/1/0
…
MAC Version :DOC1.0 <-------------------
2. Create the exclusion list.

CASA(config)# load-balance exclusion list
3. Add the CM MAC addresses to the exclusion list. Specify both to prevent the
CMs from attempting static and dynamic load balancing.
CASA(load-bal-exclusion-list)# mac addr 0013.f79e.0d6a mask
0000.0000.0000 both
Casa Systems CMTS

8-1
Chapter 8. CMTS monitoring
About this chapter

This chapter provides information on the more common monitoring practices that
helps ensure that the CMTS is operating as expected. Preventive maintenance requires
scheduled monitoring on a daily, weekly, or monthly basis where information about
the system and network activity allows operators to detect and correct potential and
foreseeable problems before they occur.
Users who are managing and monitoring the CMTS from an SNMP management
station should refer to the Casa Systems – SNMP MIBs and Traps Reference.
Topic Page
Displaying system information 8-2

Enabling system monitors 8-3
Monitoring fan, power, and temperature status 8-5
Monitoring CMTS network interfaces 8-8
Enabling the line card monitor 8-11
Monitoring DOCSIS MAC interfaces 8-11
Displaying the system log 8-13
Assessing redundancy failovers 8-15
Monitoring cable modems 8-16
Checking for flapping modems 8-17
Maintaining CMTS hardware 8-19
Checking electrical and RF connections 8-22
Casa Systems CMTS

Displaying system information
Displaying system information

The show system command provides important details about the current operating
status of the CMTS and the installed modules. Administrators and system operators
should use show system on a regular basis to view system uptime, active and standby
status of the SMM, and to ensure that all upstream and downstream modules are
running. The uptime is shown for each of the modules.
Example: show system

The following CLI session shows a sample show system output.
CASA(config)# show system

Product: C10G, System Uptime:0 d, 3 h, 39 m, 19 s
System Time: Wed Aug 14 11:02:58 UTC 2013
128MHz, 5 PPM Crystal Clock
Module 6, Master SMM_2x10G, Status ACTIVE

serial_no = SB15BCAS0040
CFE version 12.4.10
Uptime: 0 d, 3 h, 39 m, 19 s
Module 7, Slave SMM_2x10G, Status STANDBY

serial_no = SB14BA7S0295
CFE version 12.4.10
Uptime: 0 d, 3 h, 39 m, 25 s
Module 1 QAM Running (8 ports, 8 channels/port, 2 banks/port,

docsis enabled)
serial_no = QB18BB5S0188
CFE version 12.4.8
Uptime: 1 d, 14 h, 38 m, 37 s
Module 2 QAM_8x96 Running (8 ports, 16 channels/port, 2 banks/

port, docsis enabled)
serial_no = QB10CCBS0002
CFE version 12.9.12
Uptime: 1 d, 14 h, 38 m, 37 s
Module 5 QAM_8x96 Standby (8 ports, 16 channels/port, 2 banks/

port, docsis enabled)
serial_no = QB10CCCS0018
CFE version 12.9.12
Casa Systems CMTS

CMTS monitoring 8-3
Enabling system monitors
Uptime: 1 d, 14 h, 38 m, 37 s
Module 8 UPS_16x8 Standby (16 ports, 8 phy chans/port, 2 log

chans/phy chan)
serial_no = UB10CD1S0002
CFE version 12.9.12
Uptime: 1 d, 14 h, 38 m, 37 s
Module 11 UPS Running (16 ports, 4 phy chans/port, 2 log chans/

phy chan)
serial_no = UB14BAAS0677
CFE version 12.4.8
Uptime: 1 d, 14 h, 38 m, 37 s

The system monitor command enables the CMTS to capture and log all messages
associated with certain system features, objects, or particular conditions. For example,
as you continue to support more CM traffic with added customers, you might want to
monitor the CMTS over longer periods to see additional the demands on the system
CPU and memory.
Note: Enabling all system monitor options can result in excessively large
system log files. Casa Systems suggests that you disable any monitors that
are showing normal activity where only periodic monitoring is sufficient.
Example: Display system monitor configuration options

The following CLI session shows the system monitor command options:
CASA(config)# system monitor ?

cpu set cpu monitor
crash set application crash monitor
fan set fan monitor
memory set memory monitor
nvram set nvram monitor
power set power monitor
temperature set temperature monitor
watchdog system monitor watchdog enable
In most cases, you only need to enable one of the above options, while other options
allow you to set operating thresholds that would trigger messages to be logged. This is
Casa Systems CMTS

one way to keep insignificant messages out of the system log, while capturing only
those messages that are more critical based on set thresholds.
Example: Monitor memory on SMM and selected module slot

The following CLI session enables the CMTS to log memory-related messages
associated with the upstream or downstream module in system slot 1 and the SMM
based on the set memory consumption threshold of 50 MB. The valid range is 1–
1947 MB.
CASA(config)# system monitor memory ?

<number> slot number
enable set enable
log set log flag
smm smm card
CASA(config)# system monitor memory 1 threshold 50
CASA(config)# system monitor memory enable
CASA(config)# system monitor memory log enable
CASA(config)# system monitor memory smm threshold 50
Example: Monitor CPU on SMM and selected module slot

The following CLI session enables the CMTS to log CPU-related messages associated
with the upstream or downstream module in system slot 1 and the SMM based on the
set CPU idle threshold of 10 percent, where 90% CPU utilization would force the
CMTS to log a CPU message. The valid range is 1–100 percent.
CASA(config)# system monitor cpu ?

<number> slot number
enable set enable
log set log flag
smm smm card
CASA(config)# system monitor cpu 1 threshold 10
CASA(config)# system monitor cpu enable
CASA(config)# system monitor cpu log enable
CASA(config)# system monitor cpu smm threshold 10
Example: Display CMTS memory statistics

The following CLI session shows total and free memory statistics at the CMTS:
CASA# show meminfo

SMM:
MemTotal: 2003080 kB
MemFree: 1175920 kB
Casa Systems CMTS

CMTS monitoring 8-5
Monitoring fan, power, and temperature status
Example: Display CMTS CPU statistics

CASA# show cpuinfo
SMM:
cpu model XLS616 Rev B1 V0.3
BogoMIPS 133.72
microsecond timers yes
tlb_entries 64
BogoMIPS 133.81
tlb_entries 64
BogoMIPS 133.77
tlb_entries 64
BogoMIPS 133.76
tlb_entries 64
14:54:23 up 16 min, 3 users, load average: 2.61, 2.43, 1.63

87 processes: 84 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.0% user, 5.0% system, 1.5% nice, 93.5% idle
Mem: 2003080K total, 826540K used, 1176540K free, 456688K
buffers

System cooling plays a vital part in keeping the CMTS running reliably. On systems
equipped with the fan monitor, the CMTS fan subsystem reports on the operational
status of each fan tray and operating fan RPMs, and temperature sensors that detect
and report any over-temperature thresholds that might indicate a fan failure or air
restriction near the system.
For C10G and C100G platforms, use the CLI the show envm command to selectively
display fan, power, and temperature status. If a specific argument is not specified, the
CMTS displays the current status for all arguments.
The show envm command uses the following syntax:
CASA# show envm [fan | power | temperature]

CASA# show envm fan [left [0:1] | middle [0:1] | right [0:1]]
CASA# show envm temperature [module <num> | QAM | SMM | UPS]
CASA# show envm power
Casa Systems CMTS

Example: show envm command

CASA(config)# show envm
PEM A (-48V) PEM B (-48V)
Input 1 : Present Input 1 : Present
Input 1 FUSE : Good Input 1 FUSE : Good
Temperature : 29 C/84 F Temperature : 29 C/84 F
FAN_Tray Temperature Front/Back Present

Fan RPM
LEFT 28C/ 82F 3500/3500 YES
MIDDLE 27C/ 80F 3300/3500 YES
RIGHT 25C/ 77F 3500/3300 YES
Module Temperature Status Type

1 52C/125F Normal QAM
2 58C/136F Normal QAM_8x96
5 58C/136F Normal QAM_8x96
6 38C/100F Normal SMM
7 38C/100F Normal SMM
11 45C/113F Normal UPS
Note that the C10G uses three fan modules: LEFT, CENTER and RIGHT. Each
module has two fans that are designated as either front or back, as follows:
• LEFT — 0 = Front, 1 = Back

• MIDDLE — 0 = Front, 1= Back
• RIGHT — 0 = Front, 1= Back
On C2200 and C3200 systems, the show temperature qam command displays
temperature information in centigrade for QAM modules only. The show envm
command, although present in Release 6.1 versions of software, is not supported for
the C2200 and C3200.
Example: show temperature qam

CMTS_C3200> show temperature qam
temperature of qam 0 : 37 deg C
temperature of qam 1 : 40 deg C
CMTS_3200>
Casa Systems CMTS

CMTS monitoring 8-7
Fan subsystem messages
The system temperature thresholds are summarized in Table 8-1. Any temperatures
below these thresholds are marked as Normal. The system shuts down or reboots
immediately with temperatures exceeding the shutdown/reboot board threshold.
Table 8-1. System temperature thresholds
Alert board threshold Shutdown/reboot board threshold

Board type
(°C / °F) (°C / °F)
UPS 16x4 65 / 149 90 / 194

UPS 16x8 65 / 149 90 / 194
CPU core: 100 / 212 CPU core: 110 / 230
QAM 8x8 80 / 176 90 / 194
QAM 8x96 75 / 167 94 / 201
CPU core: 100 / 212 CPU core: 110 / 230
SMM 55 / 131 Reboot: 75 / 167
Fan subsystem messages

Personnel who are responsible for monitoring CMTS systems should watch for
fan-related messages that indicate a potentially serious problem if a system should
overheat.
The following messages indicate that the fan module is reporting below normal or has
no operating RPMs. The messages are usually followed by others reporting high
system temperatures (using an exceeded temperature threshold) and possible SNMP
trap messages. An immediate system inspection is necessary.
Fan tray <num> back fan low RPM detected (2200 RPM). Check fan intake
and exhaust for blockage. Replace fan tray if defective.
Fan tray <num> front fan low RPM detected (0 RPM). Check fan intake and
exhaust for blockage. Replace fan tray if defective.
Fan tray <num> is pulled out or broken.
The last message indicates that the specified fan tray is not being detected as present
in the chassis (installed but nonoperational) or is physically missing from the chassis.
Inspect the chassis for a possible missing fan tray. If the reported fan is present and
nonoperational, check the fan tray to ensure that is properly seated in its module slot.
Contact Casa Technical Support for a replacement if necessary. Continue monitory
Casa Systems CMTS

Related CLI commands
system temperatures for any over-temperature conditions that could possibly lead to
other failures.
Related CLI commands

• show envm fan {left | middle | right}
• show system
• show envm temperature
• show temperature qam (on C2200 and C3200 systems)
• show system monitor threshold fan
• system monitor fan enable
Monitoring CMTS network interfaces

The monitor gige command enables the CMTS to periodically check network activity
on GigE interfaces. During the monitoring process, interfaces that have been idle for
an excessive period of time are changed to the shutdown state.
Example
The following CLI session enables monitoring of configured CMTS GigE interfaces:
CASA(config)# monitor gige
Use the show interface gige and show interface xgige commands to display traffic
statistics and throughput over the CMTS gigabit Ethernet interfaces. Confirm the
interface and link status and look for error statistics and discarded packets.
Example: Display GigE interface statistics on SMM slot 6, port 5

CASA(config)# show interface gige 6/5 stat
Interface gige 6/5 information:
IfIndex: 1000077
interface status UP
link status UP
auto-negotiation Enabled
interface speed 1000000000
duplex status Full
mac address 0017.1005.39c7
SFP vendor Molex Inc.
Casa Systems CMTS

CMTS monitoring 8-9
SFP Serial Number 12294029

SFP Type 1000BASE-T
Statistics:
IfInOctets 877346320
IfInUcastPkts 657260
IfInNUcastPkts 125
IfInDiscards 23364
IfInErrors 0
IfInUnknownProtos 0
IfOutOctets 24145
IfOutUcastPkts 189
IfOutNUcastPkts 84
IfOutErrors 0
IfOutDiscards 0
IpForwDatagrams 98
IpInReceives 633864
IpInDiscards 0
v6IfInReceives 0
v6IfInDiscards 0
v6IfInErrors 0
v6IfOutForwDatagrams 0
v6IfOutDiscards 0
Last clearing of interface stat: never
Example: Display XGigE interface statistic on SMM slot 6, port 1

The following CLI session shows an XGigE interface and link status in the DOWN
state.
CASA(config)# show interface xgige 6/1 stat

Interface xgige 6/1 information:
IfIndex: 1000081
interface status Administratively DOWN
link status DOWN
auto-negotiation Disabled
duplex status Full
mac address 0017.1005.39cb
Statistics:
IfInOctets 0
IfInUcastPkts 0
IfInNUcastPkts 0
IfInDiscards 0
IfInErrors 0
IfInUnknownProtos 0
IfOutOctets 0
IfOutUcastPkts 0
IfOutNUcastPkts 0
IfOutErrors 0
IfOutDiscards 0
Casa Systems CMTS

IpForwDatagrams 0
IpInReceives 0
IpInDiscards 0
v6IfInReceives 0
v6IfInDiscards 0
:
interface status Administratively DOWN
link status DOWN
auto-negotiation Disabled
duplex status Full
mac address 0017.1005.39cb
Statistics:
IfInOctets 0
IfInUcastPkts 0
IfInNUcastPkts 0
IfInDiscards 0
IfInErrors 0
IfInUnknownProtos 0
IfOutOctets 0
IfOutUcastPkts 0
IfOutNUcastPkts 0
IfOutErrors 0
IfOutDiscards 0
IpForwDatagrams 0
IpInReceives 0
IpInDiscards 0
v6IfInReceives 0
v6IfInDiscards 0
v6IfInErrors 0
v6IfOutForwDatagrams 0
v6IfOutDiscards 0
Example: Display GigE interface throughput stats on C3200, port 11

The following CLI session filters GigE throughput statistics.
CASA> show interface gige 11 throughput

Interface GIGE 11 throughput
IfInOctets 260 bytes/second
IfInUcastPkts 1 packets/second
IfInNUcastPkts 2 packets/second
IfInTotalPkts 3 packets/second
IfOutOctets 240 bytes/second
IfOutUcastPkts 0 packets/second
IfOutNUcastPkts 3 packets/second
IfOutTotalPkts 3 packets/second
Casa Systems CMTS

CMTS monitoring 8-11
Enabling the line card monitor
Enabling the line card monitor

By default, line cards periodically send “keep-alive” ping packets to the SMM. If a
line card is determined to be hung, or down, the line card is automatically reset. The
default setting is enabled and it is recommended that you keep this feature enabled.
With redundancy-protected C10G and C100G systems with standby line cards, any
line card that goes down fails over to the redundant standby card in slot 5 or 8. Once a
failed card resets and comes back up, the card is placed in standby state until
interactively reverted using the ha revert command or by default during
system reboot. Release 6.5.2 allows both redundant cards to be active when backing
up a primary card on the same side of the redundant card.
Example: Monitor keepalive messages

The following CLI session enables monitoring of keepalive messages between line
cards and the SMM module:
CASA(config)# monitor keepalive
Monitoring DOCSIS MAC interfaces

DOCSIS-MAC upstream and downstream interfaces should be checked a regular
basis to ensure proper channel utilization. DOCSIS-MAC interfaces should be
checked for the proper administrative and operating status (up), and for any
DOCSIS-related transmission problems reported as statistical errors or failures that
can lead to CMs dropping off.
Example: Display upstream channel utilization

The following CLI session displays channel utilization for the upstream module in
system slot 11.
CASA# show docsis upstream channel utilization

Upstream Total-BW Utilization Online Secondary Channel
Slot/Port.Channel (Mb/Sec) Percentage Modems Modems Description
-----------------------------------------------------------------------------
11/0.0 (20000000 Hz) 10.2 0 0 0
11/2.0 (20000000 Hz) 10.2 0 0 0
11/11.0 (20000000 Hz) 10.2 0 0 0
11/12.0 (20000000 Hz) 10.2 0 0 0
11/15.0 (20000000 Hz) 30.7 0 0 0
Casa Systems CMTS

Monitoring DOCSIS MAC interfaces
Example: Display downstream channel utilization

The following CLI session displays channel utilization for the downstream module in
system slot 1.
CASA(config)#show docsis downstream channel utilization

Downstream Total-BW Utilization Online Secondary Channel
Slot/Port/Channel (Mb/Sec) Percentage Modems Modems Description
------------------------------------------------------------------------------
1/0/0 (549000000 Hz) 42.9 0 0 0
1/0/1 (555000000 Hz) 42.9 0 0 0
1/0/2 (561000000 Hz) 42.9 0 0 0
1/0/3 (567000000 Hz) 42.9 0 0 0
1/0/4 (597000000 Hz) 42.9 0 0 0
…
Example: Display DOCSIS-MAC statistics

The following CLI session displays statistics for all DOCSIS MAC interfaces
configured at the CMTS. In this example, DOCSIS MAC interface 1 reports the
administration and operation status in the UP state.
CASA(config)# show interface docsis-mac stat

Interface docsis-mac 1 statistics
Ifindex: 2000002
Administrated status: UP
Operation status: UP
Mac address: 0050.c231.9a0e
DSA Request : 5/ups; 0/ds
DSA Response : 8/ups; 5/ds
DSA Acknowledgements : 7/ups; 0/ds
DSA Success : 5/ups; 0/ds
DSA Fail : 0/ups; 0/ds
DSC Request : 0/ups; 0/ds
DSC Response : 3/ups; 0/ds
DSC Acknowledgements : 109/ups; 0/ds
DSC Success : 0/ups; 0/ds
DSC Fail : 0/ups; 0/ds
DSD Request : 5/ups; 13536/ds
DSD Response : 0/ups; 5/ds
DSD Success : 3/ups; 0/ds
DSD Fail : 0/ups; 2256/ds
DCC Request : 0/ups; 244/ds
DCC Response : 220/ups; 0/ds
DCC Acknowledgements : 0/ups; 6/ds
DCC Success : 0/ups; 5/ds
DCC Fail : 0/ups; 209/ds
DCC RSP Depart : 204/ups; 0/ds
DCC RSP Arrive : 6/ups; 0/ds
DBC Request : 0/ups; 0/ds
DBC Response : 48/ups; 0/ds
Casa Systems CMTS

Displaying the system log
DBC Acknowledgements : 0/ups; 0/ds

DBC Success : 0/ups; 0/ds
DBC Fail : 0/ups; 0/ds
DBC Partial Service : 0/ups; 0/ds
Example: Displaying upstream interface statistics

The following CLI session displays statistics for all upstream interfaces configured at
the CMTS. In this example, statistics are reported for upstream interface 11, port 0,
physical channel 0 (logical channels 0 and 1).
CASA(config)# show interface upstream stat

Interface upstream 11/0.0 statistics
Admin status: UP
Logical-channel 0
Received 0 broadcasts, 0 multicasts, 0 unicasts
0 discards, 0 errors, 0 unknown protocol
0 Unerroreds, 0 Correcteds, 0 Uncorrectables
Total Modems On This Upstream Channel: 0 ,0 active cm,0 secondary
cm
Req Mslots 21377772, Used Req Mslots 0
Init Mtn Mslots 240720, Used Init Mtn Mslots 0
Total Mslots 21618556, Ucast Granted Mslots 0
Avg upstream channel utilization: 0
Channel utilization interval: 30
Admin status: UP
Logical-channel 1
Received 0 broadcasts, 0 multicasts, 0 unicasts
0 discards, 0 errors, 0 unknown protocol
0 Unerroreds, 0 Correcteds, 0 Uncorrectables
Total Modems On This Upstream Channel: 0 ,0 active cm,0 secondary
cm
Req Mslots 0, Used Req Mslots 0
Init Mtn Mslots 0, Used Init Mtn Mslots 0
Total Mslots 0, Ucast Granted Mslots 0
Avg upstream channel utilization: 0
Channel utilization interval: 30
Admin status: DOWN

The show log command displays the messages that have been captured in the CMTS
log file. Like other shows commands supported in the CMTS CLI, you can specify
output modifiers to quickly filter the show log output to display only certain
Casa Systems CMTS

information. Add an output modifier by typing the vertical bar (|) character followed
by a specified operator and filter.
The following operators are available:
• include — Display lines containing the specified filter.

• exclude — Omit lines containing the specified filter.
• count-only — Display a count of the number of lines containing the specified
filter while suppressing output.
• count — Display a count of the number of lines containing the specified filter at
the very end of the output.
• begin — Display all lines that begin with the specified filter.
Example: show log

The following CLI session displays the current log file starting with the most recent
event messages.
CASA(config)# show log

[Tue Aug 13 15:39:09 2013]-AL-SYS-1: smm6: Module 8 (QAM) in boot
state, status 2
[Tue Aug 13 15:38:47 2013]-AL-SYS-1: smm6: Card detected in slot 8
[Tue Aug 13 15:38:25 2013]-AL-SYS-1: smm6: QAM monitor trap
notification(module 2 is undetectable)
[Tue Aug 13 15:38:25 2013]-AL-SYS-1: smm6: No available redundant card
for slot 2
[Tue Aug 13 15:38:25 2013]-AL-SYS-1: smm6: Card removed from slot 2
[Tue Aug 13 15:27:02 2013]-AL-CLI-1: smm6: User root logged in
[Tue Aug 13 15:24:39 2013]-AL-SYS-1: smm6: Module 1 changed to active
status
Example: show log command with output modifier

The following CLI session uses the include modifier with the show log command. In
this example, any message in the log file that includes the word “fail” displays in the
output.
CASA(config)# show log | include fail

[Mon Aug 5 19:02:26 2013]-ER-SYS-1: smm6: System rebooting module
8,fail reason SWITCH BACK
[Mon Aug 5 18:31:16 2013]-ER-SYS-1: smm6: System rebooting module
10,fail reason MANUAL
Casa Systems CMTS

Assessing redundancy failovers
Assessing redundancy failovers

High availability systems like the Casa C10G and C100G systems offer redundancy
protection to ensure consistent and uninterrupted CMTS operation. In the event of a
downstream or upstream line card failure, a redundant standby card in either system
slot 5 or slot 8 assumes the active role. The original line card resets and assumes
standby status until the CMTS is rebooted or when the ha redundancy revert
command forces a manual switchover back to the original redundancy configuration
after 30 minutes (by default).
Note: In most cases, slots 5 and 8 have one upstream and one downstream
line card available. After a switchover that places the redundant standby card
in the active state, redundancy is no longer available for any additional line
cards in the system, either upstream or downstream. Only one redundancy
failover is permitted at any one time.
To properly assess a module failover, use the show ha log and show log commands to
verify that the system continues to run normally using the redundant module. Use the
show ha log command to display high-availability event history, including the time of
the failover, type of failure, and the affected system slots. Executing the clear ha log
erases the current high-availability logged entries.
If the original module is in the standby state, it is recommended that you schedule a
maintenance window to revert back to original configuration so that continued
redundancy operations are available. However, the ha module revert command can
be used once the original line card is in the standby state and to re-enable system-wide
line card redundancy immediately.
For complete information on redundancy operations, refer to appropriate hardware

guide:

For preventive and immediate maintenance, Casa recommends that cable operators
using redundant C10G and C100G systems have at least one upstream and one
downstream line card available should a failed card not come back up.
Casa Systems CMTS

Monitoring cable modems
Monitoring cable modems

CMTS maintenance also requires monitoring of the CMs that have registered with the
CMTS. As part of a DOCSIS MAC interface, CMs receive downstream traffic from
the CMTS, as well as transmit traffic upstream to the CMTS, as covered in full detail
in Chapter 1, “CMTS operations overview.”
The Casa Systems – CMTS Troubleshooting and Diagnostics Guide guide provide
complete information on all of the show cable modem commands with descriptions
of all fields and statistics.
As part of routine CMTS maintenance, the following show cable modem commands
provide network and connection statistics that can indicate a configuration issue with
a CM, a problem at network side interface, or other issue that might require further
investigation:
• show cable modem errors

• show cable modem offline
• show cable modem dropped-packets
Example: show cable modem errors

The show cable modem errors command displays cyclic redundancy check (CRC)
and header check sequence (HRC) errors associated with listed CMs.
CASA# show cable modem errors

MAC Address US Intf DS Intf CRC HCS
0022.68f2.d095 10/0.1/0 0/0/2 0 0
0022.68f2.d097 10/0.1/0 0/0/0 0 0
0022.68f2.d09f 10/0.1/0 0/0/0 0 0
0022.68f2.d0a5 10/0.1/0 0/0/2 0 0
…
Example: show cable modem offline

The show cable modem offline display the modems currently in the offline state as
well as the state prior to going offline.
CASA# show cable modem offline
MAC Address US DS Prim Previous Offline Rx RX SM
Intf Intf Sid State Time Power SNR Exhaust
Count
0022.cef6.7c8e 3/0.0/0 0/0/3 3316 init(r2) 2012-01-06,03:59:12 -8.0 42.1 15
Casa Systems CMTS

Checking for flapping modems
Example: show cable modem dropped-packets

The show cable modem dropped-packets command displays dropped packet
statistics over upstream and downstream channels between CMs and the CMTS.
CASA# show cable modem dropped-packets

MAC Address US Intf DS Intf US-Dropped DS-Dropped
0022.68f2.d095 10/0.1/0 0/0/2 0 0
0022.68f2.d097 10/0.1/0 0/0/0 0 0
0022.68f2.d09f 10/0.1/0 0/0/0 0 0
0022.68f2.d0a5 10/0.1/0 0/0/2 0 0
…
Checking for flapping modems

A flapping CM is one that continually drops connections with the CMTS. Connection
problems can range from hardware issues with the CM itself or due to high periods of
traffic over the cable connection. The more instances of the CM going offline results
in more instances of the CM attempting to reconnect. Flapping CMs (by MAC
address) can be placed in a flap list for continued monitoring that helps operators
diagnose and correct the problem.
For preventive measures, use the cable flap-list command to detect abnormal CMs in
the network. The command lists malfunctioning CMs and might provide information
in helping identify problems.
Configuring the CM flap list

You can define several parameters for determining which CMs are placed in the flap
list. These parameters are:
• flap-list insertion time

• flap-list power-adjust threshold
• flap-list miss threshold
• flap-list aging
• flap-list check interval
• flap-list size
Casa Systems CMTS

Setting the flap list insertion time
Setting the flap list insertion time

During a certain period, if a CM continually sends out initial ranging requests to the
CMTS, then the CMTS places the CM into the flap-list table for observation. The
configurable range is 1–120 seconds; the default value is 60 seconds. This command
can be disabled by a no form of this command:
Example: Set the flap-list insertion-time to 5 seconds

CASA (config)# cable flap-list insertion-time 5
Setting the flap list power adjust threshold

After CMs come online and the status is stable, if the power adjustment from the
CMTS to the CMs is greater than a certain unit of dB, the CMs are moved to the
flap-list table for observation. The configurable range is 1–20 dB; the default
threshold is 2 dB. This command can be disabled with the no form of the command:
Example: Set up flap-list power-adjust threshold as 5

CASA(config)# cable flap-list power-adjust threshold 5
Configuring the flap list miss threshold

When the CMs do not reply to the maintenance message sent from the CMTS after a
certain number of times, they are put into the flap-list table for observation. The
default value is 6 times. The command can be canceled using the no form of this
command.
Example: Set up flap-list miss threshold as 5

CASA(config)# cable flap-list miss threshold 5
Configuring flap list aging

Configure the period over which the CMs are maintained in the flap-list table. If the
time limit is reached, the CMs are removed from the flap-list table. After the CM is
removed, flap-list information for this CM is unavailable. The configurable range is
15–86400 minutes; the default value is 10,080 minutes (one week).
Casa Systems CMTS

Configuring the flap list check interval
Example: Configure the flap-list aging at 120 minutes

CASA(config)# cable flap-list aging 120
Configuring the flap list check interval

Set up the interval for the CMTS to scan the flap-list table. If the CMTS finds any
cable that has reached the aging limit, the CMTS removes it from the flap-list table.
When the cable mode is removed, flap-list information for this CM is unavailable. The
configurable setting is 1–1200 minutes; the default value is 120 minutes.
Example: Configure the flap-list check-interval at 20 minutes

CASA(config)# cable flap-list check-interval 20
Showing the CM flap-list

To display the CMs that are flapping on one or more cable interfaces, use the show
cable flap-list command in privileged mode. The command displays up to 100 records
by default. The command supports several arguments that allow filtering of the flap
list statistics.
Example: Display all CM records in the flap-list

CASA(config)# show cable flap-list
MAC Address Us-Int Ins Hit Miss(%) CRC P-Adj ARP-TO Flap Time
0022.68f2.d56e 10/0.1/0 66 8226 0 (0.0 %) 0 0 0 66
2013-08-20,15:50:01
0022.68f2.e9ce 10/0.1/0 54 8226 0 (0.0 %) 0 0 0 54
2013-08-20,15:49:57
Maintaining CMTS hardware

C10G and C100G CMTS systems are equipped with air filters that are designed to
protect system hardware components from dust and other airborne particles that enter
the installation environment. Keeping the chassis air filter clean ensures that an
adequate amount of air passes through the chassis and keeps the system from
overheating.
Casa Systems CMTS

Replacing the chassis air filter
Replacing the chassis air filter

Casa Systems recommends inspecting, cleaning, or replacing the chassis air filter on a
scheduled basis. A dirty air filter restricts reliable and cooling airflow over the system
hardware components.
Installation sites that are more prone to dust and other airborne elements should
inspect the chassis air filter on a biweekly, monthly, or “as required” basis.
Caution: DO NOT operate the system for more than a minute without the
air filter installed. The filter is necessary to maintain proper airflow, and
without the air filter present in the chassis, cards will overheat. Casa
Systems recommends that you have a spare filter available for use while
the removed filter is being cleaned.
All installation sites should schedule full air filter replacement annually.
Locating and removing the air filter

On the C10G and C100G platforms, the air filter is located on the front of the chassis
just above the fan modules, as illustrated in Figure 8-1.
The filter assembly has two integrated pull tabs as handling points for insertion and
removal, and the word “FILTER” on the visible edge.
Figure 8-1. C100G air filter location

I
STATUS STATUS
ACTIVE ACTIVE
ALARM ALARM
Air filter location FILTER
Casa Systems CMTS

Installing the air filter
To remove the filter, perform the following steps:
1. Using two hands, grab the push/pull tabs and slide the air filter out of the chassis.
The filters fits snugly, so use caution as you withdraw the filter from the filter slot.
2. Inspect and clean the filter using a vacuum cleaner or similar device. If the filter
appears damaged upon inspection, install a replacement if available.
If a replacement filter is not available, reinstall the existing filter after cleaning
and order a replacement from Casa Systems for installation later.
Order Number: HDW-0142-00

Figure 8-2 illustrates the chassis air filter.
Figure 8-2. Air filter assembly (top view)

Filter framwork on top
PUSH/PULL tab PUSH/PULL tab
Installing the air filter

To install a new or existing filter, perform the following steps:
1. Supporting the filter with two hands and enduring that the filter’s metal
framework is on top, align the filter with the filter slot in the chassis.
Casa Systems CMTS

Checking electrical and RF connections
2. Using the push/pull tabs, slide the filter into the chassis until it stops. The front
edge of the filter is aligned with the chassis sheet metal. You feel the filter snap
into place.
Checking electrical and RF connections

In installation environments where humidity levels vary with seasonal changes, Casa
recommends that operators inspect electrical and RF connections for the emergence of
any corrosion. In most cases, a routine visual inspection of electrical and RF cable
connections on a quarterly basis is sufficient for most installations.
If connections at the CMTS require removal and reattachment, refer to the Casa
hardware installation guide covering the specific CMTS platform for all electrical and
safety guidelines, warnings, and cautions.
Casa Systems CMTS

Index-1
Index
B
history 2-15
binding channels to the MAC domain 6-40
no form of commands 2-19
BPI and BPI+, enforcing 3-13 operations 2-8
parameters 2-9
C privileged mode 2-4
show commands 2-11
cable modem structure 2-6
initial ranging and registration 1-5 configuration conflicts, avoiding 4-3
initialization and learning 1-4
provisioning and configuration 1-6 configuration file learning, enabling 3-16
service group (CM-SG) 1-12 CPE VRFs in an IP bundle, enforcing 3-11
channel bonding 1-11
channel sharing in QAM modules 6-8
D
CMTS administrators and operators 3-2 D3.0 channel bonding 6-43
CMTS configuration DHCP authorization, enabling 3-12
displaying 4-6
DHCP leasequery 5-3
file 4-1
restoring 4-6 DHCP servers 5-1
CMTS hardware, maintaining 8-19 DNS servers 5-8
CMTS installation 1-1 DOCSIS 3.0 (D3.0) 1-3
CMTS management port 3-2 DOCSIS 3.1 (D3.1) 1-4
CMTS monitoring 8-1 DOCSIS MAC domain 1-3
CMTS preconfiguration, ensuring 6-2 downstream port parameters 6-29
command execution privileges 3-5 dynamic bonding change (DBC) 1-13
command line interface (CLI) 2-1 dynamic channel change (DCC) 1-13
accessing 2-2 Dynamic Host Configuration Protocol (DHCP) 5-1
auto-completion 2-15
changing prompt 2-18 E
command aliases 2-18
configuration mode 2-4 enabling and disabling QAM ports and channels 6-28
date/time intervals 2-16
encryption algorithm 3-14
error messages 2-17
exiting and logging off 2-4 event reporting flags for DOCSIS events 5-11
help text 2-11 exclusion lists 1-15
hierarchy 2-7 extra narrowcast channel mode 6-9
Casa Systems CMTS

Index-2 CMTS Operations and Administration Guide
F P
files from FTP and TFTP servers, copying 4-5 password
flexible licensing 6-5 default 3-3
encrypted 3-4
G
Q
general load balancing group (GLBG) 1-12
QAM 8x192 6-7
I QAM 8x8 6-6
QAM 8x96 6-7
IP bundle interfaces 6-3 QAM channel frequencies 6-7
QAM downstream channels 6-6, 6-20
L
QAM output power levels 6-30
load balancing 1-12
CM traffic 7-1 R
dynamic 1-14
policy 1-14 radio frequency interface (RFI) 1-2
static 1-14 RADIUS server authentication 3-8
local and remote logging 5-8 restricted load balancing group (RLBG) 1-12
log files from fdsk2, copying 5-13 RF cable security settings 3-10
logging DOCSIS event messages to SYSLOG 5-10 running configuration, copying 4-4
running-config 2-5
M
S
MAC domains 6-4
moving selected QAM channels to other security association descriptor TLV length 3-14
frequencies 6-24
service group (SG) 1-11
MPTS pass-through broadcast video 6-14
service groups 6-41
multiple upstream logical channels 6-35
shared secrets to protect the CM configuration
multi-port shared channel mode 6-10 file 3-14
show commands 2-11
N filtering output 2-13
Source Address Verification (SAV) rules 3-16
network side interface (NSI) 1-2
SSH clients 2-3
network topology 1-1
SSH sessions, enabling 3-6
startup-config 2-5
startup-config file to NVRAM, copying 4-4
Casa Systems CMTS

CMTS Operations and Administration Guide Index-3
T
TACACS+ server authentication 3-7
TACACS+/RADIUS loopback interface 3-9
Telnet port, setting 3-6
terminology 1-15
TFTP options 3-11
TFTP proxy, enabling 5-6
Time-of-day (ToD) server 5-7
U
upstream channel descriptors and MAPs 1-8
upstream channels 6-31
upstream service group (US-SG) 1-12
upstream timeline 1-9
user management and security control 3-4
Casa Systems CMTS

100 Old River Road
Suite 100
Andover, MA 01810
USA
978-688-6706
CMTS
Operations and Administration Guide
© 2017 Casa Systems, Inc.
All rights reserved.
DOC-3010-01
Document Revision 08.02.02

March 2017
Printed in United States of America

Operations and Administration Guide: For Casa Software Releases To 8.2.2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Operations and Administration Guide: For Casa Software Releases To 8.2.2

Uploaded by

Copyright:

Available Formats

CMTS

Operations and Administration

For Casa Software Releases to 8.2.2

Chapter 1. CMTS operations overview

CMTS installation in the network topology ........................................................ 1-1 .

About the Casa CMTS as a headend device .............................................. 1-2 .

Understanding the CMTS as a DOCSIS MAC domain ............................... 1-3 .

Cable modem initialization and learning ........................................................... 1-4 .

Cable modem initial ranging and registration .................................................... 1-5 .

Cable modem provisioning and configuration ................................................... 1-6 .

Upstream channel descriptors and MAPs ......................................................... 1-8 .

UCD and MAP operations ........................................................................... 1-8 .

Upstream timeline ....................................................................................... 1-9 .

Channel bonding and service group operations ..............................................1-11 .

Load balancing CMTS traffic ........................................................................... 1-12 .

Dynamic channel and bonding changes ................................................... 1-13 .

Load balancing policies ............................................................................. 1-14 .

Static vs. dynamic load balancing ............................................................. 1-14 .

Applying exclusion lists ............................................................................. 1-15 .

Terminology covered in this guide ................................................................... 1-15 .

Chapter 2. Using the Casa command line interface

Getting started with the CLI .............................................................................. 2-1 .

Accessing the CLI ....................................................................................... 2-2 .

Casa Systems CMTS

Entering privileged mode ............................................................................ 2-4 .

Entering configuration mode ....................................................................... 2-4 .

Exiting and logging out of the CLI ............................................................... 2-4 .

CLI basic concepts ............................................................................................ 2-5 .

Startup configuration ................................................................................... 2-5 .

Running configuration ................................................................................. 2-5 .

CLI structure summary ................................................................................ 2-6 .

CLI hierarchies ............................................................................................ 2-7 .

Moving up and down through the hierarchy ................................................ 2-7 .

CLI operations ................................................................................................... 2-8

Displaying available objects and parameters .............................................. 2-8 .

Entering parameters ................................................................................... 2-9 .

Displaying help text ....................................................................................2-11 .

Using show commands ..............................................................................2-11 .

Filtering show command output ................................................................ 2-13 .

Using command auto-completion ............................................................. 2-15 .

Displaying and executing from command line history ............................... 2-15 .

String requirements for the CLI ................................................................. 2-16 .

Setting date and time intervals .................................................................. 2-16 .

Common CLI error messages ................................................................... 2-17 .

Changing the CLI prompt ................................................................................ 2-18 .

Creating command aliases ............................................................................. 2-18 .

Deleting existing settings ................................................................................ 2-19 .

Chapter 3. Administering CMTS security

CMTS administration overview ......................................................................... 3-2 .

Configuring the CMTS management port ......................................................... 3-2 .

Changing the default CMTS password ............................................................. 3-3 .

Encrypting passwords ....................................................................................... 3-4 .

User management and security control ............................................................ 3-4 .

Adding user command execution privileges ..................................................... 3-5 .

Casa Systems CMTS

Enabling SSH sessions to the CMTS ................................................................3-6 .

Setting the Telnet port and other settings ..........................................................3-6 .

Configuring TACACS+ server authentication ....................................................3-7 .

Configuring RADIUS server authentication .......................................................3-8 .

Configuring TACACS+/RADIUS loopback interface ..........................................3-9 .

RF cable security settings ...............................................................................3-10 .

Enforcing TFTP transfer of the CM config file ............................................3-10 .

Configuring TFTP options .......................................................................... 3-11 .