Chapter 4, DOCSIS Configuration
Available Languages
Table Of Contents
Using MIBs with Dynamic DOCSIS Templates
BACC Features for DOCSIS Configurations
DOCSIS Configuration File Based on DOCSIS Version
Troubleshooting DOCSIS Networks
Network Layer Configuration and Above
Troubleshooting Cable Modem States
Ranging Process - init(r1),init(r2), and init(rc) state
Option File Transfer Started-init(o) State
Online, Online(d), Online(pk), Online(pt) state
Reject(pk) and Reject(pt) state
Registration - reject (m) state
Registration - reject (c) state
DOCSIS Configuration
This chapter identifies those functions you must check or configure to bring a BACC DOCSIS deployment into operation. It also provides information required prior to configuration, and describes the available tools.
•
Using MIBs with Dynamic DOCSIS Templates
•
•
•
•
Note
DOCSIS Workflow
The provisioning (workflow) steps contained in the DOCSIS Provisioning Specification are shown in Figure 4-1.
Figure 4-1 DOCSIS Provisioning Flow
Table 4-1 describes the potential problems that can exist at various DOCSIS provisioning steps illustrated in Figure 4-1.
Using MIBs with Dynamic DOCSIS Templates
For a full list of MIBs shipped with BACC, see SNMP Varbind, page 12-5.
Two versions of the DOCSIS MIB are loaded into the RDU:
•
•
For information on how to use them, see DOCSIS MIBs, page 12-5.
You can add MIBs using an API call or by modifying rdu.properties. For more details, see Configuring Euro-PacketCable MIBs, page 5-6.
You can add a SNMP TLV to a template when no MIB is available. See Adding SNMP TLVs Without a MIB, page 12-10 for more information.
BACC Features for DOCSIS Configurations
This section describes BACC value-added features as they relate to the DOCSIS technology.
Dynamic Configuration TLVs
These TLVs are added by the DPE whenever a TFTP request for dynamic DOCSIS configuration is received:
•
•
•
•
Note
•
•
–
–
–
–
DPE TFTP IP Validation
For dynamic configuration files, the DPE TFTP server verifies that the IP address of the TFTP client matches the expected DOCSIS cable modem IP address. If it does not match, the request is dropped. This feature is incompatible with the Cisco CMTS DMIC feature.
Use the no tftp verify-ip command to disable the verification of requestor IP addresses on dynamic configuration TFTP requests:
dpe# no tftp verify-ip%OK.DOCSIS 1.0, 1.1, 2.0 Support
BACC 2.7 supports DOCSIS 1.0, 1.1, and 2.0. See Chapter 12, "Broadband Access Center for Cable Support Tools and Advanced Concepts" for additional information describing the TLVs and options supported in each DOCSIS version by BACC.
Dynamic DOCSIS Version Selection
BACC can detect a cable modem's DOCSIS version from an incoming DHCP request. It can also detect the CMTS DOCSIS version from any customer-supplied source that provides a mapping of GIADDR to DOCSIS version numbers.
You can specify the DOCSIS version in the Configuration File utility. See Using the Configuration File Utility, page 12-25 for more information.
DOCSIS Configuration File Based on DOCSIS Version
The default DOCSIS code generation extension uses the version of DOCSIS for provisioning the modem, to determine the filename of the DOCSIS configuration file to send to the modem.
DOCSIS Version Dependent Class of Service Properties
The following new class of service properties are supported by the Administrator's user interface and by the BACC API:
/cos/docsis/file/1.0/cos/docsis/file/1.1/cos/docsis/file/2.0These properties can optionally be added to a DOCSIS class of service to associate a DOCSIS configuration filename with a particular DOCSIS version. Each of these properties (if set) causes the RDU to establish a database relationship between the class of service and the file named by the property value, as is done for the existing DOCSIS configuration filename property.
Troubleshooting DOCSIS Networks
DOCSIS provides the bandwidth and latency guarantees needed to provide toll-quality voice, data services, and multimedia applications across a shared HFC network. It is designed to be backward compatible, enabling DOCSIS 1.0, 1.1, and 2.0 modems to operate in the same spectrum on the same network.
Note
Network Layer Configuration and Above
After ranging is successful, the cable modem needs additional configuration from the operational support servers. The collection of services they provide and configure are called operational support services (OSS).
Note
Establish DHCP State
MAC State --->>> 'establish_dhcp_state'cmWriteFlashFile("CM_MACCONFIG", 0x8313db6, 0x12e) by TID 0x82eb0f8 (tConfigNV)usrEraseSysFlash(1, 0x1e0400, 0x12e) by TID 0x82eb0f8 (tConfigNV).........cmWriteFlashFile("CM_DHCPLEASE", 0x810ebe4, 0x24) by TID 0x82d825c (tLease-0)usrEraseSysFlash(1, 0x1e0200, 0x24) by TID 0x82d825c (tLease-0)The first task in configuring the OSS is acquiring network configuration via DHCP. A broadcast DHCP DISCOVER message is issued by the modem. Normally, routers will not forward broadcast messages, but they can be configured to do so for a collection of UDP protocols, one of which is DHCP. If a DHCP server responds to the DISCOVER with an OFFER, the modem may choose to send a REQUEST for the offered configuration.
The DHCP server can respond with an ACK (acknowledged) or NAK (not acknowledged). A NAK may be the result of an incompatible IP address and gateway address, which might occur if a modem hopped from one downstream channel to another that resides on a different subnet. When the modem seeks renewal of the lease, the IP address and the gateway address of the DHCP REQUEST message will be different network numbers and the DHCP server will refuse the REQUEST with a NAK. These situations are rare and the modem will simply release the lease and start over with a DHCP DISCOVER message.
Frequently, errors at establish_dhcp_state manifest as timeouts rather than NAKs. To troubleshoot effectively:
•
•
•
The log mask 0xffff00bf used above in ranging can also help you to troubleshoot almost all the problems a modem might encounter in bring-up stage and is a good place to start when troubleshooting a bring-up error. The order of DHCP messages should be DISCOVER, OFFER, REQUEST, ACK. If the modem is transmitting a DISCOVER with no OFFER response from the DHCP server, turn on UDP debugging on the uBR, using the following command:
uBR# debug ip udp
Note
Caution
If there are no packets in the debug messages, check the configuration of the "ip helper-address" statement on the cable interface to which this modem is attached. If this is configured correctly and a packet trace of the DHCP server subnet also reveals no DHCP packets from the modem, then look at the output errors of the modem's cable interface, or the input errors of the cable interface of the uBR. It might be a good idea to boost the transmitter power a bit more with more attenuation.
If packets are being transmitted onto the DHCP server subnet, double-check the modem debug messages to see if there are parameter request or assignment errors. At this stage of troubleshooting you should investigate the routing between the modem and the DHCP server. It is also advisable to double-check the DHCP server configuration.
Establishing the ToD State
MAC State --->>> 'establish_tod_state'After a modem has acquired its network parameters, it must request the time of day from a Time Of Day (TOD) server. TOD uses a UTC timestamp (seconds from January 1, 1970) combined with the time offset option value from DHCP to calculate the current time. The time is used for syslog and event log timestamps.
Time of day errors almost always point to a DHCP misconfiguration. Possible misconfigurations that can result in TOD errors are IP address, gateway address misconfigurations, or the wrong TOD server address. Again, start troubleshooting locally by examining the DHCP parameters the modem has stored, using the following command:
-> cmShowDhcpParametersor:
-> cmAddLogValues ("SEV_ALL FAC_DHCP")The latter will give debug output of DHCP actions and tasks.
Also check the modem routing table with the vxWorks routeShow command.
Security Association State
MAC State --->>> 'security_association_state'This is a placeholder for a state yet to be defined. It is envisioned that a security association with a security server will provide IPsec-like security for the modems.Its design and implementation are still being discussed. In the meantime, DOCSIS 1.0 requires modems to support a future definition of this state including the DHCP option for a security server. It is unlikely to find a modem having a problem with this state until it is defined in DOCSIS and implemented on the modem.
Configuration File State
The main configuration and administration interface to the CM is the configuration file downloaded from the provisioning server. This configuration file contains downstream channel and upstream channel identification and characteristics, as well as class of service settings, baseline privacy settings, general operational settings, network management information, software upgrade fields, filters, and vendor specific settings.
Common reasons for failure at this state are missing file, wrong file permissions, TFTP server is unreachable, file is wrong format, file has missing required options, misconfigured required options, or incorrect options, for example, unknown or invalid TLVs.
A debug command for configuration file transactions and parsing is:
-> cmAddLogValues ("SEV_ALL FAC_CONFIGFILE")Registration State
MAC State --->>> 'registration_state'After configuration, the modem sends a registration request (REG-REQ) with a required subset of the configuration settings, as well as the CM and CMTS message integrity checks (MIC). The CM MIC is a hashed calculation over the configuration file settings which provides a method for the modem to be sure the configuration file was not tampered with in transit. The CMTS MIC is similar but also includes a setting for a shared-secret authentication string. This shared secret is known by the CMTS and the provisioning server, and ensures that only modems configured by authenticated provisioning servers will be allowed to register with the CMTS.
Problems with registration state almost always point to a configuration file error. Make sure the modem and the CMTS both support the settings in the configuration file. Make sure the CMTS allows the creation of class of service profiles or use a profile created by the CMTS. Check the authentication strings in the CMTS cable interface configuration and the configuration file.
Establish Privacy State
MAC State --->>> 'establish_privacy_state'The modem must negotiate baseline privacy with the CMTS through the Baseline Privacy Key Management protocol, if all of the following are true:
•
•
•
If errors occur in this state, the likely causes are configuration file misconfigurations. Be certain that both the CM and the CMTS support baseline privacy and are enabled in the interface configuration for the CMTS and the configuration file for the CM.
You might also encounter errors due to encryption export restrictions, some vendor modems may require the following command on the uBR7246 in the interface configuration:
uBR(config-if)# cable privacy 40-bit-desOperational State
MAC State --->>> 'operational_state' cmWriteFlashFile("CM_BOOT", 0x8109180, 0x13e) by TID 0x83049b8 (tMACCtrl)usrEraseSysFlash(1, 0x1e0900, 0x13e) by TID 0x83049b8 (tMACCtrl)If registration and baseline privacy negotiation (if required) succeed, the modem is operational and is ready to pass traffic.
A modem may become operational but not remain in operational state. This could be caused by sync loss or DHCP lease renewal failure, for example.
Troubleshooting Cable Modem States
This section discusses these cable modem states:
•
•
•
•
•
•
Online State
This section provides information on understanding the online state of the cable modem, and troubleshooting problems indicated by this state, including RF problems.
Note
The first and most useful command to use at the Cisco uBR7246VXR is show cable modem:
#show cable modem
The Online State field identifies the status. Table 4-2 displays the possible values for the state.
The following sections discuss each State value, the possible causes, and the steps that can be taken to arrive at the correct state (online).
Offline State
In some cases the cable modem may cycle through other states then back to offline. The following list gives the most common reasons for a cable modem not to achieve QAM lock:
•
•
•
•
•
The following is a portion of the output from show controllers cable-modem 0 entered at the modem:
#sh cont c 0BCM Cable interface 0:CM unit 0, idb 0x8086C88C, ds 0x8086E460, regaddr = 0x2700000, reset_mask 0x80station address 0030.96f9.65d9 default station address 0030.96f9.65d9PLD VERSION: 1Concatenation: ON Max bytes Q0: 2000 Q1: 2000 Q2: 2000 Q3: 2000MAC State is ds_channel_scanning_state, Prev States = 3MAC mcfilter 01E02F00 data mcfilter 00000000MAC extended header ONDS: BCM 3300 Receiver: Chip id = BCM3300US: BCM 3300 Transmitter: Chip id = 3300Tuner: status=0x00Rx: tuner_freq 529776400, symbol_rate 5361000, local_freq 11520000snr_estimate 166(TenthdB), ber_estimate 0, lock_threshold 26000QAM not in lock, FEC not in lock, qam_mode QAM_64 (AnnexB)Tx: tx_freq 27984000, symbol rate 8 (1280000 sym/sec)power_level: 6.0 dBmV (commanded)7 (gain in US AMP units)63 (BCM3300 attenuation in .4 dB units)...[Rest of the displayed output is omitted]The Signal to Noise ratio (SNR) estimate is 16.6 dB in the previous output example. Ideally this should be at least 30dB for the CM to operate properly for 64 QAM. See the RF specifications for DOCSIS Downstream and Upstream signals. In some cases you may have a good SNR (for example, 34dB) but still have noise present, such as impulse noise. This can be detected only by a spectrum analyzer operating in the zero span mode. One indication of impulse noise is errors that cannot be corrected. These are seen in the output of show interfaces cable 2/0 upstream 0 as shown in the following output:
#show interfaces cable 2/0 upstream 0Cable2/0: Upstream 0 is upReceived 46942 broadcasts, 0 multicasts, 205903 unicasts0 discards, 12874 errors, 0 unknown protocol
Note
252845 packets input,1 uncorrectable12871 noise, 0 microreflections Total Modems On This Upstream Channel : 3 (3 active)Default MAC schedulerQueue[Rng Polls] 0/64, fifo queueing, 0 dropsQueue[Cont Mslots] 0/104, fifo queueing, 0 dropsQueue[CIR Grants] 0/64, fair queueing, 0 dropsQueue[BE Grants] 0/64, fair queueing, 0 dropsQueue[Grant Shpr] 0/64, calendar queueing, 0 dropsReserved slot table currently has 0 CBR entriesReq IEs 77057520, Req/Data IEs 0Init Mtn IEs 1194343, Stn Mtn IEs 117174Long Grant IEs 46953, Short Grant IEs 70448Avg upstream channel utilization : 1%Avg percent contention slots : 96%Avg percent initial ranging slots : 4%Avg percent minislots lost on late MAPs : 0%Total channel bw reserved 0 bpsCIR admission control not enforcedCurrent minislot count : 7192093 Flag: 0Scheduled minislot count : 7192182 Flag: 0The optimal input power level at the CM is 0dBmV; the receiver has a range of -15dBmv to +15dBmV. This can be measured by the spectrum analyzer. If the power is too low you may need to configure the upconverter as described in the Cisco uBR 7246 Hardware Installation Guide. If the signal is too strong, you may need to add more attenuation at the high frequency port connection. If a particular frequency has too much noise present, you may need to select another frequency in the spectrum.
To confirm that the CM has not been able to achieve QAM lock, turn on debug cable-modem mac log verbose. You should see output similar to the following:
Another reason the CM might not achieve QAM lock is if the incorrect downstream center frequency was configured on the upconverter. For example, on the NTSC frequency map for standard 6-MHz channel bands in North America, channel 100-100 uses 648.0-654.0 with a center frequency of 651 MHz. However, if you are using an upconverter that is designed to work with the video carrier frequency (for example, GI C6U which is 1.75MHz below the center frequency), you must set a frequency of 649.25 MHz for Channel 100-100.
Another common mistake is to specify an incorrect frequency value in the Downstream Frequency field under the Radio Frequency Info in the Cisco Broadband Configurator (available for download on cisco.com). Usually there is no need to specify a frequency value under this option. However, if there is a need (for example, when certain modems need to lock on a different frequency), you must select the proper frequency values, as explained previously. The following debug output illustrates this: a CM locks on initially at 453MHz and then at 535.25MHz (which was specified in the DOCSIS configuration file), thus causing the cable modem to reset and cycle through this process indefinitely:
Incorrect frequency specified in cable modem change-frequency on the Cisco uBR7246VXR can also cause the CM to switch frequencies, and if the frequency configured on the router is not chosen carefully, you will see results similar to that above. The cable modem change-frequency command on the Cisco uBR7246VXR is optional and is typically left out by default.
After a downstream channel has been acquired and latency has been calculated, the next task is to locate a suitable upstream channel. The cable modem listens for an upstream channel descriptor (UCD) which contains the physical properties of the upstream channel, such as frequency, modulation, channel width, and other parameters defined in the burst descriptors.
A cable modem that cannot find a usable upstream channel descriptor may be on a downstream channel for which no upstream service is provided. This is likely to be a faulty configuration of the router. You can check this using the show controller cable x command. Another possible reason a cable modem may not find a usable UCD is that its hardware or MAC may not support the parameters in the burst descriptors. This is likely to be either a faulty configuration of the Cisco uBR7246VXR or a CM that is not DOCSIS-compliant.
After a usable UCD is found, the cable modem begins to listen to MAP (Bandwidth Allocation Map) messages which contain the upstream bandwidth allocation map of time. A section of time is mapped out into mini-slots and assigned to individual modems. There are also regions in the MAP for broadcast, contention-based initial maintenance (or broadcast) ranging. It is these regions of the MAP that the cable modem must send its initial ranging requests until the Cisco uBR7246VXR responds with a ranging response (RNG-RSP).
If a CM cannot find an initial maintenance region before a T2 timer expires, check whether the Cisco uBR7246VXR has a faulty configuration. You should also check the insertion-interval for the cable interface on the router.
Ranging Process - init(r1),init(r2), and init(rc) state
At this stage, the CM begins a ranging process to calculate the necessary transmit power level to reach the Cisco uBR7246VXR at its desired input power level. A reasonably good transmit power is roughly 40 - 50 dBmV (based on a uBR7246 input power of 0 dBmV.) Other hardware may vary. Like the downstream channel, the carrier in the upstream channel should be sufficiently strong for the Cisco uBR7246VXR receiver to discern the symbols yet not too high to prevent increased bit error-rates.
The CM sends a ranging request (RNG-REQ) message to the Cisco uBR7246VXR and waits for a ranging response (RNG-RSP) message or a T3 timer expiry. If a T3 timeout occurs, the retry count increments. If the retry count is less than the maximum number of retries, the cable modem transmits another RNG-REQ at a higher power level. This ranging process occurs in the initial maintenance or broadcast regions of the MAP because the Cisco uBR7246VXR has not assigned the cable modem a service identifier (SID) for unicast transmissions in the MAP. Thus, broadcast ranging is contention based and subject to collisions. To compensate for this, the cable modems have a ranging backoff algorithm to calculate a random backoff time between RNG-REQ transmissions. This can be configured using cable upstream range-backoff command. When the transmit power reaches a sufficient level for the Cisco uBR7246VXR, it responds to the RNG-REQ with a RNG-RSP containing a temporary SID. This SID is used to identify unicast transmission regions in the MAP for unicast ranging.
The following output shows a CM in init(r1) state indicating the CM cannot get past the initial ranging stage:
#show cable modem
12.000
The debug below shows how the CM fails to complete the ranging process and resets after a T3 timer expiry. Note the CMAC_LOG_ADJUST_TX_POWER messages coming from the Cisco uBR7246VXR asking the CM to adjust its power:
You can get an indication of the Transmit power on the CM by displaying the following command:
#sh cont cable-modem 0BCM Cable interface 0:CM unit 0, idb 0x2010AC, ds 0x86213E0, regaddr = 0x800000, reset_mask 0x80station address 0050.7366.2223 default station address 0050.7366.2223PLD VERSION: 32MAC State is wait_for_link_up_state, Prev States = 2MAC mcfilter 00000000 data mcfilter 00000000MAC extended header ONDS: BCM 3116 Receiver: Chip id = 2US: BCM 3037 Transmitter: Chip id = 30ACTuner: status=0x00Rx: tuner_freq 0, symbol_rate 5055932, local_freq 11520000snr_estimate 30640, ber_estimate 0, lock_threshold 26000QAM not in lock, FEC not in lock, qam_mode QAM_64Tx: tx_freq 27984000,power_level 0x20 (8.0 dBmV), symbol_rate 8 (1280000 sym/s)If a cable modem cannot proceed out of ranging state, the likely cause is an insufficient transmit power level. Transmit power can be adjusted by adjusting attenuation at the low frequency port. Increased attenuation will result in increased transmit power levels. 20 - 30 dBmV of attenuation is a good place to start.
After initial ranging init(r1) the cable modem proceeds to init(r2). This is where the cable modem must configure the transmit timing offset and power level to ensure that transmissions from the modem are received at the correct time and are at an acceptable input power level at the Cisco uBR7246VXR receiver. This is performed through a conversation of unicast RNG-REQ and RNG-RSP messages. The RNG-RSP messages contain the power and timing offset corrections that the cable modem must make.
The cable modem continues to transmit RNG-REQ and to perform adjustments per RNG-RSP until the RNG-RSP message indicates ranging success or ranging complete by reaching the init(rc) state. If a cable modem cannot proceed out of init (r2) the transmit power needs to be refined. Below is an output display of a CM in init(r2) state. Note the asterisk (*) symbol next to the Rec Power column indicating that the noise power adjustment method is active for this modem. An exclamation mark (!) means the cable modem has reached its maximum transmit power.
#show cable modem
DHCP - init(d) state
The next stage after successful ranging is acquiring network configuration via DHCP.
Below is a an output display of show cable modem showing a cable modem in init(d), which indicates that the DHCP request was received from the CM:
#show cable modem
Note that the CM can cycle through init(r1) to init(d) indefinitely. Following are some possible causes:
•
•
•
•
Note
Frequently, errors at DHCP state manifest themselves as timeouts rather than NAKs. The order of DHCP messages should be DISCOVER, OFFER, REQUEST, ACK. If the cable modem is transmitting a DISCOVER with no OFFER response from the DHCP server, turn on UDP debugging on the Cisco uBR7246VXR using the following command:
# debug ip udp
Caution
If no packets are seen through debug messages, check the configuration of the cable helper-address statement on the cable interface to which this modem is attached. If this is configured correctly and a packet trace of the DHCP server subnet also reveals no DHCP packets from the cable modem, then look at the output errors of the cable modem's cable interface or the input errors of the cable interface of the Cisco uBR7246VXR. It might be a good idea to boost the transmitter power of the CM a bit more with more attenuation.
If packets are seen to be transmitted onto the DHCP server subnet, check the cable modem debug messages to see if there are parameter request or assignment errors. At this stage of troubleshooting you should investigate the routing between the CM and the DHCP server. Also, double-check the DHCP server configuration and the DHCP logs.
Below is a sample debug taken at the CM by running the debug cable-modem mac log verbose command:
As you can see, the above the DHCP process failed and the cable modem was reset.
DHCP - init(i) state
After a reply to the DHCP request has been received and an IP address assigned to the cable modem the next show cable modem command gives its state as init(i):
#show cable modem
In the output above, the CM never gets beyond state init(i). Repetitive show cable modem displays will usually show the cable modem cycling between init(r1), init(r2), init(rc), init(d) and init(i) indefinitely.
Following is a list of the more common reasons for a cable modem not getting further than init(i):
•
•
•
•
Since the Cable Modem has reached as far as init(i) we know that it has got as far as obtaining an IP address. This is shown in the output display of the debug cable-modem mac log verbose command from the cable modem below:
Similarly, TFTP server issues give similar errors resulting in the cable modem resetting and cycling through the same process indefinitely:
Problems getting TOD (Time of Day) or Timing Offset can also result in the cable modem not achieving online status:
Note
In the debug below there is no time-server specified, but there is a timing offset configured in the DHCP server, and therefore the cable modem goes online:
Not including a Router option setting in the DHCP server or specifying an invalid IP address in the Router option field also results in a cable modem not getting beyond init(i) state, as shown in the output from debug cable-modem mac log verbose below:
TOD exchange- init(t) state
After a cable modem has acquired its network parameters, it must request the time of day from a Time Of Day (TOD) server. TOD uses a UTC timestamp (seconds from January 1, 1970) combined with the time offset option value from DHCP, to calculate the current time. The time is used for syslog and event log timestamps.
Below we have modems with SID 1 and 2 in init(t). Note that with IOS later than 12.1(1) the cable modem still comes online even though the TOD exchange failed, as you can see in the following output from the show cable modem command:
#show cable modem
Time of day errors almost always point to a DHCP misconfiguration. Possible misconfigurations that can result in TOD errors include the following:
•
•
Make sure you can ping the time-server to rule out IP connectivity issues and to verify the time-server is available.
Option File Transfer Started-init(o) State
The main configuration and administration interface to the cable modem is the configuration file downloaded from the provisioning server. This configuration file contains downstream channel and upstream channel identification and characteristics as well as class of service settings, baseline privacy settings, general operational settings, network management information, software upgrade fields, filters, and vendor specific settings.
A cable modem stuck in init(o) state usually indicates that the cable modem started or is ready to start downloading the configuration file, but was unsuccessful. This can be due to the following reasons:
•
•
•
•
Note that you may not always see init(o), instead you might see init(i) and then cycling through from init(r1) to init(i). A more accurate state can be derived by displaying the output of show controller cable-modem 0 mac state.
Following is an abbreviated display of that output:
#show controller cable-modem 0 mac state
When you see init(o) in the show cable modem output, running the debug cable-modem mac log verbose will not tell you if it is a corrupt configuration file or a TFTP server failure that is the cause. The debug points to both of them.
Examples of invalid configuration parameters in the Cisco Broadband Configurator (available for download on cisco.com) are invalid or missing Vendor ID or Vendor Specific Information. The result is similar to the following output display:
Online, Online(d), Online(pk), Online(pt) state
These states indicate that the cable modem has achieved online status and is able to transmit and receive data:
•
•
•
Online(d), however indicates that the cable modem has come online but has been denied network access.
#show cable modem
Online(d) is typically caused by disabling the Network Access option under Radio Frequency info in the Cisco Broadband Configurator (available for download on cisco.com). The default for Network Access is enabled. This can be seen in the display of show cable modem above and in the following output from debug cable-modem mac log verbose:
You can also check by examining the output of show controllers cable-modem 0 mac state on the cable modem:
Note
Online means the cable modem has come online and is able to communicate with the Cisco uBR7246VXR. If the baseline privacy interface (BPI) is not enabled, the online status is the default state (assuming the cable modem initialization was successful). If BPI is configured you will see a status of online(pk), followed shortly by online(pt). The following debug output display was taken on the cable modem side using the debug cable-modem mac log verbose command, showing only the registration part:
If there is a problem with BPI in general you will see reject(pk), meaning it could not get through the key authentication stage. This state is covered in the reject(pk) and reject (pt) section.
For correct BPI operation ensure that the Cisco uBR7246VXR and the cable modem are both running a BPI enabled image. This is indicated by the symbol K1 in the image name.
Also, ensure that the field Baseline Privacy Enable is set to 1 under the Class of Service option in the Cisco Broadband Configurator (available for download on cisco.com). If the Cisco uBR7246VXR is running a BPI enabled image and the cable modem is not, and BPI is enabled in the Cisco Broadband Configurator, then you will observe the cable modem cycling between online and offline.
Reject(pk) and Reject(pt) state
The following output display from show cable modem on the Cisco uBR7246VXR shows a reject(pk) state:
#show cable modem
01:58:51: %UBR7200-5-UNAUTHSIDTIMEOUT: CMTS deleted BPI unauthorized Cable Modem 0030.96f9.65d9Often, when there is a problem with the BPI configuration you will see a reject(pk) state. This state is typically caused by the following:
•
•
•
Reject(pt) is typically caused by an invalid traffic encryption key (TEK). Following is the output display using debug cable privacy on the Cisco uBR7246VXR:
02:32:08: CMTS Received AUTH REQ.02:32:08: Created a new CM key for 0030.96f9.65d9.02:32:08: CMTS generated AUTH_KEY.02:32:08: Input : 70D158F106B0B7502:32:08: Public Key:02:32:08: 0x0000: 30 68 02 61 00 DA BA 93 3C E5 41 7C 20 2C D1 8702:32:08: 0x0010: 3B 93 56 E1 35 7A FC 5E B7 E1 72 BA E6 A7 71 9102:32:08: 0x0020: F4 68 CB 86 A8 18 FB A9 B4 DD 5F 21 B3 6A BE CE02:32:08: 0x0030: 6A BE E1 32 A8 67 9A 34 E2 33 4A A4 0F 8C DB BD02:32:08: 0x0040: D0 BB DE 54 39 05 B0 E0 F7 19 29 20 8C F9 3A 6902:32:08: 0x0050: E4 51 C6 89 FB 8A 8E C6 01 22 02 34 C5 1F 87 F602:32:08: 0x0060: A3 1C 7E 67 9B 02 03 01 00 0102:32:08: RSA public Key subject:02:32:08: 0x0000: 30 7C 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 0502:32:08: 0x0010: 00 03 6B 00 30 68 02 61 00 DA BA 93 3C E5 41 7C02:32:08: 0x0020: 20 2C D1 87 3B 93 56 E1 35 7A FC 5E B7 E1 72 BA02:32:08: 0x0030: E6 A7 71 91 F4 68 CB 86 A8 18 FB A9 B4 DD 5F 2102:32:08: 0x0040: B3 6A BE CE 6A BE E1 32 A8 67 9A 34 E2 33 4A A402:32:08: 0x0050: 0F 8C DB BD D0 BB DE 54 39 05 B0 E0 F7 19 29 2002:32:08: 0x0060: 8C F9 3A 69 E4 51 C6 89 FB 8A 8E C6 01 22 02 3402:32:08: 0x0070: C5 1F 87 F6 A3 1C 7E 67 9B 02 03 01 00 0102:32:08: RSA encryption result = 002:32:08: RSA encrypted output:02:32:08: 0x0000: B6 CA 09 93 BF 2C 05 66 9D C5 AF 67 0F 64 2E 3102:32:08: 0x0010: 67 E4 2A EA 82 3E F7 63 8F 01 73 10 14 4A 24 ED02:32:08: 0x0020: 65 8F 59 D8 23 BC F3 A8 48 7D 1A 08 09 BF A3 A802:32:08: 0x0030: D6 D2 5B C4 A7 36 C4 A9 28 F0 6C 5D A1 3B 92 A202:32:08: 0x0040: BC 99 CC 1F C9 74 F9 FA 76 83 ED D5 26 B4 92 EE02:32:08: 0x0050: DD EA 50 81 C6 29 43 4F 73 DA 56 C2 29 AF 05 5302:32:08: CMTS sent AUTH response.02:32:08: CMTS Received TEK REQ.02:32:08: Created a new key for SID 2.02:32:08: CMTS sent KEY response.Below is a sample debug output on the cable modem when there is an authorization failure:
Similarly, a debug cable privacy on the Cisco uBR7246VXR provides the following errors:
02:47:00: CMTS Received AUTH REQ.02:47:00:Sending KEK REJECT.02:47:05: %UBR7200-5-UNAUTHSIDTIMEOUT: CMTS deleted BPI unauthorized Cable Modem 0030.96f9.65d9
Note
Another error you might encounter is that due to encryption export restrictions, some vendor modems may require the following command on the Cisco uBR7246VXR in the interface configuration:
(config-if)#cable privacy 40-bit-desRegistration - reject (m) state
After configuration, the cable modem sends a registration request (REG-REQ) with a required subset of the configuration settings, and the cable modem and uBR7246 message integrity checks (MIC). The cable modem MIC is a hashed calculation over the configuration file settings, which provides a method for the cable modem to be sure the configuration file was not tampered with in transit. The Cisco uBR7246VXR MIC is similar except it also includes a setting for a cable shared-secret authentication string. This shared secret is known by the Cisco uBR7246VXR and the provisioning server, and ensures that only cable modems authenticated by provisioning servers will be allowed to register with the router.
A cable modem in reject(m) state has a bad Message Integrity Check (MIC), typically caused by:
•
•
To correct the problem, verify that you have a valid configuration file, and that the value under CMTS Authentication is identical to the value configured in cable shared-secret <line> under the cable interface. Also verify that the Cisco uBR7246VXR allows the creation of class of service profiles, or use a profile created by the Cisco uBR7246VXR.
Registration - reject (c) state
A cable modem that fails registration due to bad class of service (COS) has a state of reject(c). Typically this is caused by:
•
•
Following is the output from debug cable-modem mac log verbose taken on the cable modem side showing failure due to bad COS:
Similarly, debug cable registration on the Cisco uBR7246VXR gives the following output:
sniper#debug cable registrationCMTS registration debugging is onsniper#1d04h: %UBR7200-5-CLASSFAIL: Registration failed for Cable Modem 0001.9659.4461 on interface Cable2/0/U0:Bad/Missing Class of Service Config in REG-REQNote how the cable modem eventually resets and starts all over again.
Feedback