Usage Guidelines

For bonding capable cable modems, the primary channel selection that is done by the CMTS depends on whether the modems can resolve its MAC Domain Downstream Service Group ID (MD-DS-SG). The CM must attempt to determine its MAC Domain Downstream Service Group ID (MD-DS-SG-ID) if an MDD is present on the downstream. If a modem has resolved its MD-DS-SG, the CMTS selects a bonded primary channel, the primary channel that is part of an operational wideband channel, from the RF channel set corresponding to the MD-DS-SG determined by the modem. The bonded primary channel selected by the CMTS needs to be hosted by an interface on the same uBR10-MC5X20 cable interface line card as the modem’s initial primary channel. If there are multiple primary capable channels that meet the above criteria, the final primary channel will be randomly selected among the eligible channel set.

When the CMTS has an existing record of a CM (listed in the show cable modem command output) that should be moved to a bonded channel, a Dynamic Frequency Override (DFO) is triggered to be sent in the RNG-RSP from the CMTS to that CM.

If a CM is ranging for the first time (not listed in the show cable modem command output), no DFO is triggered at initial-ranging time. The CM proceeds to register and the CMTS gleans the bonding capabilities of the CM to determine if it should be moved to a bonded channel. If the CM is on a wrong primary DS channel, the DOCSIS specification does not allow a DFO at this time, so the CMTS rejects the registration of the CM forcing it to enter the reject(c) state. The CMTS then waits for the CM to start ranging again. If the CM engages with the same incorrect DS channel, the CMTS triggers a DFO to the CM during initial-ranging because it now has a record of that CM.

If a modem has not resolved its MD-DS-SG and the enforce option is configured, the CMTS selects a bonded primary channel based on MAP group associated with the modem’s upstream channel. Typically, an upstream channel is configured into a single fiber node and the CMTS infers the topology information based on the downstream channels associated with the upstream. If the enforce option is not configured or the CMTS cannot find a target primary channel, the modem will be allowed to register on the primary channel currently selected by the modem for initialization.

Note	The CMTS will only try to move the modem with MD-DS-SG unresolved if the enforce option is configured.

By default, changing the primary channel to select a wideband channel is not enforced and modems are allowed to operate on a primary channel even if they are not included in any load balancing groups. At any time after the system is up, enabling the primary channel selection for bonding capable modems will not affect existing modems in the system. The operator has to manually reset the bonding capable modems using the clear cable modem command either globally or at per-MAC Domain level.

Note	Enabling primary channel selection for wideband modems will not affect existing modems in the system.

Usage Guidelines

A modem is identified as a non-bonding-capable modem if the modem reports a Multiple Receive Channel Support value of 1 for TLV 5.29 or an RCP ID unknown to the CMTS during the modem’s registration request.

The non-bonding capable modem, identified at registration, will be moved to a non-bonded primary channel through downstream frequency override, if its current primary channel is part of a bonding group. The target non-bonded primary channel will be selected among primary capable channels that are associated to the modem’s current upstream channel, however not included in any wideband channels associated to any host interfaces on the local line card. Once this option is enabled, the bonded primary channels will be taken out of load balancing group, to prevent non-bonding capable modems to be moved back to bonded primary channels for load balancing purpose.

Note	Enabling primary channel selection for wideband modems will not affect existing modems in the system. The operator has to reset the existing non-bonding capable modems using the clear cable modem command.

Usage Guidelines

The cable service attribute non-ds-bonded command provides the ability to prevent potential non-bonding-capable modems that access CMTS with legacy INIT-RNG-REQ at initialization to register on a CMTS that supports bonding-capable modem. These modems that use legacy initial ranging will be redirected to a specified downstream channel frequency.

Note

If the frequency option is used and if the frequency is modified, then the new frequency setting will only impact new modems trying to initialize after the frequency is modified. To enforce the downstream channel selection policy on existing modems, each modem has to be manually reset either globally or at the individual primary channel level using theclear cable modem command.

Usage Guidelines

A voice-enabled cable modem is identified either at registration by decoding DHCP TLV 122 in the modem's DHCP-ACK, or at its first voice call if DHCP TLV 122 is not exchanged. If a voice-enabled modem is detected at registration on a SPA downstream channel, it will be moved to the uBR10-MC5x20 downstream channel in the CGD via downstream frequency override. If the voice-enabled modem is detected at its first voice call after registration, it will be moved after the call is over to the uBR10-MC5x20 channel in the CGD via DCC. If the voice enabled modem fails to come up on the target uBR10-MC5x20 channel, the CMTS will continue to move the modem until three retries (the maximum number of allowed retries) has been reached, when the modem will be allowed to stay on the SPA downsream channel until another set of retries is attempted by the CMTS every 24 hours. A voice enabled modem on the uBR10-MC5x20 channel will be excluded from being load balanced to a SPA downstream channel. If this option is configured at any time after the system if up, voice enabled modems that have been identified on the SPA dowsntream channel without active voice calls will be gradually moved to the uBR10-MC5x20 downstream channel in the CGD at the rate of one modem per five seconds.

Usage Guidelines

Some DOCSIS 1.x and DOCSIS 2.0 cable modems may fail to come online when they receive DOCSIS 3.0 TLVs from the CMTS during registration. The cable service attribute withhold-TLVs command allows you to restrict sending of the configured DOCSIS 3.0 TLVs to DOCSIS 1.x and DOCSIS 2.0 cable modems. This command does not restrict sending of DOCSIS 3.0 TLVs to DOCSIS 3.0 cable modems.

Note	In Cisco IOS Release 12.2(33)SCB10 only the peak-rate keyword is supported, which represents TLVs 24.27 and 25.27.

Usage Guidelines

The sched-type option must always be specified for each upstream class. The option cannot be configured for downstream classes. When a certain scheduling type is selected, take care that the mandatory parameters for that scheduling type are explicitly entered, while non-applicable parameters must be explicitly removed.

The default direction is upstream . We recommend that you do not change the direction of a service class after you have created it, because some of the existing service class parameters might not be appropriate for the new direction. Instead, delete the current service class and create a new service class with the correct upstream or downstream direction.

If the service class is newly created, a service-class name must be defined before entering the parameters for the service class.

Note

Section C.2.2.6.10, IP Type of Service Overwrite , of the DOCSIS 1.1 specification changed the operation of tos-overwrite option. In DOCSIS 1.1 networks, the new TOS value is calculated by the following formula: New IP TOS = ((Original TOS value AND and-mask ) OR or-mask ). (For a description of the previous method of calculating the TOS value, see the cable qos profile command.) The default is to leave the TOS value unchanged (no overwrite).

Usage Guidelines

Apart from PacketCable, this command enables the cable modem to control the setup of the dynamic service flows, and to remove inactive service flows. During the creation of service flows, all Upstream and Downstream flows in the request are checked to see if the configured activity timeout needs to be applied.

Note	The cable service flow activity-timeout command affects new calls only; it does not clear any existing hung flows. To clear existing flows, use the test cable dsd mac-add sid command.

Usage Guidelines

Resources such as service identifiers (SIDs) and bandwidth are dynamically allocated by a CM using Dynamic Service Addition (DSA) transaction. If the CM fails to release these resources by issuing a Dynamic Service Deletion (DSD), then the resources might be locked indefinitely. Use this command to release unused resources.

Usage Guidelines

DOCSIS 1.1 allows a CM to request Unsolicited Grant Service (UGS) for an upstream, allowing the CM to reserve a certain amount of Constant Bit Rate (CBR) bandwidth for real-time traffic, such as Voice-over-IP (VoIP) calls. The UGS-AD variation allows the CMTS to switch a service flow to Real Time Polling Service (RTPS) after a certain period of inactivity, so that bandwidth is not reserved when it is not needed. The CM can then request UGS service when the flow again becomes active.

Note	This command replaced the cable service-flow inactivity-timeout command, which was used in DOCSIS 1.0 operation to enable or disable watchdog cleanup of dynamic service flows that are not sending any packets on the upstream.

The cable service flow inactivity-threshold command sets the inactivity timer for how long a service flow must be inactive before the CMTS can switch it from UGS-AD to RTPS. The no cable service flow inactivity-threshold command disables the timer and resets it to its default value of 10 seconds, so that the CMTS always provides UGS service to the service flow, even when the flow is idle.

Caution

The no cable service flow inactivity-threshold command effectively disables the use of RTPS and USG-AD services and configures the CMTS to provide only UGS services. This will prevent a CM that registered for USG-AD services from being able to obtain upstream transmission opportunities, resulting in a significant loss of bandwidth when a large number of CMs are requesting UGS-AD service flows.

Usage Guidelines

Use the cable service flow priority command in global configuration mode to enable service flow priority in downstream extended header.

The following example in global configuration mode enables the service flow priority in downstream extended header:

Router(config)# cable service flow priority

Use the show running-config | in service flow command to check the enabled status of the feature:

Router(config)# show running-config | in service flow
cable service flow priority

Usage Guidelines

This command will redirect the CMs matching a particular service-type identifier to downstream frequency. Multiple service types can be redirected to one frequency. However, one service type cannot be redirected to multiple DS frequencies.

Usage Guidelines

The experimental bits are set for all inner and outer MPLS labels for the egress Layer 2 VPN traffic on the WAN interface.

Usage Guidelines

A DOCSIS specification currently being developed requires the DOCSIS CMTS to maintain a log table that contains entries of deleted service flows. The cable sflog command enables the logging of deleted service flows in this table and also sets the maximum number of entries in the log. When the log becomes full, the oldest entries are deleted to make room for the newest ones.

This command also configures how long each entry can remain in the log. When an entry has been in the table for the specified time, the CMTS deletes it, even if the log is not currently full.

To display the service flow log, use SNMP commands to display the docsQosServiceFlowLogEntry entries in the docsQosServiceFlowLogTable table. These attributes are defined in the Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB) internet draft.

Cisco IOS Release 12.2(15)BC1 supports version 4 of this DOCSIS-QOS MIB draft, which is available on the IETF Internet-Drafts web site: http://http://www.ietf.org/ID.html

Note	At the time of this document’s release, the DOCSIS-QOS MIB is still in draft form and is therefore subject to change in future releases of Cisco IOS software.

The max-entry value specified by this command applies to the entire chassis for the Cisco uBR7100 series and Cisco uBR7200 series routers, but to individual line cards on the Cisco uBR10012 and Cisco cBR Series Converged Broadband Routers. However, the Cisco uBR10012 and Cisco cBR Series Converged Broadband Routers still maintain only one log table for all deleted service flows.

For example, if the max-entry value is set to 10,000 on a Cisco uBR7200 series router, the service flow log table holds a maximum of 10,000 entries for all cable line cards in the chassis. If the max-entry value is set to 10,000 on a Cisco uBR100012 router that has four cable line cards installed, the service flow log table holds a maximum of 40,000 entries, with each cable line card having a maximum of 10,000 entries each.

Usage Guidelines

The cable shared-secondary-secret command can be used to supplement the cable shared-secret command so as to prevent unauthorized interception and alteration of the DOCSIS configuration file that is downloaded to the CM during the registration process. The DOCSIS specification allows for a CM and CMTS to use a shared secret (a secret encryption string) to calculate the MD5 Message Integrity Check (MIC) value for the DOCSIS configuration file that is downloaded to the CM.

The CM must use the proper shared secret encryption string to successfully decrypt and process the configuration file, and then register with the CMTS. If the CM does not have the proper encryption string, it will be unable to calculate the proper MIC value, and the show cable modem command will show reject(m) for the modem to indicate a MIC authentication failure.

The cable shared-secondary-secret command allows a cable operator to specify up to 16 alternate DOCSIS shared secrets. If a CM has a MIC authentication failure during registration, the CMTS then checks the MIC values using the alternate shared secrets. If a match is found, the CM is allowed online. If none of the alternate MIC values match the value returned by the CM, the CMTS refuses to allow the CM to come online and instead logs a MIC authentication failure.

The use of secondary shared secrets allow the MSO to gradually phase in changes to the shared secret key. If a shared secret has been compromised, or if the MSO decides to regularly change the shared secret, the MSO can use the cable shared-secret command to immediately change the primary shared secret. The previous key can then be made a secondary shared secret, using the cable shared-secondary-secret command, so that CMs can continue to register until the MSO can change all of the DOCSIS configuration files to use the new shared secret.

To use the secondary shared-secret feature, you must do the following:

• You must specify a shared secret with the cable shared-secret command. The cable shared-secondary-secret command has no effect if you have not specified a primary shared secret.

Note	At any particular time, the majority of CMs should use the primary shared secret to avoid excessive registration times.

• Create DOCSIS configuration files that use the shared-secret encryption string to create the MD5 MIC value. This can be done using the Cisco DOCSIS Configurator tool by entering the shared-secret string in the CMTS Authentication field in the Miscellaneous parameters.

Tip	The shared-secret string itself is not saved in the DOCSIS configuration file, so you must re-enter the string in the “CMTS Authentication” field whenever you create or edit a DOCSIS configuration file using the Cisco DOCSIS Configurator tool.

• Use the cable shared-secondary-secret command to configure the cable interfaces with one or more matching shared-secret strings. The string configured on an interface must match the string used to create the DOCSIS configuration files downloaded to the CMs on that interface, or the CMs will not be able to register. You can use different shared secrets for each interface, if you are also using a different set of configuration files for each interface.
• To encrypt the shared-secret strings in the CMTS configuration, you must include the service password-encryption global configuration command in the router’s configuration.

Note	You cannot use the shared secret feature with the files created by the internal DOCSIS configuration file editor (cable config-file command).

Usage Guidelines

The cable shared-secret command can be used to prevent unauthorized interception and alteration of the DOCSIS configuration file that is downloaded to the CM during the registration process. The cable shared-secret command specifies a secret encryption string that the CMTS uses to calculate the MD5 Message Integrity Check (MIC) value that is appended to every DOCSIS configuration file and that the CM and CMTS use to verify the file’s integrity.

The CM must use the shared secret encryption string to successfully decrypt and process the configuration file, and then register with the CMTS. If the CM does not have the proper encryption string, it will be unable to calculate the proper MIC value, and the show cable modem command will show reject(m) for the modem to indicate a MIC authentication failure.

To use the shared-secret feature, you must do the following:

• Create DOCSIS configuration files that use the shared-secret encryption string to create the MD5 MIC value. This can be done using the Cisco DOCSIS Configurator tool by entering the shared-secret string in the “CMTS Authentication” field in the “Miscellaneous” parameters.

Note	The shared-secret string itself is not saved in the DOCSIS configuration file, so you must re-enter the string in the “CMTS Authentication” field whenever you create or edit a DOCSIS configuration file using the Cisco DOCSIS Configurator tool.

• Use the cable shared-secret command to configure the cable interfaces with a matching shared-secret string. The string configured on an interface must match the string used to create the DOCSIS configuration files downloaded to the CMs on that interface, or the CMs will not be able to register. You can use different shared secrets for each interface, if you are also using a different set of configuration files for each interface.
• To encrypt the shared-secret string in the CMTS configuration, you must include the service password-encryption global configuration command in the router’s configuration.

Note	You cannot use the shared secret feature with the files created by the internal DOCSIS configuration file editor (cable config-file command).

Note	In Cisco IOS Release 12.2(8)BC2 and later releases, you can also use the cable shared-secondary-secret command to specify multiple shared-secret strings, so that you can gradually phase in a new shared secret string.

Upgrading When Using Shared Secret Passwords

Cisco IOS Release 12.2 BC changed the encryption algorithm used for the cable shared-secret command. If you are upgrading from a Cisco IOS 12.1 EC or 12.0 SC release, you cannot cut and paste the cable shared-secret configuration lines that include an encrypted password. Instead, you must re-enter the original shared secret passwords at the CLI prompt, and then resave the configuration.

For example, if the actual shared secret password is “cm-sharedsecret-password”, enter the cable shared-secret cm-sharedsecret-password command at the CLI prompt. If you have enabled password encryption, the configuration file will then show only the newly encrypted password.

Note	This change affects only the encryption of the passwords that are stored in the configuration file. It does not affect the actual encryption that is used between the CMTS and CMs, so you do not need to change the shared secret in the DOCSIS configuration files for the CMs.

Usage Guidelines

Configure the cable sid-cluster-group num-of-cluster 2 command to achieve desired upstream bonded speeds. Alternatively, use a large upstream Max Traffic burst in the cable modem file (such as 30 kB). The Max Concat burst in the cable modem file does not need change because DOCSIS 3.0 uses continuous concatenations and fragmentation (CCF), and can therefore use the default value of 3044 in the Max Concat field.

If the cable sid-cluster-group command is not used, the router accepts the default SID cluster configuration. By default, only one SID cluster is configured.

Usage Guidelines

If the service flow has only one SID cluster and the SID cluster switchover criterion limit is met, the cable modem stops sending bandwidth requests until the SID cluster is cleared.

The SID cluster configuration along with switchover criterion may impact overall system performance. So we recommend not to customizing switchover criterion unless justified. The default switchover criterion will meet most of the requirements. If the cable sid-cluster-switching command is not used, the router accepts the default SID cluster switchover criterion. That is only one request can be made using the SID cluster.

Usage Guidelines

When CIR scaling is configured, the maximum reserved bandwidth is scaled based on the specified percent .

Note	Do not change the CIR scaling value frequently as it can increase the system load.

The table below provides the recommended values for the CIR scaling:

Usage Guidelines

This command can be used for automatic upgrade of Cisco 3 Gbps Wideband Shared Port Adapter and downgrade of Cisco 6 Gbps Wideband Shared Port Adapter FPD images.

Usage Guidelines

Note	If the warning message interval is set to 0, then the warning message is not displayed.

Usage Guidelines

Important

You must configure the service internal command in global configuration mode to enable or disable SNMP cache status.

The time interval for which the SNMP cache information is stored on the Supervisor is known as age and set to 5 seconds.

Usage Guidelines

The no form of this command, that is, no cable snmp cm-rcs returns service-group ID as RCS ID.

Usage Guidelines

This command is used to change the iftype of the downstream physical channel from the default Cisco-defined value 1, to the IANA-defined value 257. The command is also used to revert to the default Cisco-defined value.

Usage Guidelines

The cable snmp trap detailed-alarm CLI feature is disabled by default. When this CLI is enabled, the entity name is added into alarm trap description.

With the cable snmp trap detailed-alarm CLI, two new information will be added into the content of the ceAlarmDescrText component in alarm trap:

• A prefix character ‘#’ .

• The entity name which has alarm.

There are no changes to the other existing components.

Usage Guidelines

Configuring the cable source-verify command on the bundle interface of a bundle will configure it for all of the subordinate interfaces in the bundle as well.

The cable source-verify command helps to prevent the spoofing of IP addresses by CMs or their CPE devices by verifying that the upstream packets coming from each CM are known to be associated with the IP address in that packet. Packets with IP addresses that do not match those associated with the CM are dropped.

In order to protect the Cisco CMTS from denial of service attacks, Cisco IOS Release 12.3(9a)BC adds the option of using a per SID basis for deriving leasequeries from CPE devices. This release also introduces a global rate limit for leasequeries initiated by downstream traffic. These enhancements reduce the CPU utilization of Dynamic Host Configuration Protocol (DHCP) Receive and ISR processes when the Cisco CMTS is configured with the cable source-verify dhcp and no cable arp commands.

When cable source-verify dhcp and no cable arp commands are configured, DHCP leasequery is sent for downstream packets to verify unknown IP addresses within the IP address range configured on the bundle interface.

For DHCP leasequery to work in the downstream direction, the Cisco Network Registrar (CNR) should be made aware of the DHCP Option 82. This is required to make the CMTS map the CPE IP address to the correct CM. To do this, configure the ip dhcp relay information option command on the bundle interface to insert service class relay agent option into the DHCP DISCOVER messages. When the configuration is in place, during DHCP DISCOVER, the values of DHCP Option 82 is cached by the CNR and is returned to the CMTS on any subsequent DHCP leasequery for that IP address.

The Cisco CMTS maintains a database that links the MAC and IP addresses of known CPE devices with the CMs that are providing network access for those CPE devices. The CMTS typically populates this database with information obtained by examining the DHCP packets sent between the CPE devices and the DHCP server. Other IP traffic provides information about which CMs service which CPE devices.

After the cable source-verify command is issued, every IP upstream packet is examined. If the IP and MAC addresses of the CPE device are already associated with a known, online CM, it is allowed through. If not, the source IP address is examined to determine if it belongs to the cable network. If so, and if the dhcp option is not used, the packet is allowed through.

Using the dhcp Option

Note	Do not enable the local DHCP server on the Cisco CMTS and configure local DHCP address pools using the ip dhcp pool command, when using dhcp option, because this prevents DHCP address validation.

If the dhcp option is used, all packets with unknown IP addresses within the cable network are dropped, but the Cisco CMTS sends a DHCP leasequery message to the DHCP server to verify the IP address. If a valid response is received from the DHCP server, the 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.

In Cisco IOS Release 12.2(15)BC1 and later releases, the dhcp option extends the verification to CPE devices that had been online using a valid IP address but then were reconfigured by the user with an unused static IP address. With Cisco IOS Release 12.2(15)BC1 and later, CPE devices are not allowed online when they are using static IP addresses that have not been allocated by the DHCP server. If you are using the dhcp option, the CPE device must use an IP address that has been assigned by the DHCP server.

Note	You must enable the ip dhcp relay information option command to properly trigger the leasequery after configuring the cable source-verify dhcp command. If the ip dhcp relay information option command is not enabled, the leasequery does not recover the IP address of the CPE properly.

Note	The dhcp option automatically blocks all statically-assigned IP addresses unless the DHCP server has been configured to recognize those addresses and respond with the appropriate leasequery response.

The cable source-verify command by itself prevents someone from stealing another customer’s IP address. The cable source-verify dhcp command adds another level of security by refusing access to any CPE device with an IP address that has not been assigned by the DHCP server.

Note	This dhcp option requires that the DHCP server support the leasequery message. The CNR supports leasequery in version 7.0 onwards. The leasequery message is defined in an IETF draft, and available at the URL: http://www.ietf.org/rfc/rfc4388.txt

Caution

Do not enable the local DHCP server on the Cisco CMTS and configure local DHCP address pools, using the ip dhcp pool command, when you are also enabling the cable source-verify dhcp command, because the DHCP server on the Cisco CMTS can intercept the leasequery messages and prevent them from reaching the external DHCP server. This in turn prevents address validation from succeeding because the DHCP server on the Cisco CMTS does not support leasequery messages.

Note

When the cable source-verify dhcp feature is enabled, and a statically-defined IP address has been added to the CMTS for a CM using the cable trust command to override the cable source-verify dhcp checks for this device, packets from this CM will continue to be dropped until an entry for this CM is added to the ARP database of the CMTS. To achieve this, disable the cable source-verify dhcp feature, ping the CMTS from the CM to add an entry to the ARP database, and re-enable the cable source-verify dhcp feature.

Using the leasetimer Option

Note	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 interface and cannot be configured on subinterfaces. Configuring it for a primary interface automatically applies it to all subinterfaces.

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 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.

Note

The leasetimer option is active only if you have also specified the cable source-verify dhcp command for the bundle interface. If the dhcp option is not used, the leasetimer option has no effect. In addition, the leasetimer option can be configured only on an interface, not a subinterface. Applying it to a primary interface automatically applies it to all subinterfaces.

The leasetimer option allows you to configure how often the timer checks the lease times, so as to specify the maximum amount of time a CPE device can use an IP address that was previously assigned by the DHCP server but whose lease time has since expired. The time period can range from 1 minute to 240 minutes (4 hours), with a grace period of 2 minutes to allow a PC enough time to make a DHCP request to renew the IP address. To turn off the timer, so that the CMTS no longer checks the lease times, issue the cable source-verify command without the dhcp option, or turn off the feature entirely with the no cable source-verify command.

Using Multiple Subnets

In Cisco IOS Release 12.2(15)BC2 and later releases, the cable source-verify command can verify IP addresses that are on different subnets than what is being used on the bundle interface or subinterfaces only when Reverse Path Forwarding (RPF) is used in conjunction.

Note	You must enable RPF before running the cable source-verify command to verify IP addresses on subinterfaces.

Usage Guidelines

The following is a sample configuration of the command:

Usage Guidelines

The cable source-verify enable-sav-static command allows you to enable of SAV prefix processing on the Cisco CMTS. If the SAV feature is enabled, the SAV prefixes are matched during source verification. If the feature is disabled the SAV prefixes are not matched, and the configured SAV prefixes do not have any impact on the outcome of the source verification.

This feature is disabled by default.

Usage Guidelines

The cable source-verify group command is used to configure SAV groups. A SAV group is a group of IPv4 or IPv6 prefixes. The Cisco CMTS uses these prefixes to authenticate a cable modem (CM). A CM may be configured with an IPv4 or IPv6 prefix belonging to a particular SAV group. The time, length, value (TLV) 43.7.1 specifies the group name to which a given CM belongs. The Cisco CMTS considers a packet from a CM authorized if that packet is sourced with an IP address that belongs to the configured prefix in a SAV group.

A maximum of 255 SAV groups can be configured on a Cisco CMTS, with each SAV group containing up to four IPv4s, IPv6s, or a combination of both the prefixes (totalling up to four).

Usage Guidelines

When the cable source-verify dhcp and no cable arp commands are configured on a cable interface, the Cisco CMTS router sends a DHCP LEASEQUERY request to the DHCP server to verify unknown IP addresses that are found in packets to and from customer premises equipment (CPE) devices that are using the cable modems on the cable interface. The DHCP server returns a DHCP ACK message with the MAC address of the CPE device that has been assigned this IP address, if any. The router can then verify that this CPE device is authorized to use this IP address, which prevents users from assigning unauthorized IP addresses to their CPE devices.

Problems can occur, though, when viruses, denial of service (DoS) attacks, and theft-of-service attacks scan ranges of IP addresses, in an attempt to find unused addresses. This type of activity can generate a large volume of DHCP LEASEQUERY requests, which can result in high CPU utilization and a lack of available bandwidth for other customers.

To prevent such a large volume of LEASEQUERY requests on all downstreams in the Cisco CMTS router, use the cable source-verify leasequery-filter downstream command. After configuring this command, the Cisco CMTS allows only a certain number of DHCP LEASEQUERY requests in the downstream direction within each interval time period.

For example, the cable source-verify leasequery-filter downstream 5 10 command configures the router so that it allows a maximum of 5 DHCP LEASEQUERY requests every 10 seconds for each SID on the downstream direction. This command applies to all downstream cable interfaces in the router.

Note

The cable source-verify leasequery-filter downstream command enables DHCP lease query filtering on all downstreams, but the actual filtering does not begin until the cable source-verify dhcp command and the no cable arp command are configured on a particular downstream. You can configure these commands on either the downstream’s main interface, or on a subinterface for the downstream. If these commands are configured on a subinterface, however, the lease query filtering occurs only for cable modems using that subinterface.

Tip	Use the cable source-verify leasequery-filter upstream command to filter DHCP LEASEQUERY requests in the upstream direction.

Usage Guidelines

When the cable source-verify dhcp and no cable arp commands are configured on a cable interface, the Cisco Cable Modem Termination System (CMTS) router sends a DHCP LEASEQUERY request to the DHCP server to verify unknown IP addresses that are found in packets to and from customer premises equipment (CPE) devices that are using the cable modems on the cable interface. The DHCP server returns a DHCP ACK message with the MAC address of the CPE device that has been assigned this IP address, if any. The router can then verify that this CPE device is authorized to use this IP address, which prevents users from assigning unauthorized IP addresses to their CPE devices.

Problems can occur, though, when viruses, denial of service (DoS) attacks, and theft-of-service attacks scan ranges of IP addresses, in an attempt to find unused addresses. This type of activity can generate a large volume of DHCP LEASEQUERY requests, which can result in high CPU utilization and a lack of available bandwidth for other customers.

To prevent such a large volume of LEASEQUERY requests on the upstreams on a cable interface, use the cable source-verify leasequery-filter upstream command. After configuring this command, the Cisco CMTS allows only a certain number of DHCP LEASEQUERY requests in the upstream direction within each interval time period.

For example, the cable source-verify leasequery-filter upstream 5 5 command configures the router so that it allows a maximum of 5 DHCP LEASEQUERY requests every 5 seconds for each SID on the upstream direction. This command applies to all upstreams on the cable interface.

Note

The cable source-verify leasequery-filter upstream command enables DHCP lease query filtering on all upstreams on a cable interface, but the actual filtering does not begin until the cable source-verify dhcp command and the no cable arp command are configured on the upstream’s associated downstream interface. You can configure these commands on either the downstream’s main interface, or on a subinterface for the downstream. If these commands are configured on a subinterface, however, the lease query filtering occurs only for cable modems using that subinterface.

Note	If using cable interface bundling, configure the cable source-verify leasequery-filter upstream command on all primary and subordinate interfaces.

Tip	Use the cable source-verify leasequery-filter downstream command to filter DHCP LEASEQUERY requests in the downstream direction.

Usage Guidelines

Frequency agility is configured and activated using spectrum groups that are controlled by the spectrum manager. You can create from 1 to 32, or from 1 to 40, spectrum groups for each cable modem card upstream port, depending on the Cisco IOS software release.

To create spectrum groups, specify a list of upstream frequencies and nominal power levels that each spectrum group can use when an upstream frequency change is necessary. Each spectrum group should have its own list of upstream frequencies. At 1.6 MHz, the valid range is –10 dBmV to 25 dBmV. The power level value should be changed only if you want to change only the power level as part of spectrum management. The standard power level is 0 dBmV.

The cable spectrum-group command sets the center frequency for the upstream, but the total frequency bandwidth that is actually used depends on the channel width. Table below shows the possible center frequencies for each channel width, for both DOCSIS and EuroDOCSIS cable interfaces.

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

Note	If both an Cisco uBR-MC16E cable interface line card and a Cisco uBR-MC16C or a Cisco uBR-MC16S cable interface line card are present in the chassis, a spectrum group in the 42-MHz to 65-MHz range should not be assigned.

Tip

Cisco cable interface line cards always program the upstream’s center frequency in 16 KHz increments, and this is the frequency displayed by the show controller cable upstream command. For example, if you use the cable upstream frequency command to specify a center frequency of 27 MHz (cable upstream x frequency 27000000 ), the actual center frequency will be 27.008 MHz, which is the next highest 16 KHz boundary.

You must repeat this command for each frequency or power level that you want to add to a spectrum group’s list of valid values.

After you have created one or more spectrum groups for your cable network, you can add characteristics to them, providing you with more definitive control over frequency usage and frequency hopping.

The cable interface does not operate until you either create and configure a spectrum group or set a fixed upstream frequency. See the cable upstream channel-width command.

Usage Guidelines

This command assigns a default spectrum group to all of the upstreams on the cable interface. All upstreams on the interface use this spectrum group unless you override this configuration, using one of the following commands:

• To assign a different spectrum group to a particular upstream, use the cable upstream spectrum-group command.
• To assign a new frequency to a particular upstream, use the cable upstream frequency command.

These two commands override the cable spectrum-group command for the particular upstreams to which they are applied. The remaining upstreams in the interface, however, continue to use the default configuration that is specified by the cable spectrum-group command.

Tip	You must first create and configure the spectrum groups before you can assign them to an interface. To create and configure spectrum groups, use the set of cable spectrum-group commands that are available in global configuration mode.

Usage Guidelines

The cable spectrum-group hop period command defines the minimum amount of time that must pass between upstream frequency hops. If ingress noise becomes excessive on a particular upstream, you can set this time period to a smaller value, so as to allow frequency hopping to continue more rapidly until a clear channel is found. Conversely, if the problem appears to be a transient condition, such as a defective CM generating a large volume of errored packets, this time period can be increased to a larger value, so as to avoid excessive frequency hopping by allowing more time between frequency hops.

On the Cisco uBR-MC1xC cards, the maximum recommended hop period is 20 seconds. On the Cisco uBR-MC16S and Cisco uBR-MC5X20S/U cards, the minimum recommended hop period is 25 seconds and the maximum recommended hop period is 35 seconds.

In Cisco IOS Release 12.2(15)BC2, the Cisco CMTS adaptively increases the hop period from the user-defined value to the maximum value (300 seconds) whenever an upstream does not currently have any CMs ranging on it, so as to avoid unnecessary frequency hopping. The user-defined value is restored when a CM starts ranging on the upstream.

Note	The hop period should be set to at least 25 seconds on the Cisco uBR-MC16S and Cisco uBR-MC5X20S/U cards so that transient network problems that are unrelated to ingress noise do not generate unnecessary frequency hops.

Usage Guidelines

The Cisco CMTS sends a station maintenance message to each CM at least once every 25 to 30 seconds. If a CM does not respond to a station maintenance message within that time period, the CMTS then resends station maintenance messages at a faster rate (typically one second apart) in an attempt to restore connectivity with the CM.

Station maintenance messages can be lost because CMs have lost connectivity with the CMTS, or because ingress noise and other factors are causing dropped and errored packets. Downstream noise can also affect the delivery of station maintenance messages. When a user-configurable percentage of station maintenance messages are lost, the CMTS hops to a new upstream frequency to improve connectivity and sends out an Upstream Channel Descriptor (UCD) update to the CMs to inform them of the change.

The optimal hop threshold value depends on several factors, including the quality of the upstream return path and the number of CMs on the upstream. In addition, the hop threshold works together with the hop period so that transient network problems do not generate an unnecessary number of frequency hops. Ideally, the hop threshold should be set low enough so that the frequency hop can occur before a significant number of CMs go offline, but not so low that it generates frequency hops that are not needed.

For example, if the hop threshold is at its default of 20 percent and an upstream has 100 active CMs, a power outage that affected 20 CMs would usually cause a frequency hop since this is a 20 percent loss of CMs, which in turn would be responsible for at least 20 percent loss of station maintenance messages. But in this situation, the frequency hop would be unneeded because changing the upstream frequency could not correct the original problem (the power outage). If this were a common situation on this upstream, the network administrator might increase the hop threshold so that the repeated power outages would not generate unneeded frequency hops.

If, on the other hand, the power outage affected only 10 CMs, a frequency hop would not occur unless another factor, such as ingress noise, created a sufficient loss of station maintenance messages to reach the 20 percent threshold. In this situation, the default threshold of 20 percent might be sufficient.

Downstream problems can also generate frequency hops. For example, if 20 CMs were on a particularly noisy downstream, over time they could miss a sufficient number of station maintenance messages to generate a frequency hop. The network administrator could increase the hop threshold to limit the possibility of frequency hops due to downstream impairments.

Also, faulty CMs could generate a frequency hop under certain conditions. For example, if a number of faulty CMs generated a large number of uncorrectable forward error correction (FEC) errors or otherwise missed 50 to 60 percent of their station maintenance messages, without actually going offline, over time they could miss a sufficient number of station maintenance messages to cause a frequency hop or modulation change. The network administrator could increase the hop threshold to prevent the CMTS from generating a frequency hop or modulation change for problems such as these, which are unrelated to actual noise on the upstream.

Note

If a previous frequency hop had already occurred within the user-configurable hop period, the CMTS will not immediately frequency hop. Instead, the CMTS would wait until the hop period expires, and if the percentage of station maintenance messages still exceeds the hop threshold, the CMTS would perform another frequency hop.

Tip

When an upstream has 25 or fewer CMs (which is typical with lab and test environments), the CMTS increases the rate at which it sends station maintenance messages to the CMs. This higher polling rate, along with the small number of CMs, means that frequency hopping can occur more quickly than with a normally loaded upstream, especially when a small number of CMs are powered down or generate noisy traffic.

Note	The DOCSIS specification states that when a CM misses 16 sequential station maintenance messages, the CMTS should consider the CM offline and should stop sending station maintenance messages to that CM. The CM must then reregister with the CMTS to resume connectivity.

Usage Guidelines

Because this command forces upstream ports to use the same spectrum, you must ensure that you do not configure spectrum groups that have overlapping frequencies. To use shared spectrum groups, each group must be using a discrete set of frequencies.

Caution

Depending on the frequencies being used, and how cable modems are distributed across those frequencies and among spectrum groups, switching from a group from shared to non-shared, or from non-shared to shared, could cause CMs in the spectrum group to go offline and begin reranging procedures. You should therefore use this command only during regularly schedule maintenance times, so that a minimum number of online customers are affected.

Note	This command does not enable any sort of load balancing on the shared upstreams.

Usage Guidelines

This command enables field technicians to add a temporary CPE device behind the subscriber’s cable modem. The temporary CPE device shares the same SID settings as the original CPE device, even though the temporary CPE device has a different MAC address. The original CPE device automatically changes from dhcp cpe to static cpe in the CMTS host routing tables, and the CPE device continues to receive service with the same SID.

To disable Cisco CMTS Static CPE Override on the Cisco CMTS, use the no form of this command. This automatically updates the routing tables and enables the MAC address from the technician’s laptop for a future field service connection at a different location.Prior to using this command, the first (existing) DHCP CPE device maintains its DHCP dynamic MAC address behind the cable modem. The SID is assigned to this IP address.

However, by enabling Static CPE override, you gain the following states and options on two CPE devices behind the cable modem.

• The SID definition on the first CPE device is assigned a different static IP address. This enables you to change the existing (dynamic) DHCP IP address to a static IP address without first clearing the DHCP CPE host entries from the Cisco CMTS. The CPE IP state changes from dhcp to static cpe .
• This static override allows a second CPE device with a second MAC address behind the same cable modem with SID1 to be assigned same IP address as the first CPE device.

Note	The second CPE device changes from dhcp cpe to static cpe in the CMTS host tables.

The DOCSIS 1.1 Subscriber Management MIB (DOCS-SUBMGT-MIB) creates and maintains a number of tables that describe the state of subscriber management for the CMs and CPE devices being serviced by the Cisco CMTS. The CMTS creates rows in these tables for each CM and CPE device when the CM registers with the CMTS, and if the CM does not specify a value for an attribute in this table, the CMTS uses the defaults specified by the cable submgmt default command.

Timesaver

The DOCS-SUBMGT-MIB MIB contains its own default values for these attributes, and those defaults can be overridden by giving the appropriate SNMP SET commands. The cable submgmt default command, however, allows the new defaults to be included in the Cisco IOS configuration file so that the defaults are automatically reconfigured whenever the CMTS reboots or reloads.

Note

The cable submgmt default command sets only the default value for these attributes. These default values are used only if the CM does not specify other values when it registers with the CMTS. If the CM does specify different values at registration time, those values are used instead of these default values.

The attributes in DOCS-SUBMGT-MIB control how the CMTS manages the CPE devices behind a CM and the filters that are applied to the traffic to and from a particular CM and its CPE devices. The following sections describe the relationship between the different forms of the cable submgmt default commands and the attributes in DOCS-SUBMGT-MIB.

CPE Management

The first form of the cable submgmt default command controls the default values for the entries in the docsSubMgtCpeControlTable, which controls how the CMTS manages the CPE devices for each CM:

cable submgmt default active

Sets the docsSubMgtCpeActiveDefault attribute, which is the default value for the docsSubMgtCpeControlActive attribute in docsSubMgtCpeControlTable. This attribute controls whether the CMTS performs CPE management for a particular CM.

• The cable submgmt default active command sets the default to TRUE, which specifies that the CMTS is to manage CPE devices by enforcing the MAX-CPE number and the implemented filters.
• The no cable submgmt default active command sets the default to FALSE (the default value), which specifies that the CMTS is not to perform CPE management for the particular CM.

cable submgmt default learnable

Sets the docsSubMgtCpeLearnableDefault attribute, which is the default value for the docsSubMgtCpeControlLearnable attribute in docsSubMgtCpeControlTable. This attribute controls whether the CMTS learns the IP addresses for CPE devices behind a particular CM.

• The cable submgmt default learnable command sets the default to TRUE (the default value), which specifies that the CMTS is to learn the IP addresses for the CPE devices behind the CM, up to the value specified by the MAX-CPE parameter. The CMTS learns the IP addresses by monitoring the traffic sent by the CPE devices, and the first CPE devices to transmit traffic are the first CPE devices to be learned.
• The no cable submgmt default learnable command sets the default to FALSE, which specifies that the CMTS does not learn the IP addresses for the CPE devices behind a particular CM. Instead, the IP addresses for each CM that is to be allowed access must be specified in the DOCSIS configuration file.

cable submgmt default max-cpe cpe-num

Sets the docsSubMgtCpeMaxIpDefault attribute, which specifies the default value for the docsSubMgtCpeControlMaxCpeIp attribute in docsSubMgtCpeControlTable. This attribute specifies the maximum number of IP addresses that can transmit traffic through a particular CM. The possible range is 0 to 1024, and the original default is 16.

Note	The MAX-CPE attribute is used only when the CMTS is actively managing CPE devices for the CM.

Filter Group Management

The second form of the cable submgmt default command controls the default values for the entries in the docsSubMgtCmFilterTable, which assigns the CM to one or more filter groups. A filter group specifies what filters are applied to the traffic going to or coming from each particular CM or CPE device. Filter groups can be numbered 0 to 1024, where 0 specifies that no filtering is done for that particular traffic type.

Note	The actual filters specified in these commands must be created by setting the appropriate attributes in the DOCS-SUBMGT-MIB MIB using SNMP SET commands.

cable submgmt default filter-group cpe downstream group-id

Sets the ocsSubMgtSubFilterDownDefault attribute, which is the default value for the docsSubMgtSubFilterDownstream attribute in the docsSubMgtCmFilterTable. This attribute applies to downstream traffic that is sent to the CPE devices behind a particular CM.

cable submgmt default filter-group cpe upstream group-id

Sets the docsSubMgtSubFilterUpDefault attribute, which is the default value for the docsSubMgtSubFilterUpstream attribute in the docsSubMgtCmFilterTable. This attribute applies to upstream traffic that is sent by the CPE devices behind a particular CM.

cable submgmt default filter-group cm downstream group-id

Sets the docsSubMgtCmFilterDownDefault attribute, which is the default value for the docsSubMgtCmFilterDownstream attribute in the docsSubMgtCmFilterTable. This attribute applies to downstream traffic that is addressed to a particular CM.

cable submgmt default filter-group cm upstream group-id

Sets the docsSubMgtCmFilterUpDefault attribute, which is the default value for the docsSubMgtCmFilterUpstream attribute in the docsSubMgtCmFilterTable. This attribute applies to upstream traffic that is sent by a particular CM.

Note	For more information about using static CPE override, see the Cisco CMTS Static CPE Override feature on Cisco.com.

Usage Guidelines

To verify whether or not a sync message interval has been configured, enter the show running-config command and look for the cable interface configuration information. If a sync message interval has been configured, it appears in this output. If the sync message interval has been deactivated or reset to its default value, no sync interval command line appears in the output.