Analysis of the Anomaly Occurring When an MCA4 Board Scans Optical Channels and the Board Reports the CHAN_ADD Alarm

This case describes how to handle the anomaly that occurs when an MCA4 board scans optical channels.

Product

OptiX OSN 6800

OptiX OSN 8800

OTN

Fault Type

Spectrum Analyzer Unit

CHAN_ADD

Symptom

An ROADM NE is configured with an MCA4 board. On the MCA4 board, the IN1 and IN2 interfaces are connected to the MON interfaces on the OAU in the receive direction and the OAU in the transmit direction on the east direction. The IN3 and IN4 interfaces are connected to the MON interfaces on the OAU in the receive direction and the OAU in the transmit direction on the west direction.

At the IN1 and IN2 interfaces, however, two extra wavelengths are found, as they are not found in the wavelengths from the upstream site. Besides, there is no other inter-ring input, and no existing optical cross-connection involves the two wavelengths. In addition, the two wavelengths are not covered in the wavelengths that should be monitored by MCA4 board as the configuration. In this case, the two wavelengths should traverse the IN3 and IN4 interfaces. At the IN3 and IN4 interfaces, however, the two wavelengths are found and the scanned data is correct.

After a cold reset is performed on the MCA4 on the T2000, the fault persists.

The MCA4 board reports the CHAN_ADD alarms for the two extra wavelengths at the IN1 and IN2 interfaces.

Cause Analysis

Based on the preceding description, the MCA4 has entered an infinite loop when processing certain programs for data scan. As a result, the programs cannot release and update the scanned data.

Procedure

1. The site with the fault consists of many NEs. Therefore, at first the field engineers suspect that fibers on the MCA4 board are connected improperly. To verify this, increase the gain of the OAU on the upstream site connected to the east direction by 2 dBm. That is, the input power of the OAU in the receive direction is increased by 2 dBm. Normally, the MCA4 should detect the change at the IN1 interface connected to the MON interface on the OAU. The scan result at the IN1 interface, however, remains unchanged.
2. Check the fiber connections on the MCA4 board on site. It is found that the fibers are properly connected. Remove the fibers connected to the IN1 and IN2 interfaces. The scan result at the IN1 and IN2 interfaces remains unchanged.
3. Remove the fibers connected to the IN3 and IN4 interfaces and check the scan result of the IN1 to IN4 interfaces. It is found that no power is output.
4. Connect the fiber that is previously connected to the IN2 interface to the IN3 interface. The scan result of the IN3 interface is normal, and no extra wavelengths are found at the IN2 interface. Therefore, the problem may be caused by the IN1 or IN2 interface.
5. Restore the fiber to the IN2 interface and check the scan result of the IN2 interface. The fault recurs.
6. Reseat the MCA4 board, and then connect all the fibers on the board properly. The scanned data at all interfaces on the board is normal.

Result

The problem is solved after the operation is finished as the requests.

Two days later, perform the test again and it is found that the scanned data remains correct.

Reference Information

None.

MORE BLOG:

When customized for North America unable to configure OSN1800.

How to Use the LDMD Board to Configure Intra-Board 1+1 Protection Fails?

When OptiX OSN 1800 Database Recovery Failures

Service Interruption Occurs Because of a Channel Rate Mismatch Between TN54NS3 Boards on the OptiX OSN 8800 Network

Service interruption occurs because of a channel rate mismatch between TN54NS3 boards on the OptiX OSN 8800 and OSN 6800 network.

Fault Symptom

At a site of an OptiX OSN 8800 network in country T, a service is interrupted after it is switched to the protection path upon a fiber cut on the working path.

Network Topology

Cause Analysis

The TN54NS3 boards at the sites A and B on the faulty link use the standard ODU2 mode, but the interconnected TN54NS3 boards at sites C and D use ODU2 speedup mode. The inconsistency in the ODU2 rate modes of the NS3 boards results in the service interruption.

Procedure

1. Browse alarms on every NE on the link. No unexpected alarms are present.
2. Confirm that the service type is 10GE LAN and the port mapping mode is MAC transparent transmission.
   
3. Obtain service cross-connections from the frontline engineer, as listed below.
   
4. Confirm with the frontline engineer, learning that the ODU2 rate modes are displayed as standard ODU2 mode for the TN54NS3 boards.
5. Confirm that the frontline engineer has changed the service channels. The service is restored after the service channels are changed. The highlighted channels in the following table are the new channels.
   
6. Upload the data of all the NEs to the U2000 and query the channel rate modes of all the TN54NS3 boards. It is observed that the TN54NS3 board in slot 31 at site C and that in slot 17 at site D are provisioned with the ODU2 speedup mode. The mismatch of the ODU2 rate modes between the TN54NS3 boards leads to the service interruption.

Conclusion and Suggestion

Before deploying a service on a link, use the U2000 to query the channel data rate modes of the NEs on the link. To ensure that the NE data on the U2000 is consistent with that on the NEs, upload the data of all NEs on the link to the U2000 before performing the query.

If a service with a data rate less than the service rate of line boards is interrupted on a live network but no abnormal alarm is found, enable non-intrusive monitoring for the line boards section by section. Using the OptiX OSN 8800 network in country T as an example, the TN54NS3 boards in slot 31 at site C is interconnected with the TN54NS3 board in slot 17 at site D and the ODU2 speedup mode is specified for the ODU2LP1-1 channels on the two boards. However, the ODU2LP1-1 channels from the upstream sites are in standard ODU2 mode. When non-intrusive monitoring is enabled, an ODU2_PM_SSF alarm can be reported for the TN54NS3 board in slot 17 at site B.

More blog:

How to Use the Ethernet Test Frames on the OptiX OSN 6800?

TD Alarms Falsely Reported by Some Boards Using Pluggable Optical Modules in WDM Products

When the Software Version Compatibility Issue on the TNF2LQM and TNF2LDGF2 Boards in OptiX OSN 1800

The FDG Board Reports the R_DATA_LOST Alarm in the Early Morning

The FDG board reports the R_DATA_LOST alarm in the early morning because the traffic volume is light.

Product

OptiX Metro 6100

OptiX Metro 6040

OSN6800

OSN8800

Fault Type

Optical Transponder Board

R_DATA_LOST

Symptom

The FDG board in the Metro 6100 keeps reporting the R_DATA_LOST alarm in the early morning. The line and the data equipment connecting to the FDG board, however, are normal.

Cause Analysis

The FDG board detects the services every five seconds. If the FDG does not receive data packets during the detection, the FDG reports the R_DATA_LOST alarm. The alarm does not mean that the services are not available. No alarm is generated in the line during day and the services are normal. The alarm is generated only in the early morning. Hence, the alarm is related to the truth that the traffic volume is light. In the early morning, no data packets are transmitted normally when the FDG detects the services. Hence, the R_DATA_LOST alarm is reported.

Procedure

1. Make sure that the services are normal. To clear T_DATA_LOST and R_DATA_LOST alarms, check the KEEP ALIVE parameter of one router. If the parameter is enabled, the router continuously sends small packets to inform the remote equipment that the link is up. You can mask the alarm on the NMS if required.

Reference Information

The data boards, such as the LDG, also have the similar problem. Solve the problem in a similar way.

The T_DATA_LOST alarm is client-side transmitting data lost. The board regularly checks the Ethernet performance event "Good Octets Transmitted" and compares the number with the number of last time. The alarm occurs when the two numbers are the same, which indicating that the board does not transmit any data.

The R_DATA_LOST alarm is client-side receiving data lost. The board regularly checks the Ethernet performance event "Good Octets Received" and compares the number with the number of last time. The alarm occurs when the two numbers are the same, which indicating that the board does not receive any data

MORE BLOG:

During the Rerouting in the ASON Network, the Protection Switching Time May Exceed the Specification ValuePrewarning for ARP Entry Aging Failures on MxU

When Users on Base Stations of Different Vendors Attempt to Get Online Through an ATN Device.

Active/Standby Switching Cannot Be Performed After an SCC Board of the OptiX OSN 8800 Is Replaced

Active/Standby switching cannot be performed after an SCC board of the OptiX OSN 8800 is replaced.

Product

OptiX OSN 8800, OSN6800

Fault Type

System and Communication Unit

Symptom

An OptiX OSN 8800 NE at an office reports a file loss alarm. The TN51SCC board on the NE is then replaced with a new SCC board with NE software of a later version. The BIOS of the new SCC board, however, cannot be synchronized with that of the other SCC board on the NE. After the new SCC board is reset, the BIOS synchronization still fails and the active/standby SCC switching cannot be performed.

After the new SCC board is replaced with a normal SCC board from another NE, the alarm is cleared and the active/standby switching can be performed successfully.

After the new SCC board is inserted to one normal NE, active/standby switching also cannot be performed.

The versions of the SCC board running on the live network and the new SCC board are as follows:

• Version of the new SCC board: 5.51.5.26
• Version of the SCC board running on the live network: 5.51.4.24

Cause Analysis

The possible causes of the fault are as follows:

The version of the new SCC board is later than that of the other SCC board on the NE. The NE does not support smooth downgrade of the NE database and thus the new SCC board cannot function properly.

Procedure

1. Perform the following operations to identify the problem:
   1. Check the software version of the new SCC board and find that the version is 5.51.5.26.
   2. Attempt to downgrade the software of the new SCC board to 5.51.4.24 by inserting the new SCC board in a slave subrack.
   3. Insert the new SCC board back to the master subrack.
   4. Perform active/standby switching. The switching fails.
2. Set the jumpers on the new SCC board and insert it to the slot of the old SCC board so that the database of the new SCC board is cleared automatically.
3. After the new SCC board is started, remove it. In addition, remove the jumper caps on the board. After that, re-insert this SCC board back to the slot. For information on how to set jumpers on an SCC board, see "Replacing the SCC Board" in the Parts Replacement for OptiX OSN 8800 V100R002C02.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:

Clear the databases of the new SCC board before the replacement. Then, replace an existing SCC board on an NE with the new SCC board. For more information, see "Replacing the SCC Board" in the Parts Replacement for OptiX OSN 8800 V100R002C02. After the new SCC board goes online, synchronization of software and database between the active SCC board and the new SCC board is performed automatically. When software and database synchronization is complete, perform active/standby SCC switching.

MORE BLOG:

During the Rerouting in the ASON Network, the Protection Switching Time May Exceed the Specification Value

Prewarning for ARP Entry Aging Failures on MxU

When Users on Base Stations of Different Vendors Attempt to Get Online Through an ATN Device.

What Are the Rates for Different OTN Frame Structures

Product

OptiX OSN 1800

OptiX OSN 3800

OptiX OSN 6800

OptiX OSN 8800

Fault Type

Others

Symptom

What are the rates for different OTN frame structures?

Cause Analysis

OTUk rate = 255/(239-k) x STM-N frame rate

ODUk rate = 239/(239-k) x STM-N frame rate

OPUk rate = 238/(239-k) x STM-N frame rate

 NOTE:

• ODU0 and OTU5G frames are not standard frame structures defined in ITU-T G.709. Therefore, their rates cannot be calculated by using the preceding formulas.
• An ODU0 frame encapsulates one GE frame and is cross-connected between a tributary or line board and an XCH or XCM board. The XCS board does not support ODU0 services. OTU boards do not provide OTU0 ports on their WDM sides.
• One OTU5G frame encapsulates four GE frames. Currently, only L4G and LQG boards provide OTU5G ports on their WDM sides.

Rates for different frame structures are as follows:

• OTUk
  • OTU1: 2 666 057.143 kbit/s = 255/238 x 2 488 320 kbit/s
  • OTU5G: 5 Gbit/s
  • OTU2: 10 709 225.316 kbit/s = 255/237 x 9 953 280 kbit/s
  • OTU3: 43 018 413.559 kbit/s = 255/236 x 39 813 120 kbit/s
• ODUk
  • ODU0: 1.25 Gbit/s
  • ODU1: 2 498 775.126 kbit/s = 239/238 x 2 488 320 kbit/s
  • ODU2: 10 037 273.924 kbit/s = 239/237 x 9 953 280 kbit/s
  • ODU3: 40 319 218.983 kbit/s = 239/236 x 39 813 120 kbit/s
• OPUk
  • OPU1: 2 488 320 kbit/s
  • OPU2: 9 995 276.962 kbit/s = 238/237 x 9 953 280 kbit/s
  • OPU3: 40 150 519.322 kbit/s = 238/236 x 39 813 120 kbit/s

Procedure

1. None.

Result

The problem is resolved.

Reference Information

None.

When Service Interruption on 100G and 40G Boards in WDM Products

Incorrect Configuration of the ZL80018 Chip on OptiX OSN 1800

How to do when the Occasional Failure to Go Online for TN11HSC1 Boards

How to Clear the COMMUN_FAIL Alarm on the OptiX OSN 6800?

Boards on an OptiX OSN 6800 NE malfunction, and therefore the system reports the COMMUN_FAIL alarm.

Product

OptiX OSN 6800, 

Huawei Optix OSN8800 T16

Fault Type

COMMUN_FAIL

SUBRACK_LOOP

Symptom

Multiple boards on a newly-deployed OptiX OSN 6800 NE report the COMMUN_FAIL alarm at the same time. The NE subrack is the master subrack.

On the NMS, the historical alarm record shows that the SUBRACK_LOOP alarm is reported before the COMMUN_FAIL alarm.

Cause Analysis

Possible causes for the problem on a single NE are as follows:

• Boards on the NE are in the cold or warm reset state.
• The network cables that cascade subracks do not meet relevant requirements.
• Boards on the NE are malfunctioning.

Procedure

1. On the NMS, check the COMMUN_FAIL alarm parameter. The parameter is 0x01 0x00 0x03, indicating that inter-board ETH communication fails.
2. The NE has ever reported the SUBRACK_LOOP alarm and this alarm is cleared one minute later. The SUBRACK_LOOP alarm indicates a loopback on network ports between subracks. A loopback can cause a broadcast storm on the network and block some communication ports.
3. Remove and then reinsert the AUX board. After the board starts up, the alarm is cleared and is not reported again.

Result

The problem is resolved.

In this maintenance case, the OptiX OSN 6800 works in the master-slave mode. Internal network ports of the subracks are connected to form a loop. This causes an Ethernet broadcast storm and blocks some communication ports. Therefore, communication on these boards fails. If a COMMUN_FAIL alarm is generated accompanied by a SUBRACK_LOOP alarm on a live network, check network cables between subracks. If the SUBRACK_LOOP alarm is cleared but the COMMUN_FAIL alarm persists, reset (cold) the AUX board.

Reference Information

Meanings of possible values of the COMMUN_FAIL alarm parameter are as follows:

• 0x01 0x00 0x01 indicates that channel 1 of RS485 fails.
• 0x01 0x00 0x02 indicates that channel 2 of RS485 fails.
• 0x01 0x00 0x03 indicates that ETH communication between boards fails.
• 0x01 0x00 0x04 indicates that emergency ETH communication between subracks fails.

What is the command lines that we can use on the OLT to detect PRTE board status

How to check service board detail information?

How to Delete a Console Login Password?

How to Clear the LASER_HAZARD_WARNING Alarms Reported on Certain OBU and OAU Boards After an Upgrade of Software

After a software upgrade, certain OBU and OAU boards report the LASER_HAZARD_WARNING alarms, which are confusing for users. To avoid such an alarm, configure the IPA feature or disable monitoring of this alarm.

Product

OptiX OSN6800,OSN8800

Fault Type

Optical Amplifier Unit

LASER_HAZARD_WARNING

Symptom

During deployment for a project involving the OptiX BWS 1600G, the NE software of version 5.8.5.41 is upgraded to version 5.8.7.12 by means of package loading so that the NE software supports the 40G single wavelength feature. After the upgrade is complete, the E50BU and E50AU boards at certain stations report the LASER_HAZARD_WARNING alarms.

Cause Analysis

The LASER_HAZARD_WARNING alarm (an alarm for the hazard of the output optical power of the laser) indicates that the output optical power of the amplifier board reaches Class 3. Optical power at Class 3 may result in personal injuries (the board can reach Class 3 but may not reach currently). This amplifier board is not configured with the IPA feature. Thus the NE software reports this alarm.

The maximum output optical power of a laser at Class 3 ranges from 21.3 dBm to 27 dBm. The maximum output optical power of a laser at Class 4 ranges as high as 27 dBm.

• The NE software of version 5.8.7.12 and a later version supports the LASER_HAZARD_WARNING alarm.
• The ROP, RPA, RPC, or HBA board reports the LASER_HAZARD_WARNING alarm if the NE software report the LASER_HAZARD_WARNING alarm.
• In the case of an OAU, OBU, or OPU board, check whether the output optical power of the board reaches Class 3. The board reports the alarm if the output optical power of the board reaches Class 3.
  • An E3OAUC05 or OBUC05 board of version 3.31 and a later version supports the LASER_HAZARD_WARNING alarm.
  • An E4OAUC05 or OBUC05 board of version 4.21 and a later version supports the LASER_HAZARD_WARNING alarm.
  • An E5OAUC05 or OBUC05 board of version 5.13 and a later version supports the LASER_HAZARD_WARNING alarm.

Procedure

1. The LASER_HAZARD_WARNING alarm can be cleared by configuring the IPA feature on the amplifier board or configuring suppression of the LASER_HAZARD_WARNING alarm. The alarm may result in personal injuries. Therefore, you need to use the suppression function with caution.

Result

The problem is resolved.

Reference Information

None.

How to Delete a Console Login Password?

How to Use the LDMD Board to Configure Intra-Board 1+1 Protection Fails?

How to enable command log on S9300?

MTU Supported by an LBF Board for the 10G LAN Service on Client Side Cannot Be Configured

The MTU supported by an LBF board for the 10G LAN service on client side cannot be configured.

Product

OSN6800,OSN8800,WDM

Fault Type

Optical Transponder Unit

Symptom

When the WDM interface attributes on an E3LBFS board are configured by using the NMS, the Maximum Packet Length parameter cannot be configured after Service Type is set to 10GE(LAN). By default, Maximum Packet Length is 1518.

Cause Analysis

The possible causes of the preceding problem are as follows:

• An E2LBF board supports client-side services in two modes, that is, Flow Control Mode and Transparent Transmission Mode. In Flow Control Mode, the MTU is 9600 and cannot be changed. In Transparent Transmission Mode, the MTU is invalid.
• An E3LBF board supports the client-side services only in Transparent Transmission Mode. In this mode, the board transfers service packets transmitted from the client side without limits.

Procedure

1. None.

Result

The problem is resolved.

Reference Information

None.

How to Change the Link Type of an Interface?

10G Card Issue in Quidway S5300

In S5700 when configuring voice vlan there is an error says “no enough resources”

PMU Board Reports PWR_MAJ_ALM Due to Unfavorable Power Supply Environment

The PMU board reports a PWR_MAJ_ALM alarm due to unfavorable power supply environment.

Product

OptiX Metro 6100, OSN6800,OSN8800

Fault Type

Power Supply

PWR_MAJ_ALM

Symptom

When commissioning a network, field engineers find that the T2000 indicates that the input voltage of an OptiX Metro 6100 NE is excessively high (reaches -79.6 V). In this case, the PMU board reports a PWR_MAJ_ALM alarm to the T2000. However, after measuring the input voltage by using a voltmeter, the field engineers find that the input voltage is within the normal range (the measured voltage is -53 V).

Cause Analysis

The possible causes of this problem are as follows:

• The PMU board is faulty.
• The power supply environment is unfavorable.

Procedure

1. Replace the PMU board. The problem persists.
2. Measure the input voltage by using a broadband oscilloscope, finding that the input voltage (-53 V) contains high frequencies with the amplitude up to 80 V. Thus, the PMU board cannot identify the input voltage. As a result, the PMU board works abnormally and reports a PWR_MAJ_ALM alarm.

Result

The problem is resolved.

Reference Information

None.

When OptiX OSN 1800 Database Recovery Failures

How to Use the Ethernet Test Frames on the OptiX OSN 6800?

How to do when Failing to Connect the 155 Mbit/s Optical Port on the Router of Company C

T2000 Reports Errors After the Standard Optical Power of Single Wavelength Is Set to 7 dBm with ALC in Power Reference Mode

The T2000 reports errors after the standard optical power of a single wavelength is set to 7 dBm when ALC is in power reference mode.

Product

OptiX Metro 6100

OptiX Metro 6040

OSN6800

OSN8800

Fault Type

Automatic Level Control (ALC)

Symptom

In a network, the ALC function is configured for the OptiX Metro 6100 by using the iManager OptiX T2000. The network consists of five stations organized in OTM--OLA--OLA--OLA--OTM sequence. The OBU05 optical amplifier board is used at the transmit end of the first station and the ALC working mode of the station is set to Power Reference mode. Standard Output Power For Single Wavelength (dBm) of the OBU05 board is set to 7 dBm and that of other optical amplifier boards is set to 4 dBm.

After the settings are applied to the optical amplifier boards, the T2000 reports that these boards have different standard output power of single wavelength.

Cause Analysis

After an analysis, it is found that Standard Output Power For Single Wavelength (dBm) does not refer to the standard output optical power of a single wavelength on an optical amplifier board at a station when ALC is in Power Reference mode; instead, it refers to the standard output optical power of a single wavelength in the system. The standard output optical power of a single wavelength in the system is independent of an optical amplifier board but depends on the number of wavelengths in the system.

When there are 40 wavelengths in the system, Standard Output Power For Single Wavelength (dBm) must be set to 4 dBm; when there are 80 wavelengths, Standard Output Power For Single Wavelength (dBm) must be set to 1 dBm. In addition, the Standard Output Power For Single Wavelength (dBm) parameter for each station must be set to the same value. You cannot set this parameter for a station according to the standard output optical power of a single wavelength on an optical amplifier board.

Procedure

1. The OptiX Metro 6100 is a 40-wavelength system. Thus, set Standard Output Power For Single Wavelength (dBm) for the OptiX Metro 6100 to 4 dBm when the ALC function is in power reference mode.

Result

The problem is resolved.

Reference Information

None.

How to Use the LDMD Board to Configure Intra-Board 1+1 Protection Fails?

How to enable command log on S9300?

Why Automatical configuration backup cannot work on S5700

Manually Configuring Services Fails on the T2000 Due to Incorrect Configuration of Service Capacity

Manually configuring service fails on the T2000 due to incorrect configuration of service capacity.

Product

OptiX OSN 8800

Fault Type

Others

Symptom

The OptiX OSN 8800 master subrack connects to four OptiX OSN 6800 slave subracks and one OptiX OSN 8800 slave subrack. Configuring the ODU2 service between the TQX and NQ2 boards in the master subrack is successful. However, in the process of configuring a service between slave subracks, the system prompts that the service type in the license is incorrect. In this case, the version of the SCC board is 5.51.4.24 and the version of the NMS is iManager T2000 V200R007C03.

Cause Analysis

The service capacity of the OptiX OSN 8800 master subrack is 1.28T.

The possible cause of this problem is that the service capacity of the master subrack is set incorrectly on the T2000.

Procedure

1. Exclude the possibility that the service type of the master subrack is set incorrectly on the T2000 as configuring a service on the master subrack is successful.
2. At the station, analyze the service data of each slave subrack and then reconfigure the service data by running a command line, finding that the reconfigured serviced data is applied successfully to each slave subrack. This indicates that the service data of each slave subrack is set incorrectly on the T2000.
3. On the T2000, check the service data and find that the service capacity of the OptiX OSN 8800 slave subrack is different from that of the OptiX OSN 8800 master subrack. Then, delete the OptiX OSN 8800 slave subrack and re-create the slave subrack. In addition, select 1.28 as the service capacity of the slave subrack. After that, configure the service for the slave subrack on the T2000. At this point, the configuration is successful.

Result

The problem is resolved.

Reference Information

None.

How to Change the Link Type of an Interface?

10G Card Issue in Quidway S5300

When OptiX OSN 1800 Database Recovery Failures

LINK_ERR Occurs Due to an Optical Module Fault on the TQX Board

This section describes how to remove the LINK_ERR alarm resulting from an optical module fault on the TQX board.

Product

OptiX OSN 8800

Fault Type

Tributary Unit and Line Unit

LINK_ERR

Symptom

There are two channels of point-to-point 10G LAN services between station A and station B in a network. The TQX tributary board and NQ2 line board are used at either station. After the network connects to a router, it is found that both station A and station B report the LINK_ERR alarms in one channel of 10G LAN services. As a result, this channel of 10G LAN services is interrupted. However, the other channel of 10G LAN service runs normally.

Cause Analysis

The possible causes of this problem are as follows:

• The working mode of receive optical interface on WDM side the NQ2 board at the local station is different from the working mode of the transmit optical interface on the WDM side of the NQ2 board at the opposite station.
• The link is faulty.
• Optical fiber connections are incorrect.
• The opposite equipment is faulty.
• The input optical power of the client-side optical interface on the TQX board is excessively high or low.
• The working modes of the optical interfaces on the client side of the TQX board are inconsistent.
• The board at the local station is faulty.

Procedure

1. Exclude the possibility that working modes of the optical interfaces on the client side of the TQX board are inconsistent since the TQX board has no PHY chip.
2. Check the client-side optical power on the TQX board, finding that the receive optical power on the client side of the TQX board at station A is -6.7 dBm and that at station B is -8.1 dBm. Both of the receive optical power values are in normal range.
3. Make sure that the chip for detecting link status information is located behind the cross-connect chip since the TQX board has no Layer 2 chip. Then, configure an inloop on the client side of the NQ2 board at each of station A and station B, finding that the LINK_ERR alarm on the TQX board at station A is cleared but the LINK_ERR alarm on the TQX board at station B persists.
4. Perform a cold reset on the TQX board at station B. The LINK_ERR alarm persists.
5. Replace the optical module at optical interface 3 on the client side of the TQX board at station B, finding that the LINK_ERR alarm is cleared.
6. Release the inloop at stations A and B. At this point, the LINK_ERR alarm is cleared and normal connection between the network and the router is achieved.

Result

The problem is resolved.

Reference Information

None.

How to Use the LDMD Board to Configure Intra-Board 1+1 Protection Fails?

How to enable command log on S9300?

Why Automatical configuration backup cannot work on S5700