Troubleshooting
Guide
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.
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
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
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
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
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:
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
This guide provides the instructions and procedures for configuring and
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
This guide provides the instructions and procedures for configuring and
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:
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.
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.
Telephone Support
If you need assistance while working with the BSR 64000, contact the ARRIS
Technical Assistance Center (TAC):
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
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.
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.
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.
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
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.
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.
bsr64k036a
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
Table 2-1 BSR 64000 LED Display States Following Successful Booting
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.
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.
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.
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.
Table 2-4 SRM10G 10 Gig and 1 Gig Port LED Display States
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)
Table 2-6 Module LED Display States for the TX32 Resource Module
(Redundant Operation)
Table 2-6 Module LED Display States for the TX32 Resource Module
(Redundant Operation)
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 describes the possible display states of these LEDs during operation.
Module LEDs
The Module LEDs are visible on the module front panel and are labeled: Fail, Status,
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
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.
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-9 describes the possible display states of these LEDs during operation.
Table 2-10 Module LED Display States for the RX48 Resource Module
(Non-Redundant Operation)
Table 2-11 Module LED Display States for the RX48 Resource Module
(Redundant Operation)
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.
Port LEDs are grouped vertically. A number to the right each LED group indicates the
channel number associated with the group. The eight upstream channels are numbered
0 through 7.
Table 2-12 describes the possible display states of these LEDs during operation.
Module LEDs
The Module LEDs are visible on the module front panel and are labeled: Fail, Status,
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
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.
Port LEDs are grouped vertically. A number to the right each LED group indicates the
channel number associated with the group. The eight upstream channels are numbered
0 through 7.
Table 2-14 describes the possible display states of these LEDs during operation.
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
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:
MAC ID CableIF Hit Miss Ins CRC Pow Rng Flap Type Time
PS TimeInPS
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:
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
0021.80f2.f9c5 2/0 U1C5L0 42987 0 0 0 19 0 19 PAdj SUN FEB 09
21:32:09 2014 0 0
MAC ID CableIF Hit Miss Ins CRC Pow Rng Flap Type Time
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
Table 3-1 identifies the flap list command output column field 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.
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.
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:
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
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.
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:
X is the slot number.
Y is the port number.
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
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:
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.
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.
8. 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 near network cabling.
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>}
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.
A.B.C.D is the CMs IP address.
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.
A.B.C.D is the CMs IP 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.
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:
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:
BSR:7A#clear cable modem <mac> reset
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.
1. Issue the clear cable modem reset command, in Privileged Exec mode, to reset
the CM so that it can respond to SNMP messages:
BSR:7A#clear cable modem <mac> reset
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.
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
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.
Note: You may need to reboot the host for this change to take effect.
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.
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.
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:
BSR:7A(config)#router rip
BSR:7A(config-rip)#network 10.10.10.0 255.255.255.0
BSR:7A(config-rip)#network 10.10.20.0 255.255.255.0
Misconfigured Router
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:
BSR:7A(config)#router rip
BSR:7A(config-rip)#network 10.10.10.0 255.255.255.0
Ensure that process IDs, addresses, and other variables are properly specified for
the routing protocol you are using.
Caution: Debug commands can use considerable CPU resources on the router. Do not
execute them if the network is already heavily congested.
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
Overview
This chapter provides troubleshooting solutions to some common Routing
Information Protocol (RIP) problems:
Handling Routing Table Problems
Handling RIP Version Inconsistencies
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:
BSR:7A(config)#router rip
BSR:7A(config-rip)#network 10.10.10.3 255.255.255.0
BSR:7A(config-rip)#network 10.10.20.3 255.255.255.0
3. Ensure the correct process IDs, addresses, and other variables are properly
specified for the RIP routing protocol.
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
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
Misconfigured Router
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
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.
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
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)#router ospf
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)#router ospf
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
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.
Example:
Overview
This chapter describes how to troubleshoot IP Multicast Routing problems on the
BSR.
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.
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.
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
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.
Recommended Configuration
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.
Recommended Configuration
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 |
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.
Recommended Configuration
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).
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.
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 tcp any any eq 135
access-list 198 deny tcp any any eq 136
access-list 198 deny tcp any any eq 137
access-list 198 deny tcp any any eq 138
access-list 198 deny tcp any any eq 139
access-list 198 deny udp any any eq 135
access-list 198 deny udp any any eq 136
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 udp any eq 41170 any
access-list 198 permit udp any any eq 41170
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 deny udp any any eq 1026
access-list 198 deny udp any any eq 1027
access-list 198 deny udp any any eq 1028
access-list 198 deny udp any any eq 1029
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".
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.
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.
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.
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.
Recommended Configuration
BSR:7A(config)# cable modem remote-query 3600 public
where:
1-255 configures the remote set source interface for the specified loopback
interface number.
Recommended Configuration
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.
Recommended Configuration
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
Refer to Severity Levels and Descriptions on page 6 for detailed severity level
information.
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
Recommended Configuration
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
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.
Recommended Configuration
BSR:7A(config-if)#cable dynamic-service active-timeout 60
Recommended Configuration
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.
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
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
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.
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.
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.
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.
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:
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.
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.
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.
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
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.
"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.
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.
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)#interface cable 0/0
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
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
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
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.
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.
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.
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.
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
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.
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
Release
All
Description
Some configurations have used the Ethernet 7/0 port in unsupported ways, resulting in
errors.
Solution Type
Documentation
Solution
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.
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
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.
Release 8.0.0 Technical Solutions
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)#interface cable 1/0
BSR:7A(config-if)#shutdown
BSR:7A(config-if)#exit
BSR:7A(config)#interface cable 1/1
BSR:7A(config-if)#shutdown
BSR:7A(config-if)#exit
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)#interface cable 1/0
BSR:7A(config-if)#no shutdown
BSR:7A(config-if)#exit
BSR:7A(config)#interface cable 1/1
BSR:7A(config-if)#no shutdown
BSR:7A(config-if)#exit
BSR:7A(config)#exit
BSR:7A#
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
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.
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:
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.
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.
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.
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.
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
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
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
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