Guest

Cisco uBR10000 Series Universal Broadband Routers

N+1 Solution for the uBR10012

Cisco - N+1 Solution for the uBR10012

Document ID: 47165

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:

  • uBR-RFSW RF Switch

  • uBR10012

The uBR100012 can be setup as one card protecting seven others. This helps with economics because it now provides 7+1 availability, and also passes necessary requirements for PacketCable.

Tip: The cabling side of all the units is considered the rear view. The reference design is to mount all the units flush to the front. The VCom upconverter only has mounting brackets on the front, but the uBR10K and RF Switch can be mounted flush from the front or rear.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

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 external design allows cabling migration and linecard swap-outs. If you want to upgrade from a 2x8 card to a 5x20 card, the linecard can be forced to failover to the protect mode. The linecard can be changed out at when you are ready to the newer, denser 5x20 card and wired up for future domains. The two domains that were in the protect mode will then be switched back to the corresponding interface/ domains on the 5x20 card. Other issues must be addressed, such as the 5x20 will have internal upconverters and may require new lines of code.

The reference design is wired with DS 0’s MAC domain on the left side of the top RF Switch’s header, and DS 1’s MAC domain on the right side of that same header. DSs 3 & 4 MAC domains are wired the same, however, in the bottom RF Switch. DS 2’s MAC domain is wired in ports E & L of both RF Switches, and port G of the bottom RF Switch for the DS. The color code is very important because the cable kits are pre-made for Cisco’s reference design for the uBR10K, 5x20 cards, and RF Switches. The 5x20 card install vertically in the uBR10K, so cables are cut to a specific length for wiring.

When the 5x20 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 red. 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 white. Be sure to wire the RF Switch header with four US on the left and four on the right. Put the DS red wire on the left in the second hole from the bottom. Put the DS white wire on the right side of the header next to the red.

The RF Switch can be operated in two separate modes, either as an 8+1 switch or as 2, 4+1 switches. In the case of the uBR10K with 5x20 cards, it operates in the 8+1 mode, but really as 7+1 because there are only eight linecards in the uBR10K, and one of those most be used as the protect card. Also, because 5x20 cards are used, 5 7+1 redundancy schemes are done on the MAC domain level.

warning Warning: DSs 0 & 1 are tied to the same JIB (ASIC), and will failover together. DSs 2 & 3 are tied to the same JIB, and will failover together. DS 4 is on its own JIB. If Hot Standby Connection-to-Connection Protocol (HCCP) is not configured on an interface that shares a JIB with another interface that is configured, it will not failover.

Cables

See 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
CMTS-to-Switch; CAB-RFSW520TIMM, 1-meter PN# 74-2983-01 or PN-7814515-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. The new output cable kit (74-2984-01) will contain 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.

uBR10012 with MC5x20 Cards

This list 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).

  • On-line insertion removal (OIR) of active line card.

  • Software CLI based commands.

  • Software crash of the active line card.

  • DS cabling failure via keepalive feature.

  • Resetting the line card.

  • Egress failure via tracking and keepalive features.

  • Power outage on working linecard.

A DS failure could be from a bad internal upconverter or cable between the uBR10K and 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 5x20 card is actually five 1x4 MAC domains, you can make switch groups based on MAC domains. A MAC domain is 1 DS and all its associated USs. These MAC domains will be user-configurable in the future, but are statically set at FCS as 1x4 MAC domains. The 5x20 card is labeled with USs 0-19 and DSs 0-4. DS 0 is associated with US 0-3, DS 1 is tied to USs 4-7, and so on. The configuration in the CMTS is still considered to be USs 0-3 regardless of which MAC domain. If you want to configure DS 4, US 17 would actually be considered US 1 since DS 4 uses USs 16-19 and 16 refers to US 0, and so on.

If you shut down the working interface, the protocol will initiate a failover via the configuration file. A failover is not initiated by US ports 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 linecard out of the chassis, disconnecting the downstream cable between the linecard and RF Switch, or some other software or hardware type fault on the card itself are all considered valid N+1 failover events.

On the uBR10K, you can use the linecard power down command, which cuts power to the line card, and thus causes a failure. The command is cable power off slot/card . For example, cable power off slot [5-8] Card [0/1].

One interface will be designated as the protect interface, and all of the commands will be configured in that interface to backup all the interfaces in its group. If a linecard is removed, one or more MAC domains will be removed, and a protect card will be initiated to back it up. The configuration on the uBR10K will make the appropriate RF Switch relays to switchover.

warning Warning: 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.

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

warning Warning: The DS frequency in the uBR10K configuration does have an affect when doing N+1 redundancy. The internal upconverter needs to know the DS frequency or it will not activate.

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

The picture below is the uBR10K mock-up wired with the Belden cable with MCX-connectors and color-coded cable. Notice the cable lengths and the extra cable bracket for added support. The bracket makes it look more organized, and keeps the cables away from the fan outlet. 7+1 high availability provides protection for140 US ports and 35 DS ports. The special mini-coax and MCX connectors use less space than traditional coax and connectors, and the rugged Universal Cable Holder (UCH) can easily disconnect up to ten cables at once.

n1_config_ubr10012-A.gif

This setup uses one uBR10K and two RF Switches. Since this is really 7+1 redundancy, one of the eight working inputs on the RF Switch will be unused. This may be used for future wiring or testing purposes.

The picture below is the Cisco reference design shown from the rear view. Look closely at the cable color coding. If a power supply is needed to convert AC to –48 Vdc for the uBR10K, it is usually on the bottom. No gaps are required between the devices, because all air-flow is front-to-back and Network Equipment Business Systems (NEBS) compliant.

n1_config_ubr10012-B.gif

Interfaces 5/1/0 through 5/1/4 as are used as protect groups 1-5. 5/1/0 is protecting 8/1/0, 5/1/1 is protecting 8/1/1, and so on.

The picture below is of the entire setup. The cable kits are made with precise lengths of cabling for the upconverter, RF Switch, and 2x8 cards. Other racking techniques may be possible, but are not recommended.

n1_config_ubr10012-C.gif

The pictures below are of the new, dense connector for the 5x20 card. On the left is a 5x20 card wired up with RG-6 cable, Belden cable with F-connectors and two slots for the dense connector blades.

n1_config_ubr10012-D.gif

Even with the card wired up, the LEDs are still viewable. This will be much easier to service than 25 F-connectors on one linecard. This new dense connector will be very robust with strain relief, one-way insertion, and heavy construction.

The picture below shows the 5x20 cards wired up with the dense connectors and two RF Switches. The 5x20 cards have built-in upconverters and s-card capability for advanced spectrum management.

n1_config_ubr10012-E.gif

N+1 for uBR10012 with MC28C Cards

This section provides information on the setup, wiring, and configuration of the N+1 solution, according to Cisco’s recommended design, using the following components:

  • VCom HD4040 upconverter with an Secure Network Management Protocol (SNMP) module (HD4008)

  • uBR-RFSW RF Switch

  • uBR10012

RF Switch

The eight working inputs are numbered from left to right. The two protect are in the middle, and the eight outputs are on the right.

n1_config_ubr10012-F.gif

The picture below is the back view of the RF Switch with the 14-port header and special Belden mini-coax cable with MCX connectors.

n1_config_ubr10012-G.gif

The RF Switch in this picture was 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 10K, 2x8 cards, RF Switch, and HD4040.

The 2x8 cards install vertical in the 10K, so cables are cut to a specific length for wiring. The following color codes are used in order; 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 US on the left, and four on the right. Put the gray wire on the left in the second hole from the bottom. Put the brown wire on the right side of the header next to the gray.

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

n1_config_ubr10012-H.gif

The far two right upconverter modules have been disabled, and modules 9 and 10 have been enabled. All the RF Switch LEDS are amber/yellow, except the modules that were not used in the bitmaps, which is 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 Switch or as two 4+1 Switches. In the case of the uBR10K with 2x8 cards example, the RF Switch operates in the 8+1 mode, but really as 7+1 because there are only eight linecards in the uBR10K, and one of those must be used as a protect card. Also, because 2x8 cards are used, two 7+1 redundancy schemes are performed on the MAC domain level.

RF Switch Cabling

The input cable kit will work on the output if you use the two extra separate cables for the DS.

Input Cable Kit Part Numbers Quantity
47.5BKASFP/MCXFPWS943 1
18GYASFP/MCXFPWS940 1
18BRASFP/MCXFPWS940 1
MCXHEADERBK 1

Output Cable Kit Part Numbers Quantity
394BKASFP/MCXFPWS943 1
394GYASFP/MCXFPWS940 1
394BRASFP/MCXFPWS940 1
MCXHEADERBK 1
ASFP 13

It is recommended to keep MAC domains visibly separate, but not necessary. The headers are wired with one MAC domain on one side of the header, and the 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.

uBR10012 with MC28C Cards

Since the 2x8 card is really 2, 1x4 MAC domains, you can make switch groups based on MAC domains. A MAC domain is one DS and all its associated USs. A failover group can be considered a MAC domain, and a member would be associated with linecards.

warning Warning: Non-synched cable interface commands need to be pre-configured. These commands should be the same on all the members of an HCCP group.

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

This is a picture of the uBR10K wired up with the Belden cable with F-connectors and color-coded cable. Notice the cable lengths and the extra cable bracket for added support. It is not needed, but does make it look more organized and keeps the cables away from the fan outlet.

n1_config_ubr10012-I.gif

This sample layout is the Cisco reference design shown from the rear view. If a power supply is needed to convert AC to –48 Vdc for the uBR10K, it is usually on the bottom. No gaps are required between the devices because all air-flow is front-to-back and NEBS compliant.

n1_config_ubr10012-J.gif

Protect interface 5/1/0 is protecting 8/1/0 and 5/1/1 is protecting 8/1/1. Using Slot 5/1 for protect is easier for wiring since the protect header of the RF Switch is located in the center.

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, instead of taking one reverse and splitting it to feed two US ports before the Switch, do it after the Switch and before the CMTS.

This setup is uses one uBR10K, one RF Switch, and one HD4040 VCom upconverter. Since this is really 7+1 redundancy, one of the eight working inputs will be unused. This may be used for future wiring or testing purposes. This picture is a blow-up view of the color-coding for the upconverter and RF Switch.

n1_config_ubr10012-K.gif

This is a picture of the whole setup. The cable kits are made with precise lengths of cabling for the upconverter, RF Switch, and 2x8 cards. Other racking techniques may be possible, but not recommended.

n1_config_ubr10012-L.gif

To switch an entire header, which may hold one linecard, two MAC domains must switch when using the 2x8 cards. The best way is to issue the tracking command so that each interface points to each other. Issue the hccp 1 track c5/0/0 command on interface C5/0/1, and the hccp 1 track c5/0/1 command on interface C5/0/0.

HCCP Features

Timers

The cable interface command hccp g timers hellotime holdtime is used for inter-chassis communication. 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 intervals in milliseconds to check the sanity of the working chassis. If there is no hello-ACK for more than a time period equal to holdtime , then it is declared that the working chassis has failed and initiates a switchover. The holdtime has to be at least three times larger than the hellotime . The default is 5000 for hellotime and 15000 ms for holdtime . The max is 25000 ms. Since the uBR10K solution is entirely intra-HCCP, do not change this timer.

Tracking

By default, an HCCP interface tracks itself. When keepalive is enabled and it detects no incoming upstream packets, it will failover. The track command can also be used to track an uplink interface. For example, if working has a dedicated uplink (for example, GE) path and protect has its own, these uplink interfaces can be tracked. When one fails, the cable interface will failover to the standby. In the uBR10K solution, it seems that working and protect may share the same uplink, and the track command is not needed for this scenario.

To switch an entire linecard, five MAC domains must switch when using the 5x20 cards. One way is to issue the tracking command so that each interface points to each other. Issue the hccp g track c5/0/0 command on interface C5/0/1, and the hccp g track c5/0/1 command on interface C5/0/0. Another way would be to use the CLI command to switch the MAC domains when you must replace a linecard.

Keepalive

The purpose of the keepalive feature is to cover bad cabling between the CMTS and RF Switch. 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 USs belonging to one DS, 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 because 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 is one second.

It may be advantageous to issue the no keepalive command 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 effect all the US ports of a MAC domain, lockout that interface and its ASIC companion interface until the work is done. Also, issue the no hccp g revertive command on the associated protect interfaces that use keepalive as a failure mechanism.

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 reregister 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. This used to be set for every 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 15 seconds, the worst case scenario will give 15 seconds for a failover to occur before a T4 timeout on a modem.

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. Issuing the no reverttime command sets the command to the default of 30 minutes. To not revert, issue the no hccp g revertive command on the protect interface.

If you set the 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 best effort in double failure, and non-disruptive service is not guaranteed.

If the reverttime is too short, the user may not be able to fix the third party problem, and the protect will switch back if the working card is working correctly.

Note: Once the suspend time is over, any failure in the protect interface will switch back if the working interface is working correctly, no matter if the reverttime is over or not. If you OIR the protect card, the suspend time is bypassed, but 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 x/y command, then cable power on x/y.

You can issue the show hccp brief command to see how much time is left in the counter.

uBR # sh hccp brief 
Interface Config    Grp Mbr Status          WaitToResync    WaitToRestore
Ca5/0/0   Working   1   1   standby                         00:01:45.792
Ca5/1/0   Protect   1   1   active          00:00:45.788    00:01:45.788

After one minute, static sync takes place and the standby sync's up to the database of the active. If you use OIR or issue the hw-module reset command to trigger a failover, you may do so right after it finishes static sync.

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 the keepalive is off. Once the reverttime and two minute suspend time are up, it will go back to working if there is nothing wrong with the working card. You may choose not to revert to working by issuing the no hccp g 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 g switch m command once you feel comfortable switching back.

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

These commands must be preconfigured 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 15 BC code and above, however, 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 & BC code) will allow 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 after 12.2(8)BC2. It is recommended to use the default settings on the protect by issuing the cable map-advance dynamic 1000 1800 command.

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

Tip: After any configuration change on a working line card, the HCCP resync command hccp {group} resync {member} should be issued on that working card. This updates the protect with the new configuration and any subsequent switch-over will be successful. It is recommended to issue this command before any testing so that some of the DOCSIS tables are synced over to the protect when ready.

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

Testing Modems for Failover Capabilities

Complete these steps to test downstream SYNC loss duration for which a modem remains online:

  1. Telnet to the CLC console with 127.1.1.50 and enable it. 50 represents cable linecard slot 5/0 in this example. You can also type if-con if the server internal is invoked on the uBR10K.

  2. Issue the test cable synch delay msec command. This specifies the msec SYNC loss.

  3. From uBR10K Exec mode, issue the test cable atp cable interface for the modem under test> <mac-address of the modem mac 16 command.

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

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 should be looking for. Declare the test to fail if the ping session after the restart of SYNC fails.

Tip: Type Control + Alt or Shift+6 to stop the ping if necessary. An easier test would be to disconnect the cable to the modem for approximately five seconds, reconnect, and make sure that it does not restart.

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 555000000 Hz 
	“rfswitch" – 
module 1, normal   
	module 3, normal    
	module 5, normal   
	module 7, normal   
	module 11, normal 
Grp 2 Mbr 1 Working channel-switch: 
 	"uc" - enabled, frequency 555000000 Hz 
 	“rfswitch" – 
module 2, normal 
 	module 4, normal   
 	module 6, normal
 	module 9, normal 
 	module 13, normal 
Grp 1 Mbr 7 Protect channel-switch: 
	"uc" - disabled, frequency 555000000 Hz 
	“rfswitch" – 
module 1, normal
	module 3, normal
	module 5, normal
	module 7, normal
	module 11, normal
Grp 1 Mbr 5 Protect channel-switch:
	"uc" - disabled, frequency 555000000 Hz
	“rfswitch" – 
module 1, normal
	module 3, normal
	module 5, normal
	module 7, normal
	module 11, normal
show hccp brief
Interface Config    Grp Mbr Status          WaitToResync    WaitToRestore
Ca5/0/0   Working   1   1   standby                         00:01:45.792
Ca5/1/0   Protect   1   1   active          00:00:45.788    00:01:45.788
Each module should have a set of objectives.
show hccp detail
HCCP software version 3.0
Cable5/0/0 - Group 1 Working, enabled, forwarding
  authentication none
  hello time 5000 msec, hold time 15000 msec, revert time 120 min
  track interfaces: Cable5/0/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 172.18.73.170, working 172.18.73.170
    channel-switch "rfswitch" (rfswitch-group, 172.18.73.187/0xAA200000/8) 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 10.50.100.1 255.255.255.0
        ip address 24.51.24.1 255.255.255.0 secondary
        ip helper-address 172.18.73.16
        ip pim sparse-dense-mode
        cable helper-address 172.18.73.165
        cable arp, proxy-arp,
        cable ip-multicast-echo,
        cable dhcp-giaddr policy,
 

Testing and Troubleshooting Command Quick Lookup

Use these commands for the uBR10K.

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 these commands for the RF Switch.


test module
config card count{1-14}
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: 47165