-
Cisco IOS CMTS Cable Command Reference
-
Cisco IOS CMTS Cable Command Reference Title
-
Introduction
-
Cable Commands: a through cable-modem
-
Cable Commands: cable a through cable c
-
Cable Commands: cable d
-
Cable Commands: cable e through cable i
-
Cable Commands: cable l
-
Cable Commands: cable m
-
Cable Commands: cable p through cable r
-
Cable Commands: cable s
-
Cable Commands: cable t
-
Cable Commands: cable u through cable w
-
Cable Commands: ca through cr
-
Cable Commands: d through h
-
Cable Commands: i through p
-
Cable Commands: q through sg
-
Cable Commands: show a through show cable l
-
Cable Commands: show cable m through show cable t
-
Cable Commands: show ch through show cr
-
Cable Commands: show d through show i
-
Cable Commands: show m through show z
-
Cable Commands: snmp through w
-
Appendix A: Cable Debug Commands
-
Appendix B: Cisco CMTS Router ROM Monitor Commands
-
Table Of Contents
description (cable fiber-node)
downstream modular-cable rf-channel (interface)
downstream modular-cable rf-channel
h323-gateway voip bind srcaddr
Cable Commands: d through h
Revised: March 30, 2009, OL-15510-09
New Commands
downstream local upstream
12.3(23)BC
downstream modular-cable rf-channel (interface)
12.3(23)BC
Modified Commands
Replaced Commands
The following commands have been replaced by new commands beginning in the following Cisco IOS software releases:
enforced qos-profile
qos-profile enforced
12.3(9a)BC
description (cable fiber-node)
To specify a description for a fiber node, use the description command in cable fiber-node configuration mode. To remove a description for a fiber node, use the no form of this command.
description description
no description
Syntax Description
description
Specifies a description for the cable fiber node. The character-string can be up to 80 characters long.
Command Default
If the description command is not issued, a description does not exist.
Command Modes
Cable fiber-node configuration (config-fiber-node)
Command History
12.3(21)BC
This command was introduced for the Cisco uBR10012 router.
12.2(33)SCA
This command was integrated into Cisco IOS release 12.2(33)SCA.
Usage Guidelines
The description command adds a comment to the configuration to provide information about the fiber node.
Examples
The following example shows how to specify a description for fiber node 5:
Router# configure terminalRouter(config)# cable fiber-node 5Router(config-fiber-node)# description Branch office 5Related Commands
docsis cvc mfg
To configure the access start times and organization name for the manufacturer's code verification certificate (CVC) to enable the DOCSIS 1.1 secure software download feature on the router, use the docsis cvc mfg command in global configuration mode. To delete this information, use the no form of this command.
Cisco uBR905 and Cisco uBR925 cable access routers, and Cisco CVA122 Cable Voice Adapter
docsis cvc mfg {codeAccessStart start-time | cvcAccessStart start-time | organization name}
no docsis cvc mfg {codeAccessStart start-time | cvcAccessStart start-time | organization name}
Syntax Description
Command Default
The codeAccessStart and cvcAccessStart times default to 011219000000Z (midnight on December 19, 2001 Greenwich Mean Time). The organization defaults to Cisco Systems.
Note
Typically, the default values should not be changed unless you are instructed to do so by Cisco TAC or field service engineers.
Command Modes
Global configuration
Command History
12.2(15)CZ
This command was introduced on the Cisco uBR905 and Cisco uBR925 cable access routers, and the Cisco CVA122 Cable Voice Adapter.
Usage Guidelines
This command configures the access start times and organization name that are required by Appendix D in the DOCSIS BPI+ specification. The time values are specified as UTC time values in Greenwich Mean Time, with a two-digit year. If the year is between 50 and 99, it is interpreted as 1950 to 1999. If the year is between 00 and 49, it is interpreted as 2000 to 2049.
The router uses the codeAccessStart value to verify the Code Verification Signature (CVS) that is affixed to the code file downloaded using the secure software download feature. The router uses the ccvAccessStart value to verify the CVC for the code file. The router also uses the organization value to verify that the code file has been created by the proper manufacturer.
Tip
Examples
The following example shows the default configuration for the docsis cvc mfg commands:
Router(config)# docsis cvc mfg organization "Cisco Systems"Router(config)# docsis cvc mfg codeAccessStart 011219000000ZRouter(config)# docsis cvc mfg cvcAccessStart 011219000000ZRouter(config)#
Note
Related Commands
docsis cvc mso
To configure the access start times and organization name for the optional Multi-Service Operator (MSO) cosigned code verification certificate (CVC) for the DOCSIS 1.1 secure software download feature, use the docsis cvc mso command in global configuration mode. To delete the information, use the no form of this command.
Cisco uBR905 and Cisco uBR925 cable access routers, and Cisco CVA122 Cable Voice Adapter
docsis cvc mso {codeAccessStart start-time | cvcAccessStart start-time | organization name}
no docsis cvc mso {codeAccessStart start-time | cvcAccessStart start-time | organization name}
Syntax Description
Command Default
No default values or behavior (no cosigner is used).
Command Modes
Global configuration
Command History
12.2(15)CZ
This command was introduced on the Cisco uBR905 and Cisco uBR925 cable access routers, and the Cisco CVA122 Cable Voice Adapter.
Usage Guidelines
This command configures the optional cosigner access start times and organization name that are specified by Appendix D in the DOCSIS BPI+ specification. The time values are specified as UTC time values in Greenwich Mean Time, with a two-digit year. If the year is between 50 and 99, it is interpreted as 1950 to 1999. If the year is between 00 and 49, it is interpreted as 2000 to 2049.
You do not need to use this command unless the MSO or service provider is digitally signing the Cisco IOS software images that it plans to download to the Cisco cable modems. If so, then this command must be used to set the appropriate access times and organization name, so that the cable modem can properly authenticate the software images during a secure software download.
The router uses the codeAccessStart value to verify the cosigner's Code Verification Signature (CVS) that is affixed to the code file downloaded using the secure software download feature. The router uses the ccvAccessStart value to verify the cosigner's CVC that is affixed to the code file. The router also uses the organization value to verify that the code file has been signed by the proper MSO or cable operator.
Tip
Examples
The following example shows the docsis cvc mso commands being used to configure the router for a cosigned CVC from an organization named "MSO Organization" and with certificate access times of midnight on March 1, 2002 Greenwich Mean Time:
Router(config)# docsis cvc mfg organization "MSO Organization"Router(config)# docsis cvc mfg codeAccessStart 020301000000ZRouter(config)# docsis cvc mfg cvcAccessStart 020301000000ZRouter(config)#
Note
Related Commands
docsis cvc test
To test the root CA public key and CM private key that are installed on the router, use the docsis cvc test command in global configuration mode.
Cisco uBR905 and Cisco uBR925 cable access routers, and Cisco CVA122 Cable Voice Adapter
docsis cvc test
Syntax Description
This command has no arguments or keywords.
Command Default
No default behavior or values.
Command Modes
Global configuration
Command History
12.2(15)CZ
This command was introduced on the Cisco uBR905 and Cisco uBR925 cable access routers, and the Cisco CVA122 Cable Voice Adapter.
Usage Guidelines
This command verifies that the root CA public key and the private key that are installed in the router at the factory are valid. The command uses the root CA public key to encrypt a string, and then it uses the router's private key to decrypt the key.
Typically, the root CA public key and private key are installed at the factory and never need to be updated. However, DOCSIS allows the keys to be updated as part of the secure software download procedure. If this occurs, you can use the docsis cvc test command to verify that the keys are valid and are properly installed.
Examples
The following example shows a typical successful result of the docsis cvc test command:
Router# config terminalRouter(config)# docsis cvc testEncrypted sting: This is a testEncrypt result: xxxxxxxxxxxxxxxxxxxxxxxxxxxDecrypt result: This is a testRouter(config)#
Note
Related Commands
download
To create a DOCSIS configuration file that instructs the CM to download a new software image, use the download command in cable config-file configuration mode. To disable the specification, use the no form of this command.
download {image filename [oui oui-list] | server ip-address}
no download {image filename [oui oui-list] | server ip-address}
Note
Syntax Description
image filename
Specifies to download an image file.
oui oui-list
Specifies the list of Organizational Unique Identifiers (OUIs), up to a maximum of 8. (An OUI is the first 3 octets of the CM MAC address and typically indicates the vendor for the CM.)
Tipserver ip-address
Specifies the TFTP server IP address. If no IP address is specified, the CM defaults to using the same TFTP server that provided the configuration file.
Command Default
The CM does not download a new software image.
Command Modes
Cable config-file configuration
Command History
12.1(2)EC1
This command was introduced.
12.2(4)BC1
Support was added to the Release 12.2 BC train.
Usage Guidelines
This command sets the Software Upgrade Filename and Software Upgrade TFTP Server fields in the DOCSIS configuration file. The DOCSIS specification allows the DOCSIS configuration file to specify that the CM must be running a particular software image. If the CM is not currently using that image, it must then download the image before continuing the registration process. For security, performance, and scalability reasons, a particular TFTP server can be specified from which the CM must download the new software image.
The filename specified by download image command must be a fully qualified file and pathname that exactly matches the file and pathname as they exist on the TFTP download server. For example, if the software image is named ubr920-k1v4y556i-mz and is in a subdirectory named cisco_cms on the TFTP server, the filename specified with this command should be cisco_cms/ubr920-k1v4y556i-mz.
If the oui-list parameter is specified, the download image filename is provided only to the CMs that contain those particular OUIs. This helps ensure that the CM does not download a software image that is intended for another vendor's CMs.
Note
The download server command is not required. If it is not specified, the CM uses the same server that provided its DOCSIS configuration file. However, the download server command requires that the image filename also be specified using the download image command.
Examples
The following command shows how to setup a DOCSIS configuration file so that the cable modem will upgrade its software image:
Router(config)# cable config-file upgrade.cmRouter(config-file)# download image ubr920-k1v4y556i-mz.121-3a.T1 oui 00.50.73 00.D0.BA 00.D0.58 00.01.96Router(config-file)# download server 10.15.24.33Router(config-file)# exitRouter(config)#Related Commands
downstream cable
To assign a primary downstream channel for a fiber node, use the downstream cable command in cable fiber-node configuration mode. To remove a primary downstream channel for a fiber node, use the no form of the command.
downstream cable slot/subslot/port
no downstream cable slot/subslot/port
Syntax Description
Command Default
If the downstream cable command is not issued, no primary downstream channel is assigned to the fiber node.
Command Modes
Cable fiber-node configuration
Command History
12.3(21)BC
This command was introduced for the uBR10012 router.
12.2(33)SCA
This command was integrated into Cisco IOS Release 12.2(33)SCA.
Usage Guidelines
For each fiber node, a traditional DOCSIS downstream channel 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.
The downstream cable command assigns a primary downstream channel for a fiber node. Each fiber node must be assigned at least one primary downstream channel and can be assigned multiple primary downstream channels. Cisco IOS software decides which primary downstream channel to use for the fiber node from the set of channels assigned with downstream cable. Assigning more than one primary channel to a fiber node with the downstream cable command can be useful for load-balancing purposes.
Note
If a wideband-capable modem registers as a traditional DOCSIS 2.0 modem, it will register on a downstream channel as follows:
•
If the modem's fiber node has not been assigned a primary downstream channel with the downstream cable command, the modem can register on any downstream channel that is visible to it.
For more information on using this command, refer to the Cisco uBR10012 Universal Broadband Router SIP and SPA Software Configuration Guide.
Examples
The following example shows how to assign a primary downstream channel for fiber node 5. The primary downstream channel is the downstream port located on the cable interface line card at slot/subslot/port 6/0/0.
Router# configure terminalRouter(config)# cable fiber-node 5Router(config-fiber-node)# downstream cable 6/0/0Related Commands
downstream local upstream
To restrict the set of Cisco uBR10-MC5X20 upstreams associated with the Cisco uBR10-MC5X20 downstreams, use the downstream local upstream command in interface configuration mode.
downstream local upstream grouplist
Syntax Description
grouplist
Specifies the number of upstreams associated with the
Cisco uBR10-MC5X20 downstream channels.
Command Default
All upstreams under the cable interface are associated with the Cisco uBR10-MC5X20 downstreams.
Command Modes
Interface configuration mode (config-if)
Command History
12.3(23)BC
This command was introduced for the Cisco uBR10012 router.
12.2(33)SCB
This command was integrated into Cisco IOS Release 12.2(33)SCB.
Usage Guidelines
Use this command to restrict a set of Cisco uBR10-MC5X20 upstreams to Cisco uBR10-MC5X20 downstreams. This restricts MAC management messages (MMM) to be sent to the specified upstreams only.
Examples
The following example shows how the downstream local upstream command is used in the
Cisco uBR10012 router.Router# configure terminalRouter (config)# interface cable 5/1/0Router(config-if)# downstream local upstream 0-1Related Commands
downstream modular-cable rf-channel (interface)
To specify association of a set of Cisco uBR10-MC5X20 upstreams with individual modular downstream channels from the SPA into a given cable MAC domain, use the downstream modular-cable rf-channel command in interface configuration mode.
Cisco IOS Release 12.3(23)BC
downstream modular-cable slot/subslot/bay rf-channel rf channels [upstream grouplist]
Cisco IOS Release 12.2(33)SCB
downstream modular-cable slot/bay/port rf-channel rf channels [upstream grouplist]
Syntax Description
Command Default
No default upstream channels are configured with the modular downstream channels.
Command Modes
Interface configuration (config-if)
Command History
Usage Guidelines
Use this command to create primary-capable channels by associating a single or a set of
Cisco uBR10-MC 5X20 upstream channels with individual modular downstream channels on a fiber node. When a primary-capable channel is created, the same modular downstream channel cannot be used as a primary-capable channel in another MAC domain. However, it can be used as non-primary-capable channel in another MAC domain.Examples
The following example shows how the downstream modular-cable rf-channel command is used in the Cisco uBR10012 router.
Router# configure terminalRouter (config)# interface cable 5/1/0Router(config-if)# downstream modular-cable 1/0/0 rf-channel 0-2 upstream 0-1 4-5Related Commands
downstream modular-cable rf-channel
To specify the RF channels that are available for wideband channels on a fiber node, use the downstream modular-cable rf-channel command in cable fiber-node configuration mode. To remove RF channels that are available for wideband channels on a fiber node, use the no form of this command.
Cisco IOS Release 12.3(23)BC
downstream modular-cable slot/subslot/bay rf-channel {rf-port | low-high}
no downstream modular-cable slot/subslot/bay rf-channel {rf-port | low-high}
Cisco IOS Release 12.2(33)SCB
downstream modular-cable slot/bay/port rf-channel {rf-port | low-high}
no downstream modular-cable slot/bay/port rf-channel {rf-port | low-high}
Syntax Description
Command Default
If the downstream modular-cable rf-channel command is not issued, no RF channels are configured for wideband channels on the fiber node.
Command Modes
Cable fiber-node configuration (fiber-node)
Command History
Usage Guidelines
The downstream modular-cable rf-channel command makes RF channels available for use on a fiber node. Fiber node software configuration mirrors the physical topology of the cable network. The cable rf-channel command configures the RF channels that will be used for a wideband channel on a Wideband SPA.
The Cisco uBR10012 router supports two Wideband SPAs. Each Wideband SPA supports up to 24 RF channels depending on how the SPA is configured with the annex modulation command.
Note
•
•
A fiber node can be configured to have RF channels from one or both Wideband SPAs. However, a wideband channel cannot be comprised of RF channels from two different SPAs.
Each time the downstream modular-cable rf-channel command is issued for a fiber node, the set of RF channels that are available for use on that fiber node is added to in a cumulative manner. For example, if the following downstream modular-cable rf-channel commands were issued, the set of RF channels available for fiber node 1 is RF channels 0 to 10 on the Wideband SPA in slot/subslot/bay 1/0/0.
Router# configure terminalRouter(config)# cable fiber-node 1Router(config-fiber-node)# downstream modular-cable 1/0/0 rf-channel 0-5Router(config-fiber-node)# downstream modular-cable 1/0/0 rf-channel 6-10Examples
The following example shows how to specify that RF channels 0 to 7 on a Wideband SPA will be available for use on fiber node 5. The Wideband SPA is located in slot/subslot/bay 1/0/0.
Router# configure terminalRouter(config)# cable fiber-node 5Router(config-fiber-node)# downstream modular-cable 1/0/0 rf-channel 0-7Related Commands
dtmf-relay
To configure the router so it transmits Dual-Tone Multifrequency (DTMF) tones as out-of-band signals during H.323 voice calls, use the dtmf-relay command in dial-peer voice configuration mode. To return to the default configuration of transmitting DTMF tones as part of the voice traffic, use the no form of this command.
Cisco uBR924, uBR925 cable access routers, Cisco CVA122 Cable Voice Adapter
dtmf-relay [cisco-rtp] [h245-alphanumeric] [h245-signal]
no dtmf-relay
Syntax Description
Defaults
By default, DTMF tones are transmitted inband, as part of the voice traffic.
Command Modes
Dial-peer voice configuration mode
Command History
Usage Guidelines
DTMF tones are generated when you press the keypad digits on a touch-tone phone. DTMF tones are most commonly used to dial calls, but they can also be used during a call to interact with an Interactive Voice Response (IVR) system, such as voicemail, automated banking services and so on. By default, DTMF tones are transmitted along with the regular voice traffic, but this can cause problems with some IVR systems.
In particular, IVR systems might not recognize DTMF tones when using highly compressed CODECs such as G.729a. These CODECs are highly optimized for voice frequencies, but they can distort DTMF tones, preventing IVR systems from recognizing the tones. To avoid this problem, use one or more of the following methods of transmitting DTMF tones in an out-of-band channel, separately from the voice traffic:
•
•
•
You can enable more than one DTMF relay option for a particular dial peer to support multiple destinations that might use different methods. If you enable more than one option, and if the peer is capable of receiving DTMF in more than one of these formats, the router selects the DTMF format with the highest priority:
1.
2.
3.
4.
Examples
The following example shows how to configure an outgoing dial peer so that DTMF tones to that destination are transmitted using the Cisco RTP protocol, if it is supported by the remote end; otherwise, the DTMF tones are transmitted using the H.245 signaling protocol.
Router(config)# dial-peer voice 100 voipRouter(config-dial-peer)# destination-pattern 555-1212Router(config-dial-peer)# session target ipv4:192.168.100.110Router(config-dial-peer)# dtmf-relay cisco-rtp h245-signalRouter(config-dial-peer)# exitThe following example shows how to reconfigure the above dial peer and disables out-of-band DTMF signaling, so that the DTMF tones are sent inband, as part of the voice traffic:
Router(config)# dial-peer voice 100 voipRouter(config-dial-peer)# no dtmf-relayRouter(config-dial-peer)# exitRelated Commands
codec
Specifies the voice coder rate of speech for a dial peer.
dial-peer
Enters dial peer voice configuration mode.
duration
To specify the time period and sample rate to be used for monitoring subscribers, use the duration command in enforce-rule configuration mode. To reset an enforce-rule to its default values, use the no form of this command.
duration minutes avg-rate rate sample-interval minutes {upstream | downstream} [enforce]
no duration
Syntax Description
Command Default
The duration value defaults to 360 minutes (6 hours), and the sample-interval value defaults to 15 minutes.
Command Modes
Enforce-rule configuration (enforce-rule)
Command History
Usage Guidelines
When you enable an enforce-rule, the CMTS router periodically checks the bandwidth being used by subscribers to determine whether any subscribers are consuming more bandwidth than that specified by their registered QoS profile. The CMTS router keeps track of the subscribers using a sliding window that begins at each sample interval and continues for the duration period and average rate.
For example, with the default sample interval of 15 minutes and the default sliding window period of 360 minutes, the CMTS router samples the bandwidth usage every 15 minutes and counts the total bytes transmitted at the end of each 360-minute period. Each sample interval begins a new sliding window period for which the CMTS router keeps track of the total bytes transmitted.
Note
When you change the configuration of a currently active enforce-rule, that rule begins using the new configuration immediately to manage the cable modems tracked by this enforce-rule.
When you use the show running-configuration command to display the configuration, the keyword options for the duration command are truncated. In the following example, "do" represents downstream, and "enf" represents enforce:
Router# show running-configuration...duration 10 avg-rate 1 sample-interval 10 do enfFor more information about the Subscriber Traffic Management feature and to see an illustration of a sample monitoring window, refer to the Subscriber Traffic Management for the Cisco CMTS Routers feature document on Cisco.com.
Examples
The following example shows an enforce-rule being configured for a sliding window that is 20 minutes in length, an avg-rate of 1 kilobit per second, and a sampling interval of every 10 minutes.
Router# configure terminalRouter(config)# cable qos enforce-rule residentialRouter(enforce-rule)# duration 20 avg-rate 1 sample-interval 10Related Commands
enabled (enforce-rule)
To activate an enforce-rule and begin subscriber traffic management on a Cisco CMTS router, use the enabled command in enforce-rule configuration mode. To disable the enforce-rule without deleting it, use the no form of this command.
enabled
no enabled
Syntax Description
This commands has no keywords or arguments.
Command Default
Enforce-rules are disabled.
Command Modes
Enforce-rule configuration (enforce-rule)
Command History
Usage Guidelines
An enforce-rule is created and configured using the cable qos enforce-rule command, but it is not activated until you run the enabled command. Use the no enabled command to disable an enforce-rule without removing it from the CMTS configuration. When you disable an enforce-rule, all cable modems with that rule's registered QoS profile are no longer tracked by the Subscriber Traffic Management feature and all cable modems in penalty are moved to their registered QoS profile.
Examples
The following example shows an enforce-rule being enabled:
Router# configure terminalRouter(config)# cable qos enforce-rule residentialRouter(enforce-rule)# enabledThe following example shows an enforce-rule being disabled. The rule remains in the CMTS configuration file.
Router# configure terminalRouter(config)# cable qos enforce-rule residentialRouter(enforce-rule)# no enabledRelated Commands
enforced qos-profile
Note
To specify a quality of service (QoS) profile that should be enforced when users violate their registered QoS profiles, use the enforced qos-profile command in enforce-rule configuration mode. To delete the enforced QoS profile from the enforce-rule, use the no form of this command.
enforced qos-profile profile-id [no-persistence]
no enforced qos-profile profile-id [no-persistence]
Syntax Description
Command Default
The profile ID defaults to 0, and enforced QoS profiles are persistent across cable modem reboots.
Command Modes
Enforce-rule configuration (enforce-rule)
Command History
12.2(15)BC1
This command was introduced.
12.3(9a)BC
This command was replaced by the qos-profile enforced command.
Usage Guidelines
Both the originally provisioned QoS profile and the enforced QoS profile must be created on the Cisco CMTS router. This command does not support profiles that are created by the cable modem.
An enforce-rule can specify an enforced QoS profile, which is automatically applied to subscribers that transmit more traffic than what is allowed by their registered QoS profile. The enforced QoS profile remains in effect during the penalty time period (see the penalty-period command). At the end of the penalty period, the subscriber returns to their registered QoS profile.
If a cable modem reboots while it is in its penalty time period, it continues using the enforced QoS profile, unless the service provider has manually changed the cable modem's registered QoS profile using the cable modem qos profile command.
When you change the enforced QoS profile for a currently active enforce-rule, any cable modems using this rule that are currently in the penalty period continue using the previously configured enforced QoS profile. Any cable modems that enter the penalty period after this configuration change, however, use the new enforced QoS profile.
An enforced QoS profile must already have been created on the Cisco CMTS router before you can assign it to an enforce-rule. If the rule does not exist, the system displays an error message.
When the no-persistence option is specified, the enforced QoS profile is still automatically applied to subscribers that violate their bandwidth requirements. However, when the cable modem reboots, the Cisco CMTS router allows the cable modem to use the QoS profile that is specified in its DOCSIS configuration file.
The no-persistence option can be used when initially using subscriber traffic management to identify potential problem applications and users. When repeat offenders are identified, they can then be assigned enforce-rules that do not use the no-persistence option, so that they remain in the penalty period even if they reboot their cable modems.
Note
Examples
The following example shows profile 12 being assigned as the enforced QoS profile to an enforce-rule:
Router# configure terminalRouter(config)# cable qos enforce-rule residentialRouter(enforce-rule)# enforced qos-profile 12The following example shows profile 12 being assigned as the enforced QoS profile to an enforce-rule, but with the no-persistence option specified, so that the enforced QoS profile does not remain in force if the cable modem reboots:
Router# configure terminalRouter(config)# cable qos enforce-rule residentialRouter(enforce-rule)# enforced qos-profile 12 no-persistenceThe following example shows the error message that is displayed when the specified QoS profile does not exist on the CMTS:
Router# configure terminalRouter(config)# cable qos enforce-rule testRouter(enforce-rule)# enforced qos-profile 98The qos profile 98 doesn't exist or it's a cm created QoS profileRelated Commands
exception pxf
To control the core dumps that are generated when an exception occurs in one of the Parallel eXpress Forwarding (PXF) columns, use the exception pxf command in global configuration mode. To disable the creation of core dumps during PXF exceptions, use the no form of this command.
exception pxf {core-file filename | flash device | style {full | localized | minimal | smart} }
no exception pxf {core-file | flash | style }
Syntax Description
Defaults
Core dumps are not generated during PXF exceptions.
Command Modes
Global configuration
Command History
Usage Guidelines
Caution
Examples
The following example shows how to specify that the Cisco uBR10012 router should create a minimal core-dump file for PXF exceptions, and that this file should be named ubr10k-pxf and be written to the disk1 device:
Router# configure terminalRouter(config)# exception pxf style minimalRouter(config)# exception pxf core-file ubr10k-pxfRouter(config)# exception pxf flash disk1:Router(config)#Related Commands
show pxf xcm
Displays the current state of error checking and correcting (ECC) for the External Column Memory (XCM) on the Parallel eXpress Forwarding (PXF) processor.
facility-alarm (ubr10012)
To set the temperature thresholds at which the Performance Routing Engine (PRE) module generates a critical, major, or minor alarm to warn of potential equipment damage, use the facility-alarm command in global configuration mode. To disable the temperature alarms, use the no form of this command.
facility-alarm {core-temperature | intake-temperature}
{critical exceed-action shutdown | major [temp] | minor [temp]}no facility-alarm {core-temperature | intake-temperature}
{critical exceed-action shutdown | major [temp] | minor [temp]}Syntax Description
Defaults
If no specific temperature is given, that particular facility alarm is reset to its default value. The default core temperature thresholds are 85 (critical), 58 (major), and 50 (minor). The default intake-temperature thresholds are 72 (critical), 54 (major), and 45 (minor) degrees Centigrade.
In Cisco IOS releases previous to Cisco IOS Release 12.2(11)BC1, a critical alarm automatically shuts down the router after two minutes to prevent temperature damage. In Cisco IOS Release 12.2(11)BC1 and later, a critical alarm by default does not shut down the router.
Note
Command Modes
Global configuration (config)
Command History
Usage Guidelines
Note
The PRE module on the Cisco uBR10012 router contains temperature sensors that monitor the temperature at the air intake slots and on the PRE module itself. The facility-alarm command configures the router for the temperature thresholds that will generate a minor, major, or critical alarm, so as to notify the system operators of the temperature problem before excessive heat can damage the router or any of its components.
Before Cisco IOS Release 12.2(11)BC1, a critical alarm would also automatically shut down the router after two minutes. Cisco IOS Release 12.2(11)BC1 made this automatic shutdown a configurable option, so that the system operators can decide whether or not a critical alarm should power down the router.
As a general rule, do not disable the automatic shutdown of the router unless you have a systems operator available to immediately respond to any critical temperature alarms, because this could result in system damage. Typically, the primary reason to disable the automatic shutdown would be if you are replacing the fan tray assembly and want to ensure that the router does not power down if the procedure takes longer than expected.
Note
Examples
The following example shows how to configure the Cisco uBR10012 router so that it generates a minor alarm when the intake temperature exceed 55°C:
Router# configure terminalRouter(config)# facility-alarm intake-temperature minor 55The following example shows how to configure the Cisco uBR10012 router to automatically shut down if the high temperature continues for more than two minutes:
Router# configure terminalRouter(config)# service internalRouter(config)# facility-alarm core-temperature critical exceed-action shutdownThe following example shows how to disable the automatic shutdown feature for both the core and intake temperatures. A critical alarm is still generated when the default critical temperatures are exceeded, but the router does not automatically shut itself down:
Router# configure terminalRouter(config)# no facility-alarm core-temperature critical exceed-action shutdownRouter(config)# no facility-alarm intake-temperature critical exceed-action shutdownThe following commands disable major and minor alarms for both the core and intake temperature thresholds (but critical alarms are still generated):
Router# configure terminalRouter(config)# no facility-alarm core-temperature majorRouter(config)# no facility-alarm core-temperature minorRouter(config)# no facility-alarm intake-temperature majorRouter(config)# no facility-alarm intake-temperature minorRelated Commands
flowcontrol
To set the method of data flow control between the terminal or other serial device and the router, use the flowcontrol command in line configuration mode. To disable flow control, use the no form of this command.
flowcontrol {none | software [lock] [in | out] | hardware [in | out]}
no flowcontrol {none | software [lock] [in | out] | hardware [in | out]}
Catalyst 6500 Series Switches and Cisco 7600 Series Routers
To configure a port to send or receive pause frames, use the flowcontrol command in interface configuration mode. To return to the default settings, use the no form of this command.
flowcontrol {send | receive} {desired | off | on}
no flowcontrol {send | receive} {desired | off | on}
Cisco uBR10012 Universal Broadband Router
To temporarily stop the transmission of data between two peers to prevent packet drops in the event of data overflow, use the flowcontrol command in interface configuration mode. To return to the default settings, use the no form of this command.
flowcontrol receive off
no flowcontrol receive off
Syntax Description
Command Default
Flow control is disabled.
Catalyst 6500 Series Switches and Cisco 7600 Routers
Flow-control defaults depend upon port speed. The defaults are as follows:
•
•
•
•
Cisco uBR10012 Universal Broadband Router
Flow control is enabled by default.
Command Modes
Line configuration
Catalyst 6500 Series Switches, Cisco 7600 Series Routers, and Cisco uBR10012 Universal Broadband Router
Interface configuration
Command History
Usage Guidelines
When software flow control is set, the default stop and start characters are Ctrl-S and Ctrl-Q (XOFF and XON). You can change them using the stop-character and start-character commands.
If a remote Telnet device requires software flow control, the remote system should not be able to turn it off. Using the lock option makes it possible to refuse "dangerous" Telnet negotiations if they are inappropriate.
Catalyst 6500 Series Switches and Cisco 7600 Series Routers
The send and desired keywords are supported on Gigabit Ethernet ports only.
Pause frames are special packets that signal a source to stop sending frames for a specific period of time because the buffers are full.
Gigabit Ethernet ports on the Catalyst 6500 series switches and on the Cisco 7600 series routers use flow control to inhibit the transmission of packets to the port for a period of time; other Ethernet ports use flow control to respond to flow-control requests.
If a Gigabit Ethernet port receive buffer becomes full, the port transmits a "pause" packet that tells remote ports to delay sending more packets for a specified period of time. All Ethernet ports (1000 Mbps, 100 Mbps, and 10 Mbps) can receive and act upon "pause" packets from other devices.
You can configure non-Gigabit Ethernet ports to ignore received pause frames (disable) or to react to them (enable).
When used with receive, the on and desired keywords have the same result.
All the Gigabit Ethernet ports on the Catalyst 6500 series switches and the Cisco 7600 series routers can receive and process pause frames from remote devices.
To obtain predictable results, follow these guidelines:
•
•
•
•
Cisco uBR10012 Universal Broadband Router
Flow control is supported only on the 1-Port 10-Gigabit Ethernet SPA installed on a Cisco ubR10012 router.
Examples
The following example sets hardware flow control on line 7:
line 7flowcontrol hardwareCatalyst 6500 Series Switches and Cisco 7600 Series Routers
These examples show how to configure the local port to not support any level of flow control by the remote port:
Router(config-if)# flowcontrol receive offRouter(config-if)#Router(config-if)# flowcontrol send offRouter(config-if)#Cisco uBR10012 Universal Broadband Router
The following example shows how to disable flow control on the Cisco 1-Port 10-Gigabit Ethernet SPA:
Router# configure terminalRouter(config)#interface TenGigabitEthernet1/0/0Router(config-if)#flowcontrol receive offRelated Commands
h323-gateway voip bind srcaddr
To configure the cable access router so that H.323 VoIP traffic is sent using the Ethernet interface's IP address, use the h323-gateway voip bind srcaddr command in cable interface configuration mode. To return to the default configuration, so that the router uses the cable interface's IP address for H.323 VoIP traffic, use the no form of this command.
Cisco uBR924, uBR925 cable access routers, Cisco CVA122 Cable Voice Adapter
h323-gateway voip bind srcaddr ip-address
no h323-gateway voip bind srcaddr
Syntax Description
Defaults
No defaults assigned. By default, H.323 traffic is transmitted with the IP address assigned to the cable interface.
Command Modes
Interface configuration (cable interface only)
Command History
Usage Guidelines
The h323-gateway voip bind srcaddr command can be used with any interface, but it is primarily used with the cable access router's Ethernet interface when configuring a virtual private network (VPN). In this configuration, the h323-gateway voip bind srcaddr command configures the router so that VoIP traffic is sent using the IP address of the Ethernet interface (as opposed to the default behavior, which is to use the IP address of the default outgoing interface, which is the cable interface).
The h323-gateway voip bind srcaddr command allows the enterprise network to maintain the H.323 gatekeeper and gateway in the enterprise network's address space. Without the h323-gateway voip bind srcaddr command, outgoing voice traffic uses the IP address of the cable interface. This method requires that the H.323 gatekeeper and gateway be maintained in the cable service provider's address space, which is not desirable if the enterprise needs to control the voice network and VPN configuration.
Note
Examples
The following example shows how to configure the Ethernet interface with the IP address of 192.168.100.94, and then how to configure the interface so that H.323 traffic will be transmitted using that IP address:
Router(config)# interface ethernet0Router(config-if)# ip address 192.168.100.94 255.255.255.0Router(config-if)# h323-gateway voip bind srcaddr 192.168.100.94Router(config-if)#The following example shows how to remove the H.323 binding, so that H.323 voice traffic is transmitted using the cable interface's IP address:
Router(config-if)# no h323-gateway voip bind srcaddrRouter(config-if)#Related Commands
hccp authentication
To specify the authentication algorithm on a working or protect cable interface, or both use the hccp authentication command in cable interface configuration mode. To disable authentication on a Working CMTS or Protect CMTS, use the no form of this command.
hccp group authentication {md5 | text}
no hccp group authentication {md5 | text}
Syntax Description
Command Default
The default authentication algorithm is MD5.
Command Modes
Interface configuration (cable interface only)
Command History
Usage Guidelines
Use this command together with the hccp authentication key-chain command to enable and specify the type of N+1 redundancy authentication you will use in your protection scheme.
Examples
The following example shows how to specify MD5 as the authentication algorithm for group 1:
Router(config-if)# hccp 1 authentication md5Related Commands
hccp authentication key-chain
To enable authentication and define one or more authentication keys to use in a specified group, use the hccp authentication key-chain command in cable interface configuration mode. To disable authentication, use the no form of this command. The key chains you define must match one or more key chains configured in the Working CMTS or Protect CMTS configuration file.
hccp group authentication key-chain key-chain
no hccp group authentication key-chain [key-chain]
Syntax Description
Command Default
No default behavior or values
Command Modes
Interface configuration (cable interface only)
Command History
Usage Guidelines
Use this command in conjunction with the hccp authentication command to enable and specify the type of 1+1 redundancy authentication you will use in your protection scheme.
Note
Examples
The following excerpt from a configuration file enables authentication using the MD5 algorithm and defines the authentication key "cisco1" for group 1:
!key chain cisco1key 1key-string abcdefgkey 2key-string 123456789!...!interface cable 3/0hccp 1 authentication md5hccp 1 authentication key-chain cisco1!Related Commands
hccp bypass version
To enter bypass version mode for a specific Hot Standby Connection-to-Connection Protocol (HCCP) group, in which the hardware and software version checks are not performed before switching over to a protect interface, use the hccp bypass version command in privileged EXEC mode.
hccp group bypass version
Syntax Description
Command Default
Normal HCCP operations (hccp group check version), where hardware and software version checks are made between the Working and Protect cable interface line cards.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
By default, the Cisco CMTS verifies that the Working and Protect cable interfaces are using the same versions of software and hardware, so as to avoid potential incompatibilities during a switchover. The hardware check verifies that the Working and Protect cable interface line cards are compatible. The software check verifies that the two cards are running the same major versions of software. If either of these two conditions is not true, the CMTS by default does not perform the switchover.
You can override these version checks for a particular HCCP group by using the hccp bypass version command. After you give this command, the Cisco CMTS does not check the hardware or software versions of the two cable interfaces before performing a switchover. To return to normal HCCP operations, so that version checks are made for a group, use the hccp check version command.
Note
Examples
The following example shows how to disable the hardware and software version checks for HCCP group number 20. After giving this command, the Cisco CMTS will switchover from the Working to Protect interface in group 20 without first verifying the cards' compatibility:
Router# hccp 20 bypass versionRouter#Related Commands
hccp channel-switch
To configure the Cisco CMTS so that a Cisco RF Switch or Vecima (Wavecom) upconverter becomes a Hot Standby Connection-to-Connection Protocol (HCCP) member in a particular HCCP group, use the hccp channel-switch command in cable interface configuration mode. To remove the configuration for the Cisco RF Switch or upconverter, use the no form of this command.
hccp group channel-switch member-id switch-name rfswitch-group rfswitch-ip-address module-bitmap position
hccp group channel-switch member-id switch-name rfswitch-module rfswitch-ip-address module-number position
hccp group channel-switch member-id switch-name tty-switch [aux | console | vty] line-number port
hccp group channel-switch member-id switch-name {wavecom-hd | wavecom-ma} prot-ip-address protect-module work-ip-address work-module
no hccp group channel-switch member-id switch-name
Syntax Description
group
The group number for the specified interface. The valid range is 1 to 255.
member-id
The member number within the specified group. The valid range is 1 to 255.
switch-name
(Optional) Alpha-numeric string specifies the name of the
Cisco RF Switch.rfswitch-group
Specifies that this is the configuration for a Cisco RF Switch group.
rfswitch-module
Specifies that this is the configuration for a Cisco RF Switch module.
rfswitch-ip-address
Specifies the IP address of the Cisco RF Switch to which the CMTS is connected.
module-bitmap
Specifies the module-bitmap in hexadecimal. The valid range is 0 to FFFFFFFF.
Tipmodule-number
Specifies the module number on the Cisco RF Switch. The valid range is 1 to 255.
Note
position
Specifies the position for the Working channel on the Cisco RF Switch. The valid range is 1 to 8.
tty-switch
Specifies the configuration of a Cisco RF Switch that is controlled by its TTY line. You can further specify the type of port being used to control the switch. By default, one of the Cisco RF Switch's serial ports is used, or you can use the aux, console, or vty lines.
Note
aux
(Optional) Specifies that the auxiliary port is being used to control the Cisco RF Switch.
console
(Optional) Specifies that the console port is being used to control the Cisco RF Switch.
vty
(Optional) Specifies that a Virtual Terminal connection (Telnet connection) is being used to control the Cisco RF Switch.
line-number
Specifies the line number on which the Cisco RF Switch is receiving control information for this CMTS. The valid range is 0 to 17 for the default serial port, 0 for the aux port, 0 for the console port, and 0 to 99 for the vty port.
port
Specifies the port number being used on the Cisco RF Switch. The valid range is 1 to 255.
wavecom-hd
Specifies that this is the configuration for a Vecima (Wavecom) HD4040 and QHD4040 upconverter.
wavecom-ma
Specifies that this is the configuration for a Vecima (Wavecom) DUAL4040D, MA4040D, or UC4040D upconverter.
prot-ip-address
Specifies the IP address for the upconverter used for the Protect interface used for this cable interface.
protect-module
Specifies the module number on the upconverter used for the Protect interface to be used for this cable interface. The valid range is 1 to 255.
work-ip-address
Specifies the IP address for the upconverter used for the Working interface used for this cable interface.
work-module
Specifies the module number on the upconverter used for the Working interface to be used for this cable interface. The valid range is 1 to 255.
Command Default
The CMTS is not configured to use a Cisco RF Switch by default, and no cable interfaces are configured for N+1 redundancy by default.
Command Modes
Interface configuration—cable interface only (config-if)
Command History
Usage Guidelines
You must configure each Working and Protect cable interface for use with the Cisco RF Switch, typically specifying one hccp channel-switch command to configure the Cisco RF Switch information, and another hccp channel-switch command to configure the upconverter.
The Protect interface is configured with the same hccp channel-switch commands as those that are used on the Working interface. However, typically, the same Protect interface is configured with multiple hccp channel-switch commands to protect multiple Working interfaces.
Examples
The following example shows the cable interface 8/1/0 being configured as member 1 for the Working interface of HCCP group 1. This interface is configured to use the Wavecom HD4040 upconverter with the IP address of 10.97.1.21. The upconverter's module number 2 (B) is used for the Protect interface, and module number 16 (P) is used for the Working interface. The interface uses the Cisco RF Switch at IP address 10.97.1.20, using a module bitmap of AA200000 in switch slot 1.
Router# configure terminalRouter(config)# interface cable8/1/0Router(config-if)# hccp 1 working 1Router(config-if)# hccp 1 channel-switch 1 uc wavecom-hd 10.97.1.21 2 10.97.1.21 16Router(config-if)# hccp 1 channel-switch 1 rfswitch rfswitch-group 10.97.1.20 AA200000 1The following example shows the corresponding configuration for the Protect interface for member 1 of HCCP group 1, which is cable interface 5/1/0 on the same chassis. The hccp channel-switch commands are identical to those used for cable interface 8/1/0.
Router# configure terminalRouter(config)# interface cable5/1/0Router(config-if)# hccp 1 protect 1 10.97.1.8Router(config-if)# hccp 1 channel-switch 1 uc wavecom-hd 10.97.1.21 2 10.97.1.21 16Router(config-if)# hccp 1 channel-switch 1 rfswitch rfswitch-group 10.97.1.20 AA200000 1Typically, the same Protect interface is used to protect multiple Working cable interfaces. For example, this same interface could be configured as follows to protect a Working interface that is using module number 14 (N) on the same Wavecom HD4040 upconverter, using slot 2 in the RF Switch.
Router# configure terminalRouter(config)# interface cable5/1/0Router(config-if)# hccp 1 protect 2 10.97.1.8Router(config-if)# hccp 1 channel-switch 2 uc wavecom-hd 10.97.1.21 2 10.97.1.21 14Router(config-if)# hccp 1 channel-switch 2 rfswitch rfswitch-group 10.97.1.20 AA200000 2Related Commands
hccp check version
To exit bypass version mode and return to normal Hot Standby Connection-to-Connection Protocol (HCCP) operations for a specific HCCP group, use the hccp check version command in privileged EXEC mode.
hccp group check version
Syntax Description
Command Default
Normal HCCP operations (hccp group check version), where hardware and software version checks are made between the Working and Protect cable interface line cards.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
By default, the Cisco CMTS verifies that the Working and Protect cable interfaces are using the same versions of software and hardware, so as to avoid potential incompatibilities during a switchover. The hardware check verifies that the Working and Protect cable interface line cards are compatible. The software check verifies that the two cards are running the same major versions of software. If either of these two conditions is not true, the CMTS by default does not perform the switchover.
You can override these version checks for a particular HCCP group by using the hccp bypass version command. After you give this command, the Cisco CMTS does not check the hardware or software versions of the two cable interfaces before performing a switchover. To return to normal HCCP operations, so that version checks are made for a group, use the hccp check version command.
Note
Examples
The following example shows how to cancel a previous hccp bypass version command for HCCP group 1 and to return to normal HCCP operations:
Router# hccp 1 check versionRouter#Related Commands
hccp ds-switch
To specify the downstream upconverter module for a Working CMTS or Protect CMTS, use the hccp ds-switch command in cable interface configuration mode. To negate a downstream upconverter assignment, use the no form of this command.
hccp group ds-switch member make host-ipaddr host-module peer-ipaddr peer-module
no hccp group ds-switch member
Note
Syntax Description
group
The group number for the specified interface. Valid values are any number from 1 to 255, inclusive.
member
The member number within the specified group.
make
The maker of the specified upconverter. Currently, only the Wavecom upconverter is supported (wavecom).
host-ipaddr
The IP address of the upconverter module1 to which the host CMTS is connected.
host-module
The upconverter module number to which the host CMTS is connected. This location is expressed as a simple numeric designation.
peer-ipaddr
The IP address of the upconverter module to which the peer (or remote) CMTS is connected.
peer-module
The upconverter module number1 to which the peer (or remote) CMTS is connected. This location is expressed as a simple numeric designation.
1 The identification of the upconverter module is important to define when the host or peer CMTS is connected to a channel switch housing multiple modules. For example, the Wavecom MA4040D upconverter chassis offers a maximum of 10 independent frequency agile upconverters.
Command Default
Upconverter specification and activation is disabled by default and must be specified before switching can take place.
Command Modes
Interface configuration (cable interface only)
Command History
Usage Guidelines
It is necessary to configure the downstream upconverter module for all Protect CMTS and Working CMTS systems. If you do not specify the downstream upconverter module for all Protect CMTS and Working CMTS systems, you cannot switch between a Protect CMTS and Working CMTS.
Examples
The following excerpt from a configuration file specifies module 2 on a Wavecom upconverter at IP address 1.1.11.3 as the host switch module connected to Working CMTS 1 and module 1 on the same Wavecom upconverter (with the same IP address location) as the peer or remote switch module connected to the Protect CMTS:
hccp 1 working 1hccp ds-switch 1 wavecom 1.1.11.3 2 1.1.11.3 1Related Commands
hccp lockout
To prevent a Working CMTS from automatically switching to a Protect CMTS in the same group, use the hccp lockout command in privileged EXEC mode.
Note
hccp group lockout member
Syntax Description
group
The group number for the specified interface. Valid values are any number from 1 to 255, inclusive.
member
The member number within the specified group.
Command Default
By default, the hccp lockout command is inactive.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Typically the hccp lockout command is used to disable HCCP switchovers before removing the HCCP configuration on the Working interface. Otherwise, when you remove the HCCP configuration from the Working interface, the Protect interface assumes the Working interface has failed and switches over.
You might also want to prevent a Working CMTS from automatically switching back to a Protect CMTS for testing or additional configuration purposes. For example, you might want to fully test protecting cable interfaces on your Cisco CMTS before returning it to protect status.
Examples
The following example shows how to activate the lockout feature of a Working CMTS in group 1:
Router# hccp 1 lockoutRelated Commands
hccp protect
To configure a particular cable interface to protect another cable interface in the same group, use the hccp protect command in cable interface configuration mode. To undo a particular host cable interface protection assignment, use the no form of this command.
hccp group protect member ipaddr
no hccp group protect member
Syntax Description
Command Default
No default behavior or values
Command Modes
Interface configuration (cable interface only)
Command History
Usage Guidelines
The protect cable interface must be configured identically to the working cable interface, which typically means the interfaces must be the same card type. However, when the Cisco uBR-MC16S card is used, it can be used with either another Cisco uBR-MC16S card or a Cisco uBR-MC16C card.
Table 19 shows how a switchover affects the enhanced spectrum management features of the Cisco uBR-MC16S card.
Examples
The following example configures host cable interface 4/0 to protect member 2 of group 2 at IP address 1.1.11.2:
Router(config)# interface cable 4/0Router(config-if)# hccp 2 protect 2 1.1.11.2Related Commands
hccp resync
To manually synchronize the Inter-database between the Working and Protect interfaces for a particular member in an Hot Standby Connection-to-Connection Protocol (HCCP) group, use the hccp resync command in privileged EXEC mode.
hccp group resync member
Syntax Description
group
The group number for the specified interface. The valid range is 1 to 255.
member
The member ID to be resynchronized. The valid range is 1 to 255.
Command Default
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The Cisco CMTS automatically synchronizes the Working and Protect interfaces to ensure that when a switchover occurs, the Protect interface will run with a configuration that is identical to that of the Working interface. However, if you are troubleshooting HCCP problems, you can manually resynchronize the databases using the hccp resync command before performing any switchover tests.
Note
%No response from slot 6/1. Command aborted
If this occurs, wait a minute or so and retry the command.Examples
The following example shows how to manually resynchronize the Inter-database between the Working and Protect interfaces for member 4 in HCCP group 13:
Router# hccp 13 resync 4Router#Related Commands
hccp revertive
To configure a cable interface on a Protect CMTS that has assumed working capacity to automatically revert back to the Working CMTS, use the hccp revertive command in cable interface configuration mode. To disable the ability for the specified cable interface to automatically revert back to protect status, use the no form of this command.
hccp group revertive
no hccp group revertive
Syntax Description
group
The group number for the specified interface. Valid values are any number from 1 to 255, inclusive.
Command Default
Enabled
Command Modes
Interface configuration (cable interface only)
Command History
Usage Guidelines
Using this command in conjunction with the hccp reverttime command gives you the ability to set up your protecting cable interfaces to automatically switch between working and protecting capacity without your intervention. Otherwise, whenever a switchover has occurred, you must manually reactivate the failed Working CMTS and manually return the Protect CMTS to protect status using the hccp switch command.
Tip
Using hccp track with hccp revertive
As a general rule, if you are using the hccp track command on a cable interface, do not also configure the hccp revertive command without also configuring no keepalive on the cable interface. Configuring both commands on the same interface, along with keepalives, can cause multiple switchovers on the same fault.
If you want to use keepalives along with both the hccp track and hccp revertive commands,use the hccp track command on both the Working and Protect interfaces, so that the Working interfaces on the same card track each other and the Protect interfaces on the same card track each other. Table 20 summarizes the guidelines for using these three commands:
Examples
The following example shows cable interface 4/0 on a Protect CMTS in group 2 being configured to automatically revert to protect status after the Working CMTS peer has returned to active duty:
router(config)# interface cable 4/0router(config-if)# hccp 2 revertiveRelated Commands
hccp reverttime
To specify the amount of time a Protect interface waits before automatically reverting back to a Working interface following a system switchover, use the hccp reverttime command in cable interface configuration mode on the Working CMTS. To set the revert-time back to its default value, use the no form of this command.
hccp group reverttime revert-time
no hccp group reverttime
Syntax Description
Command Default
30 minutes
Command Modes
Interface configuration (cable interface only, on the Working CMTS)
Command History
Usage Guidelines
Use this command to configure the revert-time on the cable interfaces on the Working CMTS so that the Working CMTS will automatically resume normal operations and the Protect CMTS will automatically resume normal protect operations, in case an operator forgets to manually switch the Working CMTS back into operation after fixing the original problem.
The Working CMTS first counts down two minutes of suspend time before starting to count down the revert-time. Any failures that occur within this two-minute suspend time are considered part of the same failure.
This means that the actual time that the Working CMTS will attempt to switch back after a switchover is two minutes plus the revert-time. For example, if the revert-time is set to its default of 30 minutes, the Working CMTS will attempt to switch back into operation 32 minutes after the initial switchover to the Protect CMTS.
After the suspend time has occurred, a failure in the Protect CMTS will cause a switchover to the Working CMTS, regardless of whether the revert-time has expired or not. You can force such a failure in the Protect CMTS, and restore the Working CMTS to operation without waiting for the revert-time, by using the cable power off and cable power on commands to turn off and turn on the protect interface on the Protect CMTS.
When choosing a revert-time, take into account all possible sources of failures, including third-party equipment. For example, an upconverter failure can trigger a switchover to the Protect CMTS. You should configure the revert-time so that the Working CMTS does not switch back into operation until technicians have had sufficient time to fix the equipment failure.
Tip
Examples
The following example shows cable interface 3/0 on a Working CMTS in group 2 being configured to wait 15 minutes before automatically reverting back to working status after a system switchover:
router(config)# interface cable 3/0router(config-if)# hccp 2 reverttime 15The following example shows how to give the no form of this command, which resets the interface back to its default value of 30 minutes.
router(config)# interface cable 5/1/0router(config-if)# no hccp 2 reverttimeRelated Commands
hccp switch
To manually switch a Protect CMTS with its Working CMTS peer (or vice versa), use the hccp switch command in privileged EXEC mode.
hccp group switch member
Syntax Description
Command Default
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command overrides any configuration you may have made on your Protect CMTS and Working CMTS using the hccp revert and hccp reverttime commands. In addition, you can issue the hccp switch command on either a Protect CMTS or a Working CMTS to force it to change places with its peer.
Examples
The following example shows the host Protect CMTS being configured to assume traffic responsibility for member 2 Working CMTS in group 2:
Router# hccp 2 switch 2RRelated Commands
hccp timers
To configure HELLO packet interval and hold time for a specified group on a Protect CMTS, use the hccp timers command in cable interface configuration mode. To erase the HELLO interval and hold time configuration and to assume the default values for each parameter, use the no form of this command.
hccp group timers hello-time hold-time
no hccp group timers [hello-time hold-time]
Note
Syntax Description
Command Default
The default HELLO interval is 2,000 milliseconds, and the default hold time is 6,000 milliseconds.
Command Modes
Interface configuration (cable interface only)
Command History
Examples
The following example shows the HELLO interval and hold time on a Protect CMTS in group 2 being configured to 1,750 and 3,000 milliseconds, respectively:
Router(config)# interval c4/0Router(config-if)# hccp 2 timers 1750 3000Related Commands
hccp track
To configure a cable interface on a Working CMTS or Protect CMTS to enable automatic switchover based on the interface state, use the hccp track command in cable interface configuration mode. To disable the automatic switchover based on interface state, use the no form of this command.
hccp group track [interface]
no hccp group track [interface]
Syntax Description
group
The group number for the specified interface. Valid values are any number from 1 to 255, inclusive.
interface
Specifies another cable interface (the default is the current cable interface).
Command Default
Enabled for the current interface
Command Modes
Interface configuration (cable interface only)
Command History
Usage Guidelines
This command enables automatic switchover of one interface when a tracked interface switches over from "up" to "down."
Typically, this command is used to allow all interfaces on one card to track one another, so that if one interface goes down and switches over to the Protect, all other interfaces can also switch over, allowing the Protect card to assume full operation for these interfaces. This allows support engineers to troubleshoot the problem on the Working interface, or to remove and replace the Working card, if necessary, without interfering with traffic.
Using hccp track with hccp revertive
As a general rule, if you are using the hccp track command on a cable interface, do not also configure the hccp revertive command without also configuring no keepalive on the cable interface. Configuring both commands on the same interface, along with keepalives, can cause multiple switchovers on the same fault.
If you want to use keepalives along with both the hccp track and hccp revertive commands,use the hccp track command on both the Working and Protect interfaces, so that the Working interfaces on the same card track each other and the Protect interfaces on the same card track each other. Table 21 summarizes the guidelines for using these three commands:
Examples
The following example shows switchover behavior being enabled on a Cisco CMTS in group 2:
Router(config)# interface c3/0Router(config-if)# hccp 2 trackRouter(config-if)# keepaliveRouter(config-if)#The following example shows two Cisco uBR-LCP2-MC28C cards being used in a Cisco uBR10012 router, with each downstream being configured for a separate HCCP group. The card in slot 5/1 is being configured as the Working interfaces and the card in slot 6/1 is being configured as the Protect interfaces.
The two downstreams on each card track each other, so if one downstream fails and switches over, the other can do so as well, allowing the Protect card to assume full control of both interfaces. Similarly, when the Working interfaces come back into service, both Protect interfaces switch back at the same time.
Router(config)# interface cable c5/1/0Router(config-if)# hccp 1 working 1Router(config-if)# hccp 1 track c5/1/1Router(config-if)# keepalive 3Router(config-if)# exitRouter(config)# interface cable c5/1/1Router(config-if)# hccp 2 working 1Router(config-if)# hccp 2 track c5/1/0Router(config-if)# keepalive 3Router(config-if)# exitRouter(config)# interface cable c6/1/0Router(config-if)# hccp 1 protect 1 ip-address-of-mgmt-lanRouter(config-if)# hccp 1 track c6/1/1Router(config-if)# keepalive 3Router(config-if)# exitRouter(config)# interface cable c6/1/1Router(config-if)# hccp 2 protect 1 ip-address-of-mgmt-lanRouter(config-if)# hccp 2 track c6/1/0Router(config-if)# keepalive 3Router(config-if)#Related Commands
keepalive
A global configuration command that allows you to specify the keepalive message transmission interval on a Working CMTS or Protect CMTS. For more specific information, see the Cisco IOS Interface Command Reference on Cisco.com.
show hccp
Displays information for all cable interfaces on which one or more HCCP groups and authentication modes have been configured.
show hccp interface
Displays group information for a specific cable interface on which one or more groups and authentication modes have been configured.
hccp unlockout
To reverse the effects of the hccp lockout command—that is, to make a Working CMTS available for automatic switchover to Protect CMTS, use the hccp unlockout command in privileged EXEC mode.
hccp group unlockout member
Syntax Description
group
The group number for the specified interface. Valid values are any number from 1 to 255, inclusive.
member
The member number within the specified group.
Command Default
By default, the hccp unlockout command is active for all groups and members.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command reverses the effect of the hccp lockout command. Once you have reconfigured or tested your Protect CMTS, issuing this command manually reintroduces the CMTS back into your 1+1 redundancy protection scheme.
Note
Examples
The following example shows the lockout feature of a Working CMTS in group 1 being deactivated:
hccp 1 unlockoutRelated Commands
hccp working
To designate a cable interface on a CMTS in the specified group to be a Working CMTS, use the hccp working command in cable interface configuration mode. To remove a Working CMTS assignment, use the no form of this command.
hccp group working member
no hccp group working member
Syntax Description
Command Default
No default behavior or values
Command Modes
Interface configuration (cable interface only)
Command History
Usage Guidelines
When N+1 HCCP redundancy is configured, the Protect interface switches over and becomes the active interface when it detects a situation similar to the following:
•
•
•
•
The Protect cable interface must be configured identically to the Working cable interface, which typically means the interfaces should be the same card type. However, when the Cisco uBR-MC16S is used, it can be used with either another Cisco uBR-MC16S card or a Cisco uBR-MC16C card.
Table 22 shows how a switchover affects the enhanced spectrum management features of the Cisco uBR-MC16S card.
Examples
The following example shows cable interface 4/0 being designated as a Working CMTS interface as member number 2 of group 2:
Router(config)# interface cable 4/0Router(config-if)# hccp 2 working 2Related Commands
hold-queue
To limit the size of the IP output queue on an interface, use the hold-queue command in interface configuration mode. To restore the default values, use the no form of this command.
hold-queue length {in | out}
no hold-queue {in | out}
Syntax Description
Defaults
Input hold-queue limit is 75 packets.
Output hold-queue limit is 40 packets.
Asynchronous interfaces default is 10 packets.Command Modes
Interface configuration (config-if)
Command History
Usage Guidelines
Defaults
The default limits or this command prevent a malfunctioning interface from consuming an excessive amount of memory. There is no fixed upper limit to a queue size.
Back-to-Back Routing Updates
The default of 10 packets allows the Cisco IOS software to queue a number of back-to-back routing updates. This is the default for asynchronous interfaces only; other media types have different defaults.
Hold Queues and Priority Queueing
•
•
•
•
•
•
Caution
This is generally better than having duplicate copies of the same packet within the network (which can happen with large hold queues).
Examples
The following example shows how to set a small input queue on a slow serial line:
Router(config)# interface serial 0Router(config-if)# hold-queue 30 inCisco uBR10012 Universal Broadband Router
The following example shows how to modify the input hold queue on a Gigabit Ethernet SPA:
Router# configure terminalRouter(config)#interface GigabitEthernet3/0/0Router(config-if)#hold-queue 30 inRelated Commands
priority-list
Establishes queueing priorities based on the protocol type.
show interfaces
Displays statistics for all interfaces configured on the router or access server.
hw-module bay reload
To reload the software and restart a SPA, use the hw-module bay reload command in privileged EXEC mode.
Cisco IOS Releases 12.3(23)BC and 12.2(33)SCA
hw-module bay slot/subslot/bay reload
Cisco IOS Release 12.2(33)SCB
hw-module bay slot/bay/port reload
Syntax Description
Command Default
No default behavior or values
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
The hw-module bay reload command reloads the software and restarts a SPA.
Examples
The following example shows how to reload the software for the Cisco Wideband SPA in slot 1, subslot 0, and bay 1.
Router# hw-module bay 1/0/1 reloadRouter#Related Commands
hw-module sec-cpu reset
To reset and reload the standby Route Switch Processor (RSP) with the specified Cisco IOS image and to execute the image, use the hw-module sec-cpu reset command in privileged EXEC mode.
hw-module sec-cpu reset
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Before using this command, you must use the hw-module slot image global configuration command to specify a high availability Cisco IOS image to run on the standby RSP. After the high availability image is loaded in the active RSP, use the hw-module sec-cpu reset command to reset and reload the standby RSP with the specified Cisco IOS image and to execute the image. To load the standby RSP with the default micro-IOS software contained in the active RSP image instead of a high availability Cisco IOS image, use the no form of the hw-module slot image command followed by the hw-module sec-cpu reset command.
Examples
The following example shows a Cisco 7513 router with the standby RSP loaded in slot 7. The standby RSP is reset and reloaded with the rsp-pv-mz high availability Cisco IOS image. Both RSPs have slot 0 flash memory cards.
Router(config)# hw-module slot 7 image slot0:rsp-pv-mzRouter(config)# endRouter# hw-module sec-cpu resetRelated Commands
hw-module slot image
Specifies a high availability Cisco IOS image to run on an active or standby RSP.
hw-module shutdown (ubr10012)
To shut down a particular Performance Routing Engine (PRE1) module, line card, Wideband SIP or Wideband SPA, use the hw-module shutdown (ubr10012) command in global configuration mode. To activate a specific PRE1, line card, Wideband SIP or Wideband SPA, use the no form of this command.
hw-module {main-cpu | pre {A|B} | sec-cpu | slot slot-number | subslot slot/subslot|
bay slot/subslot/bay} shutdown [unpowered]no hw-module {main-cpu | pre {A|B} | sec-cpu | slot slot-number | subslot slot/subslot |
bay slot/subslot/bay} shutdownSyntax Description
Command Default
No default behavior or values
Command Modes
Global configuration
Command History
12.2(4)XF
This command was introduced for the Cisco uBR10012 router.
12.3(21)BC
Support was added for the Cisco Wideband SIP and Cisco 1-Gbps Wideband SPA.
Usage Guidelines
The hw-module shutdown (ubr10012) command shuts down in a controlled manner a particular Performance Routing Engine (PRE1) module, line card, Wideband SIP or Wideband SPA. To activate a specific PRE1, line card, Wideband SIP, or Wideband SPA, use the no form of this command.
Caution
Examples
The following example shows the standby PRE1 module being shut down:
Router(config)# hw-module sec-cpu shutdownRouter(config)#The following example shows the active PRE1 module being shut down (which will trigger a switchover to the standby PRE1 module):
Router(config)# hw-module main-cpu shutdownRouter(config)#The following example shows the PRE1 module in PRE1 slot B being shut down:
Router(config)# hw-module pre B shutdownRouter(config)#
Note
The following example shows how to deactivate and verify deactivation for the Cisco Wideband SPA located in slot 1, subslot 0, bay 0. In the output of the show hw-module bay oir command, notice the "admin down" in the Operational Status field.
Router# configure terminalRouter(config)# hw-module bay 1/0/0 shutdown unpowered%SPAWBCMTS-4-SFP_MISSING: Wideband-Cable 1/0/0, 1000BASE-SX SFP missing from port 0%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:1, changed state to down%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:2, changed state to down%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:3, changed state to down%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:4, changed state to down%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:5, changed state to down%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:6, changed state to down%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:7, changed state to down%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:8, changed state to down%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:9, changed state to down%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:10, changed state to down%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:11, changed state to down...Router# show hw-module bay 1/0/0 oirModule Model Operational Status-------------- ------------------ -------------------------bay 1/0/0 SPA-24XDS-SFP admin downThe following example shows how to activate and verify activation for the Cisco Wideband SPA located in slot 1, subslot 0, bay 0. In the output of the show hw-module bay oir command, notice the "ok" in the Operational Status field.
Router# configure terminalRouter(config)# no hw-module bay 1/0/0 shutdown%SPAWBCMTS-4-SFP_OK: Wideband-Cable 1/0/0, 1000BASE-SX SFP inserted in port 0%SPAWBCMTS-4-SFP_LINK_OK: Wideband-Cable 1/0/0, port 0 link changed state to up%SNMP-5-LINK_UP: LinkUp:Interface Wideband-Cable1/0/0:0 changed state to up%LINK-3-UPDOWN: Interface Cable1/0/0:0, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:1, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:2, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:3, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:4, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:5, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:6, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:7, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:8, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:9, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:10, changed state to up%LINK-3-UPDOWN: Interface Wideband-Cable1/0/0:11, changed state to up%LINEPROTO-5-UPDOWN: Line protocol on Interface Wideband-Cable1/0/0:0, changed state to up...Router# show hw-module bay 1/0/0 oirModule Model Operational Status-------------- ------------------ -------------------------bay 1/0/0 SPA-24XDS-SFP okRelated Commands
hw-module slot pos
To configure a line card slot for Packet over SONET (POS) operation, use the hw-module slot pos command in privileged EXEC mode. To remove the configuration for a line card slot, use the no form of this command.
hw-module slot slot-number pos
no hw-module slot slot-number pos
Syntax Description
slot-number
Resets the line cards that are physically present in the specified slot-number (valid range is 1 to 8).
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
12.2(11)BC3
This command was introduced for the Cisco uBR10012 OC-48 Dynamic Packet Transport (DPT) Interface Module for the Cisco uBR10012 router.
Usage Guidelines
You must first use the hw-module slot pos command to preconfigure a line card slot for POS operation of the Cisco uBR10012 OC-48 DPT card before you can configure the card with any further commands. You must also use the card 1oc48dpt/pos-1 command to configure the card slot for the proper card type.
Note
Examples
The following example shows the Cisco uBR10012 OC-48 DPT line card in slot 3 being configured for POS operation:
Router# hw-module slot 3 posRouter# card 3/0 1oc48dpt/pos-1The following example shows the Cisco uBR10012 OC-48 DPT line cards in slots 3 and 4 being reconfigured from SRP operation to POS operation:
Router# no hw-module slot 3 srpRouter# no hw-module slot 4 srpRouter# hw-module slot 3 posRouter# card 3/0 1oc48dpt/pos-1Router# hw-module slot 4 posRouter# card 4/0 1oc48dpt/pos-1Related Commands
hw-module slot srp
To configure a line card slot for Spatial Reuse Protocol (SRP) operation, use the hw-module slot srp command in privileged EXEC mode. To remove the configuration for a line card slot, use the no form of this command.
hw-module slot slot-number srp
no hw-module slot slot-number srp
Syntax Description
slot-number
Resets the line cards that are physically present in the specified slot-number (valid range is 1 to 8).
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
You must first use the hw-module slot srp command to preconfigure a line card slot for SRP operation of a pair of Cisco uBR10012 OC-48 DPT cards before you can configure the cards with any further commands. You must also use the card 1oc48dpt/pos-1 command to configure each card slot for the proper card type.
Tip
Note
Examples
The following example shows the Cisco uBR10012 OC-48 DPT line cards in slots 1 and 2 being configured for POS operation:
Router# hw-module slot 1 srpRouter# card 1/0 1oc48dpt/pos-1Router# card 2/0 1oc48dpt/pos-1The following example shows the Cisco uBR10012 OC-48 DPT line cards in slots 3 and 4 being reconfigured from POS operation to SRP operation:
Router# no hw-module slot 3 posRouter# no hw-module slot 4 posRouter# hw-module slot 3 srpRouter# card 3/0 1oc48dpt/pos-1Router# card 4/0 1oc48dpt/pos-1Related Commands
