No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

POS Port Is Physically Up and Protocol is Down on the NE40E of a Site

Publication Date:  2013-09-03 Views:  48 Downloads:  0
Issue Description
In the WAN construction project for XXX enterprise, the upstream POS 155M port on the NE40E-X8 (V600R001C00SPCe00) of a site is physically Up during cutover, but the PPP protocol is Down. Such problem also occurs on the NE40E-8 (V300R006C01) connected to the NE40E-X8 across the SDH network. The 155M uplink is an existing link. The NE40E-X8 is not located in the same equipment room as existing devices, and is directly connected to the transmission device through newly deployed optical fibers without ODFs in the middle.
At the night of cutover, the NE40E-8 properly communicates with H3C devices on the live network using the 155M port and link. After traffic is switched to the NE40E-X8, the fault occurs. The carrier's transmission maintenance personnel consider the NE40E-X8 faulty.
Handling Process
1. Link-layer protocols are different on devices at both ends.
2. Configurations such as the SDH overhead byte (C2 and J0), CRC, and frame format are different on POS ports at both ends.
3. The clock modes are different at both ends.
4. The receive and transmit optical power is abnormal on POS ports.
5. The port on the NE40E-X8 connected to the NE40E-8 is faulty.
6. The optical module is faulty, or the optical module and optical fiber do not match.
7. The transmission link is faulty.
8. The optical fiber between the transmission device and NE40E-X8 is disconnected.
Root Cause
For details, see "Handling Process."
Solution
1. Verify that PPP is configured on devices at both ends and the NE40E-8 properly communicates with H3C devices on the live network using the 155M port and link at the night of cutover.
2. Verity that configurations such as the SDH overhead byte (C2 and J0), CRC, and frame format are the same on POS ports at both ends.
3. Verify that the clock mode is slave on POS ports at both ends.
4. Verify that the receive and transmit optical power is within the allowed range on POS ports.
5. Run the loopback local command to conduct a loopback test. Loopback is detected on the port of the NE40E-X8. Use a single optical fiber to conduct an outer-loop test. Loopback is detected on the port. Change the port protocol to HDLC and conduct an outer-loop test. The protocol is Up. These tests indicate that the port on the NE40E-X8 is working properly.
6. Verify that the optical module and optical fiber are of multi-mode and match. The fault persists even after the optical module is replaced.
7. Check transmission links. Conduct a remote loopback test on the local transmission device to the NE40E-8. Loopback is detected on the port of the NE40E-8, indicating that the link and optical fiber between the transmission device and NE40E-8 are normal.
8. Conduct a local loopback test on the local transmission device to the NE40E-X8. Loopback is not detected on the port of the NE40E-X8, indicating that the optical fiber between the transmission device and NE40E-X8 is faulty.
9. Check SDH alarms on the port of the NE40E-X8. LRDI and PRDI alarms exist, further indicating that the optical fiber between the transmission device and NE40E-X8 is faulty.
10. Replace the faulty optical fiber between the transmission device and NE40E-X8. The protocol is Up on ports at both ends, and no packet is lost during the ping test. The fault is rectified.
Suggestions
It is difficult to troubleshoot the unidirectional fiber fault. When transmission devices are used, contact with maintenance personnel of transmission devices, and master basic location methods and meanings of common SDH alarms. The attachment lists common transmission alarms and errors on the SDH/SONET network where datacom devices are used.

END