Showing posts with label OptiX OSN 6800 OptiX OSN 8800 WDM. Show all posts
Showing posts with label OptiX OSN 6800 OptiX OSN 8800 WDM. Show all posts

Thursday, October 20, 2016

ClientLP Port in Tributary-Line Mode on the TN52TOM Board Cannot Be Enabled to Work in Another Mode Because an RX/TX Port on the Board Is Configured as a Line-Side Port

The ClientLP port in tributary-line mode on the TN52TOM board cannot be enabled to work in another mode because an RX/TX port on the board is configured as a line-side port.

Product

http://www.thunder-link.com/HUAWEI-OPTIX-OSN8800_p193.html

Fault Symptom

Network Y is built with OptiX OSN 8800 equipment. The TN52TOM board is enabled to work in non-cascading mode, the ClientLP1, ClientLP3, and ClientLP5 ports are working in tributary mode, and the ClientLP7 port is in ODU1 tributary-line mode.

When the ClientLP7 port mode is changed to tributary mode or None, the U2000 displays "The port working mode of the board is incorrect. Error Code:44008", as shown in the following figure.

Network Topology

None.

Cause Analysis

  1. A cross-connection is present on the ClientLP7 port, so the port working mode is not allowed to be changed. When an attempt is made to change the port working mode, the U2000 will display an error message, indicating that the port has a cross-connection.
  2. On the board one or more RX/TX ports have been configured as line-side ports. When a line-side port is present on the board, at least one ClientLP port of the board must work in tributary-line mode.

Procedure

  1. Perform warm/cold resets on the TN52TOM board, and, if necessary, replace the board. If the fault persists, then the board is normal.
  2. Review the collected data of the TN52TOM board to check its working mode, service type, and cross-connection configurations. If the ClientLP1, ClientLP3, and ClientLP5 ports are working in tributary mode, and the ClientLP7 port is working in ODU1 tributary-line mode and has no cross-connection, then at least one RX/TX port has been incorrectly configured as line-side ports.
  3. Check the RX/TX port attributes and confirm that the RX4/TX4 port type is specified as Line Side Grey Optical Port.
  4. Set the RX4/TX4 port type as Client Side Grey Optical Port. Then changing the ClientLP7 port working mode to None has succeeded.

Conclusion and Suggestion

  • When an RX/TX port on the TN52TOM board is specified as a line-side port, at least one ClientLP port on the board must work in tributary-line mode.
  • To learn whether an RX/TX port functions as a line-side port, check the attributes of the port using the U2000 and then modify the port attributes as required.

MORE BLOG:
Posted by at No comments:
Labels:

Friday, September 9, 2016

The ODUk SNCP Protection Is Abnormal due to Incorrect Fiber Connections

The ODUk SNCP protection is abnormal due to incorrect fiber connections.

Product

OptiX OSN 3800

Fault Type

Protection

Symptom

The OptiX OSN 6800 is tested in an office. The tributary board is TQS, the line board is NS2, and the host version is 5.51.3.25.
One STM-16 service is configured between sites A, B, and C. The service is dropped at site A and site C, and ODUk SNCP protection is configured for the service. The service is configured to pass through site B at the electrical layer and wavelength 15 is used to transmit the service.
The test shows that the protection channel of ODUk SNCP protection between site A and site C is in the SF state and the working channel is normal.

Cause Analysis

The possible causes of the fault are as follows:
  • The pass-through service at site B is not configured or configured incorrectly.
  • The fiber connections are incorrect.

Procedure

  1. Check the service at site B and it is found that ODU1 cross-connections and service between two NS2 boards are configured correctly.
  2. On MCA boards at sites A, B, and C, scan all monitoring points of this channel to check for the optical power of wavelength 15. The optical power of wavelength 15 is scanned.
  3. Set OTN overheads on the two NS2 boards at sites A and B. Change the TTI byte in the SM overhead to A-slot ID-NS2 and B-slot ID-NS2. The corresponding two NS2 boards can detect the bytes transmitted from the opposite end, which indicates that the optical channel from site A to site B is normal.
  4. Repeat the preceding step to set the OTN overheads for the two interconnected NS2 boards at site B and site C. The two NS2 boards fail to receive the TTI byte from the opposite end. This indicates that the optical channel from site B to site C is abnormal. Optical fibers may be connected incorrectly.
  5. Check fiber connections at the sites. It is found that optical fibers are connected incorrectly at site C. Adjust fiber connections according to the network design. Then, the fault is rectified.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:
  • A fault cannot be located accurately only by checking alarms and scanning wavelengths because no optical-layer alarm is reported.
  • Modifying the TTI byte is an important means of checking fiber connection correctness of NG WDM equipment.
  • The correctness of fiber connections must be ensured in WDM engineering.

MORE BLOG:
Posted by at No comments:
Labels:

Tuesday, August 30, 2016

Incorrect Configuration of an Added Wavelength

During expansion, service interruption occurs in a normal wavelength on an OTU board and the corresponding OTU board reports OTU2_LOF alarm because of the incorrect wavelength configuration of an added wavelength.

Product

Fault Type

Service Interruption
OTU2_LOF

Symptom

When a 192.20 THz wavelength is added for expansion between sites F and G, the services on the 192.10 THz wavelength between sites B and G are interrupted. In addition, the corresponding OTU board at site G reports an OTU2_LOF alarm.
Figure 1 The Channel allocation of office T in V Network
Figure 2 The internal fiber connections of site F in V Network

Cause Analysis

The possible causes of the fault are as follows:
  • The 192.10 THz OTU boards at sites B and G are faulty.
  • The 192.10 THz OTU board at site G receives excessively low optical power.
  • A 192.10 THz wavelength is introduced between sites B and G, thus resulting in conflicting wavelengths.

Procedure

  1. Query the alarms and performance events of the 192.10 THz OTU boards at sites B and G.
    1. The performance of the OTU board at site B is normal, but the OTU2_BDI and ODU2_PM_BDI alarms are generated on the board.
    2. The OTU2_LOF, OTU2_SSF, and ODU2_PM_SSF alarms are generated on the OTU board at site G, but the receive optical power on the WDM side of the board is proper.

    Considering that the line power does not change, it is determined that the services may be interrupted due to an OTU2_LOF alarm on the WDM side of the OTU board at site G. Thus, the OTU boards at sites B and G may be faulty.
  2. Sites B and G are left unattended. Thus, the OTU boards at the two sites cannot be tested by performing a fiber loopback on each of them. To restore the services in time, perform a cold reset on the OTU board at site B.
    1. When the OTU board at site B is cold reset, no R_LOS alarm is generated on the WDM side of the OTU board at site G but the OTU2_LOF alarm persists. In addition, the receive optical power on the WDM side of the board decreases from –8 dBm to –9.5 dBm.
    2. After the OTU board at site B is cold reset, the fault persists.

    The OTU board at site G may receive an excess 192.10 THz wavelength based on the preceding information.
  3. Disable the laser on the WDM side of the OTU at site B to check whether the OTU board at site G still receives signals with optical power of –9.5 dBm. Then, disable the laser on the WDM side of the OTU board at site G and find that the receive optical power of the OTU board at site B is –60 dBm and that a R_LOS alarm is reported.
    An excess 192.10 THz wavelength may exist on the fiber from site B to site G.
  4. Ask the customer whether the customer adds a board or changes a fiber connection on the live network during the time when the fault occurs.
    1. Check whether the customer has added an OTU board and established the corresponding physical fiber connection at site F to provide a 192.20 THz wavelength between sites F and G.
    2. Query the wavelength information about the new OTU board at site F and find that the wavelength is 192.10 THz and that the new OTU board is physically connected to the M40 optical interface on the TN11M40 board.

    The services on an existing wavelength are interrupted because the wavelength on the new board is set incorrectly.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:
The NG WDM equipment uses the TN11RMU9 board for wavelength multiplexing. Conflicted wavelengths will result if wavelengths are planned or configured incorrectly. In this case, services on the equipment will be interrupted.

MORE BLOG:

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

Posted by at No comments:
Labels:

The LQG Board Works Abnormally Due to Incorrect Clock Configuration On The Board And The Board Reports CLIENT_SF And R_LOC Alarm

The LQG board works abnormally and the board reports CLIENT_SF and R_LOC alarm due to incorrect clock configuration on the board.

Product

OptiX Metro 6100
OptiX Metro 6040

Fault Type

CLIENT_SF
R_LOC

Symptom

On a network built with the OptiX Metro 6100, two GE services are configured between sites A and B. The LQG board reports a CLIENT_SF alarm on the channel with abnormal services. The services are not configured with protection.
Check for the history alarms in the data sent back by field engineers and find that the LQG board at site A is interconnected with the LQG board at site B and the two LQG boards report the transient R_LOC alarms.

Cause Analysis

The possible causes of the fault are as follows:
  • The WDM system functions abnormally.
  • The LQG boards are faulty.
  • The clock source settings of the LQG boards are incorrect.

Procedure

  1. Check the network topology, and find that the other boards on the same route work normally and the receive and transmit optical power of the two interconnected LQG boards are proper. Thus, rule out the possibility that the WDM system is faulty.
  2. Query alarms on the two LQG boards and find that the boards report the transient R_LOC alarms for a long time. Then, query the clock source settings of the boards and find that two LQG boards are enabled to trace the line clock. See the following figure.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:
The WDM-side clock source in the transmit direction of the LQG board is configured incorrectly and thus four channels of services are faulty.
As shown in the preceding figure, 1#LQG and 2#LQG are interconnected through their WDM sides and the WDM-side clock sources in the transmit directions of the two boards are configured as the line clock. In this manner, the WDM-side transmitter on 1#LQG traces the clock from 2#LQG and the WDM-side transmitter on 2#LQG traces the clock from 1#LQG. The WDM-side transmitters on the two LQG boards trace each other's clock and thus the clock signals deteriorate continuously. Consequently, exceptions occur on the WDM sides of the two boards and the services on the boards are affected. Generally, a transient CLIENT_SF, CLIENT_SD, ALM_ETH_PORT_TLOS, or ALM_ETH_PORT_RLOS alarm is reported on the client side of a board when an R_LOC or a B1_EXC alarm is generated on the WDM side of the board.


MORE BLOG:

When customized for North America unable to configure OSN1800.

Posted by at No comments:
Labels:

Friday, August 26, 2016

OptiX OSN 6800 Fails to Create an End-to-End GE Service Because No Electrical Server Trail Is Created

The OptiX OSN 6800 fails to create an end-to-end GE service because no electrical server trail is created.

Product

Fault Type

End-to-End Trail

Symptom

During deployment of the OptiX OSN 6800 of version V100R003, the L4G board is used at an ROADM site configured with the WSD9 and RMU9 boards. After fiber connections are established, OTS and OMS trails are created. An attempt to create an end-to-end GE service by using the T2000 V200R006C01 is made. After an end-to-end OCh server trail is created on the T2000, the T2000 will automatically configure optical cross-connections. However, the T2000 cannot continue to create an end-to-end GE service.

Cause Analysis

At an ROADM site configured with the WSD9 and RMU9 boards, the ODU5G and OTU5G server trails cannot be created after an OCh server trail is created. In the current version of the T2000, users need to find the ODU5G and OTU5G server trails by using the search function. A Client GE service must be created over the OCh trail and OTU5G and ODU5G trails.
Figure 1 shows the relationships between trails.
Figure 1 Relationships between trails in the OTN architecture

Procedure

  1. After an OCh server trail is created, users need to search for the ODU5G and OTU5G server trails by using the WDM trail search function of the T2000.
  2. Create an end-to-end Client GE service on the T2000. After the Client GE service is created, the T2000 automatically configure the electrical cross-connections.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:
End-to-end grooming is a significant process of WDM service management. The T2000 supports creation of network-level end-to-end services. After users specify the source and sink of a service, the T2000 will automatically create a Client trail based on the server trails search out from the WDM trails. The function of creating WDM trails effectively simplifies the service configuration process and ensures that an operation is performed properly during service configuration. In addition, this function ensures flexible service grooming and deployment during network deployment or expansion. When the T2000 is used to deploy end-to-end services, users need to search for trails after an OCh trail is created and then create a Client trail based on the available trails.

MORE BLOG:

When Slave Main Control Board Unregistration on an ATN 950B

Posted by at No comments:
Labels:

Thursday, August 25, 2016

The Board Software Fails to Automatically Match a Board After the Board is Replaced

The board software fails to automatically match a board after the board is replaced.

Product

Fault Type

Software Upgrade
SWDL_AUTOMATCH_INH
SWDL_CHGMNG_NOMATCH
SWDL_PKG_NOBDSOFT

Symptom

The board software fails to automatically match a board after the board is replaced.

Cause Analysis

The possible causes of the fault are as follows:
An alarm indicating that an exception occurs during package loading is reported by the NE. Consequently, the board software fails to automatically match the board.

Procedure

  1. Check whether the NE reports the SWDL_AUTOMATCH_INH alarm, which indicates that the automatic matching function of the NE is disabled. If the SWDL_AUTOMATCH_INH alarm is reported, contact Huawei engineers for processing.
  2. Check whether the NE reports the SWDL_CHGMNG_NOMATCH alarm, which indicates that the SCC board is replaced. If the SWDL_CHGMNG_NOMATCH alarm is reported, the board software fails to automatically match the board. For information about how to clear the alarm, see the Alarms and Performance Events Reference.
  3. Check whether the NE reports the SWDL_PKG_NOBDSOFT alarm indicating that certain files are removed and whether the alarm parameter shows the slot number of the new board. If the SWDL_PKG_NOBDSOFT alarm is reported, it indicates that the software package of the NE does not contain the board software. For information about how to clear the alarm, see theAlarms and Performance Events Reference.
     NOTE:
    If the NE reports the SWDL_CHGMNG_NOMATCH alarm and the SWDL_PKG_NOBDSOFT alarm, clear the former one immediately and then the latter one.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:
In routine maintenance, do not suppress the alarms associated with package loading and with names begin with SWDL. If these alarms are reported, clear them immediately.

MORE BLOG:

When Slave Main Control Board Unregistration on an ATN 950B

Posted by at No comments:
Labels:

SNCP Protection Switching Fails Due to Incorrect Fiber Connections

The SNCP protection switching fails due to incorrect fiber connections.

Product

Fault Type

Protection

Symptom

In one provincial backbone ring network, the network consists of multiple sites and is configured with the SNCP protection. However, the SNCP protection switching fails during commissioning of the network.
Figure 1 The Network Topology of One Provincial Backbone Ring Network

Cause Analysis

The possible causes of the fault are as follows:
  • The parameters of the SNCP protection group are set incorrectly.
  • The board on the protection path is faulty.
  • The fiber connections are established incorrectly.

Procedure

  1. Confirm that the SNCP protection group is configured correctly.
  2. Confirm that the boards on the working and protection paths work normally and have not reported any fault-related alarm.
  3. Check the network configurations against the fiber connection diagrams in engineering design documents and find that fiber connections are established incorrectly at an OTM site. After correcting the fiber connections, perform SNCP protection switching again and find that protection switching is successful.
    The following figure shows the fiber connection diagram for site OTM.
    The following figure shows how the fibers at site OTM are connected.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:
Check the fiber and cable connections in each deployment phase of the network to ensure that boards, subracks, and network cables are connected correctly.


MORE BLOG:

Prewarning for ARP Entry Aging Failures on MxU

Posted by at No comments:
Labels:
Subscribe to: Posts (Atom)