H3C MSR Series User manual

H3C MSR Routers
Troubleshooting Guide
H3C MSR 810 routers (centralized devices)
H3C MSR 2600 routers (centralized devices)
H3C MSR 3600 routers (centralized devices)
H3C MSR 5600 routers (distributed devices)
Document version: 6W100-20200112
Copyright © 2020 New H3C Technologies Co., Ltd. All rights reserved.
No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New
H3C Technologies Co., Ltd.
Except for the trademarks of New H3C Technologies Co., Ltd., any trademarks that may be mentioned in this document are
the property of their respective owners.
The information in this document is subject to change without notice.

i
Contents
Introduction·····················································································1
General guidelines ·····················································································································1
Collecting log and operating information ·························································································1
Collecting common log messages···························································································2
Collecting diagnostic log messages ·······························································································4
Collecting operating statistics·································································································5
Contacting technical support ········································································································7
Troubleshooting Ethernet interfaces ·····················································7
Failure to ping the directly connected device····················································································7
Symptom ···························································································································7
Solution·····························································································································7
Failure to forward packets············································································································8
Symptom ···························································································································8
Solution·····························································································································8
Packet dropping ························································································································8
Symptom ···························································································································8
Solution·····························································································································8
Related commands ····················································································································9
Troubleshooting E1 and T1 interfaces ················································ 10
Common E1 and T1 interface issue troubleshooting methods···························································· 10
Troubleshooting the hardware······························································································ 10
Troubleshooting the cables·································································································· 10
Troubleshooting the configuration ························································································· 11
Troubleshooting the clocks ·································································································· 12
Troubleshooting the grounding ····························································································· 13
Troubleshooting through looping··························································································· 17
Troubleshooting E1/T1 interfaces ································································································ 18
Troubleshooting physical interface anomaly ············································································ 19
Data transmission anomaly ································································································· 19
Collecting information········································································································· 19
Troubleshooting IPsec·····································································20
Failure to negotiate IPsec SAs through IKE ··················································································· 20
Symptom ························································································································· 20
Solution··························································································································· 20
Related commands ·················································································································· 24
Troubleshooting PPPoE ·································································· 25
Authentication failure in PPPoE dialup·························································································· 25
Symptom ························································································································· 25
Solution··························································································································· 25
Related commands············································································································ 26

1
Introduction
This document provides information about troubleshooting common software and hardware
problems with H3C MSR routers.
The MSR5600 routers are distributed devices. All other router series are centralized devices.
General guidelines
IMPORTANT:
To prevent a problem from causing loss of configuration, save the configuration each time you finish
configuring a feature. For configuration recovery, regularly back up the configuration to a remote
server.
When you troubleshoot H3C MSR routers, follow these general guidelines:
•To help identify the cause of the problem, collect system and configuration information,
including:
{Symptom, time of failure, and configuration.
{Network topology information, including the network diagram, port connections, and points
of failure.
{Log messages and diagnostic information. For more information about collecting this
information, see "Collecting log and operating information."
{Physical evidence of failure:
−Photos of the hardware.
−Status of the card, power, and fan status LEDs.
{Steps you have taken, such as reconfiguration, cable swapping, and rebooting.
{Output from the commands executed during the troubleshooting process.
•To ensure safety, wear an ESD-preventive wrist strap when you replace or maintain a hardware
component.
•If hardware replacement is required, use the release notes to verify the hardware and software
compatibility.
Collecting log and operating information
IMPORTANT:
By default, the information center is enabled. If the feature has been disabled, you must use the
info-center enable command to enable the feature for collecting log messages.
Table 1 shows the types of files that the system uses to store operating log and status information.
You can export these files by using FTP, TFTP, or USB. To more easily locate log information, use a
consistent rule to categorize and name files. For example, save log information files to a separate
folder for each MPU on a distributed device, and include their chassis and slot numbers in the folder
names.

2
Table 1 Log and operating information
Category File name format Content
Common log logfileX.log Command execution and operational log messages.
Diagnostic log diagfileX.log
Diagnostic log messages about device operation, including the
following items:
•Parameter settings in effect when an error occurs.
•Information about a card startup error.
•Handshaking information between the MPU and interface
card when a communication error occurs.
Operating
statistics file-basename.gz
IMPORTANT:
Collecting operating statistics decreases system performance.
Current operating statistics for feature modules, including the
following items:
•Device status.
•CPU status.
•Memory status.
•Configuration status.
•Software entries.
•Hardware entries.
NOTE:
For common and diagnostic log files, the system automatically compresses them into .gz files when
they are full.
Collecting common log messages
Collecting common log messages on a standalone centralized device
# Save common log messages from the log buffer to a log file.
By default, the log file is saved in the logfile directory of the storage medium on the device.
<Sysname> logfile save
The contents in the log file buffer have been saved to the file cfa0:/logfile/logfile8.log
# Identify the log file on the device.
<Sysname> dir cfa0:/logfile/
Directory of cfa0:/logfile
0 -rw- 21863 Jul 11 2013 16:00:37 logfile8.log
1021104 KB total (421552 KB free)
# Transfer the files to the desired destination by using FTP, TFTP, or USB. (Details not shown.)
Collecting common log messages on an IRF fabric that contains centralized devices
1. Save common log messages from the log buffer to a log file.
By default, the log file is saved in the logfile directory of the storage medium on the master
device.
<Sysname> logfile save
The contents in the log file buffer have been saved to the file
cfa0:/logfile/logfile8.log
2. Identify the log file on each member device:

3
# Display the log file on the master device.
<Sysname> dir cfa0:/logfile/
Directory of cfa0:/logfile
0 -rw- 21863 Jul 11 2013 16:00:37 logfile.log
1021104 KB total (421552 KB free)
# Display the log file on each subordinate device.
<Sysname> dir slot2#cfa0:/logfile/
Directory of slot2#cfa0:/logfile
0 -rw- 21863 Jul 11 2013 16:00:37 logfile.log
1021104 KB total (421552 KB free)
3. Transfer the files to the desired destination by using FTP, TFTP, or USB. (Details not shown.)
Collecting common log messages on a standalone distributed device or on an IRF fabric that
contains distributed devices
1. Save common log messages from the log buffer to a log file.
By default, the log file is saved in the logfile directory of the storage medium on the active MPU
(in standalone mode) or global active MPU (in IRF mode).
<Sysname> logfile save
The contents in the log file buffer have been saved to the file
cfa0:/logfile/logfile8.log
2. Identify the log file on each MPU:
# Display the log file on the active MPU (in standalone mode) or global active MPU (in IRF
mode).
<Sysname> dir cfa0:/logfile/
Directory of cfa0:/logfile
0 -rw- 21863 Jul 11 2013 16:00:37 logfile8.log
1021104 KB total (421552 KB free)
# Display the log file on each standby MPU:
{In standalone mode, display the log file on the standby MPU.
<Sysname> dir slot1#cfa0:/logfile/
Directory of slot1#cfa0:/logfile
0 -rw- 21863 Jul 11 2013 16:00:37 logfile8.log
1021104 KB total (421552 KB free)
{In IRF mode, display the log file on each standby MPU.
<Sysname> dir chassis2#slot0#cfa0:/logfile/
Directory of chassis2#slot0#cfa0:/logfile
0 -rw- 21863 Jul 11 2013 16:00:37 logfile8.log
1021104 KB total (421552 KB free)
NOTE:
If a subordinate chassis has two MPUs, make sure you identify and export the log files on both
MPUs.
3. Transfer the files to the desired destination by using FTP, TFTP, or USB. (Details not shown.)

4
Collecting diagnostic log messages
Collecting diagnostic log messages on a standalone centralized device
# Save diagnostic log messages from the diagnostic log file buffer to a diagnostic log file.
By default, the diagnostic log file is saved in the diagfile directory of the storage medium on the
device.
<Sysname> diagnostic-logfile save
The contents in the diagnostic log file buffer have been saved to the file
cfa0:/diagfile/diagfile18.log
# Identify the diagnostic log file on the device.
<Sysname> dir cfa0:/diagfile/
Directory of cfa0:/diagfile
0 -rw- 161321 Jul 11 2013 16:16:00 diagfile18.log
1021104 KB total (421416 KB free)
# Transfer the files to the desired destination by using FTP, TFTP, or USB. (Details not shown.)
Collecting diagnostic log messages on an IRF fabric that contains centralized devices
1. Save diagnostic log messages from the diagnostic log file buffer to a diagnostic log file.
By default, the diagnostic log file is saved in the diagfile directory of the storage medium on the
master device.
<Sysname> diagnostic-logfile save
The contents in the diagnostic log file buffer have been saved to the file
cfa0:/diagfile/diagfile18.log
2. Identify the log file on each member device:
# Display the log file on the master device.
<Sysname> dir cfa0:/diagfile/
Directory of cfa0:/diagfile
0 -rw- 161321 Jul 11 2013 16:16:00 diagfile18.log
1021104 KB total (421416 KB free)
# Display the log file on each subordinate device.
<Sysname> dir slot2#cfa0:/diagfile/
Directory of slot2#cfa0:/diagfile
0 -rw- 161321 Jul 11 2013 16:16:00 diagfile18.log
1021104 KB total (421416 KB free)
3. Transfer the files to the desired destination by using FTP, TFTP, or USB. (Details not shown.)
Collecting diagnostic log messages on a standalone distributed device or on an IRF fabric
that contains distributed devices
1. Save diagnostic log messages from the diagnostic log file buffer to a diagnostic log file.
By default, the diagnostic log file is saved in the diagfile directory of the storage medium on the
active MPU (in standalone mode) or global active MPU (in IRF mode).
<Sysname> diagnostic-logfile save
The contents in the diagnostic log file buffer have been saved to the file
cfa0:/diagfile/diagfile18.log
2. Identify the diagnostic log file on each MPU:

5
# Display the diagnostic log file on the active MPU (in standalone mode) or global active MPU
(in IRF mode).
<Sysname> dir cfa0:/diagfile/
Directory of cfa0:/diagfile
0 -rw- 161321 Jul 11 2013 16:16:00 diagfile18.log
1021104 KB total (421416 KB free)
# Display the diagnostic log file on each standby MPU:
{In standalone mode, display the diagnostic log file on the standby MPU.
<Sysname> dir slot1#cfa0:/diagfile/
Directory of slot1#cfa0:/diagfile
0 -rw- 161321 Jul 11 2013 16:16:00 diagfile18.log
1021104 KB total (421416 KB free)
{In IRF mode, display the diagnostic log file on each standby MPU.
<Sysname> dir chassis2#slot0#cfa0:/diagfile/
Directory of chassis2#slot0#cfa0:/diagfile
0 -rw- 161321 Jul 11 2013 16:16:00 diagfile18.log
1021104 KB total (421416 KB free)
NOTE:
If a subordinate chassis has two MPUs, make sure you identify and export the diagnostic log
files on both MPUs.
3. Transfer the files to the desired destination by using FTP, TFTP, or USB. (Details not shown.)
Collecting operating statistics
You can collect operating statistics by saving the statistics to a file or displaying the statistics on the
screen.
When you collect operating statistics, follow these guidelines:
•Log in to the device through a network or management port instead of the console port, if
possible. Network and management ports are faster than the console port.
•Do not execute commands while operating statistics are being collected.
•H3C recommends saving operating statistics to a file to retain the information.
NOTE:
The amount of time to collect statistics increases along with the number of cards.
To collect operating statistics:
1. Disable pausing between screens of output if you want to display operating statistics on the
screen. Skip this step if you are saving statistics to a file.
<Sysname> screen-length disable
2. Collect operating statistics for multiple feature modules.
<Sysname> display diagnostic-information
Save or display diagnostic information (Y=save, N=display)? [Y/N] :
3. At the prompt, choose to save or display operating statistics:

6
# To save operating statistics, enter yat the prompt and then specify the destination file path.
Save or display diagnostic information (Y=save, N=display)? [Y/N] :y
Please input the file name(*.tar.gz)[cfa0:/diag.tar.gz] :cfa0:/diag.tar.gz
Diagnostic information is outputting to cfa0:/diag.tar.gz.
Please wait...
Save successfully.
<Sysname> dir cfa0:/
Directory of cfa0:
…
6 -rw- 898180 Jun 26 2013 09:23:51 diag.tar.gz
1021808 KB total (259072 KB free)
# To display operating statistics on the monitor terminal, enter nat the prompt.
Save or display diagnostic information (Y=save, N=display)? [Y/N] :n
===========================================================
===============display alarm===============
No alarm information.
=========================================================
===============display boot-loader===============
Software images on slot 0:
Current software images:
cfa0:/MSR-CMW710-BOOT-R7328_mrpnc.bin
cfa0:/MSR-CMW710-SYSTEM-R7328_mrpnc.bin
Main startup software images:
cfa0:/MSR-CMW710-BOOT-R7328_mrpnc.bin
cfa0:/MSR-CMW710-SYSTEM-R7328_mrpnc.bin
Backup startup software images:
None
=========================================================
===============display counters inbound interface===============
Interface Total (pkts) Broadcast (pkts) Multicast (pkts) Err (pkts)
BAGG1 0 0 0 0
GE4/0/1 0 0 0 0
GE4/0/2 2 2 0 0
GE4/0/3 0 0 0 0
GE4/0/4 0 0 0 0
GE4/0/5 0 0 0 0
GE4/0/6 0 0 0 0
GE4/0/7 0 0 0 0
GE4/0/8 0 0 0 0
GE4/0/9 0 0 0 0
GE4/0/10 0 0 0 0
……

7
Contacting technical support
If you cannot resolve a problem by using the troubleshooting procedures in this document, contact
H3C Support. When you contact an authorized H3C support representative, be prepared to provide
the following information:
•Information described in "General guidelines."
•Product serial numbers.
This information will help the support engineer assist you as quickly as possible.
The following is the contact of H3C Support:
•Telephone number—400-810-0504.
•E-mail—[e-mail].
Troubleshooting Ethernet interfaces
This section provides troubleshooting information for common problems with Ethernet interfaces.
Failure to ping the directly connected device
Symptom
An Ethernet interface cannot ping the directly connected device.
Solution
To resolve the problem:
1. Execute the display interface command and perform the following tasks:
{Verify that the interface is up.
{Verify that the speed and duplex mode of the local end match the speed and duplex mode of
the peer end.
{Verify that the cable and interface are operating correctly by viewing the packet statistics of
the interface.
{Verify that the transceiver module of the local end matches the transceiver module of the
peer end if the interface is a fiber port.
2. Use the display arp command to verify that the interface can receive ARP packets sent by
the directly connected device. If not, use the debugging arp packet command to verify that
the interface can send and receive ARP packets correctly.
3. Use the debugging ip packet command to verify that the interface can send and receive
packets correctly.
4. Use the debugging ip icmp command to verify that the interface can send and receive ICMP
packets correctly.
5. Collect the following information for the interface:
{Execute the display hardware internal module interface-name interface-number
statistics command in probe view to collect the interface statistics.
{Execute the display hardware internal module interface-name interface-number
status command in probe view to collect the status information.

8
{Execute the display hardware internal module interface-name interface-number
reg 1command in probe view to collect the FPGA information.
{Execute the display hardware internal module interface-name interface-number
reg 2command in probe view to collect the MAC information.
{Execute the display hardware internal module interface-name interface-number
reg 3command in probe view to collect the PHY information.
6. Contact H3C Support.
Failure to forward packets
Symptom
An Ethernet interface on an intermediate router cannot forward packets.
Solution
To resolve the problem:
1. Verify that the Ethernet interface can ping the directly connected device. If the ping operation
fails, see "Failure to ping the directly connected device."
2. Use the debugging ip packet command to verify that the interface can transmit packets
correctly.
3. Collect the following information for the interface:
{Execute the display hardware internal module interface-name interface-number
statistics command in probe view to collect the interface statistics.
{Execute the display hardware internal module interface-name interface-number
status command in probe view to collect the status information.
{Execute the display hardware internal module interface-name interface-number
reg 1command in probe view to collect the FPGA information.
{Execute the display hardware internal module interface-name interface-number
reg 2command in probe view to collect the MAC information.
{Execute the display hardware internal module interface-name interface-number
reg 3command in probe view to collect the PHY information.
4. Contact H3C Support.
Packet dropping
Symptom
An Ethernet interface drops packets.
Solution
To resolve the problem:
1. Determine whether the packets are dropped by the local end or the peer end by executing the
following commands to compare the rates of the two ends:
{Execute the display counters rate inbound interface command on the local end
to view the inbound traffic rate statistics.

9
{Execute the display counters rate outbound interface command on the peer end
to view the outbound traffic rate statistics.
The end with a lower rate drops packets.
2. Use the display interface command to view the traffic statistics for the interface to verify
that no packets are dropped by the interface.
3. Collect the following information for the interface:
{Execute the display hardware internal module interface-name interface-number
statistics command in probe view to collect the interface statistics.
{Execute the display hardware internal module interface-name interface-number
status command in probe view to collect the status information.
{Execute the display hardware internal module interface-name interface-number
reg 1command in probe view to collect the FPGA information.
{Execute the display hardware internal module interface-name interface-number
reg 2command in probe view to collect the MAC information.
{Execute the display hardware internal module interface-name interface-number
reg 3command in probe view to collect the PHY information.
{Execute the display hardware internal ibd pkt-info slot slot-number
slot-number command in probe view to collect inter-card packet statistics.
4. Contact H3C Support.
Related commands
This section lists the commands that you might use for troubleshooting Ethernet interfaces.
Command Description
display interface Displays Ethernet interface information.
display arp [ [ all | dynamic | multiport
|static ] | vlan vlan-id | interface interface-type
interface-number ] [ count | verbose ] Displays ARP entries.
display counters rate inbound interface Displays outbound traffic rate statistics.
display counters rate outbound interface Displays inbound traffic rate statistics.
display hardware internal module
interface-name interface-number statistics Displays Ethernet interface statistics.
display hardware internal module
interface-name interface-number status Displays status information for an Ethernet interface.
display hardware internal module
interface-name interface-number message
Displays configuration information for an Ethernet
interface.
display hardware internal module
interface-name interface-number reg 1Displays FPGA information for an Ethernet interface.
display hardware internal module
interface-name interface-number reg 2Displays MAC information for an Ethernet interface.
display hardware internal module
interface-name interface-number reg 3Displays PHY information for an Ethernet interface.
display hardware internal ibd pkt-
i
nfo
slot slot-number slot-number Displays inter-card packet statistics.
debugging arp packet Enables ARP debugging.

10
Command Description
debugging ip packet Enables IP debugging.
debugging ip icmp Enables ICMP debugging.
Troubleshooting E1 and T1 interfaces
This section/document provides troubleshooting information for common E1 and T1 interface issues.
Common E1 and T1 interface issue
troubleshooting methods
Common E1 and T1 interface issue troubleshooting methods include:
•Troubleshooting the hardware
•Troubleshooting the cables
•Troubleshooting the configuration
•Troubleshooting the clocks
•Troubleshooting grounding
•Troubleshooting through looping
Troubleshooting the hardware
1. Examine the external power supply connection.
Perform an independent power supply test for the faulty device to verify that the power supply is
operating properly.
2. Perform a local loopback test:
a. Execute the loopback local command on the E1/T1 interface or execute the {fe1 |
ft1} loopback local command on the E1-F/T1-F interface.
b. Identify whether the interface comes up physically, and identify whether the logical serial
interface performs local loopback correctly.
−If local loopback succeeds, the card has no hardware problems.
−If local loopback fails, proceed with the following steps.
3. If local loopback succeeds after the card is installed in another slot, the device has hardware
problems. In this case, proceed with the device component analysis process.
4. Replace the card.
If local loopback succeeds after the card is replaced, the card has hardware problems. In this
case, proceed with the card component analysis process.
5. Replace the host.
If local loopback succeeds after the host is replaced, the host has hardware problems. In this
case, proceed with the device component analysis process.
Troubleshooting the cables
1. Examine the cable quality.
{Verify the cables are H3C-standard cables.

11
{Replace cables.
{Connect the Tx and Rx ends of the cable. Identify whether the interface can perform self
loopback. If self loopback succeeds, the cable has no problems. For how to perform self
loopback, see “Troubleshooting through looping.”
2. Identify whether the cable impedance matches the interface impedance.
a. Execute the display controller or display fe1 command to view the interface
impedance (text in blue in the command output).
[H3C] display controller E1 1/0/0
E1 1/0/0 current state :DOWN
Description : E1 1/0/0 Interface
Basic Configuration:
Work mode is E1 framed, Cable type is 120 Ohm balanced.
b. Replace the cable or adjust the DIP switch on the card to ensure that the cable impedance
matches the interface impedance. (For an HMIM-8E1T1 card, use the hardware jumper and
the cable-type command to identify the card impedance.)
Interface type: E1 interface
Command: cable-type {75 | 120 }
Parameters:
−75: Matches 75-Ωtransmission lines.
−120: Matches 120-Ωtransmission lines.
3. Identify whether the cable length matches the configuration.
An E1/T1 interface poses a limit on the cable length. Typically, the maximum length cannot
exceed 500 meters. A longer cable will cause more serious signal attenuation. In this case, you
need to compensate the signal or connect an external CSU. The router provides the cable
command to set the attenuation or length for the transmission line of an interface. This
command configures the wave pattern for transmitted signals to adapt to different transmission
requirements. Use this command according to the quality of the received signals. If the received
signals are of good quality, use the default settings.
{Interface type: E1 interface
Command: cable { long | short }
Parameters:
−long: Matches 199.6-meter (655-feet) and longer cable length.
−short: Matches a cable length shorter than 199.6 meters (655 feet).
{Interface type: T1/T1-F interface
Command: cable { long { 0db | -7.5db | -15db | -22.5db } | short { 133ft | 266ft
| 399ft | 533ft | 655ft } }
Parameters
−long: Matches 199.6-meter (655-feet) and longer cable length. The options for this
parameter include 0db, -7.5db, -15db, and -22.5db. The attenuation is selected
depending on the signal quality received at the receiving end. A poorer line quality
results in a more serious signal attenuation. In this case, you need to compensate the
signal attenuation. No external CSU is needed.
−short: Matches a cable length shorter than 199.6 meters (655 feet). The options for this
parameter include 133ft, 266ft, 399ft, 533ft, and 655ft. The length is selected
depending on the actual transmission distance.
Troubleshooting the configuration
1. Verify that the local end and peer end have the same configuration.

12
The configuration includes operating mode (framed or unframed), framing format, CRC mode,
coding format, line idle code, and interframe filling tags.
TIP:
The Cisco E1 interfaces use the CRC4 framing format by default. The H3C E1 interfaces use
the no-CRC4 framing format by default. When interconnecting such E1 interfaces, make
sure they use the same configuration.
2. Troubleshoot the AIS alarm problems.
If the line properly transmits all-one bit streams and the idle code is FF, AIS alarms are
generated when no service data is transmitted over the line and the line transmits only all-1 idle
codes.
To resolve this issue, perform one of the following tasks:
{Execute the undo detect-ais command on the interface to disable AIS detection.
{Modify the interframe filling tags to 7E.
Troubleshooting the clocks
1. Select a standard clock scheme.
Depending on whether the transmission network provides a clock, an E1 interface has two
available clock schemes:
{When the transmission network provides a clock, the transmission network provides the
master clock, and both local and peer E1 interfaces use the slave clock mode.
Figure 1 Clock scheme when the transmission network provides a clock
{When the transmission network does not provide a clock, the transmission network
transparently transmits packets. Set the clock mode to master on one end and slave on the
other end.
Figure 2 Clock scheme when the transmission network does not provide a clock
2. Measure the frequency deviation
If the clock configuration is incorrect, frequency deviation will occur on the transmission line.
The normal frequency deviation on an E1 interface is -50ppm to +50ppm. If the frequency
deviation exceeds the range, normal packet forwarding cannot be guaranteed. The frequency
deviation will accumulate, and will continuously be bigger as time goes by. Accordingly, error
packets will appear on the E1 interface, and at last the E1 interface will become unavailable.
To restore the frequency deviation to the initial value, shut down and then bring up the interface.
Typically, you can use the ETEN meter to measure the frequency deviation of the lines.
Connect the ETEN meter to the Tx or Rx line of the E1 interface in serial, and measure the Tx
and Rx frequency deviations of the line separately.

13
Troubleshooting the grounding
Typically bad grounding and common grounding
•The device is installed in a 19-inch cabinet, but the grounding cable of the device is not
connected to the grounding strip of the cabinet.
•The device and its peer device are in the same equipment room, both devices are grounded,
but they are not commonly grounded.
Influence of bad common grounding
Bad common grounding will cause different reference voltages on the two devices. As a result, the
Rx/Tx and other signals are not detected on the same voltage platform. Then, the data transmitted
on the local end will be different from the data received on the peer end, and error packets appear.
More seriously, the protocol might come up and go down. Additionally, the normal signals transmitted
on the local end might fail to be detected or be incorrectly detected on the peer end. As a result,
alarms will appear on physical links, and physical E1 interfaces come up and go down.
Grounding requirements
•Make sure the devices are well grounded.
•If the device and its peer device are in the same equipment room, both devices must be
grounded and commonly grounded.
•The grounding cable must be a copper cable in order to reduce the high-frequency impedance.
Make sure the grounding cable is as thick and short as possible. Do not use aluminum cables.
•Make sure both ends of the grounding cable have good electric contact and have antiseptic and
antirust processing.
•Do not use other devices for electric contact of the grounding cable.
•The grounding cable cannot be parallel to or twisted with signal cables.
•The connectors, on-off switches, or fuse protectors cannot be added to the grounding cable.
•The grounding cable must be yellow-green plastic-insulated copper conductor.
•The grounding cable must be shorter than 30 meters, and try to be as short as possible. When
the cable exceeds 30 meters, the customer must place grounding strips nearby.
•If an UPS is used for power supply, the UPS must also be grounded.
Reliable grounding is the basic requirements for good protection against lightening, electric shock,
and interference, and is the prerequisites for long-period reliable, stable operation of the device.
Different grounding methods in different environments
Grounding strips are provided in the installation environment
When the grounding strips are provided in the installation environment, perform the following tasks:
1. Make sure the grounding strip is well grounded.
2. Connect one end of the yellow-green grounding cable to the grounding post on the grounding
strip, and fasten the nut.
The sectional area of the grounding cable must be no smaller than 4mm2. Make sure the cable
is as short as possible, and do not twist the cable.

14
Figure 3 Grounding when grounding strips are provided
When the device is installed in a 19-inch cabinet, you can connect the yellow-green grounding cable
to the grounding terminal of the cabinet, and make sure the grounding terminal of the 19-inch cabinet
is well connected to the grounding strips of the equipment room.
Grounding strips are not provided and the grounding conductor cannot be buried in the earth in the
installation environment
When grounding strips are not provided and the grounding conductor cannot be buried in the earth
the installation environment, follow these guidelines.
•When the device uses a 220V AC power supply, you can use the PE wire of the AC power
supply for grounding, as shown in Figure 4. Make sure the PE wire of the AC power supply is
well grounded in the electric distribution room or the AC power transformer. Additionally, make
sure the PE terminal of the device is well connected to the PE wire of the AC power supply. The
power cable of the device must be a three-core cable with a grounding cable. If the PE wire of
the AC power supply is not grounded in the electric distribution room or the AC power
transformer, submit the rectification requirements to the customer as soon as possible.
Figure 4 Grounding using the PE wire of the AC power supply
•When the device uses a -48V (or +24V) DC power supply, you can use the RTN or PGND cable
of the DC power supply for grounding, as shown in Figure 5. Make sure the RTN or PGND wire


15
of the DC power supply is well grounded in DC power supply output of the DC power supply
cabinet. Otherwise, submit the rectification requirements to the customer as soon as possible.
Figure 5 Grounding using the PGND wire of the DC power supply cabinet
Grounding strips are not provided and the grounding conductor can be buried in the earth in the
installation environment
If no grounding strips are provided and earth is available at the installation site, hammer a 0.5 m
(1.64 ft) or longer angle iron or steel tube into the earth to serve as a grounding conductor. The cross
section of the angle iron must be no smaller than L×W×H = 50×50×5 mm, and the thickness of the
steel tube must be no smaller than 3.5mm. Galvanized steel is required. Weld the yellow-green
grounding cable to the angel iron or steel tube and treat the joint for corrosion protection. The
sectional area of the grounding cable must be no smaller than 4mm2. Make sure the cable is as short
as possible, and do not twist the cable, as shown in Figure 6.
Figure 6 Grounding when the grounding conductor can be buried in the earth
NOTE:
Method 3 is simple, and the ground resistance might be very high. Use method 3 only when method
1 or method 2 cannot be used.



16
Ground resistance
Determine the ground resistance of the grounding strips according to the equipment room
environment requirements. For the central telecom equipment room, determine the ground
resistance according to YDJ26-89 (which requires the ground resistance to be smaller than 1Ω). For
non-central telecom equipment rooms, the ground resistance must be lower than 5Ω. For angle irons
hammered into the earth, the ground resistance can be relaxed appropriately to be smaller than 10Ω.
In an area with a higher ground resistance, reduce the ground resistance by using brine or resistance
reducing agent around the grounding conductor.
Commonly grounding devices
The interconnected devices must be commonly grounded and well grounded.
•If the interconnected devices are both installed in a 19-inch cabinet, connect the grounding
cables of these devices to the grounding strip of the cabinet for common grounding.
•If the interconnected devices are placed in the same equipment room and not far from each
other, you can join the grounding cables of the interconnected devices and then connect the
cables to the ground, as shown in Figure 7.
Figure 7 Common grounding for devices
•If the interconnected devices are not in the same equipment room, make sure all
interconnected devices are well grounded.
Identifying whether the devices are commonly grounded well
As shown in Figure 8, use the grounding cable to the lead out the grounding terminals of the
interconnected devices, and use the multimeter to measure the voltage and resistance between the
two grounding terminals.
•If they are well grounded, the resistance between the two terminals quickly returns to zero and
the voltage is lower than 1V.
•If they are not well grounded, the resistance between the two terminals is not zero or slowly
returns to zero, or the voltage is higher than 1V.


17
Figure 8 Identifying whether the devices are commonly grounded well
Troubleshooting through looping
Common looping points
Figure 9 Common looping points (vice versa)
Looping point 1
Method: Execute the loopback local command on the E1 interface of the router, and execute the
fe1 loopback local command on the FE1 interface.
Purpose: Verify that the router interface can properly send and receive packets.
Looping points 2 and 3
Method: Short connect the Rx and Tx cables between Router1 and transmission device 1 or form a
leftwards loop on the transmission device.
Purpose: Verify that the line between Router1 and transmission device 1 is normal.
Looping point 4
Method: Form a leftwards loop on transmission device 2.
Purpose: Verify that the transmission network is normal.
Looping point 5
Method: Short connect the E1 Rx and Tx cables between Router1 and transmission device 1.
Purpose: Verify that the line whole physical link between Router1 and Router 2 is normal.
Looping point 6
Method: Execute the loopback remote/payload command on the E1 interface of Router 2, and
execute the fe1 loopback remote/payload command on the FE1 interface of Router 2.
Purpose: Verify that the whole link including Router 2 is normal.
Troubleshooting lines after looping
Use the self-loopback test function of the router to troubleshoot lines

18
1. Enable PPP encapsulation on the interface.
2. Display the interface information.
{If the command output shows that the number of received packets evenly increases by 12
packets, loopback is detected, and no error packets appear, the link is normal.
{Otherwise, the link fails.
[H3C]dis int ser 1/0:0
Serial1/0:0
Current state: UP
Line protocol state: DOWN
Description: Serial1/0:0 Interface
Bandwidth: 64kbps
Maximum Transmit Unit: 1500
Hold timer: 10 seconds, retry times: 5
Derived from E1 1/0, Timeslot(s) Used: 1, Baudrate is 64000 bps
Internet protocol processing: disabled
Link layer protocol: PPP, Loopback: detected
LCP: closed
Output queue - Urgent queuing: Size/Length/Discards 0/100/0
Output queue - Protocol queuing: Size/Length/Discards 0/500/0
Output queue - FIFO queuing: Size/Length/Discards 0/75/0
Last clearing of counters: Never
Last 300 seconds input rate: 0.00 bytes/sec, 0 bits/sec, 0.00 packets/sec
Last 300 seconds output rate: 0.00 bytes/sec, 0 bits/sec, 0.00 packets/sec
Input:
12 packets, 156 bytes
0 broadcasts, 0 multicasts
0 errors, 0 runts, 0 giants
0 CRC, 0 align errors, 0 overruns
0 aborts, 0 no buffers, 0 frame errors
Output:
12 packets, 156 bytes
0 errors, 0 underruns, 0 collisions
0 deferred
Use the error code meter to troubleshoot lines
3. Replace the router with an error code meter.
4. Connect the Rx and Tx cables previously connected to the router to the error code meter.
In this case, the error code meter can display whether error codes exist on the line.
Troubleshooting E1/T1 interfaces
Common E1/T1 module problems include the following types:
•Physical interface anomaly, for example, the LOS, LFA, AIS, or RAI alarms exist on the
controller interface and the controller interface stays down or flaps.
•The physical interface is up, and has no alarms. However, the data cannot be sent or received
properly. For example, error packets exist on the local and peer interfaces, and the link layer
protocol comes up and go down.