TM202B Software Guide

Touchstone Telephony
Software Operators Guide (TS3.2)

Release 3.2 Standard 1.0 September 2003 ARSVD00646
Document number: ARSVD00646 Document release: Release 3.2 Standard 1.0 Date: September 2003
2002, 2003 ARRIS All rights reserved Printed in the USA

The information in this document is subject to change without notice. The statements, configurations, technical data, and recommendations in this document are believed to be accurate and reliable, but are presented without express or implied warranty. Users must take full responsibility for their applications of any products specified in this document. The information in this document is proprietary to ARRIS. ARRIS, ARRIS Interactive, and Touchstone are trademarks of ARRIS Licensing Company. Cornerstone is a registered trademark of ARRIS Licensing Company. All other trademarks and registered trademarks are the property of their respective holders.
Software Operators Guide (TS3.2) Release 3.2 Standard 1.0 Sep 2003
Publication history
September 2003 Release 3.2 Standard 1.0 version of this document.
iv
Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003
Contents
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix About the Touchstone Telephony Software. . . . . . . . . . . . . . . . . . . . . . . x Loading and Upgrading NIU Software . . . . . . . . . . . . . . . . . . . . . . . x Subscriber Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x In this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Overview
1-1
Touchstone Telephony Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1 Touchstone Telephony Modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2 Model 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2 Model 202 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4 TS3.2 Software Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4 Enhancements from TS01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6 Contents of the Software Disk. . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7 Companion Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7
Installing the Software
2-1
Procedure: Installing the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
Provisioning
3-1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 Provisioning Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 Provisioning Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4 Full DQoS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4 DSX QoS Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4 Voice and Signalling Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 About IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 CallP Feature Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 Touchstone HomePNA Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7 Compatibility Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7 HomePNA Provisioning Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7 Managing the HomePNA Interface . . . . . . . . . . . . . . . . . . . . . . . . .3-7 Provisioning Event Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8 PacketCable Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8 PacketCable (no KDC) and CPS Sequence . . . . . . . . . . . . . . . . . .3-9 GUPI Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9 Single MAC/Config File Sequence . . . . . . . . . . . . . . . . . . . . . . . .3-10 Setting Up the Provisioning Server Data. . . . . . . . . . . . . . . . . . . .3-10 Procedure: Configuring Alarm and Log Reporting . . . . . . . . . . . . . . .3-11 Procedure: Updating the KDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15
vi
Interpreting Alarms
4-1
MTA Alarm Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3 Alarm Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 Call Agent Loss of Communications . . . . . . . . . . . . . . . . . . . . . . . .4-4 Power Supply Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 Voice Line Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5 Voice Line Total Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
Interpreting Logs
5-1
Log Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 Syslog messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 Log Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3 Cable Modem Log Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3 MTA Log Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4 Common Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 NIU States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 NIU Line States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5 NIU Battery States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6 Log Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7 Certificate Downloading Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8 MTA Root Certificate download Failed . . . . . . . . . . . . . . . . . . . . . .5-8 MTA Security: Service Provider Certificate Chain Validation Failed . .5-8 MTA Root Certificate download Retry . . . . . . . . . . . . . . . . . . . . . . .5-9 MTA Root Certificate download Complete . . . . . . . . . . . . . . . . . . .5-9 MTA Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9 Voice Line Diag Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9 Voice Line Diag Passed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10 Voice Line State Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10 Voice Line Protection State Change . . . . . . . . . . . . . . . . . . . . . . .5-10 Voice Line Loop Current Change to High . . . . . . . . . . . . . . . . . . .5-11 Voice Line Loop Current Change to Normal . . . . . . . . . . . . . . . . .5-11 State Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11 CATV Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11 Power Supply Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11 MTA TFTP: No Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12 MTA TFTP: Successful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12 MTA TFTP: File Not Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12 MTA TFTP: Protocol Error: TFTP Init . . . . . . . . . . . . . . . . . . . . . .5-12 MTA TFTP: Protocol Error: TFTP Open . . . . . . . . . . . . . . . . . . . .5-12 MTA TFTP: Protocol Error: TFTP Read . . . . . . . . . . . . . . . . . . . .5-13 MTA TFTP: Protocol Error: TFTP Close . . . . . . . . . . . . . . . . . . . .5-13 MTA TFTP: Protocol Error: TFTP DB Access . . . . . . . . . . . . . . . .5-13 MTA TFTP: Config File Error . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14 MTA TFTP: Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14 MTA PROV: Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14 MTA PROV: Successful! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14
vii
Using the Password of the Day Tool
6-1
About the Password of the Day Tool . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1 Procedure: Using the PWOD Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2
MIB Reference
7-1
Supported MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 ARRIS Proprietary MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 DOCSIS MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1 PacketCable MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2 Network-related MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2 Imports and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3 Order of Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
Troubleshooting
8-1
Initial Battery Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 Using MIBs for Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 General Touchstone Information. . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 SNMPv2 MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 Interface MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 Cable Device MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6 PacketCable Event MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9 MTA MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14 Signaling MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-21 Packet Port MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-23 LED Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-25 Patterns: Normal Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-25 Patterns: Startup Sequence (Telephony Modem) . . . . . . . . . . . . .8-26 Patterns: Startup Sequence (Telephony Port) . . . . . . . . . . . . . . .8-26 End of Call Connection Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-27 Web-based Troubleshooting Interface. . . . . . . . . . . . . . . . . . . . . . . . .8-28 Standard Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-28 Advanced Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-30 Procedure: Accessing the Troubleshooting Interface. . . . . . . . . . . . .8-35 Procedure: Running Line Card Diagnostics . . . . . . . . . . . . . . . . . . . .8-38 Procedure: HomePNA Troubleshooting . . . . . . . . . . . . . . . . . . . . . . .8-40
Appendix A: Example Files
9-1
Listing of Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1 Location of Template FIles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1 MTA Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1 Cable Modem Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . .9-2 Text Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4 SNMP Co-existence Example Configuration File . . . . . . . . . . . . . . . . .9-5
Appendix B: Configuring the Service Provider Root
10-1
Service Provider Root Provisioning for Touchstone Telephony Modems . 10-2
viii
Appendix C: SNMP Access Modes
11-1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 SNMPv1/v2c NmAccess Mode . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2 SNMP Coexistence Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2 SNMP Coexistence Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2 Configuring the Cable Modem for NmAccess Mode . . . . . . . . . . . . . .11-3 Configuring SNMP access with the docsDevNmAccessTable . . .11-3 Configuring Trap Transmission with the docsDevNmAccessTable. .11-4 Rules for the docsDevNmAccessTable. . . . . . . . . . . . . . . . . . . . .11-5 Configuring the CM for Coexistence Mode . . . . . . . . . . . . . . . . . . . . .11-8 Configuring SNMPv1/v2c only coexistence . . . . . . . . . . . . . . . . .11-9 Configuring SNMPv1/v2c/v3 coexistence . . . . . . . . . . . . . . . . . .11-11 Configuring SNMPv3 only coexistence . . . . . . . . . . . . . . . . . . . .11-15 Configuring Trap Transmission within Coexistence Mode . . . . .11-15
Appendix D: Configuring SNMP Coexistence
12-1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1 Configuration File Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1 SNMP Access Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2 SNMP Trap Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2 Procedure: Configuring SNMP Co-existence . . . . . . . . . . . . . . . . . . .12-3 Procedure: Configuring Trap Servers. . . . . . . . . . . . . . . . . . . . . . . .12-14
1
Audience
About This Document

This document describes: procedures for installing and upgrading Touchstone Telephony TS3.2 software on local servers basic provisioning information and sample provisioning les included on the software CD the extensive troubleshooting information available in TS3.2, including alarms, logs, and relevant MIB objects
This document describes all the features and information available in various TS3.2 software releases. Some features described in this document may not be fully tested and supported in your specic software release version. Where possible, features supported only by specic versions are indicated in this document. See the Release Notes/Letter of Operational Considerations accompanying your software for further details.
If you are responsible for provisioning or maintaining a ToIP network that supports Touchstone Telephony NIUs, you should read this entire manual. This manual assumes that you have a basic understanding of DOCSIS and PacketCable standards, and a working knowledge of your provisioning server (including related DNS, TFTP, and DHCP servers).
About This Document
About the Touchstone Telephony Software

Touchstone Telephony software provides operating, maintenance, and troubleshooting functions for the following ARRIS NIUs: Loading and Upgrading NIU Software Subscriber Interface Touchstone Telephony Modems, models 1 and 2 Touchstone Telephony Port, model 204A
You can congure a TFTP server to automatically download the Touchstone software to the NIU when the NIU connects to the network. You can upgrade the software by setting MIB variables in the NIU. Touchstone Telephony TS3.2 software provides: support for LED status indicators PacketCable-compatible interfaces to data and telephony ports a web-based status monitoring and troubleshooting interface (see Chapter 8, Troubleshooting, for details)
In this Document
This document contains the following information: Chapter 1, Overview, provides a brief overview of the Touchstone Telephony product line and the features of the TS3.2 software release. Chapter 2, Installing the Software, describes the installation and upgrade procedures. Chapter 3, Provisioning, describes provisioning the Touchstone Telephony NIUs using the PacketCable compliant and non-compliant interfaces. Chapter 4, Interpreting Alarms, describes the alarms that TS3.2 software can generate in response to NIU events. Chapter 5, Interpreting Logs, describes log messages that TS3.2 software can generate in response to NIU events. Chapter 6, Using the Password of the Day Tool, describes the password generating tool used to access advanced NIU troubleshooting features. Chapter 7, MIB Reference, lists the standard and proprietary MIBs that apply to TS3.2 software.
About This Document
xi
Appendix A, Example Files, provides example provisioning le listings. Appendix B, Appendix B: Conguring the Service Provider Root, describes how to change the root certicate used to verify secure software downloading.
Terminology
The following is a list of terms and abbreviations used in this manual.
Call Agent (CA)
A device that maintains call state, and controls the line side of calls. The CA is often a portion of a Call Management Server (CMS).
Call Management Server (CMS)
A generic term for the devices connecting a ToIP network to the PSTN. A CMS includes both a Call Agent (CA) and the PSTN gateway, and controls audio call connections.
CallP
Call Processing. Software controlling the current state of a call.

CBR
Constant Bit Rate. A data service that provides a guaranteed, xed amount of bandwidth. Technically, it is not possible to provide actual CBR services over an IP network due to factors such as contention and latency. UGS service ows and lowlatency hardware such as the ARRIS Cadant C4 CMTS, however, can provide an approximation suitable for carriergrade telephone service.
Classier
Rules used to classify packets into a Service Flow. The device compares incoming packets to an ordered list of rules at several protocol levels. Each rule is a row in the docsQosPktClassTable. A matching rule provides a Service Flow ID (SFID) to which the packet is classied. All rules need to match for a packet to match a classier. Packets that do not match any classiers are assigned to the default (or primary) Service Flow.
CM
Cable Modem. Typically a device installed at the subscriber premises that provides a high-speed data (Internet) connection through the HFC network.
xii
About This Document
CMTS
Cable Modem Termination System. A device at a cable headend that connects to cable modems over an HFC network to an IP network.
Codec
Coder-decoder. In ToIP products, one of several possible schemes of converting audio (i.e. a phone call) to digital data and vice versa. Attributes of a codec include delity (e.g. voice quality), bandwidth, and latency.
CPE
Customer Premises Equipment. Subscriber-owned equipment connected to the network. Technically, a cable modem, MTA, or NIU falls into this category, although many operators do not designate them as such.
CVC
Code Verication Certicate, an encryption key that allows secure downloading of encrypted software over the HFC network.
DHCP
Dynamic Host Conguration Protocol. An IP protocol used to provide an IP address and location of services (such as DNS and TFTP) needed by a device connecting to the network.
DNS
Domain Name Service (Server). An IP service that associates a domain name (such as www.example.com) with an IP address.
Downstream
In an HFC network, the direction from the headend to the subscriber. Some older cable documentation may refer to this as the forward path.
DOCSIS
Data Over Cable Service Interface Specication. The interoperability standards used for data communications equipment on an HFC network.
EMTA
Embedded MTA. A device, such as the ARRIS Touchstone Telephony Modem, that contains both an MTA and a cable modem.
About This Document
xiii
Euro-DOCSIS
The European version of DOCSIS. Euro-DOCSIS species an 8MHz downstream bandwidth (vs. 6MHz for DOCSIS); other minor differences exist as well.
FQDN
Fully Qualied Domain Name. The name used to identify a single device on the Internet. See RFC2821 for details.
Headend
The central ofce in an HFC network. The headend houses both video and data equipment. In larger MSO networks, a master headend often feeds several remote headends to provide distributed services.
HFC
Hybrid Fiber-Coaxial. A broadband, bi-directional shared media transmission system using ber trunks between the headend and ber nodes, and coaxial distribution cable between the ber nodes and subscriber premises.
HomePNA
Home Phoneline Networking Alliance. A LAN interface that supports local networking over home phone lines. The Touchstone Telephony Port provides HomePNA support.
Jitter
Variance in packet arrival time. Jitter is a factor in applications such as telephony, where the originating device sends packets at a constant rate.
Latency
The time required for a signal element (e.g. packet) to pass through a device or network.
LCO
Local Connection Options. A structure that describes the characteristics of the media data connection from the point of view of the CMS creating the connection.
MAC
Acronym for Media Access Control. A general term for the link-level networking layer and associated protocols. MAC protocols used in HFC data networks include Ethernet, the DOCSIS RF interface, and HomePNA.
xiv
About This Document
Maintenance window
The usual period of time for performing maintenance and repair operations. Since these activities often affect service to one or more subscribers, the maintenance window is usually an overnight period (often 1 a.m. to 5 a.m. local time).
MD5
Message Digest 5. A one-way hashing algorithm that maps variable length plaintext into xed-length (16-byte) ciphertext. MD5 les, built by a provisioning server, contain provisioning data for each NIU on the network.
MIB
Management Information Base. The data representing the state of a managed object in an SNMP-based network management system. Often used colloquially to refer to a single object or variable in the base; e.g. the lcCmtsUpMaxCbrFlows MIB.
MSO
Multi-System Operator. A cable company that operates multiple headend locations, usually in several cities.
MPI
Micro-Processor Interface. An internal Touchstone Telephony Modem component.

MTA
Media Terminal Adapter. A subscriber premises device that contains the network interface, codecs, and all signalling and encapsulation functions required for telephony transport, CLASS features signalling, and QoS signalling. The MTA is an integral part of Touchstone Telephony embedded MTA (EMTA) products.
NCS
Network Call Signaling. The PacketCable protocol used to control calls.

NIU
Network Interface Unit. A generic term for a device providing data and telephony connections at a subscriber site. Also referred to as embedded MTA (EMTA).
NMS
Network Management System. Software, usually SNMP-based, that allows you to monitor and control devices on the network. In a ToIP network, managed devices include NIUs, CMTS, servers, PSTN interface devices, and routers. An NMS works by
About This Document
xv
reading and setting values of MIB variables presented by each device.

Off-net
A call between a ToIP phone line and a line on the PSTN.

On-net
A call between two ToIP phone lines. Depending on the CMS used, the connection may be established directly between the MTAs or be routed through a gateway.
PacketCable
A CableLabs-led initiative aimed at developing interoperable interface specications for delivering advanced, real-time multimedia services over two-way cable plant.
PSTN
Public Switched Telephone Network.

PCM
Pulse Code Modulation. A commonly employed algorithm to digitize an analog signal (e.g. voice) into a digital bit stream using simple analog to digital conversion techniques. PCM is employed in the popular G.711 codec.
QAM
Quadrature Amplitude Modulation. A method of modulating digital signals onto an RF carrier, involving both amplitude and phase coding. QAM16 modulation encodes four digital bits per state and is used on upstream carriers; QAM64 and QAM256 encode six or eight bits (respectively) for use on downstream carriers.
QoS
Quality of Service. An attribute of a Service Flow, dening limitations or guarantees for data rate, latency, and jitter.
QPSK
Quadrature Phase Shift Keying. A method of modulating digital signals onto an RF carrier, using four phase states to encode two digital bits.
RF
Radio Frequency.
xvi
About This Document
SDP
Session Description Protocol. SDP describes multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.
SLAC
Subscriber Line Audio Circuit. An internal Touchstone Telephony Modem component.

SNMP
Simple Network Management Protocol.

TFTP
Trivial File Transfer Protocol. Used in DOCSIS networks to transfer software and provisioning les to network devices.
ToIP
Telephony over IP. The ARRIS implementation of PacketCablecompliant telephony services over an HFC network.
Unsolicited Grant Service (UGS)
A Service Flow type used for applications such as telephony in which latency and jitter are critical. Packets have a xed size and interval. Within the constraints of IP networking, UGS ows attempt to deliver a constant bit rate (CBR) stream of data.
Upstream
The path from a subscriber device to the headend. Some older cable documentation may refer to this as the return path or reverse path.
VF
Voice Frequency.
Overview
This chapter describes Touchstone Telephony hardware and software features. Touchstone Telephony NIUs (also referred to as Embedded MTAs or EMTAs), provide the subscriber connection to the HFC IP network. The Touchstone NIUs are DOCSIS 1.1 and PacketCable 1.0 compliant when used with TS3.2 software.
Touchstone Telephony Port

The ARRIS Touchstone Telephony Port, model 204A, is an outdoor network-powered NIU that provides: up to four lines of telephony service cable modem functionality with either 10BaseT Ethernet or HomePNA connections CATV passthrough and internal disconnect
1-2
Overview
The Touchstone Telephony Port is the NIU of choice for operators who want to provide primary line service in small business and home environments.
Touchstone Telephony Modems

Model 102 The ARRIS Touchstone Telephony Modems, models 102A and 102D, are indoor NIUs that provide: up to two lines of telephony service cable modem functionality with 10/100BaseT Ethernet and USB 1.1 connections
The model 102D, shown on the right below, provides an integrated backup battery. The model 102A uses an external AC power supply.
Overview
1-3
The Touchstone Telephony Modems are ideal for primary or secondary lines in home environments.
1-4
Overview
Model 202
The ARRIS Model 202 Touchstone Telephony Modems are second generation NIUs. They are functionally similar to the 102 models, in a compact form factor. The model 202 Telephony modems are available in AC-only and battery-backup models (that provide up to 8 hours of backup power).
TM202 (AC-only) TM202 (with battery backup)
TS3.2 Software Functionality

The TS3.2 software provides the following functionality: Supports all current Touchstone Telephony hardware. Compatibility with DOCSIS 1.1 and PacketCable 1.0 standards, and partially compliant with PacketCable 1.1 standards. Supported Touchstone NIUs are software-upgradable to PacketCable 1.1 standards. Interoperability with all ARRIS ToIP solutions. Interoperability with ARRIS and other CMTS products.
Overview
1-5
Dynamic Quality of Service (DQoS) support for Unsolicited Grant Service (UGS) service ows for telephony connections. All TS3.2 releases support access-side (DSx) DQoS. TS3.2.2 and later releases support full PacketCable (end-toend) DQoS. Supports the following line card templates: North American Standard (-5/-7 dB) loss plan North American High (-3/-3 dB) loss plan North American 0/-9 dB loss plan Japan, Chile, Spain, Germany, and Netherlands templates Improved NCS performance and compliance over previous Touchstone software loads. TS3.2 is fully NCS compliant. TS3.2 supports SNMPv3, IPSEC, and encrypted voice trafc as required by PacketCable specications. Supports USB and Ethernet interfaces to CPE. Supports RFC 2833 functionality. RFC 2833 denes a method for carrying DTMF and other telephony signals and events in RTP packets, instead of sending audio tones over the network. Battery telemetry support (allows monitoring of battery status at the headend). Supports single- or dual-MAC address provisioning (allows interoperability with certain non-PacketCable compliant provisioning software). Support for dialup fax and modem connections, disabling echo cancellation upon detecting fax or modem start tones. Supports access to 911 (emergency), 411 (directory), 311 (nonemergency), and 611 (repair) services. Supports USB and Ethernet interfaces to CPE.
1-6
Overview
Enhancements from TS01
TS3.2 software includes the following enhancements over the previous TS01 software: End-to-end DQoS (TS3.2.2 and later releases), providing an added layer of authentication, as well as DSx DQoS support (see Provisioning Notes on page 3-4 for details). Supports a variety of non-PacketCable compliant provisioning software and cable data equipment, allowing Touchstone Telephony NIUs to interoperate with a wide range of equipment. PacketCable 1.1-compatible alarm and log interface. Support for the PacketCable Service Provider root certicate, the PacketCable Service Provider Test root certicate, and the ability to download other Service Provider root certicates (see Appendix B). Supports Model 202 Touchstone Telephony Modems. Supports HomePNA networking (Touchstone Telephony Port only). Supports end of call statistics (see End of Call Connection Statistics on page 8-27). Expanded CallP Feature Switch settings see CallP Feature Switch on page 3-5). Supports a 0/-9 dB loss plan (North America only) Support for Japan, Chile, Spain, Germany, and Netherlands line card templates
Overview
1-7
Contents of the Software Disk
The TS3.2 software is shipped on a CD that contains the following les: MIB les (see Chapter 7, MIB Reference, for a complete list) Touchstone software and data les PacketACE (see Companion Utilities below) Documentation in PDF format
Companion Utilities
The ARRIS PacketACE tools are designed for use with TS3.2 and later versions of Touchstone software. PacketACE is a conguration editor that simplies building conguration les from common fragments. See the PacketACE Conguration Tools Users Guide, ARSVD00635, for more information about PacketACE.
1-8
Overview
This chapter provides procedures used to install and upgrade Touchstone software on local DHCP and TFTP servers.
2-2

Use this procedure to install TS3.2 software on primary and backup DHCP and TFTP servers.
Requirements
You need the following to install TS3.2 software: Touchstone software CD Access to the TFTP le servers Location of the software directory on the le servers Access to the provisioning server (to change NIU provisioning les)
Action
Perform the following tasks as needed. Task Page
Installing the Software on a File Server ....................... 2-2 Conguring the NIU to Download its Software............. 2-3 Upgrading the Software through Provisioning.............. 2-3 Upgrading the Software through SNMP....................... 2-4 Installing the Software on a File Server Follow these steps to install the TS3.2 software on a le server.
1
Log into the le server, using an account with administrative privileges. If the server is local and has a CD-ROM drive, you can log directly into the le server. Otherwise, you should use an FTP client (make sure to use the binary transfer mode) or a network le sharing service to access the le server.
Insert the TS3.2 software CD into the appropriate CD-ROM drive (see the comment in step 1). Change to the appropriate server directory for software storage.
2-3
4 5
Copy or upload the TS3.2 software le from the CD to the server. Make sure that the software le has read access for all NIUs.
Conguring the NIU to Download its Software
Follow these steps to congure the Touchstone Telephony NIU provisioning data to download its software during registration. Use your provisioning server to perform this task.
1
Set the docsDevSwServer MIB to the address of the le server containing the TS3.2 software. Set the docsDevSwFilename MIB to the name of the TS3.2 software le.
Upgrading the Software through Provisioning
Follow these steps to upgrade the Touchstone software load using a provisioning server.
1
Install the new software, using the steps in Installing the Software on a File Server on page 2-2. Use the provisioning server to add or verify the following items in the cable modem conguration le:
UpgradeFileName (le name of the software load) UpgradeServer (IP address of the server containing the load) SnmpMib = docsDevSwAdminStatus.0 2 (allow
ProvisioningUpgrade)
3
During the maintenance window, use your provisioning server or element manager to reset each Touchstone NIU. The NIUs download the new software, then reset.
Verify that the NIU has the new load by checking the value of the docsDevSwOperStatus MIB (using an SNMP server). The value of the MIB should read completeFromProvisioning(3).
2-4
Upgrading the Software through SNMP
Follow these steps to upgrade the Touchstone software load using an SNMP manager.
1
Using the SNMP manager, set the following docsDevSoftware MIBs:

docsDevSwServerIP address of the server containing the
load)
docsDevSwFilenamele name of the software load docsDevSwAdminStatusset to 1 (upgradeFromMgt)
The NIU downloads the new software, then resets.

2
Verify that the NIU has the new load by checking the value of the docsDevSwOperStatus MIB. The value of the MIB should read completeFromMgt(3).
3
Overview
Provisioning Modes
Provisioning
You can provision Touchstone Telephony products using a variety of PacketCable-compliant and non-compliant tools.
Typically, you provision a ToIP network using a PacketCable-compliant provisioning server. The server provides both provisioning tools to create data les, and servers (DHCP, DNS, TFTP) to store and transfer software loads and provisioning data to both the CMTS and all attached cable modems and MTAs. In some cases, the provisioning server may not be PacketCable-compliant but supports one or two MAC addresses per NIU. To improve compatibility with non-compliant equipment, ARRIS supports six provisioning modes for Touchstone NIUs and software; each has multiple options to enable and disable PacketCable features.
Full PacketCable compliant (default)
The data and telephony components have unique IP addresses, MAC addresses, and conguration les (i.e. two of each per NIU). When the NIU registers, it makes two separate DHCP and TFTP requests. SNMP communication uses SNMPv3, sending an SNMPv3 INFORM. IPSec is supported, and may be enabled or disabled using the pktcMtaDevCmsIpsecCtrl MIB variable. Media encryption (voice security) can be enabled on a per-call basis using NCS signalling (the LCO/SDP options) or disabled per MTA using a feature switch. The feature switch is stored in NVRAM and overrides the pktcMtaDevCmsIpsecCtrl MIB variable.
3-2
Provisioning
PacketCable without KDC
A PacketCable subset, using SNMPv1 or SNMPv2 (sending an SNMPv2 INFORM). IPSec is disabled. Media encryption can be controlled on a perMTA basis using a feature switch.
CPS2000
A PacketCable subset, using SNMPv1 or SNMPv2 (sending an SNMPv2 INFORM). IPSec and media encryption are disabled.
Global Universal Provisioning Interface (GUPI)
A PacketCable subset, intended to accommodate a wide range of partially-compliant equipment. SNMP communication uses SNMPv1 or SNMPv2, with INFORM disabled. IPSec and media encryption are disabled.
Single MAC/Single Conguration File
Designed for use with certain provisioning servers that support only one IP address, MAC address, and conguration le per NIU. The NIU makes one DHCP and TFTP request. SNMP communication uses SNMPv1 or SNMPv2, with INFORM disabled. The conguration le a superset of DOCSIS 1.1, including MTA provisioning parameters. IPSec and media encryption are disabled.
DOCSIS Only
A data-only mode (no telephony support). Uses a single IP address for the cable modem component, making a DHCP and TFTP request during registration. Use the ArrisCmDevProvMethodIndicator MIB object in the CM conguration le to select a particular provisioning mode.
Provisioning
3-3
DHCP Parameters The following table lists DHCP parameters used by each provisioning method.
Provisioning Method DHCP Parameters
Full PacketCable PacketCable minus KDC CPS 2000
CM DHCP Option 177: SubOption 1: Service Providers Primary DHCP (required) SubOption 2: Service Providers Secondary DHCP (optional)
MTA DHCP Option 177: GUPI SubOption 3: Service Providers SNMP Entity (required) SubOption 4: Service Provider Network Primary DNS SubOption 5: Service Provider Network Secondary DNS SubOption 6: Kerberos Realm (FQDN) SubOption 7: Authorization method (TGT for MTA) SubOption 8: Provisioning Timer (minutes)
Separate CM and MTA offers. CM DHCP Option 177: SubOption 1: Service Providers Primary DHCP (required) SubOption 2: Service Providers Secondary DHCP (optional)
MTA DHCP Option 177: ignored MTA offer: MTA FQDN is congured in the DHCP offer (Options 12 and 15). If not present, the FQDN uses the bracketed CM IP address. DNS is optional. Single MAC/Cong File One offer requested and made. MTA FQDN is congured in the DHCP offer (Options 12 and 15). If not present, the FQDN uses the bracketed CM IP address. DNS is optional. The address is supplied in the standard DHCP option (Option 6).
3-4
Provisioning
Provisioning Method
DHCP Parameters
DOCSIS Only
One offer requested and made. The DHCP options should not contain MTA option 177 suboptions 1 and 2 (MTA primary and secondary DHCP server addresses).
Provisioning Notes
You can provision cable modem and MTA IP addresses either on separate subnets (as required in version TS01) or on a single subnet. Full DQoS Mode TS3.2.2 and later software supports Dynamic Quality of Service (DQoS) provisioning. Full DQoS simplies provisioning tasks by requiring only that the primary Best Effort (BE) and MGCP (signalling) ows be provisioned. The TS3.2.2 software dynamically sets up and tears down UGS service ows, using a standard set of parameters designed for efcient use in ToIP networks, as needed. The CMS controls the bandwidth authorization as specied in the PacketCable DQoS specications. Full DQoS provides an added layer of security by authenticating NIUs that contact it during call setup. Each session is authorized; the session authorization uses a handle (the Gate ID) assigned by the CMTS, passed to the CMS, and sent to the MTA using an NCS message, to match requests with authorizations. Upon receiving call-signalling information, the MTA passes the Gate-ID to the CMTS in a DSA/DSC message. DSX QoS Mode TS3.2 software supports an ARRIS-proprietary feature that implements QoS using UGS ows for voice transmission using DOCSIS 1.1 DSx messaging. This functionality provides a level of QoS in a network where the CMS and CMTS do not support the PacketCable Full DQoS model. DSx QoS functionality can be activated using a feature switch. When activated, the TS3.2 software sends the appropriate DSx messages needed to Add/Modify/Delete the UGS service ows. DSx messages ow only between the CMTS and the NIU, and do not involve the CMS in any validation or requests for setting up or monitoring the UGS ows. Note: When using this functionality with the ARRIS C4 CMTS, PacketCable authorization needs to be disabled. Contact your next level of support for instructions.
Provisioning
3-5
Voice and Signalling Ports
The TS3.2 software uses the RTP ports 1086 through1093 for RTCPbased voice communications. The port numbers cannot be modied or used for other purposes. By default, the MTA receives signalling information on port 2427; you can change the default port number in the MTA conguration le. By default, the MTA transmits signalling information on port 2727; you can change the default port number in the MTA conguration le, or override it by sending an NCS message from the call server once the MTA is operating. See Signaling MIB on page 8-21 for details.
About IPSec
IPSec (Internet Protocol Security) is a collection of Internet standards used to encrypt and authenticate IP packets, to provide message integrity and privacy. IPsec provides security at the network layer (all TCP and UDP packets, and layers above). IPSec is controlled by setting the pktcMtaDevCmsIpsecCtrl MIB variable for each CMS that the MTA can communicate with; you can include this variable in the MTA conguration le. Set the variable to true(1) to enable IPSec between the MTA and a particular CMS, and false(2) to disable it. Note: Touchstone NIUs use only the IPSec ESP transport mode.
CallP Feature Switch
The TS3.2 software provides an ARRIS-specic MIB used to congure the Telephony Modem for the specic sub-set of PacketCable features supported by the selected network conguration. This allows the exibility to interoperate with other vendors by providing the ability to enable/disable the following functionality: NCS message piggybacking. Allow the endpoint to transmit piggybacked NCS messages. This feature is needed to meet NCS in-order delivery requirements. A piggybacked NCS message looks like this:
RSIP 1001 aaln/*@mta204.dev33 MGCP 1.0 NCS 1.0 RM: restart . NTFY 1002 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 0 O: hd
Lockstep mode for the endpoint. Allow the endpoint to enter the LOCKSTEP quarantine mode. This mode forces the endpoint to wait for an acknowledgement to a notication (such as onhook) before processing other messages. Other messages are
3-6
Provisioning
quarantined (queued) for processing after receiving the acknowledgement. Transmission of wildcarded NCS messages. This functionality allows the endpoint to send one message to the call server that applies to all lines. TS3.2 software currently supports only the wildcarded Restart In Progress (RSIP) message. This indicates that all lines on the MTA have been reset. This message is only sent when all the lines of the device are provisioned to be InService and against the same Call Server. RFC2833 messaging support. RFC2833 support allows the Telephony Modem to use RFC2833 specic messaging with certain gateways. Contact your ARRIS tech support representative to conrm support of your gateway. DSx-QoS or full PacketCable DQoS. Provisional responses: Allow the endpoint to send provisional responses. The Telephony Modem sends a provisional response to the CMS only if it receives either a create connection (CRCX) or modify connection (MDCX) that contains a DQoS Gate ID. The CMS, in this case, must ACK the nal response later sent by the Telephony Modem. Multiple connections per line for supporting 3WC and CWT functionality. Media encryption (AES) support. Support of NCS error codes 403 & 540 for interoperation with Call Management Servers.
Complete denitions of the above functionality can be found in the PacketCable Network-Based Call Signaling Protocol Specication, PKT-SP-EC-MGCP-I08-030728. As an example, if your conguration contains a Nortel SN06 Call Management server, an ARRIS C4 CMTS, and is operating in a DSx-QoS mode, the following shows an example setting of this switch (this is taken from the text output of the conguration file using PacketACE):
SnmpMib = ppCfgMtaCallpFeatureSwitch.0 hexstr: 10.66.79
To ensure that the MTA is congured properly, contact your ARRIS Technical Support representative for the proper setting for your conguration.
Provisioning
3-7
Touchstone HomePNA Support

The Touchstone Telephony Port, model 204A, provides a Home PNA 2.0 data interface on Telephony Interface Line 1. This interface is compliant with the MAC and PHY functionality, dened in Interface Specication for HomePNA 2.0 10M8 Technology, by the Home Phoneline Networking Alliance (http://www.homepna.org/). Compatibility Exceptions The Touchstone Telephony Port operates only in HPNA 2.0 mode (10M8) and is not designed to interoperate with HPNA 1.0 (1M8) equipment or HPNA 2.0 equipment congured for 1M8 mode. The HomePNA interface is enabled by default and requires no provisioning or other software conguration for activation. To use the interface, attach any standard HomePNA adapter supporting HPNA 2.0 mode (10M8) to Telephony Line 1. Link status indicators on the HomePNA connector should show data transmission. If the device is not communicating, see HomePNA Troubleshooting on page 8-40. You manage the HomePNA interface through its entry in the Interface MIB table. An example of the Interface table is shown in the following gure.
HomePNA Provisioning Notes
Managing the HomePNA Interface
In this gure, the IfAdminStatus entry for the HPNA CPE interface is up(1), meaning a HomePNA device is connected and the link status LED on the device indicates activity. To disable the HomePNA interface, set the IfAdminStatus for the interface to down(2). There are two methods of disabling the HomePNA interface: To disable the interface permanently, set the IfAdminStatus value in the DOCSIS(CM) conguration le and reset the Touchstone Telephony Port. By setting the value in the congu-
3-8
Provisioning
ration le, the interface remains disabled after recovering from loss of communications, or during a manual reset or power cycle of the Telephony Port. Note: When disabled through the conguration le, the HomePNA interface is temporarily enabled until the Telephony Port downloads and processes the DOCSIS conguration le. To temporarily disable the interface, set the IfAdminStatus using any SNMP manager. The interface is re-enabled when the Telephony Port is reset or recovers from loss of communication.
Provisioning Event Sequences

The following diagrams show the normal sequence of events required when a PacketCable compliant NIU registers on the cable data network. The dark shaded areas are the events omitted when using each provisioning scheme. PacketCable Sequence The following diagram shows the full PacketCable event sequence. All events are included.
Provisioning
3-9
PacketCable (no KDC) and CPS Sequence
The following diagram shows the PacketCable (no KDC) and CPS event sequences. The two are identical, skipping several events in the MTA provisioning.
GUPI Sequence
The following diagram shows the GUPI event sequence. GUPI skips several steps in the MTA provisoning.
DOCSIS DOCSIS DOCSIS ToD Prov Server Flow CM / MTA CMTS DHCP TFTP Start with DOCSIS 1.1 Initialization/Registration DHCP Broadcast Discover (Option Code 177) CM-1 CM-2 CM-3 CM-4 CM-5 CM-6 CM-7 CM-8 CM-9 CM-10 MTA-1 MTA2 MTA-3 MTA-4 MTA-5 MTA-6 MTA-7 MTA-8 MTA-9 MTA-10 MTA-11 MTA-12 MTA-13 MTA-14 MTA-15 MTA-16 MTA-17 MTA-18 MTA-19 MTA-20 MTA-21 MTA-22 MTA-23 MTA-25 Resolve TFTP server FQDN TFTP server IP address Telephony config file request Telephony config file Notify completion of telephony provisioning (MTA MAC address, ESN, pass/fail) DHCP Request DHCP Ack DOCSIS 1.1 CM config file request DOCSIS 1.1 config file ToD Request ToD Response CM registration with CMTS CMTS Registration ACK DHCP Broadcast Discover (option code 60 w/ MTA device identifier) DHCP Offer (Telephony TFTP config filename, NO OPCODE 177 options) DHCP Request DHCP Ack DNS Request DNS Srv (KDC host name associated with the provisioning REALM) DNS Request DNS Response (KDC IP Address) AS Request AS Reply TGS Request TGS Reply AP Request AP Reply SNMP Inform SNMP Get Request(s) for MTA device capabilities (optional/iterative) SNMP Get Response(s) containing MTA device capabilities (optional/iterative) MTA config file SNMP Set with URL encoded file download access method (TFTP or HTTP), filename, hash, and encryption key( if required) (Key Mgmt Prot Vers. , Protocol ID, KRB_AP_REQ,, Ciphersuites, SHA-1 HMAC ) PKT DHCP PKT DNS PKT TFTP MSO KDC SYSLOG
DHCP Offer (Option Code 177 w/ telephony service provider's DHCP server address = [255.255.255.255])
Complete DOCSIS 1.1 Initialization/Registration
( KeyMgmtProtVers, Protocol ID, KRB_AP_REP, ciphersuite selected, key lifetime, Ack req , HMAC)
3-10
Provisioning
Single MAC/Cong File Sequence
The following diagram shows the event sequence for single MAC/cong le provisioning.
Setting Up the Provisioning Server Data
Set up the provisioning data as follows to use a non-PacketCable compliant provisioning server: The MTA DHCP offer may not use DNS, SNMP, or security (Kerberos or Ticket Granting). The FQDN must be in IPv4 format (i.e. an IP address such as 10.1.2.3 rather than a domain name such as tt4.example.net).
Note: DNS is not supported for FQDN when using GUPI or singleMAC/cong le provisioning.
Provisioning
3-11
Conguring Alarm and Log Reporting

Use this procedure to congure how the Touchstone NIUs generate and send events (alarms and logs). Chapters 4 and 5 provide detailed descriptions of alarms and logs, respectively. Touchstone MTA events function within the context of the PKTCEVENT-MIB. Touchstone CM events function within the context of the DOCS-CABLE-DEVICE-MIB. Overview TS3.2 software provides the capability to provision logs and alarms utilizing two different methods. A compatibility mode, that allows the TS3.2 software to use provisioning from previous software releases (see TS0101/ TS0301 Compatible Provisioning Method on page 3-14). A new mode provides the exibility to provision separate Syslog server and trap receiver addresses for alarms and logs. In addition, you can provision multiple trap receivers allowing multiple monitoring stations if desired. Finally, you can provision different reporting schemes for each event if desired.
You can use both provisioning methods as desired. However, if you use the same servers for both methods, the Telephony Modem sends duplicate reports to that server. Event Routing When the NIU generates an event, each event can be sent to any combination of: local event log CM events are stored locally in the docsDevEventTable. The Data-Over-Cable Service Interface Specications, SPOSSIv1.1-I07-030730, describes the reporting of DOCSIS and vendor-specic events. MTA events are stored locally in the pktcDevEventTable. The PacketCable Management Event Mechanism Specication, PKT-SP-MEM-I01-001128, describes the reporting of PacketCable and vendor-specic MTA events. The default conguration sends CM and MTA events only to the local event log. SNMP trap server To report CM events, you can congure the CM in either NmAccess mode or SNMP co-existence mode. To report MTA
3-12
Provisioning
events, you must congure the CM in SNMP co-existence mode. SNMP co-existence mode supports multiple trap destinations. See Conguring the CM for Coexistence Mode on page 11-8 for detailed information. Syslog server (MTA logs) The NIU sends MTA logs to the Syslog server whose IP address is specied in the pktcDevEvSyslogAddress MIB. The NIU must receive its MTA Telephony Syslog Server IP Address in the MTA DHCP OFFER, option 7. The value of the option MUST be one of the following: 0.0.0.0Disable Syslog logging for the MTA. FF.FF.FF.FFUse the CM log server as the Syslog server. Valid IP address of the Telephony syslog server. The pktcDevEvSyslogAddress MIB value can also be congured from the MTA conguration le. Syslog server (CM logs) The NIU sends CM logs to the Syslog IP address specied in docsDevEvSyslog. The CM receives its Syslog IP Address in the CM DHCP options. To disable Syslog transmission for the CM, set the IP address to 0.0.0.0.
About the Event Tables
The PKTC-EVENT-MIB provides two tables to describe events and control their reporting: the pktcDevEvProgrammableTable and the pktcDevEvFixedTable. The primary difference between the two tables is that entries in the programmable table allow for changes to the message text. Currently, the programmable table contains alarms, and the xed table contains logs, although this is not a requirement. The following tables provide an overview of the alarms and logs. pktcDevEvProgrammableTable
Event ID Origin Severity Text
65529 65530 65533 65534
ARRIS Minor(3) ARRIS Major(2) ARRIS Major(2) ARRIS Major(2)
Power Supply Telemetry Call Agent Loss of Communications Voice Line Failure Voice Line Total Failure
Provisioning
3-13
In addition, the pktcDevEvProgrammableTable denes several PacketCable alarms for battery telemetry. The ARRIS Power Supply Telemetry Alarm (and Log) supports these status events. pktcDevEvFixedTable
Instance Origin Text
1 2 3 6 7 8 10 11 14 15 16 17 18 19 20 21 22 23 24 25 26 27
ARRIS Voice Line Diag Failed ARRIS Voice Line Diag Passed ARRIS Voice Line State Change ARRIS Voice Line Protection State Change ARRIS Voice Line Loop Current Change to High ARRIS Voice Line Loop Current Change to Normal ARRIS State Change ARRIS CATV changed ARRIS Power Supply Telemetry ARRIS MTA TFTP: No Channel ARRIS MTA TFTP: Successful ARRIS MTA TFTP: File Not Found ARRIS MTA TFTP: Protocol Error: TFTP Init ARRIS MTA TFTP: Protocol Error: TFTP Open ARRIS MTA TFTP: Protocol Error: TFTP Read ARRIS MTA TFTP: Protocol Error: TFTP Close ARRIS MTA TFTP: Protocol Error: TFTP DB Access ARRIS MTA TFTP: Cong File Error ARRIS MTA TFTP: Failed ARRIS MTA PROV: Failed ARRIS MTA PROV: Successful! ARRIS MTA Security: Service Provider Certicate Chain Validation Failed
2417164291 ARRIS MTA Root Certicate download Failed 2417164292 ARRIS MTA Root Certicate download Retry 2417164290 ARRIS MTA Root Certicate download Complete
The pktcDevEvSyslogAddress MIB species the address of the Syslog server to receive event notications.
3-14
Provisioning
TS0101/TS0301 Compatible Provisioning Method
For backwards compatibility with previous releases, TS3.2 provides a proprietary method of conguring the trap/Syslog destination IP address. By setting the ppCfgMtaTeleSyslogServIpAddr MIB variable in the MTA conguration le, the MTA reports ARRIS proprietary alarms as traps/Syslog events to the specied IP address. If this IP address is set, each ARRIS alarm event reports to the local event database, an SNMP trap and a Syslog message. Each log report can also be modied by setting the new value to the pktcDevEvFixedReporting MIB.
Action
Follow these steps to congure alarm and log reporting. You can congure individual NIUs through an SNMP manager, or all NIUs by using a provisioning server to add the MIBs to the conguration le.
1
Set the pktcDevEvSyslogAddress MIB to the IP address of a Syslog server. For each event in the pktcDevEvProgrammableTable, set the pktcDevEvProgrammableReporting MIB to one of the following values:
Value Events Reported to
0x00 0x80 0xA0 0xC0 0xE0
none Local event log only Local event log and Syslog server Local event log and Trap server Local event log, Syslog server, and Trap server
For example, to congure AC Fail events to go to a Syslog server (and the local log), set the following MIB: pktcDevEvProgrammableReporting.65535.4491 = 0xA0 Note: If you want to report events to Syslog or trap servers, you must report those events to the local event log as well.
3
For each event in the pktcDevEvFixedTable, set the pktcDevEvFixedReporting MIB to one of the values shown in step 2.
Provisioning
3-15
Updating the KDC

Use this procedure if you require secure MTA provisioning and secure NCS. TS3.2 software commonly uses one of the following embedded certicates: CableLabs Real Service Provider Root certicate (default). The Real Root certicate is only issued to authorized MSOs and Service Providers. CableLabs Test Service Provider Root certicate. The Test Root certicate is an alternative to the Real Root certicate for the purpose of lab testing. If you prefer to use the test certicate, you must congure the KDC with the Test Root certicate. IPfonix Test Service Provider Root certicate (used primarily with earlier versions of Touchstone NIU software). If you continue to use the IPfonix certicate, you must recongure the CM provisioning les.
For more information, see Appendix B: Conguring the Service Provider Root. Action Perform either of the following tasks as needed. Task Page
Conguring the KDC to use the CableLabs Test root... 3-16 Using the Test Root Download feature ......................... 3-17
3-16
Provisioning
Conguring the KDC to use the CableLabs Test root
Follow these steps:

1
Generate a KDC certicate chained to your KDC certicate hierarchy (Real/Test Root CA, Service Provider CA, Local System Operator CA). the realm name that you are using the KDC's FQDN
Proceed as follows, depending on your KDC:

If you are using Then
Alopa KDC
Modify the kdcCong.org le as follows: modify the KDC realm name to contain the realm name that you are using; for example, <kdcRealm name=DEV49> Modify the principal name to contain the KDCs FQDN; for example,
<kdcPrincipalDataBase name=mmtaprovsrvr/hyde.dev49>
IPfonix KDC
Generate the KDC private key and include it in the KDC_private_key le.
If you are using a different KDC server, or need more help, contact your next level of support.
3
Place the certicates on your KDC. The directory path to place the certicates is: IPfonix - KDCDir/windows/PacketCable/certicates/ Alopa - /opt/Alopa/MetaServ/KDC/cong/certs/
Install the conguration le: IPfonix - Place the KDC_private_key le in KDCDir/windows/ Alopa - Place the kdcCong.org le in /opt/Alopa/MetaServ/ KDC/cong/
Change the realm org name in the MTA conguration le from "Really Amazing Telephone Company" to CableLabs. Restart your KDC.
Provisioning
3-17
Using the Test Root Download feature
This option allows you to continue using the KDC with the IPfonix test root conguration (supported in older versions of Touchstone NIU software). The NIUs CM conguration le must contain three MIBs, which instruct the NIU to download a test root. The test root is stored only in the NIUs RAM memory and therefore the download is required after each reboot. Follow these steps to use this option.
1
Place your IPfonix Test Root certicate on your TFTP server. This server is normally the same server as the conguration le TFTP server. Note: The certicate must use the X.509 DER-encoded format.
Edit your CM conguration le to contain the following MIBs with the following values:
PpCfgMtaDevSPTestRootCertAdminStatus: Set to downloadTestRootCert. PpCfgMtaDevSPTestRootCertFilename: Set to the le name
containing the IPfonix Test Root.

PpCfgMtaDevSPTestRootCertServer: Set to the IP address of
the TFTP server.

3
Reboot the MTA.
3-18
Provisioning
Interpreting Alarms
This chapter describes alarms supported by the TS3.2 software. Touchstone Telephony NIUs generate alarms in response to detected events. Alarm reports may be collected at: The pktcDevEventTable (part of the PKTC-EVENT-MIB) in the NIU keeps local copies of alarms until the NIU is rebooted or powered down. The default conguration stores alarms only in the local event table. A specied Syslog server (specify a Syslog server using the pktcDevEvSyslogAddress MIB). SNMP servers (the NIU sends the alarm in a pktcDevEventNotify message). See MTA Alarm Format below for details.
Alarm reporting can also be disabled. See Conguring Alarm and Log Reporting on page 3-11 for details about conguring alarm reports.
4-2
Interpreting Alarms
MTA Alarm Format

MTA alarms function within the context of the PKTC-EVENT-MIB. You can modify the text of each alarm event by setting the pktcDevEvProgrammableText MIB. The severity of each alarm event cannot be modied. An ARRIS MTA Alarm event consists of the following information: Event IndexProvides relative ordering of the objects in the event log. This also serves as a indicator of event sequence. The object value always increases except when: the log is reset using the pktcDevEvControl MIB. the device reboots and does not implement non-volatile storage for this log. the value reaches 231 (the index is a 32-bit counter that rolls over to zero at this limit). The next entry for all the above cases is 1. Event TimeProvides a human-readable description of the time at which the event occurred. Event LevelThe priority level of this event as dened by the vendor. Event Enterprise numberThe IANA enterprise number: 4115 for ARRIS events. Event IDID for a specic event to which the priority and display string are matched. These Event Ids are vendor specic. Event TextThe ID of the event. Corresponds to the pktcDevEvProgrammableId or pktcDevEvFixedId MIBs. Mac AddressProvides the MAC address of the device generating the event. FQDN/Endpoint IDThe endpoint identier followed by the FQDN/IP Address of the device. This is in the form AALN/ X:FQDN/IP Address. If the event is not specic to an endpoint, then the identier is just the FQDN/IP address.
Interpreting Alarms
4-3
Examples
The following are examples of alarms as they appear in an SNMP browser and a Syslog server. SNMP Example
Syslog Example
4-4
Interpreting Alarms
Alarm Summary
The following table summarizes the MTA alarms.
Alarm Text Event ID Priority Page
Call Agent Loss of Communications Power Supply Telemetry Voice Line Failure Voice Line Total Failure
65530 65529 65533 65534
MAJOR MINOR MAJOR MAJOR
4-4 4-4 4-5 4-6
Alarms
Touchstone Telephony NIUs may generate the following alarms. Call Agent Loss of Communications
Severity: Major, service-affecting Cause:
One of the following conditions has occurred: The MTA did not receive a response from the Call Server for an NCS message. Re-establishing communications with the Call Server clears this alarm. The Telephony Modem received a NACK in response to the RSIP message that it sent on initial registration to the call agent, resulting in CallP functionality entering a permanent error state. Clearing the condition that caused the NACK clears this alarm.
Impact: Action:
The NIU cannot register or initiate calls. Check the status of the NIU and its network connection.
Power Supply Telemetry
Severity: Major, non-service affecting Cause:
The NIU has lost AC power. The alarm includes one of the following battery status codes: AC Failthe NIU has detected an AC power failure. AC Fail Battery Lowthe NIU is operating from battery power, and has drawn down the battery to about 25% of its rated capacity.
Interpreting Alarms
4-5
AC Fail Battery Replacethe NIU is operating from battery power, and the battery has deteriorated to about 75% of its off-the-shelf capacity and should be replaced. AC Fail Battery Low Replacethe NIU is operating from battery power, and has drawn down the battery to about 25% of its rated capacity. In addition, the battery has deteriorated to about 75% of its off-theshelf capacity and should be replaced.
Impact:
None at time of alarm. Depending on the condition of the battery and the nature of the power failure, the NIU may exhaust the battery before AC power is restored. Depends on the scope of the power outage.
Action:
Voice Line Failure
Severity: Minor, service-affecting Cause:
One of the following conditions has occurred: An In-Service line card has detected a Line Card Protection Fault condition (an overcurrent protection state). A Line Card Protection Fault occurs when the line card detects foreign voltage between tip and ring, or there is an excessive imbalance in loop current. An attempt was made to put an Out-of-Service line, in an overcurrent protection state, into service.
Impact:
The affected voice line is disabled. Look for Voice Line Protection State Change logs to determine which line is in the fault condition. Run the line card diagnostics on the NIU as described in Running Line Card Diagnostics on page 8-38. If the NIU fails diagnostics, disconnect the house wiring from the NIU and proceed as follows: If the alarm clears, correct the faulty house wiring. If the alarm persists, replace the NIU.
Action:
4-6
Interpreting Alarms
Voice Line Total Failure
Severity: Major, service-affecting Cause:
The NIU detected a DSP device failure or DSP download failure. Possible causes include a corrupted software download or an NIU hardware failure. All telephony lines are disabled. Data communications are not necessarily affected. A rare occurrence of this event indicates that the DSP failed to download and should be monitored for future occurrences. If this event reoccurs on the same NIU, or occurs immediately after a reset, replace the NIU.
Impact: Action:
Interpreting Logs
This chapter describes log reports supported by the TS3.2 software. Touchstone Telephony NIUs generate logs in response to detected events. Log reports may be collected at: The docsDevEventTable (part of the DOCS-CABLEDEVICE-MIB) in the NIU keeps CM logs until the NIU is rebooted or powered down. The pktcDevEventTable (part of the PKTC-EVENT-MIB) in the NIU keeps MTA logs until the NIU is rebooted or powered down. The default conguration stores logs only in the local event tables. A specied Syslog server (specify a Syslog server using the pktcDevEvSyslogAddress MIB). SNMP servers (the NIU sends the log in a pktcDevEventNotify message). See Log Format below for details.
See Conguring Alarm and Log Reporting on page 3-11 for details on conguring log reports.
5-2
Interpreting Logs
Log Handling
TS3.2 supports several logging methods. The cable modem portion of the NIU handles all logging tasks. SNMP Traps You can congure one or more SNMP trap destinations by conguring the NIU in NmAccess mode or SNMP co-existence access mode. In SNMP v1/v2c NmAccess mode, the NIU supports event notication functions including: local event logging SYSLOG (targets/limiting/throttling) SNMP TRAP (trap-versions/targets/limiting/throttling) as specied in RFC 2669 and the current specication
For detailed information on conguring the NIU in NmAccess mode, see Conguring the Cable Modem for NmAccess Mode on page 11-3. In SNMP coexistence mode, the NIU supports event notication functions including: local event logging SYSLOG (targets/limiting/throttling) SNMP TRAP (limiting/throttling) as specied in RFC 2669 and the current specication SNMP notication functions as specied in RFC 2573
For detailed information on conguring the NIU in SNMP co-existence mode, see Conguring the CM for Coexistence Mode on page 11-8. Syslog messages TS3.2 software reports logs as syslog messages to the cable modem Syslog server IP address. Set the IP address to 0.0.0.0 to disable Syslog transmission.
Interpreting Logs
5-3
Log Format
TS3.2 software provides log messages for both the cable modem and MTA sections of the Touchstone NIU. Cable Modem Log Format Cable modem logs require the DOCS-CABLE-DEVICE-MIB. Log messages consist of the following information: EventIndexProvides relative ordering of the objects in the event log. The value of this object always increases except when: the log is reset using the docsDevEvControl MIB the device reboots and does not implement non-volatile storage for this log the value reaches 231 (the index is a 32-bit counter that rolls over to zero at this limit). The next value for all the above cases is 1. EventFirstTimeThe time that this entry was created. EventLastTimeIf multiple events are reported via the same entry, the time that the last event for this entry occurred, otherwise this should have the same value as EventFirstTime. EventCountsThe number of consecutive event instances reported by this entry. This starts at 1 with the creation of this row and increments by 1 for each subsequent duplicate event. EventLevelThe priority level of this event as dened by the vendor. These are ordered from most serious (emergency) to least serious (debug). EventIdFor this product, uniquely identies the type of event that is reported by this entry. EventTextProvides a human-readable description of the event, including all relevant context.
5-4
Interpreting Logs
MTA Log Format
MTA logs function within the context of the PKTC-EVENT-MIB. An ARRIS MTA Alarm event consists of the following information: Event IndexProvides relative ordering of the objects in the event log. This also serves as a indicator of event sequence. The object value always increases except when: the log is reset using the pktcDevEvControl MIB. the device reboots and does not implement non-volatile storage for this log. the value reaches 231 (the index is a 32-bit counter that rolls over to zero at this limit). The next entry for all the above cases is 1. Event TimeProvides a human-readable description of the time at which the event occurred. Event LevelThe priority level of this event as dened by the vendor. Event Enterprise numberThe IANA enterprise number: 4115 for ARRIS events, 4491 for PacketCable specied events. Event IDID for a specic event to which the priority and display string are matched. These Event IDs are vendor specic. Event TextThe text message associated with the event. Corresponds to the pktcDevEvProgrammableId or pktcDevEvFixedId MIBs. Mac AddressProvides the MAC address of the device generating the event. FQDN/Endpoint IDThe endpoint identier followed by the FQDN/IP Address of the device. This is in the form AALN/ X:FQDN/IP Address. If the event is not specic to an endpoint, then the identier is just the FQDN/IP address.
Interpreting Logs
5-5
Common Information
Several log messages display the NIU or battery state. NIU States The following is a list of valid NIU states and their meanings. IS NR (In Service, Normal)the NIU is operating normally. OOS TRBL (Out of Service, Trouble)the NIU is out of service due to a detected problem. Both voice and data services may be affected.
NIU Line States
The following is a list of valid NIU line states and their meanings. IS NR (In Service, Normal)the line is operating normally. IS NR TRAFBSYthe line is in service and off-hook. IS TRBL MISMATCH (In Service, Trouble, Mismatch)the MTA has detected a provisioning mismatch. IS TRBL FEF (In Service, Trouble, Family Equipment Failure)a problem with the MTA subsystem is preventing the line from functioning properly. IS TRBL TSTF (In Service, Trouble, Test Failed)the line failed diagnostics. The Voice Line Diag Failed log provides some more details. IS TRBL DIAG (In Service, Trouble, Diagnostics)the line is running diagnostics; if no problems are discovered, the line will be placed in service when diagnostics are nished. IS TRBL LCPRT (In Service, Trouble, Line Card Protection) the line card is in an overcurrent protection state. This state usually indicates either a short between tip and ring, or a foreign voltage being applied to tip and ring. OOS NR (Out of Service, Normal)the line card is out of service but has no known problems. OOS NR UNPROV (Out of Service, Normal, Unprovisioned) the line is not provisioned but has no known problems. OOS TRBL (Out of Service, Trouble)the line is out of service due to a detected problem. OOS TRBL DIAG (Out of Service, Trouble, Diagnostics)the line is out of service, and is running diagnostics.
5-6
Interpreting Logs
NIU Battery States
The following is a list of valid battery states for NIUs with battery backup. Normalthe NIU is operating on AC power. The battery is charged and in good condition. Battery Lowthe NIU has been operating from battery power, and has drawn down the battery to about 25% of its rated capacity. AC power has been restored and the battery is recharging. Battery Replacethe battery has deteriorated to about 75% of its off-the-shelf capacity and should be replaced. Battery Low Replacethe NIU has been operating from battery power, and has drawn down the battery to about 25% of its rated capacity. In addition, the battery has deteriorated and should be replaced. AC power has been restored and the battery is recharging. Shutdown Warningthe NIU has nearly exhausted its battery power, and will lose power if AC power is not restored within a few minutes. Battery Missingthe battery has been removed or has failed in such a way to appear to be removed. Telemetry Unavailablethe NIU does not support battery telemetry. Telemetry Invalidindicates a possible problem with the NIU or the battery system. Battery Reversed Shorted (Touchstone Telephony Modem only)the battery has either been installed backwards or the terminals have been shorted.
Interpreting Logs
5-7
Log Summary
The following is a list of log reports that the TS3.2 software can generate. Go to the indicated page for further details on each log report.
Log Report Event ID Priority Page
MTA Root Certicate download Failed MTA Security: Service Provider Certicate Chain Validation Failed MTA Root Certicate download Retry MTA Root Certicate download Complete Voice Line Diag Failed Voice Line Diag Passed Voice Line State Change Voice Line Protection State Change Voice Line Loop Current Change to High
2417164291 Error 2417164293 Error 2417164292 Notice 2417164290 Notice 1 2 3 6 7 Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info. Info.
5-8 5-8 5-9 5-9 5-9 5-10 5-10 5-10 5-11 5-11 5-11 5-11 5-11 5-12 5-12 5-12 5-12 5-12 5-13 5-13 5-13 5-14 5-14 5-14 5-14
Voice Line Loop Current Change to Normal 8 State Change CATV Change Power Supply Telemetry MTA TFTP: No Channel MTA TFTP: Successful MTA TFTP: File Not Found MTA TFTP: Protocol Error: TFTP Init MTA TFTP: Protocol Error: TFTP Open MTA TFTP: Protocol Error: TFTP Read MTA TFTP: Protocol Error: TFTP Close MTA TFTP: Protocol Error: TFTP DB Access MTA TFTP: Cong File Error MTA TFTP: Failed MTA PROV: Failed MTA PROV: Successful! 10 11 14 15 16 17 18 19 20 21 22 23 24 25 26
5-8
Interpreting Logs
Certicate Downloading Logs

MTA Root Certicate download Failed TFTP download of the MTA Root Certicate has failed.
Format: Fields:
MTA Root Certicate download failed: reason The reason code is one of the following: TFTP Init error (<lename>) TFTP Open - Certicate File Not Found (<lename>) TFTP Open - Request Sent No Response (<lename>) TFTP Open - OUT OF ORDER packets (<lename>) TFTP Read - Certicate File Not Found (<lename>) TFTP Read - Request Sent No Response (<lename>) TFTP Read - OUT OF ORDER packets (<lename>) File size exceeds 0x%X (<lename>) Allocating space to download Test Root certicate (0x%X) Invalid TFTP IP Address Invalid File Name
Action:
Analyze the logs for possible TFTP failures. Correct any TFTP problems and reset the NIU.
MTA Security: Service Provider Certicate Chain Validation Failed
The Service Provider Root certicate provisioned on the MTA, and the certicates obtained from the KDC, do not pass the certicate chain validation.
Format: Action:
MTA Security: Service Provider Certicate Chain Validation Failed Make sure that the Service Provider Root certicate on the MTA and the Service Provider, Local System and the KDC certicates on the KDC are congured properly.
Interpreting Logs
5-9
MTA Root Certicate download Retry
The MTA is retrying its TFTP download of the MTA Root Certicate.
Format: Fields: Action:
MTA Root Certicate download retry: nd time

n lists the number of times the NIU has attempted to download the Root Certicate (range: 1 to 3)
Monitor the logs for subsequent failure messages.
MTA Root Certicate download Complete
The NIU has successfully downloaded its MTA Root Certicate.

Format: Action:
MTA Root Certicate download Complete None.
MTA Logs
Voice Line Diag Failed The NIU has failed manual diagnostics for the specied line.
Format: Fields:
Voice Line Diag Failed, Line Number = line, Failure Reason = reason The elds are as follows:
lineThe line number of the NIU. The rst line is
line 1.
reasonone of the following:

Action:
Line is Unprovisioned Invalid State to Init Diags Power/Clock Failure SLAC Revision Failure MPI Failure PCM Failure Standby Hook Failure Active Hook Failure VF Failure Ringing Failure
Use the reason code to determine the course of action as follows: Line is UnprovisionedProvision the line and re-try the diagnostics.
5-10
Interpreting Logs
Invalid State to Init DiagsSet the line state to oos and re-try the diagnostics. othersReset the NIU and re-try diagnostics. If the problem persists, replace the NIU.
Voice Line Diag Passed
Indicates that the NIU has successfully completed manual diagnostics on the specied line.
Voice Line Diag Passed, Line Number = line

line indicates the line that passed diagnostics. The rst line is line 1.
None.
Voice Line State Change
The NIU received an operator-requested state change for the specied line.
Format: Fields:
Voice Line State Change, Line Number = line, Prev State = old_state, New State = new_state The elds are as follows:
linethe line number of the NIU. The rst line is line 1. old_state, new_statethe previous and current
line states; see NIU Line States on page 5-5 for details.
Action:
If the new state indicates a trouble condition, correct the problem.
Voice Line Protection State Change
The specied line has detected or cleared a protection fault.

Format: Fields:
Voice Line Protection State Change, Line Number = line, New State = new_state The elds are as follows: linethe line number of the NIU. The rst line is line 1. new_statethe current protection state; one of: Fault DETECTED Fault CLEARED
Interpreting Logs
5-11
Action:
Monitor the NIU for service issues and possible replacement.
Voice Line Loop Current Change to High
The NIU has changed its loop current to High.

Format: Action:
Voice Line Loop Current Change to High If the new loop current should be normal, correct the provisoning le for the NIU.
Voice Line Loop Current Change to Normal
The NIU has changed its loop current to Normal.

Format: Action:
Voice Line Loop Current Change to Normal If the new loop current should be High, correct the provisoning le for the NIU.
State Change
The NIU has received an operator-requested device state change, usually as a response to the operator changing the value of the ppCfgMtaAdminState MIB.
Format: Fields:
State Change from old_state to new_state The old_state and new_state elds reect the previous and current line states. See NIU Line States on page 5-5 for details. None.
Action:
CATV Change
The Touchstone Telephony Port has received an operator-requested state change for the CATV relay, usually as a response to the operator changing the value of the ppCfgMtaCableTvEnable MIB.
CATV changed from old_state to new_state The old_state and new_state elds reect the previous and current CATV states; valid states are ON and OFF. None.
Power Supply Telemetry
The NIU has detected a change in its battery telemetry state.

Format: Fields:
Power Supply Telemetry - state The state eld reects the telemetry state; see NIU Battery States on page 5-6 for details.
5-12
Interpreting Logs
Note: If a low battery condition persists for 24 hours, the NIU generates another Power Supply Telemetry log.
Action:
Replace the NIU battery if indicated by the telemetry state.
MTA TFTP: No Channel
The NIU was unable to open a channel to the MTA TFTP server.
Format: Action:
MTA TFTP: No Channel Make sure the TFTP server is functioning and has a route to the HFC network.
MTA TFTP: Successful
The NIU successfully downloaded its MTA provisioning le.

Format: Action:
MTA TFTP: Successful None.
MTA TFTP: File Not Found
The NIU was unable to locate its MTA provisioning le.

MTA TFTP: File Not Found: le_name The le_name eld shows the name of the MTA provisioning le. Check the MTA provisioning to determine whether the MTA should be looking for a different name. If the provisioning is correct, check the TFTP server for proper operation and make sure the le is available (and has read access set).
MTA TFTP: Protocol Error: TFTP Init
The NIU encountered a TFTP communications error.

MTA TFTP: Protocol Error: TFTP Init: err_code The err_code eld contains the error code returned by the TFTP software. Retry the download. If the problem persists, call your next level of support.
MTA TFTP: Protocol Error: TFTP Open
The NIU encountered a TFTP communications error.

Format: Fields:
MTA TFTP: Protocol Error: TFTP Open: err_code The err_code eld contains the error code returned by the TFTP software.
Interpreting Logs
5-13
Action:
Make sure the TFTP server is operating and can be reached from the NIUs controlling CMTS. Monitor the logs for similar errors from other NIUs to determine whether the problem is limited to one device (which may indicate an NIU defect or connectivity issue) or widespread (which may indicate a problem with the TFTP server or connection). If the problem persists, call your next level of support.
MTA TFTP: Protocol Error: TFTP Read
The NIU encountered an error while reading a le from the TFTP server.
MTA TFTP: Protocol Error: TFTP Read: err_code The err_code eld contains the error code returned by the TFTP software. Make sure the TFTP server is operating and can be reached from the NIUs controlling CMTS. Retry the download; if the problem persists, call your next level of support.
MTA TFTP: Protocol Error: TFTP Close
The NIU encountered an error while closing its connection to the TFTP server.
MTA TFTP: Protocol Error: TFTP Close: err_code The err_code eld contains the error code returned by the TFTP software. Make sure the TFTP server is operating and can be reached from the NIUs controlling CMTS. Retry the download; if the problem persists, call your next level of support.
MTA TFTP: Protocol Error: TFTP DB Access
The NIU encounted a TFTP communications error.

MTA TFTP: Protocol Error: TFTP DB Access: err_code The err_code eld contains the error code returned by the TFTP software. Retry the download; if the problem persists, call your next level of support.
5-14
Interpreting Logs
MTA TFTP: Cong File Error
The MTA conguration le contains invalid MIBs or invalid TLVs.

Format: Action:
MTA TFTP: Cong File Error Remove the invalid MIBs and TLVs from the conguration le. The PacketACE conguration editor automatically removes any unrecognized data.
MTA TFTP: Failed
The NIU was unable to complete downloading its MTA provisioning le from the TFTP server.
Format: Action:
MTA TFTP: Failed Check for related log messages that may indicate the cause of the problem.
MTA PROV: Failed
The NIU was unable to complete its MTA provisioning.

Format: Action:
MTA PROV: Failed Check for related log messages that may indicate the cause of the problem.
MTA PROV: Successful!
The NIU successfully completed its MTA provisioning.

Format: Action:
MTA PROV: Successful! None.
This chapter describes the purpose and usage of the ARRIS Password of the Day (PWOD) tool. Touchstone software provides a web-based troubleshooting interface (see Chapter 8, Troubleshooting for details) consisting of two parts: Standard pages, available (by default) to both subscribers and operators. Advanced pages, available only by entering a password. These pages may contain sensitive information. The password changes daily for further protection.
The PWOD tool generates the appropriate password to access the advanced troubleshooting pages.
About the Password of the Day Tool

The PWOD tool, ARRISpwod.exe, is available on the TS03 software CD. It is a Windows application, with the same hardware and software requirements as the PacketACE tool. The PWOD tool can create a single password, or a list of passwords for a range of days. For added security, you can also dene a seed value used to generate the passwords. Changing the seed requires use of the ARRIS Conguration Tool, a separate utility, to specify the seed value in the NIU conguration le.
6-2
Using the PWOD Tool

This procedure provides instructions for using the PWOD tool. Before performing any of the tasks in this procedure, double-click the le to start the PWOD tool. The following diagram shows the tool.
Action
Perform the following tasks as needed. Task Page
Generating a Single Password..................................... 6-2 Generating a List of Passwords ................................... 6-3 Changing the Seed ...................................................... 6-3 Generating a Single Password Follow these steps to generate a single password.
1 2
Start the PWOD tool, if you have not done so already. Set the Begin Day and End Day dates to the same date (the default for both elds is the current date). Click the Congure Password of the Day button. The Password of the Day appears in the text box at the bottom of the PWOD tool window. You can select and copy the password as needed.
6-3
Generating a List of Passwords
Follow these steps to generate a list of passwords.

1 2
Start the PWOD tool, if you have not done so already. Set the Begin Day and End Day dates to the range of days that you want to generate passwords for (the default for both elds is the current date). Click the Congure Password of the Day button. The Password of the Day for the rst day appears in the text box at the bottom of the PWOD tool window. The PWOD tool writes the list of passwords to a le called Passwordoftheday.dat, in the directory where the PWOD tool is located. The le contains a list of dates and the associated password for that day.
Changing the Seed
The PWOD tool can use a default seed to generate the password of the day. For added security, you can create a different seed to change the password pattern. Follow these steps to change the seed.
1 2
Start the PWOD tool, if you have not done so already. Enter a new seed value in the Seed eld at the top of the PWOD window. Make sure the Use Default Seed box is not checked. The encoded seed appears in the DES encoded eld. Note: The Touchstone NIUs also need to have the changed seed so that their internal PWOD generators remain in sync with the external tool. Write the DES encoded seed to the PPcfgMTAClientSeed MIB in the NIU conguration le.
If you want to save the seed, make sure the Save Seed box is checked. The PWOD tool saves the new seed to a le called password.dat, in the directory where the PWOD is located. Make sure that any computer that can access a password le is reasonably secure.
6-4
7
Supported MIBs
ARRIS Proprietary MIBs
MIB Reference
This chapter lists the MIBs referenced by the TS3.2 software. See Chapter 5, Troubleshooting, for a partial list of MIB variables used for troubleshooting. The MIB les required are shipped on the CD with the TS3.2 software.
The TS3.2 software supports all standard MIBs required by DOCSIS. The following ARRIS-specic MIBs are required for full SNMP support of Touchstone cable modems and are included on the software CD.
ARRIS-MIB
A header for the ARRIS enterprise MIB.

ARRIS-CM-DEVICE-MIB
The portion of the ARRIS enterprise MIB that applies to Touchstone Cable Modems.
PACKETPORT-MIB
The portion of the ARRIS enterprise MIB that applies to Touchstone NIUs. DOCSIS MIBs
DOCS-CABLE-DEVICE-MIB (RFC-2669)
Provides controls and status information in the CMTS and cable modems.
DOCS-IF-MIB (RFC-2670)
Describes MCNS compliant Radio Frequency (RF) interfaces in CMTS and cable modems.
DOCS-BPI-MIB
Describes the Baseline Privacy Interface (BPI) implementation in the CMTS and cable modems.
DOCS-BPI2-MIB
Describes the Baseline Privacy Plus Interface (BPI+) implementation in the CMTS and cable modems.
7-2
MIB Reference
DOCS-QOS-MIB
Describes the management information for Quality Of Service (QOS) in DOCSIS 1.1.
DOCS-SUBMGT-MIB
Describes the subscriber management interface for cable modems.

DOCS-IF-EXT-MIB
Extensions to the DOCS-IF-MIB.

DOCS-CABLE-DEVICE-TRAP-MIB
An extension of the CABLE DEVICE MIB dened in RFC2669. It denes various trap objects for both cable modems and the CMTS. PacketCable MIBs
PKTC-MTA-MIB
Supplies basic management objects for MTA devices.

PKTC-SIG-MIB
Contains all objects and provisioning data for each endpoint (or telephone line).
PKTC-EVENT-MIB
Supplies the basic objects required for reporting events (for example, logs and alarms). Network-related MIBs
IF-MIB
Describes generic objects for network interface sub-layers.

BRIDGE-MIB (RFC-1493)
An interface to IEEE 802.1D-style bridges.

EtherLike-MIB (RFC-1643)
Status objects and counters associated with an Ethernet interface.

IP-MIB (RFC-2011)
The MIB module for managing IP and ICMP implementations, but excluding their management of IP routes.
UDP-MIB (RFC-2013)
The MIB module for managing UDP implementations.

IGMP-STD-MIB
IGMP protocol support.

USB-MIB
Describes the cable modem USB interface.

SNMP-NOTIFICATION-MIB
This MIB module denes MIB objects that provide mechanisms to remotely congure the parameters used by an SNMP entity for the generation of notications.
MIB Reference
7-3
SNMP-TARGET-MIB (RFC-2573)
Denes MIB objects which provide mechanisms to remotely congure the parameters used by an SNMP entity for generation of SNMP messages.
SNMP-USER-BASED-SM-MIB (RFC-2574)
The management information denitions for the SNMP User-based Security Model (USM).
SNMP-USER-BASED-ACM-MIB (RFC-2575)
The management information denitions for the SNMP View-based Access Control Model (ACM).
SNMP-COMMUNITY-MIB
This MIB module denes objects to help support coexistence between SNMPv1, SNMPv2, and SNMPv3.
SNMP-USM-DH-OBJECTS-MIB
The management information denitions for providing forward secrecy for key changes for the usmUserTable, and for providing a method for kick-starting access to the agent via a Dife-Helman key agreement.
SNMP-VIEW-BASED-ACM-MIB
The management information denitions for the View-based Access Control Model for SNMP. Imports and Denitions
RFC1155-SMI
Common denitions for the structure and identication of management information for TCP/IP-based internets.
RFC1157-SNMP
Denes the SNMP protocol.

SNMPv2-PDU
Describes SNMP Protocol Data Units.

SNMPv2-TM
Denes textual conventions and objects for transporting SNMP over various network protocols.
SNMPv2-MIB
Denes SNMPv2 entities.

SNMP-FRAMEWORK-MIB (RFC-2571)
Denes the SNMP management architecture.

SNMP-MPD-MIB (RFC-2572)
SNMP Message Processing and Dispatching.

SNMPv2-SMI
Object identiers for SNMPv2.
7-4
MIB Reference
SNMPv2-TC
Common textual conventions, used throughout the MIBs.

SNMPv2-CONF
Denitions for conformance groups.

INET-ADDRESS-MIB
Denes textual conventions for representing Internet addresses. An Internet address can be an IPv4 address, an IPv6 address or a DNS domain name.
Order of Compilation
Some SNMP managers, notably SNMPc, are sensitive to the order in which MIB les are to be compiled. The following list is the recommended order for compilation. standard.mib snmp_tc.mib snmpv2.mib snmpv3.mib SNMP-COMMUNITY-MIB.mib rfc1213.mib rfc1215.mib rfc1493.mib rfc1643.mib rfc1907.mib rfc2011.mib rfc2013.mib ianaif.mib rfc2233.mib rfc2786.mib rfc2933.mib rfc2670_50.mib qos_50.mib bpi.mib
MIB Reference
7-5
bpiplus.mib dhkeychg.mib rfc2665_50.mib rfc2669_50.mib DOCS-IF-EXT-MIB.mib DOCS-CABLE-DEVICE-TRAP-MIB_50.mib lcheader.mib lancity_50.mib clabs.mib mtai02rv_50.mi2 sigi02rs_50.mi2 pkevt_50.mib almtraps.mib arrishdr.mib arris_capability.mib pp.mib usb_50.mib
Note: Files whose names contain the string _50 are modied for use with SNMPc V5.0. If you are using a different NMS, substitute the les without the string (for example, use rfc2670.mib instead of rfc2670_50.mib).
7-6
MIB Reference
8
General Touchstone Information
Troubleshooting
This chapter provides troubleshooting information for operators.
Initial Battery Charging

When the Telephony Modem is powered up, whether for the rst time or after replacing a battery, it begins a battery charging and testing sequence. See the Installation Guide for your Telephony Modem for details about the charging and testing sequence.
Using MIBs for Troubleshooting

Using an SNMP manager to read cable modem MIB variables can be useful for troubleshooting cable modem issues. The following are MIBs that can provide information to resolve many common issues. The following variables are located in the ARRIS-CM-DEVICE-MIB and provide information specic to Touchstone cable modems.
arrisCmDevWanIsolationState
Displays and controls the state of WAN Isolation.

off-InActiveMode(1) - Data trafc passes freely between the home
users network and the Internet.

on-ActiveMode(2) - The home users network is isolated from the
Internet. Data trafc does not pass between the home user's network and the Internet.
arrisCmDevSwImageName
The name of the software image currently operating on the cable modem.
arrisCmDevSwImageBuildTime
The build date and time of the software image currently operating on the cable modem.
8-2
Troubleshooting
SNMPv2 MIBs
The following variables are part of the SNMPv2 MIBs. They provide general information about the cable modem.
sysDescr
Provides information about the cable modem hardware revision level, operating software, and networking software.
sysObjectID
Provides authoritative identication of the network management subsystem contained in the cable modem.
sysUpTime
The time (in 1/100 second increments) since the network management portion of the cable modem was last re-initialized.
sysORID
Describes capabilities with respect to various MIB modules supported by the cable modem acting in an agent role
sysORDescr
A text description of the capabilities identied by the sysORID variable. Interface MIBs The following variables are part of the IF-MIB. Each interface (RF, Ethernet, USB) has its own set of variables in the IfTable. The following are the most useful troubleshooting-related variables.
ifNumber
The number of interfaces listed in the table.

ifIndex
The index number for the interface. The cable modem has the following interfaces:
1 = Ethernet interface 2 = RF MAC interface 3 = RF downstream interface 4 = RF upstream interface 5 = USB interface 16 = PacketCable Embedded Interface
The MTA has the following interfaces:

1 = DOCSIS Embedded interface 9 = Voice Over Cable interface 10 = Voice Over Cable interface ifDescr
A text string containing information about the interface.
Troubleshooting
8-3
ifType
The interface type. Values for cable modems include:

other(1) ethernetCsmacd(6) docsCableMaclayer(127) docsCableDownstream(128) docsCableUpstream(129) usb(160)
Values for MTAs include:

other(1) voiceOverCable(198) ifMtu
The size of the largest packet that can be sent and received on the interface, specied in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface.
ifSpeed
An estimate of the interface's current bandwidth, in bits per second. For interfaces that do not vary in bandwidth or for those where no accurate estimation can be made, this object contains the nominal bandwidth.
ifPhysAddress
The interface's address at its protocol sub-layer. For example, for an 802.x interface, this object normally contains a MAC address. The interface's media-specic MIB must dene the bit and byte ordering and the format of the value of this object.
ifAdminStatus
The desired state of the interface; one of up(1), down(2), or testing(3). When the cable modem initializes, all interfaces start with ifAdminStatus in the down(2) state. The conguration le can change the value of ifAdminStatus, or you can set it using the SNMP manager. The default action is to bring each interface up after loading the conguration le. The testing(3) state indicates that no operational packets can be passed.
8-4
Troubleshooting
ifOperStatus
The current operational state of the interface; one of up(1), down(2), testing(3), dormant(5), or notPresent(6). If ifAdminStatus is changed to up(1) then ifOperStatus should change to up(1) if the interface is ready to transmit and receive network trafc; dormant(5) indicates that the interface is waiting for some external action. It the status remains down(2), a fault is preventing the interface from coming up. If ifAdminStatus is down(2) then ifOperStatus should also be down(2). The testing(3) state indicates that no operational packets can be passed. The notPresent(6) indicates missing components (for example, a hardware option that has not been installed).
ifLastChange
The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered before the last re-initialization of the local network management subsystem, then this object contains a zero value.
ifInOctets
The total number of octets received on the interface, including framing characters.
ifInUcastPkts
The number of packets, delivered by this sub-layer to a higher layer (or sub-layer), which were not addressed to a multicast or broadcast address at this sub-layer.
ifInDiscards
The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.
ifInErrors
The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol.
ifInUnknownProtos
The number of packets received at the interface which were discarded because of an unknown or unsupported protocol. For any interface that does not support protocol multiplexing, this counter will always be 0.
ifOutOctets
The total number of octets transmitted out of the interface, including framing characters.
Troubleshooting
8-5
ifOutUcastPkts
The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent.
ifOutDiscards
The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
ifOutErrors
The number of outbound packets that could not be transmitted because of errors.
ifOutQLen
The length of the output packet queue (in packets).

ifSpecic
A reference to MIB denitions specic to the particular media being used to realize the interface. Values appearing in Touchstone cable modems include:
dot3 (Ethernet) docsIfMib (RF MAC-level interface) docsIfDownstreamChannelTable (RF downstream) docsIfUpstreamChannelTable (RF upstream) usbMib (USB)
8-6
Troubleshooting
Cable Device MIBs
The following variables are part of the DOCS-CABLE-DEVICE-MIB. They provide status and control for the cable modem as a system (as opposed to interface MIBs, which operate on a single interface). DocsDevBase variables The following variable allows you to reset a cable modem from the headend.
docsDevResetNow
Set this object to true(1) to reset the cable modem. Reading this object always returns false(2). DocDevSoftware variables These variables provide status and control of the cable modem software.
docsDevSwServer
The address of the TFTP server used for software upgrades. If the TFTP server is unknown, the value is 0.0.0.0.
docsDevSwFilename
The le name of the software image to be loaded into this device. Unless changed using an SNMP manager, this is the le name specied by the provisioning server.
docsDevSwAdminStatus
Controls software loading. If set to upgradeFromMgt(1), the cable modem starts downloading the software load specied by docsDevSwFilename. After successfully receiving an image, the cable modem sets its state to ignoreProvisioningUpgrade(3) and reboots. If the download process is interrupted by a reset or power failure, the cable modem reloads its previous image and, after re-initialization, continues to attempt loading the image specied in docsDevSwFilename. If set to allowProvisioningUpgrade(2), the cable modem uses the software version information supplied by the provisioning server when next rebooting (this does not cause a reboot). When set to ignoreProvisioningUpgrade(3), the cable modem disregards software image upgrade information from the provisioning server. Note that reading this object can return upgradeFromMgt(1). This indicates that a software download is currently in progress, and that the cable modem will reboot after successfully receiving an image. At initial startup, this object has the default value of allowProvisioningUpgrade(2).
Troubleshooting
8-7
docsDevSwOperStatus
Provides the current software loading status.

InProgress(1) indicates that a TFTP download is underway, either
as a result of a version mismatch at provisioning or as a result of a upgradeFromMgt request.

CompleteFromProvisioning(2) indicates that the last software upgrade was a result of version mismatch at provisioning. CompleteFromMgt(3) indicates that the last software upgrade was a result of setting docsDevSwAdminStatus to upgradeFromMgt. Failed(4) indicates that the last attempted download failed, ordi-
narily due to TFTP timeout. DocsDevServer variables These variables display and control the status of communications with network servers (CMTS, DHCP server, and so forth).
docsDevServerBootState If operational(1), the cable modem has completed loading and pro-
cessing of conguration parameters and the CMTS has completed the registration exchange. If disabled(2) then the cable modem was administratively disabled, possibly by being refused network access in the conguration le. If waitingForDhcpOffer(3) then a DHCP Discover has been transmitted and no offer has yet been received. If waitingForDhcpResponse(4) then a DHCP Request has been transmitted and no response has yet been received. If waitingForTimeServer(5) then a Time request has been transmitted and no response has yet been received. If waitingForTftp(6) then a request to the TFTP parameter server has been made and no response received. If refusedByCmts(7) then the Registration Request/Response exchange with the CMTS failed. If forwardingDenied(8) then the registration process completed, but the network access option in the received conguration le prohibits forwarding.
docsDevServerDhcp
The IP address of the DHCP server that assigned an IP address to this cable modem. Returns 0.0.0.0 if DHCP was not used for IP address assignment.
8-8
Troubleshooting
docsDevServerTime
The IP address of the Time server (RFC-868). Returns 0.0.0.0 if the time server IP address is unknown.
docsDevServerTftp
The IP address of the TFTP server responsible for downloading provisioning and conguration parameters to this cable modem. Returns 0.0.0.0 if the TFTP server address is unknown.
docsDevServerCongFile
The name of the conguration le read from the TFTP server. Returns an empty string if the conguration le name is unknown. DocsDevEvent variables These variables control event reporting, and describe network or device events that may be of interest in fault isolation and troubleshooting. Multiple sequential identical events are represented by incrementing docsDevEvCounts and setting docsDevEvLastTime to the current time rather than creating multiple rows. Entries are created with the rst occurrence of an event. Use docsDevEvControl to clear the table. Individual events can not be deleted.
docsDevEvControl
Set this object to resetLog(1) to erase the event log. Set this object to useDefaultReporting(2) to restore all event priorities to their factory-default reporting. Reading this object always returns useDefaultReporting(2).
docsDevEvSyslog
The IP address of the Syslog server. If 0.0.0.0, syslog transmission is inhibited.

docsDevEvIndex
Provides relative ordering of the objects in the event log. This object always increases except when the log is reset via docsDevEvControl, the cable modem reboots and does not keep the event log in non-volatile storage, or the value reaches 2^31. The next entry for all the above cases is 1.
docsDevEvFirstTime
The time that a particular event log entry was created. Multiple identical events can be reported using a single entry.
docsDevEvLastTime
If multiple events are reported using the same entry, the time that the last event for this entry occurred. Otherwise this should have the same value as docsDevEvFirstTime.
Troubleshooting
8-9
docsDevEvCounts
The number of consecutive event instances reported by this entry. This starts at 1 with the creation of this entry and increments by 1 for each subsequent duplicate event.
docsDevEvLevel
The priority level of this event. These are ordered from most serious (emergency) to least serious (debug).
docsDevEvId
For a particular device, uniquely identies the type of event that is reported by this entry.
docsDevEvText
A text string describing the event, including all relevant context (interface numbers, etc.). PacketCable Event MIB The following variables are part of the PKTC-EVENT-MIB. They supply the basic management objects for reporting events. See Chapter 4, Interpreting Alarms, and Chapter 5, Interpreting Logs, for events and their formats. pktcDevEventControl MIB The following variables control PacketCable event reporting.
pktcDevEvControl
Denes actions related to the event log conguration. Settings are:

resetLog(1) empties the event log (deletes all data). setDefault(2) restores all event priorities to factory default reporting parameters. useCongured(3) reloads previously congured reporting
parameters.
pktcDevEvControlState
The state of the device as modied by pktcDevEvControl. The possible states are those listed above, plus Processing (indicates that a state change is in process).
pktcDevEvSyslogAddressType
The type of Internet address of the Syslog server.

pktcDevEvSyslogAddress
The IP address of the Syslog server. Use 0.0.0.0 to specify no Syslog server. Using an FQDN is allowed but not recommended.
pktcDevEvSyslogUdpPort
The UDP port number that the MTA uses to send requests to the Syslog server.
8-10
Troubleshooting
pktcDevEventThrottle MIB The following variables control event throttling.

pktcDevEvThrottleAdminStatus
Controls the transmission of traps and syslog messages with respect to the trap pacing threshold.
throttlingInhibited(1) transmit traps and syslog messages without regard to the threshold settings. (default) dynamicThresholding(2) suppresses trap transmission and sys-
log messages to be suppressed if the number of traps would otherwise exceed the threshold.
manualThresholding(3) trap transmissions cease at the thresh-
old, and do not resume until directed to do so.

eventsInhibited(4) suppresses all trap transmission and syslog
messages. A single event is always treated as a single event for threshold counting. That is, an event causing both a trap and a syslog message is still treated as a single event. Writing to this object resets the thresholding state.
pktcDevEvThrottleInhibited If true(1), trap/inform and syslog transmission is currently inhibited due to: thresholds; the current setting of pktcDevEvThrottleAdminStatus; or no syslog (pktcDevEvSyslogAddress) or trap/inform (pktcMtaDevSnmpEntity) destinations have been
set.
pktcDevEvThrottleThreshold
Sets the number of trap/syslog events per pktcDevEvThrottleInterval to be transmitted before throttling. A single event is always treated as a single event for Threshold counting. That is, an event causing both a trap/inform and a syslog message is still treated as a single event. At initial startup, this object returns 2.
pktcDevEvThrottleInterval
The interval over which the throttle threshold applies. At initial startup, this object has a value of 1. pktcDevEvProgrammableTable This table is part of the pktcDevEventCong MIB. It congures the reporting of the various programmable events. This table allows control of the reporting of event classes. For each event priority, a combination of logging and reporting mechanisms may be chosen. The mapping of event types to priorities is vendor-dependent. Vendors may also choose to allow the user to control that mapping through proprietary means.
Troubleshooting
8-11
pktcDevEvProgrammableId
ID for a specic programmable event to which the priority and display string are matched. These Event Ids are vendor specic or in the case of PacketCable events dened in pkt-tr-memevent-id-v01001128.
pktcDevEvProgrammableEnterprise
Provides the IANA enterprise number of the device manufacturer for proprietary events, and the CableLabs IANA enterprise number for PacketCable specied events.
pktcDevEvProgrammableLevel
The priority level controlled by this entry. These are ordered from most (critical) to least (information) critical. Each event has a particular priority level associated with it. The levels are described as:
critical(1) A service-affecting condition that requires immediate
corrective action.
major(2) A service-affecting condition that requires urgent cor-
rective action.
minor(3) A non-service-affecting fault condition which warrants
corrective action in order to avoid a more serious fault.

warning(4) A potential or impending condition which can lead
to a fault; diagnostic action is suggested.

information(5) Normal event meant to convey information. pktcDevEvProgrammableReporting
Denes the action to be taken on occurrence of this event class. Implementations may not necessarily support all options for all event classes, but at minimum must allow traps and Syslog to be disabled. The value is a collection of bits:
local(0) bit log to the internal log traps(1) bit generate a trap syslog(2) bit send a Syslog message (assuming the Syslog
address is set)
inform(3) bit generate an inform none(4) bit this event is not generated pktcDevEvProgrammableText
A programmable event display string providing a human-readable description of the event.
8-12
Troubleshooting
pktcDevEvFixedTable MIB This table is part of the pktcDevEventCong MIB. It congures the reporting of the various xed events (including level, and report type) and event classes. For each event priority, a combination of logging and reporting mechanisms may be chosen. The mapping of event types to priorities is vendor-dependent.
pktcDevEvFixedId
ID for a specic xed event to which the priority and display string are matched. These Event Ids are vendor specic or in the case of PacketCable events dened in pkt-tr-memevent-id-v01-001128.
PktcDevEvFixedEnterprise
pktcDevEvFixedLevel
The priority level that is controlled by this entry. These are ordered from most (critical) to least (information) critical. Each event has a particular priority level associated with it (as dened by the vendor). The levels are:
critical(1) - A service-affecting condition that requires immediate
corrective action.
major(2) - A service-affecting condition that requires urgent cor-
rective action.
minor(3) - A non-service-affecting fault condition which warrants
corrective action in order to avoid more serious fault.

warning(4) - A potential or impending condition which can lead to
a fault; diagnostic action is suggested.

information(5) - Normal event meant to convey information. pktcDevEvFixedReporting
Denes the action to be taken on occurrence of this event class. Implementations may not necessarily support all options for all event classes, but at minimum must allow traps and Syslog to be disabled. The value is a collection of bits:
local(0) bit log to the internal log traps(1) bit generate a trap syslog(2) bit send a Syslog message (assuming the Syslog
address is set)
inform(3) bit generate an inform
Troubleshooting
8-13
none(4) bit this event is not generated. pktcDevEvFixedText
A xed event display string providing a human-readable description of the event. pktcDevEventLocal MIB This MIB provides the pktcDevEvent table, that contains a log of network and device events that may be of interest in fault isolation and troubleshooting.
pktcDevEvIndex
Provides relative ordering of the objects in the event log. This object will always increase except when (a) the log is reset via pktcDevEvControl, (b) the device reboots and does not implement non-volatile storage for this log, or (c) it reaches the value 2^31. The next entry for all the above cases is 1. This also serves as a indicator of event sequence.
PktcDevEvTime
Provides a human-readable description of the time at which the event occurred.

pktcDevEvLevel
The priority level of this event as dened by the vendor. These are ordered from most serious (critical) to least serious (debug).
pktcDevEvEnterprise
pktcDevEvId
ID for a specic event to which the priority and display string are matched. These Event Ids are vendor specic or in the case of PacketCable events dened in pkt-tr-memevent-id-v01-001128.
pktcDevEvText
Provides a human-readable description of the event, including all relevant context (interface numbers, etc.).
pktcDevEvMacAddress
Provides the MAC address of the device generating the event.

pktcDevEvEndpointName
This is the endpoint identier followed by the FQDN/IP Address of the device. This is in the form - AALN/X:FQDN/IP Address. If the event is not specic to an endpoint, then the contents is just the FQDN/IP address.
8-14
Troubleshooting
MTA MIB
This MIB module supplies the basic management objects for the MTA Device. The MTA MIB only supports a single provisioning server.
pktcMtaDevResetNow
Setting this object to true(1) causes the device to reset. Reading this object always returns false(2). When set to true, the following actions occur: 1. All connections (if present) are ushed locally. 2. All current actions such as ringing immediately terminate. 3. Requests for notications such as notication based on digit map recognition are ushed. 4. All endpoints are disabled. 5. The provisioning ow is started at step MTA-1 of the provisioning process.
pktcMtaDevMacAddress
The telephony MAC address for this device.

pktcMtaDevFQDN
The Fully Qualied Domain Name for this MTA.

pktcMtaDevEndPntCount
The physical end points for this MTA.

pktcMtaDevEnabled
The MTA Administrative Status of this device, where True(1) means the voice feature is enabled and false(2) indicates that it is disabled.
pktcMtaDevProvisioningState
The completion state of the initialization process, sent as part of the nal INFORM (step MTA-25 of the provisioning process). If the conguration le could be parsed successfully and the MTA is able to reect the same in its MIB, it must return: pass. If the conguration le was in error due to incorrect values PacketCable in the mandatory parameters, the MTA must reject the conguration le and return: fail. If the conguration le had proper values for all the mandatory parameters but has errors in any of the optional parameters (including any vendor specic OIDs which are incorrect or not known to the MTA), it must return: passWithWarnings. If the conguration le is proper, but the MTA cannot reect the same in its MIB (for example, too many entries leading to memory
Troubleshooting
8-15
exhaustion), it must accept details related to the CMSs passWithIncompleteParsing. If the conguration le cannot be parsed due to an internal error it must return: failureInternalError. If the MTA cannot accept the conguration le for any other reason than the ones stated above, it must return failureOtherReason.
pktcMtaDevHttpAccess
Indicates whether HTTP le access is supported for MTA conguration le transfer.

pktcMtaDevProvisioningTimer
Enables setting the duration of the provisioning timeout timer. The timer covers the provisioning sequence from step MTA-1 to step MTA-23. The value is in minutes and setting the timer to 0 disables this timer. The default value for the timer is 10.
pktcMtaDevProvisioningCounter
This object is the count of the number of times the provisioning cycle has looped through step MTA-1 since the last reboot.
pktcMtaDevErrorOidsTable If pktcMtaDevProvisioningState is reported with anything other than a pass(1), then this table is populated with the necessary
information, each pertaining to observations of the conguration le. Even if different parameters share the same error (for example, all Realm Names are invalid), all recognized errors must be reported as different instances. This contains the necessary information an MTA must attempt to provide in case the conguration le is not parsed and/or accepted in its entirety.
pktcMtaDevErrorOidIndex This is the index to pktcMtaDevErrorOidsEntry. This is an integer
value and will start from the value 1and be incremented for each error encountered in the conguration le. The indices need not necessarily reect the order of error occurrences in the conguration le.
pktcMtaDevErrorOid
This is the OID associated with the particular error. If the error was not due to an identiable OID, then this can be populated with impartial identiers, in hexadecimal or numeric format.
pktcMtaDevErrorGiven
If the error was due to the value associated with the corresponding pktcMtaDevErrorOid, then this contains the value of the OID as interpreted by the MTA in the conguration le provided. If the error was not due to the value of an OID this must be set to an empty string. This is provided to eliminate errors due to misrepresentation or misinterpretation of data.
8-16
Troubleshooting
pktcMtaDevErrorReason
This indicates the reason for the error, as per the MTAs interpretation, in human readable form. For example: VALUE NOT IN RANGE VALUE DOES NOT MATCH TYPE UNSUPPORTED VALUE LAST 4 BITS MUST BE SET TO ZERO OUT OF MEMORY - CANNOT STORE This MAY also contain vendor specic errors for vendor specic OIDs and any proprietary error codes/messages which can help diagnose errors better, in a manner the vendor deems t.
pktcMtaDevCongFile
The URL of the TFTP/HTTP le for downloading provisioning and conguration parameters to this device. Returns NULL if the server address is unknown. Supports both TFTP and HTTP.
pktcMtaDevSnmpEntity
The FQDN of the SNMP V3 entity of the Provisioning Server to which the MTA has to communicate in order to receive the access method, location and the name of the Conguration le during MTA provisioning. This would also be the entity which caters to the End-point provisioning needs of the MTA and is the destination for all provisioning informs. It may be also used for post-provisioning SNMP operations.
pktcMtaDevProvState operational(1) the device has completed loading and processing
of initialization parameters.
disabled(2) the device was administratively disabled, possibly
by being refused network access in the conguration le.

waitingToStart(10) the MTA is has not received a signal to start
initialization.
waitingForDhcpOffer(12) a DHCP Discover has been transmitted and no offer has yet been received. waitingForDhcpAckResponse(14) a DHCP Request has been
transmitted and no response has yet been received.

waitingProvRealmKdcNameResponse(16) a DNS Srv
request has been transmitted and no reply has yet been received.
waitingForProvRealmKdcAddrResponse(18) a DNS request
has been transmitted and no reply has yet been received.
Troubleshooting
8-17
waitingForAsReply(20) an AS request has been and no MSO KDC AS Kerberos ticket reply has yet been received. waitingForTgsReply(22) a TGS request has been transmitted
and no TGS ticket reply has yet been received.

waitingForApReply(24) an AP request has been transmitted and no SNMPv3 key info reply has yet been received. waitingForSnmpGetRequest(26) an INFORM message has
been transmitted and the device is waiting on optional/iterative GET requests.

waitingForSnmpSetInfo(28) the device is waiting on congu-
ration file download access information.

waitingForTftpAddrResponse(30) a DNS request has been
transmitted and no reply has yet been received.

waitingForCongFile(32) a TFTP request has been transmitted
and no reply has yet been received or a download is in progress.

waitingForTelRealmKdcNameResponse(34) a DNS Srv
request has been transmitted and no name reply has yet been received.
waitingForTelRealmKdcAddrResponse(36) a DNS request has been transmitted and no address reply has yet been received. waitingForPkinitAsReply(38) an AS request has been transmit-
ted and no ticket reply has yet been received.

waitingForCmsKerbTickTgsReply(40) a TGS request has been transmitted and no ticket reply has yet been received. waitingForCmsKerbTickApReply(42) a AP request has been
transmitted and no Ipsec parameters reply has yet been received.

pktcMtaDevServerDhcp1
The IP address of the primary DHCP server which would cater to the MTA during its provisioning. Contains 255.255.255.255 if there was no preference given with respect to the DHCP servers for MTA provisioning.
pktcMtaDevServerDhcp2
The IP address of the Secondary DHCP server which could cater to the MTA during its provisioning. Contains 0.0.0.0 if there is no specic secondary DHCP server to be considered during MTA provisioning.
pktcMtaDevTimeServer
IP address of the Time Server from which to obtain the time. Contains 0.0.0.0 if the Time Protocol is not used for time synchronization.
8-18
Troubleshooting
pktcMtaDevRealmTable
Shows the KDC realms. The table is indexed with pktcMtaDevRealmName. The Realm Table is used in conjunction wit h any server which needs a security association with an MTA. The server table (today the CMS) has a security association. Each server-MTA security association is associated with a single Realm. This allows for multiple realms, each with its own security association. Contains per Kerberos realm security parameters.
pktcMtaDevRealmName
The corresponding Kerberos Realm name. This is used as an index into pktcMtaDevRealmTable. When used as an index, the upper case ASCII representation of Realm Name MUST be used by both the Manager (SNMPv3 Entity) and the MTA.
pktcMtaDevRealmPkinitGracePeriod
For the purposes of the key management with an Application Server (CMS or Provisioning Server), the MTA MUST obtain a new Kerberos ticket (with a PKINIT exchange) this many minutes before the old ticket expires. The minimum allowable value is 15 minutes. The default is 30 minutes. This parameter MAY also be used with other Kerberized applications.
pktcMtaDevRealmTgsGracePeriod
When the MTA implementation uses TGS Request/TGS Reply Kerberos messages for the purpose of the key management with an Application Server (CMS or Provisioning Server), the MTA MUST obtain a new service ticket for the Application Server (with a TGS Request) this many minutes before the old ticket expires. The minimum allowable value is 1 min. The default is 10 minutes. This parameter MAY also be used with other Kerberized applications.
pktcMtaDevRealmOrgName
The value of the X.500 organization name attribute in the subject name of the Service provider certicate.
pktcMtaDevRealmUnsolicitedKeyMaxTimeout
This timeout applies only when the MTA initiated key management. The maximum timeout is the value which may not be exceeded in the exponential backoff algorithm. Default value is 30.
pktcMtaDevRealmUnsolicitedKeyNomTimeout
Denes the starting value of the timeout for the AS-REQ/REP Backoff and Retry mechanism with exponential timeout. If provided, DHCP Option 177 Sub-option 10 overrides this value. Default value is 10000.
pktcMtaDevRealmUnsolicitedKeyMeanDev
A measurement of the mean deviation for the round trip delay timings.
Troubleshooting
8-19
pktcMtaDevRealmUnsolicitedKeyMaxRetries
The maximum number of retries before the MTA gives up attempting to establish a security association.
pktcMtaDevRealmStatus
Contains the Row Status associated with the pktcMtaDevRealmTable. pktcMtaDevCmsTable
Shows the IPSec key management policy relating to a particular CMS. The table is indexed with pktcMtaDevCmsFQDN. Contains per CMS key management policy.
pktcMtaDevCmsFqdn
The fully qualied domain name of the CMS. This is the index into the pktcMtaDevCmsTable. When used as an index, the upper case ASCII representation of the associated CMS FQDN MUST be used by both the Manager (SNMPv3 Entity) and the MTA.
pktcMtaDevCmsKerbRealmName
The Kerberos Realm Name of the associated CMS. This is the index into the pktcMtaDevRealmTable. When used as an index, the upper case ASCII representation of the associated CMS FQDN must be used by both the Manager (SNMPv3 Entity) and the MTA.
pktcMtaDevCmsMaxClockSkew
The maximum allowable clock skew between the MTA and CMS
pktcMtaDevCmsSolicitedKeyTimeout
This timeout applies only when the CMS initiated key management (with a Wake Up or Rekey message). It is the period during which the MTA will save a nonce (inside the sequence number eld) from the sent out AP Request and wait for the matching AP Reply from the CMS.
pktcMtaDevCmsUnsolicitedKeyMaxTimeout
This timeout applies only when the MTA initiated key management. The maximum timeout is the value which may not be exceeded in the exponential backoff algorithm.
pktcMtaDevCmsUnsolicitedKeyNomTimeout
Denes the starting value of the timeout for the AP-REQ/REP Backoff and Retry mechanism with exponential timeout for CMS. If provided, the MTA-conguration le content overrides this value.
pktcMtaDevCmsUnsolicitedKeyMeanDev
The measurement of the mean deviation for the round trip delay timings.
8-20
Troubleshooting
pktcMtaDevCmsUnsolicitedKeyMaxRetries
The maximum number of retries before the MTA gives up attempting to establish a security association.
pktcMtaDevCmsStatus
Contains the Row Status associated with the pktcMtaDevCmsTable. pktcMtaDevCmsIpsecCtrl If true(1), IPSEC and IPSEC Key Management MUST be used to
communicate with the CMS. If false(2), IPSEC Signaling Security is disabled for both the IPSEC Key Management and IPSEC protocol (for the specic CMS).
pktcMtaCmsMapTable
Contains the signaling associations between MTA endpoints and CMSs. It maps the endpoint to zero or more entries in pktcMtaDevCmsTable. Contains per endpoint CMS signaling associations.
pktcMtaCmsMapCmsFqdn
The index for the associated CMS. Valid indices are equal to current pktcMtaDevCmsFqdn values.
pktcMtaCmsMapOperStatus
Indicates which signaling association the endpoint is actively using. The operational status of signaling association. The meaning of the status is as follows: inactive - signaling is not currently active, active - signaling is active.
pktcMtaCmsMapAdminStatus
Indicates whether or not an endpoint should use a particular CMS and its security association. By setting this ag to inhibit, this associated CMS cannot provide signaling to the referenced endpoint. The administrative status for signaling over the indicated security association. The meaning of the status is as follows: inhibit - signaling is not currently allowed, allow - signaling is allowed.
pktcMtaCmsMapRowStatus
Allows for the creation and deletion of endpoint mappings via the NMS. This object is used for creating and deleting an entry in this table via an element manager. Setting up Security Associations A security association may be set up using either conguration or NCS signaling initiation. When using the conguration le, the realm must be congured rst. Associated with the realm is a KDC. The realm table (pktcMtaDevRealmTable) indicates information about the realm (e.g., name, organi-
Troubleshooting
8-21
zation name) and parameters associated with KDC communications (e.g., grace periods, AS request/AS reply adaptive backoff parameters). Once the realm is established, one or more servers may be dened in the realm. For PacketCable 1.0, these are Call Management Servers (CMSs). Associated with each CMS entry in the pktcMtaDevCmsTable is an explicit reference to a Realm via the realm index (pktcMtaDevCmsKerbRealmName), the FQDN of the CMS, and parameters associated with IPSec key management with the CMS (e.g., clock skew, AP request/ AP reply adaptive backoff parameters). Signaling MIB This MIB module supplies the basic management object for the PacketCable Signaling protocols. This version of the MIB includes common signaling and Network Call Signaling (NCS) related signaling objects.
PktcCodecType
Textual Convention denes various types of CODECs that MAY be supported. The list of CODECs MUST be consistent with the CODEC specication PKT-SP-CODEC-I04-021018.
PktcRingCadence
Represents a ring cadence in bit string format. The ring cadence representation starts with the rst 1 in the pattern (the leading 0s in the MSB are padding and are to be ignored). Each bit represents 100ms of tone; 1 is tone, 0 is no tone. 60 bits are used for cadence representation, the least signicant 4 bits represent repeatable characteristics. 0000 means repeatable, and 1000 means non repeatable. As an example, the hex representation of a ring cadence of 0.5 seconds on; 4 seconds off; repeatable would be: 0x1F0000000000.
PktcSigType
The various types of signaling that may be supported.

ncs - Network Call Signaling; a derivation of MGCP (Media Gateway Control Protocol) version 1.0. dcs - Distributed Call Signaling; a derivation of SIP (Session Initi-
ation Protocol) RFC 2543

pktcSigDevCodecTable
This table describes the MTA supported CODEC types.

pktcSigDevCodecIndex
The index value which uniquely identies an entry in the pktcSigDevCodecTable. pktcSigDevCodecType
A CODEC type supported by this MTA.
8-22
Troubleshooting
pktcSigDevCodecMax
The maximum number of simultaneous sessions of the specic codec that the MTA can support.
pktcSigDefNcsReceiveUdpPort
Contains the MTA User Datagram Protocol (UDP) receive port that is being used for NCS call signaling. This object should only be changed by the conguration le. Default value is 2427.
pktcSigNcsServiceFlowState
Contains a status value of the Call Signaling Service Flow.

not-active indicates that the NCS SF is not being used, and has not tried to be created. active indicates that the NCS SF is in use. error indicates that the NCS SF creation resulted in an error and the
best effort channel is used for NCS Signaling

pktcNcsEndPntCongCallAgentId
Contains a string indicating the call agent name (for example, [email protected]). The call agent name after the character @ MUST be a fully qualied domain name and MUST have a corresponding pktcMtaDevCmsFqdn entry in the pktcMtaDevCmsTable.
pktcNcsEndPntCongCallAgentUdpPort
Contains the call agent User Datagram Protocol (UDP) receive port that is being used for this instance of call signaling, i.e. the default port on which the call agent receives NCS signaling from the gateway. The default port number is 2727.
pktcNcsEndPntCongStatus
Contains the Row Status associated with the pktsNcsEndPntTable. pktcNcsEndPntCongCallWaitingMaxRep
Contains the maximum number of repetitions of the call waiting tone that the MTA plays from a single CMS request. A value of zero (0) can be used if the CMS is to control the repetitions of the call waiting tone.
pktcNcsEndPntCongCallWaitingDelay
Contains the delay between repetitions of the call waiting tone that the MTA plays from a single CMS request.
pktcNcsEndPntStatusCallIpAddress
Contains the IP address of the CMS currently being used for this endpoint. This IP address creates the appropriate security association.
Troubleshooting
8-23
pktcNcsEndPntStatusError
Contains the error status for this interface. The operational state indicates that all operations necessary to put the line in service have occurred. The noSecurityAssociation status indicates that no security association yet exists for this endpoint. The disconnected status indicates that the security Association has been established and the NCS signaling Software is in process of establishing the NCS signaling Link via an RSIP exchange. Packet Port MIB This MIB contains ARRIS-proprietary variables used to control the MTA portion of Touchstone NIUs.
CountryCode
These are the countries for the country code template object. northAmerica57(1), chile(2), japan(3), australia(4), austria(5), france(6), germany(7), ireland(8), netherlands(9), portugal(10), spain(11), belgium(12), poland(13), israel(14), czechRepublic(15), brazil(16), northAmerica33(17), northAmerica09(18)
ppCfgPortTxGainControl
The per line transmit gain control setting (dB). Not currently used.
ppCfgPortRxGainControl
The per line receive gain control setting (dB). Not currently used.
ppCfgMtaCableTvEnable
Provides the ability to turn the cable off and on.

ppCfgMtaDataInterface
The data interface type: eth10baset(1), hpna1mbps(2), hpna10mbps(3), eth100baset(4), eth100basex(5).

ppCfgMtaCallpFeatureSwitch
See CallP Feature Switch on page 3-5 for details.

ppSurvPortMaintState
The maintenance state of the line: isnr(1), isnr-trafbsy(2), istrblmismatch(3), istrbl-fef(4), istrbl-tstf(5), istrbl-diag(6), istrbllcprt(7), oosnr-unprov(8), oosnr(9), oostrbl(10), oostrbltstf(11), oostrbl-diag(12), oostrbl-lcprt(13)
ppSurvPortLcDiagRequest Setting this value to true sends a diagnostics request on the line. Reading this value always returns false. The maintenance state of
the line indicates if diagnostics are being run on the line.

ppSurvPortLcDiagLastResult
The last result of diagnostics for this line: diagnostics-passed(1), slac-revision-failure(2), mpi-failure(3), power-or-clock-fail-
8-24
Troubleshooting
ure(4), pcm-failure(5), standby-hook-failure(6), active-hookfailure(7), vf-failure(8), ringing-failure(9), invalid-state-to-initdiags(10), line-is-unprovisioned(11), diagnostics-resultspending(12). If diagnostics are in progress it returns diagnosticsresults-pending. ppSurvMtaPowerSupplyTele
The battery telemetry state: tlm-unavailable(0), tlm-invalid(1), tlm-shutdown-warning(2), tlm-batt-reversed-shorted(3), tlmbatt-low-replace-ac-fail(4), tlm-batt-low-replace(5), tlm-battlow-ac-fail(6), tlm-batt-low(7), tlm-batt-missing(8), tlm-ac-failbatt-replace(9), tlm-replace-batt(10), tlm-ac-fail(11), tlm-normal(12)
ppSurvMtaMaintState
The maintenance state of the PacketPort: isnr(1), istrbl(2), oos(3).
Troubleshooting
8-25
LED Patterns
Touchstone NIUs indicate status using the ve LEDs on the front panel. Patterns: Normal Operation The following table shows LED patterns during normal operation. An x indicates that the particular LED is not important for determining the state.
Name Description Power Online Cable USB Ethernet
Off
On On On On On On On On On On
Off Blink
On
Off x x
On
Off x x x x Off
On
Off x x x x x x x Off
On
No power Standby switch active (the computers are disconnected from the Internet) Standby switch inactive No data to/from the cable interface Data activity on the cable interface USB link disconnected (i.e. PC is disconnected or powered off) USB link connected, no trafc USB data activity with PC Ethernet link disconnected (i.e. equipment is disconnected or powered off) Ethernet link connected, no trafc Ethernet data activity with connected equipment
x x x x x x x x
Blink x x x x x x
Blink x x x
Blink
8-26
Troubleshooting
Patterns: Startup Sequence (Telephony Modem)
The following table shows the Touchstone Telephony Modem LED patterns during each phase of the startup sequence.
State Pwr On On On On On On On On On On Cable Data Tele. Online
Hardware Diags DOCSIS Downstream Scanning DOCSIS Ranging DOCSIS DHCP DOCSIS TFTP DOCSIS Data Reg Complete MTA DHCP MTA TFTP MTA Reg with Call Server MTA Reg Complete
Off Blink Blink Off Off

On
Off Off Off Blink Blink Blink Off

On
Off Off
On
Off Off Off Off Off

On On On On On
Off
On
Off Blink Blink Blink

On
Off Off
On On
Off Blink
Patterns: Startup Sequence (Telephony Port)
The following table shows the Touchstone Telephony Port 7-segment LED patterns during each phase of the startup sequence.
State Display
Hardware Diags DOCSIS Downstream Scanning DOCSIS Ranging DOCSIS DHCP DOCSIS TFTP DOCSIS Data Reg Complete MTA DHCP MTA TFTP MTA Reg with Call Server MTA Reg Complete
0 1 2 3 4 d 6 7 8 walking
The walking pattern lights each outside segment in a circular pattern. With no telephony enabled, the LED cycles through its three horizontal segments. See the Touchstone Telephony Port Installation Guide, ARSVD00461, for details.
Troubleshooting
8-27
End of Call Connection Statistics

The TS3.2 software release supports the PacketCable dened call connection statistics. The software sends connection statistics to the call server during the call tear down procedure. PacketCable compliant call servers should provide a method of reporting these captured statistics (see your call server documentation for instructions on accessing the statistics). The statistics provide information on the performance of the network including the following: Number of packets sent Number of octets sent Number of packets received Number of octets received Number of packets lost in transit Interarrival jitterthe mean deviation (smoothed absolute value) of the difference in packet spacing at the receiver compared to the sender for a pair of packets. Average transmission delay Note: This statistic reports the network delay, not one-way delay. It does not account for delay within the device such as jitter buffers etc. It strictly measures the delay of the trafc travelling the users network.
In addition to the parameters above, an endpoint that has received one or more RTCP sender or receiver reports from its peer must also send the following statistics: Remote packets sent Remote octets sent Remote packets lost Remote jitter
Complete denitions of these statistics can be found in the PacketCable Network-Based Call Signaling Protocol Specication, PKT-SP-ECMGCP-I08-030728.
8-28
Troubleshooting
Web-based Troubleshooting Interface

The TS3.2 software provides a web-based interface to a status monitoring and troubleshooting subsystem. Status information is available to anyone by using a standard web browser to access the cable modem IP address. A password-protected set of pages provides views of advanced network settings. The following sections describe the screens available from the web interface. The procedure Accessing the Troubleshooting Interface on page 8-35 provides instructions for accessing the screens. Standard Screens Anyone can access the screens described in this section. Status Screen The status screen is the index page, and can also be selected by choosing the Status link at any standard screen. The following is an example:
Note: The IP address and mask information is available only if you have entered the correct Password of the Day to access the advanced pages. The top section of this page provides the following information: Hardware and software revision System uptime Cable modem status
Troubleshooting
8-29
Number of computers on the LAN that the modem detected NIU serial number
The bottom section provides the names, MAC addresses, and status of each interface on the NIU. For subscriber-side data interfaces (Ethernet and USB), the page also reports interface speed in Mb/sec. HW/SW Versions Screen The Hardware/Software Versions screen provides information about the hardware and software revision levels. To display this screen, choose the HW/SW Versions link.
Event Log Screen The Event Log screen displays a table of recent events. The NIU stores the event log in non-volatile memory. To display this screen, choose the Event Log link.
8-30
Troubleshooting
Registration Status Screen The Registration Status screen shows the results of the NIU registration process and current battery telemetry state. To display this screen, choose the CM State link.
Advanced Screens
The following screens require a password of the day. Use the Basic link on any screen to return to the standard status pages. Note: Advanced screens contain potentially sensitive information about the network. Product Details Screen The Detailed Status screen provides the following information: NIU status IP and MAC address parameters system information, including enabled features
Troubleshooting
8-31
To access this screen, choose the Product link from any advanced screen.
8-32
Troubleshooting
DHCP Parameters The DHCP Parameters screen lists DHCP details for the cable modem and MTA portions of the MTA. To access this screen, choose the DHCP link from any advanced screen.
Troubleshooting
8-33
MTA Parameters Screen The MTA Parameters screen shows MTA-related communications parameters and the value of the Callp Feature switch. To access this screen, choose the MTA link from any advanced screen.
CallP/QoS Statistics Screen The Callp/QoS Statistics screen shows the MTA Callp state and QoS statistics. To access this screen, choose the CallP/QoS link from any advanced screen.
8-34
Troubleshooting
Conguration Parameters Screen The Conguration Parameters screen shows the values of common cable modem and MTA conguration parameters. To access this screen, use the Cong Params link from any advanced screen.
Note: The above screen is modied to show only partial cable modem and MTA parameters. An actual Conguration Parameters screen is likely to be very long.
Troubleshooting
8-35
Accessing the Troubleshooting Interface

Use this procedure to access the standard and advanced troubleshooting pages.
Access Options
You can access the troubleshooting screens through either the Touchstone Telephony product RF or Ethernet interfaces. You need the following equipment to access the troubleshooting pages: computer with an Ethernet interface and a web browser Ethernet cable (if using the NIU Ethernet interface) (advanced pages only) the password of the day
Requirements
Controlling Access to the Interface
The following MIBs control access to the basic and advanced troubleshooting pages.
arrisCmDevHttpLanAccess Values: off, basic, adv, until-registered
Determines which pages are available from the Ethernet port of the NIU. The value is stored in non-volatile memory.
arrisCmDevHttpWanAccess Values: off, basic, adv
Determines which pages are available from the network attached to the CMTS. The value is stored in non-volatile memory.
arrisCmDevClientSeed
Changing the seed changes the results of the Password of the Day (PWOD). See the Conguration Editor Users Guide, ARSVD00635, for details about the PWOD. Store the seed value in the CM conguration le.
8-36
Troubleshooting
arrisCmDevHttpAdvLink Values: Non-Restricted, Restricted
Determines whether the NIU shows a link to the advanced pages from the basic pages before the user enters the PWOD.
Non-Restricted shows links regardless of the password entered
(default).
Restricted shows only the links that are accessible with the last
password entered. Before entering the PWOD, the basic pages show no link to the advanced pages; the user must manually type in the URL address of an advanced page. Action Perform the following tasks as necessary. Task Page
Accessing the Standard Pages .................................... 8-36 Accessing the Advanced Pages................................... 8-37 Accessing the Standard Pages Follow these steps to access the standard troubleshooting pages.
1
Make sure the NIU is congured to allow access to the pages (see Controlling Access to the Interface on page 8-35). Obtain the cable modem IP address of the NIU. Note: If the NIU has not registered, you can access the pages only from the Ethernet interface. After registration, you can use either the RF or Ethernet interfaces. The Ethernet interface recognizes connections to the address 192.168.100.1, whether or not the modem has registered. To use this address, set your computers IP address to a similar address, such as 192.168.100.2.
Start your web browser and access the NIU. For example, you could use the address http://192.168.100.1/
Troubleshooting
8-37
Accessing the Advanced Pages
Follow these steps to access the advanced troubleshooting pages.

1 2
Perform steps 1 and 2 of Accessing the Standard Pages above. Obtain the Password of the Day from the PWOD tool. See the Conguration Editor Users Guide, ARSVD00635, for details about the PWOD tool. Start your web browser and access the NIU, using the address http://192.168.100.1/status.htm (replace the IP address shown with the cable modem IP address if desired). The NIU displays a web form that prompts you for the password.
Enter the Password of the Day in the web form and press Enter. The NIU displays the Product Details Screen shown on page 8-30.
8-38
Troubleshooting
Running Line Card Diagnostics

Use this procedure to manually initiate line card diagnostics on a Touchstone Telephony NIU line. Line card diagnostics check the following functionality: processor communication power/clock on-hook/off-hook functionality voice frequency ring
You start line card diagnostics by setting the ppSurvPortLcDiagRequest MIB that corresponds to the line to true. This MIB is found in the ppSurvPortTable, under the ARRIS-specic PACKETPORT-MIB. The NIU generates either a Voice Line Diag Passed or Voice Line Diag Failed log message to indicate whether the diagnostic succeeded or failed. You can query the ppSurvPortLcDiagLastResult MIB, also in the ppSurvPortTable, for the results of the last diagnostic run. The value is one of the following:
diagnostics-passed(1) slac-revision-failure(2) mpi-failure(3) power-or-clock-failure(4) pcm-failure(5) standby-hook-failure(6) active-hook-failure(7) vf-failure(8) ringing-failure(9) invalid-state-to-init-diags(10) line-is-unprovisioned(11) diagnostics-results-pending(12)
Troubleshooting
8-39
Action
Follow these steps to run line card diagnostics.

1
If the line that you want to test is in service, take the line out of service using the following steps:
a
In the NMS, select the NIU to test and locate the ppCfgPortTable for that device.
Select the entry in the ppCfgPortTable that corresponds to the line that you want to disable, and set the ppCfgPortAdminState MIB to oos.
In the NMS, select the NIU to test and locate the ppSurvPortTable for that device. Select the entry in the ppSurvPortTable that corresponds to the line that you want to test, and set the ppSurvPortLcDiagRequest MIB to true. The NIU starts running diagnostics on the line. While the NIU is running diagnostics, the ppSurvPortMaintState MIB for that line is set to either istrbl-diag(6) or oostrbl-diag(12).
Monitor the NMS fault management subsystem for a log message from, the NIU, indicating that diagnostics are nished. Restore the line to service, if necessary, by setting the ppCfgPortAdminState MIB back to is.
8-40
Troubleshooting
HomePNA Troubleshooting
Use this procedure to identify and correct problems with the HomePNA interface.
HomePNA Interface MIBs
You can use interface MIB counters to troubleshoot the HomePNA interface. These counters are described in detail in Interface MIBs on page 8-2. The following gure shows the location in the MIB tree for the Interface MIB and displays the counters available for HomePNA troubleshooting activities.
Troubleshooting
8-41
Using the Troubleshooting Interface
You can use the web-based troubleshooting interface to quickly determine the IfAdminStatus. The following gure shows that the provisioning column depicts the administrative status and that the state column depicts the operational status. For more information on the Web-based Troubleshooting Interface, see Web-based Troubleshooting Interface on page 8-28.
8-42
Troubleshooting
Verifying Connectivity
Most HomePNA devices have a link status light that indicates that the device is communicating properly and passing data. Connecting a device to the Touchstone Telephony Port should show activity and also set the operation status to up(1) (see Managing the HomePNA Interface on page 3-7). If the link status light does not show activity, follow these steps to perform initial troubleshooting.
1
Check the administrative status (IfAdminStatus) of the HomePNA interface, using a MIB browser or the web-based troubleshooting interface. Verify that the interface has not been disabled through the CM conguration le. Verify that the connected device supports (and is using) HomePNA 2.0 10M8. If the device is in a HomePNA 1.0-compatible mode (1M8), recongure the device to use 10M8. Verify that device drivers are properly installed (if required). Connect the device directly to another HomePNA station and proceed as follows: If the link status lights do not show activity, replace the device. If the device indicates an active connection to the other HomePNA device, then reconnect the rst device to the Telephony Port. Disconnect other phones or fax machines from line 1, one at a time, to determine whether they are interfering with the HomePNA connection. Adding lters can sometimes correct problems with certain devices.
4 5
9
Listing of Templates
Location of Template FIles MTA Conguration Files

9
The following is a list of example data and telephony provisioning le templates included with TS3.2. See the PacketACE Conguration Tools Users Guide, ARSVD00635, for more information about using the templates.
ARRIS may update these templates when updating PacketACE or Touchstone software, so you should keep your own templates in a separate directory. The following templates are provided (additional templates may be added in later releases). The PacketACE installer places template les in the directory
C:\Program Files\ARRIS\PacketACE\ACE_Templates
The following is a list of example MTA conguration les included with PacketACE.
ARRIS_proprietary_mibs.mta
Provides default values for all ARRIS proprietary MIBs.

PCABLE_mandatory_params.mta
Mandatory PacketCable parameters.

PCABLE_mandatory_params_2line.mta
Mandatory PacketCable parameters for a Touchstone Telephony Modem.

PCABLE_mandatory_params_4line.mta
Mandatory PacketCable parameters for a Touchstone Telephony Port.
9-2
TS0302_2line.mta
Basic conguration for a Touchstone Telephony Modem using TS3.2.

TS0302_4line.mta
Basic conguration for a Touchstone Telephony Port using TS3.2. Cable Modem Conguration Files The following is a list of example MTA conguration les included with PacketACE.
DOCSIS10_mandatory_params.cm
Mandatory parameters for a DOCSIS 1.0 compatible cable modem.



TCM_CVC.cm
Cable modem conguration that uses a secure download.

TCM_http_basic_CVC.cm
Cable modem conguration that uses a secure download and enables the Touchstone cable modem troubleshooting interface.
TS0302_docsis10.cm
Basic conguration for a Touchstone NIU, congured as a DOCSIS 1.0 cable modem, using TS3.2.
TS0302_docsis11.cm
TS0302_docsis11_EUCVC.cm
Conguration for a Touchstone NIU, congured as a DOCSIS 1.1 cable modem, using TS3.2 with a secure download (European load).
TS0302_docsis11_NACVC.cm
Conguration for a Touchstone NIU, congured as a DOCSIS 1.1 cable modem, using TS3.2 with a secure download (North American load).
9-3
TS0302_docsis11_http_basic.cm
Basic conguration for a Touchstone NIU, congured as a DOCSIS 1.1 cable modem, with the basic troubleshooting interface enabled.
TS0302_docsis11_http_off.cm
Basic conguration for a Touchstone NIU, congured as a DOCSIS 1.1 cable modem, with the troubleshooting interface disabled.
TS0302_docsis20.cm
_TS0302_CPS.cm
Touchstone NIU conguration using the CPS provisioning mode.

_TS0302_DocsisOnly.cm
Touchstone NIU conguration using the DOCSIS provisioning mode.

_TS0302_FullPcable.cm
Touchstone NIU conguration using the Full PacketCable provisioning mode.

_TS0302_GUPI.cm
Touchstone NIU conguration using the GUPI provisioning mode.

_TS0302_PcableMinusKDC.cm
Touchstone NIU conguration using the PacketCable (no KDC) provisioning mode.
_TS0302_SingleMac_2line.cm
Touchstone Telephony Modem conguration using the single MAC/single conguration le provisioning mode.
_TS0302_SingleMac_4line.cm
Touchstone Telephony Port conguration using the single MAC/single conguration le provisioning mode.
9-4
Text Files
The following is a list of text les in the ACE_Templates directory. You can import them into a conguration le to add specic features.
ARRIS_proprietary_mibs.txt A text version of the ARRIS_proprietary_mibs.mta le. EUCVC.txt
European CVC.
NACVC.txt
North American CVC.
9-5
SNMP Co-existence Example Conguration File

The following listing shows the MIBs and TLVs necessary to implement SNMP co-existence. The conguration is based on a minimal DOCSIS 1.1 cable modem conguration le.
NetworkAccess = 1 UpstreamServiceFlow = SfReference = 1 SfQosSetType = 7 SfSchedulingType = 2 DownstreamServiceFlow = SfReference = 2 SfQosSetType = 7 PrivacyEnable = 0 SnmpMib = snmpCommunityName.comm1 "my_password" SnmpMib = snmpCommunitySecurityName.comm1 "rwAccess" SnmpMib = snmpCommunityStorageType.comm1 volatile SnmpMib = snmpCommunityStatus.comm1 createAndGo SnmpMib = vacmGroupName.1 rwAccess "rwAccess" SnmpMib = vacmSecurityToGroupStorageType.1 rwAccess volatile SnmpMib = vacmSecurityToGroupStatus.1 rwAccess createAndGo SnmpMib = vacmGroupName.2 rwAccess "rwAccess" SnmpMib = vacmSecurityToGroupStorageType.2 rwAccess volatile SnmpMib = vacmSecurityToGroupStatus.2 rwAccess createAndGo SnmpMib = vacmAccessContextMatch.rwAccess 1 1 exact SnmpMib = vacmAccessReadViewName.rwAccess 1 1 "docsisManagerView" SnmpMib = vacmAccessWriteViewName.rwAccess 1 1 "docsisManagerView" SnmpMib = vacmAccessNotifyViewName.rwAccess 1 1 "docsisManagerView" SnmpMib = vacmAccessStorageType.rwAccess 1 1 volatile SnmpMib = vacmAccessStatus.rwAccess 1 1 createAndGo SnmpMib = vacmAccessContextMatch.rwAccess 2 1 exact SnmpMib = vacmAccessReadViewName.rwAccess 2 1 "docsisManagerView" SnmpMib = vacmAccessWriteViewName.rwAccess 2 1 "docsisManagerView" SnmpMib = vacmAccessNotifyViewName.rwAccess 2 1 "docsisManagerView" SnmpMib = vacmAccessStorageType.rwAccess 2 1 volatile SnmpMib = vacmAccessStatus.rwAccess 2 1 createAndGo SNMPv3NotificationReceiver = SNMPv3NrIpAddress = 10.1.50.100 SNMPv3NrTrapType = 1 SNMPv3NotificationReceiver = SNMPv3NrIpAddress = 10.1.50.80 SNMPv3NrTrapType = 2
9-6
10
Appendix B: Conguring the Service Provider Root

10
PacketCable requires a Service Provider certicate hierarchy, which allows other network elements to authenticate the service provider's servers. The following gure shows the hierarchy.
CableLabs Service Provider Root CA
Service Provider CA
Local System Operator CA
DF Certificate
KDC Certificate
Other Certificate
The CableLabs Service Provider Root CA issues certicates only to authorized MSOs or Service Providers. This creates a problem for vendors or manufacturers who need to interoperate with the KDC and cannot obtain a Service Provider CA certicate under this root. One solution is to create a test root hierarchy and use it instead of the real root hierarchy for the purpose of lab testing. The MTA is manufactured with the CableLabs Service Provider Root certicate in order to verify and validate the certicates obtained in the AS_Reply message from the
10-2
KDC. In the case where the KDC is congured with a test root, the MTA must also be congured with the same test root.
Service Provider Root Provisioning for Touchstone Telephony Modems

Touchstone Software versions prior to TS3.2 embedded the IPFonix test root digital certicate. TS3.2 software embeds the ofcial PacketCable test root digital certicate from CableLabs, Inc. TS3.2 can support networks using the IPFonix test root digital certicate or MSO-generated test root digital certicates by allowing any valid test root certicate to be downloaded from a specied TFTP location. Three MIBs (described in MIBs below) control this support. The capability to download the certicates includes a retry mechanism to allow automatic recovery in the event of failure to download the certicate from the server. This mechanism retries the download 16 times, then waits for a period of time before retrying the download. The cycle repeats three times, and then the Telephony Modem resyncs and starts the conguration process over again. During this process, the Telephony Modem generates download retry/failure logs, described in Certicate Downloading Logs on page 5-8. CAUTION Service affecting If the Telephony Modem is congured to use secure downloading, the Telephony Modem does not restart the provisioning cycle and thus does not provide service.
MIBs
The CM conguration le transports the Service Provider Root MIBs to the Telephony Modem. Once the device has rebooted and downloaded the CM conguration le, then the Telephony Modem uses its private MIBs to determine how to proceed. There are three ARRIS private MIBs that can be set in the CM conguration le:
ppCfgMtaDevSPTestRootCertAdminStatusinstructs the Telephony Modem to either use the embedded test root or download and use a test root certicate from a TFTP server ppCfgMtaDevSPTestRootCertServerfor the download
option, this MIB species the IP address of the TFTP server containing the root certicate le
10-3
ppCfgMtaDevSPTestRootCertFilenamefor the download
option, this MIB species the le name on the TFTP server that contains the test root certicate The ppCfgMtaDevSPTestRootDownloadState MIB displays the status of the download, if the download option is chosen. Following is the denition of the MIBs:
ppCfgMtaDevServiceProviderTestRootCert OBJECT IDENTIFIER ::= { ppCfgMtaDevSecurity 1 } ppCfgMtaDevSPTestRootCertServer OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The IP address of the TFTP server used for downloading Service Provider Test Root Certificates to this device. Returns 0.0.0.0 if the TFTP server address is unknown or unassigned. This object can only be changed by the configuration file." ::= { ppCfgMtaDevServiceProviderTestRootCert 1 }
ppCfgMtaDevSPTestRootCertFilename OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The file name of the Service Provider Test Root Certificate to be downloaded to this device from the TFTP server. Returns an empty string if the certificate filename is unknown or unassigned. This object can only be changed by the configuration file." ::= { ppCfgMtaDevServiceProviderTestRootCert 2 }
ppCfgMtaDevSPTestRootCertAdminStatus OBJECT-TYPE SYNTAX INTEGER { ignoreCertSettings(0), useEmbeddedTestRootCert(1), downloadTestRootCert(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Controls the usage of Root Certificates by the MTA device. If set to downloadTestRootCert(2), the MTA will download the Service Provider Test Root Certificate specified by 'ppCfgMtaDevSPTestRootCertFilename' from the TFTP server
10-4
specified by 'ppCfgMtaDevSPTestRootCertServer'. If set to useEmbeddedTestRootCert(1), the MTA will use the factory-installed Test Root Certificate embedded in the device. If the value of this object is ignoreCertSettings(0), all of the Test Root Certificate settings (i.e. TestRootCertServer, TestRootCertFilename) are ignored and the MTA will, by default, use the factory-installed Real Root Certificate embedded in the device. This object can only be changed by the configuration file. At initial startup, this object has a default value of ignoreCertSettings(0)." DEFVAL { ignoreCertSettings } ::= { ppCfgMtaDevServiceProviderTestRootCert 3 } ppCfgMtaDevSPTestRootDownloadState OBJECT-TYPE SYNTAX INTEGER { noDownload(0), downloadRequested(1), inProgress(2), completed(3), failed(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the current state of the Service Provider Test Root Certificate download process. noDownload(0) indicates that no certificate download has been requested. downloadRequested(1) indicates a Test Root Certificate download is desired, most likely as a result of a downloadTestRootCert request. inProgress(2) indicates that a TFTP download is underway. completed(3) indicates that the last Test Root Certificate download was completed successfully. failed(4) indicates that the last attempted download failed. At initial startup, this object has a default value of noDownload(0)." DEFVAL { noDownload } ::= { ppCfgMtaDevServiceProviderTestRootCert 4 }
Using the default embedded root To use the embedded real root, which is the default factory setting, either remove the ppCfgMtaDevSPTestRootCertAdminStatus from the CM conguration le, or set it to ignoreCertSettings. Using the embedded test root Select the embedded test root by setting the ppCfgMtaDevSPTestRootCertAdminStatus to useEmbeddedTestRootCert. The ppCfgMtaDevSPTestRootCertFilename and ppCfgMtaDevSPTestRootCertServer MIBs are ignored. Using the downloadable test root feature
10-5
Download a test root to the MTA by setting the ppCfgMtaDevSPTestRootCertAdminStatus to downloadTestRootCert. Set ppCfgMtaDevSPTestRootCertServer to the IP address of the TFTP server and ppCfgMtaDevSPTestRootCertFilename to the le name. If the le name or the IP address of the TFTP server are missing or invalid, the download fails. The certicate must use the X.509 DER-encoded format.
10-6
11
Overview

11
This appendix describes how to congure the NIU to control (restrict) SNMP access to the cable modem MIB objects by Network Management Stations (NMS) and also how to congure the transmission of notications (traps) on the cable modem.
Touchstone NIUs support the following SNMP modes: SNMPv1, SNMPv2c, and SNMPv3 as well as SNMP-coexistence ([RFC 2567]). The contents of the CM conguration le determines the NIUs SNMP mode after registration: The CM runs in NmAccess mode if the CM conguration le contains only docsDevNmAccessTable settings. With these settings, SNMP access is controlled by the entries in the docsDevNmAccessTable. The CM runs in SNMP coexistence mode if the CM conguration le contains any of the following: any snmpCommunityTable settings any TLV type 34.1 and 34.2 (SNMPv3 Kickstart User) elements any TLV type 38 (SNMPv3 Notication Receiver) elements In SNMP coexistence mode, any conguration le entries made to the docsDevNmAccessTable are ignored. If the conguration le does not contain any SNMP access control items (no docsDevNmAccessTable or snmpCommunityTable settings and no TLV 34.1/34.2 or TLV 38 elements, then the CM runs in NmAccess mode and SNMP access to MIB objects is unrestricted.
The rules for each SNMP access mode are described below.
11-2
SNMPv1/v2c NmAccess Mode
The following rules apply in NmAccess mode: Only SNMPv1/v2c packets are processed. SNMPv3 packets are dropped. The docsDevNmAccessTable controls access and trap destinations as described in [RFC 2669]. None of the SNMPv3 MIBs as dened in [RFC 2571] through [RFC 2576] are accessible.
SNMP Coexistence Mode
The following rules apply in SNMP Coexistence mode: SNMPv1/v2c/v3 Packets are processed as described by [RFC 2571] and [RFC 2576]. The docsDevNmAccessTable is not accessible. Access control and trap destinations are determined by the snmpCommunityTable, Notication MIB, Target MIB, VACM-MIB, and USM-MIB. The Community MIB controls the translation of the SNMPv1/ v2c packet community string into a security name that selects entries in the USM MIB. Access control is provided by the VACM MIB. The USM MIB and VACM MIB controls SNMPv3 packets. Trap destinations are specied in the Target MIB and Notication MIB.
SNMP Coexistence Types
There are three different types of SNMP coexistence that can be congured. SNMPv1/v2c-only Coexistence SNMPv1/v2c coexistence takes effect if the conguration le contains: Any TLV-11 Coexistence Settings (i.e. snmpCommunityMIB, vacmSecurityToGroupTable, vacmAccessTable) OR Any SNMPv3 Notication Receiver (TLV-38) elements and no SNMPv3 Kickstart (TLV-34) elements.
The cable modem only accepts SNMPv1/v2c packets in this mode.
11-3
SNMPv1/v2c/v3 Coexistence SNMPv1/v2c/v3 coexistence takes effect if the conguration le contains all of the following: Any TLV-11 Coexistence Settings (i.e. snmpCommunityMIB, vacmSecurityToGroupTable, vacmAccessTable) any SNMPv3 Kickstart (TLV-34) elements
The cable modem accepts SNMPv1/v2c/v3 packets in this mode. SNMPv3 only coexistence SNMPv3 coexistence takes effect if the conguration le contains both: Any SNMPv3 Kickstart (TLV-34) elements NO coexistence settings
The cable modem only accepts SNMPv3 packets in this mode.
Conguring the Cable Modem for NmAccess Mode

When the CM is in SNMPv1/v2c docsDevNmAccess mode, the docsDevNmAccessTable controls SNMP access and SNMP trap destinations as described in the DOCS-CABLE-DEVICE-MIB [RFC 2669]. There are several different ways in which the table can be congured depending on what type of SNMP access and trap ltering you want to apply to the modem. This section describes a basic setup. Conguring SNMP access with the docsDevNmAcces sTable The simplest way to congure the SNMP access lteringwhere you just want to congure a user-dened community string for accessis to create one or more docsDevNmAccessTable entries within the cable modem conguration le (You can create up to a maximum of 32 NmAccess entries on Arris CM devices: CM300, CM450, TTM, TTP, etc.). A table row can be created by setting the docsDevNmAccessStatus object to a value of createAndGo(4) and the docsDevNmAccessCommunity object to a user-dened community string, say for example, my_password. This creates an entry in the table with the following default parameters. This entry will allow read-only SNMP access to the CM from any NMS using a community string of my_password:
docsDevNmAccessIp.1 (ipaddress) = 255.255.255.255 docsDevNmAccessIpMask.1 (ipaddress) = 0.0.0.0 docsDevNmAccessCommunity.1 (octet string) = my_password /* Your password, use whatever string you like. */
11-4
docsDevNmAccessControl.1 (integer) = read(2) /* Allow readonly access */ docsDevNmAccessInterfaces.1 (octet string) = FF (hex) /* Allow access from all interfaces of the cable modem */ docsDevNmAccessStatus.1 (integer) = active(1) /* createAndGo(4) will automatically go to active(1) */ docsDevNmAccessTrapVersion.1 (integer) = DisableSNMPv2trap(1)
Note: The other objects of the table row entry are set to their default values unless you also add them to the conguration le. The .1 is the instance (or index) value of this particular table entry. It does not have to be a 1, it can be any number you choose. You can create as many different entries in the conguration le as you like (up to the maximum of 32), depending on how you want to setup the SNMP Access ltering. The above description is a basic setup, but you can congure the NmAccess entry in additional ways. Just as an example, you can allow read and write access for the above entry by setting the docsDevNmAccessControl object to readWrite(3) in the conguration le. You can also congure which of the modems interfaces you want to grant access to by changing the docsDevNmAccessInterfaces object accordingly (see below), etc. The section below describes how to setup trap transmission using the docsDevNmAccessTable. Conguring Trap Transmission with the docsDevNmAcces sTable To enable trap transmission, three objects in the docsDevNmAccessTable MUST be congured to specic values. These three objects are: docsDevNmAccessIp, docsDevNmAccessIpMask, and docsDevNmAccessControl. A fourth object, docsDevNmAccessTrapVersion can optionally be congured to enable or disable SNMPv2 traps. It the TrapVersion object is not congured then its value will just default to DisableSNMPv2trap(1) and SNMPv1 traps will be sent for that particular row entry. Note: DisableSNMPv2trap(1) may show up as version(1) in the Conguration Editor. For trap transmission, the relevant objects, highlighted in bold, MUST be congured as shown below:
docsDevNmAccessIp.15 (ipaddress) = (IP address of your Trap server) docsDevNmAccessIpMask.15 (ipaddress) = 255.255.255.255 docsDevNmAccessCommunity.15 (octet string) = (any community string) /* Default community string */ docsDevNmAccessControl.15 (integer) = roWithTraps(4) or rwWithTraps(5) /* Allow traps to be sent */ docsDevNmAccessInterfaces.15 (octet string) = FF (hex) /* Allow access from all interfaces of the cable modem */ docsDevNmAccessStatus.15 (integer) = createAndGo(4)
11-5
docsDevNmAccessTrapVersion.15 (integer) EnableSNMPv2trap(2)
= DisableSNMPv2trap(1) or
You can congure multiple NmAccess entries for trap transmission if, for example, you have several different trap servers that you want your modem to send traps to. Rules for the docsDevNmAcces sTable Below is a brief overview of each of the MIB objects that comprise a row entry in the docsDevNmAccessTable. docsDevNmAccessIp and docsDevNmAccessIpMask If the docsDevNmAccessTable is used for SNMP access ltering, the following rules are applied in order to determine whether to permit SNMP access from a given source IP address (SrcIpAddr): 1 2 3 If (docsDevNmAccessIp == 255.255.255.255), the CM permits SNMP access from any SrcIpAddr. If (docsDevNmAccessIpMask == 0.0.0.0), the CM permits SNMP access from any SrcIpAddr. If ((docsDevNmAccessIp AND docsDevNmAccessIpMask) == (SrcIpAddr AND docsDevNmAccessIpMask)), the CM permits SNMP access from SrcIpAddr. If neither #1 nor #2 is applied, the CM denies SNMP access from SrcIpAddr.
The CMs default value of the docsDevNmAccessIpMask is set to 0.0.0.0. The following table contains sample MIB values and the access granted.
docsDevNmAccessIp docsDevNmAccessIpMask Access
255.255.255.255 Any IP address Any IP address except 255.255.255.255 0.0.0.0 IP address of IP subnet
Any IP address mask 0.0.0.0 255.255.255.255 255.255.255.255 Netmask of the subnet
Any NMS Any NMS Single NMS No NMS A subnet group of NMS
docsDevNmAccessCommunity If this object is set to a zero-length string, then any community string will match.
11-6
The value of this object will not show up in MIB walks of the docsDevNmAccessTable.
Default value: public Note: When read, this object returns a zero-length string, no matter what value it contains. docsDevNmAccessControl Value list: none(1)destroys this table row entry read(2)default readWrite(3) roWithTraps(4) rwWithTraps(5) trapsOnly(6)
Default value: read(2). Setting the value of this object to none(1) will cause the table row entry to be destroyed. An SNMP Walk on the docsDevNmAccessTable requires ReadWrite access to succeed. Therefore, if this value is set to read(2) or roWithTraps(4), then the docsDevNmAccessTable is not accessible using the community string that is associated with this docsDevNmAccessControl entry. In order for traps to be enabled for the associated row entry, this object must have a value of roWithTraps(4), rwWithTraps(5), or trapsOnly(6).
docsDevNmAccessInterfaces This object species the set of interfaces from which requests from this NMS will be accepted. Each octet within the value of this object species a set of eight interfaces, with the rst octet specifying interfaces 1 through 8, the second octet specifying interfaces 9 through 16, etc. Within each octet, the most signicant bit represents the lowest numbered interface, and the least signicant bit represents the highest numbered interface. Thus, each interface is represented by a single bit within the value of this object. If that bit has a value of 1 then that interface is included in the set. Default value: 0xFF
11-7
Note that entries in this table apply only to link-layer interfaces (e.g., Ethernet and CATV MAC). Upstream and downstream channel interfaces must not be specied. In the CM, the interfaces are numbered as follows:
Interface Type
1 2 3 4 5 5+n
Primary CPE Interface (Ethernet Interface) CATV-MAC (RF Interface) RF Upstream RF Downstream Secondary CPE Interface (USB Interface) Other Interfaces
Here is how the bitmask looks for the docsDevNmAccessInterfaces object:

27 Ethernet RF 26 25 RF U/S 24 RF D/S 23 USB 22 21 20
Following are examples of typical settings for the docsDevNmAccessInterfaces object:

Value (hex) Description
Most common settings FF C0 80 40 Other settings 08 48 88 C8 USB Interface only RF + USB Ethernet + USB Ethernet + RF + USB Apply to all interfaces (Default value) Ethernet Interface + RF Interface Ethernet Interface only RF Interface only
docsDevNmAccessStatus If this object is congured in the CMs conguration le, then it should have a value of createAndGo(4) or createAndWait(5). If set to createAndGo(4) in the conguration le, the value of this object automatically changes to active(1) upon successful creation of the row entry and the row entry becomes active. If set to createAndWait(5) in
11-8
the conguration le, the value of this object automatically changes to notInService(2) and the associated row entry becomes inactive. docsDevNmAccessTrapVersion This object species the trap version.
version1(1)send SNMPv1 traps (default) version2(2)send SNMPv2 traps
Note that the values for this object may show up as DisableSNMPv2trap(1) for version1(1) and EnableSNMPv2trap(2) for version2(2).
Conguring the CM for Coexistence Mode

When the CM is in coexistence mode, SNMP access and SNMP trap destinations are processed within the context of the SNMPv3 protocol architecture as dened in the SNMPv3 MIBs [RFC 2571] through [RFC 2576]. Any one of the three coexistence modes (v1/v2c only, v1/v2/v3, or v3 only) can be congured by using various combinations of the following elements in the conguration le: TLV-11 MIB settings to the snmpCommunityMIB, vacmSecurityToGroupTable, and vacmAccessTable SNMP Notication Receiver element (TLV-38) SNMP Kickstart User element (TLV-34)
The particular coexistence mode is determined as described in Overview on page 11-1. Conguring SNMPv1/v2c only coexistence Conguring the modem in SNMPv1/v2c only coexistence mode allows you to use a simple community string within the context of SNMPv3 USM security to access the CMs MIBs. This mode of coexistence makes use of the snmpCommunityTable, which is dened in the snmpCommunityMIB. The snmpCommunityTable contains objects that allow you to map a community string into the following SNMPv3 message parameters: securityName contextEngineID contextName
11-9
The snmpCommunityTable, in combination with the vacmSecurityToGroupTable, and the vacmAccessTable, permits coexistence. The coexistence settings can be congured in numerous different ways. For detailed information of their operation, refer to the SNMPv3 MIB RFCs [RFC 2571] through [RFC 2576]. Following is a basic coexistence example that congures two SNMPv1/ v2c community strings, which will map to the DOCSIS-dened SNMPv3 security user: docsisManager. The snmpCommunityTable is congured with the following community strings: 1) a read/write community string, which will provide full read-write access to the entire MIB tree and 2) a read-only community string, which will provide read-only access to the MIB tree.
snmpCommunityTable, Indexed by snmpCommunityIndex

Table Index rw ro
snmpCommunityIndex (I) snmpCommunityName snmpCommunitySecurityName snmpCommunityContextEngineID snmpCommunityContextName
rw readwrite rwAccess
ro readonly roAccess
local snmpEngineID local snmpEngineID (zero-length) (zero-length) (zero-length) volatile(2) createAndGo(4)
snmpCommunityTransportTag (zero-length) snmpCommunityStorageType snmpCommunityStatus volatile(2) createAndGo(4)
(I) indicates this object is an index value.
Italics indicates that this value is the Default value of the MIB object. How it Works When an SNMPv1 (or SNMPv2c) Request (GET or SET) is received by the modem, each row within the snmpCommunityTable will be looked at until a matching row is found or all the rows have been searched. If no matching rows are found, then the request will result in an authorization failure and the SNMP Request will be rejected. In order for a row to match, the snmpCommunityName must rst match the community name contained within the SNMP Request message.
11-10
If the community name matches a row in snmpCommunityTable, then the snmpCommunitySecurityName for that row is next compared against the vacmSecurityName entries in the vacmSecurityToGroupTable. vacmSecurityToGroupTable, Indexed by vacmSecurityModel, vacmSecurityName
Table Index 1.roAccess 1.rwAccess 2.roAccess 2.rwAccess
vacmSecurityModel (I) vacmSecurityName (I) vacmGroupName
1 (SNMPv1) roAccess roAccess
1 (SNMPv1) rwAccess rwAccess volatile(2)
2 (SNMPv2) roAccess roAccess volatile(2)
2 (SNMPv2) rwAccess rwAccess volatile(2)
vamSecurityToGroupStorage- volatile(2) Type vamSecurityToGroupStatus
createAndGo(4) createAndGo(4) createAndGo(4) createAndGo(4)
(I) indicates this object is an index value. Italics indicates that this value is the Default value of the MIB object.
If an entry is found with a vacmSecurityName that matches the snmpCommunitySecurityName, then the corresponding group name (vacmGroupName) for that row entry is used in the vacmAccessTable to determine if MIB access is allowed for that community string. In order for SNMP GET-Requests to be allowed, the vacmAccessReadViewName must be valid. In order for SNMP SET-Requests to be allowed, the vacmAccessWriteViewName must be valid. In order for SNMP Trap messages to be allowed, the vacmAccessNotifyViewName must be valid. The docsisManagerView entry is a pre-congured default DOCSISdened MIB access view that allows full read, write, and notify access to the modems entire MIB tree. vacmAccessTable, Indexed by vacmGroupName, vacmAccessContextPrex, vacmAccessSecurityModel, vacmAccessSecurityLevel
Table Index roAccess.[].1.1 roAccess.[].2.1 rwAccess.[].1.1 rwAccess.[].2.1
vacmAccessContextPrex (I)
1 (SNMPv1) 1 (noAuthnoPriv) exact(1) docsisManagerView
vacmAccessSecurityModel (I) 1 (SNMPv1) vacmAccessSecurityLevel (I) vacmAccessContextMatch vacmAccessReadViewName 1 (noAuthnoPriv) exact(1) docsisManagerView
11-11
vacmAccessTable, Indexed by vacmGroupName, vacmAccessContextPrex, vacmAccessSecurityModel, vacmAccessSecurityLevel

Table Index roAccess.[].1.1 roAccess.[].2.1 rwAccess.[].1.1 rwAccess.[].2.1
vacmAccessWriteViewName
docsisManagerView volatile(2)
docsisManagerView docsisManagerView volatile(2)
docsisManagerView docsisManagerView volatile(2)
vacmAccessNotifyViewName docsisManagerView vacmAccessStorageType vacmAccessStatus volatile(2)
createAndGo(4) createAndGo(4) createAndGo(4) createAndGo(4)
(I) indicates this object is an index value. indicates a (zero-length) string Italics indicates that this value is the Default value of the MIB object.
Conguring SNMPv1/v2c/v3 coexistence
The conguration of SNMPv1/v2c/v3 coexistence is the same as v1/ v2c only coexistence above, but with the addition of the TLV 34 (SNMP Kickstart User) element in the conguration le. The SNMP Kickstart User element is added to the conguration le in order to kickstart SNMPv3 initialization and Dife-Helman Key Change calculations. A description of the TLV 34 element follows. SnmpV3 Kickstart Value The following TLV and its sub-elements are placed in the modems conguration le to kickstart SNMPv3 access to the modem.
Type Length Value
34
Composite
Up to 5 of these objects may be included in the conguration le. Each results in an additional row being added to the usmDHKickstartTable and the usmUserTable and results in an agent public number being generated for those rows. SnmpV3 Kickstart Security Name
Type Length Value
34.1
2 to 16
UTF8 Encoded security name
Normally, this will be specied as one of the DOCSIS built-in USM users, e.g., docsisManager, docsisOperator, docsisMonitor, docsisUser.
11-12
This object is reported in the usmDHKickStartTable as usmDHKickStartSecurityName and in the usmUserTable as usmUserName and usmUserSecurityName. SnmpV3 Kickstart Manager Public Number
Type Length Value
34.2
Managers Dife-Helman public number expressed as an octet string.
This number is the Dife-Helman public number derived from a privately (by the NMS or operator) generated random number and transformed according to [RFC-2786]. This is reported in the usmDHKickStartTable as usmKickstartMgrPublic. When combined with the object reported in the same row as usmKickstartMyPublic, it can be used to derive the keys in the related row in the usmUserTable. Example: Adding a TLV-34 element in PacketACE
11-13
11-14
Conguring SNMPv3 only coexistence Conguring Trap Transmission within Coexistence Mode
To congure SNMPv3 only coexistence, enter the TLV 34 (SNMP Kickstart User) element in the conguration le and NO Coexistence MIB settings in the conguration le. There are two ways to congure traps for coexistence mode: Through the conguration le Through SNMP
The simplest way to congure traps is to add the SNMPv3 Notication Receiver element to the CM conguration le. Below is a description of this element: SNMPv3 Notication Receiver cong le element (TLV-38) The SNMPv3 Notication Receiver TLV is used to easily congure SNMPv3 tables for notication (i.e. trap) transmission. The TLV species a Network Management Station (NMS) that will receive notications (traps) from the modem when the modem is in Coexistence mode. Up to 10 of the TLV-38 elements may be included in the conguration le.
11-15
Note: The CM will process this TLV only if the CM is in Coexistence mode.
Type Length Value
38
composite
Note: If using the TLV-38 element in the conguration le, the only two sub-TLVs that MUST be present are 38.1 (IP Address) and 38.3 (Trap Type). All of the other sub-TLVs will be congured to their default values if they are not present. SNMPv3 Notication Receiver IP Address This sub-TLV species the IP address of the notication receiver.
Type Length Value
38.1
ip1,ip2,ip3,ip4
SNMPv3 Notication Receiver UDP Port Number This sub-TLV species the UDP port number of the notication receiver. If this sub-TLV is not present, the default value of 162 should be used.
Type Length Value
38.2
UDP port number
SNMPv3 Notication Receiver Trap Type

Type Length Value
38.3
trap value
This sub-TLV species the type of trap to send. The trap type may take the following values: 1 2 3 4 5 SNMP v1 trap in an SNMP v1 packet SNMP v2c trap in an SNMP v2c packet SNMP inform in an SNMP v2c packet SNMP v2c trap in an SNMP v3 packet SNMP inform in an SNMP v3 packet
11-16
SNMPv3 Notication Receiver Timeout This sub-TLV species the timeout value to use when sending an Inform message to the notication receiver.
Type Length Value
38.4
time in milliseconds
SNMPv3 Notication Receiver Retries This sub-TLV species the number of times to retry sending an Inform message if an acknowledgement is not received.
Type Length Value
38.5
number of retries
SNMPv3 Notication Receiver Filtering Parameters This sub-TLV species the Object Identier of the snmpTrapOID value that identies the notications to be sent to the notication receiver. SNMP V3 allows the specication of which Trap OIDs are to be sent to a trap receiver. This object species the OID of the root of a trap lter sub-tree. All Traps with a Trap OID contained in this trap lter sub-tree will be sent to the trap receiver.
Type Length Value
38.6
lter OID
SNMPv3 Notication Receiver Security Name This sub-TLV species the V3 Security Name to use when sending a V3 Notication. This sub-TLV is only used if the Trap Type is set to 4 or 5. This name must be a name specied in a conguration le TLV Type 34 as part of the DH Kickstart procedure. The notications will be sent using the Authentication and Privacy Keys calculated by the modem during the DH Kickstart procedure. This sub-TLV is not required for Trap Type = 1, 2, or 3. If it is not supplied for a Trap type of 4 or 5, then the V3 Notication will be sent in the noAuthNoPriv security level using the security name @cong.
Type Length Value
38.7
security name
Based on the contents of the TLV, the CM will create entries in the following tables in order to setup the desired trap transmission: snmpNotifyTable, snmpCommunityTable, usmUserTable, vacmSecurityToGroupTable, vacmAccessTable, and vacmViewTreeFamilyTable.
11-17
Example Conguration Following is an example conguration of three TLV-38 Notication elements. Note 1: Note: The TrapOID for DOCSIS events is: 1.3.6.1.2.1.69.2.1.2.0 ( = docsDevCmTraps) Note 2: The TrapOID for PacketCable/Arris-proprietary MTA events is: 1.3.6.1.4.1.4491.2.2.3.6.0.2 ( = pktcDevEvTrap)
// Send DOCSIS events to IP Addr: 192.168.78.99 as SNMPv2 traps IP Address (38.1) = 192.168.78.99 Trap Type (TLV 38.2) = 2 Filtering Parameters (TLV 38.6) = 1.3.6.1.2.1.69.2.1.2.0 // Send PacketCable and Arris-proprietary MTA events to IP Addr: 192.168.78.100 //as SNMPv1 traps IP Address (TLV 38.1) = 192.168.78.100 Trap Type (TLV 38.2) = 1 Filtering Parameters (TLV 38.6) = 1.3.6.1.4.1.4491.2.2.3.6.0.2 // Send PacketCable and Arris-proprietary MTA events to IP Addr: 192.168.78.150 //as SNMPv2 traps IP Address (TLV 38.1) = 192.168.78.150 Trap Type (TLV 38.2) = 2 Filtering Parameters (TLV 38.6) = 1.3.6.1.4.1.4491.2.2.3.6.0.2
XXX TODO: ADD PacketACE example/screenshots here after PacketACE bugs are xed XXX Example: Adding a TLV-38 element in PacketACE
11-18
11-19
11-20
12
Overview
Appendix D: Conguring SNMP Coexistence

12
TS3.2 software uses several SNMPv3 security-related features. SNMP Co-existence is a feature that allows SNMPv1 and SNMPv2c network management systems to function within the context of SNMPv3 security and view-based MIB access. The NMS can use an SNMPv1 or SNMPv2 community string to access the NIUs MIBs or to receive traps. The procedures in this chapter provide details on adding the necessary MIBs and TLVs to a cable modem conguration le. See SNMP Coexistence Example Conguration File on page 9-5 for a listing of the completed conguration le.
The procedures in this appendix use the ARRIS PacketACE Conguration Editor to create the conguration le, covering only the details needed to add the desired functionality. See the PacketACE Conguration Tools Users Guide, ARSVD00635, for more information about using PacketACE. Conguration File Notes Keep the following notes in mind when creating or editing conguration les. A MIB object whose type is StorageType must always have a value of volatile. A MIB object whose type is RowStatus should have a value of createAndGo. The NIU automatically changes its value to active after successfully adding the row.
12-2
SNMP Access Mode
The following examples congure SNMP access to the NIU for SNMPv1v2c coexistence mode. This allows an NMS (i.e. a MIB Browser) to access the NIU's MIBs with a simple community string using either SNMPv1 or SNMPv2. The SNMP requests GET, GET-NEXT, and SET are all supported. The examples use the community name my_password.
SNMP Trap Transmission
SNMP trap transmission uses the DOCSIS TLV-38 (SNMPv3 Notication Receiver) conguration le element. The example congures two trap destinations, each with a different IP address. One destination supports SNMPv1 traps and the other destination supports SNMPv2 traps. The parameters for each trap destination are: Trap destination #1: IP Address: 10.1.50.100 Trap Type: SNMPv1 Trap destination #2: IP Address: 10.1.50.80 Trap Type: SNMPv2
Note: When you create your own specic conguration file, you need to change the trap IP address to the IP address of your specic trap server.
12-3
Conguring SNMP Co-existence

To congure the NIU for coexistence mode, you must create row entries in the following MIB tables:
snmpCommunityTableone row entry, to map the community string to an SNMPv3 security name. vacmSecurityToGroupTabletwo row entries, containing
group name information. One entry supports SNMPv1 access and the other entry supports SNMPv2 access.
vacmAccessTabletwo row entries, which map the commu-
nity name, security name, and group name information to an SNMPv3 security name. The DOCSIS-standard default security name for cable modems is docsisManager. One entry supports SNMPv1 access and the other entry supports SNMPv2 access. In this example, we start with a basic DOCSIS 1.1 CM conguration file, containing enough information to allow a cable modem to range and register, and then add the coexistence MIB elements to it. If you have a CM conguration file that you are already using, you can start with that le and add the coexistence elements to it. The following gure shows the contents of a basic DOCSIS 1.1 conguration file that we have opened in PacketACE. snmpCommunityTable Parameters The following table shows the example row to add to the snmpCommunityTable. The index for this table is an octet string; the example uses the string comm1 as the index value. You can use a different string if you desire. Italicized values in the table are default values that are created automatically.
Object Name Value
snmpCommunityName.comm1 snmpCommunitySecurityName.comm1 snmpCommunityContextEngineID.comm1 snmpCommunityContextName.comm1 snmpCommunityTransportTag.comm1 snmpCommunityStorageType.comm1 snmpCommunityStatus.comm1
my_password
rwAccess
local snmpEngineID (zero-length) (zero-length)

volatile(2) createAndGo(4)
Note: Avoid adding table index objects to the conguration le; the software lls in the index object using the index value supplied with the object name (.comm1 in this example). The order in which you add objects is not important.
12-4
vacmSecurityToGroupTable Parameters
The following table shows the example row to add to the vacmSecurityToGroupTable. This table has an index consisting of two objects:
vacmSecurityModelcorresponds to the SNMP version in use; in this example; it takes the values 1 and 2 to allow support for both SNMPv1 and SNMPv2 requests. vacmSecurityNamecorresponds to the snmpCommunitySecurityName object in the snmpCommunityTable (rwAccess in this example).
Value (row 1) Value (row 2)
Object Name
vacmSecurityModel (row index 1) vacmSecurityName (row index 2) vacmGroupName vamSecurityToGroupStorageType vamSecurityToGroupStatus
1 (SNMPv1)
rwAccess rwAccess volatile(2)
2 (SNMPv2)
rwAccess rwAccess volatile(2)
createAndGo(4) createAndGo(4)
vacmAccessTable Parameters
The following table shows the example row to add to the vacmAccessTable. This table has an index consisting of four objects:
vacmGroupNamecorresponds to the vacmGroupName object in the vacmSecurityToGroupTable (rwAccess in our
example).
vacmAccessContentPrexan octet string; in this example
we use an empty (zero length) string. This is shown as in the table below.
vacmAccessSecurityModelcorresponds to the SNMP version in use; in this example; it takes the values 1 and 2 to allow
support for both SNMPv1 and SNMPv2 requests.

vacmAccessSecurityLevelfor SNMP coexistence, use a value of 1 (noAuthnoPriv). This means that the NIU has no con-
gured SNMPv3 USM security users/keys.

Object Name Value (row 1) rwAccess Value (row 2) rwAccess
GroupName (row index 1) ContentPrex (row index 2) SecurityModel (row index 3) SecurityLevel (row index 4) vacmAccessContextMatch vacmAccessReadViewName
1 (SNMPv1) 1 (noAuthnoPriv)
exact(1)
2 (SNMPv2) 1 (noAuthnoPriv)
exact(1)
docsisManagerView docsisManagerView
12-5
Object Name
Value (row 1)
Value (row 2)
vacmAccessWriteViewName vacmAccessNotifyViewName vacmAccesssStorageType vacmAccessStatus
docsisManagerView docsisManagerView docsisManagerView docsisManagerView

volatile(2) createAndGo(4) volatile(2) createAndGo(4)
Action
Perform the following tasks in the order shown. Task Page
Adding the snmpCommunityTable ............................... 12-5 Adding the vacmSecurityToGroupTable ....................... 12-8 Adding the vacmAccessTable ...................................... 12-11 Adding the snmpCommunityTable Follow these steps to add coexistence MIB objects to a CM conguration le using PacketACE.
1
Click the Add SNMP MIB icon ( Add SNMP MIB. The Available MIBs tree appears.
) or select Edit menu ->
Locate the snmpCommunityTable MIB. If you are not sure where the MIB is located in the tree, enter the name of the MIB in the upper eld along the right side of the PacketACE window and then
12-6
click Find MIB by Name. The following gure shows the snmpCommunityTable MIB.
Double-click on one of the objects listed in the following table.

Object Name Value
snmpCommunityName snmpCommunitySecurityName snmpCommunityStorageType snmpCommunityStatus
my_password
rwAccess volatile(2) createAndGo(4)
The Add SNMP MIB window appears:
12-7
Enter the index name (comm1) in the Index,DisplayString eld, and the value from the table in step 3 in the Value eld. Some of the objects have a xed set of values; this is indicated by the drop-down menu button at the end of the Value eld. Click the menu button to display a list of allowed values, and choose the correct value.
Repeat steps 3 and 4 until all values are lled in. The conguration le should now look similar to the following:
The order of your MIB entries may be different than what is shown above.
6
Proceed to Adding the vacmSecurityToGroupTable on page 12-8.
12-8
Adding the vacmSecurityToGroupTable
Follow these steps to add coexistence MIB objects to a CM conguration le using PacketACE.
1
Locate the vacmSecurityToGroupTable MIB. If you are not sure where the MIB is located in the tree, enter the name of the MIB in the upper eld along the right side of the PacketACE window and then click Find MIB by Name.
12-9

Object Name Value (row 1) rwAccess Value (row 2) rwAccess volatile(2)
vacmGroupName
vamSecurityToGroupStorageType volatile(2) vamSecurityToGroupStatus
createAndGo(4) createAndGo(4)
Enter the rst index (1 or 2) in the Index1,Integer eld, the second index (rwAccess) in the Index2,DisplayString eld, and the value from the table in step 3 in the Value eld. Some of the objects have a xed set of values; this is indicated by the drop-down menu button at the end of the Value eld. Click the menu button to display a list of allowed values, and choose the correct value.
12-10
Repeat steps 3 and 4 until all values are lled in. The conguration le should now be similar to the following:
Note: The order of your MIB entries may be different than what is shown above.
6
Proceed to Adding the vacmAccessTable on page 12-11.
12-11
Adding the vacmAccessTable
Follow these steps to add coexistence MIB objects to a CM conguration le using PacketACE.
1
Locate the vacmAccessTable MIB. If you are not sure where the MIB is located in the tree, enter the name of the MIB in the upper eld along the right side of the PacketACE window and then click Find MIB by Name.
12-12

Value (row 1) exact(1) Value (row 2) exact(1)
Object Name
vacmAccessContextMatch vacmAccessReadViewName vacmAccessWriteViewName vacmAccessNotifyViewName vacmAccesssStorageType vacmAccessStatus
docsisManagerView docsisManagerView docsisManagerView docsisManagerView docsisManagerView docsisManagerView

volatile(2) createAndGo(4) volatile(2) createAndGo(4)
Enter indexes as follows, and the value from the table in step 3 in the Value eld.
Index1,DisplayStringrwAccess (or the value of the vacm-
GroupName object from the vacmSecurityToGroupTable)

Index2,DisplayStringleave blank Index3,Integer1 or 2, depending on the SNMP level row Index4,Integer1 (noAuthnoPriv)
Some of the objects have a xed set of values; this is indicated by the drop-down menu button at the end of the Value eld. Click the menu button to display a list of allowed values, and choose the correct value.
12-13
Repeat steps 3 and 4 until all values are lled in. The conguration le should now be similar to the following:
Note: The order of your MIB entries may be different than what is shown above.
6
Proceed to Conguring Trap Servers on page 12-14.
12-14
Conguring Trap Servers

Use this procedure to congure trap destinations, using TLV-38 SNMPv3 Notication Receiver elements. The following procedure assumes that PacketACE is running and that you have already added the coexistence MIBs to the conguration le, but you can add the TLVs to the conguration le before adding the MIBs if you prefer. Action
1
Click the Add TLV parameter icon (

Add TLV.
The following window appears:
Select SNMPv3NoticationReceiver from the Type drop-down menu, then click the Add TLV button.
The SNMPv3NoticationReceiver element appears in the main PacketACE window.
12-15
In the main PacketACE window, select the SNMPv3NoticationReceiver element, then click the Add TLV sub-parameter icon ( ) or select Edit menu -> Add Sub-TLV.
The following window appears:
4 5
Select SNMPv3NrIpAddress from the Sub-Type drop-down menu. Enter the IP address of the trap server (10.1.50.100 in this example) in the Value box. Click the Add TLV button. PacketACE adds the Trap IP address sub-type to the SNMPv3NoticationReceiver element.
Repeat steps 4 through 6, adding the SNMPv3NrTrapType subparameter and specifying a value of 1: SNMP v1 trap in an SNMP v1 packet.
12-16
Repeat steps 1 through 7 to create a second SNMPv3NoticationReceiver element with an IP address of 10.1.50.80 and a trap type of 2: SNMP v2c trap in an SNMP v2c packet. The conguration le should now resemble the following:
Save the conguration le and exit PacketACE.
13
13
Index
A
Access SNMP 11-1 troubleshooting interface 8-35 Advanced screens 8-30 Alarms Call Agent Loss of Communications 4-4 conguring 3-11 Pwr Supply Telemetry 4-4 Voice Failure 4-6 Voice Line Failure 4-5
B
Battery, charging 8-1
C
Call Agent Loss of Communications 4-4 CallP feature switch 3-5, 8-33 CallP/QoS Statistics screen 8-33 CATV State Change 5-11 Certicates private MIBs 10-2 Service Provider Root 10-2 using default 10-4 Conguration File Settings screen 8-34 Conguring alarms and log reporting 3-11 Connection statistics 8-27 CPS2000 3-2
D
Detailed Status screen 8-30 DHCP parameters screen 8-32 Diagnostics, line card 8-38 Disk contents 1-7 DQoS 3-4 Dynamic Quality of Service 3-4
13-2
E
EMTA, see NIU. End of call connection statistics 8-27 Event Log screen 8-29 Event tables 3-12 Event, see Alarms, Logs. 3-11
F
Feature switch 3-5 Functionality 1-4
G
Generating a list of passwords 6-3 Generating a single password 6-2 Global Universal Provisioning Interface 3-2 GUPI 3-2
H
Hardware/Software Versions screen 8-29 HomePNA 3-7 managing 3-7 provisioning 3-7 troubleshooting 8-40
I
Installing the software 2-1 Interface, troubleshooting 8-35 IP ports 3-5 IP security 3-5 IPSEC 3-5
K
KDC, updating 3-15
L
Line card, running diagnostics 8-38 Logs, conguring 3-11
M
Managing HomePNA 3-7 MIBs for root certicates 10-2 reference 7-1 supported 7-1 MTA Parameters screen 8-33 MTA PROV Failed 5-14 MTA PROV Successful 5-12, 5-14
13-3
MTA Root Certicate download Complete 5-9 MTA Security Service Provider Certicate Chain Validation Failed 5-8 MTA Test Root Certicate download failed 5-8, 5-9 MTA TFTP Cong File Error 5-14 Failed 5-14 File Not Found 5-12 No Channel 5-12 Protocol Error TFTP Close 5-13 TFTP DB Access 5-13 TFTP Init 5-12 TFTP Open 5-12 TFTP Read 5-13
N
NIU 1-1 NIU battery states 5-6 NIU line states 5-5 NIU states 5-5 NmAccess mode 11-1
P
PacketCable event tables 3-12 provisoning 3-1 Password generating list of 6-3 generating single 6-2 Ports signalling 3-5, 8-22 voice line 3-5 Power Supply Telemetry 5-11 Protection 5-10 Provisioning 3-1 HomePNA 3-7 modes 3-1 DHCP parameters 3-3 selecting 3-2 notes 3-4 secure MTA and NCS 3-15 PWOD tool 6-1 changing the seed 6-3 generating passwords 6-3 using 6-2 Pwr Supply Telemetry 4-4
Q
Quality of Service 3-4
13-4
R
Registration Status screen 8-30 Running line card diagnostics 8-38
S
Screen CallP/QoS statistics 8-33 conguration le settings 8-34 detailed status 8-30 DHCP parameters 8-32 event log 8-29 hardware/software versions 8-29 MTA parameters 8-33 registration status 8-30 status, cable modem 8-28 Seed, changing 6-3 Service Provider Certicates private MIBs 10-2 Root certicate 10-2 Signalling port 3-5, 8-22 SNMP access modes 11-1 NmAccess 11-1 SNMP coexistence mode 11-1 SNMP coexistence mode 11-1 SNMP coexistence types 11-2 Software functionality 1-4 installation 2-1 upgrading 2-3, 2-4 State Change 5-11 States battery 5-6 line 5-5 NIU 5-5 Statistics, end of call 8-27 Status monitoring 8-28 Status screen 8-28
T
Troubleshooting 8-1, 8-28 accessing advanced pages 8-37 accessing standard pages 8-36 accessing the interface 8-35 controlling access 8-35 HomePNA 8-40
13-5
U
Updating the KDC 3-15 Upgrading the software through provisioning 2-3 through SNMP 2-4 Using the default root certicate 10-4 Using the PWOD tool 6-2
V
Voice Failure 4-6 Voice Line Diag Failed 5-9 Voice Line Diag Passed 5-10 Voice Line Failure 4-5 Voice Line Loop Current Change to High 5-11 to Normal 5-11 Voice line ports 3-5 Voice Line Protection State Change 5-10 Voice Line State Change 5-10
13-6
2002, 2003 ARRIS All rights reserved All information contained in this document is subject to change without notice. Arris Interactive reserves the right to make changes to equipment design or program components, as progress in engineering, manufacturing methods, or other circumstances may warrant. ARRIS, ARRIS Interactive, and Touchstone are trademarks of ARRIS Licensing Company. Cornerstone is a registered trademark of ARRIS Licensing Company. All other trademarks are the property of their respective holders. Document number: ARSVD00646 Release 3.2 Standard 1.0 September 2003

TM202B Software Guide

Uploaded by

Copyright:

Available Formats

TM202B Software Guide

Uploaded by

Document Information

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

TM202B Software Guide

Uploaded by

Copyright:

Available Formats

Touchstone Telephony

Software Operators Guide (TS3.2)

2002, 2003 ARRIS All rights reserved Printed in the USA

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

Installing the Software

Procedure: Installing the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

Using the Password of the Day Tool

Appendix A: Example Files

Appendix B: Configuring the Service Provider Root

Service Provider Root Provisioning for Touchstone Telephony Modems . 10-2

Appendix C: SNMP Access Modes

Appendix D: Configuring SNMP Coexistence

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

About This Document

About This Document

About the Touchstone Telephony Software

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

About This Document

Call Processing. Software controlling the current state of a call.

About This Document

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

About This Document

About This Document

Micro-Processor Interface. An internal Touchstone Telephony Modem component.

Network Call Signaling. The PacketCable protocol used to control calls.

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

About This Document

reading and setting values of MIB variables presented by each device.

A call between a ToIP phone line and a line on the PSTN.

Public Switched Telephone Network.

About This Document

Subscriber Line Audio Circuit. An internal Touchstone Telephony Modem component.

Simple Network Management Protocol.

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

Touchstone Telephony Port

Touchstone Telephony Modems

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

TS3.2 Software Functionality

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

Enhancements from TS01

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

Contents of the Software Disk

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

Installing the Software

Installing the Software

Installing the Software

Perform the following tasks as needed. Task Page

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

Installing the Software

Conguring the NIU to Download its Software

Upgrading the Software through Provisioning

Installing the Software

Upgrading the Software through SNMP

Using the SNMP manager, set the following docsDevSoftware MIBs:

The NIU downloads the new software, then resets.

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

PacketCable without KDC

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

Full PacketCable PacketCable minus KDC CPS 2000