Usage Guidelines

This command sets four attributes in the CISCO-DOCS-EXT-MIB MIB, so that the new values can be automatically loaded whenever the CMTS router powers on or reloads. To do so, put the appropriate commands in the configuration file and save it to the CMTS router’s Flash memory. The CMTS router automatically sets the appropriate MIB values when it processes the configuration file at startup.

These commands affect whether the CM online/offline notification trap (cdxCmtsCmOnOffNotification) is sent, and if so, the minimum interval that must exist between traps that are sent for the same CM undergoing the same state changes. The following describes the relationship between these commands and the attributes in the CISCO-DOCS-EXT-MIB MIB:

• The cable enable-trap cmonoff-notification command sets the cdxCmtsCmOnOffTrapEnable attribute to 1 (true), which enables the sending of the CM online and offline traps.
• The no cable enable-trap cmonoff-notification command sets the cdxCmtsCmOnOffTrapEnable attribute to 2 (false), which disables the sending of the CM online and offline traps.
• The cable enable-trap cmonoff-interval command sets the cdxCmtsCmOnOffTrapInterval attribute to the specified time period (0 to 86400 seconds), which sets the minimum interval that must exist before the CMTS sends out the same trap for the same CM.

  For example, if the interval is set to 600 seconds, and the same CM goes offline three times and online twice in that time period, only one online trap and one offline trap is sent to the SNMP manager.

• The no cable enable-trap cmonoff-interval command sets the cdxCmtsCmOnOffTrapInterval attribute to 0, which means a trap will be sent for every CM online/offline transition.

Note	cBR-8 does not support sending modem on/off event notifications to the syslog-server.

Note	Setting the cmonoff-interval option and the cdxCmtsCmOnOffTrapInterval attribute has meaning only if cdxCmtsCmOnOffNotification traps have been previously enabled.

Usage Guidelines

The DOCSIS 1.1 specifications require the CMTS to generate a set of messages for DOCSIS-specific events. These messages can be assigned one of eight priority levels, ranging from emergency (the highest level) to debug (the lowest level), and the CMTS can be configured to log each level of messages differently.

The Cisco CMTS supports the following types of logging, as defined by the DOCS-CABLE-DEVICE-MIB MIB (RFC 2669):

• none (0x0) = DOCSIS messages are not reported. (The corresponding Cisco IOS event messages, however, continue to be logged.)

• local-volatile (0x10) = DOCSIS messages are saved in a local log on the CMTS. This log can be limited in size and can automatically discard previous messages to make room for incoming messages.

• syslog (0x20) = DOCSIS messages are sent to a SYSLOG server (if one has been configured, using the cable event syslog-server command).

• traps (0x40) = DOCSIS messages are sent as SNMP traps to one or more SNMP managers.

These values can be added together to specify that the CMTS should report an event in more than one way. For example, a value of 0x70 specifies that the CMTS should record the event in its local volatile log, and also send it both as a trap and as a SYSLOG message.

Note	If event messages are configured for traps or syslog reporting, they must also be configured for either local volatile or local non-volatile reporting. This means that values 0x20 (syslog-only), 0x40 (trap-only), and 0x60 (syslog and trap only) are not supported.

Use the cable event priority command to set the reporting flags for each type of event. This also configures the appropriate instance of the docsDevEvReporting attribute DOCS-CABLE-DEVICE-MIB MIB ( RFC 2669 ) with the same value.

Note

This command affects only the DOCSIS event messages, and does not affect how the Cisco IOS software handles event messages. If SYSLOG traps are enabled on the Cisco CMTS (using the snmp-server enable traps syslog command), they continue to be sent, regardless of the cable event priority configuration.

Usage Guidelines

The DOCSIS 1.1 specifications require the CMTS router to generate a set of messages for DOCSIS-specific events. Use the cable event syslog-server command to enable DOCSIS SYSLOG services and to set the IP address for the DOCSIS SYSLOG server (which is the docsDevEvSyslog attribute in the DOCS-CABLE-DEVICE-MIB).

Note	cBR-8 does not support sending modem on/off event notifications to the syslog-server.

You can also configure the server’s IP address using SNMP commands to set the docsDevEvSyslog attribute directly. Setting the docsDevEvSyslog attribute also creates a matching cable event syslog-server command in the router’s configuration.

When you specify the IP address for a DOCSIS SYSLOG server, either by using the cable event syslog-server command or by setting the docsDevEvSyslog attribute, the Cisco CMTS router begins generating event messages that conform to the DOCSIS 1.1 specifications. This format is similar to but not identical to the format that is used by the Cisco IOS software. For example, the following message is in the typical Cisco IOS software format:

%UBR7200-4-DCC_ACK_REJ_MSG_SYNTAX_ERROR: DCC-ACK rejected message syntax error

The same error message appears as follows when using the DOCSIS 1.1 format:

<133>CMTS[DOCSIS]:<67040500> DCC-ACK rejected message syntax error

To disable the sending of events to the DOCSIS SYSLOG server, use the no cable event syslog-server command, or specify an IP address of 0.0.0.0 (cable event syslog-server 0.0.0.0 ). Both commands set the docsDevEvSyslog attribute to 0.0.0.0 and disable DOCSIS SYSLOG service. However, this does not disable the Cisco IOS SYSLOG server (if it has been configured using the logging ip-address command).

Note

You can use the same SYSLOG server for both Cisco IOS event messages and for DOCSIS-style event messages, but it might be more convenient to use separate servers for the two different message formats. Use the logging ip-address command in global configuration mode to set the IP address for the Cisco IOS SYSLOG server. The DOCSIS SYSLOG server collects only event messages for DOCSIS events using the DOCSIS format, while the Cisco IOS server collects all event messages (including DOCSIS events) using the standard Cisco IOS message format.

Tip

For more information about DOCSIS SYSLOG services and event messages, see Section 4.4.2.2.2, SYSLOG Message Format, in the DOCSIS 1.1 Operations Support System Interface (OSSI) Specification (SP-OSSIv1.1-I06-020830). For more information about all cable-related event messages that can be generated on a Cisco CMTS router, see the Cisco CMTS System Messages guide.

Usage Guidelines

This command sets the value of the docsDevEvThrottleAdminStatus attribute in the DOCS-CABLE-DEVICE-MIB MIB ( RFC 2669 ), which controls whether the Cisco CMTS should throttle SNMP traps and syslog messages that are generated for DOCSIS event messages.

The DOCS-CABLE-DEVICE-MIB MIB supports the following threshold configurations:

• inhibited—The Cisco CMTS does not generate any SNMP traps or syslog messages for DOCSIS events.
• maintainBelowThreshold—Throttling is performed, and SNMP traps and syslog messages are suppressed if they would exceed the throttle threshold (as set by the cable event throttle-interval and cable event throttle-threshold commands). The Cisco CMTS resumes generating traps and messages at the start of the next throttle interval.
• stopAtThreshold—Throttling is performed, and the Cisco CMTS stops generating all SNMP traps and syslog messages when they exceed the throttle threshold. The Cisco CMTS does not resume generating traps and messages until the threshold state is reset. This can be done by repeating the cable event throttle-adminStatus command, or by setting the docsDevEvThrottleAdminStatus attribute in the DOCS-CABLE-DEVICE-MIB MIB.
• unconstrained—All SNMP traps and syslog messages are transmitted without any throttling.

Tip

For more information about DOCSIS syslog services and event messages, see Section 4.4.2.2.2, syslog Message Format, in the DOCSIS 1.1 Operations Support System Interface (OSSI) Specification (SP-OSSIv1.1-I06-020830). For more information about all cable-related event messages that can be generated on the Cisco CMTS router, see the Cisco CMTS Error Message manual.

Usage Guidelines

The DOCSIS 1.1 specifications require the CMTS to generate a set of messages for DOCSIS-specific events. In certain situations, such as a power outage that causes a mass reregistration of cable modems, this can generate such a large volume of event messages that it can impact system performance.

To avoid this possibility, use the cable event throttle-interval command, together with the cable event throttle-threshold command, to specify the maximum number of SNMP traps or syslog events that the Cisco CMTS can generate for DOCSIS events over a specific interval:

• cable event throttle-interval —Specifies the length of the throttle interval.
• cable event throttle-threshold —Specifies the maximum number of SNMP traps and syslog events that the Cisco CMTS can generate during that period.

The threshold value counts DOCSIS events, not SNMP traps or syslog messages. If a DOCSIS event generates both an SNMP trap and a syslog message, the Cisco CMTS counts it as only one event.

Note	The cable event throttle-interval and cable event throttle-threshold commands do not have any effect unless the cable event throttle-adminStatus has been configured to allow the throttling of DOCSIS event messages.

Tip

For more information about DOCSIS syslog services and event messages, see Section 4.4.2.2.2, syslog Message Format, in the DOCSIS 1.1 Operations Support System Interface (OSSI) Specification (SP-OSSIv1.1-I06-020830). For more information about all cable-related event messages that can be generated on the Cisco CMTS router, see the Cisco CMTS Error Message manual.

Usage Guidelines

The DOCSIS 1.1 specifications require the CMTS to generate a set of messages for DOCSIS-specific events. In certain situations, such as a power outage that causes a mass reregistration of cable modems, this can generate such a large volume of event messages that it can impact system performance.

To avoid this possibility, use the cable event throttle-threshold command, together with the cable event throttle-interval command, to specify the maximum number of SNMP traps or syslog events that the Cisco CMTS can generate for DOCSIS events over a specific interval:

• cable event throttle-interval —Specifies the length of the throttle interval.
• cable event throttle-threshold —Specifies the maximum number of SNMP traps and syslog events that the Cisco CMTS can generate during that period.

The threshold value counts DOCSIS events, not SNMP traps or syslog messages. If a DOCSIS event generates both an SNMP trap and a syslog message, the Cisco CMTS counts it as only one event.

Note	The cable event throttle-interval and cable event throttle-threshold commands do not have any effect unless the cable event throttle-adminStatus has been configured to allow the throttling of DOCSIS event messages.

Tip

For more information about DOCSIS syslog services and event messages, see Section 4.4.2.2.2, syslog Message Format, in the DOCSIS 1.1 Operations Support System Interface (OSSI) Specification (SP-OSSIv1.1-I06-020830). For more information about all cable-related event messages that can be generated on the Cisco CMTS router, see the Cisco CMTS Error Message manual.

Usage Guidelines

In Cisco uBR series router, the cable fiber-node command allows the multiple service operator (MSO) or service provider to configure the CMTS to be more intelligent by making Cisco IOS aware of how the cable plant is wired. The downstream channels of the cable plant must be accurately configured in the CMTS fiber nodes. This allows the CMTS to accurately signal the wideband modems on which wideband channels are available to the modem.

In a cable network, a cable modem is physically connected to only one fiber node. Fiber node software configuration mirrors the physical topology of the cable network. When configuring fiber nodes with Cisco IOS CLI commands, a fiber node is a software mechanism to define the following:

• The set of downstream RF channels that will flow into the fiber node
• At least one primary downstream channel

Note	In Cisco IOS Releases 12.3(21)BC and 12.3(21a)BC3, this is a traditional DOCSIS downstream channel for the fiber node. Beginning in Cisco IOS Release 12.3(23)BC, either an RF channel from the SPA or a Cisco uBR10-MC5X20 downstream channel can serve as a primary channel in a fiber node.

• The set of upstream channel ports on the cable interface line card that are connected to the fiber node and available as upstream channels

Use the cable fiber-node command to enter cable fiber-node configuration mode so that you can configure a fiber node.

For a wideband channel to work correctly, each fiber node must be configured as follows:

1. Use the cable fiber-node command to create the fiber node and to enter cable fiber-node configuration mode.
2. Use the downstream command to associate the fiber node with one or more primary downstream channels (traditional DOCSIS downstream channels).

   Note	Beginning in Cisco IOS Release 12.3(23)BC, if the primary downstream channel for this fiber node is assigned from a SPA RF downstream channel, then this command is not required.

3. Use the upstream command to specify the upstream channel ports for a fiber node.
4. Use the downstream modular-cable rf-channel command to make one or more SPA RF channels available for the fiber node.
5. Optionally, use the description (cable fiber-node ) command to specify a description for the fiber node.

For each fiber node, a traditional DOCSIS downstream channel on the Cisco uBR10-MC5X20 cable interface line card is used to carry MAC management and signaling messages, and the associated traditional DOCSIS upstream channel is used for return data traffic and signaling. The traditional DOCSIS downstream channel used in this way is called the primary downstream channel . Beginning in Cisco IOS Release 12.3(23)BC, either an RF channel from the SPA or a Cisco uBR10-MC5X20 downstream channel can serve as a primary channel in a fiber node. If the fiber node does not have a Cisco uBR10-MC5X20 downstream channel, then make sure that at least one of the SPA RF channels specified in the downstream modular-cable rf-channel command is a primary-capable downstream channel.

Each wideband channel must be associated with at least one primary downstream channel and can be associated with multiple primary downstream channels. A wideband channel and its associated primary downstream channels must be belong to the same virtual bundle interface.

The maximum number of cable fiber nodes that can be configured is limited to 256 for each CMTS.

In Cisco cBR series router, for a wideband channel to work correctly, each fiber node must be configured as follows:

1. Use the cable fiber-node command to create the fiber node and to enter cable fiber-node configuration mode.
2. Use the downstream integrated-cable command to associate the fiber node with a downstream port, all the downstream channels on this port are included in the fiber node .
3. Use the upstream upstream-cable command to specify the a upstream port for the fiber node.

Use the service-group profile profile name command to associate SG profile to a fiber-node, which will generate all the MAC domains, integrated-cable interfaces and wideband interfaces.

Usage Guidelines

This command implements DOCSIS 1.1 packet filtering, as defined in the DOCS-SUBMGT-MIB . Each filter group can contain multiple filters, as defined by the different index numbers.

Note	The DOCS-SUBMGT-MIB MIB is supported only on Cisco IOS Release 12.2(8)BC2 and later 12.2 BC releases. See the description of the docsSubMgtPktFilterTable table in this MIB for further information.

Note	Before configuring layer 4 src-port and dest-port options, configure the IP protocol number using the ip-proto option. If a layer 4 IP protocol is not configured, the default value (256) is used and the filter groups configured with multiple filters will fail.

When matching the source or destination addresses, the filter ANDs the mask value with the filter’s corresponding IP address. The filter then ANDs the mask with the packet’s actual IP address and compares the two values. If they are the same, the filter matches the packet.

For example, if you specify a src-ip of 192.168.100.0 and a src-mask of 255.255.255.0, the filter matches all packets that have a source IP address in the range of 192.168.100.0 through 192.168.100.255. Use a mask value of 0.0.0.0 (default) to match all IP addresses. Use a mask value of 255.255.255.255 to match one specific IP address.

Similarly, when comparing TOS values, the filter ANDs the tos-mask parameter with the tos-value parameter and compares it to the result of ANDing the tos-mask parameter with the packet’s actual TOS value. If the two values are the same, the filter matches the packet.

Note	For the filter group to work for CMs, a CM must re-register after the CMTS router is configured.

Cable Subscriber Management Guidelines

Cable subscriber management is a DOCSIS 1.1 specification, whose functionality can be established using the following configuration methods:

• CMTS router configuration (via CLI)
• SNMP configuration
• DOCSIS 1.1 configuration file (TLVs 35, 36, and 37)

There are certain CMTS configuration requirements if the CM DOCSIS 1.1 configuration file is not used to activate cable subscriber management for the CPE. Specifically, if the docsSubMgtCpeActive object is not provisioned using TLVs 35, 36, and 37 in the DOCSIS 1.1 CM configuration file, then the object uses the docsSubMgtCpeActiveDefault object setting, which is false. This means that cable subscriber management functionality is disabled.

Therefore, if you do not provision TLVs 35, 36, and 37, then you must activate the functionality by specifying the cable submgmt default active global configuration command on the CMTS router.

Note	Since TLVs 35, 36, and 37 do not apply to DOCSIS 1.0 CM configuration files, the only way to enable cable subscriber management for a DOCSIS 1.0 CM is to configure it explicitly on the CMTS router and activate it by using the cable submgmt default active global configuration command.

IPv6 Cable Filter Group Guidelines

Note	When parallel eXpress forwarding (PXF) is configured on the Cisco ubR10012 router, either the interface ACL (ip access-list command) or the cable filter group commands can be used to filter the packets.

Consider the following restrictions and guidelines when configuring IPv6 cable filter groups:

• Chained IPv6 headers are not supported.
• If you need to support IPv4 and IPv6 filters for the same filter group, then you must use a separate index number with the same filter group ID, and configure one index as ip-version ipv4 , and the other index as ip-version ipv6 .

Usage Guidelines

Flapping refers to the rapid disconnecting and reconnecting of a CM that is having problems holding its connection to the CMTS. A flap list is a table maintained by the Cisco CMTS for every modem (active or not) that is having communication difficulties. The flap list contains modem MAC addresses and logs the time of the most recent activity. You can configure the size and entry thresholds for the flap list.

Usage Guidelines

This command controls the operation of a flapping modem detector. When a CM makes two or more initial Ranging Requests (also known as insertion or reinsertion requests) within the period of time defined by this command, the CM is placed in the flap list. A CM is not put into the flap list if the time between its two consecutive initial Ranging Requests is greater than the insertion time interval.

For example, if the CMTS is configured for the default insertion time of three minutes, and if the CM reinserts itself four minutes after its last insertion, the CM is not placed in the flap list. However, if the CM reinserts itself two minutes after its last insertion, the CM is placed in the flap list.

Also, a CM is put into the flap list only once for each insertion time interval, even if the CM reinserts itself multiple times. For example, if the CMTS is set for the default insertion time interval of 3 minutes, and the CM reinserts itself three times within that period, the flap list shows that the CM has flapped once. If the CM reinserts itself three times within the first 3 minute period and three more times within the next 3 minute period, the flap list shows that the CM has flapped twice.

Usage Guidelines

In a DOCSIS network, the CMTS regularly sends out MAC-layer keepalive messages, known as station maintenance messages, to each CM that is online. If a CM does not respond to a station maintenance message, the CMTS repeats sending these messages either until the CM responds or the CMTS reaches the maximum allowable number of messages that can be sent.

The cable flap-list miss-threshold command specifies how many consecutive station maintenance messages can be missed before the cable modem is placed in the flap list. A miss occurs when a CM does not reply to a station maintenance message.

Note

Station maintenance messages are occasionally lost due to noise or congestion in a typical DOCSIS network, with a loss rate of approximately 8 percent considered nominal. A higher miss rate can indicate RF plant problems, such as intermittent upstream problems, fiber laser clipping, or common-path distortion.

Usage Guidelines

This command controls the operation of a flapping modem detector. When the power adjustment of a CM exceeds the configured threshold value, the modem is placed in the flap list.

Note	A power adjustment threshold of less than 2 dB might cause excessive flap-list event recording. Cisco recommends setting this threshold value to 3 dB or higher.

Note

For underground HFC networks with 4 amplifier cascade length, a typical threshold value should be 3 dB. For overhead HFC networks with 4 amplifier cascade length, a typical threshold value should be 4 dB. Longer coaxial cascades without return path thermal gain control and sites with extreme daily temperatures will have larger threshold ranges.

Usage Guidelines

• The flap-list size is determined by the architecture of the CMTS and the cable line cards. Previously, the cable flap-list tables were stored on the Route Processors and Performance Routing Engine (PRE) modules.
• The legacy non-distributed cable line cards, Cisco uBR-MC16C/MC16E/MC16S line card and Cisco uBR-MC28C/MC28E line card did not store the flap-list tables in the line cards.
• The distributed line cards are designed such that they store the flap-list tables on the line cards. For a CMTS using distributed line cards, the flap-list size is the maximum size per line card.
• The distributed line cards supported on a Cisco uBR7200 router are Cisco uBR-MC28U/X and Cisco uBR-16U/16X.
• The distributed line cards supported on a Cisco uBR10012 router are Cisco uBR10-MC5X20S/U/H.
• You can calculate the flap list sizes using the following formulas:
  • For a Cisco uBR10012 router without line card high availability (LC-HA)—8191 * (Number of cable line cards)
  • For a Cisco uBR10012 router with line card high availability (LC-HA)—8191 * (Number of cable line cards - 1)
  • For a Cisco uBR72VXR router using legacy and distributed line cards—8191 * (1 + Number of distributed cable line cards)
• The flap-list tables sizes are as follows:
  • A fully loaded Cisco uBR10012 router

  With distributed line cards and no LC-HA configured—8191 * 8 = 65528 CMs.

  With distributed line cards and LC-HA configured—8191 * (8-1) = 57337 CMs.

  Note: Legacy line cards behave as the distributed line cards on a Cisco uBR10012 router. Thus, the flap-list sizes are same as for distributed line cards.

• A fully loaded Cisco uBR7246VXR router

  With distributed line cards— 8191 * 6 = 49146 CMs.

  With legacy line cards—8191 * (1+0) = 8191 CMs.

  With legacy and distributed line cards— 8191 * (1 + no of the distributed line cards) CMs.

Usage Guidelines

In Cisco IOS Release 12.2(15)BC2 and later, the Cisco CMTS router supports three different modes of operation, depending on the cable interface line cards being used. The range of frequencies that are allowed in each mode are as follows:

• North American DOCSIS (Annex B)—Upstreams use frequencies between 5 MHz and 42 MHz. This range is supported by all cable interface line cards.
• European EuroDOCSIS (Annex A)—Upstreams use frequencies between 5 MHz and 65 MHz.
• Japanese Extended Range (Annex B)—Upstreams use frequencies between 5 MHz and 55 MHz.

Note	The frequency range specified in this command does not apply to upstreams of the Cisco uBR-MC3GX60V cable interface line cards. To specify the upstream frequency for the Cisco uBR-MC3GX60V cable interface line card, use the cable upstream frequency command.

To configure the router so that it supports the proper range of upstream frequencies, use the upstream freq-range command. After you have configured the router with the cable freq-range command, the cable upstream frequency and cable spectrum-group (interface configuration) commands then accept only frequencies that are in the configured range.

Typically, the upstream freq-range command is not needed because the default behavior covers the most common configurations. However, this command can be used in the following situations:

• This command is required to enable EuroDOCSIS operations on the Cisco uBR-MC16U/X and Cisco uBR-MC28U/X cards.
• This command is never needed for the Cisco uBR-MC5X20U card nor for EuroDOCSIS cable interfaces (Cisco uBR-MC16E card, and the Cisco uBR7111E and Cisco uBR7114E routers), because these interfaces default to the EuroDOCSIS range of frequencies. However, if you have previously used this command to restrict the allowable range of frequencies, you must use the european option to re-enable the EuroDOCSIS range of frequencies.
• The north-american option is usually not needed, because this is the default mode of operations for all DOCSIS cable interfaces. However, this option can be useful on the Cisco uBR-MC16U/X and Cisco uBR-MC28U/X cards when noise exists on the frequencies above 42 MHz. In this situation, using the north-american option filters out the higher frequencies and reduces the impact of that noise.
• Similarly, the japanese option is not needed on those cable interface cards that support it, because this is the default configuration on those cards. However, if you have previously used the north-american option on an interface, you need to use the japanese option to re-enable the extended frequency range.
• Even when the upstream freq-range command is not needed to enable a frequency range, using it ensures that the cable upstream frequency and cable spectrum-group commands allow only frequencies that are within the desired range. This can help operators from assigning invalid frequencies to upstreams.

Tip

If one or more cable interface line cards that are installed in the chassis do not support the frequency range that you select with this command, the command displays an informational warning message for each of those cable interface cards. Also, you cannot configure the router for a particular frequency range if an upstream or spectrum group on the router is currently configured for a frequency that is invalid for the new range. If you try to do so, the command is ignored and a warning message is printed prompting you to reconfigure the upstream or spectrum group before retrying the command.

Note

This command configures only the range of frequencies that can be configured on an upstream. It does not configure the upstreams for the DOCSIS (Annex B) or EuroDOCSIS (Annex A) modes of operation, which is done using the cable downstream annex interface command. (Annex C mode is not supported.) You must configure the downstream for Annex A for EuroDOCSIS operations and Annex B for DOCSIS operations. You can configure certain cable interface cards (such as the Cisco uBR-MC28U) for both the DOCSIS Annex B mode and the EuroDOCSIS frequency range, but this violates the DOCSIS specifications and should not be used on standard DOCSIS networks.

The allowable range for the upstream channel frequency depends on the cable interface line card and Cisco IOS software release being used. See Table below for the currently supported values.

Note

The cable freq-range command fails if any upstreams or spectrum groups on the router are currently configured for a frequency that is outside the new range being selected. You must reconfigure those upstreams or spectrum groups, using the cable upstream frequency or cable spectrum-group commands, for lower frequencies, and then repeat the cable freq-range command.

Usage Guidelines

If you want the SC-QAM to exclusively use a specific frequency range, configure Cisco cBR to exclude the band using the cable frequency-exclusion-band command.

Usage Guidelines

This command enables CMs and their attached CPE devices (hosts) to use separate DHCP servers, so that CMs and hosts receive their IP addresses from separate address pools. The cable-modem keyword specifies that only UDP DHCP broadcasts from CMs are forwarded to that particular destination IP address. The host keyword specifies that only UDP broadcasts from hosts (CPE devices) are forwarded to that particular destination IP address.

Note

You must specify both the cable-modem or host options in separate commands, using separate IP addresses, if you decide to use them. If you specify only one option, then the other type of device (cable modem or host) will not be able to connect with a DHCP server. In addition, if you use the cable-modem or host option with the same IP address that was previously configured with this command, the new configuration overwrites the old configuration.

Note

Starting with Cisco IOS Release 12.2(33)SCG, if you use the cable-modem or host option with the same IP address that was previously configured with this command on the Cisco uBR10012 and Cisco uBR7200 series routers, the new configuration does not overwrite the old configuration. It is configured under a bundle interface.

Tip	If you configure different helper addresses on different sub-bundles within a bundle, the cable modem may not come online. We recommend that you use the same helper address on all sub-bundles within a bundle.

The cable helper-address command is similar to the ip helper-address command, but the cable helper-address command has been enhanced for cable interfaces and DOCSIS networks to allow separate helper addresses for CMs and hosts. Use only the cable helper-address command on cable interfaces, and use the ip helper-address command on all non-cable interfaces.

The cable helper-address command, as is the case with the ip helper-address command, cannot be used on subordinate interfaces, so these commands are automatically removed from an interface configuration when the interface is configured as a subordinate interface. Subordinate interfaces use the IP configuration of the primary interface, which includes not only the IP address for the interface itself, but also the helper addresses that have been configured on the primary interface.

Tip	You can repeat this command to specify any number of helper addresses, but the Cisco IOS software uses only the first 16 valid addresses that are configured on each interface (using either the cable helper-address command or the ip helper-address command) when forwarding DHCP requests.

Usage Guidelines

For the vrf keyword of this command, only the ip-address option is supported.

An access list can be configured to deny access to any IP address other than the ones previously configured, using the access-list access-list deny any any command. Starting with Cisco IOS Release 12.2(33)SCD, when a CM is added to such an access list on the Cisco uBR10012 and Cisco uBR7200 series universal broadband routers, the ping fails. If the CM is reset, removed, or powered off, the ping succeeds after the CM comes online. However, the show cable modem access-group command displays that the CM does not belong to the access-group.

Note	The cable host command, and its SNMP equivalent, cdxCmCpeAccessGroup, are not supported on the Cisco uBR10012 universal broadband router. On this router, use the standard DOCSIS MIB, DOCS-SUBMGT-MIB, instead.

Tip	This command is equivalent to configuring cdxCmCpeAccessGroup in CISCO-DOCS-EXT-MIB.

Usage Guidelines

The following command example configures the call window on the Cisco uBR10012 router to be 1 minute in length:

Router(config)# cable high-priority-call-window 1

To observe Emergency 911 calls made within the configured window, use the show cable calls command in privileged EXEC mode:

The following command example illustrates that one Emergency 911 call was made on the Cable8/1/1 interface on the Cisco uBR10012 router during the window set for high priority calls:

Router# show cable calls
Interface   ActiveHiPriCalls  ActiveAllCalls  PostHiPriCallCMs  RecentHiPriCMs
Cable5/0/0  0                 0               0                 0              
Cable5/0/1  0                 0               0                 0              
Cable5/1/0  0                 0               0                 0              
Cable5/1/1  0                 0               0                 0              
Cable5/1/2  0                 0               0                 0              
Cable5/1/3  0                 0               0                 0              
Cable5/1/4  0                 0               0                 0              
Cable6/0/0  0                 0               0                 0              
Cable6/0/1  0                 0               0                 0              
Cable7/0/0  0                 0               0                 0              
Cable7/0/1  0                 0               0                 0              
Cable8/1/0  0                 0               0                 0              
Cable8/1/1  1                 1               0                 0              
Cable8/1/2  0                 0               0                 0              
Cable8/1/3  0                 0               0                 0              
Cable8/1/4  0                 0               0                 0              
Total       1                 1               0                 0 

Router(config)# cable high-priority-call-window 2

Usage Guidelines

The Cable per-physical-downstream Static Multicast Support feature introduces the concept of a physical IGMP static group, which is an extension of the existing logical IGMP static group. The differences between the two IGMP static groups are:

• A cable bundle logical IGMP static group creates the IGMP static group for the logical IP domain and forwards multicast traffics for the configured multicast group to every subordinate interface in the same bundle.

• A cable bundle physical IGMP static group creates the IGMP static group on per-physical subordinate interface basis and will only forwards multicast traffics to only configured subordinate interfaces.

When an IGMP static group is configured on a primary interface, the IGMP static group will perform a check for each subordinate interface in the multicast group. If the multicast group is configured as a physical static group, then only the corresponding subordinate interfaces will be added to the cable bundle forwarding table. If the multicast group is configured as a logical static group, then all subordinate interfaces will be added to the cable bundle forwarding table.

Note	When all remaining physical static groups are un-configured from the subordinate interface for a particular multicast group on a particular bundle, the Cisco CMTS router will revert back to the logical static group for that multicast group on that bundle.

The cable igmp static-group command will only appear in the output of the show running-configuration command if it is configured via the CLI. If it is configured by DSG, the cable igmp static-group command CLI will remain hidden for a particular multicast group. This is done in order to eliminate any confusion with the current DSG configurations.

Note	Any multicast group being used by DSG (or CLI) within the same CMTS, should not be used for CLI (or DSG) configuration.

Usage Guidelines

Use this command to specify the minimum and maximum duration between initial ranging opportunities that appear in MAP messages sent by the Cisco CMTS router. MAP messages define the precise time intervals during which CMs can send.

The default insertion interval setting (automatic ) configures the Cisco CMTS router to optimize the initial ranging times available to new CMs that attempt to join the network. The optimization algorithm automatically varies the initial ranging times between 60 and 480 milliseconds, depending on the number of CMs attempting to come online.

Use the cable insertion-interval automatic command to bring a large number of CMs online quickly (for example, after a major power failure). After the CMs have come online, you can override the automatic keyword by giving this command again and specifying a specific insertion interval.

Usage Guidelines

When this command is activated, the Cisco CMTS router examines each packet for the desired MAC address; when a matching MAC address is found (for either the origination or destination endpoint), a copy of the packet is encapsulated into a UDP packet, which is then sent to the specified server at the given IP address and port.

Note

The data collecting system at the ip-address on the udp-port must be configured to listen for and capture the necessary data stream. An IP route to the specified IP address must exist, and IP connectivity to that device must be present for the traffic to be captured. Before Cisco IOS Release 12.1(11b)EC, the data collecting system must be within two routing hops of the Cisco CMTS.

For Cisco uBR10012 router, a maximum of 4095 MAC intercepts can be configured. This includes the MAC intercepts configured using the cable intercept command, and other lawful intercept features (such as Service Independent Intercept [SII]). The bandwidth used by each MAC intercept is also a deciding factor for the number of MAC intercepts that can be configured. High bandwidth usage by a MAC intercept might reduce the number of MAC intercepts that can be configured.

This command is originally designed to comply with the United States Federal Communications Assistance for Law Enforcement Act (CALEA) and other law enforcement wiretap requirements for voice communications. For additional information, see the PacketCable Electronic Surveillance Specification , which is available at the following URL at the PacketCable web site: http://www.packetcable.com.

Note	For lawful intercept, it is recommended to use SII (through SNMPv3) instead of the cable intercept command.

Note	Starting from Cisco IOS Release 12.2(33)SCC, the cable intercept command is configured under bundle interface. Starting from Cisco IOS Release 12.2(33)SCH, the cable intercept command is not allowed to configure in Cable Interface, both in Cisco uBR7200 series and Cisco uBR10012 routers.

Usage Guidelines

The cable ip-init command configures the cable interface for the IP addressing mode that it supports. This information is included in the IP initialization parameters of the MAC Domain Descriptor (MDD) message.

Usage Guidelines

By default, broadcast IP packets that arrive on the upstream at the Cisco CMTS router are not forwarded on the downstream ports so that they would be delivered to the other CMs and CPE devices. This behavior prevents broadcast storms in which such packets are repeatedly looped through the network.

The cable ip-broadcast-echo command changes this behavior by forwarding such packets on the appropriate downstream ports, so that the packet is received by all CMs and CPE devices on that segment of the network. This allows the cable network to behave more like a standard Ethernet network, and support direct peer-to-peer communications using IP broadcasts.

Note	This command should not be used in a typical service provider network.

Usage Guidelines

By default, multicast IP packets that arrive on the upstream at the Cisco CMTS are forwarded on the appropriate downstream ports so that they are delivered to the other CMs and CPE devices on that segment of the network. This allows the cable network to behave like a standard Ethernet network in terms of its handling of multicast IP traffic.

This behavior might not be appropriate for certain applications or networks, so the no cable ip-multicast-echo command changes this behavior by preventing the forwarding of multicast packets. Disabling multicast traffic can prevent some types of broadcast storms in which such packets are repeatedly looped through the network.

To verify if IP multicast echo has been activated or deactivated, enter the show running-config command and look for the cable interface configuration information.

If IP multicast echo is enabled, it appears in this output of the show running-config command.

If IP multicast echo is disabled, it is not displayed in the output show running-config command.

If you are having trouble, make sure that you have entered the correct slot and port numbers when you entered cable bundle interface configuration mode.

Note	On the Cisco uBR10012 router, input access lists are not applied to the multicast traffic that is echoed on each downstream. To control the echoed multicast traffic, you therefore need to configure an output access list and apply it to each downstream interface.

Usage Guidelines

The Cable IPC Statistics Collection tool provides debugging information about all IPC messages. We recommend that you enable this tool only when it is necessary as the tool consumes considerable amount of CPU memory while running on a Cisco CMTS router.

The cable ipc-stats command is synchronized on all cable interface line cards from the active RP. You do not have to use this command on cable interface line cards separately.

Usage Guidelines

The cable ipv6 dhcp-insert command is used to configure the following feature: DHCP, ToD, and TFTP Services for the CMTS Routers.

This feature enhances the DHCPv6 security potential and the Cable duplicate MAC address feature on the Cisco cBR-8 router.

The cable ipv6 dhcp-insert command specifies which descriptors to append to DHCPv6 packets. The DHCPv6 servers can then detect cable modem clones and extract geographical information.

The Cisco cBR-8 series router can use the DHCPv6 Relay Agent Information option to send particular information about a cable modem, such as its MAC address and the cable interface to which it is connected. If the DHCPv6 server cannot match the information with that belonging to a cable modem in its database, the Cisco cBR-8 series router identifies that the device is a CPE device. This allows the Cisco cBR-8 series router and DHCPv6 server to retain accurate information about which CPE devices are using which cable modems and whether the devices should be allowed network access.

Usage Guidelines

The command, cable ipv6 dhcp-relay override is enabled by default. When it releays DHCPv6 packets, cBR-8 overrides Enterprise ID to 4491 in Vendor Specific Information.

If you explicitly disable this command by using the no cable ipv6 dhcp-relay override command, cBR-8 does not change Enterprise ID in Vendor Specific Information during DHCPv6 relay.

Usage Guidelines

The IPv6 source verification feature is enabled on a cable bundle interface or subinterface.

When you enable IPv6 source verification on the Cisco CMTS bundle interface, the source verification routine is run to verify the MAC-SID-IP binding of the packet. If the source verification succeeds, the packet is forwarded. If the verification fails, then the packet is dropped.

When a cable modem (CM) is operating as a bridged modem device, then the Cisco CMTS router verifies the entire IPv6 address for that CM and the CPEs behind that CM.

When a CM is operating as a router modem device, then the Cisco CMTS router only verifies the network prefix for that CM and the CPEs behind that CM. To be successful, this means that all cable modem routers must have different prefixes assigned to them.

The cable ipv6 source-verify command only controls the source verification of IPv6 packets. For IPv4-based source verification, you must use the cable source-verify command, which also supports different options.

Note	On the Cisco uBR10012 router in Cisco IOS Release 12.2(33)SCA, source verification of IPv6 packets occurs only on packets in the process-switched path of the route processor (RP).

Using the dhcp Option

If the dhcp option is used, the Cisco CMTS sends a DHCPv6 Leasequery message to the DHCP server to verify the IP address. If a valid response is received from the DHCP server, the Cisco CMTS updates its database with the new CPE device and allows future traffic through. If the DHCP server does not return a successful response, all traffic from the CPE is dropped.

If you are using the dhcp option, you have the option to specify an alternate DHCP server using its IP address. The dhcp option supports source verification from multiple dhcp servers.

For single DHCP server, use the cable ipv6 source-verify dhcp [server ipv6-address ] command. For multiple DHCP servers use the cable ipv6 source-verify dhcp command.

Using the leasetimer Option

The leasetimer option adds another level of verification by activating a timer that periodically examines the lease times for the IP addresses for known CPE devices. If the Cisco CMTS discovers that the DHCP lease for a CPE device has expired, it removes that IP address from its database, preventing the CPE device from communicating until it makes another DHCP request. This prevents users from treating DHCP-assigned addresses as static addresses, as well as from using IP addresses that were previously assigned to other devices.

The leasetimer option takes effect only when the dhcp option is also used on an interface. Also, this option is supported only on the primary bundle interface and cannot be configured on subinterfaces. Configuring it for a primary bundle interface automatically applies it to all subinterfaces.

Using the leasequery-filter Option

To prevent a large volume of Leasequery requests on a cable interface, use the cable ipv6 source-verify leasequery-filter command. After configuring this command, the Cisco CMTS allows only the configured number of DHCPv6 Leasequery requests within the specified interval time period.

For example, the cable ipv6 source-verify leasequery-filter 5 10 command configures the Cisco CMTS so that the Cisco CMTS allows a maximum of five DHCPv6 Leasequery requests every 10 seconds for each SID.

Usage Guidelines

Using the ns-probe option

If the ns-probe option is used, the Cisco CMTS sends NS probes to CPE or PD, after LQ succeeds.

Usage Guidelines

Use the cable ipv6 source-verify leasequery-filter downstream command to enable the Leasequery filter on the Cisco CMTS downstream for IPv6 packets.