Troubleshooting

The ALARM light comes on within 5 seconds, flashes for half a second, then goes off.
Between 1 and 10 seconds after the ALARM light goes off, the WAN-LNK light starts blinking, indicating that the CPE is attempting to establish communication with the central office equipment. After communication is established, the WAN-LNK becomes solid.

So under normal conditions, the ALARM light should be off within six seconds of powering up the CPE, and within one minute the WAN-LNK light should become solid.

If the CPE cannot establish communication with the service provider equipment, the WAN-LNK light will go off and the CPE will wait 10 seconds. The WAN-LNK light will start blinking when the CPE tries again to establish communication.

If, after repeated attempts to establish communication, the WAN-LNK light continues blinking, turn the power off and then on. If the WAN-LNK light still does not become solid within one minute, call your service representative.

If the ALARM light flashes RED or lights RED and stays on, call your service representative.

Note With the POWER light ON, the WAN-LNK light may appear OFF under certain circumstances, even though the CPE is operating correctly. This condition can occur, for instance, if there is no data traffic across the WAN-LNK for two minutes or more. In this case, the PPP session will time out and the WAN-LNK light will go off. During subsequent requests for data across the link, the WAN-LNK light should start to blink, indicating that the ADSL or SDSL connection sequence has started.

Web Interface Password Lengths

Web interface passwords can be from 1 to 7 characters in length.

Web Browser Compatibility

Netscape 3.01 or higher or Internet Explorer 3.01 or higher is recommended for use as a browser for the Cisco Web Management Interface.

Serial Buffer Overflow

When using the serial port as your terminal connection, large amounts of serial data might overflow the serial buffer. This results in ASCII garbage appearing on the screen, but does not affect performance or operation in any way. To avoid this issue, use Telnet to manage the CPE.

RADIUS Password and Username Lengths

The Cisco 600 series CPE supports RADIUS passwords with more than 16 characters, however, RADIUS servers only support 16 characters or less. RADIUS usernames can be up to 255 characters. Refer to the "RADIUS Client" section.

Computers Running Linux Without term/termcap

Computers running Linux without the term/termcap database installed will have trouble connecting to Cisco equipment. The message "BAD ADDRESS" is sometimes displayed as an error message. The term/termcap database can be installed from the Linux install disks or CD-ROM.

Clearing PC Cache with ARP

If you update IP addresses on many Cisco 600 series CPEs in rapid succession using a Windows PC, the ARP cache on the PC might not clear right away. This causes communications problems with the subsequent CPEs in the line. Use the arp -a command to obtain the current ARP list, then update the entries. For example, to clear the PC cache, use the following command at the MS-DOS prompt on your PC:

c:\> arp -d 192.168.0.100

This deletes the MAC address and causes IP to send an ARP request (or packet) to the IP address 192.168.0.100. The ARP utility comes with Windows 95, Windows 98, and Windows NT, so if you don't have it in your current installation, you can install it from your original Windows install media.

RIP and Idle Timeouts

On a busy network with many RIP broadcasts and requests, RIP traffic alone can cause the Cisco 600 series CPE to remain sufficiently active to not trigger the idle timeout. Cisco recommends that RIP be disabled if Cisco 600 series CPE idle timeouts are used.

ADSL Parameters for the set interface command

The set interface wan0 command supports these parameters:

baud []	Allows the ADSL line rate to train at the highest rate possible.
looptimeout[]	Enter a time for the length of time in seconds required for a faulty line to cause a retrain event.
overhead-framing mode-number	Configures the requested ATM framing structure. The Cisco 600 series CPE supports ATM overhead framing mode 3. A retrain is required to negotiate the new overhead framing mode with the central office equipment. This parameter only applies to DMT Issue 2 encoding. This command can be saved in NVRAM.
stay	Sets stay-trained mode. ADSL line will not retrain.
trellis-coding {enabled \| disabled}	Configures the device to request trellis coding on the wan0 interface. Trellis coding can be enabled or disabled. A retrain is required to negotiate trellis coding with central office equipment. Trellis coding must also be enabled on the DSLAM for it to be enabled. This parameter only applies to DMT Issue 2 encoding. This command can be saved in NVRAM. Note Do not enable trellis coding on the Cisco 677.

Frequently Asked Questions about the WAN LNK LED

The WAN LNK LED blink patterns indicate the connection state of the CPE.

Table 6-1: WAN Link LED Blink Patterns

Blink Pattern/Rate	Description
Steady ON	A link is established to the WAN port. All parameters for physical and logical connections are correctly set. The CPE successfully transmits and receives data.
Continuous rapid blinking, about 3 blinks per second	The CPE is trying to establish a connection. The pattern continues until a connection is established.
Intermittent blinking. For the Cisco 675: 6 rapid blinks followed by a 2-second pause before repeating. For the Cisco 676 or 677: 5 rapid blinks followed by a 2-second pause before repeating.	The CPE is trying to establish a physical connection. At this time, the training session is not yet completed; there are no logical connections and negotiated line conditions with other equipment (such as DSLAMs) are not yet established.
OFF	Check all connections. Ensure the WAN0 interface is not disabled.

This list describes all known conditions indicated by the WAN LNK LED:

If the WAN LNK LED blinks continuously and never stays solid on, the Cisco 600 series CPE never trains to a system such as the Cisco 6xxx series:
If the CPE trains up and the WAN LNK LED turns off after approximately 105 seconds when the CPE is in routing mode, this means that the CPE PPP requests are not getting answered by the equipment on the service provider's network, such as a Cisco 7200 series or Cisco 6400. It takes 105 seconds for three PPP requests to be sent from the CPE, and if they are not answered by the service provider's equipment, the CPE stops sending them and the WAN LNK LED turns off.

: There are a number of possibilities why this would happen:

VPI/VCI provisioning is not correct in the ATM cloud. This could signify that the service provider's equipment or the ATM switch along the path does not have the correct provisioning.

VPI/VCI mapping in the service provider's equipment or the CPE is not configured properly.

ATM Cell scrambling is enabled on one end of the link but not the other. The show running command will display an entry with "ATM WAN Cell Scrambling = disabled" if cell scrambling is disabled. No entry implies the default behavior of ATM cell scrambling is enabled.

Service provider's equipment is powered off.

CPE is configured for routing mode, but the equipment at the service provider's network that is terminating CPE traffic is configured for bridging.
: Use the show errors command to check the contents of the error log.

If the CPE trains up and the WAN LNK LED turns off, this is a sign of no ATM cell delineation.Verify that you have the ATM link terminated at the central office end. Without ATM cell delineation , the router will attempt to retrain the line in 1 to 10 seconds.
If the CPE trains up and then immediately drops the connection, the near-end DMT firmware might not be compatible with the far-end DMT firmware . For example, an ITU G.Lite router might not train to an ANSI Issue 1 Central Office. To see the DMT firmware version installed on your router, use the show version command.
If the WAN LNK LED turns off after the CPE has successfully been transferring data end-to-end for some time, this means that the CPE or the service provider's equipment might have a timeout set. Use the show errors command to see if the error log shows that timeouts caused the drop. There are two timeouts that could affect the WAN LNK LED:
- IDLE timeout—This timeout can be set on the CPE or the service provider's equipment. If the IDLE timeout is set to some value, then the CPE WAN LNK LED will turn off if the CPE becomes idle for that specified period of time. The show timeout command will display the current timeout status and settings.
- SESSION timeout—This timeout can be set on the CPE or the service provider's equipment. If the SESSION timeout is set to some value, then the CPE WAN LNK LED will turn off after that certain period of set time whether it is idle or not. The show timeout command will display the current timeout status and settings.
If the WAN LNK LED goes solid for approximately four seconds and then turns off, this primarily points to a RADIUS problem. After the CPE trains and the service provider's equipment that is being used to authenticate its PPP session is using RADIUS, then this could point to a failed RADIUS authentication. Possible reasons for a failed RADIUS authentication include:

: Disabling RADIUS on the service provider's equipment would be a simple test to see if it is a RADIUS problem.

The show interface wan0 command provides feedback on the wan0 configuration as well as the actual configuration negotiated with the central office equipment as shown here:

cbos#show interface wan0
wan0   ADSL Physical Port
       Line Trained
Actual Configuration:
  Overhead Framing:          3
  Trellis Coding:            Disabled
  Standard Compliance:       T1.413
  Downstream Data Rate:      8032 Kbps
  Upstream Data Rate:        864 Kbps
  Interleave S Downstream:   1
  Interleave D Downstream:   64
  Interleave R Downstream:   2
  Interleave S Upstream:     4
  Interleave D Upstream:     8
  Interleave R Upstream:     16
  Modem Microcode:           G96
  DSP version:               0
  Operating State:           Showtime/Data Mode
Configured:
  Echo Cancellation:         Disabled
  Overhead Framing:          3
  Coding Gain:               Auto
  TX Power Attenuation:      0dB
  Trellis Coding:            Enabled
  Bit Swapping:              Disabled
  Standard Compliance:       Multimode
  Remote Standard Compliance:T1.413
  Tx Start Bin:              0x6
  Tx End Bin:                0x1f
  Data Interface:            Utopia L1
Status:
  Local SNR Margin:          3.5dB
  Local Coding Gain:         0.0dB
  Local Transmit Power:      12.5dB
  Local Attenuation:         28.5dB
  Remote Attenuation:        18.5dB
Local Counters:
  Interleaved RS Corrected Bytes:        0
  Interleaved Symbols with CRC Errors:   2
  No Cell Delineation Interleaved:       0
  Out of Cell Delineation Interleaved:   0
  Header Error Check Counter Interleaved:0
  Count of Severely Errored Frames:      0
  Count of Loss of Signal Frames:        0
Remote Counters:
  Interleaved RS Corrected Bytes:        0
  Interleaved Symbols with CRC Errors:   0
  No Cell Delineation Interleaved:       0
  Header Error Check Counter Interleaved:0
  Count of Severely Errored Frames:      0
  Count of Loss of Signal Frames:        0

You can also use the show interface wan0-0 command to display the status of the virtual circuit:

cbos#show int wan0-0
WAN0-0  ATM Logical Port
        PVC (VPI 1, VCI 1) is open.
        ScalaRate set to Auto
        AAL 5         UBR Traffic
        PPP LCP State: Starting
        PPP NCP State (IP Routing): Starting
        PPP MRU: 2048    HDLC Framing: enabled    MPOA Mode: VC Mux
        PPP Login: ppp1
        Authentication Type: Autodetecting/PAP
        RADIUS: disabled
        PPP Tx: 0                Rx: 60742
        Dest IP: 205.142.210.1
        Dest Mask: 255.255.255.255
        IP Port Enabled

For PPP problems, use the show ppp command to display a summary of each virtual circuit for PPP mode. Check that the state of each virtual circuit is opened.

cbos#show ppp
VC       VPI/VCI  STATE       MRU    USERNAME  RADIUS   TX       RX
wan0-0   01/01   Starting     2048   ppp1      disabled 0        60742
wan0-1   01/02   Starting     2048   ppp2      disabled 0        59950
wan0-2   01/03   Starting     2048   ppp3      disabled 1476     738
wan0-3   01/00   Starting     2048   ppp4      disabled 0        59822

BERT Testing (Cisco 675, Cisco 675e and Cisco 676 only)

This section describes BERT tests using a Cisco 6100 DSLAM, Cisco 675, Cisco 675e, or Cisco 676, and an optional HP Broadband test set.

HP Test Set Configuration

All tests are based on the single cell version of S-PRBS9. This is the only PRBS pattern that is supported by the HP for generating multiple channels of cell load. All cells will have the same data, therefore it is necessary to have a cell sequence number to verify cell loss. This is done using AAL1.

Cells are generated by the HP and terminated by the Cisco 675s in the downstream direction, and vice versa for the upstream direction. The HP can only check BERT data on one channel at a time. It is therefore necessary to manually walk through every channel to verify data integrity. The BERT test can be performed without the HP test set if the Cisco 6100 NIU is physically looped back at the OC3 port.

Transmitting BERT Data

The following are the procedures for transmitting BERT data. Note that all pertinent tests will be initiated from the Optical Line Interface Card, and not a Cell Processor.

Step 1 Configure the load generator (truck icon) to send S-PRBS9 data to each CPE on VPI X / VCI X. Starting with channel 2 on the load generator, set up a connection using VPI 1 / VCI 32. Continue with channel 3 as VPI 1 / VCI 33 and so on until the number of channels that need to be tested are accounted for.

Step 2 Set the contents of each cell to S-PRBS9 with AAL1 enabled. All channels can be done at once by highlighting all of the channels and then setting the contents. AAL1 provides sequence numbers to determine if cells are being dropped.

Step 3 Set the bandwidth to the desired downstream rate. Again, all channels can be highlighted and changed simultaneously. This rate should be slightly lower than the trained rate (for example, 1.4M).

Step 4 Configure the Cisco 6100 or Cisco 6260 to set up connections from the NIs OC3 to the CPEs. Use the same connection parameters (VPI/VCI) that were used to configure the load generator.

Step 5 Verify that no other cell generation sources are active on the HP and that the laser is turned on.

Step 6 Compile the load generator and data will start flowing to the NI, through the Cisco 6100 or Cisco 6260 and out to the CPEs. Every time a parameter is changed in the load generator, it is necessary to compile for the change to take effect.

Step 7 The CPE should now be receiving BERT data.

Receiving BERT Data

After the CPEs have been BERT enabled, they will send S-PRBS9 BERT data toward the Cisco 6100 or Cisco 6260. The HP can verify the BERT data one channel at a time. Follow this procedure to receive BERT data:

Step 1 Select the receive filter from the Optical Line Interface Card and not the Cell Processor Card. This is the net/strainer icon.

Step 2 Specify the VPI and VCI that needs to be checked. The receive filter mode should be Virtual Channel.

Step 3 Select S-PRBS9 and AAL1. Now, only the specified cells will make it to the statistics counters.

Step 4 Select the statistics icon (ones and zeros). Select View and ATM Statistics.

Step 5 Select Selected Cell Count, Bandwidth, Cell Loss, etc.

Step 6 Apply.

Step 7 Select measurements and start the counters.

This will give you the statistics for the cell currently selected in the receive filter. Repeat the above procedure to check other channels. The Cell Protocol Processors can be used to view incoming cells if desired.

Cisco 600 Series CPE Configuration

Configure the CPE to perform BERT testing:

Step 1 Log in to the CPE via Ethernet or serial port.

Step 2 Give access to the BERT commands:

cbos> enable debug commands

Step 3 Keep the CPEs from trying to retrain even though they do not see the CO equipment on the far end:

cbos#  ifconfig wan0 stay

Step 4 Initiate the BERT test:

cbos#  debug bert on

Step 5 Set the header bits of the outgoing cells and qualify the incoming cells.

Step 6 Enter: cbos# debug bert header 00100010

Note Note that these are the four bytes of header not including the calculated HEC byte. Ta ble 6-2 provides descriptions of the bit fields.

Example: VPI=1, VCI=1 (GFC=0, PTI=0, CLP=0) across the ADSL loop (see command line above).

Table 6-2: BERT Header Bit Map

5	2	1	0
GFC		VPI
VPI		VCI
VCI		VCI
VCI	PTI		CLP

Step 7 Display a count of the BERT errors and cell loss since the previous query:

cbos#  debug bert count

Step 8 Note that the two LEDs on the left of the CPE take on a new meaning during the BERT tests.

BERT SYNC LED—This is the LED at the left (WAN-ACT) and is illuminated once the PE detects a valid BERT pattern.
BERT ERROR LED—This is the second LED from the left (WAN-LNK) and is toggled whenever the CPE detects a BERT error.

During a successful BERT test, the LED at the left will be illuminated, and the second LED from the left will be solid (either off or on, but not blinking).

Table of Contents

Troubleshooting