Guest

Cable Modem Termination Systems (CMTS)

N+1 Solution for the uBR7200 with MC28C or MC16x Cards

Cisco - N+1 Solution for the uBR7200 with MC28C or MC16x Cards

Document ID: 47163

Updated: Oct 04, 2005

   Print

Introduction

This document provides information on the setup, wiring, and configuration of the N+1 solution according to Cisco’s recommended design. In addition to the wiring schemes, these components must be configured:

  • VCom HD4040 upconverter with an Simple Network Management Protocol (SNMP) module (HD4008) or non-SNMP upconverter

  • uBR-RFSW Radio Frequency (RF) Switch

  • uBR7200 VXR

The uBR7200 can be setup as one chassis with four cards protecting four other chassis. This helps with economics, because it provides 4+1 availability, and also passes necessary requirements for PacketCable. Technically, this will be four separate 4+1 scenarios on an interface level when using 1x6 cards, or eight separate scenarios when using 2x8 cards.

It is recommended to spread groups across uBRs, in the event that an entire uBR goes down. The goal is to have every card in a uBR protected if this happens. The uBR7200 started with Cisco IOS® 12.1EC for 1+1 redundancy for Data-over-Cable Service Interface Specifications (DOCSIS) 1.0 and 1.0+. N+1 for the uBR7200 for DOCSIS 1.0 and 1.1 is in 12.2(11)BC and later.

Tip: The cabling side is considered the front view on the uBR7200, but the rear view on the other equipment. The reference design is to mount all the units flush to the front except the RF Switch(es). The upconverter only has mounting brackets on the front, but the uBR7200 and RF Switch can be mounted flush from the front or rear. See the uBR7200 with MC28C or MC16x Cards section of this document for more information.

Prerequisites

Requirements

The reader of this document should have the basic understanding of the DOCSIS protocol, RF terms and concepts, and familiarity with the Cisco IOS command line and high availability.

Components Used

This document is restricted to specific use of Cisco IOS® 12.1EC or 12.2(11)BC and later on the uBR7246VXR.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

RF Switch

The reference design is wired with one MAC domain on one side of the header, and the other MAC domain of a 2x8 card on the other side of the same header. The color code is very important because the cable kits are pre-made for Cisco’s reference design for the uBR7200 2x8 cards, RF Switch, and HD4040. The 2x8 cards install horizontal in the uBR7200, so cables are cut to a specific length for wiring. The color codes in order are red, white, blue, green, yellow, purple, orange, black, gray, and brown.

When the 2x8 is wired up with this color scheme, USs 0, 1, 2, and 3 for the first MAC domain will be red, white, blue, and green, and the DS associated with it will be gray. USs 0, 1, 2, and 3 of the second MAC domain will be yellow, purple, orange, and black, and the DS associated with it will be brown. Be sure to wire the RF Switch header with four USs on the left, and four on the right. Put the gray wire on the left in the second hole from the bottom for the 3x10 RF Switch. Put the brown wire on the right side of the header next to the gray.

The picture below shows the upconverter and the RF Switch in protect mode.

n1_config_cards-A.gif

The far two right upconverter modules have been disabled, and modules 9 and 10 have been enabled. All of the RF Switch LEDS are amber/yellow, except the modules that were not used in the bitmaps, which are the 5th module down on the left, and the 5th and 7th modules on the right.

The RF Switch can be operated in two separate modes, either as an 8+1 RF Switch or as two 4+1 RF Switches. In the case of the uBR7200, 4+1 operation mode is used. In the future, the RF Switch may operate in 8+1 mode to have one protect chassis cover eight working chassis.

There is not much to program on the RF Switch itself, except an IP address and some group names with corresponding bitmaps to indicate which ports belong to specific groups. The default RF Switch mode is 8+1, and it will need to be changed to 4+1 mode.

The fail-over times are relative to the type of failure, amount of modems, and type of modems, however, they have been on the order of 3-8 seconds. The RF Switch relays are milliseconds, but to trigger a failure could be 3-5 seconds. It takes more time to restart data transfer on a modem because of the MAC tables that need to be refreshed, or reconvergence of routing between uBRs. The latest code has given precedence to modems doing Voice over IP (VoIP) traffic.

Cables

Refer to the table below for parts and part numbers.

Parts Part Numbers
Cisco Black header for N+1 switch PN# MCXHEADERBK
MCX fixed pin for field termination PN# MCXFP
F connector for field termination PN# ASFP
Crimper for MCXFP; .213 Hex crimp PN# C47-10120
Crimper for ASFP F connector; .270 Hex crimp PN# ACT-270 ~ $35
Stripper for MCXFP; .230 x .125 2-stage strip PN# CPT-7538-125
Stripper for ASFP; .250 x .250 2 stage strip PN# CPT-7538 ~ $35
MCX Jack to F Jack Adapter PN# 531-40137
Switch to 2x8 card cable kit. MCX to FP 47.5" PN# 74-2765-02
Switch to Plant side cabling kit MCXP to FP 10 m PN# 74-2961-01
Switch-to-Plant; CAB-RFSW520TPMF, 3-meter PN# 74-2984-01 or PN-78-147111-01

You can contact CablePrep at 1-800-394-4046, or visit their Web site at http://www.cableprep.com/ leavingcisco.com.

Cisco suggests getting the cable kits from WhiteSands for all inputs, protect, and outputs. WhiteSands Engineering can be reached at http://www.whitesandsengineering.com leavingcisco.com. There is a new output cable kit (74-2984-01) that contains two 3-meter cable bundles of 10, MCX to F, a 3-meter bundle of 5, and a bag of 25 extra F-connectors. The cables can be ordered from WhiteSands with female F-connectors also.

Tip: Test the connector and cabling continuity before crimping the connector. You may need to test through the RF Switch unless an adapter (531-40137) is used. Remember to test DS ports from upconverter output to RF Switch output, and test US ports from CMTS to RF Switch output. You do not have to install the cables in the header for testing purposes. You may want to use a full RF spectrum sweep from 5-70 MHz for US ports, and 50-870 MHz for DS ports.

Because the F-connector has its own pin, the Belden cable center conductor must be cut to a specific length (1/4 inch center conductor and 1/4 inch jacket removed) to connect correctly inside the special F-connector. The braid is then folded back and the bonded-foil dielectric is inserted into the mandrel of the F-connector. The center conductor is solid copper, so do not bend it for fear of potential failure. Start over with the cable preparation if need be.

It is recommended to keep MAC domains visibly separate, but not necessary. You can wire the headers with one MAC domain on one side of the header, and the other MAC domain of a 2x8 card on the other side of the same header. The MAC domain wiring must be the same in all the associated inputs, outputs, and protect that all belong to the same group. For 1x6 linecard wiring, use the same scheme above, but place the last two US ports on the right side of the header. This will make upgrading to a 2x8 card easier in the future.

Note: If doing US dense-mode combining on the uBR, you can do it at the Cable Modem Termination System (CMTS) interface, and save some US ports on the RF Switch. Cisco only supports a 3x10 and 2x12 DS-to-US configuration, but the RF Switch may be user configurable for different scenarios. It is possible to install an extra DS module in slot 14, and possibly use the DS modules in slots 11 & 12 as US modules. If so, you would have to install the proper modules. This would allow 4+1 redundancy using 1x6 linecards in the uBR7200s with only one RF Switch.

uBR7200 with MC28C or MC16x Cards

The list below indicates the situations that are tracked for failover initiation. These are considered the most prevalent issues that could allow modems to drop offline.

  • Shut down the active cable interface (works, but not supported).

  • Online Insertion Removal (OIR) of active line card.

  • Software CLI based commands (hccp g switch m ).

  • Software crash of the active line card.

  • DS cabling failure via keepalive feature.

  • Resetting the line card (hw-module slot x reset).

  • Egress failure via tracking and keepalive features.

  • Power outage on working linecard (cable power off x ).

In the future, Cisco may track the management information bases (MIBs) from the VCom upconverter to indicate when there is no Intermediate Frequency (IF) input or a module failure. At this time, Cisco tracks a DS failure via the keepalive feature. Cisco offers 2x8 and 1x6 linecards with internal upconverters, and spectrum management to help ease cabling and external upconverter reliance.

A DS failure could be from a bad upconverter or a faulty cable between the upconverter and the uBR7200 or the RF Switch. The keepalive feature tracks all communication on all the US ports of a particular MAC domain. When there is no communication, a failover will initiate, based on some user-configurable thresholds and timers. Since the 2x8 card is really two 1x4 MAC domains, you can make switch groups based on MAC domains. A MAC domain is 1 DS and all its associated USs.

If you shut down the DS signal, it will still generate its IF output, but the protocol will initiate a fail-over via the configuration file. A fail-over is not initiated by US interfaces being shut. Pulling an upstream cable from one port on a line card is not generally considered a valid event to cause an N+1 line card failover. It is essentially impossible to distinguish this from a disconnected attenuator in a fiber node or amplifier (used for operational maintenance). Pulling the card out of the chassis, disconnecting the downstream cable between the linecard and upconverter, disconnecting the upconverter module, disconnecting the output of the upconverter to the RF Switch, or some other software or hardware type fault on the card itself are all considered valid N+1 failover events.

Tip: It is not recommended to force a failover via shutting down the interface. It is best to issue the failover CLI command hccp {Group #} switch {Member id}. You can also use the line card power down command, which cuts power to the line card, and thus causes a failure. The command is cable power off slot , where slot is [3-6] .

One uBR will be designated as a protect uBR, and all the commands will be configured in that chassis to backup all the working members in its group and the upconverters that are relevant to it. If a line card is removed, one or more MAC domains will be removed and a protect card will be initiated to back it up. The configuration in the protect uBR will make the appropriate RF Switch relays switchover and also the associated upconverters to enable and disable.

Tip: Be sure to always review your configuration when updating IOS to the latest code. Make sure you configure the working interfaces before the protect interface(s).

warning Warning: The DS frequency in the uBR configuration does have an affect when doing N+1 redundancy. The external upconverter needs to know the DS frequency from the uBR configuration via SNMP when a fail-over occurs. If you leave it blank and a switch-over occurs, the protect upconverter module will change its frequency to a frequency that may be incorrect. It was originally only for informational purpose or for the cable downstream override feature when multiple DS frequencies are on the same plant.

The picture below shows the uBR7200 wired up with the Belden cable with F-connectors and color-coded cables.

n1_config_cards-B.gif

This sample layout is the Cisco reference design with MC28C linecards, two RF Switches, and three HD4040 UPxs shown from the front view. No gaps are required between the devices, but cable routing is easier with one rack unit (RU) of rack space between the two RF Switches and between the first RF Switch and uBR.

Cable bundles of eight are used for DSs per VXR with F-to-F connectors for linecard IF to UPx inputs. Cable bundles of eight are used with F-to-MCX for UPx output to the RF Switch. Cable bundles of ten are used for USs with the extras used for an MC28U upgrade in the future. The protect and all DS cables are cut to right with working USs cut to left.

The picture below shows two RF Switches being used with MC16x cards because the RF Switches are configured as 3x10 RF Switches. This sample layout uses five uBR7200s, two RF Switches, and two HD4040 VCom upconverters. This allows an easy migration to MC28U cards in the future.

Note: The cable color codes may not be relevant for your design.

n1_config_cards-C.gif

The picture below is a blow-up view of the color-coding for the upconverter and RF Switch when using 1x6 cards with two RF Switches.

n1_config_cards-D.gif

The picture below is the reference design using one RF Switch.

n1_config_cards-E.gif

Tip: If some US ports are combined for a dense-mode combining scenario, they could be combined at the CMTS to free up some US ports on the RF Switch. This means that instead of taking one reverse and splitting to feed two US ports before the RF Switch, do it after the RF Switch and before the CMTS.

Note: It is recommended to use a separate Ethernet port for SNMP traffic for Hot Standby Connection-to-Connection Protocol (HCCP) other than the backhaul port that is used for Internet traffic.

warning Warning: Bundled interfaces will fail-over as bundle and global commands need to be pre-configured on the protect uBR. Also, non-synched cable interface commands need to be pre-configured. These commands should be the same on all the members of an HCCP group. See the Non-Synchronized Commands section of this document for more information.

Timers

The cable interface command hccp {Group #} timers hellotime holdtime is for inter-chassis communication. The hellotime is the timer value of the periodic heartbeat message that HCCP exchanges between the chassis for N+1 redundancy. The protect chassis keeps sending the hello message at hellotime interval in milliseconds to check the sanity of the working chassis. If there is no helloAck for more than a time period equal to holdtime , then it is declared that the working has failed and initiates a switchover. The holdtime has to be at least three times larger than the hellotime . The default is 2000 for hello and 6000 ms for hold. The max is 25000 ms.

Tracking

By default, an HCCP interface tracks itself. When a keepalive is enabled and it detects no incoming upstream packets, it will fail-over. The track command can also be used to track an uplink interface. For example, if working has a dedicated uplink (for example, Gigabit Ethernet (GE)) path and protect has its own, these uplink interfaces can be tracked. When one fails, the cable interface will fail-over to the standby.

To switch an entire header, which may hold one linecard, two MAC domains must switch when using the 2x8 cards. Issue the track command so that each interface points to each other. Issue the hccp {Group #} track c3/0 command on interface C3/1, and hccp {Group #} track c3/1 on interface C3/0. Another way is to use interface bundling. Interfaces bundled will failover as a group, but not in the uBR10K.

Tip: Each working linecard can also track the Internet egress port, so if something happens to the backhaul adapter or connection, the whole chassis will failover. If using interface bundling for all four linecards, only the master needs to track the egress port. Set the keepalive to one second on the egress port.

KeepAlive

The purpose of this feature is to cover bad RF output from the upconverter or cabling between the RF Switch and CMTS. The way to detect an Hybrid Fiber-Coaxial (HFC) failure is to count incoming packets on all upstreams.

If within three keepalive periods there is no incoming packets (range requests/response, station maintenance, data, and so on) on all of the upstreams, the line protocol will be down, and HCCP assumes something is wrong in that channel and will switchover. Remember, if there is a real HFC problem, the switchover will occur, but will not do any good since it is still on the same bad HFC plant. This feature is meant to cover failures in components that are not common between the protect and working interfaces such as upconverters and certain cabling.

The keepalive feature is turned off by default on cable interfaces with older IOS, but is defaulted to a value of ten seconds in the newer code. Set the keepalive as low as possible, which would be one second, but only after the interface has stabilized.

It may be advantageous to issue no keepalive on the protect interfaces so that it does not fail back to the working interface if all the modems go offline.

Tip: If routine maintenance will be taking place in the cable plant (balancing amplifiers, and so on) and signal loss is eminent that will affect all the US ports of a MAC domain, lockout that interface until the work is done. If used in conjunction with IP cable interface bundling, then all associated interfaces in the bundle should be locked out as well.

Failover Times

DOCSIS 1.0 specifies 600 ms as DS sync loss, but it does not specify what the cable modem should do after sync loss. Most cable modems do not re-register immediately after sync loss.

Station maintenance for modems is one second per modem, until you get to 20 modems, then it is every 20 seconds when there are 20 or more modems in the MAC domain. Before 15BC1, this was 25 seconds. When HCCP is configured, the top number is 15 seconds for a higher probability of a successful failover. This is because of the T4 timer in modems that is set at 30 seconds. If a modem were to experience a failover right before its scheduled 20-second station maintenance, it would only have ten seconds left of its T4 timer. The failover could take slightly longer than this, and the modem would go offline. By making the station maintenance every 15 seconds, the worst case scenario will give 15 seconds for a failover to occur before a T4 timeout.

Reverttime

The reverttime is configured on working interfaces, and is for the protect to automatically revert back so that it has the capacity to serve another failure in case the user forgets to manually switch it back. The default is 30 minutes. Issue the no reverttime command to set the default of 30 minutes. To not revert, issue the command no hccp {Group #} revertive on the protect interface.

If you set reverttime to one minute in the working interface configuration, it still takes three minutes for the working to kick back in. There are two minutes of suspend time prior to reverttime. This suspend time is used to define a singular failure. Any two switchovers happening within this suspend time is considered double failure. HCCP is recommended in double failure, and non-disruptive service is not guaranteed. If the reverttime is too short, the user may not be able to fix a third-party problem, and the protect may switch back if the working card is operating correctly. Failures that occur because of keepalive faults do not revert back automatically.

Note: Once the suspend time is over, any failure on the protect interface will switch back if the working interface is operating correctly, no matter whether reverttime is over or not. If you OIR the protect card, the suspend time is bypassed, however, inserting the card will take two minutes to reboot. Another way to fail from protect back to working immediately would be to issue the cable power off slot command, then cable power on slot on the protect interface.

You can issue show hccp brief command to see how much time is left in the counter. Issue this command on the protect and working uBRs.

uBR # sh hccp brief 
Interface	Config    Grp Mbr Status          WaitToResync    WaitToRestore
C3/0   	Working   1   1   active                          00:01:45.792
C4/0   	Working   2   1   active          00:00:45.788    00:01:45.788

After one minute, static sync happens and the standby syncs up to the active. If you use shut/no-shut, OIR, or issue the hw-module reset command to trigger a failover, you may do so right after static sync is complete.

If you disconnect the DS from a working card, the protect will kick in properly after three keepalives have expired. A DS failure will not be tracked if keepalive is off. Once the reverttime and two minute suspend time are up, it will go back to the working if there is nothing wrong with the working card. You may choose not to revert to working by issuing the no hccp {Group #} revertive command on the protect interface. If you still allow the protect to revert, you may configure a larger revert time on the working interface (up to 65k minutes), and manually issue the hccp {Group #} switch {Member #} command when you want to switch back.

warning Warning: It has been observed that forcing a failover via a failed egress port or powering off the working chassis once the working egress port and/or working chassis are functional again, the protect switches back to the working, even though no revertive was configured on the protect. This may be considered a rare cause for a failover in the first place, and may not cause any issues, but it should be understood and explained.

Synchronized Commands

This is a list of interface commands that are synchronized between the protect interface and all of the working interfaces that are a part of its HCCP group.


[no] ip address <ip address> <subnet mask> [secondary]
[no] ip helper-address <address>
[no] ip vrf forwarding <vrf name>
[no] mac-address <mac address>
[no] interface <type><optional-whitespace><unit>
[no] cable arp
[no] cable proxy-arp
[no] cable ip-multicast-echo
[no] cable ip-broadcast-echo
[no] cable source-verify ["dhcp"]
[no] cable dhcp-giaddr [ policy | primary ]
[no] cable resolve-sid
[no] cable reset
cable dci-response 
   [ ignore | reject-permanent | reject-temporary | success ]
   [no] cable intercept {mac-addr} {dst-ip} {dst-port}
[no] cable downstream frequency <f>
[no] cable downstream channel-id <id>
[no] cable downstream rf-power <dbmv>
[no] cable downstream rf-shut
[no] cable insertion-interval <interval>
[no] cable insertion-interval automatic <min-interval> <max-interval>
[no] cable helper-address <ip-address> ["cable-modem" | "host"]
[no] bundle <n> [ master ]
[no] upstream <n> shutdown
[no] upstream <n> frequency <f>
[no] upstream <n> power-level <dbmv>
[no] upstream <n> concatenation
[no] upstream <n> minislot-size <2-128>
[no] upstream <n> fragmentation
[no] upstream <n> modulation-profile <1st-choice> [<2nd-choice>]
[no] upstream <n> channel-width <hz> <hz-opt2>
[no] ip access-group [<n>| <WORD>] [“in” | “out”]	
[no] cable spectrum-group <grp num>
[no] cable upstream <n> spectrum-group <grp num>
[no] cable upstream <n> hopping blind
[no] cab up<#> threshold cnr-profile1 <5-35> 
   cnr-profile2 <5-35> Corr-Fec <0-30> Uncorr-Fec <0-30>
[no] cable upstream <#> hop-priority 
   [frequency | modulation] [frequency | modulation | channel-width]
[no] ip pim sparse-dense-mode

Non-Synchronized Commands

In addition to all global commands, these commands must be pre-configured on the protect interface:


cable map-advance dynamic/static
cable downstream modulation [256qam | 64qam]
cable downstream interleave-depth [128|64|32|16|8]
[no] keepalive <0-32767>
power-adjust threshold, power-adjust continue, & power-adjust noise
tftp enforce (mark only)
shared secret
arp timeout
cable source-verify lease timer
ip policy route-map
load balance configs
no shut

All configurations will be synchronized in 15BC2 code and above, but DS modulation, annex mode, and interleave still need to be the same on all members of an HCCP group.

The newer IOS code (after 12.10 EC1 & 4BC code) allows the user to put in a hard-set number for dynamic and static map advance. Refer to Cable Map Advance (Dynamic or Static?) for a detailed explanation of this command. With this in mind, each interface could have a different map advance setting. If the working fails over to a protect with a different setting, the modems may have difficulty synchronizing maps. The initial maintenance time offsets of each modem will be synced over in IOS code 12.2(8)BC2 and later. It is recommended to use the default settings on the protect. Issue the cable map-advance dynamic 1000 1800 for the default settings.

warning Warning: When adding and removing configurations from live working line cards, the N+1 architecture cannot protect the new configuration until it is statically synched to the protect card. If a switch-over occurs before the static sync, the application, which was invoked by the new configuration, could have unpredictable behavior.

To prevent this, lockout the working line card by issuing the hccp {Group #} lockout {Member #} command, and configure the new commands. When finished, unlock the working card by issuing the hccp {Group #} unlockout {Member #} command. This forces an immediate static sync. Resyncs will take place automatically after leaving the cable interface config mode with the 12.2(11)BC1 IOS release and later.

Tip: Resyncs will take place automatically after leaving the cable interface configuration mode with the 12.2(11) BC1 IOS release and later. After any configuration change on a working line card, the hccp {group} resync {member} command should be issued on that working card, or exit from configuration mode so it is done automatically.

It is also possible to shut the protect interface until the configuration is completed, then issue the no shut command, however, you must wait one minute before a resync will take place. The problem with shutting the protect interface is there will be no protection for all the other interfaces it may be protecting while it is shut. The problem with lockout is that you may have to initiate it for all the interfaces.

Testing Modems for Failover Capabilities

Follow these steps to test downstream sync loss duration, for which a modem remains online.

  1. Issue the test cable synch delay msec command. This specifies the sync loss duration in milliseconds.

  2. From uBR7200 exec mode, issue the test cable atp mac 16 command.

The test cable atp mac 16 command pings the modem first, then stops the SYNC message for the specified duration, and restarts sending sync at 10 ms duration. It pings the modem again to check the connectivity. If this ping succeeds, the test is considered a success.

Please note that if the ping fails, the ATP test still continues, once the modem recovers. The final output ATP test pass is not an indication of what you need to verify. The test fails if the ping session after the restart of sync fails.

Follow these steps to test downstream carrier loss duration, for which a modem remains online.

  1. Issue the show cable modem command to verify if the given modem is online.

  2. While consoled in, establish a ping session from the uBR7200 to the cable modem.

  3. From a Telnet session with the uBR7200, issue the test hccp {group} {member} modem-test ds-signal name string of the upx mac-address of the modem duration in msec of carrier loss time command.

Check if the ping session continues after the completion of the test (success). If the ping session terminates, the test has failed. This test instructs the UPx to shut down for a specified amount of time.

Tip: Type Control+Alt or Shift+6 to stop the ping if necessary. Another easy way to test the cable modem is to pull the cable to the modem for ~6 seconds to see if it can handle DS loss that long.

HCCP Commands

HCCP Exec Commands

hccp 1 ?
  -bypass	Enter bypass operation
  -check      	Exit bypass operation
  -lockout    	Lockout switchover on teaching worker
  -resync     	Re-sync member's database
  -switch     	Switchover
  -unlockout  	Release lockout on teaching worker

HCCP Interface Commands

(config-if)#hccp 1 ?
–authentication	Authentication
–channel-switch	Specify channel switch
–protect         	Specify Protect interface
–revertive       	Specify revert operation on Protect interface
–reverttime      	Wait before revert switching takes place
–timers          	Specify “hello” & “hold” timers on Protect interface
–track           	Enable failover based on interface state
–working         	Specify Working interface

HCCP Debugs

debug hccp ?
authentication          Authentication
channel-switch          Channel switch
events                  Events
inter-db                inter database
plane                   inter-plane communication
sync                    SYNC/LOG message
timing                  Timing Measurement

HCCP Show Commands

sh hccp ?
|                       Output modifiers
<1-255>                 Group number
brief                   Brief output
channel-switch          Channel switch summary
detail                  Detail output
interface               Per interface summary
show hccp channel-switch
     Grp 1 Mbr 1 Working channel-switch:
             "uc" - enabled, frequency 453000000 Hz 
             “rfswitch" – 
             module 2, normal   
             module 6, normal    
             module 10, normal   
             module 14, normal
             module 18, normal
             module 22, normal
             module 26, normal
      Grp 1 Mbr 2 Working channel-switch: 
             "uc" - enabled, frequency 453000000 Hz 
             “rfswitch" – 
             module 4, normal 
             module 8, normal   
             module 12, normal
             module 16, normal 
             module 20, normal   
             module 24, normal
             module 28, normal
     uBR7246P#sh hccp channel-switch
     Grp 1 Mbr 1 Protect channel-switch: 
             "uc" - disabled, frequency 453000000 Hz 
             “rfswitch" – 
             module 2, normal   
             module 6, normal    
             module 10, normal   
             module 14, normal
             module 18, normal
             module 22, normal
             module 26, normal
      Grp 1 Mbr 2 Protect channel-switch:
             "uc" - disabled, frequency 453000000 Hz
             “rfswitch" – 
             module 4, normal 
             module 8, normal   
             module 12, normal
             module 16, normal 
             module 20, normal   
             module 24, normal
             module 28, normal
show hccp brief
     Interface Config  Grp Mbr Status          WaitToResync    WaitToRestore
     Ca3/0   Working   1   1   active                          00:01:45.792
     Ca4/0   Working   2   1   active
     Each module should have a set of objectives.
show hccp detail
     HCCP software version 3.0
     Cable3/0 - Group 1 Working, enabled, forwarding
       authentication none
       hello time 2000 msec, hold time 6000 msec, revert time 120 min
       track interfaces: Cable3/0
       sync time 1000 msec, suspend time 120000 msec
       switch time 240000 msec retries 5
       local state is Teach, tran 80
       in sync, out staticsync, start static sync in never
       last switch reason is internal
       data plane directly sends sync packets
       statistics:
         standby_to_active 5, active_to_standby 4
         active_to_active 0, standby_to_standby 0
       Member 1 active
         target ip address: protect 192.168.1.7, working 192.168.1.5
         channel-switch "uc" (wavecom-hd, 192.168.1.2/1, 192.168.1.2/16) enabled
         channel-switch "rfswitch" (rfswitch-group, 192.168.1.4/0xAA880800/1) enabled
         tran #: SYNC 72, last SYNC_ACK 4, last HELLO_ACK 5790
         hold timer expires in 00:00:11.532
         interface config:
             mac-address 0005.00e1.9908
         cmts config:
             bundle 1 master, resolve sid, dci-response success,
             downstream - frequency 453000000, channel id 0
             downstream - insertion_invl auto min = 25, max = 500
             upstream 0 - frequency 24000000, power level 0
             upstream 0 - modulation-profile 2, channel-width 3200000 

     
!--- Minislot does not show up, but it is synchronized.

             upstream 0 - cnr-profile1 25, cnr-profile2 15
                          corr-fec 1, uncorr-fec 1
             upstream 0 - hop-priority frequency modulation channel-width
         sub-interface master config:
             ip address 192.168.2.5 255.255.255.0
             ip address 24.51.24.1 255.255.255.0 secondary
             ip pim sparse-dense-mode
             cable helper-address 192.168.2.165
             cable arp, proxy-arp,
             cable ip-multicast-echo,
             cable dhcp-giaddr policy,
uBR7246P#sh hccp 1 1 ?
H.H.H                 MAC address
channel-switch        Channel switch summary
host                  Host information
modem                 Cable Modem information
qosparam              Qos Parameter information
service-flow          Service Flow information
sid                   SID information
uBR7246P#sh hccp 1 1 modem 

!--- This is used to see the modem inter-database on the protect uBR.

Cable3/0:
MAC Address    IP Address      MAC      Prim   Timing Num  BPI   Prio
                               State    Sid    Offset CPEs Enbld
0090.837c.0acb 192.168.3.1     online      6    1243   0    no    4
0090.837c.0ac9 192.168.3.2     online      7    1243   0    no    2
0000.39d7.004a 192.168.3.3     online      9    1667   0    no    0
0090.8336.030d 192.168.3.6     online      11   1242   0    no    1

Testing and Troubleshooting Command Quick Lookup

Use the commands below for the uBR7200.

test hccp {Group #}{Worker's member id} channel-switch {name} snmp/front-panel
test hccp {Group #}{Worker's member id}{working/protect }fault 1 (simulates an Iron bus fault)
test hccp {Group #}{Worker's member id}{working/protect} failover
test hccp {Group #}{Worker's member id} modem-test ds-signal{name}{mac-addr}{msec}
test cable synch delay {msec delay}
test cable atp {CMTS interface}{mac-addr} mac {test_id}
show hccp; show hccp (brief ; detail; channel-switch)
show ip interface brief; show hccp{Group #}{Worker's member id} modem
hccp {Group #} switch; lockout; resync {Worker's member id}
hw-module {slot}/{subslot} reset
debug hccp authentication; channel-switch; events; plane; sync; timing          

Use the commands below for the RF Switch.


test module
config card count{1-14} 

!--- Removed in 3.3 RF Switch firmware.


sh conf or sh cf
sh mod all
sh dhcp
sh ip
sh switch status {mod #} or sh sw st {mod #}
switch {mod #}{slot #}
switch {group name}{slot #}
switch {group name} 0

Related Information

Updated: Oct 04, 2005
Document ID: 47163