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.

Internal Communication of an NE Is Abnormal And Many Boards Report Transiently BD_STATUS or COMMUN_FAIL Alarms Due to Conflicted Subrack IDs

The internal communication of an NE is abnormal and many boards report transiently BD_STATUS or COMMUN_FAIL alarms due to the conflicted subrack IDs.

Product

OptiX OSN 6800

OptiX OSN 8800

Fault Type

NE Offline

BD_STATUS

COMMUN_FAIL

Symptom

On network C built with the OptiX OSN 6800, many boards on an NE report a transient BD_STATUS or COMMUN_FAIL alarm. A query of the NE configuration shows that the logical board for slot 10 is sometimes displayed as TMX and sometimes displayed as XCS. Actually, the board housed in slot 10 is the TMX board.

Cause Analysis

Communication between the boards on an NE is abnormal when many boards on the NE report a transient BD_STATUS or COMMUN_FAIL alarm. The possible causes of the fault are as follows:

• The boards that report the alarms are faulty.
• The AUX board, which is the communication hub of the NE, is faulty.
• An external factor results in abnormal communication.

Procedure

1. Considering that many boards of the NE report a transient BD_STATUS or COMMUN_FAIL alarm, suspect that internal communication of the NE may be abnormal.
2. Rule out the possibility that the boards reporting the BD_STATUS or COMMUN_FAIL alarm are faulty since many boards of the NE report the same alarm.
3. The logical board in slot 10 changes frequently. Thus, suspect that conflicting subrack IDs exist.
4. Check the NE configurations at the site and find that two subracks of the NE use the same ID. Thus, determine that this problem is due to conflicting subrack IDs.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:

After changing the settings of the DIP switches of a subrack in the engineering or maintenance phase, perform a power-off reset on the subrack so that the settings of the DIP switches take effect.

MORE BLOG:

Access Capacity of Slots of the OptiX OSN 1500 V1R2

How to Assemble an IMPI on the MA5620G?

Why can not login S5700 after S5700 power on when the software version was upgraded to V200R005C00SPC500?

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?

The use of the Huawei OSN 8800

The OptiX OSN 8800 is mainly deployed in national backbone networks, regional/provincial backbones, and some metropolitan core sites. In addition to large capacities and long-haul WDM features, the OptiX OSN 8800 integrates:

• ROADM
• T-bit electrical cross-connection
• Full-granularity grooming ranging from 100Mbit/s to 100Gbit/s
• Optical-electrical ASON synergy
• 40G/100G transmission capability
• Various management and protection functions

Empowered by these features, the OptiX OSN 8800 provides carriers with end-to-end OTN/WDM backbone transport solutions to accommodate large-capacity grooming and ultra-wideband transmission.

Together, the OptiX OSN 8800 T64/T32/T16 and OptiX OSN 1800 can form a complete end-to-end OTN network. The OptiX OSN 8800 can also be used with the hybrid MSTP, PTN, or data communication equipment to achieve a complete transport solution.

According to information released by Ovum, a well-known consulting firm in the telecom industry, by 2012 Huawei led the global optical network market,WDM/OTN market, and 100G/40G market, as well as the backbone WDM market. Huawei WDM/OTN solution has served 39 of the worldwide Huawei MSTP top 50 carriers.

Why can not login S5700 after S5700 power on when the software version was upgraded to V200R005C00SPC500?

When customized for North America unable to configure OSN1800.

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

When Receive Optical Power Is Excessively Low Because of the End Face Problem of the Fiber Jumper, the OAU Board Reports the MUT_LOS Alarm

The receive optical power is excessively low because of the end face problem of the fiber jumper. The OAU board reports the MUT_LOS alarm.

Product

OptiX OSN6800,OSN8800,OTN

Fault Type

Abnormal optical power

Fiber

MUT_LOS

R_LOS

Symptom

In a network consisting of the OptiX BWS 1600G equipment, a fiber jumper on the ODF is removed and then inserted when the RPC laser is enabled. In this case, the fiber connector is burnt out. After the fiber and fiber jumper are replaced, the receive optical power of the RPC is excessively low (-53 dB).

The OAU board at the station reports the MUT_LOS alarm.

Cause Analysis

Measure the optical power on the entire optical path. The results are as follows:

• The transmit optical power on the FIU at the opposite station is normal.
• The optical power on the receive side of the ODF at the local station is normal. That is, the line attenuation is normal.
• The optical power at the receive end of the OAU board at the local station is excessively low.
• The input optical power at the IN optical interface on the FIU at the local station is excessively low.
• The fiber jumper between the SYS optical interface on the RPC and the IN optical interface on the FIU is normal.

According to the preceding results, it is determined that the exception is located between the ODF and the FIU. The possible causes are as follows:

• The fiber jumper between the ODF and the RPC is faulty.
• The RPC is faulty.

Procedure

1. Check the fiber jumper between the ODF and the RPC. It is found that the fiber jumper of the FC/PC-LSH/UPC type is used. The connector for the LINE optical interface on the RPC used on the OptiX BWS 1600G is of the LSH/APC type. The end face of the UPC connector is flat while that of the APC connector is tilted. As a result, there is air spacing between the LINE optical interface on the RPC and the connector of the fiber jumper from the ODF, and therefore the pump light of the RPC cannot be normally transmitted on the optical path. Consequently, the receive optical power is excessively low. After the fiber jumper is changed to FC/PC-LSH/APC, the system is normal.

Result

The problem is resolved.

Reference Information

• Disable the lasers on a Raman optical amplifier before performing any operations on the optical path with the Raman optical amplifier.
• The optical module interfaces for Raman optical amplifiers provided by different equipment vendors are different. Huawei and certain vendors use LSH/APC while other vendors use LSH/UPC.

How to check service board detail information?

How to Delete a Console Login Password?

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

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