BSR 64000

BSR 64000
Troubleshooting
Guide
Document ID: 365-095-27197 Version 1

Release 8.0.0
Notice
ARRIS Enterprises, Inc. 2014 All rights reserved. No part of this publication may be reproduced in any form or by any means or used to
make any derivative work (such as translation, transformation, or adaptation) without written permission from ARRIS Enterprises, Inc.
(ARRIS). ARRIS reserves the right to revise this publication and to make changes in content from time to time without obligation on
the part of ARRIS to provide notification of such revision or change. The capabilities, system requirements, and/or compatibility with
third-party products described herein are subject to change without notice.
EXCEPT AS INDICATED IN THE APPLICABLE SYSTEM PURCHASE AGREEMENT, THE SYSTEM, DOCUMENTATION AND
SERVICES ARE PROVIDED "AS IS", AS AVAILABLE, WITHOUT WARRANTY OF ANY KIND. ARRIS GROUP, INC. (ARRIS)
DOES NOT WARRANT THAT THE SYSTEM WILL MEET CUSTOMER'S REQUIREMENTS, OR THAT THEIR OPERATION
WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT ANY ERRORS CAN OR WILL BE FIXED. ARRIS HEREBY
DISCLAIMS ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, ORAL OR WRITTEN, WITH RESPECT TO THE SYSTEM
AND SERVICES INCLUDING, WITHOUT LIMITATION, ALL IMPLIED WARRANTIES OF TITLE, NON-INFRINGEMENT,
INTEGRATION, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE AND ALL WARRANTIES ARISING
FROM ANY COURSE OF DEALING OR PERFORMANCE OR USAGE OF TRADE.
EXCEPT AS INDICATED IN THE APPLICABLE SYSTEM PURCHASE AGREEMENT, ARRIS SHALL NOT BE LIABLE
CONCERNING THE SYSTEM OR SUBJECT MATTER OF THIS DOCUMENTATION, REGARDLESS OF THE FORM OF ANY
CLAIM OR ACTION (WHETHER IN CONTRACT, NEGLIGENCE, STRICT LIABILITY OR OTHERWISE), FOR ANY (A)
MATTER BEYOND ITS REASONABLE CONTROL, (B) LOSS OR INACCURACY OF DATA, LOSS OR INTERRUPTION OF USE,
OR COST OF PROCURING SUBSTITUTE TECHNOLOGY, GOODS OR SERVICES, (C) INDIRECT, PUNITIVE, INCIDENTAL,
RELIANCE, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES INCLUDING, BUT NOT LIMITED TO, LOSS OF
BUSINESS, REVENUES, PROFITS OR GOODWILL, OR (D) DIRECT DAMAGES, IN THE AGGREGATE, IN EXCESS OF THE
FEES PAID TO IT HEREUNDER FOR THE SYSTEM OR SERVICE GIVING RISE TO SUCH DAMAGES DURING THE
12-MONTH PERIOD PRIOR TO THE DATE THE CAUSE OF ACTION AROSE, EVEN IF COMPANY HAS BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS ARE INDEPENDENT FROM ALL OTHER PROVISIONS OF
THIS AGREEMENT AND SHALL APPLY NOTWITHSTANDING THE FAILURE OF ANY REMEDY PROVIDED HEREIN.
All ARRIS products are furnished under a license agreement included with the product. If you are unable to locate a copy of the license
agreement, please contact ARRIS.
ARRIS provides this guide without warranty of any kind, implied or expressed, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. ARRIS may make improvements or changes in the product(s) described in this
manual at any time.
The capabilities, system requirements and/or compatibility with third-party products described herein are subject to change without
notice.
ARRIS and the ARRIS logo are all trademarks of ARRIS Enterprises, Inc. Other trademarks and trade names may be used in this
document to refer to either the entities claiming the marks and the names of their products. ARRIS disclaims proprietary interest in the
marks and names of others.
Caring for the Environment by Recycling

When you see this symbol on an ARRIS product, do not dispose of the product with residential or commercial waste.
Recycling your ARRIS Equipment
Please do not dispose of this product with your residential or commercial waste. Some countries or regions, such as the European
Union, have set up systems to collect and recycle electrical and electronic waste items. Contact your local authorities for informa-
tion about practices established for your region.
Document ID: 365-095-27197 Version 1

Release 8.0.0
Published: 10/14
Contents
Preface
Scope .............................................................................................................................................ix
Audience........................................................................................................................................ix
Documentation Set ........................................................................................................................ix
Conventions...................................................................................................................................xi
Notes, Cautions, Warnings ............................................................................................................xi
If You Need Help..........................................................................................................................xii
Telephone Support.............................................................................................................xii
Online Support..................................................................................................................xiii
1 Introduction
Overview .....................................................................................................................................1-1
Understanding Basic Troubleshooting ........................................................................................1-1
Discovering Problems .................................................................................................................1-2
Viewing Symptoms .....................................................................................................................1-2
Isolating the Problem ..................................................................................................................1-3
Solving the Problem ....................................................................................................................1-3
Evaluating the Solution ...............................................................................................................1-3
2 Checking Physical Equipment

Overview .....................................................................................................................................2-1
Checking Physical Network Connections ..................................................................................2-1
Turning On the BSR 64000.........................................................................................................2-2
Determining BSR 64000 Operational Status ..............................................................................2-2
Document ID: 365-095-27197 Version 1 iii

BSR 64000 SNMP Configuration and Management Guide Release 8.0.0
Interpreting Resource Module LED Displays ............................................................................2-4

Supervisor Resource Module LEDs .................................................................................2-4
Module LEDs.....................................................................................................2-4
Fan Status LEDs ................................................................................................2-5
SRM10G 10 Gig and 1 Gig Port LEDs .............................................................2-5
TX32 Resource Module LEDs .........................................................................................2-5
Module LEDs.....................................................................................................2-6
Per-Port LEDs ...................................................................................................2-7
TX32 Standby Resource Module LEDs ...........................................................................2-7
Module LEDs.....................................................................................................2-7
Per-Port LEDs ...................................................................................................2-8
RX48 Resource Module LEDs.........................................................................................2-8
Module LEDs.....................................................................................................2-8
Per-Port LEDs ...................................................................................................2-9
Diagnostic Ethernet Port LEDs........................................................................2-10
RX48 Standby Resource Module LEDs.........................................................................2-10
Module LEDs...................................................................................................2-10
Per-Port LEDs .................................................................................................2-11
Diagnostic Ethernet Port LEDs........................................................................2-11
Rebooting an Individual Resource Module...............................................................................2-11
3 Troubleshooting the CMTS

Overview .....................................................................................................................................3-1
Using Flap Lists to Troubleshoot CM Problems.........................................................................3-1
Viewing Flap List Statistics to Identify Network Health .................................................3-1
Interpreting Flap List Statistics .......................................................................................3-4
Tips for Administrating Flap Lists ...................................................................................3-7
Resolving HFC Network Performance Problems ......................................................................3-7
Downstream Signal Reflected on Upstream Path ............................................................3-7
Slow Performance Detected on Upstream Port ...............................................................3-8
Resolving Problems on the Upstream Path ...............................................................................3-10
Unacceptable Upstream Signal-to-noise Ratio Detected ..............................................3-10
Upstream Power Level Too Low or High .....................................................................3-12
Resolving Problems on the Downstream Path ..........................................................................3-13
iv Document ID: 365-095-27197 Version 1

Release 8.0.0 Contents
Unacceptable Downstream Signal-to-Noise Ratio Detected .........................................3-14

Downstream Power Level Too Low or High ................................................................3-15
Resolving Cable Modem Problems ..........................................................................................3-16
Misconfigured Authentication String or Key ................................................................3-16
CM Does Not Reply to Station Maintenance Requests .................................................3-17
CM is Offline .................................................................................................................3-17
CM Cannot Obtain an IP Address ..................................................................................3-19
Provisioning Problems Cause CMs Not to Register ......................................................3-20
CM Does Not Respond to SNMP Messages .................................................................3-22
4 Troubleshooting Basic Routing Problems

Overview .....................................................................................................................................4-1
Resolving Host Connectivity Problems ......................................................................................4-1
Default Gateway Configuration Problems ......................................................................4-2
Misconfigured or Missing Default Routes ......................................................................4-2
Incomplete DNS Host Table ............................................................................................4-3
DNS Not Running ............................................................................................................4-3
Handling Routing Problems ........................................................................................................4-3
Problem Router ................................................................................................................4-3
Misconfigured Router.......................................................................................................4-5
Routing Interface Down ...................................................................................................4-5
Handling a Misconfigured Access List ......................................................................................4-6
Access List and Filter Misconfigurations ........................................................................4-7
Handling UDP Broadcast Forwarding Problems .......................................................................4-8
Missing or Misconfigured IP Helper-address Specification.............................................4-8
UDP Broadcast Misconfiguration ...................................................................................4-8
5 Troubleshooting RIP
Overview .....................................................................................................................................5-1
Handling Routing Table Problems ..............................................................................................5-1
Misconfigured or Missing Network Router Table Entries ...............................................5-1
Misconfigured Route Filtering .........................................................................................5-2
Split Horizon is Disabled .................................................................................................5-2
Handling RIP Version Inconsistencies .......................................................................................5-3
Document ID: 365-095-27197 Version 1 v

BSR 64000 SNMP Configuration and Management Guide Release 8.0.0
Misconfigured Version of RIP Running on BSR .............................................................5-3

Misconfigured Version of RIP Running on Specified Interface.......................................5-3
6 Troubleshooting OSPF
Overview .....................................................................................................................................6-1
Handling OSPF-designated Interface Problems..........................................................................6-1
Handling Router Neighbor Misconfigurations............................................................................6-2
Misconfigured Router.......................................................................................................6-2
Mismatched OSPF Parameters ........................................................................................6-2
Mismatched IP MTU ........................................................................................6-3
Resolving Missing Routes in Routing Table ..............................................................................6-4
RIP Routing Information Incorrectly Redistributed into OSPF ......................................6-4
ABR Configured Without Area 0 Interface .....................................................................6-4
7 Troubleshooting BGP
Overview .....................................................................................................................................7-1
Handling BGP Routing Problems ...............................................................................................7-1
Missing Neighbor Table Entry ........................................................................................7-1
Misconfigured Access List ..............................................................................................7-2
Missing Network Destination Advertisement .................................................................7-2
Handling BGP Peer Misconfigurations ......................................................................................7-3
8 Troubleshooting Multicast Routing

Overview ....................................................................................................................................8-1
Hosts are Not Receiving Video ..................................................................................................8-1
Check Connection Between IGMP and Hosts .................................................................8-1
IGMP Configuration Problems .........................................................................8-1
Misconfigured IGMP Access Group .................................................................8-2
Some IGMP Hosts Are Not Receiving Multicast Services ...............................8-2
Check Connections Between Multicast Routers .............................................................8-3
9 Recommended BSR Configurations

Introduction .................................................................................................................................9-1
Increasing the Log File Size........................................................................................................9-2
vi Document ID: 365-095-27197 Version 1

Release 8.0.0 Contents
Denial of Service Protection .......................................................................................................9-2

Enabling DHCP Throttling...............................................................................................9-2
Constraining Logging and Reporting ...............................................................................9-2
Blocking Unsolicited Network Traffic .............................................................................9-5
Configuring Unresolved IP Packet Throttling ...................................................9-5
Configuring IPv4 Access Control Lists .............................................................9-6
Configuring IPv6 Access Control Lists .............................................................9-8
Changing the Upstream Range Backoff Value..........................................................................9-10
Configuring the Boot ROM Filename.......................................................................................9-11
Enabling Remote Query ............................................................................................................9-11
Enabling Remote Set.................................................................................................................9-12
Sending Events to a SYSLOG Server .......................................................................................9-12
Repeated Log Detection .................................................................................................9-13
Configuring an SNTP Server ....................................................................................................9-13
Configuring Voice .....................................................................................................................9-15
Configuring Downstream Voice Priority........................................................................9-15
Configuring Upstream Voice Priority.............................................................................9-16
Configuring a Service Class for Voice ...........................................................................9-17
Configuring the Packet Cable Active Timeout...............................................................9-17
Disabling the Empty Channel Load Balancing Restriction ......................................................9-18
Resetting Non-Bonded Cable Modems.....................................................................................9-18
10 Technical Solutions
Overview ..................................................................................................................................10-1
List of Solutions ........................................................................................................................10-1
2:8 CMTS to RX48 Upgrade Practices ....................................................................................10-2
3-Slot I/O Module in Slot 15 ....................................................................................................10-4
ACL Port Ranges .....................................................................................................................10-5
Air Filter Maintenance .............................................................................................................10-6
Blank Module Requirements ....................................................................................................10-7
BPI Security Recommendation ................................................................................................10-8
Chassis Fan / Blower Module Connector .................................................................................10-9
CM IP Address Issue with Cable Privacy Mandatory ............................................................10-11
Gigabit Ethernet Protective Boot ...........................................................................................10-12
Document ID: 365-095-27197 Version 1 vii

Loose SFPs Could Cause SRM10G Reset .............................................................................10-13
Outpost24 TCP Issues ............................................................................................................10-14
PLL Loss After Switchover Issue ..........................................................................................10-15
Redundancy DRX Reset-After-Switchover ...........................................................................10-16
RX48 Power Surge Recovery .................................................................................................10-17
Shut/Noshut MAC Domain Modem Recovery ......................................................................10-18
SNMP Timeout .......................................................................................................................10-19
SRM Ethernet 7/0 Port Restrictions .......................................................................................10-20
SRM10G Occasional Packet Loss ..........................................................................................10-21
SSH Causes SRM4 Reset ............................................................................................10-22
Subnet Migration ....................................................................................................................10-23
TX32 Module Replacement Procedure ..................................................................................10-24
TX32 Upgrade Issue from 6.0.1 or Earlier .............................................................................10-25
A Cable Modem
Registration Process
Introduction ................................................................................................................................A-1
Scanning .....................................................................................................................................A-1
Initial Ranging............................................................................................................................A-2
Establishing IP Connectivity ......................................................................................................A-2
Establishing Time of Day...........................................................................................................A-2
TFTP Connectivity.....................................................................................................................A-3
Registration ................................................................................................................................A-3
Baseline Privacy .........................................................................................................................A-3
Periodic Ranging ........................................................................................................................A-3
Data Exchange............................................................................................................................A-4
Index
Preface
Scope
This document describes how to troubleshoot the ARRIS Broadband Services
Router 64000 (BSR 64000) including hardware, applications, servers, databases,
and routing. This guide uses the term network to refer to subscriber cable modems, the
BSR family of products, cables and equipment, and host servers.
Audience
This document is for use by those persons who will install and configure the
BSR 64000 product. Only trained service personnel should install, maintain, or
replace the BSR 64000.
Documentation Set
The following documents comprise the BSR 64000 documentation set:
BSR 64000 Quick Start Guide

The quick start guide provides a "roadmap" to the tasks involved in physically
installing the BSR 64000 product, physically connecting it to your network/HFC
infrastructure, and performing configuration tasks to enable the BSR 64000 to
operate in your networking environment.
BSR 64000 Chassis Installation Guide
Document ID: 365-095-27197 Version 1 ix

BSR 64000 Troubleshooting Guide Release 8.0.0
This guide provides detailed instructions for physically installing the BSR 64000
product including: procedures for rack mounting, making physical network cable
connections, connecting DC power, and for determining the status of the BSR
64000 after applying power to it. This document also provides a description of the
BSR 64000 chassis, its hardware components and modules.
BSR 64000 Module Installation Guide
This guide contains procedures for installing additional and replacement
Resource and I/O Modules in a BSR 64000 chassis and for making physical cable
connections to the modules.
BSR 64000 Command Line Interface Users Guide
For users, this guide describes the structure of the BSR 64000 Command Line
Interface (CLI) and its various command modes. It also provides rules and
guidelines for navigating through the CLI.
BSR 64000 Command Reference Guide
This guide contains individual descriptions of the entire set of commands that
comprise the BSR 64000 Command Line Interface (CLI). These commands are
used to interface with, configure, manage, and maintain the BSR 64000.
BSR 64000 System Administration Guide
For system administrators, this guide provides detailed procedures for performing
initial configuration tasks including setting up: user accounts and passwords;
telnet and console access; system logging; and associated servers such as DHCP,
DNS, etc.
BSR 64000 CMTS Configuration and Management Guide
This guide provides the instructions and procedures for configuring and
managing BSR 64000 CMTS operation.
BSR 64000 Routing Configuration and Management Guide
This guide contains the instructions and procedures for configuring and managing
BSR 64000 routing operation, including RIP, OSPF, and BGP.
BSR 64000 SNMP Configuration and Management Guide
ixx Document ID: 365-095-27197 Version 1

Release 8.0.0 Preface
managing BSR 64000 Simple Network Management Protocol (SNMP) operation.
It also describes SNMP MIBs; provides information that describes standard and
proprietary MIB support; describes how to walk MIBs; and how to compile and
load SNMP MIBs.
BSR 64000 BGP/MPLS VPN Configuration Guide
managing the BSR 64000 to support and implement Border Gateway Protocol/
MultiProtocol Label Switching Virtual Private Networks (BGP/MPLS VPNs).
BSR 64000 Troubleshooting Guide
This guide contains instructions and procedures for troubleshooting typical
configuration problems that might be encountered using the BSR 64000. It also
offers suggestions for information to record, and have available should the need
arise to call ARRIS support for assistance with BSR 64000 operational problems.
BSR 64000 Release Notes
These documents are specific to each release of the BSR 64000 product (software
and hardware). Release notes provide information about features not documented
or incorrectly documented in the main documentation set; known problems and
anomalies; product limitations; and problem resolutions.
Conventions
This document uses the conventions in the following table:
Convention Example Explanation

angle brackets < > ping <ip-address> Arguments in italic and enclosed by angle
ping 54.89.145.71 brackets must be replaced by the text the
argument represents. In the example,
54.89.145.71 replaces <ip-address>. When
entering the argument, do not type the angle
brackets.
bar brackets [ ] disable [level] Bar brackets enclose optional arguments. The
example indicates you can use the disable
command with or without specifying a level.
Some commands accept more than one
optional argument. When entering the
argument, do not type the bar brackets.
Document ID: 365-095-27197 Version 1 xi

Convention Example Explanation

bold text cable relay-agent-option Boldface text must be typed exactly as it
appears.
brace brackets {} page {on | off} Brace brackets enclose required text. The
example indicates you must enter either on or
off after page. The system accepts the
command with only one of the parameters.
When entering the text, do not type the brace
brackets.
italic text boot system <filename> Italic type indicates variables for which you
supply values in command syntax descriptions.
It also indicates file names, directory names,
document titles, or emphasized text.
screen display Wed Jun 16 17:01:03 This font indicates system output.
2014
vertical bar | page {on | off} A vertical bar separates the choices when a
parameter is required. The example indicates
you can enter either command:
page on or page off
When entering the parameter, do not type the
vertical bar or the brace brackets.
Notes, Cautions, Warnings

The following icons and associated text may appear in this document.
Note: A note contains tips, suggestions, and other helpful information, such as references to
material not contained in the document, that can help you complete a task or understand the
subject matter.
Caution: The exclamation point, within an equilateral triangle, is intended to alert the user to
the presence of important installation, servicing, and operating instructions in the documents
accompanying the equipment.
ixxii Document ID: 365-095-27197 Version 1

Release 8.0.0 Preface
Warning: This symbol indicates that dangerous voltage levels are present within the
equipment. These voltages are not insulated and may be of sufficient strength to cause
serious bodily injury when touched. The symbol may also appear on schematics.
If You Need Help

Support for your BSR 64000 hardware and software is available via telephone and the
Internet.
Telephone Support
If you need assistance while working with the BSR 64000, contact the ARRIS
Technical Assistance Center (TAC):
U.S. 1-888-944-HELP (1-888-944-4357)

International +1-215-323-2345
Spanish language support 215-323-2346
The ARRIS TAC is on call 24 hours a day, 7 days a week.

When calling for technical support, please have the following information available:
Your customer information, including location, main contact, and telephone
number
BSR product and modules
Detailed description of the issue
Specific information to assist with resolving the problem, including:
BSR hostname
BSR error messages and logs
Output of BSR show tech command
Cable modem information
List of troubleshooting steps you have performed before calling the TAC.
Current state of your BSR 64000 product
Severity of the issue you are reporting
When calling for repair or Advanced Component Exchange (ACE) replacement,
please provide the following additional information:
Document ID: 365-095-27197 Version 1 xiii

Output of BSR show version command, with part numbers and serial numbers of BSR
components
Shipping information for the replacement, including contact name, company name, address, phone
number, and email address
Online Support
The customer website, http://www.arrisi.com/cc360, is available for BSR customers to access the latest
product information, software updates, troubleshooting information, and technical publications for the
BSR 64000 product line.
You may request access to BSR information by emailing the product support team at
Tac.Helpdesk@ARRISI.com with the following information:
Company name
Contact name, phone number, and email address
ARRIS Support contact
BSR product under service contract
The BSR product support team will email an invitation to you with further instructions on how to set up
an account.
1
Introduction
Overview
This chapter identifies the basic tasks you perform to solve problems with the network
and BSR hardware and software configurations.
The next sections describe how to perform standard troubleshooting techniques:
Understanding Basic Troubleshooting
Discovering Problems
Viewing Symptoms
Isolating the Problem
Solving the Problem
Evaluating the Solution
Understanding Basic Troubleshooting

The basic steps you need to troubleshoot network problems are as follows:
Document ID: 365-095-27197 Version 1 1-1

1. Identify the cause or symptom of the problem, which can be any undesired result
or behavior. See Discovering Problems on page 1-2, to learn how to identify
problems.
Note: One or more symptoms or causes can be related to a single problem.
2. Isolate the cause or symptom of the problem and try to determine its scope. For
example, determine if it is the whole HFC network, a particular subnetwork on
the HFC network, or just one subscriber that is experiencing the problem. See
Isolating the Problem on page 1-3, for more information.
3. Once the cause or symptom of a problem is isolated, make a list of
troubleshooting procedures that you plan to use. Refer to subsequent chapters in
this document for specific troubleshooting procedures you can use.
4. Document the changes and effects of changes as you perform troubleshooting
procedures, and note any new troubleshooting procedures that you use. This
simple precaution helps to avoid repeating steps, allows for future reference in
case the problem recurs, and is especially useful for troubleshooting intermittent
problems.
5. Determine if the problem is solved. Ensure that the troubleshooting procedure did
not cause new problems.
6. If the problem is not solved, try to identify problem causes more clearly, isolate
any additional causes, and perform additional troubleshooting procedures to
correct the problem.
Discovering Problems
Ensure that you thoroughly understand the network so that you can establish a
baseline from which to work, and distinguish the differences between normal and
abnormal activity on the network.
Perform the following steps to determine the source of problems:
Review release notes and technical bulletins to determine if there are any
incompatibilities or known problems.
1-2 Document ID: 365-095-27197 Version 1

Release 8.0.0 Introduction
Gather information for all the possible causes or symptoms to more quickly
isolate the problem.
Discover if the problem relates to another problem that you must solve first.
Record all configuration parameters that relate to the problem.
Determine if the network configuration has changed recently, such as the addition
or removal of components, upgrading, or reconfiguration.
Identify aspects that causes or symptoms have in common to determine if they are
related.
Look for network patterns in the causes. What time of day did these problems
occur? What events were logged? What network thresholds were transgressed?
Record any changes that occurred since the network was last functioning
correctly. Changes in network activity may relate to a configuration change.
Record any changes that occurred since the last time the BSR was operating
properly. Investigate any configuration changes that might be related to the
problem.
Viewing Symptoms
Perform the following tasks to view and compare symptoms that are related to a
problem:
Repeat the conditions that led to the symptom. Consider any errors or failures that
can cause a particular symptom, and test them to see if they are causing the
symptom.
Determine if any symptoms are related. Are there unexpected or undesired results
in more than one area? If so, find the areas in common and the variables that
affect them. The source of the problem is often found in similar areas.
Focus on one symptom or a set of related symptoms of a problem. However, do
not completely disregard other symptoms, because what may appear to be an
unrelated problem may actually be related based on other symptoms.
Isolating the Problem

A problem can have one or more causes. To identify the cause of unwanted behavior,
use the following techniques:
Isolate the problem. For example, isolate a problem to one part of the network or
to a specific access module.

Find the functions that are working correctly.

Retrace the steps that were taken, and return the network to its condition before
the problem first appeared. Once the network is in a known condition, take
incremental steps and observe the network to learn when and where the problems
occur.
Determine if there have been any additions, changes, or upgrades to the network.
If so, consider any consequences the changes could have had on the network, and
whether they affect the current situation.
Solving the Problem

Different problems require different actions and solutions, but follow these basic steps
to fix any problem:
1. Identify the course of action and the steps you plan to take.
2. Decide what tools are necessary to fix the problem on the network. For example,
you can use the CLI as a tool to look at events and set SNMP traps. You can use a
cable tester to check physical media connections.
3. Perform each step for the course of action.
4. Verify the result of each action using the available CLI show commands. For
example, if you enabled a port, use the appropriate show ip interface brief
command in Privileged EXEC mode to verify that the port is enabled.
5. If more than one possible action exists, select the easiest one first to quickly
eliminate possibilities, or select the action that appears most likely to solve the
problem first, even if it is the most time-consuming or difficult to perform.
Evaluating the Solution

Once you find the solution, test it to ensure that no new symptoms or problems occur.
If new symptoms or problems do occur, repeat the troubleshooting process to
determine the cause. If problems or symptoms recur, create a standard test plan to
evaluate fixes.

2
Checking Physical Equipment
Overview
This chapter describes how to turn on the BSR 64000 and observe system startup to
determine if the system boots properly. The process also involves checking physical
connections and observing LEDs on the BSR products. In addition, you should check
power and network connections anytime you install new hardware or whenever a
problem occurs.
Topics in this chapter include:
Checking Physical Network Connections
Turning On the BSR 64000
Determining BSR 64000 Operational Status
Interpreting Resource Module LED Displays
Rebooting an Individual Resource Module
Checking Physical Network Connections

Check network connections for loose, broken, or disconnected cables. Inspect the
cable terminating connectors for damage.
Use the following techniques to troubleshoot physical cables on the network:

Use the Command Line Interface (CLI) show commands to view port and slot
information.
Use a cable tester to test the network cables for damage.
Verify that all the networks associated with the BSR are within proper
specifications.
Use cable testing equipment to measure or ensure that the correct distances for
cable runs are in place.
If the BSR 64000 is installed, ensure that all modules are seated correctly in the
chassis.
Replace any suspected defective modules or devices with known working spare
modules or devices.
Refer to the system documentation or service contract information for
replacements and on-site spares.
Turning On the BSR 64000

To apply power to the BSR 64000, complete the following tasks:
1. Verify that the electrical connections to the BSR 64000 are secure.
2. Turn on the DC power supply connected to the BSR 64000.

Release 8.0.0 Checking Physical Equipment
3. Turn on each BSR 64000 Power Entry Module by placing its power switch in the
ON (I) position. You can access the Power Entry Module power switches through
the plastic shield that covers the DC power connections. See Figure 2-1.
Power Entry Module A Power Entry Module B

Power Switch Power Switch
bsr64k036a
Figure 2-1 Accessing BSR 64000 Power Switches
Determining BSR 64000 Operational Status

To determine BSR 64000 status following power up do the following:
Visually check the operational status of the cooling units. All fans in the bottom
Fan Module and the blowers in the top Blower Module should be turning and the
Fan Status LED labeled OK on the front panel of the SRM should be lit green for
both the top (TOP) Blower Module and bottom (BOT) Fan Module.

Observe the LEDs on the SRM, TX32, and RX48 modules after the booting
process completes. The LED display on these modules will vary until the
BSR 64000 is booted. When the booting process completes, the LEDs will
display as described in Table 2-1.
Table 2-1 BSR 64000 LED Display States Following Successful Booting
Module LED LED Display State

Supervisor Resource Module LEDs:
Module (SRM)
Fail Off
Status Green (Active SRM)
or
Blinking Green (Standby SRM)
(SRM Redundant Systems Only)
Alarm Off
Fan Status LEDs (Top and Bottom Fan Module):
OK Green
Fail Off
10 Gigabit and 1 Gigabit Ethernet Port LEDs:
Link Green (when Link is present)
ACT Off (no activity) or Flashing Green
(activity)
TX32 Resource Module Module LEDs:
Fail Off
Status Green
Alarm Off
Downstream Port LEDs:
Link Off (unconfigured) or Green
Fault Off

Table 2-1 BSR 64000 LED Display States Following Successful Booting
Module LED LED Display State

TX32 Standby Resource Module LEDs:
Module
Fail Off
Status Blinking Green
Alarm Off
Downstream Port LEDs:
Link Off
Fault Off
RX48 Resource Module Module LEDs:
Fail Off
Status Green
Alarm Off
Upstream Port LEDs:
Link Off (unconfigured) or Green
Fault Off
RX48 Standby Resource Module LEDs:
Module
Fail Off
Status Blinking Green
Alarm Off
Upstream Port LEDs:
Link Off
Fault Off
Interpreting Resource Module LED Displays

The following sections describe the LED displays of the following BSR 64000
Resource Modules:
Supervisor Resource Module LEDs
TX32 Resource Module LEDs
TX32 Standby Resource Module LEDs
RX48 Resource Module LEDs

RX48 Standby Resource Module LEDs
Supervisor Resource Module LEDs

The SRM has the following groups of LEDs that indicate its operational status and the
status of other chassis components:
Module LEDs
Fan Status LEDs
10 Gig and 1 Gig Port LEDs
The subsections that follow describe the display states of these LED groups.
Module LEDs
The SRM Module LEDs are visible on the module front panel and are labeled: Fail,
Status, and Alarm.
Table 2-2 describes the possible display states of these LEDs during operation.
Table 2-2 Module LED Display States for the SRM
Fail Status Alarm Interpretation

Off Green Off Normal operating status. When operating in SRM redundant
mode, indicates that the SRM is the Active SRM.
Off Blinking Off Normal operating status. When operating in SRM redundant
Green mode, indicates that the SRM is the Standby SRM.
Off Green Red Failure. SRM is operating with an alarm condition. See Fan
Status LEDs for more information. Also see the show system
alarms console command, as this failure could be an indication
of an Over Temperature alarm.
Red Off Off Indicates a module hardware failure.
Red Off Red Failure. SRM is not operational.
Red Green Red Reset. SRM is booting.
Off Off Off Module is not receiving power.
Fan Status LEDs

The SRM provides a set of Fan Status LEDs for each of the Fan Tray Modules
installed in the chassis. These LEDs are visible on the module front panel of the SRM

and are labeled: OK and Fail. Table 2-3 describes the possible display states of the
LEDs. Separate LED status is available for the top and bottom Fan Tray Modules.
Table 2-3 SRM Fan Status LED Display States
OK Fail Interpretation
Green Off Normal operating status.
Off Red Failure. One or more fans of the fan module failed or the fan module is
removed.
SRM10G 10 Gig and 1 Gig Port LEDs

The SRM10G supports two 10 Gigabit optical ports, labeled 0 and 1, and four 1
Gigabit optical ports, labeled 2 through 5. Each port has two LEDs associated with it
to indicate the ports operational status. The LEDs are visible on the module front
panel and are labeled Link and ACT.
Table 2-4 SRM10G 10 Gig and 1 Gig Port LED Display States
Link ACT Interpretation

Green Flashing Normal operating status when configured and connected to an external
Green device. Link is established, and the ACT LED flashes to show activity on the
port.
Off Off Port is not configured, has failed, is not operational, or is not connected.
Note: Check module LEDs to determine if the module is receiving power.
Green Off Link without activity.
TX32 Resource Module LEDs

TX32 Resource Modules have two groups of LEDs that indicate the operational status
of the module. These LED groupings include:
Module LEDs
Per-Port LEDs
The following subsections describe the possible display states of these LED types.

Module LEDs
The Module LEDs are visible on the module front panel and are labeled: Fail, Status,
and Alarm.
Table 2-5 describes the possible display states of these LEDs during non-redundant
operation and Table 2-6 describes the possible states of these LEDs during redundant
operation.
Table 2-5 Module LED Display States for the TX32 Resource Module
(Non-Redundant Operation)

Off Green Off Normal operating status.
Off Green Red Failure. Module is operating with an alarm condition. Note: This
sequence of LED occurs when an alarm condition is detected
on individual downstream ports.
Red Green Off Indicates a module hardware failure.
Red Off Red Failure. Module is not operational.
Red Off Off Failure. Power (-48 Vdc) is present at the midplane connector
but not at the module. May indicate a blown fuse on the module.
Off Off Off Module is not receiving power or is not secured in the chassis
through its module ejectors and integrated ejector switch.
(Redundant Operation)

Off Green Off Normal operating status. Module is capable of providing service
to the HFC network.
Off Blinking Off A failure or other disruption has caused the TX32 Standby
Green Module to assume service to the HFC network. The module can
be placed back in service by performing an administrative
switch-over from the TX32 Standby Module to this module.


Off Blinking Red Failure. Module is operating with an alarm condition and service
Green to the HFC network is switched over to the TX32 Standby
Module (if available).
Note: This sequence of LED occurs when an alarm condition is
detected on individual upstream and downstream ports.
Red Blinking Off Indicates a module hardware failure and service to the HFC
Green network is switched over to the TX32 Standby Module (if
available).
Red Off Red Failure. Module is not operational and service to the HFC
network is switched over to the TX32 Standby Module (if
available).
Red Green Red Reset. Module is booting.
Per-Port LEDs
Downstream ports each have two LEDs associated with them to indicate their
operational status. These LEDs are visible on the module front panel and are labeled
Link and Fault.
Port LEDs are grouped vertically. A number to the right each LED group indicates the
channel number associated with the group. The eight downstream channels are
numbered 0 through 7.
Table 2-7 TX32 Downstream Per-Port LED Display States
Link Fault Interpretation

Green Off Normal operating status when configured.
Green Red Operating with an alarm condition detected. Note: An alarm condition
detected for an individual port also causes the System Alarm LED to light.

Table 2-7 TX32 Downstream Per-Port LED Display States

Off Red Failed port. Port is not operational.
Off Off Port is not configured.
TX32 Standby Resource Module LEDs

TX32 Standby Resource Modules have two groups of LEDs that indicate the
operational status of the module. These LED groupings include:
Module LEDs
Per-Port LEDs
Module LEDs
and Alarm.
Table 2-8 describes the possible display states of these LEDs when the module has
assumed service for a primary TX32 module. When the module is operating in
Standby mode, the LEDs should all be Off.
Table 2-8 Module LED Display States for the TX32 Standby Resource Module

Off Blinking Off Normal operating status. Module is in a Standby state.
Green
Off Green Off Normal operating status. Module has assumed service for a
primary TX32 module.
on individual upstream and downstream ports.
Red Off Off Indicates a module hardware failure.

Table 2-8 Module LED Display States for the TX32 Standby Resource Module

Per-Port LEDs
Downstream ports each have two LEDs associated with them to indicate their
operational status. These LEDs are visible on the module front panel and are labeled
Link and Fault.
channel number associated with the group. The eight downstream channels are
numbered 0 through 7.
Table 2-9 TX32 Standby Downstream Per-Port LED Display States

Green Off Normal operating status when configured.
RX48 Resource Module LEDs

RX48 Modules have two groups of LEDs that indicate the operational status of the
module. These LED groupings include:
Module LEDs
Per-Port LEDs

Module LEDs
The Module LEDs are visible on the module front panel and are labeled: Fail, Status, and Alarm.
Table 2-10 describes the possible display states of these LEDs during non-redundant operation.
Table 2-11 describes the possible display states of these LEDs during redundant operation.
Table 2-10 Module LED Display States for the RX48 Resource Module
(Non-Redundant Operation)

Off Green Off Normal operating status when configured.
on individual upstream ports.
Table 2-11 Module LED Display States for the RX48 Resource Module

Off Green Off Normal operating status. Module is capable of providing service
to the HFC network
Off Blinking Off A failure or other disruption has caused the RX48 Standby
Green Module to assume service to the HFC network. The module can
be placed back in service by performing an administrative
switch-over from the RX48 Standby Module to this module.
Off Blinking Red Failure. Module is operating with an alarm condition and service
Green to the HFC network is switched over to the RX48 Standby
Module (if available).
Note: This sequence of LED occurs when an alarm condition is
detected on individual upstream and downstream ports.
Red Blinking Off Indicates a module hardware failure and service to the HFC
Green network is switched over to the RX48 Standby Module (if
available).
Red Off Red Failure. Module is not operational and service to the HFC
network is switched over to the RX48 Standby Module (if
available).
Per-Port LEDs
Upstream port have two LEDs associated with them to indicate their operational
status. These LEDs are visible on the module front panel and are labeled Link and
Fault.
channel number associated with the group. The eight upstream channels are numbered
0 through 7.
Table 2-12 RX48 Upstream Per-Port LED Display States

Diagnostic Ethernet Port LEDs

The RX48 front panel includes an RJ45 connector for use as a 1000BaseT diagnostic
Ethernet Port. The RJ45 connector includes two integrated LEDs, one green and one
yellow. The Green LED provides Link status of the port. The yellow LED indicates
port activity.
RX48 Standby Resource Module LEDs

RX48 Standby Modules have two groups of LEDs that indicate the operational status
of the module. These LED groupings include:
Module LEDs
Per-Port LEDs
Module LEDs
and Alarm.

Table 2-13 describes the possible display states of these LEDs when the module has
assumed service for a primary RX48 module. When the module is operating in
Standby mode, the LEDs should all be Off.
Table 2-13 Module LED Display States for RX48 Standby Resource Module

Off Blinking Off Normal operating status. Module is in Standby state.
Green
Off Green Off Normal operating status. Module has assumed service for a
primary RX48 Module.
on individual upstream ports.
Per-Port LEDs
Upstream port have two LEDs associated with them to indicate their operational
status. These LEDs are visible on the module front panel and are labeled Link and
Fault.
channel number associated with the group. The eight upstream channels are numbered
0 through 7.
Table 2-14 RX48 Standby Upstream Per-Port LED Display States


Table 2-14 RX48 Standby Upstream Per-Port LED Display States

Diagnostic Ethernet Port LEDs

The RX48 Standby front panel includes an RJ45 connector for use as a 1000BaseT
diagnostic Ethernet Port. The RJ45 connector includes two integrated LEDs, one
green and one yellow. The Green LED provides Link status of the port. The yellow
LED indicates port activity.
Rebooting an Individual Resource Module

You can reboot an individual resource module operating in a BSR 64000. This means
that only the individual resource module will start its booting process. Other resource
modules operating in the BSR 64000 continue to operate.
To initiate a reset (reboot) of an individual resource module, use one of the following
methods:
1. Use the CLI reset command for the individual resource module. Refer to Chapter
1 of the BSR 64000 Command Reference Guide.
2. Use the latchdown method to reset the module.
After you initiate a reset, the individual module reboots and the LEDs on its front
panel display their boot sequence.


3
Troubleshooting the CMTS
Overview
This chapter provides troubleshooting solutions to some common DOCSIS network
problems with the following:
Using Flap Lists to Troubleshoot CM Problems
Resolving HFC Network Performance Problems
Resolving Problems on the Upstream Path
Resolving Problems on the Downstream Path
Resolving Cable Modem Problems
Using Flap Lists to Troubleshoot CM Problems

The BSR maintains a database of flapping CMs to assist in locating cable plant
problems. The flap list feature tracks the upstream and downstream performance of all
CMs on the network, without impacting throughput and performance between the CM
and BSR, or creating additional packet overhead on the HFC network.
Refer to the BSR 64000 CMTS Configuration and Management Guide for more
information on configuring flap-list settings.

Viewing Flap List Statistics to Identify Network Health

Flap lists are used to collect statistics for determining CM problems on the network.
There are several different options for sorting flap list statistics. The CM flap list
keeps track of the CM MAC addresses, up and down transitions, registration events,
missed periodic ranging packets, upstream power adjustments on the BSR. This
section describes the different sorting options and describes the command output
fields.
CMs appear in the flap list when any of the following conditions are detected:
The CM re-registers more frequently than the configured insertion time.
Intermittent keepalive messages are detected between the BSR and the CM.
The CM upstream transmit power changes beyond the configured power adjust
threshold.
Follow these steps to view flap list statistics by using different sorting options:
1. Issue the show cable flap-list command, in Privileged EXEC mode, to view all
flap list statistics for CMs:
BSR:7A#show cable flap-list
The following is typical show cable flap-list command output:
MAC ID CableIF Hit Miss Ins CRC Pow Rng Flap Type Time
PS TimeInPS
0019.5ef5.a19a 2/0 U1C5L0 42938 0 0 0 17 0 17 PAdj SUN FEB 09
21:32:44 2014 0 0
dc45.17a2.32df 2/0 U1C0L0 3701 0 0 0 6 0 6 PAdj SUN FEB 09
21:32:30 2014 0 0
3c75.4a33.b133 2/0 U1C0L0 5940 0 4 0 3 0 7 PAdj SUN FEB 09
21:31:03 2014 0 0
2. Issue the show cable flap-list sort-flap command, in Privileged EXEC mode, to
sort the flap list statistics in descending order by the CM flap:
BSR:7A#show cable flap-list sort-flap
The following is typical show cable flap-list sort-flap command output:
PS TimeInPS

Release 8.0.0 Troubleshooting the CMTS

21:32:44 2014 0 0
3c75.4a33.b133 2/0 U1C0L0 5940 0 4 0 3 0 7 PAdj SUN FEB 09
21:31:03 2014 0 0
21:32:30 2014 0 0
3. Issue the show cable flap-list sort-time command, in Privileged EXEC mode, to
sort the flap list statistics in ascending order by the time at which the CM flap
occurred:
BSR:7A#show cable flap-list sort-time
The following is typical show cable flap-list sort-time command output:
PS TimeInPS
21:32:44 2014 0 0
21:32:30 2014 0 0
0021.80f2.f9c5 2/0 U1C5L0 42987 0 0 0 19 0 19 PAdj SUN FEB 09
21:32:09 2014 0 0
4. Issue the show cable flap-list sort-interface command, in Privileged EXEC

mode, to sort the flap list statistics in ascending order by the cable upstream
interface on which the CM flap occurred:
BSR:7A#show cable flap-list sort-interface
The following is typical show cable flap-list sort-interface command output:
PS TimeInPS
2c9e.5fdd.8bb1 5/0 U0C0L0 51 0 0 0 1 0 1 PAdj THU MAR 06
22:38:33 2014 0 0
2c9e.5fdd.8bd6 5/2 U2C0L0 49 0 1 0 0 0 1 Ins THU MAR 06
22:38:34 2014 0 0
2c9e.5fdd.8c7a 5/3 U3C0L0 47 0 1 0 0 0 1 Ins THU MAR 06
22:38:44 2014 0 0
001d.d01e.a5b2 14/0 U0C0L0 54 0 0 0 1 0 1 PAdj THU MAR 06
22:38:26 2014 0 0

0023.74f3.efa0 14/2 U2C0L0 52 0 0 0 1 0 1 PAdj THU MAR 06

22:38:25 2014 0 0
Table 3-1 identifies the flap list command output column field identifications:
Table 3-1 Flap List Command Output Identifications
Field Identification
MAC ID Lists the MAC addresses of the CMs sorted by the flap rate or most
recent flap time. The first six digits in the CM MAC address indicate
the vendor ID of the CM manufacturer, followed by six digits indicating
a unique host address. Each CM MAC address is unique.
Cable IF The cable interface on the BSR 64000 CMTS module. It denotes the
CMTS module slot number, the downstream and the upstream port
number. The flap list data can be sorted based on the upstream port
number which is useful when isolating reverse path problems unique
to certain combining groups.
Hit The Hit and Miss column fields help detect intermittent upstream
issues. The keepalive hits versus misses is the number of times CMs
Miss
do not respond to the MAC layer keepalive messages. If there are a
number of misses, this points to a potential upstream problem.
Ins The Insertions Link process is used by a CM to perform an initial
maintenance procedure to establish a connection with the BSR. The
Ins column is the flapping CMs (re-) insertion count and indicates the
number of times the a CM starts and inserts into the network in an
abnormal way. An abnormality is detected when the time between link
re-establishment attempts is less than the user-configurable
parameter. This function can identify potential problems in the
downstream interface such as incorrectly provisioned CMs repeatedly
trying to re-establish a link.
CRC Displays the count of CRC errors for each cable modem on the
flap-list. This count is also saved in the cable modem history record so
that the count remains valid if cable modems flap. The count is a sum
of all of the CRC errors for each service flow tied to a cable modem.
Pow The Power Adjustment column field shows power adjustment
statistics during station maintenance polling. This column indicates the
number of times the BSR tells a CM to adjust the transmit power more
than the configured threshold. If constant power adjustments are
detected, an amplifier problem is usually the cause. The source of
failure is found by viewing CMs either in front or behind various
amplifiers.

Table 3-1 Flap List Command Output Identifications
Field Identification
Rng Response to RNG-RSP messages from affected CMs. The cable
modem is online and sent a periodic Ranging Request (RNG-REQ)
message to the CMTS, but it received an Abort Ranging reply from the
CMTS.
Flap Total of Pow, Rng, and Ins values.
Type Type of error event which triggered the CM to flap on the last
occurrence.
Time Indicates the most recent time a flap has occurred for a particular CM.
PS Indicates the number of times the CM has entered Partial Service.
TimeInPS Indicates how long the CM functioned in Partial Service mode.

Interpreting Flap List Statistics

This section describes how to interpret flap list statistics in order to troubleshoot the
cable network.
CM activity follows the sequence below:
Power-on
Initial maintenance
Station maintenance
Power-off
The initial link insertion is followed by a keepalive loop between the BSR and CM
and is called station maintenance. When the link is broken, initial maintenance is
repeated to re-establish the link.
Initial maintenance @ Time T1
Station maintenance
Init maintenance @ Time T2
The Ins and Flap counters in the flap list are incremented whenever T2 T1 < N,
where N is the insertion-time parameter configured using the cable flap-list
insertion-time command. The default value for this parameter is 60 seconds.
Use the following cause or symptom observations to interpret flap list activity and
solve CM problems:
Table 3-2 Troubleshooting CM Problems
Cause or Symptom Problem

Subscriber CM shows a lot of flap list CM is having communication problems with the BSR.
activity
CMs have a lot of power adjustment (P-Adj) CMs have problems with their physical upstream paths or
errors. in-home wiring problems.
Use corresponding CMs on the same physical upstream port
interface with similar flap list statistics to quickly resolve
problems outside the cable plant to a particular node or
geographic location.
A high flap list insertion (Ins) time number. Intermittent downstream synchronization loss.
DHCP or CM registration problems.
Low miss/hit ratio, low insertion, low P-adj, Indicates an optimal network situation.
low flap counter and old timestamp.

Table 3-2 Troubleshooting CM Problems
Cause or Symptom Problem

High ratio of misses over hits (> 10%) Hit/miss analysis should be done after the "Ins" count stops
incrementing. In general, if the hit and miss counts are about
the same order of magnitude, then the upstream may be
experiencing noise. If the miss count is greater, then the CM is
probably dropping out frequently and not completing
registration. The upstream or downstream is perhaps not
stable enough for reliable link establishment. Very low hits and
miss counters and high insertion counters indicate
provisioning problems.
High power adjustment counter. Indicates the power adjustment threshold is probably set at
default value of 2 dB adjustment. The CM transmitter step size
is 1.5 dB, whereas the headend may command 0.25 dB step
sizes. Tuning the power threshold to 6 dB is recommended to
decrease irrelevant entries in the flap list. The power
adjustment threshold may be set using the cable flap-list
power-adjust threshold command from Global
Configuration mode. A properly operating HFC network with
short amplifier cascades can use a 2-3 dB threshold.
High P-Adj (power adjustment) This condition can indicate that the fiber node is clipping the
upstream return laser. Evaluate the CMs with the highest
number of correcteds and uncorrecteds first. If the CMs are
not going offline (Ins = 0), this will not be noticed by the
subscriber. However, they could receive slower service due to
dropped IP packets in the upstream. This condition will also
result in input errors on the cable interface.
High insertion rate. If link re-establishment happens too frequently, then the CM is
usually having a registration problem. This is indicated by a
high Ins counter which tracks the Flap counter.
Note: CMs go offline faster than the frequency hop period and can cause the frequency to
stay fixed while CMs go offline. Reduce the hop period to 10 seconds to adjust to the hop
frequency period.

Table 3-3 describes how to interpret flap list statistics. The values in the cable flap list
are collected from the last time the table was cleared or the BSR was reloaded. This
can make the values appear abnormally high. Pay attention to the Time of last
occurence or clear the list if you wish to see current results:
Table 3-3 Flap List Statistic Interpretations
Field Description
Hit and Miss The HIT and MISS columns are keepalive polling statistics between the BSR and the CM.
The station maintenance process occurs for every CM approximately every 10 seconds.
When the BSR receives a response from the CM, the event is counted as a Hit. If the BSR
does not receive a response from the CM, the event is counted as a Miss. A CM will fail to
respond either because of noise or if it is down. CMs which only log Misses and zero Hits are
assumed to be powered off.
Misses are not desirable since this is usually an indication of a return path problem;
however, having a small number of misses is normal. The flap count is incremented if there
are M consecutive misses where M is configured in the cable flap-list miss-threshold
parameter. The parameter value ranges from 1-12 with a default of 6.
Ideally, the HIT count should be much greater than the Miss counts. If a CM has a HIT count
much less than its MISS count, then registration is failing. Noisy links cause the MISS/HIT
ratio to deviate from a nominal 1% or less. High Miss counts can indicate:
Intermittent upstream possibly due to noise
Laser clipping
Common-path distortion
Ingress or interference
Too much or too little upstream attenuation
P-Adj The station maintenance poll in the BSR constantly adjusts the CM transmit power,
frequency, and timing as necessary. The Power Adjustments (P-Adj) column indicates the
number of times the CMs power adjustment exceeded the threshold value. The power
adjustment threshold may be set using the cable flap-list power-adjust threshold
command with a value range of 0-10 dB and a default value of 2 dB. Tuning this threshold is
recommended to decrease irrelevant entries in the flap list. Power Adjustment values of 2 dB
and below will continuously increment the P-Adj counter. The CM transmitter step size is 1.5
dB, whereas the headend may command 0.25 dB step sizes. Power adjustment flap strongly
suggests upstream plant problems such as:
Amplifier degradation
Poor connections
Thermal sensitivity
Attenuation problem

Table 3-3 Flap List Statistic Interpretations
Field Description
Flap The Flap counter indicates the number of times the CM has flapped. This counter is
incremented when one of the following events is detected:
Unusual CM insertion or re-registration attempts. The Flap and the Ins counters are
incremented when the CM tries to re-establish the RF link with the BSR within a period of
time that is less than the user-configurable insertion interval value.
Abnormal Miss/Hit ratio The Flap counter is incremented when N consecutive Misses are
detected after a Hit where N can be user-configurable with a default value of 6.
Unusual power adjustment The Flap and P-adj counters are incremented when the CMs
upstream power is adjusted beyond a user-configurable power level.
Time Time is the timestamp indicating the last time the CM flapped. The value is based on the
clock configured on the local BSR. When a CM meets one of the three flap list criteria, the
Flap counter is incremented and Time is set to the current time.
Tips for Administrating Flap Lists

Follow these suggestions for administrating flap lists:
Write script(s) to periodically poll the flap list.
Analyze and identify CM trends from the flap list data.
Query the billing and administrative database for CM MAC address-to-street
address translation and generate reports. These reports can then be given to the
Customer Service Department or the cable plants Operations and Maintenance
Department. Maintenance personnel use the reports to see patterns of flapping
CMs, street addresses, and flap statistics that indicate which amplifier or feeder
lines are faulty. The reports also help troubleshoot problems in the downstream
and/or upstream path, and determine if a problem is related to ingress noise or
equipment.
Save the flap list statistics to a database server at least once a day to keep a record
of flap list statistics which includes upstream performance and quality control
data. These statistics can be used again at a later time to evaluate trends and solve
intermittent problems on the HFC networks. Once the flap list statistics are
backed up daily on the database server, the flap list statistics can be cleared.

Resolving HFC Network Performance Problems

If Cable Modem (CM) subscribers can use their data connection, but experience slow
network performance during activities such as Web surfing and exchanging files and
the problem is only occurring on certain upstreams or downstreams, the problem may
be the following:
Downstream Signal Reflected on Upstream Path
Slow Performance Detected on Upstream Port
The following sections describe how to handle these problems.
Downstream Signal Reflected on Upstream Path

Follow these steps to correct common path distortion that occurs when the
downstream signal is reflected on the upstream path:
1. Check for corrosion or loose connections on common point contacts such as
F-connectors, G-connectors, screw-down seizures, or terminators.
2. Inspect connections for poor craftsmanship on common point contacts.
3. If one or more poor or damaged contacts have been detected, these contacts may
develop an electronic potential that functions like a tiny diode. This situation
causes the forward (downstream) signals to mix with the return (upstream) signal
causing unwanted beat signals on the spectrum.
4. Use a spectrum analyzer to check for unwanted beat signals on the upstream path
to determine if common path distortion is occurring. This impairment happens on
the spectrum at points where both the upstream and downstream signals are
present.
5. Do the following tasks to repair damaged contacts:
a. Ensure that contacts are made of similar metals.
b. Ensure that contacts are clean.
c. Ensure that contacts are securely fastened.
d. Replace or repair defective equipment, if necessary.
Slow Performance Detected on Upstream Port

Subscriber CMs connected to an upstream port are experiencing poor or slow
performance.

Follow these steps to gather information and correct slow performance related to a
specific upstream port:
1. Determine the physical location or MAC addresses of the CMs having problems.
2. Issue the interface cable command, in Global Configuration mode, to enter the
cable interface:
BSR:7A(config)#interface cable <X/Y.N>
where:
X is the slot number.
Y is the port number.
.N is the subinterface number from 1 to 127.
3. Issue the show interfaces cable upstream signal-quality command, in Global
mode, to determine the upstream signal quality to determine the signal-to-noise
ratio and upstream packet statistics:
BSR:7A(config-if)#show interfaces cable <X/Y/Z> upstream <NUM>
signal-quality
where:
Z is the subinterface number.
NUM is the upstream channel number.
Figure 3-1 provides an example of signal quality statistics for an upstream port.
ifIndex 164098
includesContention 0
unerroreds 212730
correctables 0
uncorrectables 1
signalToNoise 321
microReflections 0
equalData
Figure 3-1 Upstream Signal Quality Statistics

4. View the signal quality statistics for the upstream interface. If there is a high
number of unerroreds (uncorrupted packets), the SignalToNoise is high and the
microReflections are high, the upstream signal-quality is good.
Table 3-4 describes the signal quality statistics:
Table 3-4 Signal Quality Statistics
Field Description
ifIndex Cable interface number.
includesContention Number of CMs included in contention for mini-slots.
unerroreds Number of unerrored packets on cable interface.
correctables Number of corrected error packets received through this upstream
interface.
uncorrectables Number of packets that cannot be corrected.
signalToNoise The Signal-to-Noise ratio described in decibel (dB).
microReflections Total microreflections including in-channel response as perceived
on this interface, measured in dB below the signal level. This
object is not assumed to return an absolutely accurate value, but
should give a rough indication of microreflections received on this
interface.
5. If there is a large number of correctables there is a physical problem with the

upstream signal. Use a spectrum analyzer to measure the signal to noise ratio for
the upstream path. For 16 QAM and QPSK, the optimum signal-to-noise ratio is
33 dB or greater.
The signal-to noise ratio learned from the spectrum analyzer may indicate the
following conditions:
If there is under a 10 dB loss in signal quality, the cable interface has the
ability to compensate by correcting packets.
If there is more than a 10 dB loss in signal quality, the signal is degraded to
the point where it can no longer successfully carry data and the noise
problem has to be manually investigated and corrected.

A high number of correctables (corrected packets) and uncorrectables

(uncorrected, dropped packets) occurs when the signal-to-noise ratio is
around 25 dB for QAM 16 and QPSK. The problem has to be manually
troubleshot and corrected. See if errors are incrementing from fixed points in
time in a higher than normal way.
The number of micro reflections expressed in dB, can correlate to a high
number of corrupted packets (erroreds) and fixed packets (correcteds), or can
be attributed to burst errors.
If there needs to be manual intervention to correct the upstream signal-to-noise ratio,
follow these steps to resolve a bad upstream signal-to-noise ratio:
1. Check for bad optical amplifiers in the HFC network.
2. Check for defective equipment in the HFC network.
3. Determine if there is a cable that is physically cracked or damaged in such a way
to cause external ingress from a variety of sources is entering into the network.
4. Look for loose connections.
5. Study the HFC network topology and look for flaws that may be causing
additional ingress noise.
6. If there is too much ingress noise detected, increase the interleave depth. Issue the
cable downstream interleave-depth command, in TX32 Downstream
Configuration mode, to set the downstream port interleave depth.
BSR:7A(config)#cable downstream port 9/0
BSR:7A(config-ds)#cable downstream interleave-depth {8 | 16 | 32 | 64 |
128}
where:
9/0 is the TX32 downstream slot and port number.
8 is the number of taps with 16 increments.
128 is the number of taps with 1 increment.

7. If the cable plant is clean and the interleave depth is set too high, there may be too
much latency on the downstream path causing CMs to experience slower
performance. Issue the cable downstream interleave-depth command, in TX32
Downstream Configuration mode, to decrease the interleave depth.
8. Determine if there are too many nodes that are combined on an upstream port.
Combining too many nodes can affect the signal-to-noise ratio.
9. Check the individual nodes that are combined on an upstream port that is
experiencing ingress problems. For example, there may be three nodes that have
an acceptable signal-to-noise ratio, but the fourth node has a bad signal-to-noise
ratio that is cascading into the other three nodes and causing poor performance on
the upstream port.
10. Determine if impulse and electrical ingress noise is entering the network from
electrical sources within a home, such as hair dryers, light switches, and
thermostats; or from high-voltage lines that run near cabling in the network.
Resolving Problems on the Upstream Path

When the upstream port fault LED is red, the upstream port is not operating and is not
receiving data from the CM subnetwork.
Refer to the procedures in this section to troubleshoot an upstream port problem:
Unacceptable Upstream Signal-to-noise Ratio Detected
Upstream Power Level Too Low or High
Unacceptable Upstream Signal-to-noise Ratio Detected

If too much noise is detected on the upstream path a condition called noise funneling
occurs. Noise funneling occurs when the cumulative upstream noise from anywhere
on the HFC network becomes concentrated on the cable headend.
For example, the HFC branch and tree network architecture works in the following
ways:
Downstream: the trunk feeds the branches. As the signal propagates from the
trunk, the signal weakens.
Upstream: the branches feed the trunk. As the signal propagates from the
branches, noise and ingress increase.

Follow these steps to troubleshoot ingress noise on the upstream path:

1. Issue the show cable upstream command in Interface Configuration mode to
determine the modulation profile number for an upstream port:
BSR:7A(config-if)#show cable upstream <X/Y/Z>
where:
Z is the subinterface number.
2. Issue the show cable modulation-profile command, in Privileged EXEC mode,
to view the modulation profile for the upstream port to determine modulation
profile used on the upstream interface:
BSR:7A#show cable modulation-profile <1-1000>
where:
1-1000 is the modulation profile number identified using the show cable
upstream command.
3. View the show cable modulation-profile command output to determine whether
the upstream modulation profile is appropriate.
4. Issue the show interfaces cable upstream signal-quality command, in
Privileged EXEC mode, to determine the signal quality on the upstream port:
BSR:7A#show interfaces cable <X/Y.N> upstream <X/Y> signal-quality
where:
X/Y is the upstream port and logical channel number.
Signal quality statistics for all the upstream interfaces (ports) displays.
5. View the signal-quality statistics for the specific upstream interface. If there is a
high number of unerroreds (uncorrupted packets), the upstream signal-quality is
good.

6. If there is a large number of correctables there is a physical problem with the

upstream signal. Use a spectrum analyzer to measure the signal to noise ratio for
the upstream path. For 16 QAM and QPSK, the optimum signal-to-noise ratio is
33 dB or greater.
If the loss in signal quality is less than 10dB, the cable interface can
compensate by correcting packets.
If the loss in signal quality is greater than 10 dB, the signal is degraded to the
point where it can no longer carry data, and you must troubleshoot and
correct the noise problem.
A high number of correctables (corrected packets) and uncorrectables
(uncorrected, dropped packets) occurs when the signal-to-noise ratio is
approximately 25 dB for QAM 16 and QPSK. You must manually
troubleshoot and correct the problem. See if errors increment at a specific
time at a higher than expected rate.
The number of microreflections (expressed in dB) can signify a high number
of corrupted packets (erroreds) and fixed packets (correcteds).
Follow these steps to manually resolve an upstream signal-to-noise ratio problem:
1. Inspect optical amplifiers in the HFC network to make sure they are working
properly.
2. Make sure all HFC network equipment is working properly.
3. Inspect cables for damage.
4. Secure all cable connections.
5. Review the HFC network topology and identify any flaws that may cause
additional ingress.
6. Determine if there are too many nodes on an upstream port. Combining too many
nodes can affect the signal-to-noise ratio.
7. Check the individual nodes on an upstream port that is experiencing ingress
problems. For example, three nodes may have an acceptable signal-to-noise ratio,
but the fourth node might have a bad signal-to-noise ratio that is cascading into
the other three nodes and causing poor performance on the upstream port.

electrical sources within a home (such as hair dryers, light switches, and
thermostats), or from high-voltage lines near network cabling.
Upstream Power Level Too Low or High

The cable interface controls CM output power levels to meet the desired upstream
input power level at the CMTS. Input power level adjustments to an operational
upstream port compensate for cable headend path loss between the optical receiver
and the upstream RF port. This section describes how to troubleshoot physical
problems that may affect power levels on the upstream channel.
This section also describes how to configure the upstream input power level when
problems occur. The upstream input power level is configured in either an absolute or
relative mode. If the upstream input power level is set in relative mode, the input
power level changes when the upstream channel width is changed. If the upstream
input power level is set to the absolute mode, the input power level does not change
when the upstream channel width is changed. Defining the input power level in
absolute mode could possibly cause upstream return lasers to clip on a completely
populated upstream channel. In addition, having the input power level set to absolute
mode could cause low upstream SNR or laser clipping when Advanced Spectrum
Management makes channel width changes.
Caution must be used when the input power level is increased in absolute mode
because the CMs on the HFC network increase their transmit power level by 3 dB for
every incremental upstream channel bandwidth change, causing an increase in the
total power on the upstream channel and possibly violating the upstream return laser
design parameters.
Table 3-5 describes how the upstream channel bandwidth setting corresponds to the
input power-level range and default power-level range for a specific upstream
channel.
Table 3-5 Upstream Input Power Level Range Parameters
Channel Bandwidth Default Range

200 KHz -1 dBmV -16 to +14 dBmV
400 KHz +2 dBmV -13 to +17 dBmV
800 KHz +5 dBmV -10 to +20 dBmV
1.6 MHz +8 dBmV -7 to +23 dBmV
3.2 MHz +11 dBmV -4 to +26 dBmV

Follow these steps to troubleshoot upstream power-level problems:

1. Check all upstream passive equipment, such as combiners, couplers, and
attenuators and cabling for flaws. The upstream signal may be weak because of
low input power levels on a portion or portions of the upstream spectrum (5 to 42
MHz). This is known as a frequency response problem in the HFC network. The
cause of a frequency response problem may be defective passive equipment, or
damaged cable on the upstream path.
2. Verify that the path between the optical receiver and CMTS matches the design
specification.
3. Inspect amplifiers if there is an attenuation problem on the upstream path. View
CMs that proceed or follow an amplifier in the upstream path to isolate the
defective amplifier and replace or repair it. Look for amplifier degradation.
Improperly configured amplifiers can degrade digital data signals. The larger the
network, the higher the possibility of amplifier noise affecting the signals.
4. Be aware of thermal sensitivity. Signal loss over coaxial cable is affected by
temperature. This can cause variations of 6 to 10 dB per year.
5. Inspect the upstream physical cabling and passive equipment to be sure it is in
good condition. If the problem persists, check the upstream input power-level
configuration.
6. Issue the cable upstream power level command, in Port Configuration mode, to
adjust the upstream input power level. Use the default argument to have the
power level adjusted in relative (or power-per-hertz) mode. Use the command
without the default argument to have it operate in absolute mode. Adjustments
are expressed in tenths of a dB.
BSR:7A(config-us)#cable upstream <NUM> power-level [default <-150 -
+150>]
<-130 - +230>
where:
NUM is the number of the upstream port.
-150 - +150 is the number of tenths of a dB above or below the default input
power level.
-130 - +230 is the number of tenths of a dB above or below the input power
level in absolute mode.

Resolving Problems on the Downstream Path

When the downstream port fault LED is red, the downstream port is not operating and
is not sending data to the CM subnetwork.
Refer to the procedures in this section to troubleshoot a downstream port problem:
Unacceptable Downstream Signal-to-Noise Ratio Detected
Downstream Power Level Too Low or High

Unacceptable Downstream Signal-to-Noise Ratio Detected

Follow these steps to identify problems associated with an unacceptable downstream
signal-to-noise ratio:
1. Issue the show interface cable downstream command to determine the type of
Quadrature Amplitude Modulation (QAM) that is used on the downstream
interface:
BSR:7A#show interface cable <X/Y.N> downstream <NUM>
where:
NUM is the downstream port number.
2. View the qamMode field in the show interface cable downstream command
output. The qamMode field displays whether the downstream modulation is 64
QAM or 256 QAM.
3. Isolate the CM on the network that is experiencing ingress problems, such as
degraded performance or connection difficulties.
4. Use a spectrum analyzer to determine the downstream signal quality. For 256
QAM, the typical minimum signal-to-noise ratio is 33 dB or greater. For 64
QAM, the typical minimum signal-to-noise ratio is 25 dB or greater.
If the loss in signal quality is less than 10 dB, the cable interface can
compensate by correcting packets.
If the loss in signal quality is greater than 10 dB, the signal is degraded to the
point where it can no longer carry data, and you must troubleshoot and
correct the noise problem.
A high number of corrected packets and uncorrected, dropped packets occurs
when the signal-to-noise ratio is approximately 25 dB for 256 QAM, and 20
dB for 64 QAM. You must manually troubleshoot and correct the problem.
See if errors increment at a specific time at a higher than expected rate.

The micro reflections number (expressed in dB) represents a specific type of

noise on the cable interface. A high value for micro reflections will
correspond to a high number of corrupted packets (erroreds) and fixed
packets (correcteds).
Follow these steps to manually resolve a downstream signal-to-noise ratio problem:
1. At the cable headend, make sure that the power levels of adjacent channels do not
interfere with the downstream channel.
2. Inspect optical amplifiers in the HFC network to make sure they are working
properly.
3. Make sure all HFC network equipment is working properly.
4. Inspect cables for damage.
5. Check for laser clipping on fiber-optic transmitters on the downstream path from
the cable headend to the CMs. If the downstream power level is too high for the
downstream path, laser clipping can occur. Laser clipping prevents the
transmission of light, which can cause bit errors in downstream transmissions. If
a laser experiences excessive input power for even a fraction of a second, clipping
can occur. Refer to the Downstream Power Level Too Low or High on page 3-21
section for more troubleshooting information.
6. Secure all cable connections.
7. Review the HFC network topology to identify any flaws that may cause
additional ingress.
electrical sources within a home (such as hair dryers, light switches, and
thermostats) or from high-voltage lines near network cabling.
Downstream Power Level Too Low or High

Follow these steps to troubleshoot downstream power-level problems:
1. Check all downstream passive equipment (such as combiners, couplers, and
attenuators) and cabling for flaws. The downstream signal may be weak because
of a low power level on a portion of the downstream spectrum (88-860 MHz).
This is known as a frequency response problem on the HFC network. The cause
of a frequency response problem may be defective passive equipment, or
damaged cable on the downstream path.

2. If the downstream physical cabling and passive equipment is in good condition

and the problem persists, check the downstream power-level configuration.
Issue the cable downstream power-level command to set the downstream power
level to a value from 44 to 60 decibels per millivolt (dBmV):
BSR:7A(config-ds)#cable downstream <NUM> power-level {440-600}
where:
NUM is the downstream port number.
440-600 is the downstream power level (expressed in tenths of dBmV). The
upper limit is dependent upon the channel mode (number of channels on the
port).
3. Check for laser clipping on fiber-optic transmitters on the downstream path from
the cable headend to the CMs. If the downstream power level is set too high for
the downstream path, laser clipping can occur. Laser clipping distorts the light
transmission, which can cause high bit error rates on the downstream path.
4. Inspect amplifiers if there is an attenuation problem on the downstream path.
View CMs that proceed or follow an amplifier in the downstream path to isolate
the defective amplifier and replace or repair it. Look for amplifier degradation.
Improperly configured amplifiers can degrade digital data signals. The larger the
network, the higher the possibility of amplifier noise affecting the signals.
5. Be aware of thermal sensitivity: signal loss over coaxial cable is affected by
temperature. This can cause variations of 6 to 10 dB per year. The downstream
power level may need seasonal adjustment.

Resolving Cable Modem Problems

If CMs are not registering and cannot communicate with the cable interface, the
problem may be one of the following:
Misconfigured Authentication String or Key
CM Does Not Reply to Station Maintenance Requests
CM is Offline
CM Cannot Obtain an IP Address
Provisioning Problems Cause CMs Not to Register
CM Does Not Respond to SNMP Messages
Misconfigured Authentication String or Key

All CMs must return a known authentication text string or key to register with the
cable interface for network access. If the text string or key is improperly entered, the
CMs cannot authenticate and register with the cable interface.
Follow these steps to re-enter the shared authentication text string or key so that the
CMs can authenticate and register with the cable headend:
1. Ensure that the authentication string or hexadecimal key in the CM configuration
file matches the authentication string or hexadecimal key configured on the
CMTS. CMs cannot register with the CMTS if authentication parameters do not
match.
2. The default authentication parameters are enabled, but have a null value by
default. Authentication parameters need to be set on the CMTS and the CMs to
ensure security on the HFC network. Issue the cable shared-secret command, in
Global Configuration mode, to activate authentication on the CMTS so all CMs
return a known text string to register with the CMTS for network access:
BSR:7A(config)#cable shared-secret {0 <string> | 7 <hex-string>}
where:
0 specifies that an UNENCRYPTED string is specified in string.
7 specifies that an ENCRYPTED string is specified in hex-string.
string is the UNENCRYPTED authentication key, in alpha-numeric text
format (enclosed in double quotes if the string contains spaces).

hex-string is the ENCRYPTED authentication key, in hexadecimal format.
Caution: Ensure that the authentication string or hexadecimal key in the CM configuration
file matches the authentication string or hexadecimal key configured on the CMTS. CMs
cannot register with the CMTS if authentication parameters do not match.
By default the shared-secret authentication is active with a null value, and does
not appear in the running configuration. Once the shared-secret has been defined
to a value other than null, it will appear in the running configuration as a
hexadecimal string regardless of whether it was entered encrypted or not.
3. Issue the no cable shared-secret command, in Global Configuration mode, to
restore the default CM authentication, which is a null value:
BSR:7A(config)#no cable shared-secret {0 <string> | 7 <hex-string>}
CM Does Not Reply to Station Maintenance Requests

If a CM does not reply to station maintenance requests after 16 retries, the cable
interface assumes that it is offline. The cable interface marks the CM Service
Identifier (SID) state offline and removes the SID from the ranging list.
Follow these steps to solve CM station maintenance registration problems:
1. Issue the show cable modem command, in Privileged EXEC mode, to identify
registration problems concerning CMs connected to the cable interface:
BSR:7A#show cable modem
2. Issue the show cable modem detail command to view the status of a CM that is
marked offline by the cable interface:
BSR:7A#show cable modem detail [<mac> | <X/Y.N>]
where:
mac is the hardware address of the cable modem.
The SM Exhausted Count value in the command output is the number of times a
CM was dropped because it did not reply to station maintenance requests.

The SM Aborted Count value in the command output is the number of times the
CM was dropped because of unacceptable operating parameters. This can occur if
the power level is outside the acceptable range, or the timing offset changes. The
command output indicates the times when this occurs.
CM is Offline
If a CM appears to be offline, disconnected from the network, or unable to register,
ping the CM to determine if there is any connectivity between the cable interface and
the CM. A CM may appear to be offline if it does not show an IP address; however, it
may still be online.
This section refers to the generic ping command. When applicable, the ping6
command can be substituted for CMs registering in an IPv6 or dual IPv4/IPv6 mode.
1. Issue the ping command in Privileged EXEC mode to ping a specific CM IP
address or hostname to determine connectivity:
BSR:7A#ping {<A.B.C.D> | <Hostname>}
where:
A.B.C.D is the CMs IP address.
Hostname is the DNS hostname of the CM.
2. If there is no IP level connectivity, but you suspect the CM has connectivity at the
MAC layer, issue the ping docsis command in to ping a specific CM at the MAC
layer:
BSR:7A#ping docsis {<mac> | <A.B.C.D>}
where:
mac is the CMs hardware address.
Note: Be sure to use the correct MAC or IP address of the CM.
3. Determine if the CM is having registration problems by using the debug cable

reg command:

BSR:7A#debug cable <X/Y> reg

where:
X/Y is the slot and port where the CM is trying to register.
Caution: Be careful using this command if a large number of CMs are trying to register.
Multiple debug messages are returned for each CM attempt.
Use the no debug cable <X/Y> reg or undebug all comand when you are done.
4. Issue the clear cable modem reset command in Privileged Exec mode to reset a
specific CM by using its MAC address:
BSR:7A#clear cable modem [<mac> | <A.B.C.D>] reset
where:
mac is the CMs hardware address.
Note: It may take up to 30 seconds for the CM to timeout and start the registration sequence.
5. If some CMs are unable to obtain an IP address and they are offline, issue the
clear cable modem offline reset command to remove all offline CMs from the
BSR database:
BSR:7A#clear cable modem offline [<mac> | slot <NUM>]
where:
mac optionally removes the offline CMs MAC address.
NUM optionally removes the offline CMs on a specified CMTS slot number.
CM Cannot Obtain an IP Address

When a CM is unable to obtain an IP address it cannot successfully register and
connect to the HFC network.
Follow these steps to reset the CM:

1. Issue the debug cable command in Privileged Exec mode to determine if a CM or

several CMs are having registration problems on a specified CMTS module:
BSR:7A#debug cable <NUM>
where:
NUM is the CMTS slot number.
Caution: Be careful using this command if a large number of CMs are trying to register.
Multiple debug messages are returned for each CM attempt.
Use the no debug cable <NUM> or undebug all comand when you are done.
2. Issue the clear cable modem command, in Privileged Exec mode, to reset the
problem CM:
BSR:7A#clear cable modem <mac> reset
where:
mac is the CM hardware address.
Note: It may take up to 30 seconds for the CM to timeout and start the registration sequence.
3. If the CM has an IP address and must be reset, you can issue the clear cable
modem reset command in Privileged Exec mode as shown below:
BSR:7A#clear cable modem <A.B.C.D> reset
where:
A.B.C.D is the modems IP address.
4. If CMs still cannot obtain an IP address, there may be a problem with the DHCP
server or the provisioning configuration. Ensure that the DHCP server is
operational and configured correctly. Refer to Provisioning Problems Cause CMs
Not to Register on page 3-29 for more information.
5. To verify that a particular CM obtained an IP address, enter the show cable
modem command in Privileged Exec mode:

BSR:7A#show cable modem <mac>

where:
mac is the CM MAC address.

Provisioning Problems Cause CMs Not to Register

It is important to understand the basic communication process between the CM, cable
interface on the BSR, and the DHCP server to troubleshoot provisioning problems.
Depending on whether you are using IPv4, IPv6, or both, the types of messages may
be different, but the overall process will be the same: DHCP to get an IP address,
optionally NTP to get the current time, and TFTP to get the CM configuration file.
This document refers to the IPv4 DHCP message types Discover, Offer, Request, and
Ack, but can generally be equally applied to the DHCPv6 message types of Solicit,
Advertise, Request, and Reply.
The DHCP portion of the CM registration process works as follows:
1. The CM sends a Discovery or Solicit message asking for an IP address and
options such as the default gateway, TFTP, configuration file, and so on, which is
forwarded by the BSR acting as a DHCP Relay Agent to the configured DHCP
servers.
2. Each DHCP server sends an Offer or Advertise message via the Relay Agent
(BSR) to the CM offering an IP address and other parameters.
3. The CM sends a Request message to the DHCP servers requesting the use of the
IP address received in one of the offer messages.
4. The DHCP server which offered the IP address sends an Acknowledgement or
Reply message confirming that the CM can use the parameters offered.
Follow these steps to identify CM registration problems associated with provisioning:
1. Issue the show cable modem command, in Privileged EXEC mode, to review
information about a CM attempting to register with the cable interface:
BSR:7A#show cable modem <mac>
2. View the Connect State column in the show cable modem command output.
3. Determine whether the cable interface is receiving a DHCP discover message
from the CM. If the cable interface has received a DHCP discover message from
the CM, the dhcp(d) state will be displayed in the Connect State column.
4. Issue the debug ip udp dhcp command in Privileged Exec mode to either display
all DHCP traffic traversing the cable interface or DHCP traffic traversing a
specified DHCP client:
BSR:7A#debug ip udp dhcp <mac>
where:

mac is the DHCP client MAC address.
Caution: Do not use this command for all DHCP traffic if a large number of CMs are trying to
register. Be sure to include the <mac> argument in this case.
Use the no debug ip upd dhcp <mac> or undebug all comand when you are done.
5. If the cable interface is receiving a DHCP discover message from the CM,
determine if the cable interface is forwarding DHCP discover messages to the
DHCP server by checking if the DHCP sever is receiving DHCP discover packets
and if it is sending DHCP offer packets to the CM.
a. If the DHCP server is receiving DHCP discover messages from the CM,
the DHCP server can reply by sending a DHCP offer. However, if the
DHCP server is not receiving DHCP discover messages from the CM
through the cable interface, the cable helper IP address may not be
configured properly.
b. If the DHCP server is receiving DHCP discover messages from the CM,
but is not sending DHCP offer messages, the DHCP server is
misconfigured. Make sure that the DHCP is configured to service the
subnet associated with the CM.
c. The DHCP server could be attempting to send offer messages, but may
not have a route. Verify that you can ping from the DHCP server to the
CM loopback address on the BSR, or from the BSRs CM loopback
address to the DHCP server using the source argument to the ping
command:
BSR:7A#ping <DHCP server address> source <CM loopback IP address>
d. If the CM receives a DHCP offer, the CM sends a DHCP request message
to the DHCP server so that it can use the information received in the offer
message. When the DHCP server acknowledges the request, it provisions
the CM with an IP address so that the CM can use TFTP to continue the
registration process. If the CM is able to obtain an IP address, but is
unable to complete the registration process, make sure that the TFTP
server IP address and CM configuration file name, including the full path
from the TFTP root directory, are properly configured.

6. If there is no communication between the TFTP server and the cable interface,
determine if the TFTP server is running and reachable.
7. If CMs are registering successfully but there is no Customer Premises Equipment
(CPE) connectivity, the helper IP address for the CPE might be incorrect. Issue
the cable helper-address host command, in Interface Configuration mode, to set
the helper IP address for the CPE behind a CM to forward only UDP broadcasts:
BSR:7A(config-if)#cable helper-address <A.B.C.D> host
where:
A.B.C.D is the IP address of the destination TFTP server.
8. If the DHCP server is operating correctly, but a CM remains unresponsive, reset
the CM so that it can obtain a new IP address.
Issue the clear cable modem reset command in Privileged EXEC mode to reset a
CM:
where:
mac is the CMs MAC address.
Note: Be sure to correctly enter the CM MAC address in the command. It may take up to 30
seconds for the CM to timeout and start the registration sequence.
9. If you have exhausted all the provisioning troubleshooting possibilities for CM

registration problems, refer to other sections in this chapter for help on
troubleshooting the upstream path from the CM to the cable interface.
CM Does Not Respond to SNMP Messages

In most cases when a CM does not respond to SNMP, it is due to a misconfigured CM
configuration file. At a minimum, the CM configuration file must contain the
community string for read access on the cable interface. Check the CM configuration
file on the BSR to ensure that it is valid.
Once the CM configuration file is correct, follow these steps to reset a CM that is not
responding to SNMP messages, so that it will retrieve the newest version of the
configuration file:

1. Issue the clear cable modem reset command, in Privileged Exec mode, to reset
the CM so that it can respond to SNMP messages:
Note: Be sure to correctly enter the CM MAC address. It may take up to 30 seconds for the
CM to timeout and start the registration sequence.
2. Issue the clear cable modem all reset command, in Privileged Exec mode, to
reset all CMs so that they can respond to SNMP messages:
BSR:7A#clear cable modem all reset
3. Issue the show cable modem command, in Privileged Exec mode, to verify that
the clear cable modem all reset command enabled CMs to respond to SNMP
messages.
4. Make sure that the community names for SNMP Version 1 and SNMP Version 2
and the user name for SNMP Version 3 are correct.

4
Troubleshooting Basic
Routing Problems
Overview
This chapter provides troubleshooting solutions to some common TCP/IP
internetwork problems:
Resolving Host Connectivity Problems
Handling Routing Problems
Misconfigured Router
Handling a Misconfigured Access List
Access List and Filter Misconfigurations
Handling UDP Broadcast Forwarding Problems
Resolving Host Connectivity Problems

The following sections provide instructions for resolving local and remote host
connectivity problems:
Default Gateway Configuration Problems

Misconfigured or Missing Default Routes

Incomplete DNS Host Table
DNS Not Running
Default Gateway Configuration Problems

If a local host cannot access a remote host, the default gateway might not be specified,
or the default gateway could be incorrectly configured on local or remote host.
Note: This chapter presents host configuration solutions from a UNIX perspective. If you are
working with a PC, consult the corresponding documentation to determine how to set the
default gateway IP address.
Follow these steps to configure a default gateway for a local or remote host:
1. Issue the netstat -rn command, at the UNIX prompt, to determine whether the
local and remote hosts have a default gateway:
unix-host% netstat -rn
Check the output of this command for a default gateway specification.
2. If the default gateway specification is incorrect or not present, change or add a
default gateway using the route add default command, at the UNIX prompt, on
the local host:
unix-host% route add default <A.B.C.D> <n>
where:
A.B.C.D is the IP address of the default gateway (the router local to the host).
n indicates the number of hops to the specified gateway.
Note: You may need to reboot the host for this change to take effect.
3. You should specify a default gateway as part of the boot process. Specify the IP
address of the gateway in the /etc/defaultrouter UNIX host file. This filename
might be different on your UNIX system.

Release 8.0.0 Troubleshooting Basic Routing Problems
Misconfigured or Missing Default Routes

Follow these steps to resolve misconfigured or missing default routes:
1. Issue the netstat -rn command, at the UNIX prompt, to view the host routing
table (if the host is routed):
unix-host% netstat -rn
The entry with the destination default denotes the default route.
2. The default route entry should specify the router that has the route to the remote
host. If there is no default route entry, issue the route add default command, at
the UNIX prompt, to manually configure the default gateway:
unix-host% route add default <A.B.C.D> <n>
where:
A.B.C.D is the IP address of the default gateway (the router local to the host).
n indicates the number of hops to the specified gateway.
Note: You may need to reboot the host for this change to take effect.
Incomplete DNS Host Table

If the Domain Name Server (DNS) receives a lookup request for a host name that is
not in its cache, it cannot reply to the request, and the client cannot establish a
connection.
Follow these steps to complete the DNS host table:
1. Enter the following host command at the UNIX prompt:
unix-host% host <A.B.C.D>
where:
A.B.C.D is the IP address of a server, router, or other network node.

2. If a "Host not found" message displays, but you can open the connection using
the host's IP address rather than its name, try connecting to other hosts using their
names. If you can open connections to other hosts using their names, the host
table might be incomplete. Add hostname-to-address mappings to the DNS cache
for every host on the network.
3. If any connections cannot be opened using host names, the DNS might not be
running. Refer to DNS Not Running on page 4-4, for more troubleshooting
information.
DNS Not Running

If issuing the host command, at the UNIX prompt, returns a "Host not found"
message, but you are able to open a connection using the host's IP address, DNS
might not be running. Consult the DNS software documentation or your system
administrator for information on configuring and enabling DNS.
Handling Routing Problems

The following sections describe how to re-enable a problem router and correct
network router configuration problems that can occur after a new interface is added to
a router:
Problem Router
Routing Interface Down
Problem Router
Follow these steps to enable a router that is having problems:
1. Issue the traceroute command, in Privileged EXEC mode, to isolate the problem
router:
BSR:7A#traceroute [<A.B.C.D> | <Hostname> | vrf <WORD>]
where:
A.B.C.D is the destination IP address or host name on the command line.
Hostname is the destination Domain Name Server (DNS) hostname.
WORD is the optional VPN Routing and Forwarding table (VRF) to use for
tracing.

Table 4-1 describes the traceroute command output field descriptions:
Table 4-1 traceroute Command Output Field Descriptions
Field Description
nn/msec For each node, the round trip time in milliseconds for the specified
number of probes.
* The probe timed out.
? Unknown packet type.
Q Source quench.
P Protocol unreachable.
N Network unreachable.
U Port unreachable.
H Host unreachable.
2. Once you isolate a problem router, determine whether routing is enabled on the
BSR. Issue the show ip route command, in Privileged EXEC mode, to view the
routing table:
BSR:7A#show ip route
Examine the command output to see whether the routing table is populated with
routing information. If the command output displays no entries, the routing
information is not being exchanged.
3. If the routing information is not being exchanged, a routing interface may not be
configured.
4. Issue the interface command to configure a routing interface on the Gigabit
Ethernet module(s):
BSR:7A(config)#interface gigaether <X/Y>
where:
X is the Gigabit Ethernet module slot number.
Y is the ethernet port.
5. Issue the ip address command to set the IP address and subnet mask for a routing
interface.

For example:
BSR:7A(config-if)#ip address 10.10.10.92 255.255.255.0
6. Issue the router command, in Global Configuration mode, to enable the proper
routing protocol on the router interface:
BSR:7A(config)#router rip
Note: The Autonomous System (AS) number needs to be entered when enabling BGP. The
AS applies to BGP only.
7. Issue the network command to determine the network on which the routing
protocol is running. The following example shows how to enable the RIP routing
protocol on the 10.10.10.0 network:
BSR:7A(config-rip)#network 10.10.10.0 255.255.255.0
8. Check if one or more networks need to be associated with the appropriate routing
protocol. For example, issue the following configuration commands to enable
RIP routing for networks 10.10.10.0 and 10.10.20.0:
Follow these steps to resolve misconfigured or missing router commands that can
cause routes to be missing from routing tables:
1. Issue the show ip route command, in Privileged EXEC mode, to check routing
tables on routers.
2. Determine whether there are missing routes to specific networks that are known
to be connected.
3. Reconfigure the identified missing routes so that they are associated with their
designated network.
4. Issue the show running-config command, in Privileged EXEC mode, to view a
specific router configuration.
5. Try to ping another device that is on the same network that has a routing problem.

6. Make sure that there is a network router configuration command specified for the
network to which the interface belongs. For example, if you assign the new
interface IP address 10.10.10.5 on the network 10.10.10.0, issue the following
commands to enable RIP on the interface:
Ensure that process IDs, addresses, and other variables are properly specified for
the routing protocol you are using.
Routing Interface Down

Follow these steps to activate a routing interface:
1. Issue the show ip interface brief command, in Privileged EXEC mode, to see
whether the interface is administratively down:
BSR:7A#show ip interface brief
Check the command output to determine if the Ethernet or POS interface is
administratively down.
2. If the interface is administratively down, bring it up using the no shutdown
command in Interface Configuration mode:
BSR:7A(config-if)#no shutdown {<X/Y>}
where:
X/Y is the slot and port number.
3. Issue the show ip interface brief command, in Privileged EXEC mode, to
discover if the router interface is enabled. If the interface is still down, there
might be a hardware or media problem.
Handling a Misconfigured Access List

Access lists are used to filter IP packets so that certain IP packets are denied or
permitted. Follow these steps to troubleshoot a misconfigured access list:

1. Issue the debug ip packet command, in Privileged EXEC mode, to determine

whether IP packets are being sent and received and whether there are
encapsulation problems.
Caution: Debug commands can use considerable CPU resources on the router. Do not
execute them if the network is already heavily congested.
2. If a router appears to be sending IP packets, but a connected router does not

receive them, check the configuration of the connected router for access lists that
might be filtering out packets.
3. Issue the interface command, in Global Configuration mode, to enter the router
interface:
BSR:7A(config)#interface {type} <X/Y>
where:
type is the interface type: cable, gigaether, lag, etc.
X/Y is the slot and port number.
4. Issue the no ip access-group access-list command, in Interface Configuration
mode, to disable all access lists enabled on the router:
BSR:7A(config-if)#no ip access-group {<1-199> | <1300-2699>} [in |
out]
where:
1-199 is the standard IP access list number.
1300-2699 is the extended IP list number
in specifies inbound packets.
out specifies outbound packets.
5. Execute the debug ip packet command to determine whether the router is
receiving packets.

6. If the router is receiving packets, an access list is probably filtering packets. To

isolate the problem list, enable access lists one at a time until packets are no
longer forwarded by using the distribute-list command in Router Configuration
mode:
BSR:7A(config)#router <protocol>
where:
protocol is the routing protocol used: bgp, dvmrp, isis, ospf, pim, or rip.
BSR:7A(config-router)#distribute-list {<1-199> | <1300-2699>} [in |
out]
where:
1300-2699 is the extended IP list number.
in filters incoming routing updates.
out filters outgoing routing updates.
7. Check the access list to see whether it is filtering traffic from the source router. If
it is, alter the access list to allow the traffic to pass. Enter explicit permit
statements for traffic that you want the router to forward normally.
8. Issue the ip access-group command, in Interface Configuration mode, to enable
the altered access list on the routing interface to see whether packets continue to
pass normally:
BSR:7A(config-if)#ip access-group {<1-199> | <1300-2699>} [in | out]
where:
1300-2699 is the extended IP list number.
in specifies inbound packets.
out specifies outbound packets.
9. If packets pass normally, perform Step 1 to Step 7 on any other routers in the path
until all access lists are enabled and packets are forwarded properly.

Access List and Filter Misconfigurations

Application errors that drop host connections are frequently caused by misconfigured
access lists or other filters. Follow these steps to fix access lists or other filters:
1. Issue the show running-config command, in Privileged EXEC mode, to check
each router in the path. Discover if there are IP access lists configured on the
BSR.
2. If IP access lists are enabled on the BSR, disable them using the appropriate
commands. An access list may be filtering traffic from a TCP or UDP port. For
example, to disable input access list 80, use the no ip access-group command in
Router Interface configuration mode:
BSR:7A(config-if)#no ip access-group 80 in
3. After disabling all the access lists on the BSR, determine whether the application
operates normally.
If the application operates normally, an access list is probably blocking traffic.
4. To isolate the problem list, enable access lists one at a time until the application
no longer functions. Check the problem access list to determine whether it is
filtering traffic from any TCP or UDP ports.
5. If the access list denies specific TCP or UDP ports, make sure that it does not
deny the port used by the application in question (such as TCP port 23 for Telnet).
6. Enter explicit permit statements for the ports that the applications use. The
following example allows DNS and NTP2 requests and replies:
BSR:7A(config)#access-list 50 permit udp 0.0.0.0
255.255.255.255 0.0.0.0 255.255.255.255 eq 53
BSR:7A(config)#access-list 50 permit udp 0.0.0.0

255.255.255.255 0.0.0.0 255.255.255.255 eq 123
7. If you altered an access list, enable the list to see whether the application can still
operate normally.
8. If the application operates normally, repeat the previous steps to isolate any other
problem access lists until the application operates correctly with all access lists
enabled.

Handling UDP Broadcast Forwarding Problems

The User Datagram Protocol (UDP) describes how messages reach application
programs within a destination computer. The following sections describe how to solve
problems that occur when forwarding BOOTP or other UDP broadcast packets. For
example, if UDP broadcasts sent from network hosts are not forwarded by routers,
then diskless workstations cannot boot.
Missing or Misconfigured IP Helper-address Specification
UDP Broadcast Misconfiguration
Missing or Misconfigured IP Helper-address Specification

1. Issue the debug ip udp command, in Privileged EXEC mode, on the BSR that
should be receiving packets from the host. Check the output of the command to
see whether the BSR is receiving packets from the host.
Caution: The debug ip udp command can use considerable CPU resources on the BSR.
Do not execute the command if the network is heavily congested. If the network is
congested, attach a protocol analyzer to see whether the BSR is receiving UDP broadcasts
from the host.
2. If the router receives packets from the host, there is a problem with the host or the
application. Consult the host or application documentation.
3. If the router does not receive packets from the host, issue the show
running-config command, in Privileged EXEC mode, to check the configuration
of the router interface that should first receive the packet from the host.
4. Look for an ip helper-address command entry for that router interface. Make
sure that the specified address is correct (it should be the IP address of a server
application such as a BOOTP server). If there is no command entry, no helper
address is configured.
5. If there is no IP helper address configured, or if the wrong address is specified,
add or change the helper address using the ip helper-address interface
configuration command. For example, to configure the IP address 10.10.10.0 as
the helper address on Ethernet interface 4 on the 10/100 Ethernet module in slot
15, enter the following commands:
BSR:7A(config)#interface ethernet 15/4
BSR:7A(config-if)#ip helper-address 10.10.10.0

UDP Broadcast Misconfiguration

Specifying an IP helper address ensures that broadcasts from only a certain default set
of UDP ports are forwarded. UDP broadcasts forwarded out other ports require
further configuration.
1. Issue the ip forward-protocol udp command, in Global Configuration mode, to
configure each applicable port to forward UDP broadcasts.
For example:
BSR:7A(config)#ip forward-protocol udp 200
2. If you want to allow the forwarding of all UDP broadcasts, issue the ip
forward-protocol udp:
BSR:7A(config)#ip forward-protocol udp

5
Troubleshooting RIP
Overview
This chapter provides troubleshooting solutions to some common Routing
Information Protocol (RIP) problems:
Handling Routing Table Problems
Handling RIP Version Inconsistencies
Handling Routing Table Problems

Problems that occur when hosts on one network cannot access hosts on another
network may occur on an internetwork running only RIP.
The following sections provide instructions for resolving RIP routing table problems:
Misconfigured or Missing Network Router Table Entries
Misconfigured Route Filtering
Split Horizon is Disabled
Misconfigured or Missing Network Router Table Entries

Follow these steps to resolve routes that are missing from the routing table:

1. Issue the show running-config command in Privileged EXEC mode to view the
router configuration.
2. Ensure that a network command is specified in Router Configuration mode for
every network to which a router interface belongs.
For example, enter the following commands to enable RIP on the interfaces:
3. Ensure the correct process IDs, addresses, and other variables are properly
specified for the RIP routing protocol.
Misconfigured Route Filtering

If route filtering is misconfigured, it prevents a RIP router from receiving routing
table updates or prevents a RIP router from transmitting routing table updates.
Follow these steps to discover and resolve misconfigured route filters:
1. Issue the show running-config command to examine the suspect BSR.
2. See if any distribute-list in or distribute-list out command is configured in
Router Configuration mode on the BSR.
The distribute-list in command filters specific information in routing table
updates received by a router. The distribute-list out command prevents a router
from including specific information in routing table updates that it transmits. The
information that is filtered is specified with an access list.
3. Issue the distribute-list command in Router Configuration mode to redefine the
distribute-list as in or out for a specific access list:
BSR:7A(config-rip)#distribute-list {<1-199> | <1300-2699>} [in | out]
where:
1300-2699 is the extended IP list number
in filters incoming routing updates.
out filters outgoing routing updates.

Release 8.0.0 Troubleshooting RIP
Split Horizon is Disabled

If routing loops are occurring between neighboring RIP routers or the size of routing
updates to routing tables are large, the problem may be that split horizon is disabled.
Follow these steps to enable split horizon:
1. Issue the show ip route command in Privileged EXEC mode on the remote router
to determine if split horizon is disabled.
2. View the Split horizon is enabled message in the show ip route
command output.
3. If split horizon is not enabled, enter the ip split-horizon command in Router
Interface Configuration mode on the remote router interface. For example, to
enable split horizon on ethernet interface 0, enter the following commands:
BSR:7A(config)#interface ethernet 0
BSR:7A(config-if)#ip split-horizon
Note: The default split-horizon setting for all interfaces is enabled.

Handling RIP Version Inconsistencies

The following sections provide instructions for resolving inconsistent versions of RIP
running between two RIP routers:
Misconfigured Version of RIP Running on BSR
Misconfigured Version of RIP Running on Specified Interface
Misconfigured Version of RIP Running on BSR

If the BSR is configured globally with the wrong version of RIP, remote RIP
interfaces discard received RIP packets or do not receive RIP packets.
Follow these steps to ensure that the correct version of RIP is running globally on the
BSR:
1. Issue the router rip command in Global Configuration mode to enter Router
Configuration mode for the RIP routing process:
2. Issue the debug ip rip events command in Router Configuration mode to
determine which version of RIP is configured on the BSR:
BSR:7A(config-rip)#debug ip rip events
3. Review the debug ip rip events command output and identify the cause of the
problem. Use no debug ip rip events to turn off debugging.
4. Issue the version command in Router Configuration mode:
BSR:7A(config-rip)#version [1 | 2]
where:
1 allows only RIP version 1 packets to be sent or received BSR interfaces.
2 allows only RIP version 2 packets to be sent or received BSR interfaces.
5. Issue the show running-config interface command to verify that the correct
version of RIP is configured on a BSR NIM interface:
BSR:7A(config-rip)#show running-config interface

Release 8.0.0 Troubleshooting RIP
Misconfigured Version of RIP Running on Specified Interface

Follow these steps to ensure that the correct version of RIP is running on a RIP
routing interface:
1. Issue the debug ip rip command in Router Configuration mode to determine
which version of RIP is configured on the BSR:
BSR:7A(config-rip)#debug ip rip
2. Review the debug ip rip events command output and identify the cause of the
problem. Use no debug ip rip events to turn off debugging.
3. Enter the NIM interface that is used for RIP routing.
4. If the wrong version of RIP is configured for receiving RIP packets on the RIP
routing interface, issue the ip rip receive version command in Interface
Configuration mode:
BSR:7A(config-if)#ip rip receive version [0 | 1 | 2]
where:
0 allows RIP version 1 and 2 packets to be received on this interface.
1 allows only RIP version 1 packets to be received on this interface.
2 allows only RIP version 2 packets to be received on this interface.
5. If the wrong version of RIP is configured for sending RIP packets on the RIP
routing interface, issue the ip rip send version command in Interface
Configuration mode:
BSR:7A(config-if)#ip rip send version [0 | 1 | 2 | 3]
where:
0 allows RIP version 1 and 2 packets to be sent over this interface.
1 allows only RIP version 1 packets to be sent over this interface.
2 allows only RIP version 2 packets to be sent over this interface.
3 stops any RIP packets from being sent over this interface.
6. Issue the show running-config interface command to verify that the correct
version of RIP is configured on the BSR:
BSR:7A(config-if)#show running-config interface


6
Troubleshooting OSPF
Overview
This chapter provides troubleshooting solutions to some common Open Shortest Path
First (OSPF) routing protocol problems:
Handling OSPF-designated Interface Problems
Handling Router Neighbor Misconfigurations
Resolving Missing Routes in Routing Table
Handling OSPF-designated Interface Problems

At least one active interface needs to be configured with an IP address to configure
OSPF on the BSR. OSPF uses the IP address of a NIM interface on the BSR as its
router ID.
Follow these steps to check for an active OSPF interface and correct any interface
related OSPF problems:
1. Issue the show ip ospf command in Global Configuration mode to check if there
is an active OSPF interface with an IP address:
BSR:7A(config)#show ip ospf

2. If there is no active OSPF interface with an IP address, configure an interface on

a specified NIM by issuing the ip address command in Interface Configuration
mode.
3. Next, issue the no shutdown command in Interface Configuration mode to
activate the configured interface.
Example:
BSR:7A(config)#interface gigaether 7/2
BSR:7A(config-if)#ip address 10.1.1.5 255.255.255.252
BSR:7A(config-if)#no shutdown
Handling Router Neighbor Misconfigurations

The following sections explain why OSPF routers may not exchange information to
establish neighbor relationships:
Mismatched OSPF Parameters
Follow these steps to resolve a misconfigured or missing network router command:
1. Issue the show ip ospf command in Privileged EXEC mode to determine which
interfaces have OSPF enabled.
2. Make sure that network router configuration commands are specified for each
interface on which OSPF should run.
For example, if the IP address of the Ethernet interface 7/2 is 100.148.22.2 with a
subnet mask of 255.255.255.0, enter the following commands to enable OSPF on
the interface:
BSR:7A(config)#router ospf
BSR:7A(config-ospf)#network 100.148.22.0.0.0.0.255 area 0

Release 8.0.0 Troubleshooting OSPF
3. Ensure the proper addresses, wildcard masks, and other variables are properly
specified.
Note: There is no relation between OSPF wildcard masks (used in OSPF network
commands) and the subnet mask configured as part of an interface IP address.
4. Check other OSPF routers on the network by repeating steps 1 to 3. Make sure
that OSPF is configured properly on all neighboring routers so that neighbor
relationships can be established.
Mismatched OSPF Parameters

The Hello or dead timers, E-bits (set for stub areas), N-bits that are set for
Not-So-Stubby Areas (NSSAs), area IDs, authentication types, or network mask
parameters may be mismatched. The values set for these parameters (except for
N-bits) should all be the same throughout an OSPF area, and, in some cases, the entire
OSPF network.
Follow these steps to set consistent parameters for the OSPF network:
1. Issue the show ip ospf neighbor command in Privileged EXEC mode to identify
the OSPF neighbors of each router.
2. If the output does not list an expected neighbor, issue the show ip ospf interface
command in Privileged EXEC mode on the router and its expected neighbor:
BSR:7A#show ip ospf interface
Examine the Hello and dead timer interval values configured on OSPF interfaces.
3. Compare the values configured for the timers on each router. If there is a
mismatch, reconfigure the timer values so that they are the same on the router and
its neighbor.
The following example describes how to change the Hello timer interval to 5 on
an Ethernet interface for the BSR to identify the OSPF neighbors:
BSR:7A(config)#interface ethernet 7/2
BSR:7A(config-if)#ip ospf hello-interval 5
The ospf hello-interval value must be the same for all nodes on a specific
network. The default ospf hello-interval is 10 seconds.

4. Issue the debug ip ospf adj command in Privileged EXEC mode. Check the
output for mismatched values:
BSR:7A#debug ip ospf adj
5. If mismatches are indicated in the debug output, try to resolve the mismatch.
6. Ensure that all routers in an area have the same area ID and authentication type,
and are configured as stub routers.
Mismatched IP MTU
This section describes what to do if the OSPF router rejects packets with a Maximum
Transmission Unit (MTU) size that exceeds the configured IP MTU of the
neighboring or adjacent OSPF interface.
Follow these steps to align IP MTU sizes between OSPF routers:
1. Issue the debug ip ospf adj command in Privileged EXEC mode to determine the
mismatched IP MTU size problem with the adjacent OSPF router:
BSR:7A#debug ip ospf adj
2. Look in the debug ip ospf adj command output for a message similar to the
following example, which identifies that the neighboring OSPF router has a
larger MTU than the local OSPF router:
OSPF: Nbr 102.2.2.2 has larger interface MTU
3. Issue the show ip interface command in Privileged EXEC mode to get the MTU
value for the local OSPF router:
BSR:7A#show ip interface
4. Look in the show ip interface command output for a message for a specific
interface that is similar to the one in the following example:
gigaether 7/2 is up, line protocol is up
Internet address is 10.10.20.143/16
Broadcast address is 255.255.255.255
MTU 1500 bytes
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is not set
Outgoing qos list is not set
Proxy ARP is disabled
Split horizon is enabled
ICMP redirects are always sent

Release 8.0.0 Troubleshooting OSPF
ICMP unreachables are always sent

ICMP mask replies are always sent
Router Discovery is disabled
5. Telnet into the neighboring OSPF router (which would be 102.2.2.2 using the
example in step 2) to adjust the MTU size on the neighboring OSPF router to
match the local MTU size.
6. On the OSPF interface on the neighboring OSPF router, configure the MTU size
to match the MTU size of the local OSPF router:
router(config-if)#ip mtu 1500
7. Issue the debug ip ospf adj command in Privileged EXEC mode to verify that
the MTU size matches on both OSPF router interfaces.
Resolving Missing Routes in Routing Table

When OSPF routes and networks are not advertised to other routers, routers in one
area do not receive routing information for other areas. Some hosts cannot
communicate with hosts in other areas, and routing table information is incomplete.
The following sections describe how to resolve missing OSPF routes in a routing
table:
RIP Routing Information Incorrectly Redistributed into OSPF
ABR Configured Without Area 0 Interface
RIP Routing Information Incorrectly Redistributed into OSPF

Follow these steps to redistribute RIP routing information into OSPF:
1. Issue the show running-config command in Privileged EXEC mode to check the
2. Look for a redistribute command entry that was made in Router Configuration
mode. Ensure that redistribution is configured and that the subnets keyword is
used with the command. The subnets keyword must be included when RIP is
redistributed into OSPF. If RIP is not redistributed into OSPF, only major routes
(not subnet routes) are redistributed.
3. If the redistribute command is not present, or if the subnets keyword is not
specified, add or change the configuration using the following commands:

BSR:7A(config-ospf)#redistribute rip subnets
ABR Configured Without Area 0 Interface

If there are two or more OSPF networks, both should be configured with a different area ID, and at
least one OSPF network must have an area ID of 0.
Follow these steps to configure an OSPF Area Border Router (ABR) with an Area 0 interface:
1. Issue the show running-config command in Privileged EXEC mode on OSPF routers to verify
that at least one ABR exists for the area. ABRs must belong to area 0, which is the OSPF backbone
and one other area. Look for network statements that indicate that the router is part of area 0.
Note: Ensure that at least one OSPF network is defined as area 0.
2. Issue the network area command in Router Configuration mode to define the interfaces on which
OSPF runs and to define the area ID for those interfaces:
BSR:7A(config-ospf)#network <A.B.C.D> <A.B.C.D> area {<0-4294967295> |
<A.B.C.D>}
where:
A.B.C.D is the IP address of the OSPF network.
A.B.C.D is the IP-address-type mask that includes the wild card "don't care" bits.
0-4294967295 is the OSPF area ID in decimal format.
A.B.C.D is the OSPF area ID in IP address format.
Note: The area that is associated with the OSPF address range can be specified as either a
decimal value or as an IP address. If you intend to associate areas with IP subnets, you can
specify a subnet address as the area-id.
3. Issue the network command in Router Configuration mode to configure an ABR if one does not
exist in an area.
For example, to configure OSPF router 100 to participate in the OSPF backbone area, follow these
commands:
BSR:7A(config-ospf)#network 10.10.3.7 0.0.0.255 area 0
7
Troubleshooting BGP
Overview
This chapter provides troubleshooting solutions to some common Border Gateway
Protocol (BGP) routing protocol problems:
Handling BGP Routing Problems
Handling BGP Peer Misconfigurations
Handling BGP Routing Problems

Follow these sections to correct BGP routes missing from the routing table so that the
BGP router and network are advertised to other routers.
Missing Neighbor Table Entry

Follow these steps to add entries to the BGP neighbor routing table:
1. Check local and remote routers and ensure the specified autonomous system
numbers and neighbors are correct.

2. Configure any autonomous system numbers and neighbors that are misconfigured
or missing. For example, to specify that a router at the address 10.10.1.2 is a
neighbor in autonomous system number 100, issue the following series of
commands.
BSR:7A(config)#router bgp 1
BSR:7A(config-bgp)#network 10.10.0.0
BSR:7A(config-bgp)#neighbor 10.10.1.2 remote-as 100
3. Issue the show running-config command in Privileged EXEC mode to ensure
any enabled route filters are not misconfigured.
Misconfigured Access List

Follow these steps to resolve access list configuration problems:
1. Issue the show access-lists command in Privileged EXEC mode on suspect
routers to determine if there are access lists configured and enabled on the router.
2. If there are access lists enabled on the router, disable them using the appropriate
commands. For example, issue the following command to disable access list 10:
BSR:7A(config)#no ip access-list standard 10 in
3. After disabling all access lists on the router, determine whether the missing
routing information now appears in routing tables.
4. If the information appears, it is likely that an access list is filtering traffic. To
isolate the problem access list, enable access lists one at a time until the routing
information no longer appears in the routing table.
5. Check the access list to see whether it is filtering traffic from specific TCP ports.
If an access list denies specific TCP ports, make sure that it does not deny TCP
port 179, the port BGP uses. For example, enter an explicit permit statement for
port 179 to ensure that BGP traffic is forwarded normally.
BSR:7A(config)#ip access-list 101 permit tcp 0.0.0.0
255.255.255.255 0.0.0.0 255.255.255.255 eq 179
6. If you altered an access list, enable the list to see whether routing information can
still pass normally.
7. If routing information is no longer missing, repeat steps 1 to 6 on any other
routers in the path until all access lists are enabled and routing information
appears in the appropriate routing tables.

Release 8.0.0 Troubleshooting BGP
Missing Network Destination Advertisement

When BGP routers do not advertise routes, routing updates from those routers do not
contain information about certain network destinations that should be advertised.
Follow these steps to solve BGP advertising routing problems:
1. Issue the show running-config command in Privileged EXEC mode to view the
2. Ensure that the network command entered in Router Configuration mode is
specified for every network that the BGP router should advertise (these networks
need not be directly connected). For example, if the BGP router needs to
advertise networks 10.168.52.0 and 10.168.0.0, enter the following commands to
have the router include those networks in its routing updates:
BSR:7A(config)#router bgp

Handling BGP Peer Misconfigurations

Follow these steps to find and resolve a misconfigured or missing configuration for
BGP peers:
1. Issue the show ip bgp neighbors command in Privileged EXEC mode to verify
that all the required BGP peers are configured with the correct IP addresses and
Autonomous System (AS) numbers:
BSR:7A#show ip bgp neighbors
2. If some BGP peer routers are misconfigured or are not configured, configure
them with the proper IP addresses and AS numbers.
Issue the neighbor remote-as command in Router Configuration mode to add an
entry to the BGP neighbor table. The BGP neighbor table identifies a router as a
BGP peer and maps its IP address to a specific AS.
BSR:7A(config-bgp)#neighbor {<A.B.C.D> | <WORD>} remote-as
<1-65535>
where:
A.B.C.D is the neighbor IP address.
WORD is the BGP peer group name.
1-65535 is the AS to which the neighbor belongs
3. Issue the neighbor description command in Router Configuration mode to
associate a textual description of up to 80 characters with a BGP neighbor:
BSR:7A(config-bgp)#neighbor {<A.B.C.D> | <WORD>} description
<LINE>
where:
A.B.C.D is the neighbor IP address.
WORD is the BGP peer group name.
LINE is up to 80 characters of text that describes the neighbor
Example:
The following commands configure Routers Miami with Routers Chicago,

Boston, and NY as neighbors:

Release 8.0.0 Troubleshooting BGP
BSR:7A(config-bgp)#router bgp 100

BSR:7A(config-bgp)#neighbor 172.30.20.2 description peer NY
BSR:7A(config-bgp)#neighbor 172.40.20.2 description peer
Chicago
BSR:7A(config-bgp)#neighbor 192.50.30.2 description peer Boston
4. Issue the show ip bgp summary command in Privileged EXEC mode to verify
that BGP peer routers have been established and are functioning correctly:
BSR:7A#show ip bgp summary
5. Issue the show ip bgp command in Privileged EXEC mode to view route entries
in the BGP table after the BGP peer sessions are established:
BSR:7A#show ip bgp
6. Issue the show ip route command in Privileged EXEC mode to view route entries
in the route table (also known as the forwarding table):
7. If you suspect that the local BGP router is not receiving some routes, issue the
show running-config command in Privileged EXEC mode:
BSR:7A#show running-config
8. View the BGP portion of the show running-config command output to determine
if any route-maps, access-lists, distribute-lists, AS-path-access-lists, and/or
community-access-lists are applied. If they are applied, confirm that they are
configured correctly.
9. Verify that a suspect remote BGP peer router is sending the route-maps,
access-lists, distribute-lists, AS-path-access-lists, and/or community-access-lists
to the local BGP router.
10. If there are routes in the local BGP router table that do not display in a peer router
BGP table, issue the show ip bgp command in Privileged EXEC mode to view
the list of BGP peers to which the local router sends routes.
BSR:7A#show ip bgp <A.B.C.D> [<A.B.C.D>]
where:
A.B.C.D is the network in the BGP routing table to display.

A.B.C.D is the subnetwork mask (if applicable).

11. If the suspect peer BGP router is absent from the list, verify the route-map,
access-list, distribute-list, AS-path-access-list, and community-access-list
parameters that belong to the suspect peer BGP router to ensure that it is
configured correctly.

8
Troubleshooting Multicast
Routing
Overview
This chapter describes how to troubleshoot IP Multicast Routing problems on the
BSR.
Hosts are Not Receiving Video

Multicast routing on the BSR is used primarily for transporting video and other
Constant Bit Rate (CBR) data traffic, such as audio, over a network from a multicast
server to multicast hosts. The primary problem that can occur on an IP multicast
network is that host computers are not receiving video from a multicast source, such
as a video conference server.
The following sections provide a way to troubleshoot IP multicast problems from the
host computers to the multicast server:
Check Connection Between IGMP and Hosts
Check Connections Between Multicast Routers

Check Connection Between IGMP and Hosts

IGMP manages the membership of hosts and routers in multicast groups. IP hosts use
IGMP to report their multicast group memberships to any immediately neighboring
multicast routers. Multicast routers use IGMP to learn, for each of their attached
physical networks, which groups have members. The following sections describe how
to troubleshoot connections between IGMP and hosts:
IGMP Configuration Problems
Misconfigured IGMP Access Group
Some IGMP Hosts Are Not Receiving Multicast Services
IGMP Configuration Problems

Follow these steps to check the connection between the IGMP and Multicast hosts:
1. IP hosts use IGMP to report their group membership to directly connected
multicast routers. IGMP uses class D IP addresses for its group addresses that can
range from 225.0.0.0 to 239.255.255.255.
Ensure that the following multicast addressing rules are applied to IGMP:
The 224.0.0.0 IP address is guaranteed not to be assigned to any group.
The address 224.0.0.1 is assigned to all systems on a subnetwork.
The address 224.0.0.2 is assigned to all routers on a subnetwork.
2. IGMP is enabled on all interfaces on which DVMRP or PIM is configured by
default. Issue the show ip igmp interface command to ensure that IGMP is
enabled on the BSR and all routers and hosts that want to receive IP multicasts.
3. If IGMP is not enabled on the interface, check to determine if DVMRP or PIM
has been configured.
Misconfigured IGMP Access Group

The BSR learns about multicast group members that are connected to local networks
by sending IGMP host-query messages. The BSR then forwards all packets addressed
to the multicast group to these group members. IP multicast group access is
determined by associating the IGMP access group to an access list.

Release 8.0.0 Troubleshooting Multicast Routing
Follow these steps to ensure that the IGMP groups or group that you configured are
associated with the correct access lists or access list:
1. Issue the show ip igmp groups command to gather IGMP group membership
information, which includes the IGMP group IP address and interface. This
address is the IP address of the access list. Ensure that the access list number uses
a class D IP addresses for its group address that ranges from 225.0.0.0 to
239.255.255.255.
2. If the access list does not meet this criteria, issue the access-list permit igmp
command, in Global Configuration mode, to configure the correct IP multicast
address for this access list:
BSR:7A(config)#access-list <100-199> permit igmp {<A.B.C.D>
<A.B.C.D>} any
where:
100-199 is the extended access list number for multicast networks.
A.B.C.D is the IP multicast group IP address.
A.B.C.D is the wildcard bits to be applied to the multicast group IP address
range. For example, 0.0.0.255.
any specifies any destination host.
Some IGMP Hosts Are Not Receiving Multicast Services

Some hosts in multicast networks may only be able to accept IGMP Version 1
protocol packets. The BSR uses IGMP Version 2 by default, which allows the IGMP
query time-out and the maximum query response time features. All hosts connected to
an interface must support the same version of IGMP.
Follow these steps to check the IGMP version that hosts connected to an interface are
using and set the proper IGMP version (if applicable) so that all hosts can participate
in the same multicast network:
1. Issue the show ip igmp groups command to determine the version of IGMP each
IGMP group is using.
2. If hosts connected to a particular interface only support IGMP Version 1, select
Version 1 for the interface. Issue the ip igmp version 1 command, in Interface
Configuration mode, to change the version of IGMP to IGMP Version 1:
BSR:7A(config-if)#ip igmp version 1

Check Connections Between Multicast Routers

When troubleshooting IP Multicast, determine if the primary source address in the
multicast packet passes a Reverse Path Forwarding (RPF) check on an incoming
interface so that multicast packets can then be forwarded. The purpose of the RPF
check process is to prevent loops by ensuring that this incoming interface is the
outgoing interface used by unicast routing to reach the multicast packet source. Once
a multicast packet is forwarded, the multicast routing process forwards the packet
based only on its destination address.
If hosts directly connected to one router receive a multicast flow, but hosts directly
connected to another router in the same multicast network are not receiving this same
flow, a forwarding problem may exist with the multicast route and the multicast group
address. In the troubleshooting example below, BSR 1 and BSR 2 represent the
routers in this multicast network.
Follow these steps to determine if a router is not forwarding IP multicast packets as
the result of a Reverse Path Forwarding (RPF) failure:
1. Issue the show ip multicast fwd-cache command to view the multicast source
information, and multicast group information on BSR 1.
2. If multicast packets are being successfully forwarded to the network on which
BSR 2 is connected, issue the show ip route command on BSR 2 to check if its
connected hosts are not getting the multicast flow:
3. Check if the multicast server IP address and the multicast network IP address
display in the show ip route command output for BSR 2. If they are not listed,
then BSR 2 is not forwarding the packets from them.
4. Issue the show ip pim neighbor command on BSR 2 to determine if information
for the PIM neighboring upstream router (BSR 1) displays.
5. If BSR 1 displays as a neighbor, issue the show ip rpf command to determine if
there is an RPF error:
BSR:7A#show ip rpf <A.B.C.D>
where:
A.B.C.D is the RPF multicast source.
6. If the output shows the wrong incoming RPF interface, issue the debug ip pim rp
command to review Reverse Path (RP) processing information.

Release 8.0.0 Troubleshooting Multicast Routing
7. If multicast packets are arriving on the correct interface connected to BSR 1, but
they are being dropped, the unicast routing table is not using this interface for the
RPF check.
IP multicast static routes (mroutes) enable unicast and multicast packets to take
different paths over combined multicast and unicast network topologies by
allowing multicast packets to travel from the router that is configured with the
static multicast route to the next multicast router, even if there are one or more
unicast routers in the path. The router with the multicast static route uses the IP
static multicast route configuration instead of the unicast routing table to
determine the path, and no information about this IP multicast static route is
advertised or redistributed to any other router on the network.
Issue the ip mroute command, in Global Configuration mode, to add a static
multicast route to force RPF packets out the interface connected to BSR 1,
regardless of what the unicast routing table states:
BSR:7A(config)#ip mroute {<A.B.C.D> <A.B.C.D> <A.B.C.D>}
[<1-255>]
where:
A.B.C.D is the source IP address of the multicast static route.
A.B.C.D is the source subnetwork IP address of the multicast static route.
A.B.C.D is the Reverse Path Forwarding neighbor interface IP address or
route.
1-255 is the optional administrative distance of the multicast static route.
8. Issue the show ip route command on BSR 1 and BSR 2 to verify if multicast
packets are being forwarded successfully to the multicast group.
9. Issue the debug ip pim all command on BSR to verify all PIM processing
information to verify that packets are forwarded from the multicast source to the
multicast group on the proper interface.


9
Recommended BSR
Configurations
Introduction
This chapter describes ARRIS Technical Assistance Centers recommended
configurations for the BSR 64000. These recommendations will ensure that the BSR
performs at the most optimal level for normal operations. The following
recommended configurations are described:
Increasing the Log File Size
Denial of Service Protection
Changing the Upstream Range Backoff Value
Configuring the Boot ROM Filename
Enabling Remote Query
Enabling Remote Set
Sending Events to a SYSLOG Server
Configuring an SNTP Server
Configuring Voice
Disabling the Empty Channel Load Balancing Restriction

Resetting Non-Bonded Cable Modems
Increasing the Log File Size

ARRIS recommends that the default log file size be increased to the maximum
allowable size for normal BSR operations.
BSR:7A(config) #logging buffered 5242880
where:
5242880 is the maximum logging buffer size expressed in bytes.
Denial of Service Protection

Protecting the BSR from Denial of Service attacks is very important. Often these type
of attacks cause no significant impact to the BSR but cause user or back office
problems. For example, SNMP time-outs, slow cable modem registration, dropped
sessions, etc. This section discusses the following ways of protecting the BSR from
Denial of Service attacks:
Enabling DHCP Throttling
Constraining Logging and Reporting
Blocking Unsolicited Network Traffic
Enabling DHCP Throttling

The cable dhcp throttle upstream command limits the number of upstream IPv4 and
IPv6 DHCP packets accepted per cable modem over a specified time interval. The
BSR drops all DHCP packets beyond the configured limit within the configured time.
The no cable dhcp throttle upstream command disables DHCP throttling and is the
default configuration.
There have been numerous instances where a cable modem can cause problems with
the BSR and DHCP servers by flooding DHCP messages. Enabling DHCP throttling
prevents this type of Denial of Service attack.
BSR:7A(config)#cable dhcp throttle upstream <10-200> <1-5>
where:
10-200 is the number of DHCP packets accepted from any particular cable
modem.
1-5 is the time interval, in seconds, over which the count is accepted.

Release 8.0.0 Recommended BSR Configurations
Recommended Configuration
BSR:7A(config)#cable dhcp throttle upstream 10 1
Setting DHCP throttling to 10 1 allows each cable modem to send up to 10 DHCP
queries every 1 second. This configuration provides a reasonable starting point for
normal operations, but can be reduced as required.
Constraining Logging and Reporting

If logging is unconstrained, the amount of processing of events can impact other BSR
functionality. Recommended logging configurations are as follows:
1. Setting the logging administrative status to maintainBelowThreshold tells the
BSR to monitor for excessive logging messages and throttle them as necessary to
keep from exceeding the configured threshold. This is not enabled by default.
BSR:7A(config)# logging admin-status maintainBelowThreshold
where:
maintainBelowThreshold causes trap transmission and SYSLOG messages
to be suppressed if the number of traps/messages would exceed the threshold
specified with the logging rate-limit command.
2. To restrict the rate of logged messages, specify the number of logged messages
allowed per second with the logging rate-limit command in Global
Configuration mode, as shown below:
BSR:7A(config) #logging rate-limit <0-2147483647> <1-2147483647>
where:
0-2147483647 is the number of messages.
1-2147483647 is the number of seconds at which the specified number of
SYSLOG and trap messages are logged.
Logging rate limiting is disabled by default.
BSR:7A(config) #logging rate-limit 60 1
A logging rate-limit of 60 1 limits the logging to 60 messages per second. The
default setting is 100 1 if logging rate-limit is enabled.

3. Specify what logged information is buffered with the logging buffered

command, in Global Configuration mode, as shown below:
BSR:7A(config) #logging buffered [alerts | critical | emergencies | errors |
informational | notifications | warnings]
where:
alerts logs conditions where immediate action is needed
critical logs critical conditions
emergencies logs emergency conditions where the system is unusable
errors logs error conditions
informational logs informational system messages
notifications logs normal but significant conditions
warnings logs warning conditions
Refer to Severity Levels and Descriptions on page 6 for detailed severity level
information.
BSR:7A(config) #logging buffered errors
Setting the logging buffer command to errors and above reduces the buffered
logging messages to the more important conditions (alerts, critical, emergencies
and errors).
4. Specify the severity level of messages to be logged to the local console with the
logging console command in Global Configuration mode, as shown below:
BSR:7A(config) #logging console [alerts | critical | emergencies | errors |
where:
alerts logs conditions where immediate action is needed.
critical logs critical conditions.
emergencies logs emergency conditions where the system is unusable.
errors logs error conditions.
informational logs informational system messages.

notifications logs normal but significant conditions.

warnings logs warning conditions.
information.
BSR:7A(config) #logging console errors
Setting the logging console command to errors and above reduces the console
displayed messages to the more important conditions (alerts, critical,
emergencies and errors).
Severity Levels and Descriptions

emergencies Emergency conditions where the system is unusable - reserved
for vendor-specific, fatal hardware or software errors that
prevent normal system operation and cause reporting system to
reboot (severity level = 0).
alert Conditions where immediate action is needed - a serious
failure which causes the reporting system to reboot but is not
caused by hardware or software malfunctioning
(severity level = 1).
critical Critical conditions - a serious failure that requires immediate
attention and prevents the device from transmitting data, but
the system could recover without rebooting
error Error conditions - a failure occurred that could interrupt the
normal data flow (severity level = 3).
warnings Warning conditions - a failure occurred that could interrupt the
normal data flow (severity level = 4).

Severity Levels and Descriptions

notifications Normal but significant conditions - an event of importance
occurred which is not a failure (severity level = 5).
information Informational descriptive system messages - an unimportant
event, which could be helpful for tracing normal operations
Blocking Unsolicited Network Traffic

There are various ways of blocking unsolicited network traffic. Some type of
configuration is recommended in order to minimize "spam" traffic and its potential
effect on BSR operations.
The optimal configuration is to implement an Firewall/IDS (Intrusion Detection
System) in the network. A Firewall/IDS system will dynamically learn and
control any type of Denial of Service behavior coming into the network. This is
really the ultimate solution to this problem as well as blocking any local
spammers/hackers
The unresolved-ip-packet-throttle command provides a throttling mechanism
to prevent problems such as voice packet drops or latency that can be caused by
short bursts of a large number of packets which require ARP resolutions being
sent to the CMTS at a rate higher than the CMTS can process. The
unresolved-ip-packet-throttle command prevents such problems from occurring
regardless of configuration or traffic load by preventing the CMTS from being
overrun but still allowing normal ARP resolution traffic to occur.
Refer to:
Configuring Unresolved IP Packet Throttling on page 8
Denial of Service traffic can be blocked at the BSR using Access Control Lists
(ACLs). At a minimum, the example access control lists described in this section
should be implemented.
Refer to:
Configuring IPv4 Access Control Lists on page 8
Configuring IPv6 Access Control Lists on page 11

Note: Unresolved IP throttling or ACLs by no means replace the need for a Firewall/IDS
system but should help alleviate the problem of Denial of Service traffic until a Firewall/IDS
system can be implemented. The important difference is that a Firewall/IDS system can
recognize message protocol IP packets whereas the BSR can only block UDP ports.
Configuring Unresolved IP Packet Throttling

Use the unresolved-ip-packet-throttle command, in Global Configuration mode, to
configure unresolved IP packet throttling on the BSR.
BSR:7A(config) #unresolved-ip-packet-throttle {burst-rate <1-8000> | rate
<1-4000>}
where:
burst-rate 1-8000 configures the unresolved IP packet throttling burst-rate in
packets/second.
rate 1-4000 configures the unresolved IP packet throttling packet rate in packets/
second.
Unresolved IP packet throttling is enabled by default. The default burst-rate is 20
packets/second and the default rate is 200 packets/second. The default rate can be
reduced to 50 packets/second if required to further reduce unresolved packet traffic.
Configuring IPv4 Access Control Lists

Access control lists are used on the BSR to control entry or exit access to or from the
BSR. Access lists can be configured for all routed network protocols to filter packets
as the packets pass through the BSR. The access list criteria can be defined by the
source or the destination address, upper-layer protocol, or other routing information.
Configuring an IPv4 access control list requires the following procedures:
Configuring a Cable Interface IPv4 Access Control List
Configuring a Network Interface IPv4 Access Control List
Configuring a Cable Interface IPv4 Access Control List

Access Group 198 below (ACL number 198 is used as an example) denies some dead
protocols (typically used as a hacker tool) as well as NetBIOS and spammer traffic
while allowing other common UDP traffic. NetBIOS also generates a large amount of
ARP and other broadcast traffic while it browses for other computers. This is an
enormous hacker hole.

Destination UDP ports 1026 and 1027 should be blocked on the cable interfaces.
Before blocking these ports, an entry allowing any packets from the TFTP, DNS and
NTP servers must be added to the ACL table. This is show with the <TFTP server IP
address> or x.x.x.0 entries below. The x.x.x.0 entry would be the subnet used for your
backend servers such as TFTP and NTP. The other option is a separate line for each
server defined similarly to the <TFTP server IP address> entry.
1. Configure Access Group 198, with the access-list command in Global
Configuration mode, as follows:
access-list 198 deny pim any any
access-list 198 deny tcp any any eq 445
access-list 198 deny udp any any eq 445
access-list 198 deny udp any any eq netbios-ns
access-list 198 deny udp any any eq netbios-dgm
access-list 198 deny udp any any eq netbios-ss
access-list 198 permit udp any eq domain any
access-list 198 permit udp any any eq domain
access-list 198 permit udp any eq snmp any
access-list 198 permit udp any any eq snmp
access-list 198 permit udp any eq snmptrap any
access-list 198 permit udp any any eq snmptrap
access-list 198 permit udp any eq ntp any
access-list 198 permit udp any any eq ntp
access-list 198 permit udp any eq syslog any
access-list 198 permit udp any any eq syslog
access-list 198 permit udp any eq time any
access-list 198 permit udp any any eq time
access-list 198 permit udp any eq 6346 any
access-list 198 permit udp any any eq 6346
access-list 198 permit ip host any <TFTP server IP address>
and/or
access-list 198 permit ip any x.x.x.0 0.0.0.255

access-list 198 permit ip any any

2. Assign Access Group 198 to every physical upstream cable interface, as follows:
a. BSR:7A(config) #interface cable X/Y
where:
X/Y is the slot and MAC domain number (0-15) of the RX48 module.
b. BSR:7A(config-if) #ip access-group 198 in
Configuring a Network Interface IPv4 Access Control List

Access Group 180 below (ACL number 180 is used as an example) denies several
UDP destination ports that were found to be a major contributor to the problem while
allowing other UDP traffic.
Destination UDP ports 1026 and 1027 should be blocked on the network interfaces.
Before blocking these ports, an entry allowing any packets from the TFTP, DNS and
NTP servers must be added to the ACL table. As mentioned for the cable interface
ACL above, these are shown as <TFTP server IP address> or the x.x.x.0 entries
below. The entries need to reflect the servers or subnets in your network.
1. Configure Access Group 180, with the access-list command in Global
Configuration mode, as follows:
access-list 180 permit udp any eq domain any
access-list 180 permit udp any any eq domain
access-list 180 permit udp any eq snmp any
access-list 180 permit udp any any eq snmp
access-list 180 permit udp any eq snmptrap any
access-list 180 permit udp any any eq snmptrap
access-list 180 permit udp any eq ntp any
access-list 180 permit udp any any eq ntp
access-list 180 permit udp any eq syslog any
access-list 180 permit udp any any eq syslog
access-list 180 permit udp any eq time any
access-list 180 permit udp any any eq time
access-list 180 permit ip host any <TFTP server IP address>
and/or
access-list 180 permit ip x.x.x.0 0.0.0.255 any


access-list 180 permit ip any any
2. Assign Access Group 180 to each of the network interfaces.
a. BSR:7A(config) #interface gigaether 7/0
where:
X/Y is the Gigabit Ethernet slot and port number.
X is either slot 7 (the active SRM10G) or slot 8 (the standby SRM10G).
Y is the HSIM port number (0-5).
b. BSR:7A(config-if) #ip access-group 180 in
Configuring IPv6 Access Control Lists

Configuring an IPv6 access control list, requires the following procedures:
Gigabit Ethernet Interface Configuration
Configuring the IPv6 ACL
Applying an IPv6 Access Control List to a Cable Interface
Gigabit Ethernet Interface Configuration

On the Gigabit Ethernet interface, configure the following:
BSR:7A(config)#ipv6 nd ra suppress
This instructs the BSR not to send out Router Advertisements.
BSR:7A(config)#no ipv6 redirects
This instructs the BSR not to send host redirect messages.
Configuring the IPv6 ACL

The iv6p access-list command adds an IPv6 extended access-list entry and enters
IPv6 Access Control List Configuration mode.
BSR:7A(config)#ipv6 access-list <access-list-name>
The IPv6 Access Control List Configuration mode prompt is as follows:
BSR:7A(config-ipv6-acl)#

The following table provides general recommendations for configuring IPv6 ACLs on
the BSR.
Note: Because IPv6 ACLs are supported in extended form only, both a source and a
destination needs to be specified in each entry even if one or both entries are "any".
Gigabit Ethernet Interface Cable Interface

Permit Deny Permit Deny
Router-solicitation Router-solicitation
(ICMP 133) (ICMP 133)
Router-advertisement Router-advertisement
(ICMP 134) (ICMP 134)
Neighbor-solicitation Neighbor-solicitation
(ICMP 135) (ICMP 135)
Neighbor-advertisement Neighbor-advertisement
(ICMP 136) (ICMP 136)
DHCP-server DHCP-server
(UDP 547) (UDP 547)
DHCP-client DHCP-client
(UDP 546) (UDP 546)
Hop-by-hop Hop-by-hop
(0 any any) (0 any any)
Example IPv6 ACL Configuration on a Cable Interface

The following is an example of an IPv6 ACL configuration on a cable interface. The
example reflects output that would be found in the running-configuration file and
displayed with the show running-configuration command.
ipv6 access-list ipv6-cable-in

deny tcp any any eq 135


deny udp any any eq 135
deny udp any any eq netbios-ns
deny udp any any eq netbios-ss
deny 0 any any
deny ipv6 any <IPv6 Internal Infrastructure addresses>
permit ipv6 any any
The <IPv6 Internal Infrastructure addresses> line refers to server or network
addresses that should not be accessible from the cable side of the network.
Applying an IPv6 Access Control List to a Cable Interface

The configured IPv6 ACL needs to be applied to a cable interface.
1. Enter Interface Configuration Mode for the cable interface.
BSR:7A(config) #interface cable X/Y
where:
X/Y is the slot and MAC domain number (0-15) of the RX48 module.
2. Use the ipv6 traffic-filter command to enable inbound or outbound IPv6 access
control list traffic filtering. In this example, outbound traffic.
BSR:7A(config-if) #ipv6 traffic-filter <-list-name> {in | out}
Changing the Upstream Range Backoff Value

The cable upstream range-backoff command sets the starting and ending upstream
range-backoff values for a cable modem or re-establishes a cable modem if a power
outage occurs. The no cable upstream range-backoff command restores the default
range-backoff values of 0 and 4.
Note: The DOCSIS-specified method of contention resolution for cable modems used to
send data or requests on the upstream channel is a truncated binary exponential back-off
with the initial backoff window and the maximum backoff window controlled by the CMTS.
The BSR specifies backoff window values for both data and initial ranging and sends these
values downstream as part of the Bandwidth Allocation Map (MAP) MAC message. The
values are power-of-two values. For example, a value of 4 indicates a window between 0 and
15; a value of 10 indicates a window between 0 and 1023.

BSR:7A(config-us)#cable upstream <X/Y> range-backoff <0-15> <0-15>

where:
X/Y is the RX48 upstream RF channel number (0-5) and logical channel number
(0-3).
0-15 the start of range-backoff.
0-15 the end of range-backoff.
BSR:7A(config-us)#cable upstream <X/Y> range-backoff 2 6
The range-backoff configuration shown above is a good starting point for most
networks and is much better than the default configuration of 0 4. Depending on the
network and the number of cable modems, the range backoff should be increased to 4
10.
If Upstream Channel Bonding is configured and running, the range-backoff should be
set to 4 10.
Note: Use the show controllers cable upstream command to display the current
range-backoff settings.
If the range-backoff values are changed, all cable modems need to re-register before the new
range-backoff values are in effect.

Configuring the Boot ROM Filename

Configuring the Boot ROM filename allows a BSR module to easily acquire a new
Boot ROM image if there is a system failure.
The bootrom-filename command sets the BSR Boot ROM filename using a Boot
ROM image file stored in NVRAM on the SRM10G module or on an FTP server.
BSR:7A(config)#bootrom-filename nvram: <filename>
filename is the user-specified filename of the boot ROM image stored in
NVRAM.
For example:
BSR:7A(config)#bootrom-filename NVRAM:roms3_70040.Z
Note: When a new standby SRM10G module is inserted into the BSR chassis, the Boot
ROM image file is not automatically copied to the redundant SRM10G. The Boot ROM image
file must synced manually.
Use the sync file command, in Privileged EXEC mode, to synchronize all files stored
in NVRAM between an Active SRM10G module and a Standby SRM10G module
including the startup and running configuration files.
BSR:7A#sync file nvram: <filename>
where:
filename is the name of a file stored in NVRAM.
Enabling Remote Query

Remote query is an invaluable troubleshooting tool. The cable modem remote-query
command enables the remote query features polling operation, configures the polling
interval to use when querying each cable modem, and specifies the SNMP community
name to use when to reading a cable modems RF parameters. The new polling
interval starts immediately when specified with this command. The no cable modem
remote-query command disables remote query polling.
BSR:7A(config)#cable modem remote-query <1-86400>
<snmp-community-name>
where:

1-86400 configures the interval, in seconds, that the remote query task waits after
completing one full polling cycle of all cable modems before starting the next
polling cycle.
snmp-community-name is the SNMPv1 community name that the remote query
task uses to read a cable modems RF parameters.
Note: The remote query feature polls cable modems using SNMPv1 only. The MSO must
configure cable modems to accept the SNMPv1 community string specified with the cable
modem remote-query command.
Since the remote-query functions use SNMP "sets" and "gets" to the cable modem,
the cable modem configuration file must allow SNMP from the BSR with matching
community strings. By default, the BSR uses the CM loopback IP address as the
source IP address for these SNMP queries. This can be set to other interface IP
addresses with the cable modem remote-query source-interface command.
BSR:7A(config)# cable modem remote-query 3600 public
Enabling Remote Set

The cable modem remote-set command enables the "set/write" SNMP community
string for a cable modem. The cable modem remote-set command allows for
instantaneous resets of a cable modem. The SNMP community names will have to be
specified in the cable modems configuration file.
BSR:7A(config)#cable modem remote-set <snmp-community-name>
where:
snmp-community-name is the SNMPv1 write community string to access the
cable modem.
BSR:7A(config)# cable modem remote-set private
If SNMP access is restricted in the cable modems configuration file, a BSR loopback
interface needs to be enabled with the cable modem remote-set source-interface
loopback command:.
BSR:7A(config)#cable modem remote-set source-interface loopback <1-255>

where:
1-255 configures the remote set source interface for the specified loopback
interface number.
Sending Events to a SYSLOG Server

The BSR generates log messages when there are configuration changes or when
network or device events occur. The BSR logging can be configured to save these log
messages to a file or direct log messages to a system console, log buffer, or other
devices.
By default, the BSR logs normal but significant log messages to its internal log buffer
and then sends these messages to the system console. You can specify which system
messages should be logged based on the severity level of the message.
Sending less significant log messages to a SYSLOG server offloads log messages that
are not displayed on the system console and are also taking up space in the BSRs log
memory buffer.
1. The logging on command starts the SYSLOG and starts sending messages to a
logging process. The no logging on command disables the SYSLOG. The
SYSLOG is disabled by default.
BSR:7A(config)#logging on
2. Identify the SYSLOG server and specify the severity level of messages to be
logged to the SYSLOG server with the logging command, in Global
Configuration mode, as shown below:
BSR:7A(config)#logging <A.B.C.D> [alerts | critical | emergencies | errors |
where:
A.B.C.D is the IP address of the SYSLOG server.
alerts logs conditions where immediate action is needed.
critical logs critical conditions.
emergencies logs emergency conditions where the system is unusable.
errors logs error conditions.
informational logs informational system messages.
notifications logs normal but significant conditions.

warnings logs warning conditions.

information.
BSR:7A(config)#logging <A.B.C.D> informational
BSR:7A(config)#logging <A.B.C.D> notifications
3. The logging trap and logging snmp-trap commands set the logging level sent to
a SYSLOG or SNMP trap server. Setting this to a particular severity level will
send all severity messages greater than and including the set severity level.
The following example configures the SYSLOG server to log all messages from
warnings (severity level 4) up to emergencies (severity level 0):
BSR:7A(config)#logging trap warnings
BSR:7A(config)#logging snmp-trap warnings
information.
Repeated Log Detection

Repeated Log Detection (RLD), introduced in Release 7.1.1, dynamically caches and
suppresses repeated messages destined to the log file as well as the SYSLOG server.
By default, RLD will:
Cache messages in a sliding 15-minute window.
When there are more than 10 repeated unique events in that window, they will be
replaced with a repeated message.
If a message continues to occur and is continually suppressed, the system will
generate a report every 60 minutes listing the number of messages suppressed.
The default configuration command is:
BSR:7A(config)#logging repeated filter warnings 15 10 summary 60

Configuring an SNTP Server

The Simple Network Time Protocol (SNTP) provides system time with high accuracy.
Configure the BSR to operate in client mode with the remote system at the specified
address. This way the BSR will be synchronized to the remote system time.
For logged messages to be accurately timestamped, an SNTP server must be
configured as shown in the following procedure.
Note: The clock timezone command must be configured before configuring SNTP on the
BSR. If the clock timezone command is not configured, then time fluctuations will occur
during a switchover if the Primary SRM10G module switches to the Standby SRM10G
module and the standby does not have the timezone configured.
1. The clock timezone command allows you to set the time zone for the system. The
no clock timezone command changes the system time to Universal Time
Coordinated (UTC).
BSR:7A(config)#clock timezone 5 0
This configuration indicates Eastern Standard Time.
where:
5 is the hours corrected from UTC, range -23 to 23.
0 is the non-negative difference in minutes corrected from UTC, range 0 to
59.
2. The clock summer-time command changes the BSR clock offset from the
currently configured time zone at the start and end times specified in the
command. The no clock summer-time command restores the default daylight
saving time configuration.
BSR:7A(config)#clock summer-time EDT 60 start 2 sun mar 2:00 end first
sun nov 2:00
where:
EDT is the name of the time zone during daylight saving time.
60 is the minute offset to be added during daylight saving time.
start is the start of daylight saving time

2 is the week of the month.

sun is the day of the week.
mar is the month of the year.
2:00 is the time of day.
end is the end of daylight saving time.
first is the week of the month.
sun is the day of the week.
mar is the month of the year.
2:00 is the time of day.
3. The sntp server command configures the BSR to query the specified server for
the correct time. The no sntp server command disables the BSR from receiving
NTP traffic.
A secondary SNTP server can also be configured as a backup in case the primary
SNTP server goes down unexpectedly. This secondary SNTP server
automatically becomes the primary SNTP server after 5 unsuccessful attempts to
contact the primary SNTP server.
BSR:7A(config)#sntp server <A.B.C.D>
BSR:7A(config)#sntp server <A.B.C.D> secondary
where:
A.B.C.D is the SNTP servers IP address.
secondary specifies this SNTP server as a secondary SNTP server.
4. The sntp timer command specifies the time interval between queries to the
SNTP server. The no sntp timer command removes the time interval.
BSR:7A(config)#sntp timer <16-16284>
where:
16-16284 is the SNTP server query interval in seconds.
BSR:7A(config)#sntp timer 3600

Configuring Voice
ARRIS recommends the following VoIP QoS implementation for all voice
applications to ensure voice quality. This implementation will prioritize voice packets
over the best-effort data traffic. This is necessary to ensure the delay-sensitive voice
traffic is processed ahead of the data.
Configuring Downstream Voice Priority
Configuring Upstream Voice Priority
Configuring a Service Class for Voice
Configuring the Packet Cable Active Timeout
Configuring Downstream Voice Priority

To implement downstream VoIP QoS, use the following configuration procedure:
1. Add a new Access Control List (ACL) (ACL 134 is used as an example) which
matches downstream traffic from any source with a destination of the eMTA IP
Subnet. This will include voice bearer packets, voice signaling packets, and
management traffic to the eMTA.
BSR:7A(config)#access-list 134 permit ip any <MTA IP Subnet> <MTA IP
Subnet Mask>
2. Create a new route-map (SELECTQOS-DS is used as an example) for the newly

created ACL and configure the match and set actions as follows:
BSR:7A(config)#route-map SELECTQOS-DS permit 50
BSR:7A(config-rmap)#match ip address 134
BSR:7A(config-rmap)#set ip qos queue 1
3. Apply the SELECTQOS-DS route-map to the HSIM interface.

BSR:7A(config)#interface gigaether 7/0
BSR:7A(config-if)#ip policy route-map SELECTQOS-DS
BSR:7A(config-if)#qos queue 0 bw 50
(This is the QoS queue to be used for non-voice traffic)

BSR:7A(config-if)#qos queue 1 bw 45
(This is the QoS queue for voice traffic)
Note: The qos queue 1 bw value of 45 has been selected to provide more than enough
bandwidth to support voice and minimize any delay.
If any QoS queue is not using its assigned bandwidth, then that bandwidth is available for
other traffic, e.g. if there is no voice traffic, then data traffic is permitted to use all of the
bandwidth.
There are a total of 8 QoS queues (0-7) with the higher number queues having the higher
priority.
Configuring Upstream Voice Priority

To support applications that send voice packets directly between eMTAs (e.g. do not
back haul the voice bearer packets to the Media Gateway) and when upstream voice
traffic may be "redirected" from one HSIM to another HSIM, a route-map should be
added to the cable interface to provide QoS for voice calls between two eMTAs on the
same BSR.
An upstream route-map is required on the cable interface because all user upstream
packets received on the cable interface are forwarded to the HSIM. If the HSIM
determines that the destination of the upstream packets is one of the cable interfaces,
it will forward the packets to that cable interface. The HSIM only applies the
route-map to the Ingress port, not on to packets traversing the HSIM. Defining the
queue on the Ingress of the cable interface allows the packets to be properly
prioritized over the best effort traffic.
To implement upstream VoIP QoS, use the following configuration procedure:
1. Add a new Access Control List (ACL) (ACL 131 is used as an example) which
matches upstream traffic from any eMTA IP Subnet. This includes voice bearer
packets, voice signaling packets, and management traffic to the eMTA.
BSR64K-5:7A(config)#access-list 131 permit ip <MTA IP Subnet> <MTA
IP Subnet Mask> any

2. Create a new route-map (SELECTQOS-US is used as an example) for the newly

created ACL 131 and configure the match and set actions as follows:
BSR:7A(config)#route-map SELECTQOS-US permit 10
BSR:7A(config-rmap)#match ip address 131
BSR:7A(config-rmap)#set ip qos queue 1
3. Apply the SELECTQOS-US route-map to each cable interface:

BSR:7A(config)#interface cable 0/0
BSR:7A(config-if)#cable bundle 1
BSR:7A(config-if)#no ip address
BSR:7A(config-if)#ip policy route-map SELECTQOS-US
Configuring a Service Class for Voice

With the large amount of grant servicing being done on a single cable modem, the
Packet Cable Multimedia (PCMM) provisioning configuration must guarantee an
optimal quality of service for all service flows on the cable modem. Specifically, there
must be an acceptable packet latency that will not translate into voice jitter.
A recommended PCMM configuration is shown below:
BSR:7A(config-srvclass)#max-latency 20
(Assumed packetization interval 20 milliseconds
BSR:7A(config-srvclass)#grant-size 240
(Unsolicited Grant Size 240 bytes)
BSR:7A(config-srvclass)#grants-per-interval 1
BSR:7A(config-srvclass)#grant-interval 9000
(Nominal Grant Interval 9000 microseconds)
BSR:7A(config-srvclass)#grant-jitter 2000
(Tolerated Grant Jitter 2000 microseconds)
BSR:7A(config-us)#cable upstream <X> map-interval 4000
(Upstream map-interval 4000 microseconds)

The recommended configuration for a packetization interval of 20 milliseconds

mandates an Unsolicited Grant Size of 240 bytes
To keep up with the rate of grants being offered, the upstream map-interval
configured on the BSR should not be set higher than 5000 microseconds. The
recommended value is 4000, which is the default.
The Nominal Grant Interval should not be set to align with the packetization
interval of 20 milliseconds (20000 microseconds). If a cable modem were to miss
a grant in such a configuration, it would have to wait for an entire grant interval
before being able to send out a packet. This would result in close to a 20000
microsecond latency, which would translate to voice jitter and possible backlog of
subsequent packets. Set the Nominal Grant Interval to a value that lets packets
utilize a subsequent grant in time if the original grant was missed. The
recommended value for this configuration is 9000 microseconds.
Configuring the Packet Cable Active Timeout

Cable modems dynamically allocate resources such as service identifiers (SIDs) and
bandwidth by using a Dynamic Service Addition (DSA) transaction. If a cable modem
fails to issue a Dynamic Service Deletion Request (DSD-REQ) to the cable interface
or the DSD-REQ is being dropped for any reason (e.g. due to noise), these resources
could be held by the cable interface indefinitely. For this reason, an active timeout
interval should be configured on the cable interface so that the cable interface can
remove the dynamic service flows by issuing the DSD-REQs to the cable modem
when the timer expires.
The cable dynamic-service active-timeout command specifies an active timeout for
dynamic service flows. The active timeout is the time since the dynamic service was
used. As long as the dynamic service continues to receive at least one packet within
this interval, the service is not deleted. If using PCMM, the activity timeout must be
configured to prevent sessions from hanging. The activity timeout value is configured
in cable interface configuration mode.
BSR:7A(config-if)#cable dynamic-service active-timeout <0-65535>
where:
0-65535 is the active timeout in seconds. It is set to "0" (disabled) by default.
BSR:7A(config-if)#cable dynamic-service active-timeout 60

Disabling the Empty Channel Load Balancing

Restriction
The cable load-balancing empty-channel restricted command prevents moves of
cable modems or MTAs to channels within a load balancing group that have no
registered cable modems or MTAs. The no cable load-balancing empty-channel
restricted command lifts this restriction and allows these devices to be moved to
empty channels. ARRIS recommends the latter configuration.
BSR:7A(config)#no cable load-balancing empty-channel restricted
The no cable load-balancing empty-channel restricted command allows the BSR to
load balance an upstream channel that has no registered cable modems.
Caution: Using the no cable load-balancing empty-channel restricted command

introduces the possibility of moving cable modems to an inoperable channel.
Resetting Non-Bonded Cable Modems

The cable downstream non-bonding-reset interval configures the periodic resetting
of bonding capable cable modems operating in a non-bonded mode after a specific
time interval. The command checks for downstream voice flows to determine if there
is an active call on a cable modem before resetting it. If there is an active call, the
cable modem is not reset. The no cable downstream non-bonding-reset interval
command disables the periodic resetting of bonding capable cable modems operating
in a non-bonded mode after a specific time interval.
BSR:7A(config)#cable downstream non-bonding-reset interval <5-10080>
where:
5-10080 is the reset interval in minutes. It is disabled by default.
BSR:7A(config)#cable downstream non-bonding-reset interval 60
This will reset a cable modem that is not registered as bonded after 60 minutes if the
cable modem is capable of bonding and bonding is configured.



10
Technical Solutions
Overview
This chapter describes issues that have been identified and resolved with a
configuration, procedure, or upgrade, usually described in a Technical Bulletin. Some
solutions in this chapter do not apply to this release (for example, SRM4 procedures),
but are included for use with earlier releases.
List of Solutions
The following solutions are described in this chapter:
2:8 CMTS to RX48 Upgrade Practices on page 10-2
3-Slot I/O Module in Slot 15 on page 10-5
ACL Port Ranges on page 10-7
Air Filter Maintenance on page 10-8
Blank Module Requirements on page 10-9
BPI Security Recommendation on page 10-10
Chassis Fan / Blower Module Connector on page 10-12
CM IP Address Issue with Cable Privacy Mandatory on page 10-15
Gigabit Ethernet Protective Boot on page 10-16
Loose SFPs Could Cause SRM10G Reset on page 10-18

Outpost24 TCP Issues on page 10-19

PLL Loss After Switchover Issue on page 10-20
Redundancy DRX Reset-After-Switchover on page 10-21
RX48 Power Surge Recovery on page 10-22
Shut/Noshut MAC Domain Modem Recovery on page 10-23
SNMP Timeout on page 10-24
SRM Ethernet 7/0 Port Restrictions on page 10-25
SRM10G Occasional Packet Loss on page 10-26
SSH Causes SRM4 Reset on page 10-27
Subnet Migration on page 10-28
TX32 Module Replacement Procedure on page 10-29
2:8 CMTS to RX48 Upgrade Practices

This provides information on 2:8 CMTS to RX48 module upgrade practices. This
includes a procedure which will preserve the integrity of the BSR databases.
Release
6.0 and later
Description
The BSR 64000 supports mixed deployment of 2:8 and RX48 modules within the
same chassis. In a mixed deployment chassis, only 2:8 or RX48 redundancy is
supported, not both. When replacing 2:8 CMTS modules with RX48 modules, all 2:8
related configurations or references for those slots must be removed from the system
databases.
The upgrade procedures below ensure that the BSR 64000 properly clears out any 2:8
references or configurations where appropriate.
Solution Type
Hardware and software procedures
Solution - All RX48

Use the following procedure to upgrade a BSR 64000 chassis from an all-2:8 system
(with or without TX modules) to an all-RX48 system (no 2:8 modules), with TX
modules.

Release 8.0.0 Technical Solutions
Note: The following procedure will wipe out all CMTS-related configurations, but
will retain network and other non-CMTS-related configurations.
This procedure requires that the BSR system software and boot ROMs have already
been upgraded to a version of software which supports the RX48 module.
1. Store a backup copy of the current running configuration by entering the
following command:
copy running-config nvram:run_backup
2. Disable any redundancy configurations by entering the appropriate no
redundancy command from configuration mode for each protected slot.
3. Remove all 2:8 resource modules, including any redundant 2:8 modules.
4. Remove all 2:8 I/O modules. Be sure to remove any I/O in slot 6.
5. If TX modules will remain in the same slots, then continue to Step 6. Otherwise
unseat any TX modules present and the associated rear I/O modules.
6. Enter the copy running-config startup-config command.
7. Power off the BSR.
8. Seat/secure all new RX48 I/O modules.
9. Seat/secure all RX48 resource modules.
10. If TX modules were not removed in Step 5 continue to Step 13.
11. Seat/secure each TX I/O module.
12. Seat/secure all TX resource modules.
13. Power on the BSR and wait for all modules in the BSR to reach the run or standby
state.
14. If applicable, enable redundancy for each protected slot by removing the no
redundancy statements configured in Step 2.
15. Configure the TX and RX48 modules to support your new network configuration
and save the configuration again.

Solution - Mixed System

This section describes the procedure to use when replacing 2:8 modules with RX48
modules while keeping some 2:8 modules in the system. This procedure assumes that
any TX modules in the system will remain in the original slots. If this is not the case,
ARRIS recommends that you follow the "All RX48" upgrade procedure above,
moving the TX cards while the system is powered off.
This procedure requires that the BSR system software and boot ROMs have already
been upgraded to a version of software which supports the RX48 module.
1. Ensure that all 2:8 modules are running on their primary slot if redundancy is
present.
2. Disable any redundancy configurations by entering the appropriate no
redundancy command from configuration mode for each protected slot.
3. Remove the 2:8 redundant module if present in slot 6 (even if the 2:8 redundancy
will be utilized after changing the configuration).
4. Remove any I/O module present in slot 6.
5. Remove any 2:8 front resource modules that will be replaced by RX48 modules.
6. Remove any 2:8 rear I/O modules that will be replaced by RX48 I/O modules.
7. If TX modules will remain in the same slots, then continue to Step 8. Otherwise
unseat any TX modules present and the associated rear I/O modules.
8. Enter the copy running-config startup-config command.
9. Power off the BSR.
10. If enabling RX48 or 2:8 redundancy, install the appropriate redundant I/O in
slot 6.
11. Install the new RX48 I/Os.
12. If enabling CMTS redundancy, install the redundant RX48 or 2:8 module in
slot 6.
13. Install the new RX48 primary modules.
14. If TX modules were not removed in Step 7, continue to Step 17.
15. Seat/secure each TX I/O module.
16. Seat/secure all TX resource modules.

17. Power on the BSR and wait for all modules in the BSR to reach the run or standby
state.
18. Enter the copy running-config startup-config command. When prompted,
confirm that you wish to continue with the copy.
19. Configure the TX and RX48 modules to support your new network configuration
and save the configuration again.
20. If applicable, enable redundancy for each protected slot by removing the no
redundancy statements configured in Step 2 and save the configuration again.
3-Slot I/O Module in Slot 15

This describes an engineering change to the TX32 3-slot I/O module that makes it
compatible with slot 15 of a BSR 64000 chassis.
Release
All
Description
A new revision of the TX32 3-slot I/O module, identified with the plus sign (+)
after the word PROTECTED on the exterior label (PROTECTED +), is physically
compatible with slot 15 of the BSR 64000 chassis. The PDM part number for the
compatible module is changed to 570760-001-00, but the orderable part number is
unchanged.
Orderable Part PDM Part

Number Number Exterior Label Slot 15 Use
537809-001 548848-001-00 TX32 3-SLOT I/O not compatible
PROTECTED
537809-001 570760-001-00 TX32 3-SLOT I/O compatible
PROTECTED +
With this revision, the TX32 3-slot rear I/O module may be deployed in slots 13, 14,
and 15 with the TX32 Standby front module occupying slot 14 and TX32 Primary
front modules in slot 13 and/or 15 of the BSR 64000 chassis.

Solution Type
Hardware change
Solution
Use a "PROTECTED +" TX 3-slot I/O module with slots 13 - 15 of the chassis.

ACL Port Ranges

This describes the function of port ranges within the access control list (ACL) feature
on the BSR 64000.
Release
All
Description
When the ACL range is specified, any packet that matches the first set of criteria is
then subject to an implicit "permit" or "deny," without further processing of the packet
for other ACLs.
Solution Type
Documentation example
Solution
Examples:
access-list 107 deny tcp any any range 137 139
The above example denies TCP traffic in the range of ports 137-139, and permits all
other TCP traffic, without further processing of the packets for ACLs.
access-list 107 permit tcp any any range 161 162
The above example permits TCP traffic in the range of ports 161-162, and denies all
other TCP traffic without further processing of the packets for ACLs.

Air Filter Maintenance

This describes BSR 64000 air filter maintenance to ensure proper cooling and
expected product life of the chassis.
Release
All
Description
The BSR 64000 ships without the air filter installed. ARRIS recommends that the air
filter be used.
The BSR 64000 Fan and Blower Module airflow must be unimpeded, so that required
operating temperatures in the chassis can be maintained. A clogged or soiled air filter
can impede airflow. Periodic inspection and replacement of the air filter is necessary
to maximize airflow through the chassis during operation.
Generally, you can expect to replace the air filter approximately every 6 to 12 months.
Solution Type
Hardware procedure
Solution
Inspect the air filter of each BSR 64000 monthly to determine whether it needs
replacing, and develop an air filter replacement schedule based on your observations.
At a minimum, replace the air filter every 12 months.
To order replacement air filters from ARRIS, reference part number 500670-001-00.
Two filters come in each package.
For air filter installation procedures, refer to your hardware installation
documentation.

Blank Module Requirements

This describes the requirement for blank modules to be installed in all empty front
slots of the BSR 64000 configured for I-CMTS operation with TX and RX48 modules
installed, to maintain optimal cooling.
Release
All
Description
The TX32/TXPlus and RX48 I-CMTS modules are designed with high performance
integrated circuit components required to support DOCSIS 3.0 technology, providing
significant increase in both channel capacity and bandwidth performance. This
increase in performance requires additional power in comparison to legacy DOCSIS
2.0 2:8 CMTS modules for the BSR 64000.
To assure uniform airflow across all slots of a partially populated BSR 64000 chassis,
blank modules are required to be installed in all empty slots. This uniformly directs
airflow across all populated front slots to provide optimum cooling for all supported
BSR 64000 I-CMTS configurations.
Solution Type
Hardware procedure
Solution
A Blank Front Module must be installed into each empty front Resource Module slot
to ensure uniform airflow and proper operation of the BSR 64000 when running with
an I-CMTS configuration (TX and RX48 cards installed). Each Blank Module must
be paired with a Rear I/O Filler Panel in the corresponding rear I/O slot.
There are two versions of the Blank Front Module for the BSR 64000:
BSR 64000 Blank Module Front - Ivory (compatible with Slots 0-6 and 9-15)
BSR 64000 Blank Module Front - Blue (compatible with SRM Slots 7 and 8)

Make sure that you are using the correct one for the slot you are populating.
Table 10-1 summarizes the available blank module options for the BSR 64000
orderable in either single slot or 11 slot quantities:
Table 10-1
Module Part Number

BSR 64000 Blank Module Front - Ivory 579932-001-00
BSR 64000 Rear I/O Filler Panel - Ivory 579939-001-00
BSR 64000 Blank Module Front Bulk (11) - Ivory 579937-001-00

BSR 64000 Rear I/O Filler Panel Bulk (11) - Ivory 580269-001-00
BSR 64000 SRM Blank Front Module - Blue 579638-001-00
To install a blank module, do the following:

1. Loosen the two captive screws on the filler panel.
2. Grasp the filler panel by its two captive screw collars, then pull firmly to remove
it from the unpopulated slot.
3. Slide the blank module into the chassis until it stops.
4. Tighten the captive screws on the blank module.
5. Repeat these steps for all empty front module slots.
Note: Blank front modules must be paired with Rear I/O Filler Panels in the
corresponding rear I/O slots.
BPI Security Recommendation

This describes an equivalent configuration recommendation which will implement the
same security functionality as cable privacy mandatory without encountering a
potential service-impacting issue.
Release
5.2.1

5.2.2
5.3.1
6.x
Description
An issue was identified in software releases 5.2.1, 5.2.2, 5.3.1 and 6.x when using
cable privacy mandatory. This can result in result in cable modems not acquiring a
valid host IP address.
Solution Type
Workaround
Solution
To enforce BPI and BPI+ security on cable modems of all DOCSIS versions, with the
same security measures as cable privacy mandatory, implement the following:
1. Ensure all cable modem configuration files contain BPI security.
2. Configure the following on the BSR:
cable security authorized
cable privacy enforce-bpi-plus
Cable privacy mandatory enforces the following rules for BPI and BPI+, regardless
of cable modem configuration.
DOCSIS 1.0 devices MUST use BPI
DOCSIS 1.1, 2.0, and 3.0 devices MUST use BPI+
When BPI and BPI+ are configured in the cable modem file, cable privacy
enforce-bpi-plus enforces the same rules as cable privacy mandatory, but is
dependent on the cable modem configuration file. To ensure that a valid modem
configuration file is used, the cable security authorized command is required to
enforce the original CM configuration file parameters.
When first enabling the cable security feature, ARRIS recommends configuring the
feature to implement mark mode for field trial to ensure there are no
interoperability issues with modems on the network. Running in mark mode will
identify modems suspected of falsifying the configuration file and provide
opportunity to determine if false positives are being detected.

BSR:7A(config-if)# cable security authorized

BSR:7A(config-if)# cable security failure mark
"Mark" mode detects modems that fail the security check but still allow them to
register after 3 failures, and mark them with an exclamation point (i.e. "!online") in
show cable modem output. Confirm expected operation by evaluating devices that
are labeled as !online.
After confirming expected functionality during the trial period, modify the feature to
run in reject mode to implement full functionality and disallow registration of
malicious users.
BSR:7A(config-if)# cable security failure reject
Chassis Fan / Blower Module Connector

This describes an issue where BSR 64000 chassis connectors are damaged when
installing or removing a fan or blower module from a BSR 64000.
Release
All
Description
Installation or removal of a fan or blower module with excessive force can damage
the Molex Blind Mate Interface (BMI) connectors that secure the fan or blower
module in the chassis and supply power to the module. The Molex connectors used in
the BSR 64000 chassis can have a rare manufacturing defect that causes weakness in
the connector making the connector easier to damage during installation or removal of
a fan or blower module.
When excessive force is used to install (or remove) a fan or blower module from the
BSR 64000 chassis, one or both of the BMI connector posts can break. As a result, on
installation, the fan or blower module does not connect to the chassis BMI connector
and will fail to operate. An alarm is logged when the fan or blower module fails to
operate.
Solution Type
Hardware procedure

Solution
Figure 1 shows an undamaged chassis connector and its connector posts. During
installation or removal of a fan or blower module, the connector posts can break when
excessive force is used to seat (or remove) the fan or blower module in the chassis, as
shown in Figure 2. Once the connector posts break there is nothing to secure the
chassis connector in the chassis housing as shown in Figure 3.
Since there is no way to determine if a BSR 64000 has weak Molex BMI
connectors, ARRIS recommends that customers install or remove a fan or blower
module slowly, applying force gradually, to avoid damage to the chassis BMI
connectors. When installing a fan or blower module and it is seated properly in the
BSR 64000 chassis, secure the module in the BSR 64000 using its captive screws.

Figure 1: Undamaged Upper Blower and Lower Fan Chassis Connectors
Figure 2: Damaged Lower Fan Chassis Connector
Figure 3: Sheared off Molex Connector Guide Post and Resulting

Disconnection of Connector to the Chassis

CM IP Address Issue with Cable Privacy

Mandatory
This describes a condition where a cable modem registered on a TX downstream does
not acquire a valid host IP address when cable privacy mandatory is configured.
Release
5.2.1
5.2.2
5.3.1
Description
When cable privacy mandatory is configured either globally or on the interface, BPI
encrypted DHCP packets destined for a TX32 downstream may be corrupted. This
corruption impacts the destination MAC address field within the Ethernet header. As a
result, cable modems drop downstream DHCP packets that are intended for CPE
devices and the CPE devices fail to complete DHCP.
Solution Type
Workaround; Patch
Solution - Workaround
Disabling cable privacy mandatory at the global and interface level is a short-term
solution to recover subscriber services until a patch or software fix is available for
implementation.
Disabling the global configuration:
BSR:7A#config
BSR:7A(config)#no cable privacy mandatory
Disabling on every cable interface:
BSR:7A#config
BSR:7A(config-if)#no cable privacy mandatory
The cable security authorized feature will mitigate risks associated with disabling
cable privacy mandatory.
Enabling cable security authorized:
BSR:7A#config


BSR:7A(config-if)#cable security authorized
Solution - Patch
As an alternative to the workaround, persistent and non-persistent patches can be used
to avoid the DHCP packet corruption without disabling cable privacy mandatory.
Until a root cause solution is available, this patch allows the BSR 64000 to continue
BPI authentication enforcement using cable privacy mandatory. The patch does this
by disabling BPI encryption for DHCP packets. The cable privacy mandatory
command will continue to enforce the use of BPI encryption for cable modem and
CPE data traffic.
Contact Motorola Support for access to the appropriate patch file:
5.2.1P27.01
5.2.1P31
5.2.1P37
Gigabit Ethernet Protective Boot

This describes actions that need to be taken to avoid damage to Gigabit Ethernet
resource modules during physical installation into the BSR 64000 chassis.
Release
All
Description
Gigabit Ethernet resource module optical connectors have rubber boots covering them
during shipment. When you install a module, you must remove this rubber boot
before installation. If you meet resistance while attempting to install a Gigabit
Ethernet resource module into a BSR 64000 chassis slot, or if the module stops before
its front panel is flush with the other installed modules, remove it and check to make
sure that the rubber boot has been removed from the modules optical connector.
Solution Type
Hardware procedure

Solution
Figure 1 shows the rubber boot installed on the module as shipped. Figure 2 shows the
rubber boot removed from the module, ready to install in the BSR 64000 chassis.
Figure 1 Figure 2

Loose SFPs Could Cause SRM10G Reset

This describes an issue where a loose SFP could cause the SRM10G module to reset.
Release
7.1.0 and later
Description
ARRIS identified an issue on the BSR 64000 where a loose SFP or fiber, not fully
inserted, could cause the SRM10G module to reset. The symptoms of this issue could
include a ring buffer overflow error. In that event, the following error messages
could be generated:
- 08 HSIM:tIrqTask]panic: netJobAdd: ring buffer overflow!
- 08 HSIM:LOG]-repeat 2:
- 08 HSIM:tIrqTask]panic: netJobAdd: ring buffer overflow!
Solution Type
Hardware procedure
Solution
If a "ring buffer overflow" occurs, check the SFP connections and make sure that they
are fully inserted and are not loose. Please try this before sending the module back for
service.

Outpost24 TCP Issues

This addresses the CERT-FI Advisory on the Outpost24 TCP issues related to the
BSR 64000.
Release
5.x
Description
The advisory identifies vulnerabilities of the TCP protocol (RFC 793) found on some
operating systems by running the Outpost24 Sockstress tool. The TCP issues exposed
may increase the susceptibility to Denial of Service (DoS) attacks with malicious TCP
packet manipulation. The CERT-FI Advisory reference number is FICORA #193744.
The BSR 64000 uses the Wind River VxWorks embedded operating system for the
implementation of the TCP protocol. Wind River has determined the vulnerabilities
described by the CERT-FI advisory can potentially affect the systems and applications
running the TCP protocol. However, the impact on the VxWorks operating system is
only temporary and the system will recover when the TCP packet manipulation is
halted. Wind River is providing the necessary software patches to address the
vulnerabilities.
Solution Type
Workaround; Software upgrade
Solution
The Outpost24 TCP state manipulation vulnerability requires a full three way TCP
handshake to be completed in order to manipulate the TCP state tables. This
vulnerability can be addressed by the implementation of access lists and trusted hosts
configurations on the BSR 64000.
ARRIS has incorporated the VxWorks updates in the BSR software maintenance
releases. Please contact your local ARRIS support representative for release
availability.

PLL Loss After Switchover Issue

This describes a firmware update to alleviate an issue on Vectron Timing Modules of
TX32 and RX48 front resource modules that may occur following an SRM
switchover. Modules manufactured after mid-2011 include the updated firmware.
Release
All
Description
After an SRM installation and then a switchover to that SRM, modems may deregister
and re-register repeatedly due to PLL loss on the TX32 and RX48 modules. The
workaround is to reset the chassis.
The initial condition is initiated by a latchdown or removal of the SRM card. However
at this time cable modems and CPEs will continue to operate normally on the active
SRM card. At subsequent giveback, the timing modules on either the TX32 or RX48
are unable to lock on to the SRM 10 Khz clock source. This results in PLL loss and
therefore causes cable modem deregistration and high packet loss. The show
redundancy command can be used to identify the PLL loss issue.
Solution Type
Firmware update
Solution
The Vectron Timing Module FPGA firmware on TX32 and RX48 hardware must be
updated to correct this problem. The corrected firmware versions are:
TX32: 02020010 or later
RX48: 02020020 or later
The boot ROM code on the affected hardware modules can be upgraded to 6.0.0.52 or
later to avoid an error message associated with the version of the Timing Module
firmware which older boot ROM code does not recognize as valid; or the error
message can be ignored.

Redundancy DRX Reset-After-Switchover

This provides instructions to prevent an issue where changing the redundancy drx
reset-after-switchover command setting may cause an RX48 module reset and cable
modem registration issues.
Release
All
Description
By default, the BSR 64000 automatically resets the surrendering module as part of an
RX48 module failover. This allows the surrendering module to properly synchronize
its redundancy records when going into a Standby state following the reset. This
default behavior is configured with the following CLI command:
redundancy drx reset-after-switchover
(Note: This default applies only to RX48 modules. TX32 and 2:8 CMTS modules
default configurations are no redundancy dtx reset-after-switchover and no
redundancy cmts reset-after-switchover, respectively.)
ARRIS does NOT recommend disabling the automatic reset, as this may lead to RX48
module resets and cable modem registration issues. Some customers may have
overridden/disabled the default behavior by configuring the following command:
no redundancy drx reset-after-switchover
Solution Type
Software configuration
Solution
If you have overridden the default behavior, you should change the command back to
the default behavior.
To verify that the default is configured, enter the following command on the BSR
64000:
BSR:7A#show run | include reset-after-switchover
redundancy drx reset-after-switchover
Note: Although redundancy drx reset-after-switchover is displayed in a
non-verbose show run output, it is default behavior.

RX48 Power Surge Recovery

This describes the solution to an issue where RX48 modules do not recover after a
power surge.
Release
6.x and later
Description
A software issue has been identified where most RX48 modules do not recover after a
power surge. The RX48 Power Monitor logic needs to support recovery auto-retry
under these circumstances.
Solution Type
Software upgrade
Solution
The solution to this issue is to install an updated boot ROM image. The required boot
ROM depends upon the BSR 64000 Software Release you are running:
Table 10-2
Release Boot ROM

6.x 6.0.0.61 (or later 6.0.0.xx)
7.x 7.0.0.31 (or later 7.0.0.xx)
Run the show version slot <RX48> command and compare the listed software release
and boot ROM versions to the required boot ROM versions to fix this issue.
Contact ARRIS Support for access to the boot ROM images. Follow the standard boot
ROM upgrade procedures described in your BSR 64000 Software Release Notes to
install the newer boot ROM images.

Shut/Noshut MAC Domain Modem Recovery

This describes an issue where a MAC domain shut/noshut action left all modems
offline on some MAC domains.
Release
7.1.1.2
Description
On occasion, after shutting down and re-enabling a MAC domain, modems will not
register. The issue leaves cable modems offline until administrative action is taken to
recover the devices. The root cause of this behavior remains under investigation. Until
a solution can be provided, ARRIS recommends that operators follow the recovery
methods below.
Solution Type
Recovery procedure
Solution
There are two potential recovery methods you can use to alleviate this issue.
Recovery Method 1:
1. Switchover to the Standby RX48 module.
2. By default, the Primary RX48 module should reset automatically, but if it doesnt,
manually reset the Primary RX48 module.
3. After the Primary module has come back up (it will be in Standby mode),
switchover control back to the Primary module.
4. Check the cable modems.
To confirm if this recovery method worked, you should check to see if the entire
MAC domain is offline. If there is a subset of cable modems still having trouble
registering, then this is likely a different issue and you should contact ARRIS for
support. However, if the problem persists (the entire MAC domain is offline) move to
Recovery Method 2.
Recovery Method 2:
Reload the BSR.

SNMP Timeout
This describes an issue with SNMP timeouts.
Release
6.3
6.4.0
7.0.0
7.1.0.2
Description
During high activity on some BSR 64000 configurations, it is possible for SNMP
client collectors to indicate an SNMP timeout has occurred when the collector has a
short timeout duration value.
Solution Type
Software configuration; Software upgrade
Solution
ARRIS recommends that SNMP client collectors have a minimum timeout value of
10 seconds when polling the BSR 64000 to avoid polling timeouts on the client
collector.
In addition, upgrade to the following release revisions may alleviate the issue:
6.4.1.1 or later
7.1.0.3 or later
7.1.1.1 or later

SRM Ethernet 7/0 Port Restrictions

This outlines the restrictions and intended function of the Ethernet 7/0 port on the
SRM10G I/O and SRM4 I/O modules.
Release
All
Description
Some configurations have used the Ethernet 7/0 port in unsupported ways, resulting in
errors.
Solution Type
Documentation
Solution
SRM10G Ethernet 7/0 Port

The Ethernet 7/0 port on the SRM10G I/O module (labeled MGMT on some older
units) is intended to provide access to the BSR 64000 chassis for the purpose of initial
configuration, software transfer, Telnet, and SSH access for troubleshooting. Using
the Ethernet 7/0 port for functionality including but not limited to DHCP, SNMP,
SYSLOG, or IPDR may result in unexpected system behavior.
ARRIS recommends transitioning any existing functionality that does not meet the
intended use of the Ethernet 7/0 interface to a Gigabit or 10 Gigabit interface on the
SRM10G module.
SRM4 Ethernet 7/0 Port

The Ethernet 7/0 port on the SRM4 I/O module (labeled Management 10/100
Ethernet Port 0) is intended to provide access to the BSR 64000 chassis for the
purpose of initial configuration, software transfer, Telnet, and SSH access for
troubleshooting. Using the Ethernet 7/0 port for functionality including but not
limited to DHCP, SNMP, SYSLOG, or IPDR may result in unexpected system
behavior.
ARRIS recommends transitioning any existing functionality that does not meet the
intended use of the Ethernet 7/0 interface to a Gigabit or Fast Ethernet interface on the
EtherFlex module.

SRM10G Occasional Packet Loss

This describes a problem with SRM10G hardware that, in rare cases, can result in
occasional packet loss.
Release
7.1.x.x and later
Description
The packet loss issue is rarely seen. When it happens, the packet loss duration is in the
range of a few seconds.
Solution Type
Firmware upgrade
Solution
This problem is resolved in SRM10G CPLD firmware version 0038.
ARRIS recommends (but does not require) a SRM10G CPLD firmware upgrade to
Version 0038 for SRM10G hardware running application software Version 7.1.0.2.
The CPLD firmware upgrade requires a boot ROM upgrade to 7.0.0.40 (or later).
Contact ARRIS Support for the firmware upgrade.

SSH Causes SRM4 Reset

This describes an issue where SSH connections can cause SRM4 modules to reset.
Release
5.2.1.x
6.2.x
6.3.x
6.4.1.x
Description
ARRIS identified an issue on the BSR 64000 where the SRM4 module can reset when
sending commands through an SSH session. When using SSH, a memory buffer
allocated for the SSH component can be written beyond its intended size. Exceeding
the memory space results in an SRM4 reset.
Solution Type
Workaround; Software upgrade
Solution
As a workaround, ARRIS recommends that you use Telnet sessions in place of SSH.
In addition, upgrade to the following release revisions resolves the issue:
6.4.2
7.1.0.4B or later
7.1.1.2 or later

Subnet Migration
This describes an issue seen with MTAs not coming online during IPv4 subnet migration on an RX48
module.
Release
7.0.0.5
7.1.0.x
Description
After a BSR loopback was expanded to add additional networks and re-enabled, a large number of
MTAs did not come online. The issue was caused by a missing logical interface (LIF) entry for the
subnet on the RX48 module for the MAC domain.
When a logical interface deletion aborts, the entry is restored on the CMTS, but deleted on the SRM
module. As a result, the SRM may assign the same global index to a new logical interface. When the
SRM tries to add this logical interface to the CMTS, the CMTS already has an entry for this global
index, and discards the entry. This causes a missing entry on the CMTS.
Solution Type
Software procedure; Software upgrade
Solution
ARRIS recommends the following procedure for migrating subnets:
1. Add the new IP subnet to the cable bundle.
2. Migrate the devices to the new subnet by changing the configuration in the DHCP server and
resetting the devices that need to be migrated.
3. Delete the old subnet when finished.
In addition, upgrading to Release 7.1.1 resolves the issue.
TX32 Module Replacement Procedure

This describes the recommended procedure when replacing or resetting a TX32
module on a live system running software release 5.2.1P37 or later.
Release
All SRM4 releases including 5.2.1P37 and later
Description
An issue has been identified in the field where, after replacing or resetting a TX32
module in a non-redundant TX32 configuration, an issue with loss of remote channels
on the 2:8 CMTS modules bound to that TX32 module may be seen. The issue is
triggered by a large number of cable modem deregistrations which occur when the
TX32 module is removed or reset. These deregistrations can impact the BSR 64000
while the remote channel information is being reconfigured in response to the TX32
module status change. This is usually accompanied by ICP timeout error messages in
the logs.
When this issue occurs, the only way to recover the system is to disable CMTS
redundancy and reset both the primary and redundant 2:8 CMTS modules which were
bound to that TX32 module.
Solution Type
Hardware procedure
Solution
Perform the steps in the procedure below prior to replacing or resetting a TX32
module.
1. Shut the entire interface on both domains on all of the 2:8 modules bound to the
TX32 module that will be replaced or reset.
A typical command sequence to do this is shown in the example below.
BSR:7A#config
BSR:7A(config-if)#shutdown
BSR:7A(config-if)#exit
BSR:7A(config-if)#shutdown
BSR:7A(config)#exit
BSR:7A#

2. Following the shutdown, wait approximately two minutes to allow all of the cable
modems to deregister.
3. Remove the TX32 module from the chassis.
4. Install the replacement TX32 module.
5. Wait for the TX32 module to boot into the "RUN" state.
6. Perform a "no shut" on both domains on all the 2:8 modules bound to the TX32
module.
A typical command sequence to do this is shown in the example below.
BSR:7A#config
BSR:7A(config)#exit
BSR:7A#
TX32 Upgrade Issue from 6.0.1 or Earlier

This describes an issue with systems that have TX32 modules installed that are being
upgraded from 6.0.1.x or earlier software revisions to a later release.
Release
6.0.1.x or earlier
Description
This timing issue may cause the update chassis command to fail during the
programming of some TX32 modules during an application code upgrade. There is no
issue when using the update chassis command for boot ROM upgrades.
An increase in the size of the TX32 binary image in the application code may cause
the amount of time required by the SRM to program the TX32 module(s) to exceed
the programming timeout limit threshold. This can cause the download and
programming of the TX32 module(s) to fail. The following messages will be
displayed on the BSR 64000 Telnet or console session during a failure:
- 07:console]-E-upgrading FLASH:6321.srm4 Failed for slots 11

- 11:RMIOM]-I- RMIOM.20 Application Image (tx.bin.zl) Written State: 0

- 11:RMIOM]-I- RMIOM.11 Programming image (tx.bin) completed
- 07:RMs]-E-Resource Module download FAILURE, Slot 11, reportDownLoadStatus(),
line 972, flags 0x2, invalid state error
Upgrade Report [COMPLETE]
Last upgrade successful for slots: 0 1 2 7 8 14 15

FAILED for slots: 11
Board Upgrade Time Result
0 DRX RX48 fpga2 fpga1 application CMTSarchive 0:08:17 Success
1 DRX RX48 fpga2 fpga1 application CMTSarchive 0:08:52 Success
2 CMTS 2x8E(2.0) fpga1 CMTSarchive 0:06:18 Success
7 SRM4 0:01:35 Nothing to do
8 SRM4 0:01:28 Nothing to do
11 DTX TX32E fpga1 CMTSarchive 0:45:21 FAILED
14 HSIM GE2/ETH8 fpga2 fpga1 application 0:05:37 Success
15 HSIM GE2/ETH8 fpga2 fpga1 application 0:05:34 Success
This may not affect all TX32 modules in a chassis. This issue will not affect the
programming of non-TX32 modules in the chassis. The TX32 modules that failed to
take the new software download will continue to operate with the current version of
software until the system is reloaded.
Solution Type
Software procedure
Solution
ARRIS does not recommend that you retry the update chassis command following
any TX32 failure. Instead, ARRIS recommends that you set the boot parameters to
point to the new archive image using the boot system command, verify using the
show boot command, and configure a forced-download command, as shown below:
BSR:7A# boot system flash:6321.srm4
BSR:7A# show boot
Boot location currently set to FLASH:6321.srm4
BSR:7A# config
BSR:7A(config)# forced-download
BSR:7A(config)# exit
BSR:7A# copy running-config startup-config

If the boot parameters are correct, then issue a reload command to reload the entire
chassis. Once the TX32 module(s) begin their boot process, the new archive image
will be transferred to the TX32. This timing issue will not be seen during the boot
time transfer of a new archive image. The only impact will be that the boot time of the
TX32 module(s) will be extended as a result of having to transfer the archive image.
After a successful upgrade, remove the forced-download command from the startup
configuration.

A
Cable Modem
Registration Process
Introduction
This appendix describes the cable modem registration process. A cable modem goes
through a standard registration process as defined by the Data Over Cable Service
Interface Specification (DOCSIS) to successfully connect to the BSR 64000 DOCSIS
modules on the network.
Scanning
When attached to the network and powered on, the cable modem scans the
downstream channel frequency for a valid 8 MHz channel frequency (European
DOCSIS - Annex A) or 6 MHz channel frequency (North American DOCSIS - Annex
B), or it uses its last known downstream frequency that is stored in its NVRAM.
The cable modem establishes a 64 or 256 Quadrature Amplitude Modulation (QAM)
downstream connection. The cable modem listens on the downstream frequency for
the following upstream interface management information:
Document ID: 365-095-27197 Version 1 A-1

Upstream Channel Descriptor (UCD) - The UCD describes the characteristics

of an upstream channel for the cable modem. The UCD contains information on
the mini-time slot size, upstream channel ID, and downstream channel ID. It also
contains information on how to transmit the symbol rate, frequency, and preamble
length. The UCD also has a burst descriptor that identifies the maximum burst
size, guard time size, and amount of Forward Error Control (FEC) for all six
Interval Usage Codes (IUCs).
Upstream Bandwidth Allocation Maps (MAPs) - MAPs tell the cable modem
where and when there is an opportunity to transmit bursts of data in time slots that
are in contention by using six types of IUCs:
Request uses discover time-slot contention areas on the upstream frequency
in which a cable modem may request a future time when the cable modem
could transmit.
Request Data discovers descriptions of time-slot contention areas in which it
can transmit either small data packets or requests for future grants.
Initial Maintenance ranging uses time intervals to find a time slot
opportunity on the upstream frequency and initializes and transmits a
temporary Service Indentifier (SID) for a new cable modem to connect to the
CM network.
Station Maintenance ranging uses periodic time intervals to send a unicast
message containing a registered SID between the cable modem and the
CMTS.
Short Data Grants and Long Data Grants are grants of time that a cable
modem with a particular SID has to transmit upstream.
The cable modem establishes downstream synchronization with the CMTS.
Initial Ranging
The cable modem sends an Initial Ranging request to establish its time reference and
transmit power settings from the UCD. The CMTS responds to the Initial Ranging
request with a temporary SID equal to zero, and the downstream channel ID.
The cable modem receives the upstream interface information and transmits a
Ranging Request to the CMTS that is consistent with the UCD and MAP information.
The CMTS replies to the cable modem Ranging Request with a Ranging Response
that contains the appropriate SID or SIDs, upstream channel ID on which the CMTS
heard the Ranging Request, and specific adjustments to its MAP for the cable modem
transmitter so that the cable modem can effectively transmit to the CMTS.
A-2 Document ID: 365-095-27197 Version 1

Release 8.0.0 Cable Modem Registration Process
Establishing IP Connectivity
The cable modem obtains an IP address from the Dynamic Host Configuration
Protocol (DHCP) server on the network to establish IP connectivity, and it exchanges
configuration parameters automatically without manual intervention over the CM
network.
1. The cable modem broadcasts a DHCP discovery packet containing its MAC
address.
2. The DHCP server checks the validity of the cable modem MAC address and
sends a response offer if the MAC address is valid.
3. The cable modem selects the response offer and sends a DHCP request for its IP
parameters to the DHCP server. The DHCP server sends a response to the cable
modem containing the following parameters:
Cable modem IP address.
Gateway Router IP address if the DHCP server is on a different network.
Cable modem Subnet Mask.
TFTP server IP address used to connect to the TFTP server.
Download Configuration file name is the name of the cable modem
configuration file to be read from the TFTP server by the cable modem.
Cable Modem Lease Time used for keeping the correct time on error logs.
Establishing Time of Day

For security purposes, the cable modem obtains its IP parameters from the DHCP
server and it establishes the Time of Day (TOD).
TFTP Connectivity
The cable modem communicates with the TFTP server on the network to obtain its
configuration file. The configuration file contains bandwidth specifications, class of
service parameters, network access authorization, and upstream and downstream
operating frequencies. The cable modem requests the TFTP server configuration file.
The TFTP server sends the configuration file.

Registration
The registration process authorizes the cable modem to forward traffic on the
network. The cable modem must send a TFTP response containing its configured
class of service, SID, Service Flow Identifier (SFID), and any other operational
parameters in its configuration file to the CMTS.
The CMTS uses a Message Integrity Check (MIC) to verify the contents of the
configuration file and checks that the configuration file was created by a valid TFTP
provisioning server. The CMTS ascertains that if the configuration file was created by
a valid TFTP provisioning server using a secret key shared with the TFTP server. The
network administrator enters the secret key at both the TFTP provisioning server and
the CMTS. Once the CMTS receives verification from the cable modem after
computing the secret key, the CMTS sends a registration response telling the cable
modem that it is authorized to forward data on the CM network.
Baseline Privacy
Baseline Privacy encrypts upstream and downstream data passed between the cable
modem and CMTS using the shared Authentication Key (AK) and Traffic Encryption
Key(s) (TEKs). The CMTS assigns an AK to a cable modem based on the cable
modem SID. The CMTS AK can be set to expire based on a grace-time or a lifetime
value. The TEK is assigned to a cable modem once the cable modem has a valid AK.
The TEK encrypts data traffic between the cable modem and the CMTS. Each
authorized SID is encrypted with a TEK. The AK and TEK encryption use 40-bit or
56-bit Data Encryption Standard (DES) encryption algorithms. Once the AK and TEK
are accepted by the CMTS, the cable modem authenticated identity is associated with
a paying subscriber and services, the cable modem is authorized to access.
Periodic Ranging
A cable modem performs periodic ranging based on a configured time interval. Cable
modems use periodic ranging to make adjustments according to the MAPs sent to
them by the CMTS. This ensures that the cable modem transmits upstream
information within acceptable limits.
A modem monitors the allocation map for Station Maintenance intervals. When the
CMTS sends a ranging request to the cable modem, the cable modem goes through
the ranging process and makes the appropriate adjustments in its ranging response.
During this process, the cable modem continues to forward data over the network.
A-4 Document ID: 365-095-27197 Version 1

Release 8.0.0 Cable Modem Registration Process
The CMTS may send an Upstream Channel Change (UCC) to the cable modem after
the cable modem has successfully completed the Initial Ranging process on the
current upstream channel. When the cable modem responds to this request, it
monitors the downstream channel for the new UCD. Once the cable modem receives
the new UCD, it goes through the Initial Ranging process on the new upstream
channel. During the process, no data is forwarded over the network. If Initial Ranging
cannot be accomplished within the configured timeouts and retries, then the modem
goes through the Scanning process.
Data Exchange
Cable modems use the dedicated data intervals in the current upstream MAPs to
transmit data to the CMTS. When no dedicated data interval in the current upstream
bandwidth allocation map exists and the Protocol Data Unit (PDU) data frame is
within the appropriate size range, cable modems compete for request and data
contention intervals to transmit data to the CMTS. If a dedicated data interval
becomes available while the cable modem is competing for a contention interval, the
cable modem drops its bid for the contention slot and uses the dedicated data interval
instead of the contention interval.
The cable modem sends data with bandwidth allocation requests whenever possible.
The cable modem continuously monitors allocation MAP messages for short and long
grants and for pending indications given by the CMTS. The cable modem also
monitors its transmission rate to keep it within the maximum upstream data rate for its
class of service.
The CMTS supports the concatenation of MAC level frames. Cable modems that
support concatenation combine multiple MAC level frames into one larger frame for
an efficient and smooth traffic flow over the upstream channel path. The CMTS
processes these concatenated frames and sends the data to its destination.

Index
A
D
access lists, 4-6 to 4-7
BGP, 7-2 default gateway, 4-2
RIP, 5-2
default power-level
ACL range, 10-5 range, 3-12
air filter, 10-6 default routes, 4-2
amplifier noise, 3-15 DHCP, 3-20
application errors, 4-7 DNS, 4-3
area border router (ABR) DOCSIS, 3-1
see OSPF
domain name server
Autonomous System (AS), 4-4 see DNS
downstream passive equipment, 3-15
B
BGP, 7-1 to 7-4 E
AS path access lists, 7-4
Ethernet 7/0, 10-20
autonomous system numbers, 7-1
community access lists, 7-4
distribute lists, 7-4 F
missing network command, 7-2 fan connector, 10-9
neighbors, 7-1
peer configuration problems, 7-3 fan status, 2-2, 2-5
blank module, 10-7 fiber-optic

transmitters, 3-15
border gateway protocol
see BGP flap lists, 3-1
administrating, 3-7
BPI security, 10-8 interpreting, 3-4
frequency response, 3-15
C
cable headend path loss, 3-12 G
cable privacy mandatory, 10-11 Gigabit Ethernet installation, 10-12
cables, 2-1
class D IP address, 8-1 H
CM output power level, 3-12 HFC network, 3-7
CM registration problems, 3-16 to 3-21
commands I
cable downstream interleave-depth, 3-9, 3-10
IGMP, 8-1
common path distortion, 3-7
configuration, 8-1
Constant Bit Rate (CBR) data traffic, 8-1 host-query messages, 8-2
controlling version, 8-2
upstream input power level, 3-12 ingress noise, 3-9, 3-15
cooling, 10-7 electrical, 3-10
correctables, 3-9 impulse, 3-10
input power-level range, 3-12

interleave depth
setting, 3-9
IP helper address, 4-8
IP multicast group access, 8-2
IP multicast static routes, 8-3
L
laser clipping, 3-15
LED displays, 2-2
ports, 2-5, 2-7, 2-8, 2-9, 2-11
Primary RX48 Resource Modules, 2-8
resource modules, 2-4
RX48 Module, 2-8
RX48 Standby Module, 2-10
Supervior Resource Module, 2-4
TX32 Module, 2-5
TX32 Standby Module, 2-7
M
maximum transmission unit
see MTU
micro reflections, 3-9, 3-11
MTU, 6-3
multicast, 8-1
N
network problems, 3-1
noise funneling, 3-10
O
Open Shortest Path First
see OSPF
optical amplifiers, 3-14
OSPF, 6-1 to 6-5
ABR, 6-4
adjacent OSPF router, 6-3
area IDs, 6-2
E-bits, 6-2
hello or dead timers, 6-2

Release 8.0.0 Index
N-bits, 6-2
Not-So-Stubby Areas (NSSAs), 6-2
wildcard masks, 6-2
Outpost24, 10-14
P
pinging a CM, 3-17
PLL loss, 10-15
port LEDs, 2-5, 2-7, 2-8, 2-9, 2-11
PROTECTED +, 10-4
provisioning problems, 3-20
Q
QAM, 3-11
16 QAM, 3-9
256 QAM, 3-14
64 QAM, 3-14
QPSK, 3-9, 3-11
quadrature phase shift keying
see QPSK
R
redundancy
RX48, 10-2
reset command, 2-11
Resource Module reboot, 2-11
Reverse Path Forwarding (RPF), 8-3
RIP, 5-1 to 5-2
into OSPF, 6-4
misconfigured version, 5-3
wrong version, 5-3
routing information protocol
see RIP
routing table, 6-4
RX48
failover, 10-16
MAC domain modem recovery, 10-18
power surge recovery, 10-17
upgrade, 10-2
RX48 module, 2-8

RX48 Standby module, 2-10
S
setting
interleave depth, 3-9
SID, 3-17
signal quality, 3-8, 3-11
signal-to-noise ratio, 3-9, 3-10, 3-12, 3-14
downstream path, 3-14
upstream path, 3-10
slot 15, 10-4
SNMP
cable modem response to, 3-22
SNMP timeouts, 10-19
solutions, 10-1
split horizon, 5-2
SRM module, 2-4
SRM10G, 10-13
Ethernet 7/0, 10-20
packet loss, 10-21
SSH, 10-22
station maintenance requests, 3-17
subnet migration, 10-23
T
TCP ports, 7-2
thermal sensitivity, 3-15
traceroute command, 4-3
TX32
3-slot, 10-4
replacement, 10-24
slot 15, 10-4
upgrade, 10-25
TX32 module, 2-5
TX32 Standby module, 2-7
U
UDP
broadcasts, 4-8
unerroreds, 3-8, 3-11
UNIX
resolving host problems through, 4-2
upstream channel bandwidth, 3-12
upstream input power level
controlling, 3-12
User Datagram Protocol
see UDP, 4-8
W
Wildcard bits, 8-2
Visit our website at:
http://www.arrisi.com/cc360
Document ID: 365-095-27197

Version 1
10/14

BSR 64000 - Release 8.0.0 - Troubleshooting Guide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

BSR 64000 - Release 8.0.0 - Troubleshooting Guide

Enviado por

Direitos autorais:

Formatos disponíveis

Document ID: 365-095-27197 Version 1

Caring for the Environment by Recycling

Document ID: 365-095-27197 Version 1

2 Checking Physical Equipment

Document ID: 365-095-27197 Version 1 iii

Interpreting Resource Module LED Displays ............................................................................2-4

3 Troubleshooting the CMTS

iv Document ID: 365-095-27197 Version 1

Unacceptable Downstream Signal-to-Noise Ratio Detected .........................................3-14

4 Troubleshooting Basic Routing Problems

Document ID: 365-095-27197 Version 1 v

Misconfigured Version of RIP Running on BSR .............................................................5-3

8 Troubleshooting Multicast Routing

9 Recommended BSR Configurations

vi Document ID: 365-095-27197 Version 1

Denial of Service Protection .......................................................................................................9-2

Document ID: 365-095-27197 Version 1 vii

BSR 64000 Quick Start Guide

Document ID: 365-095-27197 Version 1 ix

ixx Document ID: 365-095-27197 Version 1

Convention Example Explanation

Document ID: 365-095-27197 Version 1 xi

Convention Example Explanation

Notes, Cautions, Warnings

ixxii Document ID: 365-095-27197 Version 1

If You Need Help

U.S. 1-888-944-HELP (1-888-944-4357)

The ARRIS TAC is on call 24 hours a day, 7 days a week.

Document ID: 365-095-27197 Version 1 xiii

Understanding Basic Troubleshooting

Document ID: 365-095-27197 Version 1 1-1

Note: One or more symptoms or causes can be related to a single problem.

1-2 Document ID: 365-095-27197 Version 1

Isolating the Problem

Document ID: 365-095-27197 Version 1 1-3

Find the functions that are working correctly.

Solving the Problem

Evaluating the Solution

1-4 Document ID: 365-095-27197 Version 1

Checking Physical Network Connections

Document ID: 365-095-27197 Version 1 2-1

Turning On the BSR 64000

2-2 Document ID: 365-095-27197 Version 1

Power Entry Module A Power Entry Module B

Figure 2-1 Accessing BSR 64000 Power Switches

Determining BSR 64000 Operational Status

Document ID: 365-095-27197 Version 1 2-3

Module LED LED Display State

2-4 Document ID: 365-095-27197 Version 1

Module LED LED Display State

Interpreting Resource Module LED Displays

Document ID: 365-095-27197 Version 1 2-5

RX48 Standby Resource Module LEDs

Supervisor Resource Module LEDs

Table 2-2 Module LED Display States for the SRM

Fail Status Alarm Interpretation

Fan Status LEDs

2-6 Document ID: 365-095-27197 Version 1

Table 2-3 SRM Fan Status LED Display States

SRM10G 10 Gig and 1 Gig Port LEDs

Link ACT Interpretation

TX32 Resource Module LEDs

Document ID: 365-095-27197 Version 1 2-7